KINK Conformance Test Specification Revision 1.0.0

Transcription

KINK Conformance Test Specification Revision 1.0.0
TAHI Project
Conformance Test Specification
KINK
Technical Document
Revision 1.0.0
Converged Test Specification
TAHI Project (Japan)
MODIFICATION RECORD
Version 1.0.0
Version 0.1.0
Version 0.0.0
Mar. 23, 2010
- supported whole message exchanges in RFC 4430
Feb. 24, 2009
- supported only optimistic keying
Jan. 15, 2009
- launched this document
TAHI Project TECHNICAL DOCUMENT
1
KINK Test Specification
ACKNOWLEDGMENTS
The TAHI Project would like to acknowledge the efforts of the following organizations in
the development of this test suite.
Authors:
Yokogawa Electric Corporation
Commentators:
NTT Advanced Technology Corporation (NTT-AT)
Note:
Development of this document was supported in part by a grant from NICT.
TAHI Project TECHNICAL DOCUMENT
2
KINK Test Specification
INTRODUCTION
Overview:
TAHI Project is the joint effort formed with the objective of developing and providing
the verification technology for IPv6.
The growth process of IPv4 was the history of encountering various kinds of obstacles
and conquering such obstacles.
However, once the position as infrastructure was
established, it is not allowed to repeat the same history.
This is a reason why the
verification technology is essential for IPv6 deployment.
We research and develop conformance tests and interoperability tests for IPv6.
We closely work with the KAME project and USAGI project.
We help activities of these
projects in the quality side by offering the verification technology we develop in TAHI
project and improve the development efficiency.
We open the results and fruits of the project to the public for FREE.
Any developer
concerned with IPv6 can utilize the results and fruits of TAHI project freely.
software plays an important role in progress of the Internet.
Free
We believe that providing
the verification technology for FREE contributes to advances of IPv6.
Besides the programs, the specifications and criteria of verification will be included in
the Package.
TAHI Project TECHNICAL DOCUMENT
3
KINK Test Specification
Abbreviations and Acronyms:
TN:
TH:
TR:
NUT:
HUT:
RUT:
EN:
SGW:
SPI:
KDC:
KINK:
DPD:
PFS:
SA:
P:
T
KE:
IDi:
IDr:
Ni:
Nr:
N:
D:
TLV:
TV:
Testing Node
Testing Host
Testing Router
Node Under Test
Host Under Test
Router Under Test
End Node
Security Gateway
Security Parameter Index
Key Distribution Center
Kerberized Internet Negotiation of Keys
Dead Peer Detection
Perfect Forward Secrecy
Security Association
Proposal
Transform
Key Exchange
Identification – Initiator
Identification – Responder
Nonce – Initiator
Nonce – Responder
Notification
Delete
Type/Length/Value
Type/Value
TAHI Project TECHNICAL DOCUMENT
4
KINK Test Specification
Advanced Functionality Tests:
The following tests may be omitted if the NUT does not support the advanced
functionalities.
Test Label
EN.EN.I.1.1
EN.EN.I.1.2
EN.EN.I.1.3
EN.EN.I.2.1
EN.EN.I.2.2
EN.EN.I.2.3
EN.EN.I.2.4
EN.EN.I.2.5
EN.EN.I.2.6
EN.EN.I.3.1
EN.EN.I.4.1
EN.EN.I.6.1
EN.EN.I.7.1
EN.EN.I.7.2
EN.EN.I.7.3
EN.EN.I.8.1
EN.EN.I.8.2
EN.EN.I.8.3
EN.EN.I.8.4
EN.EN.I.8.5
EN.EN.I.8.6
EN.EN.I.8.7
EN.EN.I.8.8
EN.EN.I.9.1
EN.EN.I.9.2
EN.EN.I.9.3
EN.EN.I.9.4
EN.EN.I.9.5
EN.EN.R.1.1
EN.EN.R.1.2
EN.EN.R.2.1
EN.EN.R.2.2
EN.EN.R.2.3
EN.EN.R.2.4
EN.EN.R.2.5
EN.EN.R.2.6
EN.EN.R.2.7
EN.EN.R.2.8
EN.EN.R.2.9
EN.EN.R.3.1
EN.EN.R.3.2
EN.EN.R.4.1
EN.EN.R.4.2
EN.EN.R.4.3
EN.EN.R.5.1
EN.EN.R.5.2
Part
A
A
A
A
B
C
D
E
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
B
C
D
E
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
ENs
(BASIC)
(BASIC)
(BASIC)
(ADVANCED)
(ADVANCED)
(ADVANCED)
(ADVANCED)
(ADVANCED)
(BASIC)
(ADVANCED)
(ADVANCED)
(ADVANCED)
(ADVANCED)
(ADVANCED)
(BASIC)
(BASIC)
(ADVANCED)
(ADVANCED)
(ADVANCED)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(ADVANCED)
(ADVANCED)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(ADVANCED)
(ADVANCED)
(ADVANCED)
(ADVANCED)
(ADVANCED)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(ADVANCED)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
SGWs
-
Required ADVANCED function
NULL encryption algorithm
AES-CBC with 128-bit keys
AES-CTR with 128-bit keys
NULL authentication algorithm
AES-XCBC-MAC-96
Transmitting multiple Transform payloads
Transmitting multiple Transform payloads
Transmitting multiple Proposal payloads
Transmitting multiple Proposal payloads
PFS
User-to-User authentication
User-to-User authentication
User-to-User authentication
User-to-User authentication
User-to-User authentication
NULL encryption algorithm
AES-CBC with 128-bit keys
AES-CTR with 128-bit keys
NULL authentication algorithm
AES-XCBC-MAC-96
PFS
-
-
TAHI Project TECHNICAL DOCUMENT
5
KINK Test Specification
EN.EN.R.6.1
EN.EN.R.6.2
EN.EN.R.6.3
EN.EN.R.7.1
EN.EN.R.7.2
EN.EN.R.7.3
EN.EN.R.7.4
EN.EN.R.8.1
EN.EN.R.8.2
EN.EN.R.8.3
EN.EN.R.8.4
EN.EN.R.8.5
EN.EN.R.8.6
EN.EN.R.9.1
EN.EN.R.9.2
EN.EN.R.9.3
EN.EN.R.9.4
EN.EN.R.9.5
EN.EN.R.9.6
EN.EN.R.9.7
EN.EN.R.9.8
EN.EN.R.9.9
EN.EN.R.9.10
EN.EN.R.9.11
EN.SGW.I.1.1
EN.SGW.R.1.1
SGW.SGW.I.1.1
SGW.SGW.I.1.2
SGW.SGW.I.1.3
SGW.SGW.I.1.4
SGW.SGW.I.2.1
SGW.SGW.I.2.2
SGW.SGW.I.2.3
SGW.SGW.I.2.4
SGW.SGW.I.2.5
SGW.SGW.I.2.6
SGW.SGW.I.3.1
SGW.SGW.I.4.1
SGW.SGW.I.6.1
SGW.SGW.I.7.1
SGW.SGW.I.7.2
SGW.SGW.I.7.3
SGW.SGW.I.8.1
SGW.SGW.I.8.2
SGW.SGW.I.8.3
SGW.SGW.I.8.4
SGW.SGW.I.8.5
SGW.SGW.I.8.6
SGW.SGW.I.8.7
SGW.SGW.I.8.8
SGW.SGW.I.9.1
SGW.SGW.I.9.2
SGW.SGW.I.9.3
SGW.SGW.I.9.4
SGW.SGW.I.9.5
SGW.SGW.R.1.1
SGW.SGW.R.1.2
SGW.SGW.R.2.1
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
B
A
A
A
A
A
A
A
A
A
A
A
A
A
A
B
C
D
E
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
B
(BASIC)
(BASIC)
(BASIC)
(ADVANCED)
(ADVANCED)
(ADVANCED)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(ADVANCED)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(ADVANCED)
(ADVANCED)
-
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(ADVANCED)
(ADVANCED)
(ADVANCED)
(ADVANCED)
(ADVANCED)
(BASIC)
(ADVANCED)
(ADVANCED)
(ADVANCED)
(ADVANCED)
(ADVANCED)
(BASIC)
(BASIC)
(ADVANCED)
(ADVANCED)
(ADVANCED)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(ADVANCED)
(ADVANCED)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(ADVANCED)
(ADVANCED)
TAHI Project TECHNICAL DOCUMENT
6
User-to-User authentication
User-to-User authentication
User-to-User authentication
User-to-User authentication
Endpoint to Security Gateway Tunnel
Endpoint to Security Gateway Tunnel
NULL encryption algorithm
AES-CBC with 128-bit keys
AES-CTR with 128-bit keys
NULL authentication algorithm
AES-XCBC-MAC-96
Transmitting multiple Transform payloads
Transmitting multiple Transform payloads
Transmitting multiple Proposal payloads
Transmitting multiple Proposal payloads
PFS
User-to-User authentication
User-to-User authentication
User-to-User authentication
User-to-User authentication
User-to-User authentication
NULL encryption algorithm
AES-CBC with 128-bit keys
KINK Test Specification
SGW.SGW.R.2.2
SGW.SGW.R.2.3
SGW.SGW.R.2.4
SGW.SGW.R.2.5
SGW.SGW.R.2.6
SGW.SGW.R.2.7
SGW.SGW.R.2.8
SGW.SGW.R.2.9
SGW.SGW.R.3.1
SGW.SGW.R.3.2
SGW.SGW.R.4.1
SGW.SGW.R.4.2
SGW.SGW.R.4.3
SGW.SGW.R.5.1
SGW.SGW.R.5.2
SGW.SGW.R.6.1
SGW.SGW.R.6.2
SGW.SGW.R.6.3
SGW.SGW.R.7.1
SGW.SGW.R.7.2
SGW.SGW.R.7.3
SGW.SGW.R.7.4
SGW.SGW.R.8.1
SGW.SGW.R.8.2
SGW.SGW.R.8.3
SGW.SGW.R.8.4
SGW.SGW.R.8.5
SGW.SGW.R.8.6
SGW.SGW.R.9.1
SGW.SGW.R.9.2
SGW.SGW.R.9.3
SGW.SGW.R.9.4
SGW.SGW.R.9.5
SGW.SGW.R.9.6
SGW.SGW.R.9.7
SGW.SGW.R.9.8
SGW.SGW.R.9.9
SGW.SGW.R.9.10
SGW.SGW.R.9.11
SGW.EN.I.1.1
SGW.EN.R.1.1
C
D
E
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
B
A
A
A
A
A
A
A
A
A
-
(ADVANCED)
(ADVANCED)
(ADVANCED)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(ADVANCED)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(ADVANCED)
(ADVANCED)
(ADVANCED)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(ADVANCED)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(BASIC)
(ADVANCED)
(ADVANCED)
TAHI Project TECHNICAL DOCUMENT
7
AES-CTR with 128-bit keys
NULL authentication algorithm
AES-XCBC-MAC-96
PFS
User-to-User authentication
User-to-User authentication
User-to-User authentication
User-to-User authentication
Endpoint to Security Gateway Tunnel
Endpoint to Security Gateway Tunnel
KINK Test Specification
TEST ORGANIZATION
This document organizes tests by Section based on related test methodology or goals.
Each group begins with a brief set of comments pertaining to all tests within that group.
This is followed by a series of description blocks; each block describes a single test. The
format of the description block is as follows:
Test Label:
Purpose:
References:
Resource
Requirements:
Test Setup:
Procedure:
Observable
Results:
Possible
Problems:
The test label and title comprise the first line of the test block. The
test label is composed by concatenating the short test suite name, the
section number, the group number, and the test number within the
group. These elements are separated by periods. The Test
Number is the section, group and test number, also separated by
periods.
The Purpose is a short statement describing what the test attempts
to achieve. It is usually phrased as a simple assertion of the feature
or capability to be tested.
The References section lists cross-references to the specifications and
documentation that might be helpful in understanding and
evaluating the test and results.
The Resource Requirements section specifies the software, hardware,
and test equipment that will be needed to perform the test.
The Test Setup section describes the configuration of all devices prior
to the start of the test. Different parts of the procedure may involve
configuration steps that deviate from what is given in the test setup.
If a value is not provided for a protocol parameter, then the protocol’s
default is used for that parameter.
This section of the test description contains the step-by-step
instructions for carrying out the test. These steps include such
things as enabling interfaces, unplugging devices from the network,
or sending packets from a test station. The test procedure also cues
the tester to make observations, which are interpreted in accordance
with the observable results given for that test part.
This section lists observable results that can be examined by the
tester to verify that the NUT is operating properly. When multiple
observable results are possible, this section provides a short
discussion on how to interpret them. The determination of a pass or
fail for each test is usually based on how the NUT’s behavior
compares to the results described in this section.
This section contains a description of known issues with the test
procedure, which may affect test results in certain situations.
TAHI Project TECHNICAL DOCUMENT
8
KINK Test Specification
REFERENCES
The following documents are referenced in this text:
[KERBEROS]
[KINK]
Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos
Network Authentication Service (V5)", RFC 4120, July 2005.
Sakane, S., Kamada, K., Thomas, M. and J. Vilhuber, "Kerberized
Internet Negotiation of Keys (KINK)", RFC 4430, March 2006.
TAHI Project TECHNICAL DOCUMENT
9
KINK Test Specification
TABLE OF CONTENTS
MODIFICATION RECORD ................................................................................................ 1
ACKNOWLEDGMENTS .................................................................................................... 2
INTRODUCTION................................................................................................................ 3
Overview: ......................................................................................................................... 3
Abbreviations and Acronyms: ......................................................................................... 4
Advanced Functionality Tests: ........................................................................................ 5
TEST ORGANIZATION...................................................................................................... 8
REFERENCES .................................................................................................................... 9
TABLE OF CONTENTS ................................................................................................... 10
Requirements .................................................................................................................... 17
Equipment Type:............................................................................................................ 17
Function List:................................................................................................................. 18
Chapter 1: EN implementation ........................................................................................ 19
Section 1.1: EN to EN Transport .................................................................................. 20
Subsection 1.1.1: Initiator.......................................................................................... 23
Group 1: CREATE Message Flow .......................................................................... 35
EN.EN.I.1.1: Sending CREATE Message .......................................................... 36
EN.EN.I.1.2: CREATE Message Flow (2-way handshake) ............................... 38
EN.EN.I.1.3: The non-optimistic keying by receipt of Nr ................................. 41
Group 2: Cryptographic Algorithm Negotiation.................................................... 44
EN.EN.I.2.1: Cryptographic Algorithm Negotiation ......................................... 45
EN.EN.I.2.2: The shorter LIFE_SECONDS is selected from optimistic proposal
............................................................................................................................. 49
EN.EN.I.2.3: The optimistic proposal is selected from multiple transforms ... 52
EN.EN.I.2.4: The non-optimistic proposal is selected from multiple transforms
............................................................................................................................. 56
EN.EN.I.2.5: The optimistic proposal is selected from multiple proposals...... 60
EN.EN.I.2.6: The non-optimistic proposal is selected from multiple proposals
............................................................................................................................. 64
Group 3: Perfect Forward Secrecy ......................................................................... 68
EN.EN.I.3.1: PFS................................................................................................ 69
Group 4: Rekeying .................................................................................................. 74
EN.EN.I.4.1: Initiating Rekeying....................................................................... 75
Group 5: DELETE Message Flow .......................................................................... 78
TAHI Project TECHNICAL DOCUMENT
10
KINK Test Specification
Group 6: Dead Peer Detection................................................................................ 79
EN.EN.I.6.1: Initiating Liveness Check ............................................................ 80
Group 7: GETTGT Message Flow .......................................................................... 83
EN.EN.I.7.1: Sending GETTGT Message .......................................................... 84
EN.EN.I.7.2: GETTGT Message Flow ............................................................... 86
EN.EN.I.7.3: Receipt of KINK_TGT_REP against a KINK command with a
User-to-User ticket that cannot be decrypted with its TGT ............................. 89
Group 8: Retransmission........................................................................................ 92
EN.EN.I.8.1: Retransmission of CREATE ......................................................... 93
EN.EN.I.8.2: Stop the retransmission of CREATE ........................................... 96
EN.EN.I.8.3: Responding to retransmitted REPLY with the ACKREQ bit set99
EN.EN.I.8.4: Retransmission of STATUS........................................................ 102
EN.EN.I.8.5: Stop the retransmission of STATUS.......................................... 105
EN.EN.I.8.6: Retransmission of GETTGT....................................................... 109
EN.EN.I.8.7: Stop the retransmission of GETTGT ......................................... 111
EN.EN.I.8.8: Restart a new transaction by receipt of
KRB_AP_ERR_TKT_EXPIRED ....................................................................... 114
Group 9: Message Validation ............................................................................... 117
EN.EN.I.9.1: Responding to KINK_ERROR with the ACKREQ bit set......... 118
EN.EN.I.9.2: Receipt of REPLY with non-zero value in reserved field .......... 121
EN.EN.I.9.3: Receipt of unencrypted REPLY.................................................. 124
EN.EN.I.9.4: Receipt of authenticated KRB_AP_ERR_SKEW ...................... 127
EN.EN.I.9.5: Receipt of unauthenticated KRB_AP_ERR_SKEW .................. 131
Subsection 1.1.2: Responder .................................................................................... 135
Group 1: CREATE Message Flow ........................................................................ 151
EN.EN.R.1.1: Receipt of CREATE Message .................................................... 152
EN.EN.R.1.2: CREATE Message Flow ............................................................ 155
Group 2: Cryptographic Algorithm Negotiation.................................................. 158
EN.EN.R.2.1: Cryptographic Algorithm Negotiation ...................................... 159
EN.EN.R.2.2: The shorter LIFE_SECONDS is proposed ............................... 163
EN.EN.R.2.3: Selecting the optimistic proposal from multiple transforms ... 168
EN.EN.R.2.4: Selecting the non-optimistic proposal from multiple transforms
........................................................................................................................... 172
EN.EN.R.2.5: Selecting the optimistic proposal from multiple proposals ..... 176
EN.EN.R.2.6: Selecting the non-optimistic proposal from multiple proposals
........................................................................................................................... 180
TAHI Project TECHNICAL DOCUMENT
11
KINK Test Specification
EN.EN.R.2.7: Responding to multiple KINK_ISAKMP by optimistic keying 184
EN.EN.R.2.8: Responding to multiple KINK_ISAKMP by non-optimistic
keying ................................................................................................................ 196
EN.EN.R.2.9: Sending NO-PROPOSAL-CHOSEN ......................................... 206
Group 3: Perfect Forward Secrecy ....................................................................... 211
EN.EN.R.3.1: PFS............................................................................................. 212
EN.EN.R.3.2: Sending INVALID-PAYLOAD-TYPE against the receipt of KE
........................................................................................................................... 217
Group 4: Rekeying ................................................................................................ 222
EN.EN.R.4.1: Responding to Rekeying............................................................ 223
EN.EN.R.4.2: Receipt of transaction ID constructed by using a non monotonic
counter............................................................................................................... 227
EN.EN.R.4.3: Responding to CREATE with INVALID-SPI............................ 231
Group 5: DELETE Message Flow ........................................................................ 236
EN.EN.R.5.1: DELETE Message Flow ............................................................ 237
EN.EN.R.5.2: Responding to DELETE with INVALID-SPI ........................... 240
Group 6: Dead Peer Detection.............................................................................. 245
EN.EN.R.6.1: Responding to Liveness Check.................................................. 246
EN.EN.R.6.2: Closing SA when the principal's epoch has changed ............... 249
EN.EN.R.6.3: Not closing SA by unprotected routing information ................ 252
Group 7: GETTGT Message Flow ........................................................................ 255
EN.EN.R.7.1: Receipt of GETTGT Message .................................................... 256
EN.EN.R.7.2: GETTGT Message Flow ............................................................ 258
EN.EN.R.7.3: Receipt of a KINK command with a User-to-User ticket that
cannot be decrypted with its TGT .................................................................... 261
EN.EN.R.7.4: Sending KINK_U2UDENIED................................................... 263
Group 8: Retransmission...................................................................................... 265
EN.EN.R.8.1: Responding to retransmitted CREATE .................................... 266
EN.EN.R.8.2: Retransmission of REPLY with the ACKREQ bit set .............. 269
EN.EN.R.8.3: Stop the retransmission of REPLY with the ACKREQ bit set 273
EN.EN.R.8.4: Responding to retransmitted DELETE .................................... 277
EN.EN.R.8.5: Responding to retransmitted STATUS..................................... 280
EN.EN.R.8.6: Responding to retransmitted GETTGT .................................... 283
Group 9: Message Validation ............................................................................... 285
EN.EN.R.9.1: Sending INVALID-PAYLOAD-TYPE against the unrecognized
ISAKMP payload............................................................................................... 286
TAHI Project TECHNICAL DOCUMENT
12
KINK Test Specification
EN.EN.R.9.2: Checksum Verification .............................................................. 291
EN.EN.R.9.3: Sending KINK_INVMAJ........................................................... 293
EN.EN.R.9.4: Sending KINK_BADQMVERS ................................................. 296
EN.EN.R.9.5: Receipt of unnecessary data after the message ....................... 300
EN.EN.R.9.6: Receipt of CREATE with non-zero value in reserved field ...... 303
EN.EN.R.9.7: Receipt of ACK with non-zero value in reserved field ............. 306
EN.EN.R.9.8: Receipt of GETTGT with non-zero value in reserved field...... 310
EN.EN.R.9.9: Receipt of unencrypted CREATE.............................................. 313
EN.EN.R.9.10: Receipt of unencrypted DELETE............................................ 316
EN.EN.R.9.11: Sending KRB_AP_ERR_SKEW .............................................. 320
Section 1.2: EN to SGW Tunnel .................................................................................. 324
Subsection 1.2.1: Initiator........................................................................................ 327
Group 1: CREATE Message Flow ........................................................................ 334
EN.SGW.I.1.1: CREATE Message Flow (2-way handshake)........................... 335
Subsection 1.2.2: Responder .................................................................................... 338
Group 1: CREATE Message Flow ........................................................................ 349
EN.SGW.R.1.1: CREATE Message Flow.......................................................... 350
Chapter 2: SGW implementation ................................................................................... 353
Section 2.1: SGW to SGW Tunnel ............................................................................... 354
Subsection 2.1.1: Initiator........................................................................................ 357
Group 1: CREATE Message Flow ........................................................................ 369
SGW.SGW.I.1.1: Sending CREATE Message................................................... 370
SGW.SGW.I.1.2: CREATE Message Flow (2-way handshake) ........................ 372
SGW.SGW.I.1.3: The non-optimistic keying by receipt of Nr.......................... 375
SGW.SGW.I.1.4: Creating an optimistic inbound SA ...................................... 378
Group 2: Cryptographic Algorithm Negotiation.................................................. 381
SGW.SGW.I.2.1: Cryptographic Algorithm Negotiation.................................. 382
SGW.SGW.I.2.2: The shorter LIFE_SECONDS is selected from optimistic
proposal ............................................................................................................. 386
SGW.SGW.I.2.3: The optimistic proposal is selected from multiple transforms
........................................................................................................................... 389
SGW.SGW.I.2.4: The non-optimistic proposal is selected from multiple
transforms ......................................................................................................... 393
SGW.SGW.I.2.5: The optimistic proposal is selected from multiple proposals
........................................................................................................................... 397
SGW.SGW.I.2.6: The non-optimistic proposal is selected from multiple
TAHI Project TECHNICAL DOCUMENT
13
KINK Test Specification
proposals............................................................................................................ 401
Group 3: Perfect Forward Secrecy ....................................................................... 405
SGW.SGW.I.3.1: PFS......................................................................................... 406
Group 4: Rekeying ................................................................................................ 412
SGW.SGW.I.4.1: Initiating Rekeying ............................................................... 413
Group 5: DELETE Message Flow ........................................................................ 417
Group 6: Dead Peer Detection.............................................................................. 418
SGW.SGW.I.6.1: Initiating Liveness Check ..................................................... 419
Group 7: GETTGT Message Flow ........................................................................ 422
SGW.SGW.I.7.1: Sending GETTGT Message................................................... 423
SGW.SGW.I.7.2: GETTGT Message Flow ........................................................ 425
SGW.SGW.I.7.3: Receipt of KINK_TGT_REP against a KINK command with a
User-to-User ticket that cannot be decrypted with its TGT ........................... 428
Group 8: Retransmission...................................................................................... 431
SGW.SGW.I.8.1: Retransmission of CREATE.................................................. 432
SGW.SGW.I.8.2: Stop the retransmission of CREATE.................................... 435
SGW.SGW.I.8.3: Responding to retransmitted REPLY with the ACKREQ bit
set ...................................................................................................................... 438
SGW.SGW.I.8.4: Retransmission of STATUS .................................................. 441
SGW.SGW.I.8.5: Stop the retransmission of STATUS..................................... 444
SGW.SGW.I.8.6: Retransmission of GETTGT ................................................. 448
SGW.SGW.I.8.7: Stop the retransmission of GETTGT.................................... 450
SGW.SGW.I.8.8: Restart a new transaction by receipt of
KRB_AP_ERR_TKT_EXPIRED ....................................................................... 453
Group 9: Message Validation ............................................................................... 456
SGW.SGW.I.9.1: Responding to KINK_ERROR with the ACKREQ bit set ... 457
SGW.SGW.I.9.2: Receipt of REPLY with non-zero value in reserved field..... 460
SGW.SGW.I.9.3: Receipt of unencrypted REPLY ............................................ 463
SGW.SGW.I.9.4: Receipt of authenticated KRB_AP_ERR_SKEW ................. 466
SGW.SGW.I.9.5: Receipt of unauthenticated KRB_AP_ERR_SKEW............. 469
Subsection 2.1.2: Responder .................................................................................... 473
Group 1: CREATE Message Flow ........................................................................ 490
SGW.SGW.R.1.1: Receipt of CREATE Message ............................................... 491
SGW.SGW.R.1.2: CREATE Message Flow ....................................................... 494
Group 2: Cryptographic Algorithm Negotiation.................................................. 497
SGW.SGW.R.2.1: Cryptographic Algorithm Negotiation................................. 498
TAHI Project TECHNICAL DOCUMENT
14
KINK Test Specification
SGW.SGW.R.2.2: The shorter LIFE_SECONDS is proposed.......................... 502
SGW.SGW.R.2.3: Selecting the optimistic proposal from multiple transforms
........................................................................................................................... 507
SGW.SGW.R.2.4: Selecting the non-optimistic proposal from multiple
transforms ......................................................................................................... 511
SGW.SGW.R.2.5: Selecting the optimistic proposal from multiple proposals 515
SGW.SGW.R.2.6: Selecting the non-optimistic proposal from multiple proposals
........................................................................................................................... 519
SGW.SGW.R.2.7: Responding to multiple KINK_ISAKMP by optimistic keying
........................................................................................................................... 523
SGW.SGW.R.2.8: Responding to multiple KINK_ISAKMP by non-optimistic
keying ................................................................................................................ 534
SGW.SGW.R.2.9: Sending NO-PROPOSAL-CHOSEN.................................... 543
Group 3: Perfect Forward Secrecy ....................................................................... 548
SGW.SGW.R.3.1: PFS ....................................................................................... 549
SGW.SGW.R.3.2: Sending INVALID-PAYLOAD-TYPE against the receipt of KE
........................................................................................................................... 554
Group 4: Rekeying ................................................................................................ 559
SGW.SGW.R.4.1: Responding to Rekeying....................................................... 560
SGW.SGW.R.4.2: Receipt of transaction ID constructed by using a non
monotonic counter............................................................................................. 564
SGW.SGW.R.4.3: Responding to CREATE with INVALID-SPI ...................... 568
Group 5: DELETE Message Flow ........................................................................ 573
SGW.SGW.R.5.1: DELETE Message Flow ....................................................... 574
SGW.SGW.R.5.2: Responding to DELETE with INVALID-SPI ...................... 578
Group 6: Dead Peer Detection.............................................................................. 583
SGW.SGW.R.6.1: Responding to Liveness Check ............................................ 584
SGW.SGW.R.6.2: Closing SA when the principal's epoch has changed .......... 587
SGW.SGW.R.6.3: Not closing SA by unprotected routing information ........... 591
Group 7: GETTGT Message Flow ........................................................................ 595
SGW.SGW.R.7.1: Receipt of GETTGT Message............................................... 596
SGW.SGW.R.7.2: GETTGT Message Flow ....................................................... 598
SGW.SGW.R.7.3: Receipt of a KINK command with a User-to-User ticket that
cannot be decrypted with its TGT .................................................................... 602
SGW.SGW.R.7.4: Sending KINK_U2UDENIED ............................................. 604
Group 8: Retransmission...................................................................................... 606
TAHI Project TECHNICAL DOCUMENT
15
KINK Test Specification
SGW.SGW.R.8.1: Responding to retransmitted CREATE............................... 607
SGW.SGW.R.8.2: Retransmission of REPLY with the ACKREQ bit set......... 610
SGW.SGW.R.8.3: Stop the retransmission of REPLY with the ACKREQ bit set
........................................................................................................................... 614
SGW.SGW.R.8.4: Responding to retransmitted DELETE............................... 618
SGW.SGW.R.8.5: Responding to retransmitted STATUS ............................... 622
SGW.SGW.R.8.6: Responding to retransmitted GETTGT............................... 626
Group 9: Message Validation ............................................................................... 628
SGW.SGW.R.9.1: Sending INVALID-PAYLOAD-TYPE against the
unrecognized ISAKMP payload........................................................................ 629
SGW.SGW.R.9.2: Checksum Verification ......................................................... 634
SGW.SGW.R.9.3: Sending KINK_INVMAJ ..................................................... 636
SGW.SGW.R.9.4: Sending KINK_BADQMVERS ............................................ 639
SGW.SGW.R.9.5: Receipt of unnecessary data after the message .................. 643
SGW.SGW.R.9.6: Receipt of CREATE with non-zero value in reserved field. 646
SGW.SGW.R.9.7: Receipt of ACK with non-zero value in reserved field ........ 649
SGW.SGW.R.9.8: Receipt of GETTGT with non-zero value in reserved field 653
SGW.SGW.R.9.9: Receipt of unencrypted CREATE ........................................ 656
SGW.SGW.R.9.10: Receipt of unencrypted DELETE ...................................... 659
SGW.SGW.R.9.11: Sending KRB_AP_ERR_SKEW ......................................... 663
Section 2.2: SGW to EN Tunnel .................................................................................. 667
Subsection 2.2.1: Initiator........................................................................................ 670
Group 1: CREATE Message Flow ........................................................................ 678
SGW.EN.I.1.1: CREATE Message Flow (2-way handshake)........................... 679
Subsection 2.2.2: Responder .................................................................................... 682
Group 1: CREATE Message Flow ........................................................................ 694
SGW.EN.R.1.1: CREATE Message Flow.......................................................... 695
TAHI Project TECHNICAL DOCUMENT
16
KINK Test Specification
Requirements
NUT must satisfy all of the following requirements.
Equipment Type:
There are two possibilities for equipment types:
EN:
A node which can use KINK (IPsec transport mode and optionally
tunnel mode) only for itself.
Host and Router can be an EN.
SGW:
A node which can provide IKEv2 (IPsec tunnel mode) for nodes behind
it.
Router can be a SGW.
TAHI Project TECHNICAL DOCUMENT
17
KINK Test Specification
Function List:
This conformance test specification consists following BASIC/ADVANCED functions.
The tests for ADVANCED functions may be omitted if the NUT does not support the
ADVANCED function. All NUTs are required to support BASIC. ADVANCED is
required for all NUTs which support ADVANCED function.
Table 1 BASIC/ADVANCED Functionality table
Parameter
Kerberos
encryption
Kerberos checksum
Kerberos
authentication
IPsec protocol
IPsec
EN
mode
SGW
IPsec encryption
algorithm
-
BASIC
AES256-CTS-HMAC-SHA1-96
-
HMAC-SHA1-96-AES256
Non-User-to-User authentication
-
ESP
Transport mode
Tunnel mode
TripleDES-CBC
ADVANCED
-
-
-
IPsec
authentication
algorithm
IPsec SA life type
KINK role
KINK_ISAKMP
Payload
-
HMAC-SHA1-96
-
Seconds
Initiator
Responder
Initiating by single
KINK_ISAKMP
Responding to single
KINK_ISAKMP
Responding to multiple
KINK_ISAKMP
Receiving KINK_ENCRYPT
KINK_ENCRYPT
Payload
Proposal Payload
-
Nr payload
-
PFS
-
Transform Payload
Retransmission
-
Rekeying
-
Deleting existing
SA
DPD
Liveness Check
-
-
Sending single Proposal
Receiving single Proposal
Receiving multiple Proposal
Sending single Transform
Receiving single Transform
Receiving multiple Transform
Sending Nr payload when
non-optimistic proposal is selected
Receiving Nr payload
Rejecting KE payload
Retransmitting the command
Retransmitting the response with
the ACKREQ bit set
Initiating Rekeying
Responding to Rekeying
Responding to DELETE message
flow
closing SA when the principal's
epoch has changed
Sending STATUS for DAD
Responding to STATUS for DAD
TAHI Project TECHNICAL DOCUMENT
18
UNTESTED
-
User-to-User
authentication
Tunnel mode
NULL
AES-CBC with
128-bit keys
AES-CTR with
128-bit keys
NULL
AES-XCBC-MAC-96
-
AH
-
-
-
-
Kilobytes
-
-
-
Initiating by
multiple
KINK_ISAKMP
-
-
Sending
KINK_ENCRYPT
-
-
Transmitting
multiple Proposal
-
Transmitting
multiple Transform
-
-
-
-
-
Sending KE payload
Receiving KE payload
-
Sending Nr payload
when optimistic
proposal is selected
-
-
-
-
- Initiating to DELETE
message flow
-
-
-
KINK Test Specification
Chapter 1: EN implementation
TAHI Project TECHNICAL DOCUMENT
19
KINK Test Specification
Section 1.1: EN to EN Transport
Scope:
The following tests cover the endpoint-to-endpoint transport scenario.
In this
endpoint-to-endpoint transport scenario, both endpoints of the IP connection implement
IPsec and the transport mode will be used with no inner IP header.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation uses the transport mode IPsec to
communicate with the another endpoint.
Default Network Topology:
The logical network topology involves ENs, KDC and Router on each link.
region labelled as <TN> in Fig 1 is done inside TN node logically.
The shaded
The transport mode
is used in this network topology as shown as Fig 2.
Fig 1 EN to EN Common Network Topology for NUT (EN)
TAHI Project TECHNICAL DOCUMENT
20
KINK Test Specification
Fig 2 EN to EN Transport Scenario for NUT (EN)
Default NUT (EN) Configuration:
- IP configuration:
Address
Default router
NUT - Link A
(Prefix A::<any_interface_ID>)
TR1 - Link A
(fe80::f)
- Kerberos configuration:
KDC
Principal Name
Pre-shared Key
Encryption Type
Checksum Type
User-to-User authentication
KDC - Link X
(Prefix X::e)
"kink/[email protected]"
"KINKtest0123456789abcdefABCDEF!?"
AES256-CTS-HMAC-SHA1-96 (18)
HMAC-SHA1-96-AES256 (16)
disable
- KINK configuration:
Address
Port
Principal Name
PFS
IDi
IDr
ID Type
Protocol ID
Port
Identification
Data
Local
NUT - Link A
(Prefix A::<any_interface_ID>)
kink (910)
"kink/nut.example.com
@EXAMPLE.COM"
disable
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
Remote
TN1 - Link X
(Prefix X::1)
kink (910)
"kink/tn.example.com
@EXAMPLE.COM"
disable
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
- IPsec configuration:
IPsec Security Protocol
IPsec ESP Transform
SA Life Type (1)
SA Life Duration (2)
Encapsulation Mode (4)
Authentication Algorithm (5)
Inbound
Outbound
PROTO_IPSEC_ESP (3) PROTO_IPSEC_ESP (3)
ESP_3DES (3)
ESP_3DES (3)
Seconds (1)
Seconds (1)
28,800
28,800
Transport (2)
Transport (2)
HMAC-SHA (2)
HMAC-SHA (2)
If NUT is the initiator, above proposal must be one of proposals from NUT.
If NUT is the responder, NUT must select above proposal.
TAHI Project TECHNICAL DOCUMENT
21
KINK Test Specification
TAHI Project TECHNICAL DOCUMENT
22
KINK Test Specification
Subsection 1.1.1: Initiator
Scope:
In KINK exchanges, either of endpoints initiates the exchange by sending the command
and the another responds to this command with the response.
The following tests
cover KINK exchanges when the KINK implementation initiates these exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation initiates KINK exchanges.
Default Packets:
Packets sent from TN:
Common Packets to be transmitted from TN are defined as the following. Tests in
this test group may refer to these packets.
Common Transmitted Packet #1: REPLY for CREATE
IPv6
Next Header:
Source Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
TAHI Project TECHNICAL DOCUMENT
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
the same value as CREATE message
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the current POSIX time
23
KINK Test Specification
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
TAHI Project TECHNICAL DOCUMENT
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
IDi (5)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
0x10000000
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
NONE (0)
24
KINK Test Specification
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
* The shaded region in Common Transmitted Packet #1 is encrypted by
Kerberos encrypt function with Key Usage Number 39 (KINK_ENCRYPT
payload).
Common Transmitted Packet #2: REPLY with Nr for CREATE
IPv6
Next Header:
Source Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
TAHI Project TECHNICAL DOCUMENT
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
the same value as CREATE message
KINK_AP_REP (2)
true (1)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Nr (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
25
KINK Test Specification
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Nr Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
0x10000000
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
8 bytes length random data
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
* The shaded region in Common Transmitted Packet #2 is encrypted by
Kerberos encrypt function with Key Usage Number 39 (KINK_ENCRYPT
payload).
TAHI Project TECHNICAL DOCUMENT
26
KINK Test Specification
Common Transmitted Packet #3: IPsec ESP { ICMPv6 Echo Request }
IPv6
Next Header:
Source Address:
ESP (50)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
Destination Address:
ESP
SPI:
Sequence Number:
IV:
proposed by CREATE from NUT
1
8 bytes length stream
that all bits are set to zero
ICMPv6
Type:
Code:
Checksum:
Identifier:
Sequence Number:
Data:
Padding:
Pad Length:
Next Header:
ICV:
Echo Request (128)
0
ICMPv6 checksum
0
0
8 bytes length stream
that all bits are set to zero
ANY
the actual length of Pad in octets
IPv6-ICMP (58)
calculated by HMAC-SHA1-96
using calculated KEYMAT
* The shaded region in Common Transmitted Packet #3 is encrypted by
TripleDES in CBC mode using calculated KEYMAT.
Common Transmitted Packet #4: REPLY for STATUS
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
REPLY (3)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
the same value as STATUS message
NextPayload:
KINK_AP_REP (2)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_AP_REP Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
EPOCH:
the same value as REPLY message
in CREATE Message Flow
AP-REP:
raw data of Kerberos AP-REP
TAHI Project TECHNICAL DOCUMENT
27
KINK Test Specification
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Common Transmitted Packet #5: REPLY for GETTGT
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
REPLY (3)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
the same value as GETTGT message
NextPayload:
KINK_TGT_REP (5)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_TGT_REP Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
TGT:
DER-encoded TGT of the responder
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Common Transmitted Packet #6: ICMPv6 Destination Unreachable
IPv6
Next Header:
Source Address:
Destination Address:
ICMPv6
Type:
Code:
Checksum:
Unused:
Data:
IPv6-ICMP (58)
TR1 - Link X
(Prefix X::f)
NUT - Link A
(Prefix A::<any_interface_ID>)
Destination Unreachable (1)
Address unreachable (3)
ICMPv6 checksum
0
Common Observed Packet #4
Packets sent from NUT:
Common Packets to be transmitted from NUT are defined as the following. Tests
in this test group may refer to these packets.
Common Observed Packet #1: CREATE
TAHI Project TECHNICAL DOCUMENT
28
KINK Test Specification
IPv6
Next Header:
Source Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REQ Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REQ:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
TAHI Project TECHNICAL DOCUMENT
29
kink (910)
kink (910)
CREATE (1)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
ANY
KINK_AP_REQ (1)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REQ
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
KINK Test Specification
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
ANY
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
* The shaded region in Common Observed Packet #1 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
Common Observed Packet #2: unencrypted CREATE
IPv6
Next Header:
Source Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
TAHI Project TECHNICAL DOCUMENT
kink (910)
kink (910)
CREATE (1)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
ANY
KINK_AP_REQ (1)
false (0)
0
the actual length of Cksum
30
KINK Test Specification
KINK_AP_REQ Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REQ:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
KINK_ISAKMP (6)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REQ
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
ANY
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
IDr Payload
TAHI Project TECHNICAL DOCUMENT
31
KINK Test Specification
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
Common Observed Packet #3: ACK
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
ACK (5)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
the same value as CREATE message
NextPayload:
KINK_AP_REQ (1)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_AP_REQ Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
EPOCH:
the same value as CREATE message
AP-REQ:
raw data of Kerberos AP-REQ
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Common Observed Packet #4: IPsec ESP { ICMPv6 Echo Reply }
IPv6
Next Header:
Source Address:
Destination Address:
ESP
SPI:
Sequence Number:
IV:
ICMPv6
Type:
Code:
Checksum:
Identifier:
Sequence Number:
TAHI Project TECHNICAL DOCUMENT
ESP (50)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
0x10000000
ANY
ANY
Echo Reply (129)
0
ICMPv6 checksum
0
0
32
KINK Test Specification
Data:
Padding:
Pad Length:
Next Header:
ICV:
8 bytes length stream
that all bits are set to zero
ANY
the actual length of Pad in octets
IPv6-ICMP (58)
calculated by HMAC-SHA1-96
using calculated KEYMAT
* The shaded region in Common Observed Packet #4 is encrypted by TripleDES
in CBC mode using calculated KEYMAT.
Common Observed Packet #5: STATUS
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
STATUS (6)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
ANY
NextPayload:
KINK_AP_REQ (1)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_AP_REQ Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
EPOCH:
the same value as CREATE message
AP-REQ:
raw data of Kerberos AP-REQ
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Common Observed Packet #6: GETTGT
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
ACK (5)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
33
KINK Test Specification
XID:
ANY
NextPayload:
KINK_TGT_REQ (4)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_TGT_REQ Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
PrincName:
kink/[email protected]
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
TAHI Project TECHNICAL DOCUMENT
34
KINK Test Specification
Group 1: CREATE Message Flow
Scope:
In KINK exchanges, either of endpoints initiates the exchange by sending the command
and the another responds to this command with the response.
The following tests
cover the CREATE message flows when the KINK implementation initiates these
exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation initiates CREATE message flows.
TAHI Project TECHNICAL DOCUMENT
35
KINK Test Specification
EN.EN.I.1.1: Sending CREATE Message
Purpose:
Verify that an initiator transmits CREATE message in properly format
References:
- [KINK] - Section 3.2
- [KINK] - Section 6.3
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
NUT (EN)
initiator
Judgment #1
TN1 (EN)
responder
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
TAHI Project TECHNICAL DOCUMENT
36
KINK Test Specification
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
37
TLV (0)
SA Life Duration (2)
ANY
28,800
KINK Test Specification
EN.EN.I.1.2: CREATE Message Flow (2-way handshake)
Purpose:
Verify that an initiator properly establish SA by CREATE message flow
References:
- [KINK] - Section 3.2
- [KINK] - Section 6.3
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
38
KINK Test Specification
NUT (EN)
initiator
Judgment #1
TN1 (EN)
responder
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Packet #1
REPLY, AP_REP,
E{ISAKMP(SA(P(T)), IDi, IDr)}
Packet #2
IPsec(ESP){ICMPv6 Echo Request}
Judgment #2
IPsec(ESP){ICMPv6 Echo Reply}
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #1.
4. After responding to CREATE, TN1 transmits ICMPv6 Echo Request
encrypted by ESP described as Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #4.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
TAHI Project TECHNICAL DOCUMENT
39
KINK Test Specification
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
40
TLV (0)
SA Life Duration (2)
ANY
28,800
KINK Test Specification
EN.EN.I.1.3: The non-optimistic keying by receipt of Nr
Purpose:
Verify that an initiator properly processes 3-way handshake when the responder
wants to contribute the keying materials
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.4
- [KINK] - Section 6.2
- [KINK] - Section 6.3
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
41
KINK Test Specification
NUT (EN)
initiator
Judgment #1
Packet #1
Judgment #2
Packet #2
Judgment #3
TN1 (EN)
responder
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T)), Nr, IDi, IDr)}
ACK, AP_REQ
IPsec(ESP){ICMPv6 Echo Request}
IPsec(ESP){ICMPv6 Echo Reply}
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #2.
4. Observe the packets transmitted by the NUT on Link A.
5. After observing ACK, TN1 transmits ICMPv6 Echo Request encrypted by ESP
described as Common Transmitted Packet #3.
6. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 4: (Judgment #2)
The NUT must respond to REPLY with ACK described as Common Observed
Packet #3.
Step 6: (Judgment #3)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #4.
TAHI Project TECHNICAL DOCUMENT
42
KINK Test Specification
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
43
TLV (0)
SA Life Duration (2)
ANY
28,800
KINK Test Specification
Group 2: Cryptographic Algorithm Negotiation
Scope:
Creating SAs has two modes -- 2-way handshake and 3-way handshake.
The initiator
usually begins a negotiation expecting a 2-way handshake but the negotiation is
switched to a 3-way handshake when the optimistic proposal is not chosen by the
responder. The following tests cover 2-way handshake and 3-way handshake.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation can switch two modes while the
cryptographic algorithm negotiation.
TAHI Project TECHNICAL DOCUMENT
44
KINK Test Specification
EN.EN.I.2.1: Cryptographic Algorithm Negotiation
Purpose:
Verify that an initiator properly establish SA with the specific cryptographic
algorithms
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.1
- [KINK] - Section 5.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration, however use Cryptographic Algorithms as described below.
Part
A
B
C
D
E
IPsec encryption algorithm
ESP_NULL (11)
ESP_AES-CBC (12) with 128-bit keys
ESP_AES-CTR (13) with 128-bit keys
ESP_3DES (3)
ESP_3DES (3)
IPsec authentication algorithm
HMAC-SHA (2)
HMAC-SHA (2)
HMAC-SHA (2)
NONE (undefined)
AES-XCBC-MAC (9)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
TAHI Project TECHNICAL DOCUMENT
45
KINK Test Specification
Procedure:
NUT (EN)
initiator
TN1 (EN)
responder
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Judgment #1
Packet #1
REPLY, AP_REP,
E{ISAKMP(SA(P(T)), IDi, IDr)}
Packet #2
IPsec(ESP){ICMPv6 Echo Request}
Judgment #2
IPsec(ESP){ICMPv6 Echo Reply}
Part A through E (ADVANCED)
Part
A
B
C
D
E
IPsec encryption algorithm
NULL
AES-CBC with 128-bit keys
AES-CTR with 128-bit keys
TripleDES-CBC
TripleDES-CBC
IPsec authentication algorithm
HMAC-SHA1-96
HMAC-SHA1-96
HMAC-SHA1-96
NONE
AES-XCBC-MAC-96
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #1. However Transform-ID in Transform payload and Attribute Value
in Authentication Algorithm Data Attribute must be set according to the
corresponding entry of the table above.
Only for Part B and C, following
Data Attribute must be also additionally included in Transform payload.
And only for Part D, Authentication Algorithm Data Attribute does not appear
in Transform Payload.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
TV (1)
Key Length (6)
128
4. After responding to CREATE, TN1 transmits ICMPv6 Echo Request
encrypted by ESP described as Common Transmitted Packet #3.
However
encryption algorithm and authentication algorithm must be set according to
the corresponding entry of the table above.
TAHI Project TECHNICAL DOCUMENT
46
KINK Test Specification
5. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A through E:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. However Transform-ID in Transform
payload and Attribute Value in Authentication Algorithm Data Attribute must be
set according to the corresponding entry of the table in the procedure above.
In
addition, Data Attributes in Transform payload can be placed in any order
excepting that SA Life Duration Data Attribute is always follow SA Life Type
Data Attribute.
Only for Part B and C, following Data Attribute must be also
additionally included in Transform payload.
And only for Part D,
Authentication Algorithm Data Attribute must not appear in Transform Payload.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
TV (1)
Key Length (6)
128
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #4. However encryption algorithm
and authentication algorithm must be set according to the corresponding entry of
the table in the procedure above.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
47
TLV (0)
SA Life Duration (2)
ANY
28,800
KINK Test Specification
TAHI Project TECHNICAL DOCUMENT
48
KINK Test Specification
EN.EN.I.2.2: The shorter LIFE_SECONDS is selected from optimistic proposal
Purpose:
Verify that an initiator uses the shorter lifetime when the responder set lifetime to a
lower value
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.1
- [KINK] - Section 5.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
TN1 will respond with 30 seconds SA Life Duration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
49
KINK Test Specification
NUT (EN)
initiator
Judgment #1
TN1 (EN)
responder
CREATE, AP_REQ,
E{ISAKMP(SA(P(T(LIFE_SECONDSi))), Ni, IDi, IDr)}
Packet #1
REPLY, AP_REP,
E{ISAKMP(SA(P(T(LIFE_SECONDSr))), IDi, IDr)}
Packet #2
IPsec(ESP){ICMPv6 Echo Request}
Judgment #2
IPsec(ESP){ICMPv6 Echo Reply}
(LIFE_SECONDSr expires)
Packet #3
Judgment #3
IPsec(ESP){ICMPv6 Echo Request}
No response
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #1.
However Attribute Value in SA Life Duration Data Attribute
must be set to 30 seconds.
4. After responding to CREATE, TN1 transmits ICMPv6 Echo Request
encrypted by ESP described as Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
6. After 30 seconds, TN1 transmits ICMPv6 Echo Request encrypted by ESP
described as Common Transmitted Packet #3 with updating ICMPv6
Identifier to one.
7. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
TAHI Project TECHNICAL DOCUMENT
50
KINK Test Specification
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #4.
Step 7: (Judgment #3)
The NUT must not respond to ICMPv6 Echo Request with ICMPv6 Echo Reply
because SA has negotiated with 30 seconds lifetime and should expire.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
51
TLV (0)
SA Life Duration (2)
ANY
28,800
KINK Test Specification
EN.EN.I.2.3: The optimistic proposal is selected from multiple transforms
Purpose:
Verify that a node properly processes 2-way handshake when the responder selects
the optimistic proposal from proposed multiple transforms
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.1
- [KINK] - Section 5.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
In addition, configure NUT to propose with multiple
Transform payloads as described below.
Transform #
1
2
IPsec encryption algorithm
ESP_3DES (3)
ESP_AES-CBC (12)
Transform #1 will be selected by TN1.
IPsec authentication algorithm
HMAC-SHA (2)
AES-XCBC-MAC (9)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
TAHI Project TECHNICAL DOCUMENT
52
KINK Test Specification
Procedure:
NUT (EN)
initiator
Judgment #1
TN1 (EN)
responder
CREATE, AP_REQ,
E{ISAKMP(SA(P(T1, T2)), Ni, IDi, IDr)}
Packet #1
REPLY, AP_REP,
E{ISAKMP(SA(P(T1)), IDi, IDr)}
Packet #2
IPsec(ESP){ICMPv6 Echo Request}
Judgment #2
IPsec(ESP){ICMPv6 Echo Reply}
Part A: (ADVANCED)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #1.
4. After responding to CREATE, TN1 transmits ICMPv6 Echo Request
encrypted by ESP described as Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. However Proposal Payload must be set as
following.
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
TAHI Project TECHNICAL DOCUMENT
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
2
ANY
T (3)
0
the actual length of this payload in octets
53
KINK Test Specification
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
NONE (0)
0
the actual length of this payload in octets
2
ESP_AES-CBC (12)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
AES-XCBC-MAC (9)
TV (1)
Key Length (6)
128
In addition, Data Attributes in Transform payload can be placed in any order
excepting that SA Life Duration Data Attribute is always follow SA Life Type
Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #4.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
TAHI Project TECHNICAL DOCUMENT
54
KINK Test Specification
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- If NUT doesn't support cryptographic algorithms required in Transform #2, NUT can
use any other algorithms other than Transform #1.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
55
TLV (0)
SA Life Duration (2)
ANY
28,800
KINK Test Specification
EN.EN.I.2.4: The non-optimistic proposal is selected from multiple transforms
Purpose:
Verify that a node properly processes 3-way handshake when the responder selects
the non-optimistic proposal from proposed multiple transforms
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.1
- [KINK] - Section 5.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
In addition, configure NUT to propose with multiple
Transform payloads as described below.
Transform #
1
2
IPsec encryption algorithm
ESP_AES-CBC (12)
ESP_3DES (3)
Transform #2 will be selected by TN1.
IPsec authentication algorithm
AES-XCBC-MAC (9)
HMAC-SHA (2)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
TAHI Project TECHNICAL DOCUMENT
56
KINK Test Specification
Procedure:
NUT (EN)
initiator
Judgment #1
Packet #1
Judgment #2
Packet #2
Judgment #3
TN1 (EN)
responder
CREATE, AP_REQ,
E{ISAKMP(SA(P(T1, T2)), Ni, IDi, IDr)}
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T2)), Nr, IDi, IDr)}
ACK, AP_REQ
IPsec(ESP){ICMPv6 Echo Request}
IPsec(ESP){ICMPv6 Echo Reply}
Part A: (ADVANCED)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #2.
4. Observe the packets transmitted by the NUT on Link A.
5. After observing ACK, TN1 transmits ICMPv6 Echo Request encrypted by ESP
described as Common Transmitted Packet #3.
6. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. However Proposal Payload must be set as
following.
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
TAHI Project TECHNICAL DOCUMENT
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
2
ANY
57
KINK Test Specification
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
T (3)
0
the actual length of this payload in octets
1
ESP_AES-CBC (12)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
AES-XCBC-MAC (9)
TV (1)
Key Length (6)
128
NONE (0)
0
the actual length of this payload in octets
2
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
In addition, Data Attributes in Transform payload can be placed in any order
excepting that SA Life Duration Data Attribute is always follow SA Life Type
Data Attribute.
Step 4: (Judgment #2)
The NUT must respond to REPLY with ACK described as Common Observed
Packet #3.
Step 6: (Judgment #3)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #4.
TAHI Project TECHNICAL DOCUMENT
58
KINK Test Specification
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- If NUT doesn't support cryptographic algorithms required in Transform #1, NUT can
use any other algorithms other than Transform #2.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
59
TLV (0)
SA Life Duration (2)
ANY
28,800
KINK Test Specification
EN.EN.I.2.5: The optimistic proposal is selected from multiple proposals
Purpose:
Verify that a node properly processes 2-way handshake when the responder selects
the optimistic proposal from proposed multiple proposals
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.1
- [KINK] - Section 5.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
In addition, configure NUT to propose with multiple
Transform payloads as described below.
Proposal #
1
2
Protocol ID
PROTO_IPSEC_ESP (3)
PROTO_IPSEC_AH (2)
Proposal #1 will be selected by TN1.
IPsec encryption algorithm
ESP_3DES (3)
-
IPsec authentication algorithm
HMAC-SHA (2)
AH_SHA (3)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
TAHI Project TECHNICAL DOCUMENT
60
KINK Test Specification
Procedure:
NUT (EN)
initiator
Judgment #1
TN1 (EN)
responder
CREATE, AP_REQ,
E{ISAKMP(SA(P1(T), P2(T)), Ni, IDi, IDr)}
Packet #1
REPLY, AP_REP,
E{ISAKMP(SA(P1(T)), IDi, IDr)}
Packet #2
IPsec(ESP){ICMPv6 Echo Request}
Judgment #2
IPsec(ESP){ICMPv6 Echo Reply}
Part A: (ADVANCED)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #1.
4. After responding to CREATE, TN1 transmits ICMPv6 Echo Request
encrypted by ESP described as Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. However Security Association Payload must
be set as following.
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
TAHI Project TECHNICAL DOCUMENT
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
P (2)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
61
KINK Test Specification
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
NONE (0)
0
the actual length of this payload in octets
2
PROTO_IPSEC_AH (2)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
AH_SHA (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
In addition, Data Attributes in Transform payload can be placed in any order
excepting that SA Life Duration Data Attribute is always follow SA Life Type
Data Attribute.
Step 5: (Judgment #2)
TAHI Project TECHNICAL DOCUMENT
62
KINK Test Specification
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #4.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- If NUT doesn't support Protocol ID required in Proposal #2, NUT can use any other
Protocol IDs other than Proposal #1.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
63
TLV (0)
SA Life Duration (2)
ANY
28,800
KINK Test Specification
EN.EN.I.2.6: The non-optimistic proposal is selected from multiple proposals
Purpose:
Verify that a node properly processes 3-way handshake when the responder selects
the non-optimistic proposal from proposed multiple proposals
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.1
- [KINK] - Section 5.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
In addition, configure NUT to propose with multiple
Transform payloads as described below.
Proposal #
1
2
Protocol ID
PROTO_IPSEC_AH (2)
PROTO_IPSEC_ESP (3)
Proposal #2 will be selected by TN1.
IPsec encryption algorithm
ESP_3DES (3)
IPsec authentication algorithm
AH_SHA (3)
HMAC-SHA (2)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
TAHI Project TECHNICAL DOCUMENT
64
KINK Test Specification
Procedure:
NUT (EN)
initiator
Judgment #1
TN1 (EN)
responder
CREATE, AP_REQ,
E{ISAKMP(SA(P1(T), P2(T)), Ni, IDi, IDr)}
Packet #1
Judgment #2
Packet #2
Judgment #3
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P2(T)), Nr, IDi, IDr)}
ACK, AP_REQ
IPsec(ESP){ICMPv6 Echo Request}
IPsec(ESP){ICMPv6 Echo Reply}
Part A: (ADVANCED)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #2.
4. Observe the packets transmitted by the NUT on Link A.
5. After observing ACK, TN1 transmits ICMPv6 Echo Request encrypted by ESP
described as Common Transmitted Packet #3.
6. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. However Security Association Payload must
be set as following.
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
TAHI Project TECHNICAL DOCUMENT
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
P (2)
0
the actual length of this payload in octets
65
KINK Test Specification
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
1
PROTO_IPSEC_AH (2)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
AH_SHA (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
NONE (0)
0
the actual length of this payload in octets
2
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
In addition, Data Attributes in Transform payload can be placed in any order
excepting that SA Life Duration Data Attribute is always follow SA Life Type
Data Attribute.
TAHI Project TECHNICAL DOCUMENT
66
KINK Test Specification
Step 4: (Judgment #2)
The NUT must respond to REPLY with ACK described as Common Observed
Packet #3.
Step 6: (Judgment #3)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #4.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- If NUT doesn't support Protocol ID required in Proposal #1, NUT can use any other
Protocol IDs other than Proposal #2.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
67
TLV (0)
SA Life Duration (2)
ANY
28,800
KINK Test Specification
Group 3: Perfect Forward Secrecy
Scope:
The initiator usually begins a negotiation expecting a 2-way handshake, but 3-way
handshake is expected from the beginning when and only when the initiator uses a KE
payload.
The following tests cover 3-way handshake by adding KE payload.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation proposes to use the perfect forward
secrecy (PFS).
TAHI Project TECHNICAL DOCUMENT
68
KINK Test Specification
EN.EN.I.3.1: PFS
Purpose:
Verify that an initiator properly processes 3-way handshake when the initiator
requires to use PFS
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.7
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration with enabling PFS.
DH group is 1024 MODP Group (2).
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
69
KINK Test Specification
NUT (EN)
initiator
Judgment #1
Packet #1
Judgment #2
Packet #2
Judgment #3
TN1 (EN)
responder
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, KE, IDi, IDr)}
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T)), Nr, KE, IDi, IDr)}
ACK, AP_REQ
IPsec(ESP){ICMPv6 Echo Request}
IPsec(ESP){ICMPv6 Echo Reply}
Part A: (ADVANCED)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #2.
However KINK_ISAKMP Payload must be set as following.
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
TAHI Project TECHNICAL DOCUMENT
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Nr (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
0x10000000
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
70
KINK Test Specification
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Nr Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
KE Payload
Next Payload:
RESERVED:
Payload Length:
Key Exchange Data
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
SA Life Duration (2)
28,800
TV (1)
Group Description (3)
1024 MODP Group (2)
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
KE (4)
0
the actual length of this payload in octets
8 bytes length random data
IDi (5)
0
the actual length of this payload in octets
DH Group #2 public value
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
4. Observe the packets transmitted by the NUT on Link A.
5. After observing ACK, TN1 transmits ICMPv6 Echo Request encrypted by ESP
described as Common Transmitted Packet #3.
6. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. However KINK_ISAKMP Payload must be
set as following.
TAHI Project TECHNICAL DOCUMENT
71
KINK Test Specification
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
KE Payload
Next Payload:
RESERVED:
Payload Length:
Key Exchange Data
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
TAHI Project TECHNICAL DOCUMENT
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Group Description (3)
1024 MODP Group (2)
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
KE (4)
0
the actual length of this payload in octets
ANY
IDi (5)
0
the actual length of this payload in octets
DH Group #2 public value
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
72
KINK Test Specification
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
Data Attributes in Transform payload can be placed in any order excepting that
SA Life Duration Data Attribute is always follow SA Life Type Data Attribute.
Step 4: (Judgment #2)
The NUT must respond to REPLY with ACK described as Common Observed
Packet #3.
Step 6: (Judgment #3)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #4.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
73
TLV (0)
SA Life Duration (2)
ANY
28,800
KINK Test Specification
Group 4: Rekeying
Scope:
Unlike IKE, the initiator of KINK exchange has the responsibility for rekeying the SA.
The following tests cover CREATE message flow when the SA lifetime expires.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation rekeys SA.
TAHI Project TECHNICAL DOCUMENT
74
KINK Test Specification
EN.EN.I.4.1: Initiating Rekeying
Purpose:
Verify that a node properly processes rekeying
References:
- [KINK] - Section 3.6
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
TN1 will respond with 30 seconds SA Life Duration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
75
KINK Test Specification
NUT (EN)
initiator
Judgment #1
TN1 (EN)
responder
CREATE, AP_REQ,
E{ISAKMP(SA(P(SPIi1, T)), Ni, IDi, IDr)}
Packet #1
REPLY, AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), IDi, IDr)}
Packet #2
IPsec(ESP(SPIi1)){
ICMPv6 Echo Request}
IPsec(ESP(SPIr1)){
ICMPv6 Echo Reply}
Judgment #2
(repeat until initiator’s
soft lifetime expires)
Packet #2
Judgment #2
IPsec(ESP(SPIi1)){
ICMPv6 Echo Request}
IPsec(ESP(SPIr1)){
ICMPv6 Echo Reply}
(Rekeying)
Judgment #3
CREATE, AP_REQ,
E{ISAKMP(SA(P(SPIi2, T)), Ni, IDi, IDr)}
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #1.
However Attribute Value in SA Life Duration Data Attribute
must be set to 30 seconds.
4. After responding to CREATE, TN1 transmits ICMPv6 Echo Request
encrypted by ESP described as Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
6. Repeat Steps 4 and 5 for 30 seconds with the interval value of 1 second.
ICMPv6 Sequence Number should be incremented in each of transmitted
packets.
While transmitting ICMPv6 Echo Request, observe the packets
transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. SPI in Proposal Payload must be updated to
TAHI Project TECHNICAL DOCUMENT
76
KINK Test Specification
establish new SA.
Data Attributes in Transform payload can be placed in any
order excepting that SA Life Duration Data Attribute is always follow SA Life
Type Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #4.
ICMPv6 Sequence Number
must be the same value as the value in transmitted ICMPv6 Echo Request by
TN1.
Step 6: (Judgment #3)
The NUT must newly transmit properly formatted CREATE message described
as Common Observed Packet #1 or 2.
Data Attributes in Transform payload can
be placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
77
TLV (0)
SA Life Duration (2)
ANY
28,800
KINK Test Specification
Group 5: DELETE Message Flow
Scope:
The DELETE command deletes existing SAs.
The following tests cover the DELETE
message flows when the KINK implementation initiates these exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation initiates DELETE message flows.
There are no tests in this group because initiating DELETE message flow is defined as
untested item in this document.
TAHI Project TECHNICAL DOCUMENT
78
KINK Test Specification
Group 6: Dead Peer Detection
Scope:
The STATUS flow is used to send any information to a peer or to elicit any information
from a peer.
A STATUS command is also used as a means of dead peer detection. The
following tests cover the STATUS message flows when the KINK implementation
initiates these exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation initiates STATUS message flows.
TAHI Project TECHNICAL DOCUMENT
79
KINK Test Specification
EN.EN.I.6.1: Initiating Liveness Check
Purpose:
Verify that a node properly processes a dead peer detection
References:
- [KINK] - Section 3.4
- [KINK] - Section 3.7
- [KINK] - Section 6.5
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
80
KINK Test Specification
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #1.
4. After responding to CREATE, TN1 transmits ICMPv6 Echo Request
encrypted by ESP described as Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
6. TR1 responds to ICMPv6 Echo Reply with ICMPv6 Destination Unreachable
described as Common Transmitted Packet #6.
7. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #4.
TAHI Project TECHNICAL DOCUMENT
81
KINK Test Specification
Step 7: (Judgment #3)
The NUT must transmit properly formatted STATUS message described as
Common Observed Packet #5.
However XID should be updated from the value
in CREATE transmitted at Step 1.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
82
TLV (0)
SA Life Duration (2)
ANY
28,800
KINK Test Specification
Group 7: GETTGT Message Flow
Scope:
GETTGT flow is used to retrieve a TGT from the remote peer in User-to-User
authentication mode. The following tests cover the GETTGT message flows when the
KINK implementation initiates these exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation uses User-to-User authentication
mode.
TAHI Project TECHNICAL DOCUMENT
83
KINK Test Specification
EN.EN.I.7.1: Sending GETTGT Message
Purpose:
Verify that an initiator transmits GETTGT message in properly format
References:
- [KINK] - Section 3.1
- [KINK] - Section 6.6
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration with enabling User-to-User authentication.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
Both
TN1 and NUT must obtain TGT from their KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
84
KINK Test Specification
Part A: (ADVANCED)
1. NUT starts to negotiate with TN1 by using User-to-User authentication.
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted GETTGT message described as
Common Observed Packet #6.
Possible Problems:
- None
TAHI Project TECHNICAL DOCUMENT
85
KINK Test Specification
EN.EN.I.7.2: GETTGT Message Flow
Purpose:
Verify that a node properly retrieve a TGT from the remote peer in User-to-User
authentication mode
References:
- [KINK] - Section 3.1
- [KINK] - Section 6.6
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration with enabling User-to-User authentication.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
Both
TN1 and NUT must obtain TGT from their KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
86
KINK Test Specification
NUT (EN)
initiator
Judgment #1
TN1 (EN)
responder
GETTGT, TGT_REQ
Packet #1
TN2 (KDC)
REPLY, TGT_REP
(Kerberos specific procedure)
Kerberos (TGS-REQ)
(Kerberos specific procedure)
Kerberos (TGS-REP)
Judgment #2
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Packet #2
REPLY, AP_REP,
E{ISAKMP(SA(P(T)), IDi, IDr)}
Packet #3
IPsec(ESP){ICMPv6 Echo Request}
Judgment #3
IPsec(ESP){ICMPv6 Echo Reply}
Part A: (ADVANCED)
1. NUT starts to negotiate with TN1 by using User-to-User authentication.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to GETTGT with REPLY described as Common Transmitted
Packet #5.
4. Observe the packets transmitted by the NUT on Link A.
5. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #1.
6. After responding to CREATE, TN1 transmits ICMPv6 Echo Request
encrypted by ESP described as Common Transmitted Packet #3.
7. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted GETTGT message described as
Common Observed Packet #6.
Step 4: (Judgment #2)
After the NUT obtains a service ticket for TN1 from TN2, the NUT must transmit
properly formatted CREATE message described as Common Observed Packet #1
TAHI Project TECHNICAL DOCUMENT
87
KINK Test Specification
or 2.
Data Attributes in Transform payload can be placed in any order excepting
that SA Life Duration Data Attribute is always follow SA Life Type Data
Attribute.
Step 7: (Judgment #3)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #4.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
88
TLV (0)
SA Life Duration (2)
ANY
28,800
KINK Test Specification
EN.EN.I.7.3: Receipt of KINK_TGT_REP against a KINK command with a
User-to-User ticket that cannot be decrypted with its TGT
Purpose:
Verify that a node properly recovers dead user-to-user peer
References:
- [KINK] - Subsection 3.7.1
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration with enabling User-to-User authentication.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
Both
TN1 and NUT must obtain TGT from their KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
89
KINK Test Specification
NUT (EN)
initiator
Judgment #1
TN1 (EN)
responder
GETTGT, TGT_REQ
Packet #1
TN2 (KDC)
REPLY, TGT_REP(TGTr1)
(Kerberos specific procedure)
Kerberos (TGS-REQ)
(Kerberos specific procedure)
Kerberos (TGS-REP)
Judgment #2
CREATE, AP_REQ, E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Packet #1
REPLY, TGT_REP(TGTr2)
(Kerberos specific procedure)
Kerberos (TGS-REQ)
(Kerberos specific procedure)
Kerberos (TGS-REP)
Judgment #3
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Part A: (ADVANCED)
1. NUT starts to negotiate with TN1 by using User-to-User authentication.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to GETTGT with REPLY described as Common Transmitted
Packet #5.
4. Observe the packets transmitted by the NUT on Link A.
5. TN1 responds to CREATE with REPLY, but the packet format is the same as
REPLY for GETTGT described as Common Transmitted Packet #5.
However
TGT is newly obtained from TN2.
6. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted GETTGT message described as
Common Observed Packet #6.
TAHI Project TECHNICAL DOCUMENT
90
KINK Test Specification
Step 4: (Judgment #2)
After the NUT obtains a service ticket for TN1 from TN2, the NUT must transmit
properly formatted CREATE message described as Common Observed Packet #1
or 2.
Data Attributes in Transform payload can be placed in any order excepting
that SA Life Duration Data Attribute is always follow SA Life Type Data
Attribute.
Step 6: (Judgment #3)
After the NUT newly obtains a service ticket for TN1 from TN2 again, the NUT
must transmit properly formatted CREATE message described as Common
Observed Packet #1 or 2.
Data Attributes in Transform payload can be placed in
any order excepting that SA Life Duration Data Attribute is always follow SA Life
Type Data Attribute.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
91
TLV (0)
SA Life Duration (2)
ANY
28,800
KINK Test Specification
Group 8: Retransmission
Scope:
KINK implementation must retransmit the request using timer T when this message
expects a response.
The following tests cover the retransmission mechanism.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation retransmits KINK messages.
TAHI Project TECHNICAL DOCUMENT
92
KINK Test Specification
EN.EN.I.8.1: Retransmission of CREATE
Purpose:
Verify that a node properly retransmit CREATE message
References:
- [KINK] – Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
93
KINK Test Specification
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. After NUT transmits CREATE, observe the packets transmitted by the NUT
on Link A until the timer T expires.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 3: (Judgment #2)
The NUT must retransmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
TAHI Project TECHNICAL DOCUMENT
94
KINK Test Specification
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TLV (0)
SA Life Duration (2)
ANY
28,800
- A timer T may be implemented with implementation's local policy. The tester must
consider the timer T configurable parameter.
TAHI Project TECHNICAL DOCUMENT
95
KINK Test Specification
EN.EN.I.8.2: Stop the retransmission of CREATE
Purpose:
Verify that a node properly stops the retransmission of CREATE message
References:
- [KINK] – Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
96
KINK Test Specification
NUT (EN)
initiator
Judgment #1
TN1 (EN)
responder
CREATE(XIDi1), AP_REQ(AP-REQ1),
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
(T expires)
(Retransmission)
Judgment #2
Packet #1
CREATE(XIDi1), AP_REQ(AP-REQ2),
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
REPLY(XIDi), AP_REP,
E{ISAKMP(SA(P(T)), IDi, IDr)}
(T*2 expires)
Judgment #3
No response
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. After NUT transmits first CREATE, observe the packets transmitted by the
NUT on Link A until the timer T expires.
4. TN1 responds to second CREATE with REPLY described as Common
Transmitted Packet #1.
5. Observe the packets transmitted by the NUT on Link A until doubled T
expires.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 3: (Judgment #2)
The NUT must retransmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
TAHI Project TECHNICAL DOCUMENT
97
KINK Test Specification
follow SA Life Type Data Attribute.
Step 5: (Judgment #3)
The NUT never retransmit CREATE message because message exchange had
been completed at Step 5.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TLV (0)
SA Life Duration (2)
ANY
28,800
- A timer T may be implemented with implementation's local policy. The tester must
consider the timer T configurable parameter.
TAHI Project TECHNICAL DOCUMENT
98
KINK Test Specification
EN.EN.I.8.3: Responding to retransmitted REPLY with the ACKREQ bit set
Purpose:
Verify that a node properly retransmit REPLY message
References:
- [KINK] - Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
99
KINK Test Specification
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #2.
4. Observe the packets transmitted by the NUT on Link A.
5. After observing ACK, TN1 transmits REPLY described as Common
Transmitted Packet #2 again.
6. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 4: (Judgment #2)
The NUT must respond to REPLY with ACK described as Common Observed
Packet #3.
Step 6: (Judgment #3)
The NUT must respond to REPLY with ACK described as Common Observed
Packet #3 again.
TAHI Project TECHNICAL DOCUMENT
100
KINK Test Specification
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
101
KINK Test Specification
EN.EN.I.8.4: Retransmission of STATUS
Purpose:
Verify that a node properly retransmit STATUS message
References:
- [KINK] – Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
102
KINK Test Specification
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #1.
4. After responding to CREATE, TN1 transmits ICMPv6 Echo Request
encrypted by ESP described as Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
6. TR1 responds to ICMPv6 Echo Reply with ICMPv6 Destination Unreachable
described as Common Transmitted Packet #6.
7. Observe the packets transmitted by the NUT on Link A.
8. After NUT transmits STATUS, observe the packets transmitted by the NUT
on Link A until the timer T expires.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
TAHI Project TECHNICAL DOCUMENT
103
KINK Test Specification
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #4.
Step 7: (Judgment #3)
The NUT must transmit properly formatted STATUS message described as
Common Observed Packet #5.
Step 8: (Judgment #4)
The NUT must retransmit properly formatted STATUS message described as
Common Observed Packet #5.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TLV (0)
SA Life Duration (2)
ANY
28,800
- A timer T may be implemented with implementation's local policy. The tester must
consider the timer T configurable parameter.
TAHI Project TECHNICAL DOCUMENT
104
KINK Test Specification
EN.EN.I.8.5: Stop the retransmission of STATUS
Purpose:
Verify that a node properly stops the retransmission of STATUS message
References:
- [KINK] – Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
105
KINK Test Specification
TR1 (Router)
NUT (EN)
initiator
Judgment #1
TN1 (EN)
responder
CREATE(XIDi1), AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Packet #1
REPLY(XIDi1), AP_REP,
E{ISAKMP(SA(P(T)), IDi, IDr)}
Packet #2
IPsec(ESP){ICMPv6 Echo Request}
Judgment #2
Packet #3
Judgment #3
IPsec(ESP){ICMPv6 Echo Reply}
ICMPv6 Destination Unreachable
(Address unreachable)
STATUS(XIDi2), AP_REQ(AP-REQ1)
(T expires)
(Retransmission)
Judgment #4
Packet #4
STATUS(XIDi2), AP_REQ(AP-REQ2)
REPLY(XIDi2), AP_REP
(T*2 expires)
Judgment #5
No response
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #1.
4. After responding to CREATE, TN1 transmits ICMPv6 Echo Request
encrypted by ESP described as Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
6. TR1 responds to ICMPv6 Echo Reply with ICMPv6 Destination Unreachable
described as Common Transmitted Packet #6.
7. Observe the packets transmitted by the NUT on Link A.
8. After NUT transmits first STATUS, observe the packets transmitted by the
NUT on Link A until the timer T expires.
9. TN1 responds to second STATUS with REPLY described as Common
Transmitted Packet #4.
10. Observe the packets transmitted by the NUT on Link A until doubled T
expires.
TAHI Project TECHNICAL DOCUMENT
106
KINK Test Specification
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #4.
Step 7: (Judgment #3)
The NUT must transmit properly formatted STATUS message described as
Common Observed Packet #5.
Step 8: (Judgment #4)
The NUT must retransmit properly formatted STATUS message described as
Common Observed Packet #5.
Step 10: (Judgment #5)
The NUT never retransmit STATUS message because message exchange had
been completed at Step 9.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TLV (0)
SA Life Duration (2)
ANY
28,800
- A timer T may be implemented with implementation's local policy. The tester must
consider the timer T configurable parameter.
TAHI Project TECHNICAL DOCUMENT
107
KINK Test Specification
TAHI Project TECHNICAL DOCUMENT
108
KINK Test Specification
EN.EN.I.8.6: Retransmission of GETTGT
Purpose:
Verify that a node properly retransmit GETTGT message
References:
- [KINK] – Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration with enabling User-to-User authentication.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
Both
TN1 and NUT must obtain TGT from their KDC.
Procedure:
NUT (EN)
initiator
Judgment #1
TN1 (EN)
responder
GETTGT, TGT_REQ
(T expires)
(Retransmission)
Judgment #2
GETTGT, TGT_REQ
TAHI Project TECHNICAL DOCUMENT
109
KINK Test Specification
Part A: (ADVANCED)
1. NUT starts to negotiate with TN1 by using User-to-User authentication.
2. Observe the packets transmitted by the NUT on Link A.
3. After NUT transmits GETTGT, observe the packets transmitted by the NUT
on Link A until the timer T expires.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted GETTGT message described as
Common Observed Packet #6.
Step 3: (Judgment #2)
The NUT must retransmit properly formatted GETTGT message described as
Common Observed Packet #6.
Possible Problems:
- A timer T may be implemented with implementation's local policy. The tester must
consider the timer T configurable parameter.
TAHI Project TECHNICAL DOCUMENT
110
KINK Test Specification
EN.EN.I.8.7: Stop the retransmission of GETTGT
Purpose:
Verify that a node properly stops the retransmission of GETTGT message
References:
- [KINK] – Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration with enabling User-to-User authentication.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
Both
TN1 and NUT must obtain TGT from their KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
111
KINK Test Specification
NUT (EN)
initiator
Judgment #1
TN1 (EN)
responder
GETTGT, TGT_REQ
(T expires)
(Retransmission)
Judgment #2
Packet #1
GETTGT, TGT_REQ
REPLY, TGT_REP
(T*2 expires)
Judgment #3
No response
Part A: (ADVANCED)
1. NUT starts to negotiate with TN1 by using User-to-User authentication.
2. Observe the packets transmitted by the NUT on Link A.
3. After NUT transmits first GETTGT, observe the packets transmitted by the
NUT on Link A until the timer T expires.
4. TN1 responds to second GETTGT with REPLY described as Common
Transmitted Packet #5.
5. Observe the packets transmitted by the NUT on Link A until doubled T
expires.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted GETTGT message described as
Common Observed Packet #6.
Step 3: (Judgment #2)
The NUT must retransmit properly formatted GETTGT message described as
Common Observed Packet #6.
Step 5: (Judgment #3)
The NUT never retransmit GETTGT message because message exchange had
been completed at Step 4.
Possible Problems:
TAHI Project TECHNICAL DOCUMENT
112
KINK Test Specification
- A timer T may be implemented with implementation's local policy. The tester must
consider the timer T configurable parameter.
TAHI Project TECHNICAL DOCUMENT
113
KINK Test Specification
EN.EN.I.8.8: Restart a new transaction by receipt of
KRB_AP_ERR_TKT_EXPIRED
Purpose:
Verify that a node properly starts a new transaction with a new ticket when the node
receives the error indicating ticket expired
References:
- [KINK] – Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
114
KINK Test Specification
NUT (EN)
initiator
Judgment #1
TN1 (EN)
responder
CREATE(XIDi1), AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Packet #1
REPLY, KRB_ERROR(KRB_AP_ERR_TKT_EXPIRED)
TN2 (KDC)
(Kerberos specific procedure)
Kerberos (TGS-REQ)
(Kerberos specific procedure)
Kerberos (TGS-REP)
Judgment #2
CREATE(XIDi2), AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with KRB_ERROR described as following.
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
REPLY (3)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
the same value as GETTGT message
NextPayload:
KINK_KRB_ERROR (3)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_KRB_ERROR Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
KRB-ERROR:
raw Kerberos KRB-ERROR
indicating KRB_AP_ERR_TKT_EXPIRED
4. Observe the packets transmitted by the NUT on Link A.
TAHI Project TECHNICAL DOCUMENT
115
KINK Test Specification
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 4: (Judgment #2)
After the NUT obtains a service ticket for TN1 from TN2, The NUT must newly
transmit properly formatted CREATE message described as Common Observed
Packet #1 or 2.
Data Attributes in Transform payload can be placed in any order
excepting that SA Life Duration Data Attribute is always follow SA Life Type
Data Attribute.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
116
KINK Test Specification
Group 9: Message Validation
Scope:
The following tests cover the message validation.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation processes of suspicious messages.
TAHI Project TECHNICAL DOCUMENT
117
KINK Test Specification
EN.EN.I.9.1: Responding to KINK_ERROR with the ACKREQ bit set
Purpose:
Verify that a node properly responds to an error message that the ACKREQ bit is set
with ACK message
References:
- [KINK] - Section 3.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
118
KINK Test Specification
NUT (EN)
initiator
Judgment #1
TN1 (EN)
responder
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Packet #1
Judgment #2
REPLY(ACKREQ), ERROR(KINK_INTERR)
ACK, AP_REQ
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as following.
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
REPLY (3)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
the same value as CREATE message
NextPayload:
KINK_ERROR (8)
ACKREQ:
true (1)
RESERVED2:
0
CksumLen:
0
KINK_ ERROR Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
ErrorCode:
KINK_INTERR (5)
4. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
TAHI Project TECHNICAL DOCUMENT
KINK Test Specification
119
follow SA Life Type Data Attribute.
Step 4: (Judgment #2)
The NUT must respond to REPLY with ACK described as Common Observed
Packet #3.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
120
KINK Test Specification
EN.EN.I.9.2: Receipt of REPLY with non-zero value in reserved field
Purpose:
Verify that a node properly ignores reserved field in REPLY message
References:
- [KINK] – Chapter 4
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
121
KINK Test Specification
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #1. However Reserved Field in CREATE message must be set as
following.
KINK
RESRVED:
0xf
RESERVED2:
0x7f
KINK_AP_REP Payload
RESERVED:
0xff
KINK_ENCRYPT Payload
RESERVED:
0xff
RESERVED2:
0xffffff
KINK_ISAKMP Payload
RESERVED: 0xff
RESERVED: 0xffff
4. After responding to CREATE, TN1 transmits ICMPv6 Echo Request
encrypted by ESP described as Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
TAHI Project TECHNICAL DOCUMENT
122
KINK Test Specification
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #4.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
123
KINK Test Specification
EN.EN.I.9.3: Receipt of unencrypted REPLY
Purpose:
Verify that a node properly processes REPLY message which doesn't encrypted by
KINK_ENCRYPT payload
References:
- [KINK] - Section 6.3
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
124
KINK Test Specification
NUT (EN)
initiator
Judgment #1
TN1 (EN)
responder
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Packet #1
REPLY, AP_REP, ISAKMP(SA(P(T)), IDi, IDr)
Packet #2
IPsec(ESP){ICMPv6 Echo Request}
Judgment #2
IPsec(ESP){ICMPv6 Echo Reply}
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #1.
However KINK_ENCRYPT Payload must not appear as described
as following.
KINK
KINK_AP_REP Payload
KINK_ISAKMP Payload
SA Payload
P Payload
T Payload
Data Attribute
Data Attribute
Data Attribute
Data Attribute
IDi Payload
IDr Payload
4. After responding to CREATE, TN1 transmits ICMPv6 Echo Request
encrypted by ESP described as Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
TAHI Project TECHNICAL DOCUMENT
125
KINK Test Specification
follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #4.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
126
KINK Test Specification
EN.EN.I.9.4: Receipt of authenticated KRB_AP_ERR_SKEW
Purpose:
Verify that a node properly adjust clock by the receipt of protected
KRB_AP_ERR_SKEW
References:
- [KINK] - Section 3.5
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
127
KINK Test Specification
Part A: (BASIC)
1. Set the clock forward 6 minutes on TN1.
2. NUT starts to negotiate with TN1 by sending CREATE message.
3. Observe the packets transmitted by the NUT on Link A.
4. TN1 responds to CREATE with KRB_ERROR described as following.
The
shaded region in the figure is encrypted by Kerberos encrypt function with
Key Usage Number 39 (KINK_ENCRYPT payload).
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
REPLY (3)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
the same value as CREATE message
NextPayload:
KINK_AP_REP (2)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_AP_REP Payload
Next Payload:
KINK_ENCRYPT (7)
RESERVED:
0
Payload Length:
the actual length of this payload in octets
EPOCH:
the current POSIX time
AP-REP:
raw data of Kerberos AP-REP
KINK_ENCRYPT Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length:
the actual length of this payload in octets
TAHI Project TECHNICAL DOCUMENT
128
KINK Test Specification
InnerNextPload:
KINK_KRB_ERROR (3)
RESERVED2:
0
KINK_KRB_ERROR Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
KRB-ERROR:
raw Kerberos KRB-ERROR
indicating KRB_AP_ERR_SKEW
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
5. NUT starts to negotiate with TN1 by sending CREATE message again.
6. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 3: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 6: (Judgment #2)
The NUT adjusts system clock to the time noticed by KRB-ERROR message.
And the NUT must newly transmit properly formatted CREATE message
described as Common Observed Packet #1 or 2. EPOCH in KINK_AP_REQ
Payload must be computed with the newly updated system clock.
Data
Attributes in Transform payload can be placed in any order excepting that SA
Life Duration Data Attribute is always follow SA Life Type Data Attribute.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
129
KINK Test Specification
TAHI Project TECHNICAL DOCUMENT
130
KINK Test Specification
EN.EN.I.9.5: Receipt of unauthenticated KRB_AP_ERR_SKEW
Purpose:
Verify that a node properly does not adjust clock by the receipt of unprotected
KRB_AP_ERR_SKEW
References:
- [KINK] - Section 3.5
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
131
KINK Test Specification
NUT (EN)
initiator
TN1 (EN)
responder
(push TN’s clock forward 6 minutes)
Judgment #1
Packet #1
CREATE, AP_REQ(EPOCHi1),
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
REPLY, AP_REP,
E{KRB_ERROR(KRB_AP_ERR_SKEW)}
(Reinitiating)
Judgment #2
CREATE, AP_REQ(EPOCHi2),
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Part A: (BASIC)
1. Set the clock forward 6 minutes on TN1.
2. NUT starts to negotiate with TN1 by sending CREATE message.
3. Observe the packets transmitted by the NUT on Link A.
4. TN1 responds to CREATE with KRB_ERROR described as following.
The
shaded region in the figure is encrypted by Kerberos encrypt function with
Key Usage Number 39 (KINK_ENCRYPT payload).
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
REPLY (3)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
the same value as CREATE message
NextPayload:
KINK_AP_REP (2)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_AP_REP Payload
Next Payload:
KINK_ENCRYPT (7)
RESERVED:
0
Payload Length:
the actual length of this payload in octets
EPOCH:
the current POSIX time
AP-REP:
raw data of Kerberos AP-REP
KINK_ENCRYPT Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
TAHI Project TECHNICAL DOCUMENT
132
KINK Test Specification
Payload Length:
the actual length of this payload in octets
InnerNextPload:
KINK_KRB_ERROR (3)
RESERVED2:
0
KINK_KRB_ERROR Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
KRB-ERROR:
raw Kerberos KRB-ERROR
indicating KRB_AP_ERR_SKEW
5. NUT starts to negotiate with TN1 by sending CREATE message again.
6. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 3: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 6: (Judgment #2)
The NUT never adjusts system clock to the time noticed by KRB-ERROR
message.
And the NUT must newly transmit properly formatted CREATE
message described as Common Observed Packet #1 or 2, but EPOCH in
KINK_AP_REQ Payload is still computed without updating the system clock.
Data Attributes in Transform payload can be placed in any order excepting that
SA Life Duration Data Attribute is always follow SA Life Type Data Attribute.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
133
KINK Test Specification
TAHI Project TECHNICAL DOCUMENT
134
KINK Test Specification
Subsection 1.1.2: Responder
Scope:
In KINK exchanges, either of endpoints initiates the exchange by sending the command
and the another responds to this command with the response.
The following tests
cover KINK exchanges when the KINK implementation responds to these exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation initiates KINK exchanges.
Default Packets:
Packets sent from TN:
Common Packets to be transmitted from TN are defined as the following. Tests in
this test group may refer to these packets.
Common Transmitted Packet #1: CREATE
IPv6
Next Header:
Source Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REQ Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REQ:
TAHI Project TECHNICAL DOCUMENT
kink (910)
kink (910)
CREATE (1)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
0
KINK_AP_REQ (1)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REQ
135
KINK Test Specification
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
0x10000000
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
8 bytes length random data
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
IDr Payload
TAHI Project TECHNICAL DOCUMENT
136
KINK Test Specification
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
* The shaded region in Common Transmitted Packet #1 is encrypted by
Kerberos encrypt function with Key Usage Number 39 (KINK_ENCRYPT
payload).
Common Transmitted Packet #2: ACK
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
ACK (5)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
0
NextPayload:
KINK_AP_REQ (1)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_AP_REQ Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
EPOCH:
the same value as CREATE message
AP-REQ:
raw data of Kerberos AP-REQ
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Common Transmitted Packet #3: IPsec ESP { ICMPv6 Echo Request }
IPv6
Next Header:
Source Address:
Destination Address:
ESP
SPI:
Sequence Number:
TAHI Project TECHNICAL DOCUMENT
ESP (50)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
proposed by REPLY from NUT
1
137
KINK Test Specification
IV:
ICMPv6
Type:
Code:
Checksum:
Identifier:
Sequence Number:
Data:
Padding:
Pad Length:
Next Header:
ICV:
8 bytes length stream
that all bits are set to zero
Echo Request (128)
0
ICMPv6 checksum
0
0
8 bytes length stream
that all bits are set to zero
ANY
the actual length of Pad in octets
IPv6-ICMP (58)
calculated by HMAC-SHA1-96
using calculated KEYMAT
* The shaded region in Common Transmitted Packet #3 is encrypted by
TripleDES in CBC mode using calculated KEYMAT.
Common Transmitted Packet #4: DELETE
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REQ Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REQ:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
D Payload
TAHI Project TECHNICAL DOCUMENT
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
kink (910)
kink (910)
DELETE (2)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REQ (1)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as CREATE message
raw data of Kerberos AP-REQ
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
D (12)
1
0
0
138
KINK Test Specification
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-Id:
SPI Size:
# of SPIs
SPI #1
Cksum:
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
4
1
proposed by REPLY from NUT
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
* The shaded region in Common Transmitted Packet #4 is encrypted by
Kerberos encrypt function with Key Usage Number 39 (KINK_ENCRYPT
payload).
Common Transmitted Packet #5: STATUS
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
STATUS (6)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
1
NextPayload:
KINK_AP_REQ (1)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_AP_REQ Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
EPOCH:
the same value as CREATE message
AP-REQ:
raw data of Kerberos AP-REQ
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Common Transmitted Packet #6: GETTGT
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
TAHI Project TECHNICAL DOCUMENT
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
kink (910)
kink (910)
139
KINK Test Specification
Type:
ACK (5)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
0
NextPayload:
KINK_TGT_REQ (4)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_TGT_REQ Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
PrincName:
kink/[email protected]
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Common Transmitted Packet #7: ICMPv6 Destination Unreachable
IPv6
Next Header:
Source Address:
Destination Address:
ICMPv6
Type:
Code:
Checksum:
Unused:
Data:
IPv6-ICMP (58)
TR1 - Link X
(Prefix X::f)
NUT - Link A
(Prefix A::<any_interface_ID>)
Destination Unreachable (1)
Address unreachable (3)
ICMPv6 checksum
0
Common Observed Packet #4
Packets sent from NUT:
Common Packets to be transmitted from NUT are defined as the following. Tests
in this test group may refer to these packets.
Common Observed Packet #1: REPLY for CREATE
IPv6
Next Header:
Source Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
TAHI Project TECHNICAL DOCUMENT
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message
Internet IP Security DOI (1)
0
KINK_AP_REP (2)
140
KINK Test Specification
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
IDi Payload
Next Payload:
RESERVED:
TAHI Project TECHNICAL DOCUMENT
141
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
IDi (5)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDr (5)
0
KINK Test Specification
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
* The shaded region in Common Observed Packet #1 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
Common Observed Packet #2: unencrypted REPLY for CREATE
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REP:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message
Internet IP Security DOI (1)
0
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ISAKMP (6)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
IDi (5)
0
the actual length of this payload in octets
142
KINK Test Specification
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
Cksum:
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Common Observed Packet #3: REPLY with Nr for CREATE
IPv6
Next Header:
Source Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
UDP
TAHI Project TECHNICAL DOCUMENT
143
KINK Test Specification
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
144
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
0
KINK_AP_REP (2)
true (1)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Nr (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
KINK Test Specification
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Nr Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
ANY
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
* The shaded region in Common Observed Packet #3 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
Common Observed Packet #4: unencrypted REPLY with Nr for CREATE
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REP:
KINK_ISAKMP Payload
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message
Internet IP Security DOI (1)
0
KINK_AP_REP (2)
true (1)
0
the actual length of Cksum
KINK_ISAKMP (6)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REP
145
KINK Test Specification
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Nr Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
TAHI Project TECHNICAL DOCUMENT
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Nr (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
ANY
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
146
KINK Test Specification
Identification Data:
Cksum:
NUT - Link A
(Prefix A::<any_interface_ID>)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Common Observed Packet #5: IPsec ESP { ICMPv6 Echo Reply }
IPv6
Next Header:
Source Address:
Destination Address:
ESP
SPI:
Sequence Number:
IV:
ICMPv6
Type:
Code:
Checksum:
Identifier:
Sequence Number:
Data:
Padding:
Pad Length:
Next Header:
ICV:
ESP (50)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
0x10000000
ANY
ANY
Echo Reply (129)
0
ICMPv6 checksum
0
0
8 bytes length stream
that all bits are set to zero
ANY
the actual length of Pad in octets
IPv6-ICMP (58)
calculated by HMAC-SHA1-96
using calculated KEYMAT
* The shaded region in Common Observed Packet #5 is encrypted by TripleDES
in CBC mode using calculated KEYMAT.
Common Observed Packet #6: REPLY for DELETE
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
147
KINK Test Specification
Payload Length:
EPOCH:
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
D Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-Id:
SPI Size:
# of SPIs
SPI #1
Cksum:
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
D (12)
1
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
4
1
proposed by REPLY from NUT
in CREATE Message Flow
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
* The shaded region in Common Observed Packet #6 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
Common Observed Packet #7: unencrypted REPLY for DELETE
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
148
KINK Test Specification
AP-REP:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
D Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-Id:
SPI Size:
# of SPIs
SPI #1
Cksum:
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
D (12)
1
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
4
1
proposed by REPLY from NUT
in CREATE Message Flow
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Common Observed Packet #8: REPLY for STATUS
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
REPLY (3)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
0
NextPayload:
KINK_AP_REP (2)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_AP_REP Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
EPOCH:
the same value as REPLY message
in CREATE Message Flow
AP-REP:
raw data of Kerberos AP-REP
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Common Observed Packet #9: REPLY for GETTGT
IPv6
Next Header:
Source Address:
Destination Address:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
149
KINK Test Specification
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
REPLY (3)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
0
NextPayload:
KINK_TGT_REP (5)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_TGT_REP Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
TGT:
DER-encoded TGT of the responder
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
TAHI Project TECHNICAL DOCUMENT
150
KINK Test Specification
Group 1: CREATE Message Flow
Scope:
In KINK exchanges, either of endpoints initiates the exchange by sending the command
and the another responds to this command with the response.
The following tests
cover the CREATE message flows when the KINK implementation initiates these
exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation responds to CREATE message
flows.
TAHI Project TECHNICAL DOCUMENT
151
KINK Test Specification
EN.EN.R.1.1: Receipt of CREATE Message
Purpose:
Verify that an initiator processes CREATE message in properly format
References:
- [KINK] - Section 3.2
- [KINK] - Section 6.3
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
152
KINK Test Specification
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
TAHI Project TECHNICAL DOCUMENT
153
KINK Test Specification
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
154
KINK Test Specification
EN.EN.R.1.2: CREATE Message Flow
Purpose:
Verify that a responder properly establish SA by CREATE message flow
References:
- [KINK] - Section 3.2
- [KINK] - Section 6.3
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
155
KINK Test Specification
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
TAHI Project TECHNICAL DOCUMENT
156
KINK Test Specification
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
157
KINK Test Specification
Group 2: Cryptographic Algorithm Negotiation
Scope:
Creating SAs has two modes -- 2-way handshake and 3-way handshake.
The initiator
usually begins a negotiation expecting a 2-way handshake but the negotiation is
switched to a 3-way handshake when the optimistic proposal is not chosen by the
responder. The following tests cover 2-way handshake and 3-way handshake.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation can switch two modes while the
cryptographic algorithm negotiation.
TAHI Project TECHNICAL DOCUMENT
158
KINK Test Specification
EN.EN.R.2.1: Cryptographic Algorithm Negotiation
Purpose:
Verify that a responder properly establish SA with the specific cryptographic
algorithms
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.1
- [KINK] - Section 5.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration, however use Cryptographic Algorithms as described below.
Part
A
B
C
D
E
IPsec encryption algorithm
ESP_NULL (11)
ESP_AES-CBC (12) with 128-bit keys
ESP_AES-CTR (13) with 128-bit keys
ESP_3DES (3)
ESP_3DES (3)
IPsec authentication algorithm
HMAC-SHA (2)
HMAC-SHA (2)
HMAC-SHA (2)
NONE (undefined)
AES-XCBC-MAC (9)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
TAHI Project TECHNICAL DOCUMENT
159
KINK Test Specification
Procedure:
Part A through E (ADVANCED)
Part
A
B
C
D
E
IPsec encryption algorithm
NULL
AES-CBC with 128-bit keys
AES-CTR with 128-bit keys
TripleDES-CBC
TripleDES-CBC
IPsec authentication algorithm
HMAC-SHA1-96
HMAC-SHA1-96
HMAC-SHA1-96
NONE
AES-XCBC-MAC-96
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However Transform-ID in Transform payload and Attribute Value in
Authentication Algorithm Data Attribute must be set according to the
corresponding entry of the table above.
Only for Part B and C, following
Data Attribute must be also additionally included in Transform payload.
And only for Part D, Authentication Algorithm Data Attribute does not appear
TAHI Project TECHNICAL DOCUMENT
KINK Test Specification
160
in Transform Payload.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
TV (1)
Key Length (6)
128
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3. However encryption algorithm and
authentication algorithm must be set according to the corresponding entry of
the table above.
5. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A through E:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
However Transform-ID in Transform
payload and Attribute Value in Authentication Algorithm Data Attribute must be
set according to the corresponding entry of the table in the procedure above.
In
addition, Data Attributes in Transform payload can be placed in any order
excepting that SA Life Duration Data Attribute is always follow SA Life Type
Data Attribute.
Only for Part B and C, following Data Attribute must be also
additionally included in Transform payload.
And only for Part D,
Authentication Algorithm Data Attribute must not appear in Transform Payload.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
TV (1)
Key Length (6)
128
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5. However encryption algorithm
and authentication algorithm must be set according to the corresponding entry of
the table in the procedure above.
TAHI Project TECHNICAL DOCUMENT
161
KINK Test Specification
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
162
KINK Test Specification
EN.EN.R.2.2: The shorter LIFE_SECONDS is proposed
Purpose:
Verify that a responder properly processes CREATE message when the initiator
proposes lower lifetime than the responder's lifetime
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.1
- [KINK] - Section 5.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
TN1 will propose with 30 seconds SA Life Duration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
163
KINK Test Specification
NUT (EN)
responder
Packet #1
TN1 (EN)
initiator
CREATE, AP_REQ,
E{ISAKMP(SA(P(T(LIFE_SECONDSi))), Ni, IDi, IDr)}
(optimistic proposal, but Nr was added by the responder)
(2-way handshake)
NUT (EN)
responder
(3-way handshake)
TN1 (EN)
initiator
NUT (EN)
responder
Judgment #1
TN1 (EN)
initiator
Judgment #1
REPLY, AP_REP,
E{ISAKMP(SA(P(T(LIFE_SECONDSi))),
IDi, IDr)}
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T(LIFE_SECONDSi))),
Nr, IDi, IDr)}
(IPsec DOI-specific error)
NUT (EN)
responder
Judgment #1
TN1 (EN)
initiator
REPLY, AP_REP,
E{ISAKMP(N(NO-PROPOSAL-CHOSEN))}
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However Attribute Value in SA Life Duration Data Attribute must be set
to 30 seconds.
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3, 4 or the packets described below.
If the
packet transmitted by NUT is REPLY, Attribute Value in SA Life Duration Data
Attribute must be set to 30 seconds.
TAHI Project TECHNICAL DOCUMENT
In addition, Data Attributes in Transform
164
KINK Test Specification
payload can be placed in any order excepting that SA Life Duration Data
Attribute is always follow SA Life Type Data Attribute.
NO-PROPOSAL-CHOSEN
IPv6
Next Header:
Source Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
N Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-ID:
SPI Size:
Notify Message Type:
Notification Data:
Cksum:
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
N (11)
1
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
0
NO-PROPOSAL-CHOSEN (14)
ANY
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
* The shaded region in Common Observed Packet #6 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
TAHI Project TECHNICAL DOCUMENT
165
KINK Test Specification
unencrypted NO-PROPOSAL-CHOSEN
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REP:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
N Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-ID:
SPI Size:
Notify Message Type:
Notification Data:
Cksum:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
N (11)
1
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
0
NO-PROPOSAL-CHOSEN (14)
ANY
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
TAHI Project TECHNICAL DOCUMENT
166
KINK Test Specification
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
167
KINK Test Specification
EN.EN.R.2.3: Selecting the optimistic proposal from multiple transforms
Purpose:
Verify that a node properly chooses optimistic proposal from proposed multiple
transforms
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.1
- [KINK] - Section 5.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
below.
TN1 will propose multiple Transform payloads as described
Transform #1 will be selected by NUT.
Transform #
1
2
IPsec encryption algorithm
ESP_3DES (3)
ESP_AES-CBC (12)
IPsec authentication algorithm
HMAC-SHA (2)
AES-XCBC-MAC (9)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
TAHI Project TECHNICAL DOCUMENT
168
KINK Test Specification
Procedure:
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However Proposal Payload must be set as following.
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
TAHI Project TECHNICAL DOCUMENT
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
2
ANY
T (3)
0
the actual length of this payload in octets
1
ESP_3DES (3)
169
KINK Test Specification
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
NONE (0)
0
the actual length of this payload in octets
2
ESP_AES-CBC (12)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
AES-XCBC-MAC (9)
TV (1)
Key Length (6)
128
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
TAHI Project TECHNICAL DOCUMENT
170
KINK Test Specification
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
171
KINK Test Specification
EN.EN.R.2.4: Selecting the non-optimistic proposal from multiple transforms
Purpose:
Verify that a node properly chooses non-optimistic proposal from proposed multiple
transforms
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.1
- [KINK] - Section 5.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
below.
TN1 will propose multiple Transform payloads as described
Transform #2 will be selected by NUT.
Transform #
1
2
IPsec encryption algorithm
ESP_AES-CBC (12)
ESP_3DES (3)
IPsec authentication algorithm
AES-XCBC-MAC (9)
HMAC-SHA (2)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
TAHI Project TECHNICAL DOCUMENT
172
KINK Test Specification
Procedure:
NUT (EN)
responder
Packet #1
Judgment #1
TN1 (EN)
initiator
CREATE, AP_REQ,
E{ISAKMP(SA(P(T1, T2)), Ni, IDi, IDr)}
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T2)), Nr, IDi, IDr)}
Packet #2
ACK, AP_REQ
Packet #3
IPsec(ESP){ICMPv6 Echo Request}
Judgment #2
IPsec(ESP){ICMPv6 Echo Reply}
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However Proposal Payload must be set as following.
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
TAHI Project TECHNICAL DOCUMENT
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
2
ANY
T (3)
0
the actual length of this payload in octets
1
ESP_AES-CBC (12)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
AES-XCBC-MAC (9)
TV (1)
Key Length (6)
173
KINK Test Specification
Attribute Value:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
128
NONE (0)
0
the actual length of this payload in octets
2
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to REPLY with ACK described as Common Transmitted Packet
#2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #3 or 4. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
TAHI Project TECHNICAL DOCUMENT
174
KINK Test Specification
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
175
KINK Test Specification
EN.EN.R.2.5: Selecting the optimistic proposal from multiple proposals
Purpose:
Verify that a node properly chooses optimistic proposal from proposed multiple
proposals
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.1
- [KINK] - Section 5.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
below.
Proposal #
1
2
TN1 will propose multiple Proposal payloads as described
Proposal #1 will be selected by NUT.
Protocol ID
PROTO_IPSEC_ESP (3)
PROTO_IPSEC_AH (2)
IPsec encryption algorithm
ESP_3DES (3)
-
IPsec authentication algorithm
HMAC-SHA (2)
AH_SHA (3)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
TAHI Project TECHNICAL DOCUMENT
176
KINK Test Specification
Procedure:
NUT (EN)
responder
Packet #1
TN1 (EN)
initiator
CREATE, AP_REQ,
E{ISAKMP(SA(P1(T), P2(T)), Ni, IDi, IDr)}
(optimistic proposal, but Nr was added by the responder)
(2-way handshake)
NUT (EN)
responder
(3-way handshake)
TN1 (EN)
initiator
NUT (EN)
responder
Judgment #1
TN1 (EN)
initiator
Judgment #1
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P1(T)), Nr, IDi, IDr)}
REPLY, AP_REP,
E{ISAKMP(SA(P1(T)), IDi, IDr)}
Packet #2
ACK, AP_REQ
NUT (EN)
responder
Packet #3
TN1 (EN)
initiator
IPsec(ESP){ICMPv6 Echo Request}
Judgment #2
IPsec(ESP){ICMPv6 Echo Reply}
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However Security Association Payload must be set as following.
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
TAHI Project TECHNICAL DOCUMENT
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
P (2)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
177
KINK Test Specification
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
NONE (0)
0
the actual length of this payload in octets
2
PROTO_IPSEC_AH (2)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
AH_SHA (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
TAHI Project TECHNICAL DOCUMENT
178
KINK Test Specification
5. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
179
KINK Test Specification
EN.EN.R.2.6: Selecting the non-optimistic proposal from multiple proposals
Purpose:
Verify that a node properly chooses non-optimistic proposal from proposed multiple
proposals
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.1
- [KINK] - Section 5.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
below.
Proposal #
1
2
TN1 will propose multiple Proposal payloads as described
Proposal #2 will be selected by NUT.
Protocol ID
PROTO_IPSEC_AH (2)
PROTO_IPSEC_ESP (3)
IPsec encryption algorithm
ESP_3DES (3)
IPsec authentication algorithm
AH_SHA (3)
HMAC-SHA (2)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
TAHI Project TECHNICAL DOCUMENT
180
KINK Test Specification
Procedure:
NUT (EN)
responder
Packet #1
Judgment #1
TN1 (EN)
initiator
CREATE, AP_REQ,
E{ISAKMP(SA(P1(T), P2(T)), Ni, IDi, IDr)}
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P2(T)), Nr, IDi, IDr)}
Packet #2
ACK, AP_REQ
Packet #3
IPsec(ESP){ICMPv6 Echo Request}
Judgment #2
IPsec(ESP){ICMPv6 Echo Reply}
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However Security Association Payload must be set as following.
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
TAHI Project TECHNICAL DOCUMENT
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
P (2)
0
the actual length of this payload in octets
1
PROTO_IPSEC_AH (2)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
AH_SHA (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
181
KINK Test Specification
Attribute Format:
Attribute Type:
Attribute Value:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
NONE (0)
0
the actual length of this payload in octets
2
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to REPLY with ACK described as Common Transmitted Packet
#2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #3 or 4. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
TAHI Project TECHNICAL DOCUMENT
182
KINK Test Specification
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
183
KINK Test Specification
EN.EN.R.2.7: Responding to multiple KINK_ISAKMP by optimistic keying
Purpose:
Verify that a node properly chooses optimistic proposal from proposed multiple
KINK_ISAKMP payloads
References:
- [KINK] - Section 3.2
- [KINK] - Subsection 4.2.6
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
However, multiple SPD entries are needed to configure on
NUT for both inbound and outbound direction as described below.
SPD #
1
2
Remote IP Address
TN1 - Link X
(Prefix X::1)
TN1 - Link X
(Prefix X::1)
Local IP Address
NUT - Link A
(Prefix A::<any_interface_ID>)
NUT - Link A
(Prefix A::<any_interface_ID>)
Next Layer Protocol
IPv6-ICMP (58)
TCP (6)
For both SPD #1 and #2, IPsec configuration described in Default NUT (EN)
Configuration will be proposed by TN1.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
TAHI Project TECHNICAL DOCUMENT
184
Both
TN1 must obtain NUT's
KINK Test Specification
service ticket from its KDC.
Procedure:
NUT (EN)
responder
Packet #1
TN1 (EN)
initiator
CREATE, AP_REQ,
E{ISAKMP1(SA(P(T)), Ni, IDi, IDr),
ISAKMP2(SA(P(T)), Ni, IDi, IDr)}
(optimistic proposal, but Nr was added by the responder)
(2-way handshake)
NUT (EN)
responder
(3-way handshake)
TN1 (EN)
initiator
NUT (EN)
responder
TN1 (EN)
initiator
Judgment #1
Judgment #1
REPLY(ACKREQ), AP_REP,
E{ISAKMP1(SA(P(T)), Nr, IDi, IDr),
ISAKMP2(SA(P(T)), Nr, IDi, IDr)}
REPLY, AP_REP,
E{ISAKMP1(SA(P(T)), IDi, IDr),
ISAKMP2(SA(P(T)), IDi, IDr)}
Packet #2
ACK, AP_REQ
NUT (EN)
responder
Packet #3
Judgment #2
Packet #4
Judgment #3
TN1 (EN)
initiator
IPsec(ESP1){ICMPv6 Echo Request}
IPsec(ESP1){ICMPv6 Echo Reply}
IPsec(ESP2){TCP(SYN)}
IPsec(ESP2){TCP(SYN, ACK) or TCP(RST, ACK)}
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However KINK_ENCRYPT Payload must be set as following.
The
shaded region in this packet is encrypted by Kerberos encrypt function with
Key Usage Number 39 (KINK_ENCRYPT payload).
TAHI Project TECHNICAL DOCUMENT
185
KINK Test Specification
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
TAHI Project TECHNICAL DOCUMENT
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_ISAKMP (6)
0
the actual length of this payload in octets
SA (1)
1
0
0
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
0x10000000
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
8 bytes length random data
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
186
KINK Test Specification
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
TAHI Project TECHNICAL DOCUMENT
TN1 - Link X
(Prefix X::1)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
0x20000000
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
8 bytes length random data
IDr (5)
0
187
KINK Test Specification
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
the actual length of this payload in octets
ID_IPV6_ADDR (5)
TCP (6)
ANY (0)
TN1 - Link X
(Prefix X::1)
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
TCP (6)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
SPI must be set to the value proposed in
the first KINK_ISAKMP Payload of REPLY.
5. Observe the packets transmitted by the NUT on Link A.
6. TN1 transmits TCP packet by ESP described as described below. The shaded
region in this packet is encrypted by TripleDES in CBC mode using calculated
KEYMAT.
IPv6
Next Header:
Source Address:
Destination Address:
ESP
SPI:
Sequence Number:
IV:
TCP
Source Port:
Destination Port:
Sequence Number:
Acknowledgment Number:
Data Offset:
Reserved:
URG:
ACK:
PSH:
RST:
SYN:
FIN:
Window:
Checksum:
Urgent Pointer:
Padding:
TAHI Project TECHNICAL DOCUMENT
ESP (50)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
proposed by second KINK_ISAKMP Payload
in REPLY from NUT
1
8 bytes length stream
that all bits are set to zero
0x1000
0x1000
0
0
5
0
false (0)
false (0)
false (0)
false (0)
true (1)
false (0)
0xffff
TCP checksum
0
ANY
188
KINK Test Specification
Pad Length:
Next Header:
ICV:
the actual length of Pad in octets
TCP (6)
calculated by HMAC-SHA1-96
using calculated KEYMAT
7. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
However the NUT includes two
KINK_ISAKMP Payloads as following.
KINK_ISAKMP Payload for Common Observed Packet #1 and 2
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
TAHI Project TECHNICAL DOCUMENT
KINK_ISAKMP (6)
0
the actual length of this payload in octets
SA (1)
1
0
0
IDi (5)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
189
KINK Test Specification
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
IDi (5)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
190
KINK Test Specification
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
TCP (6)
ANY (0)
TN1 - Link X
(Prefix X::1)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
TCP (6)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
KINK_ISAKMP Payload for Common Observed Packet #3 and 4
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
KINK_ISAKMP (6)
0
the actual length of this payload in octets
SA (1)
1
0
0
Nr (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
191
KINK Test Specification
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Nr Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
TAHI Project TECHNICAL DOCUMENT
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
8 bytes length random data
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Nr (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
192
KINK Test Specification
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Nr Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
8 bytes length random data
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
TCP (6)
ANY (0)
TN1 - Link X
(Prefix X::1)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
TCP (6)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
Data Attributes in Transform payload can be placed in any order excepting that
SA Life Duration Data Attribute is always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5.
Step 7: (Judgment #3)
The NUT must transmit properly formatted TCP packet encrypted by ESP.
If
the NUT provides a service on port 0x1000, the NUT respond with the packet
described as following.
IPv6
Next Header:
Source Address:
ESP (50)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
ESP
SPI:
Sequence Number:
TAHI Project TECHNICAL DOCUMENT
0x20000000
1
193
KINK Test Specification
IV:
8 bytes length stream
that all bits are set to zero
TCP
Source Port:
Destination Port:
Sequence Number:
Acknowledgment Number:
Data Offset:
Reserved:
URG:
ACK:
PSH:
RST:
SYN:
FIN:
Window:
Checksum:
Urgent Pointer:
Padding:
Pad Length:
Next Header:
ICV:
0x1000
0x1000
ANY
1
5
0
false (0)
true (1)
false (0)
false (0)
true (1)
false (0)
ANY
TCP checksum
0
ANY
the actual length of Pad in octets
TCP (6)
calculated by HMAC-SHA1-96
using calculated KEYMAT
Otherwise, the NUT respond with the packet described as following.
IPv6
Next Header:
Source Address:
ESP (50)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
ESP
SPI:
Sequence Number:
IV:
TCP
Source Port:
Destination Port:
Sequence Number:
Acknowledgment Number:
Data Offset:
Reserved:
URG:
ACK:
PSH:
RST:
SYN:
FIN:
Window:
Checksum:
Urgent Pointer:
Padding:
Pad Length:
Next Header:
ICV:
0x20000000
ANY
ANY
0x1000
0x1000
ANY
1
5
0
false (0)
true (1)
false (0)
true (1)
false (0)
false (0)
ANY
TCP checksum
0
ANY
the actual length of Pad in octets
TCP (6)
calculated by HMAC-SHA1-96
using calculated KEYMAT
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
TAHI Project TECHNICAL DOCUMENT
194
KINK Test Specification
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TLV (0)
SA Life Duration (2)
ANY
28,800
- An implementation may add TCP options to SYN-ACK or RST-ACK packet.
- An implementation may want to contribute the keying materials by adding Nr
Payload to only one KINK_ISAKMP. Payload.
TAHI Project TECHNICAL DOCUMENT
195
KINK Test Specification
EN.EN.R.2.8: Responding to multiple KINK_ISAKMP by non-optimistic keying
Purpose:
Verify that a node properly chooses non-optimistic proposal from proposed multiple
KINK_ISAKMP payloads
References:
- [KINK] - Section 3.2
- [KINK] - Subsection 4.2.6
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
However, multiple SPD entries are needed to configure on
NUT for both inbound and outbound direction as described below.
SPD #
1
2
Remote IP Address
TN1 - Link X
(Prefix X::1)
TN1 - Link X
(Prefix X::1)
Local IP Address
NUT - Link A
(Prefix A::<any_interface_ID>)
NUT - Link A
(Prefix A::<any_interface_ID>)
Next Layer Protocol
IPv6-ICMP (58)
TCP (6)
For SPD #1, IPsec configuration described in Default NUT (EN) Configuration
will be proposed by TN1.
However, for SPD #2, multiple Transform payloads
described below are proposed by TN1. Transform #2 will be selected by NUT.
Transform #
1
IPsec encryption algorithm
ESP_AES-CBC (12)
TAHI Project TECHNICAL DOCUMENT
196
IPsec authentication algorithm
AES-XCBC-MAC (9)
KINK Test Specification
2
ESP_3DES (3)
HMAC-SHA (2)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
NUT (EN)
responder
TN1 (EN)
initiator
Packet #1
Judgment #1
CREATE, AP_REQ,
E{ISAKMP1(SA(P(T)), Ni, IDi, IDr),
ISAKMP2(SA(P(T1, T2)), Ni, IDi, IDr)}
REPLY(ACKREQ), AP_REP,
E{ISAKMP1(SA(P(T)), Nr, IDi, IDr),
ISAKMP2(SA(P(T2)), Nr, IDi, IDr)}
Packet #2
ACK, AP_REQ
Packet #3
IPsec(ESP1){ICMPv6 Echo Request}
Judgment #2
Packet #4
Judgment #3
IPsec(ESP1){ICMPv6 Echo Reply}
IPsec(ESP2){TCP(SYN)}
IPsec(ESP2){TCP(SYN, ACK) or TCP(RST, ACK)}
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However KINK_ENCRYPT Payload must be set as following.
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
TAHI Project TECHNICAL DOCUMENT
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_ISAKMP (6)
0
the actual length of this payload in octets
SA (1)
1
0
0
197
KINK Test Specification
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
TAHI Project TECHNICAL DOCUMENT
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
0x10000000
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
8 bytes length random data
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
198
KINK Test Specification
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
TAHI Project TECHNICAL DOCUMENT
0
0
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
2
0x20000000
T (3)
0
the actual length of this payload in octets
1
ESP_AES-CBC (12)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
AES-XCBC-MAC (9)
TV (1)
Key Length (6)
128
NONE (0)
0
the actual length of this payload in octets
2
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
199
KINK Test Specification
Attribute Format:
Attribute Type:
Attribute Value:
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDi (5)
0
the actual length of this payload in octets
8 bytes length random data
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
TCP (6)
ANY (0)
TN1 - Link X
(Prefix X::1)
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
TCP (6)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to REPLY with ACK described as Common Transmitted Packet
#2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
SPI must be set to the value proposed in
the first KINK_ISAKMP Payload of REPLY.
5. Observe the packets transmitted by the NUT on Link A.
6. TN1 transmits TCP packet by ESP described as described below. The shaded
region in this packet is encrypted by TripleDES in CBC mode using calculated
KEYMAT.
IPv6
Next Header:
Source Address:
Destination Address:
ESP
SPI:
Sequence Number:
IV:
TCP
Source Port:
Destination Port:
Sequence Number:
Acknowledgment Number:
Data Offset:
TAHI Project TECHNICAL DOCUMENT
ESP (50)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
proposed by second KINK_ISAKMP Payload
in REPLY from NUT
1
8 bytes length stream
that all bits are set to zero
0x1000
0x1000
0
0
5
200
KINK Test Specification
Reserved:
URG:
ACK:
PSH:
RST:
SYN:
FIN:
Window:
Checksum:
Urgent Pointer:
Padding:
Pad Length:
Next Header:
ICV:
0
false (0)
false (0)
false (0)
false (0)
true (1)
false (0)
0xffff
TCP checksum
0
ANY
the actual length of Pad in octets
TCP (6)
calculated by HMAC-SHA1-96
using calculated KEYMAT
7. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #3 or 4. However the NUT includes two
KINK_ISAKMP Payloads as following.
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
TAHI Project TECHNICAL DOCUMENT
KINK_ISAKMP (6)
0
the actual length of this payload in octets
SA (1)
1
0
0
IDi (5)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
201
KINK Test Specification
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Nr (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
202
KINK Test Specification
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Nr Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
8 bytes length random data
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
TCP (6)
ANY (0)
TN1 - Link X
(Prefix X::1)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
TCP (6)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
Data Attributes in Transform payload can be placed in any order excepting that
SA Life Duration Data Attribute is always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5.
Step 7: (Judgment #3)
The NUT must transmit properly formatted TCP packet encrypted by ESP.
If
the NUT provides a service on port 0x1000, the NUT respond with the packet
described as following.
IPv6
Next Header:
Source Address:
ESP (50)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
ESP
SPI:
Sequence Number:
IV:
TAHI Project TECHNICAL DOCUMENT
0x20000000
ANY
ANY
203
KINK Test Specification
TCP
Source Port:
Destination Port:
Sequence Number:
Acknowledgment Number:
Data Offset:
Reserved:
URG:
ACK:
PSH:
RST:
SYN:
FIN:
Window:
Checksum:
Urgent Pointer:
Padding:
Pad Length:
Next Header:
ICV:
0x1000
0x1000
0
1
5
0
false (0)
true (1)
false (0)
false (0)
true (1)
false (0)
ANY
TCP checksum
0
ANY
the actual length of Pad in octets
TCP (6)
calculated by HMAC-SHA1-96
using calculated KEYMAT
Otherwise, the NUT respond with the packet described as following.
IPv6
Next Header:
Source Address:
ESP (50)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
ESP
SPI:
Sequence Number:
IV:
TCP
Source Port:
Destination Port:
Sequence Number:
Acknowledgment Number:
Data Offset:
Reserved:
URG:
ACK:
PSH:
RST:
SYN:
FIN:
Window:
Checksum:
Urgent Pointer:
Padding:
Pad Length:
Next Header:
ICV:
0x20000000
ANY
ANY
0x1000
0x1000
0
1
5
0
false (0)
true (1)
false (0)
true (1)
false (0)
false (0)
ANY
TCP checksum
0
ANY
the actual length of Pad in octets
TCP (6)
calculated by HMAC-SHA1-96
using calculated KEYMAT
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
TAHI Project TECHNICAL DOCUMENT
204
The tester must allow
KINK Test Specification
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TLV (0)
SA Life Duration (2)
ANY
28,800
- An implementation may add TCP options to SYN-ACK or RST-ACK packet.
- An implementation may want to contribute the keying materials by adding Nr
Payload also to optimistic proposal represented as first KINK_ISAKMP Payload.
TAHI Project TECHNICAL DOCUMENT
205
KINK Test Specification
EN.EN.R.2.9: Sending NO-PROPOSAL-CHOSEN
Purpose:
Verify that a node properly rejects the proposal which is not accepted by the
responder
References:
- [KINK] - Section 5.5
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
TN1 will propose following Transform payload and NUT will
reject it by sending NO-PROPOSAL-CHOSEN.
IPsec encryption algorithm
ESP_AES-CBC (12)
IPsec authentication algorithm
AES-XCBC-MAC (9)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
206
KINK Test Specification
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However Transform Payload must be set as following.
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
T (3)
0
the actual length of this payload in octets
1
ESP_AES-CBC (12)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
AES-XCBC-MAC (9)
TV (1)
Key Length (6)
128
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must respond to CREATE with properly formatted IPsec DOI-specific
error described as following.
TAHI Project TECHNICAL DOCUMENT
207
KINK Test Specification
NO-PROPOSAL-CHOSEN
IPv6
Next Header:
Source Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
N Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-ID:
SPI Size:
Notify Message Type:
Notification Data:
Cksum:
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
N (11)
1
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
0
NO-PROPOSAL-CHOSEN (14)
ANY
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
* The shaded region in Common Observed Packet #6 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
unencrypted NO-PROPOSAL-CHOSEN
TAHI Project TECHNICAL DOCUMENT
208
KINK Test Specification
IPv6
Next Header:
Source Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
raw data of Kerberos AP-REP
AP-REP:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
N Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-ID:
SPI Size:
Notify Message Type:
Notification Data:
Cksum:
KINK_DONE (0)
0
the actual length of this payload in octets
N (11)
1
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
0
NO-PROPOSAL-CHOSEN (14)
ANY
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
209
KINK Test Specification
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
28,800
210
KINK Test Specification
Group 3: Perfect Forward Secrecy
Scope:
The initiator usually begins a negotiation expecting a 2-way handshake, but 3-way
handshake is expected from the beginning when and only when the initiator uses a KE
payload.
The following tests cover 3-way handshake by adding KE payload.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation chooses to use the perfect forward
secrecy (PFS).
TAHI Project TECHNICAL DOCUMENT
211
KINK Test Specification
EN.EN.R.3.1: PFS
Purpose:
Verify that a responder properly processes 3-way handshake when the initiator
requires to use PFS
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.7
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration with enabling PFS.
DH group is 1024 MODP Group (2).
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
212
KINK Test Specification
NUT (EN)
responder
Packet #1
Judgment #1
TN1 (EN)
initiator
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, KE, IDi, IDr)}
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T)), Nr, KE, IDi, IDr)}
Packet #2
ACK, AP_REQ
Packet #3
IPsec(ESP){ICMPv6 Echo Request}
Judgment #2
IPsec(ESP){ICMPv6 Echo Reply}
Part A: (ADVANCED)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However KINK_ISAKMP Payload must be set as following.
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
TAHI Project TECHNICAL DOCUMENT
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
0x10000000
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
213
KINK Test Specification
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
KE Payload
Next Payload:
RESERVED:
Payload Length:
Key Exchange Data
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
TV (1)
Group Description (3)
1024 MODP Group (2)
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
KE (4)
0
the actual length of this payload in octets
8 bytes length random data
IDi (5)
0
the actual length of this payload in octets
DH Group #2 public value
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to REPLY with ACK described as Common Transmitted Packet
#2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #3 or 4. However KINK_ISAKMP Payload must be
set as following.
TAHI Project TECHNICAL DOCUMENT
214
KINK Test Specification
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Nr Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
KE Payload
Next Payload:
RESERVED:
Payload Length:
Key Exchange Data
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
TAHI Project TECHNICAL DOCUMENT
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Nr (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Group Description (3)
1024 MODP Group (2)
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
KE (4)
0
the actual length of this payload in octets
ANY
IDi (5)
0
the actual length of this payload in octets
DH Group #2 public value
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
215
KINK Test Specification
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
Data Attributes in Transform payload can be placed in any order excepting that
SA Life Duration Data Attribute is always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
216
KINK Test Specification
EN.EN.R.3.2: Sending INVALID-PAYLOAD-TYPE against the receipt of KE
Purpose:
Verify that a responder properly rejects to use PFS when the responder doesn't
support PFS
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.7
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
217
KINK Test Specification
NUT (EN)
responder
Packet #1
Judgment #1
TN1 (EN)
initiator
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, KE, IDi, IDr)}
REPLY, AP_REP,
E{ISAKMP(N(INVALID-PAYLOAD-TYPE))}
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However KINK_ISAKMP Payload must be set as following.
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
TAHI Project TECHNICAL DOCUMENT
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
0x10000000
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Group Description (3)
1024 MODP Group (2)
TV (1)
Encapsulation Mode (4)
Transport (2)
218
KINK Test Specification
Attribute Format:
Attribute Type:
Attribute Value:
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
KE Payload
Next Payload:
RESERVED:
Payload Length:
Key Exchange Data
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
KE (4)
0
the actual length of this payload in octets
8 bytes length random data
IDi (5)
0
the actual length of this payload in octets
DH Group #2 public value
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must respond to CREATE with properly formatted IPsec DOI-specific
error described as following.
INVALID-PAYLOAD-TYPE
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
219
KINK Test Specification
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
N Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-ID:
SPI Size:
Notify Message Type:
Notification Data:
Cksum:
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
N (11)
1
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
0
INVALID-PAYLOAD-TYPE (1)
ANY
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
* The shaded region in Common Observed Packet #6 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
unencrypted INVALID-PAYLOAD-TYPE
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
220
KINK Test Specification
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
raw data of Kerberos AP-REP
AP-REP:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
N Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-ID:
SPI Size:
Notify Message Type:
Notification Data:
Cksum:
KINK_DONE (0)
0
the actual length of this payload in octets
N (11)
1
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
0
INVALID-PAYLOAD-TYPE (1)
ANY
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
221
KINK Test Specification
Group 4: Rekeying
Scope:
Unlike IKE, the initiator of KINK exchange has the responsibility for rekeying the SA.
The following tests cover CREATE message flow when the SA lifetime expires.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation responds to rekeying SA.
TAHI Project TECHNICAL DOCUMENT
222
KINK Test Specification
EN.EN.R.4.1: Responding to Rekeying
Purpose:
Verify that a node properly processes rekeying
References:
- [KINK] - Section 3.6
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
223
KINK Test Specification
(2-way handshake)
NUT (EN)
responder
(3-way handshake)
TN1 (EN)
initiator
NUT (EN)
responder
Packet #1
TN1 (EN)
initiator
Packet #1
CREATE(XID=0), AP_REQ,
E{ISAKMP(SA(P(SPIi1, T)), Ni, IDi, IDr)}
Judgment #1
Judgment #1
REPLY(XID=0, ACKREQ), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), Nr, IDi, IDr)}
REPLY(XID=0), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), IDi, IDr)}
Packet #2
ACK(XID=0), AP_REQ
NUT (EN)
responder
Packet #3
Judgment #2
TN1 (EN)
initiator
IPsec(ESP(SPIr1)){ICMPv6 Echo Request}
IPsec(ESP(SPIi1)){ICMPv6 Echo Reply}
(Rekeying)
(optimistic proposal, but Nr was added by the responder)
(2-way handshake)
NUT (EN)
responder
(3-way handshake)
TN1 (EN)
initiator
NUT (EN)
responder
Packet #4
TN1 (EN)
initiator
Packet #4
CREATE(XID=1), AP_REQ,
E{ISAKMP(SA(P(SPIi2, T)), Ni, IDi, IDr)}
Judgment #3
Judgment #3
REPLY(XID=1), AP_REP,
E{ISAKMP(SA(P(SPIr2, T)), IDi, IDr)}
REPLY(XID=1, ACKREQ), AP_REP,
E{ISAKMP(SA(P(SPIr2, T)), Nr, IDi, IDr)}
Packet #5
ACK(XID=1), AP_REQ
NUT (EN)
responder
Packet #6
Judgment #4
TN1 (EN)
initiator
IPsec(ESP(SPIr2)){ICMPv6 Echo Request}
IPsec(ESP(SPIi2)){ICMPv6 Echo Reply}
TAHI Project TECHNICAL DOCUMENT
224
KINK Test Specification
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
6. TN1 transmits CREATE message described as Common Transmitted Packet
#1 with updating SPI value to 0x20000000.
XID is updated to one.
7. Observe the packets transmitted by the NUT on Link A.
8. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
9. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
ICMPv6 Identifier is set to one.
10. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5.
Step 7: (Judgment #3)
The NUT must newly transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
XID must be 1. Data Attributes in
Transform payload can be placed in any order excepting that SA Life Duration
Data Attribute is always follow SA Life Type Data Attribute.
Step 10: (Judgment #4)
TAHI Project TECHNICAL DOCUMENT
225
KINK Test Specification
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5 with updating SPI value to
0x20000000.
ICMPv6 Identifier is set to one.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
226
KINK Test Specification
EN.EN.R.4.2: Receipt of transaction ID constructed by using a non monotonic
counter
Purpose:
Verify that a node properly processes the transaction ID
References:
- [KINK] – Chapter 4
- [KINK] – Chapter 6
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
227
KINK Test Specification
(2-way handshake)
NUT (EN)
responder
(3-way handshake)
TN1 (EN)
initiator
NUT (EN)
responder
Packet #1
TN1 (EN)
initiator
Packet #1
CREATE(XID=65535), AP_REQ,
E{ISAKMP(SA(P(SPIi1, T)), Ni, IDi, IDr)}
Judgment #1
Judgment #1
REPLY(XID=65535, ACKREQ), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), Nr, IDi, IDr)}
REPLY(XID=65535), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), IDi, IDr)}
Packet #2
ACK(XID=65535), AP_REQ
NUT (EN)
responder
Packet #3
Judgment #2
TN1 (EN)
initiator
IPsec(ESP(SPIr1)){ICMPv6 Echo Request}
IPsec(ESP(SPIi1)){ICMPv6 Echo Reply}
(Rekeying)
(optimistic proposal, but Nr was added by the responder)
(2-way handshake)
NUT (EN)
responder
(3-way handshake)
TN1 (EN)
initiator
NUT (EN)
responder
Packet #4
TN1 (EN)
initiator
Packet #4
CREATE(XID=255), AP_REQ,
E{ISAKMP(SA(P(SPIi2, T)), Ni, IDi, IDr)}
Judgment #3
Judgment #3
REPLY(XID=255), AP_REP,
E{ISAKMP(SA(P(SPIr2, T)), IDi, IDr)}
REPLY(XID=255, ACKREQ), AP_REP,
E{ISAKMP(SA(P(SPIr2, T)), Nr, IDi, IDr)}
Packet #5
ACK(XID=255), AP_REQ
NUT (EN)
responder
Packet #6
Judgment #4
TN1 (EN)
initiator
IPsec(ESP(SPIr2)){ICMPv6 Echo Request}
IPsec(ESP(SPIi2)){ICMPv6 Echo Reply}
TAHI Project TECHNICAL DOCUMENT
228
KINK Test Specification
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However XID is set to 65535.
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
6. TN1 transmits CREATE message described as Common Transmitted Packet
#1 with updating SPI value to 0x20000000.
XID is updated to 255.
7. Observe the packets transmitted by the NUT on Link A.
8. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
9. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
ICMPv6 Identifier is set to one.
10. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
XID must be 65535.
Data Attributes in
Transform payload can be placed in any order excepting that SA Life Duration
Data Attribute is always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5.
Step 7: (Judgment #3)
The NUT must newly transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
XID must be 255.
Data Attributes in
Transform payload can be placed in any order excepting that SA Life Duration
Data Attribute is always follow SA Life Type Data Attribute.
Step 10: (Judgment #4)
TAHI Project TECHNICAL DOCUMENT
229
KINK Test Specification
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5 with updating SPI value to
0x20000000.
ICMPv6 Identifier is set to one.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
230
KINK Test Specification
EN.EN.R.4.3: Responding to CREATE with INVALID-SPI
Purpose:
Verify that a node properly rejects CREATE message containing an existing SPI
References:
- [KINK] - Section 3.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
231
KINK Test Specification
(2-way handshake)
NUT (EN)
responder
(3-way handshake)
TN1 (EN)
initiator
NUT (EN)
responder
Packet #1
TN1 (EN)
initiator
Packet #1
CREATE(XID=0), AP_REQ,
E{ISAKMP1(SA(P(SPIi1, T)), Ni, IDi, IDr)}
Judgment #1
Judgment #1
REPLY(XID=0), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), IDi, IDr)}
REPLY(XID=0, ACKREQ), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), Nr, IDi, IDr)}
Packet #2
ACK(XID=0), AP_REQ
NUT (EN)
responder
Packet #3
Judgment #2
TN1 (EN)
initiator
IPsec(ESP1(SPIr1)){ICMPv6 Echo Request}
IPsec(ESP1(SPIi1)){ICMPv6 Echo Reply}
(Rekeying)
Packet #4
Judgment #3
CREATE(XID=1), AP_REQ,
E{ISAKMP(SA(P(SPIi1, T)), Ni, IDi, IDr)}
REPLY(XID=1), AP_REP, E{ISAKMP(N(INVALID-SPI))}
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
6. TN1 transmits CREATE message described as Common Transmitted Packet
#1 again.
XID is updated to one.
7. Observe the packets transmitted by the NUT on Link A.
Observable Results:
TAHI Project TECHNICAL DOCUMENT
232
KINK Test Specification
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5.
Step 7: (Judgment #3)
The NUT must respond to CREATE with properly formatted IPsec DOI-specific
error described as following.
INVALID-SPI
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
N (11)
1
233
KINK Test Specification
QMMin:
RESERVED:
N Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-ID:
SPI Size:
Notify Message Type:
SPI
Notification Data:
Cksum:
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
4
INVALID-SPI (11)
0x10000000
ANY
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
* The shaded region in Common Observed Packet #6 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
unencrypted INVALID-SPI
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REP:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
N Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-ID:
SPI Size:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
N (11)
1
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
4
234
KINK Test Specification
Notify Message Type:
SPI
Notification Data:
Cksum:
INVALID-SPI (11)
0x10000000
ANY
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
235
KINK Test Specification
Group 5: DELETE Message Flow
Scope:
The DELETE command deletes existing SAs.
The following tests cover the DELETE
message flows when the KINK implementation responds to these exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation responds to DELETE message
flows.
TAHI Project TECHNICAL DOCUMENT
236
KINK Test Specification
EN.EN.R.5.1: DELETE Message Flow
Purpose:
Verify that a node properly deleates an existing SA
References:
- [KINK] - Section 3.3
- [KINK] - Section 6.4
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
237
KINK Test Specification
(2-way handshake)
NUT (EN)
responder
(3-way handshake)
TN1 (EN)
initiator
NUT (EN)
responder
TN1 (EN)
initiator
Packet #1
Packet #1
CREATE(XID=0), AP_REQ,
E{ISAKMP(SA(P(SPIi1, T)), Ni, IDi, IDr)}
Judgment #1
Judgment #1
REPLY(XID=0), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), IDi, IDr)}
REPLY(XID=0, ACKREQ), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), Nr, IDi, IDr)}
Packet #2
ACK(XID=0), AP_REQ
NUT (EN)
responder
Packet #3
Judgment #2
TN1 (EN)
initiator
IPsec(ESP1(SPIr1)){ICMPv6 Echo Request}
IPsec(ESP1(SPIi1)){ICMPv6 Echo Reply}
(Deleting)
Packet #4
DELETE(XID=1), AP_REQ, E{ISAKMP(D(SPIi1))}
Judgment #3
REPLY(XID=1), AP_REP, E{ISAKMP(D(SPIr1)))}
Packet #5
Judgment #4
IPsec(ESP(SPIr1)){ICMPv6 Echo Request}
No response
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
6. TN1 transmits DELETE message described as Common Transmitted Packet
#4.
7. Observe the packets transmitted by the NUT on Link A.
8. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
TAHI Project TECHNICAL DOCUMENT
238
KINK Test Specification
Common Transmitted Packet #3.
ICMPv6 Identifier is set to one.
9. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5.
Step 7: (Judgment #3)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #6 or 7.
Step 9: (Judgment #4)
The NUT must not respond to ICMPv6 Echo Request with ICMPv6 Echo Reply
because SA has already deleted at Step 7.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
239
KINK Test Specification
EN.EN.R.5.2: Responding to DELETE with INVALID-SPI
Purpose:
Verify that a node properly rejects DELETE message containing a non-existing SPI
References:
- [KINK] - Section 3.3
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
240
KINK Test Specification
(2-way handshake)
NUT (EN)
responder
(3-way handshake)
TN1 (EN)
initiator
NUT (EN)
responder
TN1 (EN)
initiator
Packet #1
Packet #1
CREATE(XID=0), AP_REQ,
E{ISAKMP(SA(P(SPIi1, T)), Ni, IDi, IDr)}
Judgment #1
Judgment #1
REPLY(XID=0), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), IDi, IDr)}
REPLY(XID=0, ACKREQ), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), Nr, IDi, IDr)}
Packet #2
ACK(XID=0), AP_REQ
NUT (EN)
responder
Packet #3
Judgment #2
TN1 (EN)
initiator
IPsec(ESP1(SPIr1)){ICMPv6 Echo Request}
IPsec(ESP1(SPIi1)){ICMPv6 Echo Reply}
(Deleting)
Packet #4
Judgment #3
DELETE(XID=1), AP_REQ, E{ISAKMP(D(SPIi2))}
REPLY(XID=1), AP_REP,
E{ISAKMP(N(INVALID-SPI))}
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
6. TN1 transmits DELETE message described as Common Transmitted Packet
#4.
However SPI is set to 0x20000000.
7. Observe the packets transmitted by the NUT on Link A.
Observable Results:
TAHI Project TECHNICAL DOCUMENT
241
KINK Test Specification
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5.
Step 7: (Judgment #3)
The NUT must respond to DELETE with properly formatted IPsec DOI-specific
error described as following.
INVALID-SPI
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
N (11)
1
242
KINK Test Specification
QMMin:
RESERVED:
N Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-ID:
SPI Size:
Notify Message Type:
SPI
Notification Data:
Cksum:
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
4
INVALID-SPI (11)
0x20000000
ANY
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
* The shaded region in Common Observed Packet #6 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
unencrypted INVALID-SPI
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REP:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
N Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-ID:
SPI Size:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
N (11)
1
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
4
243
KINK Test Specification
Notify Message Type:
SPI
Notification Data:
Cksum:
INVALID-SPI (11)
0x20000000
ANY
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
244
KINK Test Specification
Group 6: Dead Peer Detection
Scope:
The STATUS flow is used to send any information to a peer or to elicit any information
from a peer.
A STATUS command is also used as a means of dead peer detection. The
following tests cover the STATUS message flows when the KINK implementation
responds to these exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation responds to STATUS message
flows.
TAHI Project TECHNICAL DOCUMENT
245
KINK Test Specification
EN.EN.R.6.1: Responding to Liveness Check
Purpose:
Verify that a node properly processes a dead peer detection
References:
- [KINK] - Section 3.4
- [KINK] - Section 3.7
- [KINK] - Section 6.5
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
246
KINK Test Specification
(2-way handshake)
NUT (EN)
responder
(3-way handshake)
TN1 (EN)
initiator
NUT (EN)
responder
Packet #1
TN1 (EN)
initiator
Packet #1
CREATE(XID=0), AP_REQ(EPOCHi1),
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Judgment #1
Judgment #1
REPLY(XID=0), AP_REP(EPOCHr1),
E{ISAKMP(SA(P(T)), IDi, IDr)}
REPLY(XID=0, ACKREQ),
AP_REP(EPOCHr1),
E{ISAKMP(SA(P(T)), Nr, IDi, IDr)}
Packet #2
ACK(XID=0),
AP_REQ(EPOCHi1)
NUT (EN)
responder
Packet #3
Judgment #2
Packet #4
Judgment #3
TN1 (EN)
initiator
IPsec(ESP){ICMPv6 Echo Request}
IPsec(ESP){ICMPv6 Echo Reply}
STATUS(XID=1), AP_REQ
REPLY(XID=1), AP_REP
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
6. TN1 transmits STATUS message described as Common Transmitted Packet
#5.
7. Observe the packets transmitted by the NUT on Link A.
Observable Results:
TAHI Project TECHNICAL DOCUMENT
247
KINK Test Specification
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5.
Step 7: (Judgment #3)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #8.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
248
KINK Test Specification
EN.EN.R.6.2: Closing SA when the principal's epoch has changed
Purpose:
Verify that a node properly closes SA when the principal's epoch has changed
References:
- [KINK] - Section 3.7
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
249
KINK Test Specification
(2-way handshake)
NUT (EN)
responder
(3-way handshake)
TN1 (EN)
initiator
NUT (EN)
responder
Packet #1
TN1 (EN)
initiator
Packet #1
CREATE(XID=0), AP_REQ(EPOCHi1),
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Judgment #1
Judgment #1
REPLY(XID=0), AP_REP(EPOCHr1),
E{ISAKMP(SA(P(T)), IDi, IDr)}
REPLY(XID=0, ACKREQ),
AP_REP(EPOCHr1),
E{ISAKMP(SA(P(T)), Nr, IDi, IDr)}
Packet #2
ACK(XID=0),
AP_REQ(EPOCHi1)
NUT (EN)
responder
Packet #3
Judgment #2
Packet #4
TN1 (EN)
initiator
IPsec(ESP){ICMPv6 Echo Request}
IPsec(ESP){ICMPv6 Echo Reply}
STATUS(XID=1), AP_REQ(EPOCHi2)
Judgment #3
REPLY(XID=1), AP_REP(EPOCHr1)
Packet #5
IPsec(ESP){ICMPv6 Echo Request}
Judgment #4
No response
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
6. TN1 transmits STATUS message described as Common Transmitted Packet
#5.
However, EPOCH is newly generated with the current time.
7. Observe the packets transmitted by the NUT on Link A.
8. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
TAHI Project TECHNICAL DOCUMENT
250
KINK Test Specification
Common Transmitted Packet #3.
ICMPv6 Identifier is set to one.
9. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5.
Step 7: (Judgment #3)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #8.
Step 9: (Judgment #4)
The NUT must not respond to ICMPv6 Echo Request with ICMPv6 Echo Reply
because SA has already been considered as invalid at Step 6.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
251
KINK Test Specification
EN.EN.R.6.3: Not closing SA by unprotected routing information
Purpose:
Verify that a node properly keeps SA by the receipt of an unprotected routing
information
References:
- [KINK] - Section 3.7
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
252
KINK Test Specification
(2-way handshake)
NUT (EN)
responder
(3-way handshake)
TN1 (EN)
initiator
NUT (EN)
responder
TN1 (EN)
initiator
Packet #1
Packet #1
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Judgment #1
Judgment #1
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T)), Nr, IDi, IDr)}
REPLY, AP_REP,
E{ISAKMP(SA(P(T)), IDi, IDr)}
Packet #2
ACK, AP_REQ
TR1 (Router)
NUT (EN)
responder
Packet #3
TN1 (EN)
initiator
IPsec(ESP){ICMPv6 Echo Request}
Judgment #2
IPsec(ESP){ICMPv6 Echo Reply}
ICMPv6 Destination Unreachable
(Address unreachable)
Packet #4
Packet #5
IPsec(ESP){ICMPv6 Echo Request}
Judgment #3
IPsec(ESP){ICMPv6 Echo Reply}
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
6. TR1 responds to ICMPv6 Echo Reply with ICMPv6 Destination Unreachable
described as Common Transmitted Packet #7.
7. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
ICMPv6 Identifier is set to one.
8. Observe the packets transmitted by the NUT on Link A.
TAHI Project TECHNICAL DOCUMENT
253
KINK Test Specification
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5.
Step 8: (Judgment #3)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5.
However, ICMPv6 Identifier
must be set to one.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
254
KINK Test Specification
Group 7: GETTGT Message Flow
Scope:
GETTGT flow is used to retrieve a TGT from the remote peer in User-to-User
authentication mode. The following tests cover the GETTGT message flows when the
KINK implementation responds to these exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation chooses to use User-to-User
authentication mode.
TAHI Project TECHNICAL DOCUMENT
255
KINK Test Specification
EN.EN.R.7.1: Receipt of GETTGT Message
Purpose:
Verify that an responder responds to GETTGT message
References:
- [KINK] - Section 3.1
- [KINK] - Section 6.6
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration with enabling User-to-User authentication.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
Both
TN1 and NUT must obtain TGT from their KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
256
KINK Test Specification
Part A: (ADVANCED)
1. TN1 transmits GETTGT message described as Common Transmitted Packet
#6.
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must respond to GETTGT with properly formatted REPLY message
described as Common Observable Packet #9.
Possible Problems:
- None
TAHI Project TECHNICAL DOCUMENT
257
KINK Test Specification
EN.EN.R.7.2: GETTGT Message Flow
Purpose:
Verify that a responder properly establish SA in User-to-User authentication mode
References:
- [KINK] - Section 3.1
- [KINK] - Section 6.6
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration with enabling User-to-User authentication.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
Both
TN1 and NUT must obtain TGT from their KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
258
KINK Test Specification
NUT (EN)
responder
Packet #1
TN1 (EN)
initiator
GETTGT, TGT_REQ
Judgment #1
TN2 (KDC)
REPLY, TGT_REP
(tester internal procedure)
Kerberos (TGS-REQ)
(tester internal procedure)
Kerberos (TGS-REP)
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)),
Ni, IDi, IDr)}
Packet #2
(optimistic proposal, but Nr was added by the responder)
(2-way handshake)
NUT (EN)
responder
(3-way handshake)
TN1 (EN)
initiator
NUT (EN)
responder
Judgment #2
TN1 (EN)
initiator
Judgment #2
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T)), Nr, IDi, IDr)}
REPLY, AP_REP,
E{ISAKMP(SA(P(T)), IDi, IDr)}
Packet #3
ACK, AP_REQ
NUT (EN)
responder
Packet #4
TN1 (EN)
initiator
IPsec(ESP){ICMPv6 Echo Request}
Judgment #3
IPsec(ESP){ICMPv6 Echo Reply}
Part A: (ADVANCED)
1. TN1 transmits GETTGT message described as Common Transmitted Packet
#6.
2. Observe the packets transmitted by the NUT on Link A.
3. After the TN1 obtains a service ticket for NUT from TN2 internally, TN1
transmits CREATE message described as Common Transmitted Packet #1
with updating XID to one.
4. Observe the packets transmitted by the NUT on Link A.
TAHI Project TECHNICAL DOCUMENT
259
KINK Test Specification
5. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2
with updating XID to one.
6. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
7. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must respond to GETTGT with properly formatted REPLY message
described as Common Observable Packet #9.
Step 4: (Judgment #2)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4. However, XID must be set to one.
Data
Attributes in Transform payload can be placed in any order excepting that SA
Life Duration Data Attribute is always follow SA Life Type Data Attribute.
Step 7: (Judgment #3)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
260
KINK Test Specification
EN.EN.R.7.3: Receipt of a KINK command with a User-to-User ticket that cannot
be decrypted with its TGT
Purpose:
Verify that a node properly processes against dead user-to-user peer
References:
- [KINK] - Subsection 3.7.1
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration with enabling User-to-User authentication.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
Both
TN1 and NUT must obtain TGT from their KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
261
KINK Test Specification
NUT (EN)
responder
Packet #1
Judgment #1
TN1 (EN)
initiator
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
REPLY, TGT_REP(TGTr)
Part A: (ADVANCED)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1, even though NUT is configured to use User-to-User authentication.
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must respond to GETTGT with properly formatted REPLY message
described as Common Observable Packet #9.
Possible Problems:
- None
TAHI Project TECHNICAL DOCUMENT
262
KINK Test Specification
EN.EN.R.7.4: Sending KINK_U2UDENIED
Purpose:
Verify that a node properly rejects to use User-to-User authentication mode when the
responder is not allowed to return its TGT
References:
- [KINK] - Section 6.6
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
263
KINK Test Specification
Part A: (BASIC)
1. TN1 transmits GETTGT message described as Common Transmitted Packet
#6.
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must respond to GETTGT with REPLY message described as following
to indicate that the NUT is not allowed to return its TGT.
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
REPLY (3)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
the same value as GETTGT message
NextPayload:
KINK_ERROR (8)
ACKREQ:
true (1)
RESERVED2:
0
CksumLen:
0
KINK_ ERROR Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
ErrorCode:
KINK_U2UDENIED (7)
Possible Problems:
- None
TAHI Project TECHNICAL DOCUMENT
264
KINK Test Specification
Group 8: Retransmission
Scope:
KINK implementation must retransmit the request using timer T when this message
expects a response.
The following tests cover the retransmission mechanism.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation responds to retransmission of
KINK messages.
TAHI Project TECHNICAL DOCUMENT
265
KINK Test Specification
EN.EN.R.8.1: Responding to retransmitted CREATE
Purpose:
Verify that a node properly responds to retransmitted CREATE message
References:
- [KINK] – Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
266
KINK Test Specification
NUT (EN)
responder
Packet #1
Judgment #1
TN1 (EN)
initiator
CREATE(XID=0), AP_REQ(AP-REQ1),
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
REPLY(XID=0), AP_REP(AP-REP1),
E{ISAKMP(SA(P(T)), IDi, IDr)}
REPLY(XID=0, ACKREQ), AP_REP(AP-REP1),
E{ISAKMP(SA(P(T)), Nr, IDi, IDr)}
(Retransmission)
Packet #2
Judgment #2
CREATE(XID=0), AP_REQ(AP-REQ2),
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
REPLY(XID=0), AP_REP(AP-REP2),
E{ISAKMP(SA(P(T)), IDi, IDr)}
REPLY(XID=0, ACKREQ), AP_REP(AP-REP2),
E{ISAKMP(SA(P(T)), Nr, IDi, IDr)}
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 newly transmits CREATE message described as Common Transmitted
Packet #1.
4. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 4: (Judgment #2)
The NUT must newly transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
TAHI Project TECHNICAL DOCUMENT
267
KINK Test Specification
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
268
KINK Test Specification
EN.EN.R.8.2: Retransmission of REPLY with the ACKREQ bit set
Purpose:
Verify that a node properly retransmit REPLY message
References:
- [KINK] – Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
below.
TN1 will propose multiple Transform payloads as described
Transform #2 will be selected by NUT.
Transform #
1
2
IPsec encryption algorithm
ESP_AES-CBC (12)
ESP_3DES (3)
IPsec authentication algorithm
AES-XCBC-MAC (9)
HMAC-SHA (2)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
269
KINK Test Specification
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However Proposal Payload must be set as following.
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
T Payload
Next Payload:
RESERVED:
TAHI Project TECHNICAL DOCUMENT
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
2
ANY
T (3)
0
the actual length of this payload in octets
1
ESP_AES-CBC (12)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
AES-XCBC-MAC (9)
TV (1)
Key Length (6)
128
NONE (0)
0
270
KINK Test Specification
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
the actual length of this payload in octets
2
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
2. Observe the packets transmitted by the NUT on Link A.
3. After NUT transmits REPLY, observe the packets transmitted by the NUT on
Link A until the timer T expires.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #3 or 4. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 3: (Judgment #3)
The NUT must retransmit properly formatted REPLY message described as
Common Observed Packet #3 or 4. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
TAHI Project TECHNICAL DOCUMENT
271
KINK Test Specification
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TLV (0)
SA Life Duration (2)
ANY
28,800
- A timer T may be implemented with implementation's local policy. The tester must
consider the timer T configurable parameter.
TAHI Project TECHNICAL DOCUMENT
272
KINK Test Specification
EN.EN.R.8.3: Stop the retransmission of REPLY with the ACKREQ bit set
Purpose:
Verify that a node properly stops the retransmission of REPLY message
References:
- [KINK] – Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
below.
TN1 will propose multiple Transform payloads as described
Transform #2 will be selected by NUT.
Transform #
1
2
IPsec encryption algorithm
ESP_AES-CBC (12)
ESP_3DES (3)
IPsec authentication algorithm
AES-XCBC-MAC (9)
HMAC-SHA (2)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
273
KINK Test Specification
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However Proposal Payload must be set as following.
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
TAHI Project TECHNICAL DOCUMENT
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
2
ANY
T (3)
0
the actual length of this payload in octets
1
ESP_AES-CBC (12)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
AES-XCBC-MAC (9)
TV (1)
274
KINK Test Specification
Attribute Type:
Attribute Value:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Key Length (6)
128
NONE (0)
0
the actual length of this payload in octets
2
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
2. Observe the packets transmitted by the NUT on Link A.
3. After NUT transmits REPLY, observe the packets transmitted by the NUT on
Link A until the timer T expires.
4. TN1 responds to REPLY with ACK described as Common Transmitted Packet
#2.
5. Observe the packets transmitted by the NUT on Link A until doubled T
expires.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #3 or 4. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 3: (Judgment #3)
The NUT must retransmit properly formatted REPLY message described as
Common Observed Packet #3 or 4. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 5: (Judgment #3)
TAHI Project TECHNICAL DOCUMENT
275
KINK Test Specification
The NUT never retransmit REPLY message because message exchange had been
completed at Step 4.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TLV (0)
SA Life Duration (2)
ANY
28,800
- A timer T may be implemented with implementation's local policy. The tester must
consider the timer T configurable parameter.
TAHI Project TECHNICAL DOCUMENT
276
KINK Test Specification
EN.EN.R.8.4: Responding to retransmitted DELETE
Purpose:
Verify that a node properly responds to retransmitted DELETE message
References:
- [KINK] – Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
277
KINK Test Specification
(2-way handshake)
NUT (EN)
responder
(3-way handshake)
TN1 (EN)
initiator
NUT (EN)
responder
TN1 (EN)
initiator
Packet #1
Packet #1
CREATE(XID=0), AP_REQ,
E{ISAKMP(SA(P(SPIi1, T)), Ni, IDi, IDr)}
Judgment #1
Judgment #1
REPLY(XID=0), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), IDi, IDr)}
REPLY(XID=0, ACKREQ), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), Nr, IDi, IDr)}
Packet #2
ACK(XID=0), AP_REQ
NUT (EN)
responder
Packet #3
Judgment #2
TN1 (EN)
initiator
IPsec(ESP1(SPIr1)){ICMPv6 Echo Request}
IPsec(ESP1(SPIi1)){ICMPv6 Echo Reply}
(Deleting)
Packet #4
Judgment #3
DELETE(XID=1), AP_REQ(AP-REQ1),
E{ISAKMP(D(SPIi1))}
REPLY(XID=1), AP_REP, E{ISAKMP(D(SPIr1)))}
(Retransmission)
Packet #5
Judgment #6
DELETE(XID=1), AP_REQ(AP-REQ2),
E{ISAKMP(D(SPIi1))}
REPLY(XID=1), AP_REP, E{ISAKMP(D(SPIr1)))}
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
6. TN1 transmits DELETE message described as Common Transmitted Packet
#4.
7. Observe the packets transmitted by the NUT on Link A.
TAHI Project TECHNICAL DOCUMENT
278
KINK Test Specification
8. TN1 retransmits DELETE message described as Common Transmitted
Packet #4.
9. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5.
Step 7: (Judgment #3)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #6 or 7.
Step 9: (Judgment #4)
The NUT must newly transmit properly formatted REPLY message described as
Common Observed Packet #6 or 7.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
279
KINK Test Specification
EN.EN.R.8.5: Responding to retransmitted STATUS
Purpose:
Verify that a node properly responds to retransmitted STATUS message
References:
- [KINK] – Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
280
KINK Test Specification
(2-way handshake)
NUT (EN)
responder
(3-way handshake)
TN1 (EN)
initiator
NUT (EN)
responder
TN1 (EN)
initiator
Packet #1
Packet #1
CREATE(XID=0), AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Judgment #1
Judgment #1
REPLY(XID=0, ACKREQ), AP_REP,
E{ISAKMP(SA(P(T)), Nr, IDi, IDr)}
REPLY(XID=0), AP_REP,
E{ISAKMP(SA(P(T)), IDi, IDr)}
Packet #2
ACK(XID=0), AP_REQ
NUT (EN)
responder
Packet #3
Judgment #2
Packet #4
Judgment #3
TN1 (EN)
initiator
IPsec(ESP){ICMPv6 Echo Request}
IPsec(ESP){ICMPv6 Echo Reply}
STATUS(XID=1), AP_REQ(AP-REQ1)
REPLY(XID=1), AP_REP
(Retransmission)
Packet #5
Judgment #4
STATUS(XID=1), AP_REQ(AP-REQ2)
REPLY(XID=1), AP_REP
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
6. TN1 transmits STATUS message described as Common Transmitted Packet
#5.
7. Observe the packets transmitted by the NUT on Link A.
8. TN1 retransmits STATUS message described as Common Transmitted Packet
TAHI Project TECHNICAL DOCUMENT
281
KINK Test Specification
#5.
9. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5.
Step 7: (Judgment #3)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #8.
Step 9: (Judgment #4)
The NUT must newly transmit properly formatted REPLY message described as
Common Observed Packet #8.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
282
KINK Test Specification
EN.EN.R.8.6: Responding to retransmitted GETTGT
Purpose:
Verify that a node properly responds to retransmitted GETTGT message
References:
- [KINK] – Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration with enabling User-to-User authentication.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
Both
TN1 and NUT must obtain TGT from their KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
283
KINK Test Specification
Part A: (ADVANCED)
1. TN1 transmits GETTGT message described as Common Transmitted Packet
#6.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 retransmits GETTGT message described as Common Transmitted
Packet #6.
4. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must respond to GETTGT with properly formatted REPLY message
described as Common Observable Packet #9.
Step 4: (Judgment #1)
The NUT must respond to GETTGT with properly formatted REPLY message
described as Common Observable Packet #9 again.
Possible Problems:
- None
TAHI Project TECHNICAL DOCUMENT
284
KINK Test Specification
Group 9: Message Validation
Scope:
The following tests cover the message validation.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation processes of suspicious messages.
TAHI Project TECHNICAL DOCUMENT
285
KINK Test Specification
EN.EN.R.9.1: Sending INVALID-PAYLOAD-TYPE against the unrecognized
ISAKMP payload
Purpose:
Verify that a node properly rejects unrecognized ISAKMP payload
References:
- [KINK] - Section 5.5
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
286
KINK Test Specification
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However KINK_ISAKMP Payload must be set as following.
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
TAHI Project TECHNICAL DOCUMENT
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
0x10000000
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Group Description (3)
1024 MODP Group (2)
TV (1)
Encapsulation Mode (4)
287
KINK Test Specification
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
Unrecognized Payload
Next Payload:
RESERVED:
Payload Length:
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
8 bytes length random data
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
unrecognized (0xff)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
NONE (0)
0
4
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must respond to CREATE with properly formatted IPsec DOI-specific
error described as following.
INVALID-PAYLOAD-TYPE
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
288
KINK Test Specification
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
N Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-ID:
SPI Size:
Notify Message Type:
Notification Data:
Cksum:
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
N (11)
1
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
0
INVALID-PAYLOAD-TYPE (1)
ANY
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
* The shaded region in Common Observed Packet #6 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
unencrypted INVALID-PAYLOAD-TYPE
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
289
KINK Test Specification
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
raw data of Kerberos AP-REP
AP-REP:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
N Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-ID:
SPI Size:
Notify Message Type:
Notification Data:
Cksum:
KINK_DONE (0)
0
the actual length of this payload in octets
N (11)
1
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
0
INVALID-PAYLOAD-TYPE (1)
ANY
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
290
KINK Test Specification
EN.EN.R.9.2: Checksum Verification
Purpose:
Verify that a node properly rejects the message containing invalid checksum
References:
- [KINK] – Chapter 4
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
291
KINK Test Specification
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However, Cksum is overwritten by the data that all bits set to one.
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must not respond to CREATE message.
Possible Problems:
- None.
TAHI Project TECHNICAL DOCUMENT
292
KINK Test Specification
EN.EN.R.9.3: Sending KINK_INVMAJ
Purpose:
Verify that a node properly rejects a message containing unsupported KINK version
number in the header
References:
- [KINK] - Subsection 4.2.8
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
293
KINK Test Specification
NUT (EN)
responder
Packet #1
TN1 (EN)
initiator
CREATE(MjVer=0xf), AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Judgment #1
REPLY, ERROR(KINK_INVMAJ)
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However, MjVer is set to 0xf.
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must respond to CREATE with REPLY message described as following
to indicate KINK error.
KINK_INVMAJ
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
REPLY (3)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
1
NextPayload:
KINK_ERROR (8)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_ERROR Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
ErrorCode:
KINK_INVMAJ (3)
Possible Problems:
TAHI Project TECHNICAL DOCUMENT
294
KINK Test Specification
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
TAHI Project TECHNICAL DOCUMENT
295
KINK Test Specification
EN.EN.R.9.4: Sending KINK_BADQMVERS
Purpose:
Verify that a node properly rejects a message containing ISAKMP version which is
greater than the highest currently supported version
References:
- [KINK] – Chapter 12
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
Part A: bad major version (BASIC)
TAHI Project TECHNICAL DOCUMENT
296
KINK Test Specification
NUT (EN)
responder
Packet #1
Judgment #1
TN1 (EN)
initiator
CREATE, AP_REQ,
E{ISAKMP(QMMaj=0xf, SA(P(T)), Ni, IDi, IDr)}
REPLY, AP_REP,
E{ERROR(KINK_BADQMVERS), ISAKMP())}
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However, QMMaj is set to 0xf.
2. Observe the packets transmitted by the NUT on Link A.
Part B: bad minor version (BASIC)
NUT (EN)
responder
Packet #1
Judgment #1
TN1 (EN)
initiator
CREATE, AP_REQ,
E{ISAKMP(QMMin=0xf, SA(P(T)), Ni, IDi, IDr)}
REPLY, AP_REP,
E{ERROR(KINK_BADQMVERS), ISAKMP())}
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However, QMMin is set to 0xf.
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must respond to CREATE with REPLY message described as following
to indicate KINK error.
KINK_BADQMVERS
IPv6
Next Header:
Source Address:
Destination Address:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
297
KINK Test Specification
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
AP-REP:
raw data of Kerberos AP-REP
KINK_ENCRYPT Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length:
the actual length of this payload in octets
InnerNextPload:
KINK_ERROR (8)
RESERVED2:
0
KINK_ERROR Payload
Next Payload:
KINK_ISAKMP (6)
RESERVED:
0
Payload Length: the actual length of this payload in octets
ErrorCode:
KINK_BADQMVERS (6)
KINK_ISAKMP Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
InnerNextPload: NONE (0)
QMMaj:
1
QMMin:
0
RESERVED:
0
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
* The shaded region in Common Observed Packet #6 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
unencrypted KINK_BADQMVERS
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
298
KINK Test Specification
DOI:
Internet IP Security DOI (1)
XID:
1
NextPayload:
KINK_AP_REP (2)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_AP_REP Payload
Next Payload:
KINK_ERROR (8)
RESERVED:
0
Payload Length: the actual length of this payload in octets
EPOCH:
the same value as REPLY message
in CREATE Message Flow
AP-REP:
raw data of Kerberos AP-REP
KINK_ERROR Payload
Next Payload:
KINK_ISAKMP (6)
RESERVED:
0
Payload Length: the actual length of this payload in octets
ErrorCode:
KINK_BADQMVERS (6)
KINK_ISAKMP Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
InnerNextPload: NONE (0)
QMMaj:
1
QMMin:
0
RESERVED:
0
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
299
KINK Test Specification
EN.EN.R.9.5: Receipt of unnecessary data after the message
Purpose:
Verify that a node properly proccesses a message which has unnecessary data after
the message
References:
- [KINK] – Chapter 4
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
300
KINK Test Specification
NUT (EN)
responder
Packet #1
TN1 (EN)
initiator
KINK(CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}, Cksum),
8 bytes unnecessary data (all bits set to zero)
(optimistic proposal, but Nr was added by the responder)
(2-way handshake)
NUT (EN)
responder
(3-way handshake)
TN1 (EN)
initiator
NUT (EN)
responder
Judgment #1
TN1 (EN)
initiator
Judgment #1
REPLY, AP_REP,
E{ISAKMP(SA(P(T)), IDi, IDr)}
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T)), Nr, IDi, IDr)}
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However, 8 bytes extra UDP data that all bits set to zero is added after
KINK message.
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
TAHI Project TECHNICAL DOCUMENT
301
KINK Test Specification
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
302
KINK Test Specification
EN.EN.R.9.6: Receipt of CREATE with non-zero value in reserved field
Purpose:
Verify that a node properly ignores reserved field in CREATE message
References:
- [KINK] – Chapter 4
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
303
KINK Test Specification
NUT (EN)
responder
Packet #1
TN1 (EN)
initiator
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
(optimistic proposal, but Nr was added by the responder)
(2-way handshake)
NUT (EN)
responder
(3-way handshake)
TN1 (EN)
initiator
NUT (EN)
responder
TN1 (EN)
initiator
Judgment #1
Judgment #1
REPLY, AP_REP,
E{ISAKMP(SA(P(T)), IDi, IDr)}
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T)), Nr, IDi, IDr)}
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However, Reserved Field in CREATE message must be set as following.
KINK
RESRVED:
0xf
RESERVED2:
0x7f
KINK_AP_REQ Payload
RESERVED:
0xff
KINK_ENCRYPT Payload
RESERVED:
0xff
RESERVED2:
0xffffff
KINK_ISAKMP Payload
RESERVED: 0xff
RESERVED: 0xffff
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
TAHI Project TECHNICAL DOCUMENT
304
KINK Test Specification
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
305
KINK Test Specification
EN.EN.R.9.7: Receipt of ACK with non-zero value in reserved field
Purpose:
Verify that a node properly ignores reserved field in ACK message
References:
- [KINK] – Chapter 4
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
below.
TN1 will propose multiple Transform payloads as described
Transform #2 will be selected by NUT.
Transform #
1
2
IPsec encryption algorithm
ESP_AES-CBC (12)
ESP_3DES (3)
IPsec authentication algorithm
AES-XCBC-MAC (9)
HMAC-SHA (2)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
306
KINK Test Specification
NUT (EN)
responder
Packet #1
Judgment #1
TN1 (EN)
initiator
CREATE, AP_REQ,
E{ISAKMP(SA(P(T1, T2)), Ni, IDi, IDr)}
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T2)), Nr, IDi, IDr)}
Packet #2
ACK, AP_REQ
Packet #3
IPsec(ESP){ICMPv6 Echo Request}
Judgment #2
IPsec(ESP){ICMPv6 Echo Reply}
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However Proposal Payload must be set as following.
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
T Payload
Next Payload:
RESERVED:
TAHI Project TECHNICAL DOCUMENT
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
2
ANY
T (3)
0
the actual length of this payload in octets
1
ESP_AES-CBC (12)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
AES-XCBC-MAC (9)
TV (1)
Key Length (6)
128
NONE (0)
0
307
KINK Test Specification
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
the actual length of this payload in octets
2
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Transport (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to REPLY with ACK described as Common Transmitted Packet
#2.
However, Reserved Field in CREATE message must be set as following.
KINK
RESRVED:
0xf
RESERVED2:
0x7f
KINK_AP_REQ Payload
RESERVED:
0xff
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #3 or 4. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5.
TAHI Project TECHNICAL DOCUMENT
308
KINK Test Specification
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
309
KINK Test Specification
EN.EN.R.9.8: Receipt of GETTGT with non-zero value in reserved field
Purpose:
Verify that a node properly ignores reserved field in GETTGT message
References:
- [KINK] – Chapter 4
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
NUT (EN)
responder
Packet #1
Judgment #1
TN1 (EN)
initiator
GETTGT, TGT_REQ
REPLY, ERROR(KINK_U2UDENIED)
TAHI Project TECHNICAL DOCUMENT
310
KINK Test Specification
Part A: (BASIC)
1. TN1 transmits GETTGT message described as Common Transmitted Packet
#6.
However, Reserved Field in CREATE message must be set as following.
KINK
RESRVED:
0xf
RESERVED2:
0x7f
KINK_TGT_REQ Payload
RESERVED:
0xff
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must respond to GETTGT with REPLY message described as following
to indicate that the NUT is not allowed to return its TGT.
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
REPLY (3)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
the same value as GETTGT message
NextPayload:
KINK_ERROR (8)
ACKREQ:
true (1)
RESERVED2:
0
CksumLen:
0
KINK_ ERROR Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
ErrorCode:
KINK_U2UDENIED (7)
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
TAHI Project TECHNICAL DOCUMENT
311
The tester must allow
KINK Test Specification
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
312
KINK Test Specification
EN.EN.R.9.9: Receipt of unencrypted CREATE
Purpose:
Verify that a node properly processes CREATE message which doesn't encrypted by
KINK_ENCRYPT payload
References:
- [KINK] - Section 6.3
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
313
KINK Test Specification
NUT (EN)
responder
Packet #1
TN1 (EN)
initiator
CREATE, AP_REQ, ISAKMP(SA(P(T)), Ni, IDi, IDr)
(optimistic proposal, but Nr was added by the responder)
(2-way handshake)
NUT (EN)
responder
(3-way handshake)
TN1 (EN)
initiator
NUT (EN)
responder
TN1 (EN)
initiator
Judgment #1
Judgment #1
REPLY, AP_REP,
E{ISAKMP(SA(P(T)), IDi, IDr)}
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T)), Nr, IDi, IDr)}
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However KINK_ENCRYPT Payload must not appear as described as
following.
KINK
KINK_AP_REQ Payload
KINK_ISAKMP Payload
SA Payload
P Payload
T Payload
Data Attribute
Data Attribute
Data Attribute
Data Attribute
Ni Payload
IDi Payload
IDr Payload
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
TAHI Project TECHNICAL DOCUMENT
314
KINK Test Specification
always follow SA Life Type Data Attribute.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
315
KINK Test Specification
EN.EN.R.9.10: Receipt of unencrypted DELETE
Purpose:
Verify that a node properly processes DELETE message which doesn't encrypted by
KINK_ENCRYPT payload
References:
- [KINK] - Section 6.4
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
316
KINK Test Specification
(2-way handshake)
NUT (EN)
responder
(3-way handshake)
TN1 (EN)
initiator
NUT (EN)
responder
TN1 (EN)
initiator
Packet #1
Packet #1
CREATE(XID=0), AP_REQ,
E{ISAKMP(SA(P(SPIi1, T)), Ni, IDi, IDr)}
Judgment #1
Judgment #1
REPLY(XID=0), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), IDi, IDr)}
REPLY(XID=0, ACKREQ), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), Nr, IDi, IDr)}
Packet #2
ACK(XID=0), AP_REQ
NUT (EN)
responder
Packet #3
Judgment #2
TN1 (EN)
initiator
IPsec(ESP1(SPIr1)){ICMPv6 Echo Request}
IPsec(ESP1(SPIi1)){ICMPv6 Echo Reply}
(Deleting)
Packet #4
Judgment #3
Packet #5
Judgment #4
DELETE(XID=1), AP_REQ, ISAKMP(D(SPIi1))
REPLY(XID=1), AP_REP, E{ISAKMP(D(SPIr1)))}
IPsec(ESP(SPIr1)){ICMPv6 Echo Request}
No response
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
6. TN1 transmits DELETE message described as Common Transmitted Packet
#4.
However KINK_ENCRYPT Payload must not appear as described as
following.
TAHI Project TECHNICAL DOCUMENT
317
KINK Test Specification
KINK
KINK_AP_REQ Payload
KINK_ISAKMP Payload
D Payload
7. Observe the packets transmitted by the NUT on Link A.
8. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
ICMPv6 Identifier is set to one.
9. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5.
Step 7: (Judgment #3)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #6 or 7.
Step 9: (Judgment #4)
The NUT must not respond to ICMPv6 Echo Request with ICMPv6 Echo Reply
because SA has already deleted at Step 7.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
318
KINK Test Specification
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
ANY
28,800
319
KINK Test Specification
EN.EN.R.9.11: Sending KRB_AP_ERR_SKEW
Purpose:
Verify that a node properly rejects a message when the responder clock and the
initiator clock are off by more than the policy-determinde clock skew limit.
References:
- [KINK] - Section 3.5
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
320
KINK Test Specification
NUT (EN)
responder
TN1 (EN)
initiator
(push TN’s clock forward 6 minutes)
Packet #1
Judgment #1
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
REPLY, AP_REP,
E{KRB_ERROR(KRB_AP_ERR_SKEW)}
Part A: (BASIC)
1. Set the clock forward 6 minutes on TN1.
2. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
3. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 3: (Judgment #1)
The NUT must respond to CREATE with REPLY message described as following
to indicate Kerberos error.
KRB_AP_ERR_SKEW
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
0
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
321
KINK Test Specification
EPOCH:
the current POSIX time
AP-REP:
raw data of Kerberos AP-REP
KINK_ENCRYPT Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length:
the actual length of this payload in octets
InnerNextPload:
KINK_KRB_ERROR (3)
RESERVED2:
0
KINK_KRB_ERROR Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
KRB-ERROR:
raw Kerberos KRB-ERROR
indicating KRB_AP_ERR_SKEW
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
* The shaded region in Common Observed Packet #6 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
unencrypted KRB_AP_ERR_SKEW
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
REPLY (3)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
0
NextPayload:
KINK_AP_REP (2)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_AP_REP Payload
Next Payload:
KINK_KRB_ERROR (3)
RESERVED:
0
Payload Length: the actual length of this payload in octets
EPOCH:
the current POSIX time
AP-REP:
raw data of Kerberos AP-REP
KINK_KRB_ERROR Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
KRB-ERROR:
raw Kerberos KRB-ERROR
indicating KRB_AP_ERR_SKEW
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Possible Problems:
TAHI Project TECHNICAL DOCUMENT
322
KINK Test Specification
- None.
TAHI Project TECHNICAL DOCUMENT
323
KINK Test Specification
Section 1.2: EN to SGW Tunnel
Scope:
The following tests cover the endpoint to security gateway tunnel mode scenario.
In
this endpoint to security gateway tunnel mode scenario, a protected endpoint connects
back to its network through an IPsec-protected tunnel.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation uses the tunnel mode IPsec to
communicate with the another endpoint.
Default Network Topology:
The logical network topology involves EN, SGW, KDC, Host and Router on each link.
The shaded region labelled as <TN> in Fig 3 is done inside TN node logically.
The
tunnel mode is used in this network topology as shown as Fig 4.
TAHI Project TECHNICAL DOCUMENT
324
KINK Test Specification
Fig 3 EN to SGW Common Network Topology for NUT (EN)
Fig 4 EN to SGW Tunnel Scenario for NUT (EN)
Default NUT (EN) Configuration:
- IP configuration:
Address
Default router
NUT - Link A
(Prefix A::<any_interface_ID>)
TR1 - Link A
(fe80::f)
- Kerberos configuration:
KDC
Principal Name
Pre-shared Key
Encryption Type
Checksum Type
User-to-User authentication
KDC - Link X
(Prefix X::e)
"kink/[email protected]"
"KINKtest0123456789abcdefABCDEF!?"
AES256-CTS-HMAC-SHA1-96 (18)
HMAC-SHA1-96-AES256 (16)
disable
TAHI Project TECHNICAL DOCUMENT
325
KINK Test Specification
- KINK configuration:
Address
Port
Principal Name
PFS
IDi
IDr
ID Type
Protocol ID
Port
Identification
Data
Local
NUT - Link A
(Prefix A::<any_interface_ID>)
910
"kink/nut.example.com
@EXAMPLE.COM"
disable
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
Remote
TN1 - Link X
(Prefix X::1)
910
"kink/tn.example.com
@EXAMPLE.COM"
disable
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link Y
(Prefix Y::/64)
- IPsec configuration:
IPsec Security Protocol
IPsec ESP Transform
SA Life Type (1)
SA Life Duration (2)
Encapsulation Mode (4)
Authentication Algorithm (5)
Inbound
Outbound
PROTO_IPSEC_ESP (3) PROTO_IPSEC_ESP (3)
ESP_3DES (3)
ESP_3DES (3)
Seconds (1)
Seconds (1)
28,800
28,800
Tunnel (1)
Tunnel (1)
HMAC-SHA (2)
HMAC-SHA (2)
If NUT is the initiator, above proposal must be one of proposals from NUT.
If NUT is the responder, NUT must select above proposal.
TAHI Project TECHNICAL DOCUMENT
326
KINK Test Specification
Subsection 1.2.1: Initiator
Scope:
In KINK exchanges, either of endpoints initiates the exchange by sending the command
and the another responds to this command with the response.
The following tests
cover KINK exchanges when the KINK implementation initiates these exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation initiates KINK exchanges.
Default Packets:
Packets sent from TN:
Common Packets to be transmitted from TN are defined as the following. Tests in
this test group may refer to these packets.
Common Transmitted Packet #1: REPLY for CREATE
IPv6
Next Header:
Source Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
TAHI Project TECHNICAL DOCUMENT
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
0
KINK_AP_REP (2)
false (0)
the same value as CREATE message
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the current POSIX time
327
KINK Test Specification
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
TAHI Project TECHNICAL DOCUMENT
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
IDi (5)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
0x10000000
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
NONE (0)
328
KINK Test Specification
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link Y
(Prefix Y::/64)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
* The shaded region in Common Transmitted Packet #1 is encrypted by
Kerberos encrypt function with Key Usage Number 39 (KINK_ENCRYPT
payload).
Common Transmitted Packet #2: IPsec ESP { ICMPv6 Echo Request }
IPv6
Next Header:
Source Address:
ESP (50)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
Destination Address:
ESP
SPI:
Sequence Number:
IV:
proposed by CREATE from NUT
1
8 bytes length stream
that all bits are set to zero
IPv6
Next Header:
Source Address:
IPv6-ICMP (58)
TH1 - Link Y
(Prefix Y::d)
NUT - Link A
(Prefix A::<any_interface_ID>)
Destination Address:
ICMPv6
Type:
Code:
Checksum:
Identifier:
Sequence Number:
Data:
Padding:
Pad Length:
Next Header:
ICV:
Echo Request (128)
0
ICMPv6 checksum
0
0
8 bytes length stream
that all bits are set to zero
ANY
the actual length of Pad in octets
IPv6 (41)
calculated by HMAC-SHA1-96
using calculated KEYMAT
* The shaded region in Common Transmitted Packet #2 is encrypted by
TripleDES in CBC mode using calculated KEYMAT.
Packets sent from NUT:
Common Packets to be transmitted from NUT are defined as the following. Tests
in this test group may refer to these packets.
TAHI Project TECHNICAL DOCUMENT
329
KINK Test Specification
Common Observed Packet #1: CREATE
IPv6
Next Header:
Source Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REQ Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REQ:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
TAHI Project TECHNICAL DOCUMENT
kink (910)
kink (910)
CREATE (1)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
ANY
KINK_AP_REQ (1)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REQ
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
330
KINK Test Specification
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
ANY
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link Y
(Prefix Y::/64)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
* The shaded region in Common Observed Packet #1 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
Common Observed Packet #2: unencrypted CREATE
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
CREATE (1)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
331
KINK Test Specification
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REQ Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REQ:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
TAHI Project TECHNICAL DOCUMENT
ANY
KINK_AP_REQ (1)
false (0)
0
the actual length of Cksum
KINK_ISAKMP (6)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REQ
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
ANY
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
332
KINK Test Specification
Protocol ID:
Port:
Identification Data:
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link Y
(Prefix Y::/64)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
Common Observed Packet #3: IPsec ESP { ICMPv6 Echo Reply }
IPv6
Next Header:
Source Address:
ESP (50)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
ESP
SPI:
Sequence Number:
IV:
IPv6
Next Header:
Source Address:
0x10000000
ANY
ANY
IPv6-ICMP (58)
NUT - Link A
(Prefix A::<any_interface_ID>)
TH1 - Link Y
(Prefix Y::d)
Destination Address:
ICMPv6
Type:
Code:
Checksum:
Identifier:
Sequence Number:
Data:
Padding:
Pad Length:
Next Header:
ICV:
Echo Reply (129)
0
ICMPv6 checksum
0
0
8 bytes length stream
that all bits are set to zero
ANY
the actual length of Pad in octets
IPv6 (41)
calculated by HMAC-SHA1-96
using calculated KEYMAT
* The shaded region in Common Observed Packet #3 is encrypted by TripleDES
in CBC mode using calculated KEYMAT.
TAHI Project TECHNICAL DOCUMENT
333
KINK Test Specification
Group 1: CREATE Message Flow
Scope:
In KINK exchanges, either of endpoints initiates the exchange by sending the command
and the another responds to this command with the response.
The following tests
cover the CREATE message flows when the KINK implementation initiates these
exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation initiates CREATE message flows.
TAHI Project TECHNICAL DOCUMENT
334
KINK Test Specification
EN.SGW.I.1.1: CREATE Message Flow (2-way handshake)
Purpose:
Verify that an initiator properly establish SA by CREATE message flow
References:
- [KINK] - Section 3.2
- [KINK] - Section 6.3
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
335
KINK Test Specification
TN1 (SGW)
responder
NUT (EN)
initiator
Judgment #1
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
REPLY, AP_REP,
E{ISAKMP(SA(P(T)), IDi, IDr)}
Packet #1
TH1 (Host)
Packet #2
ICMPv6 Echo Request
Judgment #2
ICMPv6 Echo Reply
IPsec ESP tunnel
Part A: (ADVANCED)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #1.
4. After responding to CREATE, TN1 transmits ICMPv6 Echo Request
encrypted by ESP described as Common Transmitted Packet #2.
5. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #3.
Possible Problems:
TAHI Project TECHNICAL DOCUMENT
336
KINK Test Specification
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
337
KINK Test Specification
Subsection 1.2.2: Responder
Scope:
In KINK exchanges, either of endpoints initiates the exchange by sending the command
and the another responds to this command with the response.
The following tests
cover KINK exchanges when the KINK implementation responds to these exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation initiates KINK exchanges.
Default Packets:
Packets sent from TN:
Common Packets to be transmitted from TN are defined as the following. Tests in
this test group may refer to these packets.
Common Transmitted Packet #1: CREATE
IPv6
Next Header:
Source Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REQ Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REQ:
TAHI Project TECHNICAL DOCUMENT
kink (910)
kink (910)
CREATE (1)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
0
KINK_AP_REQ (1)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REQ
338
KINK Test Specification
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
0x10000000
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
8 bytes length random data
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link Y
(Prefix Y::/64)
IDr Payload
TAHI Project TECHNICAL DOCUMENT
339
KINK Test Specification
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
* The shaded region in Common Transmitted Packet #1 is encrypted by
Kerberos encrypt function with Key Usage Number 39 (KINK_ENCRYPT
payload).
Common Transmitted Packet #2: ACK
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
ACK (5)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
0
NextPayload:
KINK_AP_REQ (1)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_AP_REQ Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
EPOCH:
the same value as CREATE message
AP-REQ:
raw data of Kerberos AP-REQ
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Common Transmitted Packet #3: IPsec ESP { ICMPv6 Echo Request }
IPv6
Next Header:
Source Address:
Destination Address:
ESP
SPI:
Sequence Number:
TAHI Project TECHNICAL DOCUMENT
ESP (50)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
proposed by REPLY from NUT
in CREATE Message Flow
1
340
KINK Test Specification
IV:
8 bytes length stream
that all bits are set to zero
IPv6
Next Header:
Source Address:
IPv6-ICMP (58)
TH1 - Link Y
(Prefix Y::d)
NUT - Link A
(Prefix A::<any_interface_ID>)
Destination Address:
ICMPv6
Type:
Code:
Checksum:
Identifier:
Sequence Number:
Data:
Padding:
Pad Length:
Next Header:
ICV:
Echo Request (128)
0
ICMPv6 checksum
0
0
8 bytes length stream
that all bits are set to zero
ANY
the actual length of Pad in octets
IPv6 (41)
calculated by HMAC-SHA1-96
using calculated KEYMAT
* The shaded region in Common Transmitted Packet #2 is encrypted by
TripleDES in CBC mode using calculated KEYMAT.
Packets sent from NUT:
Common Packets to be transmitted from NUT are defined as the following. Tests
in this test group may refer to these packets.
Common Observed Packet #1: REPLY for CREATE
IPv6
Next Header:
Source Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
TAHI Project TECHNICAL DOCUMENT
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message
Internet IP Security DOI (1)
0
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the current POSIX time
341
KINK Test Specification
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
TAHI Project TECHNICAL DOCUMENT
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
IDi (5)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link Y
(Prefix Y::/64)
NONE (0)
342
KINK Test Specification
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
* The shaded region in Common Observed Packet #1 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
Common Observed Packet #2: unencrypted REPLY for CREATE
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REP:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message
Internet IP Security DOI (1)
0
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ISAKMP (6)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
IDi (5)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
343
KINK Test Specification
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
Cksum:
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link Y
(Prefix Y::/64)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Common Observed Packet #3: REPLY with Nr for CREATE
IPv6
Next Header:
Source Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
TAHI Project TECHNICAL DOCUMENT
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
0
344
KINK Test Specification
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Nr Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
TAHI Project TECHNICAL DOCUMENT
345
KINK_AP_REP (2)
true (1)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Nr (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
ANY
KINK Test Specification
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link Y
(Prefix Y::/64)
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
* The shaded region in Common Observed Packet #3 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
Common Observed Packet #4: unencrypted REPLY with Nr for CREATE
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REP:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message
Internet IP Security DOI (1)
0
KINK_AP_REP (2)
true (1)
0
the actual length of Cksum
KINK_ISAKMP (6)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Nr (10)
346
KINK Test Specification
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Nr Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
Cksum:
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
ANY
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link Y
(Prefix Y::/64)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
NUT - Link A
(Prefix A::<any_interface_ID>)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Common Observed Packet #5: IPsec ESP { ICMPv6 Echo Reply }
TAHI Project TECHNICAL DOCUMENT
347
KINK Test Specification
IPv6
Next Header:
Source Address:
ESP (50)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
ESP
SPI:
Sequence Number:
IV:
IPv6
Next Header:
Source Address:
0x10000000
ANY
ANY
IPv6-ICMP (58)
NUT - Link A
(Prefix A::<any_interface_ID>)
TH1 - Link Y
(Prefix Y::d)
Destination Address:
ICMPv6
Type:
Code:
Checksum:
Identifier:
Sequence Number:
Data:
Padding:
Pad Length:
Next Header:
ICV:
Echo Reply (129)
0
ICMPv6 checksum
0
0
8 bytes length stream
that all bits are set to zero
ANY
the actual length of Pad in octets
IPv6 (41)
calculated by HMAC-SHA1-96
using calculated KEYMAT
* The shaded region in Common Observed Packet #3 is encrypted by TripleDES
in CBC mode using calculated KEYMAT.
TAHI Project TECHNICAL DOCUMENT
348
KINK Test Specification
Group 1: CREATE Message Flow
Scope:
In KINK exchanges, either of endpoints initiates the exchange by sending the command
and the another responds to this command with the response.
The following tests
cover the CREATE message flows when the KINK implementation initiates these
exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation responds to CREATE message
flows.
TAHI Project TECHNICAL DOCUMENT
349
KINK Test Specification
EN.SGW.R.1.1: CREATE Message Flow
Purpose:
Verify that a responder properly establish SA by CREATE message flow
References:
- [KINK] - Section 3.2
- [KINK] - Section 6.3
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (EN)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
350
KINK Test Specification
TN1 (SGW)
initiator
NUT (EN)
responder
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Packet #1
(optimistic proposal, but Nr was added by the responder)
(2-way handshake)
(3-way handshake)
TN1 (SGW)
initiator
NUT (EN)
responder
TN1 (SGW)
initiator
NUT (EN)
responder
Judgment #1
Judgment #1
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T)), Nr, IDi, IDr)}
REPLY, AP_REP,
E{ISAKMP(SA(P(T)), IDi, IDr)}
Packet #2
ACK, AP_REQ
TN1 (SGW)
initiator
NUT (EN)
responder
TH1 (Host)
Packet #3
ICMPv6 Echo Request
Judgment #2
ICMPv6 Echo Reply
IPsec ESP tunnel
Part A: (ADVANCED)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link A.
Observable Results:
TAHI Project TECHNICAL DOCUMENT
351
KINK Test Specification
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must transmit properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
352
KINK Test Specification
Chapter 2: SGW implementation
TAHI Project TECHNICAL DOCUMENT
353
KINK Test Specification
Section 2.1: SGW to SGW Tunnel
Scope:
The following tests cover the security gateway to security gateway tunnel scenario.
In
this security gateway to security gateway tunnel scenario, neither endpoint of the IP
connection implements IPsec, but network nodes between them protect traffic for part
of the way.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation uses the tunnel mode IPsec to
protect the communication between endpoints behind their own gateways.
Default Network Topology:
The logical network topology involves SGWs, KDC, Router and Host on each link. The
shaded region labelled as <TN> in Fig 5 is done inside TN node logically.
The tunnel
mode is used in this network topology as shown as Fig 6.
TAHI Project TECHNICAL DOCUMENT
354
KINK Test Specification
Fig 5 SGW to SGW Common Network Topology for NUT (SGW)
Fig 6 SGW to SGW Tunnel Scenario for NUT (SGW)
Default NUT (SGW) Configuration:
- IP configuration:
Address
Default router
NUT - Link A
(Prefix A::<any_interface_ID>)
NUT - Link B
(Prefix B::<any_interface_ID>)
TR1 - Link A
(fe80::f)
- Kerberos configuration:
TAHI Project TECHNICAL DOCUMENT
355
KINK Test Specification
KDC
Principal Name
Pre-shared Key
Encryption Type
Checksum Type
User-to-User authentication
KDC - Link X
(Prefix X::e)
"kink/[email protected]"
"KINKtest0123456789abcdefABCDEF!?"
AES256-CTS-HMAC-SHA1-96 (18)
HMAC-SHA1-96-AES256 (16)
disable
- KINK configuration:
Address
Port
Principal Name
PFS
IDi
IDr
ID Type
Protocol ID
Port
Identification
Data
Local
NUT - Link A
(Prefix A::<any_interface_ID>)
910
"kink/nut.example.com
@EXAMPLE.COM"
disable
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link B
(Prefix B::/64)
Remote
TN1 - Link X
(Prefix X::1)
910
"kink/tn.example.com
@EXAMPLE.COM"
disable
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link Y
(Prefix Y::/64)
- IPsec configuration:
IPsec Security Protocol
IPsec ESP Transform
SA Life Type (1)
SA Life Duration (2)
Encapsulation Mode (4)
Authentication Algorithm (5)
Inbound
Outbound
PROTO_IPSEC_ESP (3) PROTO_IPSEC_ESP (3)
ESP_3DES (3)
ESP_3DES (3)
Seconds (1)
Seconds (1)
28,800
28,800
Tunnel (1)
Tunnel (1)
HMAC-SHA (2)
HMAC-SHA (2)
If NUT is the initiator, above proposal must be one of proposals from NUT.
If NUT is the responder, NUT must select above proposal.
TAHI Project TECHNICAL DOCUMENT
356
KINK Test Specification
Subsection 2.1.1: Initiator
Scope:
In KINK exchanges, either of endpoints initiates the exchange by sending the command
and the another responds to this command with the response.
The following tests
cover KINK exchanges when the KINK implementation initiates these exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation initiates KINK exchanges.
Default Packets:
Packets sent from TN:
Common Packets to be transmitted from TN are defined as the following. Tests in
this test group may refer to these packets.
Common Transmitted Packet #1: REPLY for CREATE
IPv6
Next Header:
Source Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
TAHI Project TECHNICAL DOCUMENT
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
0
KINK_AP_REP (2)
false (0)
the same value as CREATE message
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the current POSIX time
357
KINK Test Specification
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
TAHI Project TECHNICAL DOCUMENT
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
IDi (5)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
0x10000000
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link B
(Prefix B::/64)
NONE (0)
358
KINK Test Specification
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link Y
(Prefix Y::/64)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
* The shaded region in Common Transmitted Packet #1 is encrypted by
Kerberos encrypt function with Key Usage Number 39 (KINK_ENCRYPT
payload).
Common Transmitted Packet #2: REPLY with Nr for CREATE
IPv6
Next Header:
Source Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
TAHI Project TECHNICAL DOCUMENT
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
the same value as CREATE message
KINK_AP_REP (2)
true (1)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Nr (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
359
KINK Test Specification
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Nr Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
0x10000000
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (3)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
8 bytes length random data
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link B
(Prefix B::/64)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link Y
(Prefix Y::/64)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
* The shaded region in Common Transmitted Packet #2 is encrypted by
Kerberos encrypt function with Key Usage Number 39 (KINK_ENCRYPT
payload).
TAHI Project TECHNICAL DOCUMENT
360
KINK Test Specification
Common Transmitted Packet #3: IPsec ESP { ICMPv6 Echo Request }
IPv6
Next Header:
Source Address:
ESP (50)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
Destination Address:
ESP
SPI:
Sequence Number:
IV:
proposed by CREATE from NUT
1
8 bytes length stream
that all bits are set to zero
IPv6
Next Header:
Source Address:
IPv6-ICMP (58)
TH2 - Link Y
(Prefix Y::c)
TH1 - Link B
(Prefix B::d)
Destination Address:
ICMPv6
Type:
Code:
Checksum:
Identifier:
Sequence Number:
Data:
Padding:
Pad Length:
Next Header:
ICV:
Echo Request (128)
0
ICMPv6 checksum
0
0
8 bytes length stream
that all bits are set to zero
ANY
the actual length of Pad in octets
IPv6 (41)
calculated by HMAC-SHA1-96
using calculated KEYMAT
* The shaded region in Common Transmitted Packet #3 is encrypted by
TripleDES in CBC mode using calculated KEYMAT.
Common Transmitted Packet #4: ICMPv6 Echo Reply
IPv6
Next Header:
Source Address:
IPv6-ICMP (58)
TH1 - Link B
(Prefix B::d)
TH2 - Link Y
(Prefix Y::c)
Destination Address:
ICMPv6
Type:
Code:
Checksum:
Identifier:
Sequence Number:
Data:
Echo Reply (129)
0
ICMPv6 checksum
0
0
8 bytes length stream
that all bits are set to zero
Common Transmitted Packet #5: REPLY for STATUS
IPv6
Next Header:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
361
KINK Test Specification
Source Address:
Destination Address:
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
REPLY (3)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
the same value as STATUS message
NextPayload:
KINK_AP_REP (2)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_AP_REP Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
EPOCH:
the same value as REPLY message
in CREATE Message Flow
AP-REP:
raw data of Kerberos AP-REP
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Common Transmitted Packet #6: REPLY for GETTGT
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
REPLY (3)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
the same value as GETTGT message
NextPayload:
KINK_TGT_REP (5)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_TGT_REP Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
TGT:
DER-encoded TGT of the responder
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Common Transmitted Packet #7: ICMPv6 Destination Unreachable
IPv6
Next Header:
TAHI Project TECHNICAL DOCUMENT
IPv6-ICMP (58)
362
KINK Test Specification
Source Address:
Destination Address:
ICMPv6
Type:
Code:
Checksum:
Unused:
Data:
TR1 - Link X
(Prefix X::f)
NUT - Link A
(Prefix A::<any_interface_ID>)
Destination Unreachable (1)
Address unreachable (3)
ICMPv6 checksum
0
Common Observed Packet #4
Packets sent from NUT:
Common Packets to be transmitted from NUT are defined as the following. Tests
in this test group may refer to these packets.
Common Observed Packet #1: CREATE
IPv6
Next Header:
Source Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REQ Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REQ:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
TAHI Project TECHNICAL DOCUMENT
kink (910)
kink (910)
CREATE (1)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
ANY
KINK_AP_REQ (1)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REQ
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Ni (10)
363
KINK Test Specification
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
ANY
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link B
(Prefix B::/64)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link Y
(Prefix Y::/64)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
* The shaded region in Common Observed Packet #1 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
TAHI Project TECHNICAL DOCUMENT
364
KINK Test Specification
Common Observed Packet #2: unencrypted CREATE
IPv6
Next Header:
Source Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REQ Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REQ:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
TAHI Project TECHNICAL DOCUMENT
kink (910)
kink (910)
CREATE (1)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
ANY
KINK_AP_REQ (1)
false (0)
0
the actual length of Cksum
KINK_ISAKMP (6)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REQ
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
365
KINK Test Specification
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (3)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
ANY
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link B
(Prefix B::/64)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link Y
(Prefix Y::/64)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
Common Observed Packet #3: ACK
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
ACK (5)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
the same value as CREATE message
NextPayload:
KINK_AP_REQ (1)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_AP_REQ Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
EPOCH:
the same value as CREATE message
AP-REQ:
raw data of Kerberos AP-REQ
TAHI Project TECHNICAL DOCUMENT
366
KINK Test Specification
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Common Observed Packet #4: ICMPv6 Echo Request
IPv6
Next Header:
Source Address:
IPv6-ICMP (58)
TH2 - Link Y
(Prefix Y::c)
TH1 - Link B
(Prefix B::d)
Destination Address:
ICMPv6
Type:
Code:
Checksum:
Identifier:
Sequence Number:
Data:
Echo Request (128)
0
ICMPv6 checksum
0
0
8 bytes length stream
that all bits are set to zero
Common Observed Packet #5: IPsec ESP { ICMPv6 Echo Reply }
IPv6
Next Header:
Source Address:
ESP (50)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
ESP
SPI:
Sequence Number:
IV:
IPv6
Next Header:
Source Address:
0x10000000
ANY
ANY
IPv6-ICMP (58)
TH1 - Link B
(Prefix B::d)
TH2 - Link Y
(Prefix Y::c)
Destination Address:
ICMPv6
Type:
Code:
Checksum:
Identifier:
Sequence Number:
Data:
Padding:
Pad Length:
Next Header:
ICV:
Echo Reply (129)
0
ICMPv6 checksum
0
0
8 bytes length stream
that all bits are set to zero
ANY
the actual length of Pad in octets
IPv6 (41)
calculated by HMAC-SHA1-96
using calculated KEYMAT
* The shaded region in Common Observed Packet #5 is encrypted by TripleDES
in CBC mode using calculated KEYMAT.
Common Observed Packet #6: STATUS
TAHI Project TECHNICAL DOCUMENT
367
KINK Test Specification
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
STATUS (6)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
ANY
NextPayload:
KINK_AP_REQ (1)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_AP_REQ Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
EPOCH:
the same value as CREATE message
AP-REQ:
raw data of Kerberos AP-REQ
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Common Observed Packet #7: GETTGT
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
ACK (5)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
ANY
NextPayload:
KINK_TGT_REQ (4)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_TGT_REQ Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
PrincName:
kink/[email protected]
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
TAHI Project TECHNICAL DOCUMENT
368
KINK Test Specification
Group 1: CREATE Message Flow
Scope:
In KINK exchanges, either of endpoints initiates the exchange by sending the command
and the another responds to this command with the response.
The following tests
cover the CREATE message flows when the KINK implementation initiates these
exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation initiates CREATE message flows.
TAHI Project TECHNICAL DOCUMENT
369
KINK Test Specification
SGW.SGW.I.1.1: Sending CREATE Message
Purpose:
Verify that an initiator transmits CREATE message in properly format
References:
- [KINK] - Section 3.2
- [KINK] - Section 6.3
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
370
KINK Test Specification
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
371
KINK Test Specification
SGW.SGW.I.1.2: CREATE Message Flow (2-way handshake)
Purpose:
Verify that an initiator properly establish SA by CREATE message flow
References:
- [KINK] - Section 3.2
- [KINK] - Section 6.3
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
372
KINK Test Specification
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #1.
4. After responding to CREATE, TN1 transmits ICMPv6 Echo Request
encrypted by ESP described as Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #4 and forward to TH1.
Step 7: (Judgment #3)
TAHI Project TECHNICAL DOCUMENT
373
KINK Test Specification
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5 to TN1.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
374
KINK Test Specification
SGW.SGW.I.1.3: The non-optimistic keying by receipt of Nr
Purpose:
Verify that an initiator properly processes 3-way handshake when the responder
wants to contribute the keying materials
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.4
- [KINK] - Section 6.2
- [KINK] - Section 6.3
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
375
KINK Test Specification
TN1 (SGW)
responder
NUT (SGW)
initiator
Judgment #1
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Packet #1
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T)), Nr, IDi, IDr)}
Judgment #2
ACK, AP_REQ
IPsec ESP tunnel
TH1 (Host)
TH2 (Host)
Pkt #2/Jdg #3
ICMPv6 Echo Request
Pkt #3/Jdg #4
ICMPv6 Echo Reply
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #2.
4. Observe the packets transmitted by the NUT on Link A.
5. After observing ACK, TN1 transmits ICMPv6 Echo Request encrypted by ESP
described as Common Transmitted Packet #3.
6. Observe the packets transmitted by the NUT on Link B.
7. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
8. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 4: (Judgment #2)
The NUT must respond to REPLY with ACK described as Common Observed
TAHI Project TECHNICAL DOCUMENT
376
KINK Test Specification
Packet #3.
Step 6: (Judgment #3)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #4 and forward to TH1.
Step 8: (Judgment #4)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5 to TN1.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
377
KINK Test Specification
SGW.SGW.I.1.4: Creating an optimistic inbound SA
Purpose:
Verify that a node properly creates an optimistic inbound SA before initiating
CREATE message flow
References:
- [KINK] - Section 3.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
378
KINK Test Specification
TN1 (SGW)
responder
NUT (SGW)
initiator
Judgment #1
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
IPsec ESP tunnel
TH1 (Host)
TH2 (Host)
Pkt #1/Jdg #2
ICMPv6 Echo Request
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. After observing CREATE, TN1 transmits ICMPv6 Echo Request encrypted by
ESP described as Common Transmitted Packet #3.
4. Observe the packets transmitted by the NUT on Link B.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 4: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #4 and forward to TH1.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
TAHI Project TECHNICAL DOCUMENT
379
KINK Test Specification
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
380
KINK Test Specification
Group 2: Cryptographic Algorithm Negotiation
Scope:
Creating SAs has two modes -- 2-way handshake and 3-way handshake.
The initiator
usually begins a negotiation expecting a 2-way handshake but the negotiation is
switched to a 3-way handshake when the optimistic proposal is not chosen by the
responder. The following tests cover 2-way handshake and 3-way handshake.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation can switch two modes while the
cryptographic algorithm negotiation.
TAHI Project TECHNICAL DOCUMENT
381
KINK Test Specification
SGW.SGW.I.2.1: Cryptographic Algorithm Negotiation
Purpose:
Verify that an initiator properly establish SA with the specific cryptographic
algorithms
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.1
- [KINK] - Section 5.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration, however use Cryptographic Algorithms as described below.
Part
A
B
C
D
E
IPsec encryption algorithm
ESP_NULL (11)
ESP_AES-CBC (12) with 128-bit keys
ESP_AES-CTR (13) with 128-bit keys
ESP_3DES (3)
ESP_3DES (3)
IPsec authentication algorithm
HMAC-SHA (2)
HMAC-SHA (2)
HMAC-SHA (2)
NONE (undefined)
AES-XCBC-MAC (9)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
TAHI Project TECHNICAL DOCUMENT
382
KINK Test Specification
Procedure:
Part A through E (ADVANCED)
Part
A
B
C
D
E
IPsec encryption algorithm
NULL
AES-CBC with 128-bit keys
AES-CTR with 128-bit keys
TripleDES-CBC
TripleDES-CBC
IPsec authentication algorithm
HMAC-SHA1-96
HMAC-SHA1-96
HMAC-SHA1-96
NONE
AES-XCBC-MAC-96
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #1. However Transform-ID in Transform payload and Attribute Value
in Authentication Algorithm Data Attribute must be set according to the
corresponding entry of the table above.
Only for Part B and C, following
Data Attribute must be also additionally included in Transform payload.
And only for Part D, Authentication Algorithm Data Attribute does not appear
in Transform Payload.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
TV (1)
Key Length (6)
128
4. After responding to CREATE, TN1 transmits ICMPv6 Echo Request
encrypted by ESP described as Common Transmitted Packet #3.
TAHI Project TECHNICAL DOCUMENT
383
However
KINK Test Specification
encryption algorithm and authentication algorithm must be set according to
the corresponding entry of the table above.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A through E:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. However Transform-ID in Transform
payload and Attribute Value in Authentication Algorithm Data Attribute must be
set according to the corresponding entry of the table in the procedure above.
In
addition, Data Attributes in Transform payload can be placed in any order
excepting that SA Life Duration Data Attribute is always follow SA Life Type
Data Attribute.
Only for Part B and C, following Data Attribute must be also
additionally included in Transform payload.
And only for Part D,
Authentication Algorithm Data Attribute must not appear in Transform Payload.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
TV (1)
Key Length (6)
128
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #4 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5 to TN1. However encryption
algorithm and authentication algorithm must be set according to the
corresponding entry of the table in the procedure above.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
TAHI Project TECHNICAL DOCUMENT
384
KINK Test Specification
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
385
KINK Test Specification
SGW.SGW.I.2.2: The shorter LIFE_SECONDS is selected from optimistic proposal
Purpose:
Verify that an initiator uses the shorter lifetime when the responder set lifetime to a
lower value
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.1
- [KINK] - Section 5.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
TN1 will respond with 30 seconds SA Life Duration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
386
KINK Test Specification
NUT (SGW)
initiator
TN1 (SGW)
responder
Judgment #1
CREATE, AP_REQ,
E{ISAKMP(SA(P(T(LIFE_SECONDSi))),
Ni, IDi, IDr)}
Packet #1
REPLY, AP_REP,
E{ISAKMP(SA(P(T(LIFE_SECONDSr))),
IDi, IDr)}
IPsec ESP tunnel
TH2 (Host)
TH1 (Host)
Pkt #2/Jdg #2
ICMPv6 Echo Request
Pkt #3/Jdg #3
ICMPv6 Echo Reply
(LIFE_SECONDSr expires)
Pkt #4/Jdg #4
No response
ICMPv6 Echo Request
IPsec ESP tunnel
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #1.
However Attribute Value in SA Life Duration Data Attribute
must be set to 30 seconds.
4. After responding to CREATE, TN1 transmits ICMPv6 Echo Request
encrypted by ESP described as Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
8. After 30 seconds, TN1 transmits ICMPv6 Echo Request encrypted by ESP
described as Common Transmitted Packet #3 with updating ICMPv6
Identifier to one.
9. Observe the packets transmitted by the NUT on Link A.
Observable Results:
TAHI Project TECHNICAL DOCUMENT
387
KINK Test Specification
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #4 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5 to TN1.
Step 9: (Judgment #4)
The NUT must not decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #4 and must not forward to TH1 because SA has negotiated
with 30 seconds lifetime and should expire.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
388
KINK Test Specification
SGW.SGW.I.2.3: The optimistic proposal is selected from multiple transforms
Purpose:
Verify that a node properly processes 2-way handshake when the responder selects
the optimistic proposal from proposed multiple transforms
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.1
- [KINK] - Section 5.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
In addition, configure NUT to propose with multiple
Transform payloads as described below.
Transform #
1
2
IPsec encryption algorithm
ESP_3DES (3)
ESP_AES-CBC (12)
Transform #1 will be selected by TN1.
IPsec authentication algorithm
HMAC-SHA (2)
AES-XCBC-MAC (9)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
TAHI Project TECHNICAL DOCUMENT
389
KINK Test Specification
Procedure:
Part A: (ADVANCED)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #1.
4. After responding to CREATE, TN1 transmits ICMPv6 Echo Request
encrypted by ESP described as Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. However Proposal Payload must be set as
following.
P Payload
Next Payload:
RESERVED:
Payload Length:
TAHI Project TECHNICAL DOCUMENT
NONE (0)
0
the actual length of this payload in octets
390
KINK Test Specification
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
1
PROTO_IPSEC_ESP (3)
4
2
ANY
T (3)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
NONE (0)
0
the actual length of this payload in octets
2
ESP_AES-CBC (12)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
AES-XCBC-MAC (9)
TV (1)
Key Length (6)
128
In addition, Data Attributes in Transform payload can be placed in any order
excepting that SA Life Duration Data Attribute is always follow SA Life Type
Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
TAHI Project TECHNICAL DOCUMENT
391
KINK Test Specification
Observed Packet #4 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5 to TN1.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- If NUT doesn't support cryptographic algorithms required in Transform #2, NUT can
use any other algorithms other than Transform #1.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
392
KINK Test Specification
SGW.SGW.I.2.4: The non-optimistic proposal is selected from multiple transforms
Purpose:
Verify that a node properly processes 3-way handshake when the responder selects
the non-optimistic proposal from proposed multiple transforms
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.1
- [KINK] - Section 5.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
In addition, configure NUT to propose with multiple
Transform payloads as described below.
Transform #
1
2
IPsec encryption algorithm
ESP_AES-CBC (12)
ESP_3DES (3)
Transform #2 will be selected by TN1.
IPsec authentication algorithm
AES-XCBC-MAC (9)
HMAC-SHA (2)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
TAHI Project TECHNICAL DOCUMENT
393
KINK Test Specification
Procedure:
NUT (SGW)
initiator
TN1 (SGW)
responder
CREATE, AP_REQ,
E{ISAKMP(SA(P(T1, T2)), Ni, IDi, IDr)}
Judgment #1
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T2)), Nr, IDi, IDr)}
Packet #1
Judgment #2
ACK, AP_REQ
IPsec ESP tunnel
TH1 (Host)
TH2 (Host)
Pkt #2/Jdg #3
ICMPv6 Echo Request
Pkt #3/Jdg #4
ICMPv6 Echo Reply
Part A: (ADVANCED)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #2.
4. Observe the packets transmitted by the NUT on Link A.
5. After observing ACK, TN1 transmits ICMPv6 Echo Request encrypted by ESP
described as Common Transmitted Packet #3.
6. Observe the packets transmitted by the NUT on Link B.
7. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
8. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. However Proposal Payload must be set as
following.
TAHI Project TECHNICAL DOCUMENT
394
KINK Test Specification
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
2
ANY
T (3)
0
the actual length of this payload in octets
1
ESP_AES-CBC (12)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
AES-XCBC-MAC (9)
TV (1)
Key Length (6)
128
NONE (0)
0
the actual length of this payload in octets
2
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
In addition, Data Attributes in Transform payload can be placed in any order
excepting that SA Life Duration Data Attribute is always follow SA Life Type
Data Attribute.
TAHI Project TECHNICAL DOCUMENT
395
KINK Test Specification
Step 4: (Judgment #2)
The NUT must respond to REPLY with ACK described as Common Observed
Packet #3.
Step 6: (Judgment #3)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #4 and forward to TH1.
Step 8: (Judgment #4)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5 to TN1.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- If NUT doesn't support cryptographic algorithms required in Transform #1, NUT can
use any other algorithms other than Transform #2.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
396
KINK Test Specification
SGW.SGW.I.2.5: The optimistic proposal is selected from multiple proposals
Purpose:
Verify that a node properly processes 2-way handshake when the responder selects
the optimistic proposal from proposed multiple proposals
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.1
- [KINK] - Section 5.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
In addition, configure NUT to propose with multiple
Transform payloads as described below.
Proposal #
1
2
Protocol ID
PROTO_IPSEC_ESP (3)
PROTO_IPSEC_AH (2)
Proposal #1 will be selected by TN1.
IPsec encryption algorithm
ESP_3DES (3)
-
IPsec authentication algorithm
HMAC-SHA (2)
AH_SHA (3)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
TAHI Project TECHNICAL DOCUMENT
397
KINK Test Specification
Procedure:
NUT (SGW)
initiator
TN1 (SGW)
responder
CREATE, AP_REQ,
E{ISAKMP(SA(P1(T), P2(T)), Ni, IDi, IDr)}
Judgment #1
REPLY, AP_REP,
E{ISAKMP(SA(P1(T)), IDi, IDr)}
Packet #1
TH1 (Host)
TH2 (Host)
Pkt #2/Jdg #2
ICMPv6 Echo Request
Pkt #3/Jdg #3
ICMPv6 Echo Reply
IPsec ESP tunnel
Part A: (ADVANCED)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #1.
4. After responding to CREATE, TN1 transmits ICMPv6 Echo Request
encrypted by ESP described as Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. However Security Association Payload must
be set as following.
SA Payload
Next Payload:
TAHI Project TECHNICAL DOCUMENT
Ni (10)
398
KINK Test Specification
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
TAHI Project TECHNICAL DOCUMENT
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
P (2)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
NONE (0)
0
the actual length of this payload in octets
2
PROTO_IPSEC_AH (2)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
AH_SHA (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
399
KINK Test Specification
Attribute Value:
HMAC-SHA (2)
In addition, Data Attributes in Transform payload can be placed in any order
excepting that SA Life Duration Data Attribute is always follow SA Life Type
Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #4 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5 to TN1.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- If NUT doesn't support Protocol ID required in Proposal #2, NUT can use any other
Protocol IDs other than Proposal #1.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
400
KINK Test Specification
SGW.SGW.I.2.6: The non-optimistic proposal is selected from multiple proposals
Purpose:
Verify that a node properly processes 3-way handshake when the responder selects
the non-optimistic proposal from proposed multiple proposals
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.1
- [KINK] - Section 5.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
In addition, configure NUT to propose with multiple
Transform payloads as described below.
Proposal #
1
2
Protocol ID
PROTO_IPSEC_AH (2)
PROTO_IPSEC_ESP (3)
Proposal #2 will be selected by TN1.
IPsec encryption algorithm
ESP_3DES (3)
IPsec authentication algorithm
AH_SHA (3)
HMAC-SHA (2)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
TAHI Project TECHNICAL DOCUMENT
401
KINK Test Specification
Procedure:
NUT (SGW)
initiator
TN1 (SGW)
responder
CREATE, AP_REQ,
E{ISAKMP(SA(P1(T), P2(T)), Ni, IDi, IDr)}
Judgment #1
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P2(T)), Nr, IDi, IDr)}
Packet #1
Judgment #2
ACK, AP_REQ
IPsec ESP tunnel
TH1 (Host)
TH2 (Host)
Pkt #2/Jdg #3
ICMPv6 Echo Request
Pkt #3/Jdg #4
ICMPv6 Echo Reply
Part A: (ADVANCED)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #2.
4. Observe the packets transmitted by the NUT on Link A.
5. After observing ACK, TN1 transmits ICMPv6 Echo Request encrypted by ESP
described as Common Transmitted Packet #3.
6. Observe the packets transmitted by the NUT on Link B.
7. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
8. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. However Security Association Payload must
be set as following.
TAHI Project TECHNICAL DOCUMENT
402
KINK Test Specification
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
TAHI Project TECHNICAL DOCUMENT
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
P (2)
0
the actual length of this payload in octets
1
PROTO_IPSEC_AH (2)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
AH_SHA (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
NONE (0)
0
the actual length of this payload in octets
2
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
403
KINK Test Specification
Attribute Format:
Attribute Type:
Attribute Value:
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
In addition, Data Attributes in Transform payload can be placed in any order
excepting that SA Life Duration Data Attribute is always follow SA Life Type
Data Attribute.
Step 4: (Judgment #2)
The NUT must respond to REPLY with ACK described as Common Observed
Packet #3.
Step 6: (Judgment #3)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #4 and forward to TH1.
Step 8: (Judgment #4)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5 to TN1.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- If NUT doesn't support Protocol ID required in Proposal #1, NUT can use any other
Protocol IDs other than Proposal #2.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
404
KINK Test Specification
Group 3: Perfect Forward Secrecy
Scope:
The initiator usually begins a negotiation expecting a 2-way handshake, but 3-way
handshake is expected from the beginning when and only when the initiator uses a KE
payload.
The following tests cover 3-way handshake by adding KE payload.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation proposes to use the perfect forward
secrecy (PFS).
TAHI Project TECHNICAL DOCUMENT
405
KINK Test Specification
SGW.SGW.I.3.1: PFS
Purpose:
Verify that an initiator properly processes 3-way handshake when the initiator
requires to use PFS
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.7
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration with enabling PFS.
DH group is 1024 MODP Group (2).
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
406
KINK Test Specification
TN1 (SGW)
responder
NUT (SGW)
initiator
Judgment #1
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, KE, IDi, IDr)}
Packet #1
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T)), Nr, KE, IDi, IDr)}
Judgment #2
ACK, AP_REQ
IPsec ESP tunnel
TH1 (Host)
TH2 (Host)
Pkt #2/Jdg #3
ICMPv6 Echo Request
Pkt #3/Jdg #4
ICMPv6 Echo Reply
Part A: (ADVANCED)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #2.
However KINK_ISAKMP Payload must be set as following.
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
TAHI Project TECHNICAL DOCUMENT
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Nr (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
0x10000000
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
407
KINK Test Specification
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Nr Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
KE Payload
Next Payload:
RESERVED:
Payload Length:
Key Exchange Data
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Group Description (3)
1024 MODP Group (2)
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
KE (4)
0
the actual length of this payload in octets
8 bytes length random data
IDi (5)
0
the actual length of this payload in octets
DH Group #2 public value
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link B
(Prefix B::/64)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link Y
(Prefix Y::/64)
4. Observe the packets transmitted by the NUT on Link A.
5. After observing ACK, TN1 transmits ICMPv6 Echo Request encrypted by ESP
described as Common Transmitted Packet #3.
6. Observe the packets transmitted by the NUT on Link B.
7. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
8. Observe the packets transmitted by the NUT on Link A.
Observable Results:
TAHI Project TECHNICAL DOCUMENT
408
KINK Test Specification
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. However KINK_ISAKMP Payload must be
set as following.
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
KE Payload
TAHI Project TECHNICAL DOCUMENT
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Group Description (3)
1024 MODP Group (2)
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
KE (4)
0
the actual length of this payload in octets
ANY
409
KINK Test Specification
Next Payload:
RESERVED:
Payload Length:
Key Exchange Data
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDi (5)
0
the actual length of this payload in octets
DH Group #2 public value
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link B
(Prefix B::/64)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link Y
(Prefix Y::/64)
Data Attributes in Transform payload can be placed in any order excepting that
SA Life Duration Data Attribute is always follow SA Life Type Data Attribute.
Step 4: (Judgment #2)
The NUT must respond to REPLY with ACK described as Common Observed
Packet #3.
Step 6: (Judgment #3)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #4 and forward to TH1.
Step 8: (Judgment #4)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5 to TN1.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
410
KINK Test Specification
TAHI Project TECHNICAL DOCUMENT
411
KINK Test Specification
Group 4: Rekeying
Scope:
Unlike IKE, the initiator of KINK exchange has the responsibility for rekeying the SA.
The following tests cover CREATE message flow when the SA lifetime expires.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation rekeys SA.
TAHI Project TECHNICAL DOCUMENT
412
KINK Test Specification
SGW.SGW.I.4.1: Initiating Rekeying
Purpose:
Verify that a node properly processes rekeying
References:
- [KINK] - Section 3.6
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
TN1 will respond with 30 seconds SA Life Duration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
413
KINK Test Specification
NUT (SGW)
initiator
TN1 (SGW)
responder
CREATE, AP_REQ,
E{ISAKMP(SA(P(SPIi1, T)), Ni, IDi, IDr)}
Judgment #1
REPLY, AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), IDi, IDr)}
Packet #1
IPsec ESP(SPIi) tunnel
TH1 (Host)
TH2 (Host)
ICMPv6
Echo Request
ICMPv6
Echo Reply
Pkt #2/Jdg #2
Pkt #3/Jdg #3
IPsec ESP(SPIr) tunnel
(repeat
until initiator’s
soft lifetime
expires)
IPsec ESP(SPIi) tunnel
ICMPv6
Echo Request
ICMPv6
Echo Reply
Pkt #4/Jdg #4
Pkt #5/Jdg #5
IPsec ESP(SPIr) tunnel
(Rekeying)
Judgment #6
CREATE, AP_REQ,
E{ISAKMP(SA(P(SPIi2, T)), Ni, IDi, IDr)}
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #1.
However Attribute Value in SA Life Duration Data Attribute
must be set to 30 seconds.
4. After responding to CREATE, TN1 transmits ICMPv6 Echo Request
encrypted by ESP described as Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
8. Repeat Steps 4 and 7 for 30 seconds with the interval value of 1 second.
TAHI Project TECHNICAL DOCUMENT
414
KINK Test Specification
ICMPv6 Sequence Number should be incremented in each of transmitted
packets.
While transmitting ICMPv6 Echo Request and Echo Reply, observe
the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. SPI in Proposal Payload must be updated to
establish new SA.
Data Attributes in Transform payload can be placed in any
order excepting that SA Life Duration Data Attribute is always follow SA Life
Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #4 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5 to TN1.
Step 8: (Judgment #4)
The NUT must newly transmit properly formatted CREATE message described
as Common Observed Packet #1 or 2.
Data Attributes in Transform payload can
be placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
415
KINK Test Specification
TAHI Project TECHNICAL DOCUMENT
416
KINK Test Specification
Group 5: DELETE Message Flow
Scope:
The DELETE command deletes existing SAs.
The following tests cover the DELETE
message flows when the KINK implementation initiates these exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation initiates DELETE message flows.
There are no tests in this group because initiating DELETE message flow is defined as
untested item in this document.
TAHI Project TECHNICAL DOCUMENT
417
KINK Test Specification
Group 6: Dead Peer Detection
Scope:
The STATUS flow is used to send any information to a peer or to elicit any information
from a peer.
A STATUS command is also used as a means of dead peer detection. The
following tests cover the STATUS message flows when the KINK implementation
initiates these exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation initiates STATUS message flows.
TAHI Project TECHNICAL DOCUMENT
418
KINK Test Specification
SGW.SGW.I.6.1: Initiating Liveness Check
Purpose:
Verify that a node properly processes a dead peer detection
References:
- [KINK] - Section 3.4
- [KINK] - Section 3.7
- [KINK] - Section 6.5
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
419
KINK Test Specification
NUT (SGW)
initiator
TR1 (Router)
TN1 (SGW)
responder
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Judgment #1
REPLY, AP_REP,
E{ISAKMP(SA(P(T)), IDi, IDr)}
Packet #1
IPsec ESP tunnel
TH1 (Host)
TH2 (Host)
Pkt #2/Jdg #2
ICMPv6 Echo Request
Pkt #3/Jdg #3
ICMPv6 Echo Reply
ICMPv6 Destination Unreachable
(Address unreachable)
Packet #4
Judgment #4
STATUS, AP_REQ
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #1.
4. After responding to CREATE, TN1 transmits ICMPv6 Echo Request
encrypted by ESP described as Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
8. TR1 responds to ICMPv6 Echo Reply with ICMPv6 Destination Unreachable
described as Common Transmitted Packet #7.
9. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
TAHI Project TECHNICAL DOCUMENT
420
KINK Test Specification
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #4 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5 to TN1.
Step 9: (Judgment #4)
The NUT must transmit properly formatted STATUS message described as
Common Observed Packet #6.
However XID should be updated from the value
in CREATE transmitted at Step 1.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
421
KINK Test Specification
Group 7: GETTGT Message Flow
Scope:
GETTGT flow is used to retrieve a TGT from the remote peer in User-to-User
authentication mode. The following tests cover the GETTGT message flows when the
KINK implementation initiates these exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation uses User-to-User authentication
mode.
TAHI Project TECHNICAL DOCUMENT
422
KINK Test Specification
SGW.SGW.I.7.1: Sending GETTGT Message
Purpose:
Verify that an initiator transmits GETTGT message in properly format
References:
- [KINK] - Section 3.1
- [KINK] - Section 6.6
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration with enabling User-to-User authentication.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
Both
TN1 and NUT must obtain TGT from their KDC.
Procedure:
Part A: (ADVANCED)
TAHI Project TECHNICAL DOCUMENT
423
KINK Test Specification
1. NUT starts to negotiate with TN1 by using User-to-User authentication.
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted GETTGT message described as
Common Observed Packet #7.
Possible Problems:
- None
TAHI Project TECHNICAL DOCUMENT
424
KINK Test Specification
SGW.SGW.I.7.2: GETTGT Message Flow
Purpose:
Verify that a node properly retrieve a TGT from the remote peer in User-to-User
authentication mode
References:
- [KINK] - Section 3.1
- [KINK] - Section 6.6
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration with enabling User-to-User authentication.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
Both
TN1 and NUT must obtain TGT from their KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
425
KINK Test Specification
NUT (SGW)
initiator
TN1 (SGW)
responder
Judgment #1
TN2 (KDC)
GETTGT, TGT_REQ
Packet #1
REPLY, TGT_REP
(Kerberos specific procedure)
Kerberos (TGS-REQ)
(Kerberos specific procedure)
Kerberos (TGS-REP)
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Judgment #2
REPLY, AP_REP,
E{ISAKMP(SA(P(T)), IDi, IDr)}
Packet #2
IPsec ESP tunnel
TH1 (Host)
TH2 (Host)
Pkt #3/Jdg #3
ICMPv6 Echo Request
Pkt #4/Jdg #4
ICMPv6 Echo Reply
Part A: (ADVANCED)
1. NUT starts to negotiate with TN1 by using User-to-User authentication.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to GETTGT with REPLY described as Common Transmitted
Packet #6.
4. Observe the packets transmitted by the NUT on Link A.
5. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #1.
6. After responding to CREATE, TN1 transmits ICMPv6 Echo Request
encrypted by ESP described as Common Transmitted Packet #3.
7. Observe the packets transmitted by the NUT on Link B.
8. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
9. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
TAHI Project TECHNICAL DOCUMENT
426
KINK Test Specification
The NUT must transmit properly formatted GETTGT message described as
Common Observed Packet #7.
Step 4: (Judgment #2)
After the NUT obtains a service ticket for TN1 from TN2, the NUT must transmit
properly formatted CREATE message described as Common Observed Packet #1
or 2.
Data Attributes in Transform payload can be placed in any order excepting
that SA Life Duration Data Attribute is always follow SA Life Type Data
Attribute.
Step 7: (Judgment #3)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #4 and forward to TH1.
Step 9: (Judgment #4)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5 to TN1.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
427
KINK Test Specification
SGW.SGW.I.7.3: Receipt of KINK_TGT_REP against a KINK command with a
User-to-User ticket that cannot be decrypted with its TGT
Purpose:
Verify that a node properly recovers dead user-to-user peer
References:
- [KINK] - Subsection 3.7.1
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration with enabling User-to-User authentication.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
Both
TN1 and NUT must obtain TGT from their KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
428
KINK Test Specification
TN1 (SGW)
responder
NUT (SGW)
initiator
Judgment #1
Packet #1
TN2 (KDC)
GETTGT, TGT_REQ
REPLY, TGT_REP(TGTr1)
(Kerberos specific procedure)
Kerberos (TGS-REQ)
(Kerberos specific procedure)
Kerberos (TGS-REP)
Judgment #2
CREATE, AP_REQ, E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Packet #1
REPLY, TGT_REP(TGTr2)
(Kerberos specific procedure)
Kerberos (TGS-REQ)
(Kerberos specific procedure)
Kerberos (TGS-REP)
Judgment #3
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Part A: (ADVANCED)
1. NUT starts to negotiate with TN1 by using User-to-User authentication.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to GETTGT with REPLY described as Common Transmitted
Packet #6.
4. Observe the packets transmitted by the NUT on Link A.
5. TN1 responds to CREATE with REPLY, but the packet format is the same as
REPLY for GETTGT described as Common Transmitted Packet #6.
However
TGT is newly obtained from TN2.
6. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted GETTGT message described as
Common Observed Packet #7.
TAHI Project TECHNICAL DOCUMENT
429
KINK Test Specification
Step 4: (Judgment #2)
After the NUT obtains a service ticket for TN1 from TN2, the NUT must transmit
properly formatted CREATE message described as Common Observed Packet #1
or 2.
Data Attributes in Transform payload can be placed in any order excepting
that SA Life Duration Data Attribute is always follow SA Life Type Data
Attribute.
Step 6: (Judgment #3)
After the NUT newly obtains a service ticket for TN1 from TN2 again, the NUT
must transmit properly formatted CREATE message described as Common
Observed Packet #1 or 2.
Data Attributes in Transform payload can be placed in
any order excepting that SA Life Duration Data Attribute is always follow SA Life
Type Data Attribute.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
430
KINK Test Specification
Group 8: Retransmission
Scope:
KINK implementation must retransmit the request using timer T when this message
expects a response.
The following tests cover the retransmission mechanism.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation retransmits KINK messages.
TAHI Project TECHNICAL DOCUMENT
431
KINK Test Specification
SGW.SGW.I.8.1: Retransmission of CREATE
Purpose:
Verify that a node properly retransmit CREATE message
References:
- [KINK] – Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
432
KINK Test Specification
NUT (SGW)
initiator
TN1 (SGW)
responder
Judgment #1
CREATE(XIDi1), AP_REQ(AP-REQ1),
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
(T expires)
(Retransmission)
Judgment #2
CREATE(XIDi1), AP_REQ(AP-REQ2),
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. After NUT transmits CREATE, observe the packets transmitted by the NUT
on Link A until the timer T expires.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 3: (Judgment #2)
The NUT must retransmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
TAHI Project TECHNICAL DOCUMENT
433
KINK Test Specification
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TLV (0)
SA Life Duration (2)
ANY
28,800
- A timer T may be implemented with implementation's local policy. The tester must
consider the timer T configurable parameter.
TAHI Project TECHNICAL DOCUMENT
434
KINK Test Specification
SGW.SGW.I.8.2: Stop the retransmission of CREATE
Purpose:
Verify that a node properly stops the retransmission of CREATE message
References:
- [KINK] – Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
435
KINK Test Specification
NUT (SGW)
initiator
TN1 (SGW)
responder
Judgment #1
CREATE(XIDi1), AP_REQ(AP-REQ1),
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
(T expires)
(Retransmission)
Judgment #2
Packet #1
CREATE(XIDi1), AP_REQ(AP-REQ2),
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
REPLY(XIDi), AP_REP,
E{ISAKMP(SA(P(T)), IDi, IDr)}
(T*2 expires)
Judgment #3
No response
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. After NUT transmits first CREATE, observe the packets transmitted by the
NUT on Link A until the timer T expires.
4. TN1 responds to second CREATE with REPLY described as Common
Transmitted Packet #1.
5. Observe the packets transmitted by the NUT on Link A until doubled T
expires.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 3: (Judgment #2)
The NUT must retransmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
TAHI Project TECHNICAL DOCUMENT
436
KINK Test Specification
Step 5: (Judgment #3)
The NUT never retransmit CREATE message because message exchange had
been completed at Step 5.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TLV (0)
SA Life Duration (2)
ANY
28,800
- A timer T may be implemented with implementation's local policy. The tester must
consider the timer T configurable parameter.
TAHI Project TECHNICAL DOCUMENT
437
KINK Test Specification
SGW.SGW.I.8.3: Responding to retransmitted REPLY with the ACKREQ bit set
Purpose:
Verify that a node properly retransmit REPLY message
References:
- [KINK] - Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
438
KINK Test Specification
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #2.
4. Observe the packets transmitted by the NUT on Link A.
5. After observing ACK, TN1 transmits REPLY described as Common
Transmitted Packet #2 again.
6. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 4: (Judgment #2)
The NUT must respond to REPLY with ACK described as Common Observed
Packet #3.
Step 6: (Judgment #3)
The NUT must respond to REPLY with ACK described as Common Observed
Packet #3 again.
TAHI Project TECHNICAL DOCUMENT
439
KINK Test Specification
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
440
KINK Test Specification
SGW.SGW.I.8.4: Retransmission of STATUS
Purpose:
Verify that a node properly retransmit STATUS message
References:
- [KINK] – Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
441
KINK Test Specification
TN1 (SGW)
responder
TR1 (Router)
NUT (SGW)
initiator
CREATE(XIDi1), AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Judgment #1
REPLY(XIDi1), AP_REP,
E{ISAKMP(SA(P(T)), IDi, IDr)}
Packet #1
IPsec ESP tunnel
TH1 (Host)
TH2 (Host)
Pkt #2/Jdg #2
ICMPv6 Echo Request
Pkt #3/Jdg #3
ICMPv6 Echo Reply
ICMPv6 Destination Unreachable
(Address unreachable)
Packet #4
Judgment #4
STATUS(XIDi2), AP_REQ(AP-REQ1)
(T expires)
(Retransmission)
Judgment #5
STATUS(XIDi2), AP_REQ(AP-REQ2)
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #1.
4. After responding to CREATE, TN1 transmits ICMPv6 Echo Request
encrypted by ESP described as Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
8. TR1 responds to ICMPv6 Echo Reply with ICMPv6 Destination Unreachable
described as Common Transmitted Packet #7.
9. Observe the packets transmitted by the NUT on Link A.
10. After NUT transmits STATUS, observe the packets transmitted by the NUT
on Link A until the timer T expires.
Observable Results:
TAHI Project TECHNICAL DOCUMENT
442
KINK Test Specification
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #4 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5 to TN1.
Step 9: (Judgment #4)
The NUT must transmit properly formatted STATUS message described as
Common Observed Packet #6.
Step 10: (Judgment #5)
The NUT must retransmit properly formatted STATUS message described as
Common Observed Packet #6.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TLV (0)
SA Life Duration (2)
ANY
28,800
- A timer T may be implemented with implementation's local policy. The tester must
consider the timer T configurable parameter.
TAHI Project TECHNICAL DOCUMENT
443
KINK Test Specification
SGW.SGW.I.8.5: Stop the retransmission of STATUS
Purpose:
Verify that a node properly stops the retransmission of STATUS message
References:
- [KINK] – Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
444
KINK Test Specification
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #1.
4. After responding to CREATE, TN1 transmits ICMPv6 Echo Request
encrypted by ESP described as Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
8. TR1 responds to ICMPv6 Echo Reply with ICMPv6 Destination Unreachable
described as Common Transmitted Packet #7.
9. Observe the packets transmitted by the NUT on Link A.
10. After NUT transmits first STATUS, observe the packets transmitted by the
TAHI Project TECHNICAL DOCUMENT
445
KINK Test Specification
NUT on Link A until the timer T expires.
11. TN1 responds to second STATUS with REPLY described as Common
Transmitted Packet #5.
12. Observe the packets transmitted by the NUT on Link A until doubled T
expires.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #4 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5 to TN1.
Step 9: (Judgment #4)
The NUT must transmit properly formatted STATUS message described as
Common Observed Packet #6.
Step 10: (Judgment #5)
The NUT must retransmit properly formatted STATUS message described as
Common Observed Packet #6.
Step 12: (Judgment #6)
The NUT never retransmit STATUS message because message exchange had
been completed at Step 11.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
TAHI Project TECHNICAL DOCUMENT
446
KINK Test Specification
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TLV (0)
SA Life Duration (2)
ANY
28,800
- A timer T may be implemented with implementation's local policy. The tester must
consider the timer T configurable parameter.
TAHI Project TECHNICAL DOCUMENT
447
KINK Test Specification
SGW.SGW.I.8.6: Retransmission of GETTGT
Purpose:
Verify that a node properly retransmit GETTGT message
References:
- [KINK] – Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration with enabling User-to-User authentication.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
Both
TN1 and NUT must obtain TGT from their KDC.
Procedure:
NUT (SGW)
initiator
TN1 (SGW)
responder
Judgment #1
GETTGT, TGT_REQ
(T expires)
(Retransmission)
Judgment #2
GETTGT, TGT_REQ
TAHI Project TECHNICAL DOCUMENT
448
KINK Test Specification
Part A: (ADVANCED)
1. NUT starts to negotiate with TN1 by using User-to-User authentication.
2. Observe the packets transmitted by the NUT on Link A.
3. After NUT transmits GETTGT, observe the packets transmitted by the NUT
on Link A until the timer T expires.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted GETTGT message described as
Common Observed Packet #7.
Step 3: (Judgment #2)
The NUT must retransmit properly formatted GETTGT message described as
Common Observed Packet #7.
Possible Problems:
- A timer T may be implemented with implementation's local policy. The tester must
consider the timer T configurable parameter.
TAHI Project TECHNICAL DOCUMENT
449
KINK Test Specification
SGW.SGW.I.8.7: Stop the retransmission of GETTGT
Purpose:
Verify that a node properly stops the retransmission of GETTGT message
References:
- [KINK] – Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration with enabling User-to-User authentication.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
Both
TN1 and NUT must obtain TGT from their KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
450
KINK Test Specification
NUT (SGW)
initiator
TN1 (SGW)
responder
Judgment #1
GETTGT, TGT_REQ
(T expires)
(Retransmission)
Judgment #2
Packet #1
GETTGT, TGT_REQ
REPLY, TGT_REP
(T*2 expires)
Judgment #3
No response
Part A: (ADVANCED)
1. NUT starts to negotiate with TN1 by using User-to-User authentication.
2. Observe the packets transmitted by the NUT on Link A.
3. After NUT transmits first GETTGT, observe the packets transmitted by the
NUT on Link A until the timer T expires.
4. TN1 responds to second GETTGT with REPLY described as Common
Transmitted Packet #6.
5. Observe the packets transmitted by the NUT on Link A until doubled T
expires.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted GETTGT message described as
Common Observed Packet #7.
Step 3: (Judgment #2)
The NUT must retransmit properly formatted GETTGT message described as
Common Observed Packet #7.
Step 5: (Judgment #3)
The NUT never retransmit GETTGT message because message exchange had
been completed at Step 4.
Possible Problems:
TAHI Project TECHNICAL DOCUMENT
451
KINK Test Specification
- A timer T may be implemented with implementation's local policy. The tester must
consider the timer T configurable parameter.
TAHI Project TECHNICAL DOCUMENT
452
KINK Test Specification
SGW.SGW.I.8.8: Restart a new transaction by receipt of
KRB_AP_ERR_TKT_EXPIRED
Purpose:
Verify that a node properly starts a new transaction with a new ticket when the node
receives the error indicating ticket expired
References:
- [KINK] – Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
453
KINK Test Specification
NUT (SGW)
initiator
TN1 (SGW)
responder
Judgment #1
Packet #1
CREATE(XIDi1), AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
REPLY, KRB_ERROR(KRB_AP_ERR_TKT_EXPIRED)
TN2 (KDC)
(Kerberos specific procedure)
Kerberos (TGS-REQ)
(Kerberos specific procedure)
Kerberos (TGS-REP)
Judgment #2
CREATE(XIDi2), AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with KRB_ERROR described as following.
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
REPLY (3)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
the same value as GETTGT message
NextPayload:
KINK_KRB_ERROR (3)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_KRB_ERROR Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
KRB-ERROR:
raw Kerberos KRB-ERROR
indicating KRB_AP_ERR_TKT_EXPIRED
4. Observe the packets transmitted by the NUT on Link A.
Observable Results:
TAHI Project TECHNICAL DOCUMENT
454
KINK Test Specification
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 4: (Judgment #2)
After the NUT obtains a service ticket for TN1 from TN2, The NUT must newly
transmit properly formatted CREATE message described as Common Observed
Packet #1 or 2.
Data Attributes in Transform payload can be placed in any order
excepting that SA Life Duration Data Attribute is always follow SA Life Type
Data Attribute.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
455
KINK Test Specification
Group 9: Message Validation
Scope:
The following tests cover the message validation.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation processes of suspicious messages.
TAHI Project TECHNICAL DOCUMENT
456
KINK Test Specification
SGW.SGW.I.9.1: Responding to KINK_ERROR with the ACKREQ bit set
Purpose:
Verify that a node properly responds to an error message that the ACKREQ bit is set
with ACK message
References:
- [KINK] - Section 3.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
457
KINK Test Specification
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as following.
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
REPLY (3)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
the same value as CREATE message
NextPayload:
KINK_ERROR (8)
ACKREQ:
true (1)
RESERVED2:
0
CksumLen:
0
KINK_ ERROR Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
ErrorCode:
KINK_INTERR (5)
4. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
TAHI Project TECHNICAL DOCUMENT
KINK Test Specification
458
follow SA Life Type Data Attribute.
Step 4: (Judgment #2)
The NUT must respond to REPLY with ACK described as Common Observed
Packet #3.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
459
KINK Test Specification
SGW.SGW.I.9.2: Receipt of REPLY with non-zero value in reserved field
Purpose:
Verify that a node properly ignores reserved field in REPLY message
References:
- [KINK] – Chapter 4
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
460
KINK Test Specification
NUT (SGW)
initiator
TN1 (SGW)
responder
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Judgment #1
REPLY, AP_REP,
E{ISAKMP(SA(P(T)), IDi, IDr)}
Packet #1
IPsec ESP tunnel
TH1 (Host)
TH2 (Host)
Pkt #2/Jdg #2
ICMPv6 Echo Request
Pkt #3/Jdg #3
ICMPv6 Echo Reply
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #1. However Reserved Field in CREATE message must be set as
following.
KINK
RESRVED:
0xf
RESERVED2:
0x7f
KINK_AP_REP Payload
RESERVED:
0xff
KINK_ENCRYPT Payload
RESERVED:
0xff
RESERVED2:
0xffffff
KINK_ISAKMP Payload
RESERVED: 0xff
RESERVED: 0xffff
4. After responding to CREATE, TN1 transmits ICMPv6 Echo Request
encrypted by ESP described as Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
Observable Results:
TAHI Project TECHNICAL DOCUMENT
461
KINK Test Specification
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #4 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5 to TN1.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
462
KINK Test Specification
SGW.SGW.I.9.3: Receipt of unencrypted REPLY
Purpose:
Verify that a node properly processes REPLY message which doesn't encrypted by
KINK_ENCRYPT payload
References:
- [KINK] - Section 6.3
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
463
KINK Test Specification
NUT (SGW)
initiator
TN1 (SGW)
responder
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Judgment #1
Packet #1
REPLY, AP_REP, ISAKMP(SA(P(T)), IDi, IDr)
IPsec ESP tunnel
TH1 (Host)
TH2 (Host)
Pkt #2/Jdg #2
ICMPv6 Echo Request
Pkt #3/Jdg #3
ICMPv6 Echo Reply
Part A: (BASIC)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #1.
However KINK_ENCRYPT Payload must not appear as described
as following.
KINK
KINK_AP_REP Payload
KINK_ISAKMP Payload
SA Payload
P Payload
T Payload
Data Attribute
Data Attribute
Data Attribute
Data Attribute
IDi Payload
IDr Payload
4. After responding to CREATE, TN1 transmits ICMPv6 Echo Request
encrypted by ESP described as Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
TAHI Project TECHNICAL DOCUMENT
464
KINK Test Specification
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #4 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #5 to TN1.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
465
KINK Test Specification
SGW.SGW.I.9.4: Receipt of authenticated KRB_AP_ERR_SKEW
Purpose:
Verify that a node properly adjust clock by the receipt of protected
KRB_AP_ERR_SKEW
References:
- [KINK] - Section 3.5
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
466
KINK Test Specification
NUT (SGW)
initiator
TN1 (SGW)
responder
(push TN’s clock forward 6 minutes)
Judgment #1
Packet #1
CREATE, AP_REQ(EPOCHi1),
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
REPLY, AP_REP,
E{KRB_ERROR(KRB_AP_ERR_SKEW)}
(Reinitiating)
Judgment #2
CREATE, AP_REQ(EPOCHi2),
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Part A: (BASIC)
1. Set the clock forward 6 minutes on TN1.
2. NUT starts to negotiate with TN1 by sending CREATE message.
3. Observe the packets transmitted by the NUT on Link A.
4. TN1 responds to CREATE with KRB_ERROR described as following.
The
shaded region in the figure is encrypted by Kerberos encrypt function with
Key Usage Number 39 (KINK_ENCRYPT payload).
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
REPLY (3)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
the same value as CREATE message
NextPayload:
KINK_AP_REP (2)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_AP_REP Payload
Next Payload:
KINK_ENCRYPT (7)
RESERVED:
0
Payload Length:
the actual length of this payload in octets
EPOCH:
the current POSIX time
AP-REP:
raw data of Kerberos AP-REP
KINK_ENCRYPT Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length:
the actual length of this payload in octets
InnerNextPload:
KINK_KRB_ERROR (3)
RESERVED2:
0
TAHI Project TECHNICAL DOCUMENT
467
KINK Test Specification
KINK_KRB_ERROR Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
KRB-ERROR:
raw Kerberos KRB-ERROR
indicating KRB_AP_ERR_SKEW
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
5. NUT starts to negotiate with TN1 by sending CREATE message again.
6. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 3: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 6: (Judgment #2)
The NUT adjusts system clock to the time noticed by KRB-ERROR message.
And the NUT must newly transmit properly formatted CREATE message
described as Common Observed Packet #1 or 2. EPOCH in KINK_AP_REQ
Payload must be computed with the newly updated system clock.
Data
Attributes in Transform payload can be placed in any order excepting that SA
Life Duration Data Attribute is always follow SA Life Type Data Attribute.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
468
KINK Test Specification
SGW.SGW.I.9.5: Receipt of unauthenticated KRB_AP_ERR_SKEW
Purpose:
Verify that a node properly does not adjust clock by the receipt of unprotected
KRB_AP_ERR_SKEW
References:
- [KINK] - Section 3.5
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
469
KINK Test Specification
NUT (SGW)
initiator
TN1 (SGW)
responder
(push TN’s clock forward 6 minutes)
Judgment #1
Packet #1
CREATE, AP_REQ(EPOCHi1),
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
REPLY, AP_REP,
E{KRB_ERROR(KRB_AP_ERR_SKEW)}
(Reinitiating)
Judgment #2
CREATE, AP_REQ(EPOCHi2),
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Part A: (BASIC)
1. Set the clock forward 6 minutes on TN1.
2. NUT starts to negotiate with TN1 by sending CREATE message.
3. Observe the packets transmitted by the NUT on Link A.
4. TN1 responds to CREATE with KRB_ERROR described as following.
The
shaded region in the figure is encrypted by Kerberos encrypt function with
Key Usage Number 39 (KINK_ENCRYPT payload).
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
REPLY (3)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
the same value as CREATE message
NextPayload:
KINK_AP_REP (2)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_AP_REP Payload
Next Payload:
KINK_ENCRYPT (7)
RESERVED:
0
Payload Length:
the actual length of this payload in octets
EPOCH:
the current POSIX time
AP-REP:
raw data of Kerberos AP-REP
KINK_ENCRYPT Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
TAHI Project TECHNICAL DOCUMENT
470
KINK Test Specification
Payload Length:
the actual length of this payload in octets
InnerNextPload:
KINK_KRB_ERROR (3)
RESERVED2:
0
KINK_KRB_ERROR Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
KRB-ERROR:
raw Kerberos KRB-ERROR
indicating KRB_AP_ERR_SKEW
5. NUT starts to negotiate with TN1 by sending CREATE message again.
6. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 3: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 6: (Judgment #2)
The NUT never adjusts system clock to the time noticed by KRB-ERROR
message.
And the NUT must newly transmit properly formatted CREATE
message described as Common Observed Packet #1 or 2, but EPOCH in
KINK_AP_REQ Payload is still computed without updating the system clock.
Data Attributes in Transform payload can be placed in any order excepting that
SA Life Duration Data Attribute is always follow SA Life Type Data Attribute.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
471
KINK Test Specification
TAHI Project TECHNICAL DOCUMENT
472
KINK Test Specification
Subsection 2.1.2: Responder
Scope:
In KINK exchanges, either of endpoints initiates the exchange by sending the command
and the another responds to this command with the response.
The following tests
cover KINK exchanges when the KINK implementation responds to these exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation initiates KINK exchanges.
Default Packets:
Packets sent from TN:
Common Packets to be transmitted from TN are defined as the following. Tests in
this test group may refer to these packets.
Common Transmitted Packet #1: CREATE
IPv6
Next Header:
Source Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REQ Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REQ:
TAHI Project TECHNICAL DOCUMENT
kink (910)
kink (910)
CREATE (1)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
0
KINK_AP_REQ (1)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REQ
473
KINK Test Specification
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
0x10000000
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
8 bytes length random data
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link Y
(Prefix Y::/64)
IDr Payload
TAHI Project TECHNICAL DOCUMENT
474
KINK Test Specification
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link B
(Prefix B::/64)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
* The shaded region in Common Transmitted Packet #1 is encrypted by
Kerberos encrypt function with Key Usage Number 39 (KINK_ENCRYPT
payload).
Common Transmitted Packet #2: ACK
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
ACK (5)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
0
NextPayload:
KINK_AP_REQ (1)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_AP_REQ Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
EPOCH:
the same value as CREATE message
AP-REQ:
raw data of Kerberos AP-REQ
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Common Transmitted Packet #3: IPsec ESP { ICMPv6 Echo Request }
IPv6
Next Header:
Source Address:
Destination Address:
ESP
SPI:
Sequence Number:
TAHI Project TECHNICAL DOCUMENT
ESP (50)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
proposed by REPLY from NUT
in CREATE Message Flow
1
475
KINK Test Specification
IV:
8 bytes length stream
that all bits are set to zero
IPv6
Next Header:
Source Address:
IPv6-ICMP (58)
TH2 - Link Y
(Prefix Y::c)
TH1 - Link B
(Prefix B::d)
Destination Address:
ICMPv6
Type:
Code:
Checksum:
Identifier:
Sequence Number:
Data:
Padding:
Pad Length:
Next Header:
ICV:
Echo Request (128)
0
ICMPv6 checksum
0
0
8 bytes length stream
that all bits are set to zero
ANY
the actual length of Pad in octets
IPv6 (41)
calculated by HMAC-SHA1-96
using calculated KEYMAT
* The shaded region in Common Transmitted Packet #3 is encrypted by
TripleDES in CBC mode using calculated KEYMAT.
Common Transmitted Packet #4: ICMPv6 Echo Reply
IPv6
Next Header:
Source Address:
IPv6-ICMP (58)
TH1 - Link B
(Prefix B::d)
TH2 - Link Y
(Prefix Y::c)
Destination Address:
ICMPv6
Type:
Code:
Checksum:
Identifier:
Sequence Number:
Data:
Echo Reply (129)
0
ICMPv6 checksum
0
0
8 bytes length stream
that all bits are set to zero
Common Transmitted Packet #5: DELETE
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
kink (910)
kink (910)
DELETE (2)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
476
KINK Test Specification
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REQ Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REQ:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
D Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-Id:
SPI Size:
# of SPIs
SPI #1
Cksum:
1
KINK_AP_REQ (1)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as CREATE message
raw data of Kerberos AP-REQ
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
D (12)
1
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
4
1
proposed by REPLY from NUT
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
* The shaded region in Common Transmitted Packet #5 is encrypted by
Kerberos encrypt function with Key Usage Number 39 (KINK_ENCRYPT
payload).
Common Transmitted Packet #6: STATUS
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
kink (910)
kink (910)
STATUS (6)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REQ (1)
false (0)
477
KINK Test Specification
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_AP_REQ Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
EPOCH:
the same value as CREATE message
AP-REQ:
raw data of Kerberos AP-REQ
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Common Transmitted Packet #7: GETTGT
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
ACK (5)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
0
NextPayload:
KINK_TGT_REQ (4)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_TGT_REQ Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
PrincName:
kink/[email protected]
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Common Transmitted Packet #8: ICMPv6 Destination Unreachable
IPv6
Next Header:
Source Address:
Destination Address:
ICMPv6
Type:
Code:
Checksum:
Unused:
Data:
IPv6-ICMP (58)
TR1 - Link X
(Prefix X::f)
NUT - Link A
(Prefix A::<any_interface_ID>)
Destination Unreachable (1)
Address unreachable (3)
ICMPv6 checksum
0
Common Observed Packet #4
Packets sent from NUT:
Common Packets to be transmitted from NUT are defined as the following. Tests
TAHI Project TECHNICAL DOCUMENT
KINK Test Specification
478
in this test group may refer to these packets.
Common Observed Packet #1: REPLY for CREATE
IPv6
Next Header:
Source Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
TAHI Project TECHNICAL DOCUMENT
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message
Internet IP Security DOI (1)
0
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
IDi (5)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
479
KINK Test Specification
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link Y
(Prefix Y::/64)
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link B
(Prefix B::/64)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
* The shaded region in Common Observed Packet #1 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
Common Observed Packet #2: unencrypted REPLY for CREATE
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
480
KINK Test Specification
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REP:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
TAHI Project TECHNICAL DOCUMENT
the actual length of this message
Internet IP Security DOI (1)
0
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ISAKMP (6)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
IDi (5)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (2)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
481
KINK Test Specification
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
Cksum:
Link Y
(Prefix Y::/64)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link B
(Prefix B::/64)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Common Observed Packet #3: REPLY with Nr for CREATE
IPv6
Next Header:
Source Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
TAHI Project TECHNICAL DOCUMENT
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
0
KINK_AP_REP (2)
true (1)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Nr (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
482
KINK Test Specification
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Nr Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
ANY
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link Y
(Prefix Y::/64)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link B
(Prefix B::/64)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
* The shaded region in Common Observed Packet #3 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
Common Observed Packet #4: unencrypted REPLY with Nr for CREATE
IPv6
TAHI Project TECHNICAL DOCUMENT
483
KINK Test Specification
Next Header:
Source Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REP:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message
Internet IP Security DOI (1)
0
KINK_AP_REP (2)
true (1)
0
the actual length of Cksum
KINK_ISAKMP (6)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Nr (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
484
KINK Test Specification
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Nr Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
ANY
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link Y
(Prefix Y::/64)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link B
(Prefix B::/64)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
Common Observed Packet #5: ICMPv6 Echo Request
IPv6
Next Header:
Source Address:
IPv6-ICMP (58)
TH2 - Link Y
(Prefix Y::c)
TH1 - Link B
(Prefix B::d)
Destination Address:
ICMPv6
Type:
Code:
Checksum:
Identifier:
Sequence Number:
Data:
Echo Request (128)
0
ICMPv6 checksum
0
0
8 bytes length stream
that all bits are set to zero
Common Observed Packet #6: IPsec ESP { ICMPv6 Echo Reply }
IPv6
Next Header:
Source Address:
Destination Address:
ESP
SPI:
Sequence Number:
IV:
IPv6
Next Header:
TAHI Project TECHNICAL DOCUMENT
ESP (50)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
0x10000000
ANY
ANY
IPv6-ICMP (58)
485
KINK Test Specification
Source Address:
TH1 - Link B
(Prefix B::d)
TH2 - Link Y
(Prefix Y::c)
Destination Address:
ICMPv6
Type:
Code:
Checksum:
Identifier:
Sequence Number:
Data:
Padding:
Pad Length:
Next Header:
ICV:
Echo Reply (129)
0
ICMPv6 checksum
0
0
8 bytes length stream
that all bits are set to zero
ANY
the actual length of Pad in octets
IPv6 (41)
calculated by HMAC-SHA1-96
using calculated KEYMAT
* The shaded region in Common Observed Packet #6 is encrypted by TripleDES
in CBC mode using calculated KEYMAT.
Common Observed Packet #7: REPLY for DELETE
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
D (12)
1
486
KINK Test Specification
QMMin:
RESERVED:
D Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-Id:
SPI Size:
# of SPIs
SPI #1
Cksum:
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
4
1
proposed by REPLY from NUT
in CREATE Message Flow
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
* The shaded region in Common Observed Packet #7 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
Common Observed Packet #8: unencrypted REPLY for DELETE
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REP:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
D Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-Id:
SPI Size:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
D (12)
1
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
4
487
KINK Test Specification
# of SPIs
SPI #1
Cksum:
1
proposed by REPLY from NUT
in CREATE Message Flow
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Common Observed Packet #9: REPLY for STATUS
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
REPLY (3)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
0
NextPayload:
KINK_AP_REP (2)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_AP_REP Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
EPOCH:
the same value as REPLY message
in CREATE Message Flow
AP-REP:
raw data of Kerberos AP-REP
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Common Observed Packet #10: REPLY for GETTGT
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
REPLY (3)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
0
NextPayload:
KINK_TGT_REP (5)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_TGT_REP Payload
Next Payload:
KINK_DONE (0)
TAHI Project TECHNICAL DOCUMENT
488
KINK Test Specification
RESERVED:
Payload Length:
TGT:
Cksum:
TAHI Project TECHNICAL DOCUMENT
0
the actual length of this payload in octets
DER-encoded TGT of the responder
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
489
KINK Test Specification
Group 1: CREATE Message Flow
Scope:
In KINK exchanges, either of endpoints initiates the exchange by sending the command
and the another responds to this command with the response.
The following tests
cover the CREATE message flows when the KINK implementation initiates these
exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation responds to CREATE message
flows.
TAHI Project TECHNICAL DOCUMENT
490
KINK Test Specification
SGW.SGW.R.1.1: Receipt of CREATE Message
Purpose:
Verify that an initiator processes CREATE message in properly format
References:
- [KINK] - Section 3.2
- [KINK] - Section 6.3
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
491
KINK Test Specification
NUT (SGW)
responder
TN1 (SGW)
initiator
Packet #1
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
(optimistic proposal, but Nr was added by the responder)
(2-way handshake)
NUT (SGW)
responder
(3-way handshake)
TN1 (SGW)
initiator
NUT (SGW)
responder
Judgment #1
TN1 (SGW)
initiator
Judgment #1
REPLY, AP_REP,
E{ISAKMP(SA(P(T)), IDi, IDr)}
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T)), Nr, IDi, IDr)}
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
TAHI Project TECHNICAL DOCUMENT
492
KINK Test Specification
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
493
KINK Test Specification
SGW.SGW.R.1.2: CREATE Message Flow
Purpose:
Verify that a responder properly establish SA by CREATE message flow
References:
- [KINK] - Section 3.2
- [KINK] - Section 6.3
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
494
KINK Test Specification
NUT (SGW)
responder
TN1 (SGW)
initiator
Packet #1
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
(optimistic proposal, but Nr was added by the responder)
(2-way handshake)
NUT (SGW)
responder
(3-way handshake)
TN1 (SGW)
initiator
NUT (SGW)
responder
Judgment #1
TN1 (SGW)
initiator
Judgment #1
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T)), Nr, IDi, IDr)}
REPLY, AP_REP,
E{ISAKMP(SA(P(T)), IDi, IDr)}
Packet #2
ACK, AP_REQ
TH1 (Host)
NUT (SGW)
responder
TN1 (SGW)
initiator
TH2 (Host)
Pkt #3/Jdg #2
ICMPv6 Echo Request
Pkt #4/Jdg #3
ICMPv6 Echo Reply
IPsec ESP tunnel
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
TAHI Project TECHNICAL DOCUMENT
495
KINK Test Specification
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
496
KINK Test Specification
Group 2: Cryptographic Algorithm Negotiation
Scope:
Creating SAs has two modes -- 2-way handshake and 3-way handshake.
The initiator
usually begins a negotiation expecting a 2-way handshake but the negotiation is
switched to a 3-way handshake when the optimistic proposal is not chosen by the
responder. The following tests cover 2-way handshake and 3-way handshake.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation can switch two modes while the
cryptographic algorithm negotiation.
TAHI Project TECHNICAL DOCUMENT
497
KINK Test Specification
SGW.SGW.R.2.1: Cryptographic Algorithm Negotiation
Purpose:
Verify that a responder properly establish SA with the specific cryptographic
algorithms
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.1
- [KINK] - Section 5.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration, however use Cryptographic Algorithms as described below.
Part
A
B
C
D
E
IPsec encryption algorithm
ESP_NULL (11)
ESP_AES-CBC (12) with 128-bit keys
ESP_AES-CTR (13) with 128-bit keys
ESP_3DES (3)
ESP_3DES (3)
IPsec authentication algorithm
HMAC-SHA (2)
HMAC-SHA (2)
HMAC-SHA (2)
NONE (undefined)
AES-XCBC-MAC (9)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
TAHI Project TECHNICAL DOCUMENT
498
KINK Test Specification
Procedure:
NUT (SGW)
responder
TN1 (SGW)
initiator
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Packet #1
(optimistic proposal, but Nr was added by the responder)
(2-way handshake)
NUT (SGW)
responder
(3-way handshake)
TN1 (SGW)
initiator
NUT (SGW)
responder
Judgment #1
TN1 (SGW)
initiator
Judgment #1
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T)), Nr, IDi, IDr)}
REPLY, AP_REP,
E{ISAKMP(SA(P(T)), IDi, IDr)}
Packet #2
ACK, AP_REQ
TH1 (Host)
NUT (SGW)
responder
TN1 (SGW)
initiator
TH2 (Host)
Pkt #3/Jdg #2
ICMPv6 Echo Request
Pkt #4/Jdg #3
ICMPv6 Echo Reply
IPsec ESP tunnel
Part A through E (ADVANCED)
Part
A
B
C
D
E
IPsec encryption algorithm
NULL
AES-CBC with 128-bit keys
AES-CTR with 128-bit keys
TripleDES-CBC
TripleDES-CBC
IPsec authentication algorithm
HMAC-SHA1-96
HMAC-SHA1-96
HMAC-SHA1-96
NONE
AES-XCBC-MAC-96
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However Transform-ID in Transform payload and Attribute Value in
Authentication Algorithm Data Attribute must be set according to the
corresponding entry of the table above.
Only for Part B and C, following
Data Attribute must be also additionally included in Transform payload.
TAHI Project TECHNICAL DOCUMENT
KINK Test Specification
499
And only for Part D, Authentication Algorithm Data Attribute does not appear
in Transform Payload.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
TV (1)
Key Length (6)
128
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3. However encryption algorithm and
authentication algorithm must be set according to the corresponding entry of
the table above.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A through E:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
However Transform-ID in Transform
payload and Attribute Value in Authentication Algorithm Data Attribute must be
set according to the corresponding entry of the table in the procedure above.
In
addition, Data Attributes in Transform payload can be placed in any order
excepting that SA Life Duration Data Attribute is always follow SA Life Type
Data Attribute.
Only for Part B and C, following Data Attribute must be also
additionally included in Transform payload.
And only for Part D,
Authentication Algorithm Data Attribute must not appear in Transform Payload.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Step 5: (Judgment #2)
TAHI Project TECHNICAL DOCUMENT
500
TV (1)
Key Length (6)
128
KINK Test Specification
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1. However encryption
algorithm and authentication algorithm must be set according to the
corresponding entry of the table in the procedure above.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
501
KINK Test Specification
SGW.SGW.R.2.2: The shorter LIFE_SECONDS is proposed
Purpose:
Verify that a responder properly processes CREATE message when the initiator
proposes lower lifetime than the responder's lifetime
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.1
- [KINK] - Section 5.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
TN1 will propose with 30 seconds SA Life Duration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
502
KINK Test Specification
NUT (SGW)
responder
TN1 (SGW)
initiator
CREATE, AP_REQ,
E{ISAKMP(SA(P(T(LIFE_SECONDSi))), Ni, IDi, IDr)}
Packet #1
(optimistic proposal, but Nr was added by the responder)
(2-way handshake)
NUT (SGW)
responder
(3-way handshake)
TN1 (SGW)
initiator
NUT (SGW)
responder
Judgment #1
TN1 (SGW)
initiator
Judgment #1
REPLY, AP_REP,
E{ISAKMP(SA(P(T(LIFE_SECONDSi))),
IDi, IDr)}
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T(LIFE_SECONDSi))),
Nr, IDi, IDr)}
(IPsec DOI-specific error)
NUT (SGW)
responder
TN1 (SGW)
initiator
Judgment #1
REPLY, AP_REP,
E{ISAKMP(N(NO-PROPOSAL-CHOSEN))}
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However Attribute Value in SA Life Duration Data Attribute must be set
to 30 seconds.
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3, 4 or the packets described below.
If the
packet transmitted by NUT is REPLY, Attribute Value in SA Life Duration Data
Attribute must be set to 30 seconds.
TAHI Project TECHNICAL DOCUMENT
In addition, Data Attributes in Transform
503
KINK Test Specification
payload can be placed in any order excepting that SA Life Duration Data
Attribute is always follow SA Life Type Data Attribute.
NO-PROPOSAL-CHOSEN
IPv6
Next Header:
Source Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
N Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-ID:
SPI Size:
Notify Message Type:
Notification Data:
Cksum:
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
N (11)
1
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
0
NO-PROPOSAL-CHOSEN (14)
ANY
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
* The shaded region in Common Observed Packet #6 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
TAHI Project TECHNICAL DOCUMENT
504
KINK Test Specification
unencrypted NO-PROPOSAL-CHOSEN
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REP:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
N Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-ID:
SPI Size:
Notify Message Type:
Notification Data:
Cksum:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
N (11)
1
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
0
NO-PROPOSAL-CHOSEN (14)
ANY
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
TAHI Project TECHNICAL DOCUMENT
505
KINK Test Specification
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
506
KINK Test Specification
SGW.SGW.R.2.3: Selecting the optimistic proposal from multiple transforms
Purpose:
Verify that a node properly chooses optimistic proposal from proposed multiple
transforms
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.1
- [KINK] - Section 5.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
below.
TN1 will propose multiple Transform payloads as described
Transform #1 will be selected by NUT.
Transform #
1
2
IPsec encryption algorithm
ESP_3DES (3)
ESP_AES-CBC (12)
IPsec authentication algorithm
HMAC-SHA (2)
AES-XCBC-MAC (9)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
TAHI Project TECHNICAL DOCUMENT
507
KINK Test Specification
Procedure:
NUT (SGW)
responder
TN1 (SGW)
initiator
CREATE, AP_REQ,
E{ISAKMP(SA(P(T1, T2)), Ni, IDi, IDr)}
Packet #1
(optimistic proposal, but Nr was added by the responder)
(2-way handshake)
(3-way handshake)
TN1 (SGW)
initiator
NUT (SGW)
responder
NUT (SGW)
responder
Judgment #1
TN1 (SGW)
initiator
Judgment #1
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T1)), Nr, IDi, IDr)}
REPLY, AP_REP,
E{ISAKMP(SA(P(T1)), IDi, IDr)}
Packet #2
ACK, AP_REQ
NUT (SGW)
responder
TH1 (Host)
TN1 (SGW)
initiator
TH2 (Host)
Pkt #3/Jdg #2
ICMPv6 Echo Request
Pkt #4/Jdg #3
ICMPv6 Echo Reply
IPsec ESP tunnel
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However Proposal Payload must be set as following.
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
TAHI Project TECHNICAL DOCUMENT
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
2
ANY
T (3)
0
the actual length of this payload in octets
508
KINK Test Specification
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
NONE (0)
0
the actual length of this payload in octets
2
ESP_AES-CBC (12)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
AES-XCBC-MAC (9)
TV (1)
Key Length (6)
128
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
TAHI Project TECHNICAL DOCUMENT
509
KINK Test Specification
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
510
KINK Test Specification
SGW.SGW.R.2.4: Selecting the non-optimistic proposal from multiple transforms
Purpose:
Verify that a node properly chooses non-optimistic proposal from proposed multiple
transforms
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.1
- [KINK] - Section 5.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
below.
TN1 will propose multiple Transform payloads as described
Transform #2 will be selected by NUT.
Transform #
1
2
IPsec encryption algorithm
ESP_AES-CBC (12)
ESP_3DES (3)
IPsec authentication algorithm
AES-XCBC-MAC (9)
HMAC-SHA (2)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
TAHI Project TECHNICAL DOCUMENT
511
KINK Test Specification
Procedure:
NUT (SGW)
responder
TN1 (SGW)
initiator
Packet #1
Judgment #1
Packet #2
CREATE, AP_REQ,
E{ISAKMP(SA(P(T1, T2)), Ni, IDi, IDr)}
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T2)), Nr, IDi, IDr)}
ACK, AP_REQ
IPsec ESP tunnel
TH1 (Host)
TH2 (Host)
Pkt #3/Jdg #2
ICMPv6 Echo Request
Pkt #4/Jdg #3
ICMPv6 Echo Reply
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However Proposal Payload must be set as following.
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
2
ANY
T (3)
0
the actual length of this payload in octets
1
ESP_AES-CBC (12)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
AES-XCBC-MAC (9)
512
KINK Test Specification
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
TV (1)
Key Length (6)
128
NONE (0)
0
the actual length of this payload in octets
2
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to REPLY with ACK described as Common Transmitted Packet
#2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #3 or 4. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
TAHI Project TECHNICAL DOCUMENT
513
KINK Test Specification
Observed Packet #5 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
514
KINK Test Specification
SGW.SGW.R.2.5: Selecting the optimistic proposal from multiple proposals
Purpose:
Verify that a node properly chooses optimistic proposal from proposed multiple
proposals
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.1
- [KINK] - Section 5.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
below.
Proposal #
1
2
TN1 will propose multiple Proposal payloads as described
Proposal #1 will be selected by NUT.
Protocol ID
PROTO_IPSEC_ESP (3)
PROTO_IPSEC_AH (2)
IPsec encryption algorithm
ESP_3DES (3)
-
IPsec authentication algorithm
HMAC-SHA (2)
AH_SHA (3)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
TAHI Project TECHNICAL DOCUMENT
515
KINK Test Specification
Procedure:
NUT (SGW)
responder
TN1 (SGW)
initiator
CREATE, AP_REQ,
E{ISAKMP(SA(P1(T), P2(T)), Ni, IDi, IDr)}
Packet #1
(optimistic proposal, but Nr was added by the responder)
(2-way handshake)
NUT (SGW)
responder
(3-way handshake)
TN1 (SGW)
initiator
TN1 (SGW)
initiator
NUT (SGW)
responder
Judgment #1
Judgment #1
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P1(T)), Nr, IDi, IDr)}
REPLY, AP_REP,
E{ISAKMP(SA(P1(T)), IDi, IDr)}
Packet #2
ACK, AP_REQ
NUT (SGW)
responder
TH1 (Host)
TN1 (SGW)
initiator
TH2 (Host)
Pkt #3/Jdg #2
ICMPv6 Echo Request
Pkt #4/Jdg #3
ICMPv6 Echo Reply
IPsec ESP tunnel
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However Security Association Payload must be set as following.
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
TAHI Project TECHNICAL DOCUMENT
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
P (2)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
516
KINK Test Specification
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
NONE (0)
0
the actual length of this payload in octets
2
PROTO_IPSEC_AH (2)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
AH_SHA (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
TAHI Project TECHNICAL DOCUMENT
517
KINK Test Specification
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
518
KINK Test Specification
SGW.SGW.R.2.6: Selecting the non-optimistic proposal from multiple proposals
Purpose:
Verify that a node properly chooses non-optimistic proposal from proposed multiple
proposals
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.1
- [KINK] - Section 5.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
below.
Proposal #
1
2
TN1 will propose multiple Proposal payloads as described
Proposal #2 will be selected by NUT.
Protocol ID
PROTO_IPSEC_AH (2)
PROTO_IPSEC_ESP (3)
IPsec encryption algorithm
ESP_3DES (3)
IPsec authentication algorithm
AH_SHA (3)
HMAC-SHA (2)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
TAHI Project TECHNICAL DOCUMENT
519
KINK Test Specification
Procedure:
TN1 (SGW)
initiator
NUT (SGW)
responder
Packet #1
Judgment #1
Packet #2
CREATE, AP_REQ,
E{ISAKMP(SA(P1(T), P2(T)),
Ni, IDi, IDr)}
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P2(T)), Nr, IDi, IDr)}
ACK, AP_REQ
IPsec ESP tunnel
TH1 (Host)
TH2 (Host)
Pkt #3/Jdg #2
ICMPv6 Echo Request
Pkt #4/Jdg #3
ICMPv6 Echo Reply
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However Security Association Payload must be set as following.
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
TAHI Project TECHNICAL DOCUMENT
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
P (2)
0
the actual length of this payload in octets
1
PROTO_IPSEC_AH (2)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
AH_SHA (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
520
KINK Test Specification
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
NONE (0)
0
the actual length of this payload in octets
2
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to REPLY with ACK described as Common Transmitted Packet
#2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
TAHI Project TECHNICAL DOCUMENT
KINK Test Specification
521
Common Observed Packet #3 or 4. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
522
KINK Test Specification
SGW.SGW.R.2.7: Responding to multiple KINK_ISAKMP by optimistic keying
Purpose:
Verify that a node properly chooses optimistic proposal from proposed multiple
KINK_ISAKMP payloads
References:
- [KINK] - Section 3.2
- [KINK] - Subsection 4.2.6
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
However, multiple SPD entries are needed to configure on
NUT for both inbound and outbound direction as described below.
SPD #
1
2
Remote IP Address
TH2 - Link Y
(Prefix Y::c)
TH3 - Link Y
(Prefix Y::b)
Local IP Address
TH1 - Link B
(Prefix B::d)
TH1 - Link B
(Prefix B::d)
Next Layer Protocol
IPv6-ICMP (58)
IPv6-ICMP (58)
For both SPD #1 and #2, IPsec configuration described in Default NUT (SGW)
Configuration will be proposed by TN1.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
TAHI Project TECHNICAL DOCUMENT
523
Both
TN1 must obtain NUT's
KINK Test Specification
service ticket from its KDC.
Procedure:
TN1 (SGW)
initiator
NUT (SGW)
responder
Packet #1
CREATE, AP_REQ,
E{ISAKMP1(SA(P(T)), Ni, IDi, IDr),
ISAKMP2(SA(P(T)), Ni, IDi, IDr)}
(optimistic proposal, but Nr was added by the responder)
(2-way handshake)
(3-way handshake)
TN1 (SGW)
initiator
NUT (SGW)
responder
TN1 (SGW)
initiator
NUT (SGW)
responder
Judgment #1
Judgment #1
REPLY(ACKREQ), AP_REP,
E{ISAKMP1(SA(P(T)), Nr, IDi, IDr),
ISAKMP2(SA(P(T)), Nr, IDi, IDr)}
REPLY, AP_REP,
E{ISAKMP1(SA(P(T)), IDi, IDr),
ISAKMP2(SA(P(T)), IDi, IDr)}
Packet #2
ACK, AP_REQ
NUT (SGW)
responder
TH1 (Host)
TN1 (SGW)
initiator
TH2 (Host)
Pkt #3/Jdg #2
ICMPv6 Echo Request
Pkt #4/Jdg #3
ICMPv6 Echo Reply
IPsec ESP tunnel
*
TH3 (Host)
Pkt #5/Jdg #4
Pkt #6/Jdg #5
IPsec ESP tunnel
*
ICMPv6 Echo Request
ICMPv6 Echo Reply
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However KINK_ENCRYPT Payload must be set as following.
TAHI Project TECHNICAL DOCUMENT
524
The
KINK Test Specification
shaded region in this packet is encrypted by Kerberos encrypt function with
Key Usage Number 39 (KINK_ENCRYPT payload).
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
TAHI Project TECHNICAL DOCUMENT
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_ISAKMP (6)
0
the actual length of this payload in octets
SA (1)
1
0
0
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
0x10000000
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
8 bytes length random data
IDr (5)
0
the actual length of this payload in octets
525
KINK Test Specification
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
TAHI Project TECHNICAL DOCUMENT
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TH2 - Link Y
(Prefix Y::c)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TH1 - Link B
(Prefix B::d)
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
0x20000000
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
8 bytes length random data
526
KINK Test Specification
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TH3 - Link Y
(Prefix Y::b)
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TH1 - Link B
(Prefix B::d)
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
SPI must be set to the value proposed in
the first KINK_ISAKMP Payload of REPLY.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
8. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3. However, Source Address in the inner IPv6
Header is set to TH3 address.
SPI must be set to the value proposed in the
second KINK_ISAKMP Payload of REPLY.
9. Observe the packets transmitted by the NUT on Link B.
10. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4. However, Destination address in IPv6
Header is set to TH3 address.
11. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
TAHI Project TECHNICAL DOCUMENT
527
KINK Test Specification
Common Observed Packet #1, 2, 3 or 4.
However the NUT includes two
KINK_ISAKMP Payloads as following.
KINK_ISAKMP Payload for Common Observed Packet #1 and 2
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
TAHI Project TECHNICAL DOCUMENT
KINK_ISAKMP (6)
0
the actual length of this payload in octets
SA (1)
1
0
0
IDi (5)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TH2 - Link Y
(Prefix Y::c)
NONE (0)
0
528
KINK Test Specification
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
TAHI Project TECHNICAL DOCUMENT
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TH1 - Link B
(Prefix B::d)
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
IDi (5)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TH3 - Link Y
(Prefix Y::b)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
529
KINK Test Specification
Port:
Identification Data:
ANY (0)
TH1 - Link B
(Prefix B::d)
KINK_ISAKMP Payload for Common Observed Packet #3 and 4
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Nr Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
TAHI Project TECHNICAL DOCUMENT
KINK_ISAKMP (6)
0
the actual length of this payload in octets
SA (1)
1
0
0
Nr (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
8 bytes length random data
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
530
KINK Test Specification
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Nr Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
TAHI Project TECHNICAL DOCUMENT
IPv6-ICMP (58)
ANY (0)
TH2 - Link Y
(Prefix Y::c)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TH1 - Link B
(Prefix B::d)
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Nr (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
8 bytes length random data
531
KINK Test Specification
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TH3 - Link Y
(Prefix Y::b)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TH1 - Link B
(Prefix B::d)
Data Attributes in Transform payload can be placed in any order excepting that
SA Life Duration Data Attribute is always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1.
Step 9: (Judgment #4)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and forward to TH1.
However, Source Address in IPv6
Header is set to TH3 address.
Step 11: (Judgment #5)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1.
However, Destination
address in the inner IPv6 Header is set to TH3 address.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
TAHI Project TECHNICAL DOCUMENT
532
KINK Test Specification
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TLV (0)
SA Life Duration (2)
ANY
28,800
- An implementation may want to contribute the keying materials by adding Nr
Payload to only one KINK_ISAKMP. Payload.
TAHI Project TECHNICAL DOCUMENT
533
KINK Test Specification
SGW.SGW.R.2.8: Responding to multiple KINK_ISAKMP by non-optimistic keying
Purpose:
Verify that a node properly chooses non-optimistic proposal from proposed multiple
KINK_ISAKMP payloads
References:
- [KINK] - Section 3.2
- [KINK] - Subsection 4.2.6
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
However, multiple SPD entries are needed to configure on
NUT for both inbound and outbound direction as described below.
SPD #
1
2
Remote IP Address
TH2 - Link Y
(Prefix Y::c)
TH3 - Link Y
(Prefix Y::b)
Local IP Address
TH1 - Link B
(Prefix B::d)
TH1 - Link B
(Prefix B::d)
Next Layer Protocol
IPv6-ICMP (58)
IPv6-ICMP (58)
For SPD #1, IPsec configuration described in Default NUT (SGW)
Configuration will be proposed by TN1.
However, for SPD #2, multiple
Transform payloads described below are proposed by TN1. Transform #2 will
be selected by NUT.
Transform #
IPsec encryption algorithm
TAHI Project TECHNICAL DOCUMENT
534
IPsec authentication algorithm
KINK Test Specification
1
2
ESP_AES-CBC (12)
ESP_3DES (3)
AES-XCBC-MAC (9)
HMAC-SHA (2)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TN1 (SGW)
initiator
NUT (SGW)
responder
Packet #1
Judgment #1
Packet #2
TH1 (Host)
CREATE, AP_REQ,
E{ISAKMP1(SA(P(T)), Ni, IDi, IDr),
ISAKMP2(SA(P(T1, T2)), Ni, IDi, IDr)}
REPLY(ACKREQ), AP_REP,
E{ISAKMP1(SA(P(T)), Nr, IDi, IDr),
ISAKMP2(SA(P(T2)), Nr, IDi, IDr)}
ACK, AP_REQ
TH2 (Host)
Pkt #3/Jdg #2
ICMPv6 Echo Request
Pkt #4/Jdg #3
ICMPv6 Echo Reply
IPsec ESP tunnel
*
TH3 (Host)
Pkt #5/Jdg #4
ICMPv6 Echo Request
Pkt #6/Jdg #5
ICMPv6 Echo Reply
IPsec ESP tunnel
*
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However KINK_ENCRYPT Payload must be set as following.
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
TAHI Project TECHNICAL DOCUMENT
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
535
KINK Test Specification
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
TAHI Project TECHNICAL DOCUMENT
KINK_ISAKMP (6)
0
the actual length of this payload in octets
SA (1)
1
0
0
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
0x10000000
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
8 bytes length random data
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TH2 - Link Y
(Prefix Y::c)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
536
KINK Test Specification
Identification Data:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
TAHI Project TECHNICAL DOCUMENT
TH1 - Link B
(Prefix B::d)
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
2
0x20000000
T (3)
0
the actual length of this payload in octets
1
ESP_AES-CBC (12)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
AES-XCBC-MAC (9)
TV (1)
Key Length (6)
128
NONE (0)
0
the actual length of this payload in octets
2
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
537
KINK Test Specification
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
8 bytes length random data
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TH3 - Link Y
(Prefix Y::b)
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TH1 - Link B
(Prefix B::d)
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to REPLY with ACK described as Common Transmitted Packet
#2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
SPI must be set to the value proposed in
the first KINK_ISAKMP Payload of REPLY.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
8. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3. However, Source Address in the inner IPv6
Header is set to TH3 address.
SPI must be set to the value proposed in the
second KINK_ISAKMP Payload of REPLY.
9. Observe the packets transmitted by the NUT on Link B.
10. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
TAHI Project TECHNICAL DOCUMENT
538
KINK Test Specification
Common Transmitted Packet #4. However, Destination address in IPv6
Header is set to TH3 address.
11. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #3 or 4. However the NUT includes two
KINK_ISAKMP Payloads as following.
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
TAHI Project TECHNICAL DOCUMENT
KINK_ISAKMP (6)
0
the actual length of this payload in octets
SA (1)
1
0
0
IDi (5)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
539
KINK Test Specification
Attribute Value:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
HMAC-SHA (2)
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TH2 - Link Y
(Prefix Y::c)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TH1 - Link B
(Prefix B::d)
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Nr (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
540
KINK Test Specification
Nr Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDi (5)
0
the actual length of this payload in octets
8 bytes length random data
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TH3 - Link Y
(Prefix Y::b)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TH1 - Link B
(Prefix B::d)
Data Attributes in Transform payload can be placed in any order excepting that
SA Life Duration Data Attribute is always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1.
Step 9: (Judgment #4)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and forward to TH1.
However, Source Address in IPv6
Header is set to TH3 address.
Step 11: (Judgment #5)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1.
However, Destination
address in the inner IPv6 Header is set to TH3 address.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
TAHI Project TECHNICAL DOCUMENT
541
KINK Test Specification
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TLV (0)
SA Life Duration (2)
ANY
28,800
- An implementation may want to contribute the keying materials by adding Nr
Payload also to optimistic proposal represented as first KINK_ISAKMP Payload.
TAHI Project TECHNICAL DOCUMENT
542
KINK Test Specification
SGW.SGW.R.2.9: Sending NO-PROPOSAL-CHOSEN
Purpose:
Verify that a node properly rejects the proposal which is not accepted by the
responder
References:
- [KINK] - Section 5.5
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
TN1 will propose following Transform payload and NUT will
reject it by sending NO-PROPOSAL-CHOSEN.
IPsec encryption algorithm
ESP_AES-CBC (12)
IPsec authentication algorithm
AES-XCBC-MAC (9)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
543
KINK Test Specification
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However Transform Payload must be set as following.
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
T (3)
0
the actual length of this payload in octets
1
ESP_AES-CBC (12)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
AES-XCBC-MAC (9)
TV (1)
Key Length (6)
128
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must respond to CREATE with properly formatted IPsec DOI-specific
error described as following.
TAHI Project TECHNICAL DOCUMENT
544
KINK Test Specification
NO-PROPOSAL-CHOSEN
IPv6
Next Header:
Source Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
N Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-ID:
SPI Size:
Notify Message Type:
Notification Data:
Cksum:
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
N (11)
1
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
0
NO-PROPOSAL-CHOSEN (14)
ANY
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
* The shaded region in Common Observed Packet #6 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
unencrypted NO-PROPOSAL-CHOSEN
TAHI Project TECHNICAL DOCUMENT
545
KINK Test Specification
IPv6
Next Header:
Source Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
raw data of Kerberos AP-REP
AP-REP:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
N Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-ID:
SPI Size:
Notify Message Type:
Notification Data:
Cksum:
KINK_DONE (0)
0
the actual length of this payload in octets
N (11)
1
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
0
NO-PROPOSAL-CHOSEN (14)
ANY
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
546
KINK Test Specification
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
28,800
547
KINK Test Specification
Group 3: Perfect Forward Secrecy
Scope:
The initiator usually begins a negotiation expecting a 2-way handshake, but 3-way
handshake is expected from the beginning when and only when the initiator uses a KE
payload.
The following tests cover 3-way handshake by adding KE payload.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation chooses to use the perfect forward
secrecy (PFS).
TAHI Project TECHNICAL DOCUMENT
548
KINK Test Specification
SGW.SGW.R.3.1: PFS
Purpose:
Verify that a responder properly processes 3-way handshake when the initiator
requires to use PFS
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.7
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration with enabling PFS.
DH group is 1024 MODP Group (2).
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
549
KINK Test Specification
Part A: (ADVANCED)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However KINK_ISAKMP Payload must be set as following.
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
TAHI Project TECHNICAL DOCUMENT
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
0x10000000
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
550
KINK Test Specification
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
KE Payload
Next Payload:
RESERVED:
Payload Length:
Key Exchange Data
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
SA Life Duration (2)
28,800
TV (1)
Group Description (3)
1024 MODP Group (2)
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
KE (4)
0
the actual length of this payload in octets
8 bytes length random data
IDi (5)
0
the actual length of this payload in octets
DH Group #2 public value
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link Y
(Prefix Y::/64)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link B
(Prefix B::/64)
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to REPLY with ACK described as Common Transmitted Packet
#2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
Observable Results:
TAHI Project TECHNICAL DOCUMENT
551
KINK Test Specification
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #3 or 4. However KINK_ISAKMP Payload must be
set as following.
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Nr Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
KE Payload
TAHI Project TECHNICAL DOCUMENT
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Nr (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Group Description (3)
1024 MODP Group (2)
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
KE (4)
0
the actual length of this payload in octets
ANY
552
KINK Test Specification
Next Payload:
RESERVED:
Payload Length:
Key Exchange Data
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDi (5)
0
the actual length of this payload in octets
DH Group #2 public value
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link Y
(Prefix Y::/64)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link B
(Prefix B::/64)
Data Attributes in Transform payload can be placed in any order excepting that
SA Life Duration Data Attribute is always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
553
KINK Test Specification
SGW.SGW.R.3.2: Sending INVALID-PAYLOAD-TYPE against the receipt of KE
Purpose:
Verify that a responder properly rejects to use PFS when the responder doesn't
support PFS
References:
- [KINK] - Section 3.2
- [KINK] - Section 5.7
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
554
KINK Test Specification
NUT (SGW)
responder
TN1 (SGW)
initiator
Packet #1
Judgment #1
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, KE, IDi, IDr)}
REPLY, AP_REP,
E{ISAKMP(N(INVALID-PAYLOAD-TYPE))}
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However KINK_ISAKMP Payload must be set as following.
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
TAHI Project TECHNICAL DOCUMENT
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
0x10000000
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Group Description (3)
1024 MODP Group (2)
TV (1)
Encapsulation Mode (4)
Tunnel (1)
555
KINK Test Specification
Attribute Format:
Attribute Type:
Attribute Value:
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
KE Payload
Next Payload:
RESERVED:
Payload Length:
Key Exchange Data
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
KE (4)
0
the actual length of this payload in octets
8 bytes length random data
IDi (5)
0
the actual length of this payload in octets
DH Group #2 public value
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link Y
(Prefix Y::/64)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link B
(Prefix B::/64)
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must respond to CREATE with properly formatted IPsec DOI-specific
error described as following.
INVALID-PAYLOAD-TYPE
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
556
KINK Test Specification
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
N Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-ID:
SPI Size:
Notify Message Type:
Notification Data:
Cksum:
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
N (11)
1
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
0
INVALID-PAYLOAD-TYPE (1)
ANY
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
* The shaded region in Common Observed Packet #6 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
unencrypted INVALID-PAYLOAD-TYPE
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
557
KINK Test Specification
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
raw data of Kerberos AP-REP
AP-REP:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
N Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-ID:
SPI Size:
Notify Message Type:
Notification Data:
Cksum:
KINK_DONE (0)
0
the actual length of this payload in octets
N (11)
1
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
0
INVALID-PAYLOAD-TYPE (1)
ANY
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
558
KINK Test Specification
Group 4: Rekeying
Scope:
Unlike IKE, the initiator of KINK exchange has the responsibility for rekeying the SA.
The following tests cover CREATE message flow when the SA lifetime expires.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation responds to rekeying SA.
TAHI Project TECHNICAL DOCUMENT
559
KINK Test Specification
SGW.SGW.R.4.1: Responding to Rekeying
Purpose:
Verify that a node properly processes rekeying
References:
- [KINK] - Section 3.6
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
560
KINK Test Specification
(2-way handshake)
NUT (EN)
responder
(3-way handshake)
TN1 (EN)
initiator
NUT (EN)
responder
TN1 (EN)
initiator
Packet #1
Packet #1
CREATE(XID=0), AP_REQ,
E{ISAKMP(SA(P(SPIi1, T)), Ni, IDi, IDr)}
Judgment #1
Judgment #1
REPLY(XID=0, ACKREQ), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), Nr, IDi, IDr)}
REPLY(XID=0), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), IDi, IDr)}
Packet #2
ACK(XID=0), AP_REQ
TH1 (Host)
NUT (SGW)
responder
TN1 (SGW)
initiator
TH2 (Host)
Pkt #3/Jdg #2
ICMPv6 Echo Request
Pkt #4/Jdg #3
ICMPv6 Echo Reply
IPsec ESP(SPIi1) tunnel
IPsec ESP(SPIr1) tunnel
(Rekeying)
(optimistic proposal, but Nr was added by the responder)
(2-way handshake)
NUT (EN)
responder
(3-way handshake)
TN1 (EN)
initiator
NUT (EN)
responder
Packet #4
TN1 (EN)
initiator
Packet #4
CREATE(XID=1), AP_REQ,
E{ISAKMP(SA(P(SPIi2, T)), Ni, IDi, IDr)}
Judgment #4
Judgment #4
REPLY(XID=1, ACKREQ), AP_REP,
E{ISAKMP(SA(P(SPIr2, T)), Nr, IDi, IDr)}
REPLY(XID=1), AP_REP,
E{ISAKMP(SA(P(SPIr2, T)), IDi, IDr)}
Packet #5
ACK(XID=1), AP_REQ
TH1 (Host)
NUT (SGW)
responder
TN1 (SGW)
initiator
TH2 (Host)
Pkt #6/Jdg #5
ICMPv6 Echo Request
Pkt #7/Jdg #6
ICMPv6 Echo Reply
IPsec ESP(SPIi2) tunnel
IPsec ESP(SPIr2) tunnel
TAHI Project TECHNICAL DOCUMENT
561
KINK Test Specification
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
8. TN1 transmits CREATE message described as Common Transmitted Packet
#1 with updating SPI value to 0x20000000.
XID is updated to one.
9. Observe the packets transmitted by the NUT on Link A.
10. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
11. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
ICMPv6 Identifier is set to one.
12. Observe the packets transmitted by the NUT on Link B.
13. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4 with updating ICMPv6 Identifier to one.
14. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and forward to TH1.
TAHI Project TECHNICAL DOCUMENT
562
KINK Test Specification
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1.
Step 9: (Judgment #4)
The NUT must newly transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
XID must be 1. Data Attributes in
Transform payload can be placed in any order excepting that SA Life Duration
Data Attribute is always follow SA Life Type Data Attribute.
Step 12: (Judgment #5)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and forward to TH1.
ICMPv6 Identifier is set to one.
Step 14: (Judgment #6)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1 with updating SPI value
to 0x20000000 with updating ICMPv6 Identifier to one.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
563
KINK Test Specification
SGW.SGW.R.4.2: Receipt of transaction ID constructed by using a non monotonic
counter
Purpose:
Verify that a node properly processes the transaction ID
References:
- [KINK] – Chapter 4
- [KINK] – Chapter 6
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
564
KINK Test Specification
(2-way handshake)
NUT (EN)
responder
(3-way handshake)
TN1 (EN)
initiator
NUT (EN)
responder
TN1 (EN)
initiator
Packet #1
Packet #1
CREATE(XID=65535), AP_REQ,
E{ISAKMP(SA(P(SPIi1, T)), Ni, IDi, IDr)}
Judgment #1
Judgment #1
REPLY(XID=65535, ACKREQ), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), Nr, IDi, IDr)}
REPLY(XID=65535), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), IDi, IDr)}
Packet #2
ACK(XID=65535),
AP_REQ
TH1 (Host)
NUT (SGW)
responder
TN1 (SGW)
initiator
TH2 (Host)
Pkt #3/Jdg #2
ICMPv6 Echo Request
Pkt #4/Jdg #3
ICMPv6 Echo Reply
IPsec ESP(SPIi1) tunnel
IPsec ESP(SPIr1) tunnel
(Rekeying)
(optimistic proposal, but Nr was added by the responder)
(2-way handshake)
NUT (EN)
responder
(3-way handshake)
TN1 (EN)
initiator
NUT (EN)
responder
Packet #4
TN1 (EN)
initiator
Packet #4
CREATE(XID=255), AP_REQ,
E{ISAKMP(SA(P(SPIi2, T)), Ni, IDi, IDr)}
Judgment #4
Judgment #4
REPLY(XID=255, ACKREQ), AP_REP,
E{ISAKMP(SA(P(SPIr2, T)), Nr, IDi, IDr)}
REPLY(XID=255), AP_REP,
E{ISAKMP(SA(P(SPIr2, T)), IDi, IDr)}
Packet #5
ACK(XID=255),
AP_REQ
TH1 (Host)
NUT (SGW)
responder
TN1 (SGW)
initiator
TH2 (Host)
Pkt #6/Jdg #5
ICMPv6 Echo Request
Pkt #7/Jdg #6
ICMPv6 Echo Reply
IPsec ESP(SPIi2) tunnel
IPsec ESP(SPIr2) tunnel
TAHI Project TECHNICAL DOCUMENT
565
KINK Test Specification
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However XID is set to 65535.
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
8. TN1 transmits CREATE message described as Common Transmitted Packet
#1 with updating SPI value to 0x20000000.
XID is updated to 255.
9. Observe the packets transmitted by the NUT on Link A.
10. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
11. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
ICMPv6 Identifier is set to one.
12. Observe the packets transmitted by the NUT on Link A.
13. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4
ICMPv6 Identifier is set to one.
14. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
XID must be 65535.
Data Attributes in
Transform payload can be placed in any order excepting that SA Life Duration
Data Attribute is always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and forward to TH1.
TAHI Project TECHNICAL DOCUMENT
566
KINK Test Specification
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1.
Step 9: (Judgment #4)
The NUT must newly transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
XID must be 255.
Data Attributes in
Transform payload can be placed in any order excepting that SA Life Duration
Data Attribute is always follow SA Life Type Data Attribute.
Step 12: (Judgment #5)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and forward to TH1.
ICMPv6 Identifier is set to one.
Step 14: (Judgment #6)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1 with updating SPI value
to 0x20000000.
ICMPv6 Identifier is set to one.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
567
KINK Test Specification
SGW.SGW.R.4.3: Responding to CREATE with INVALID-SPI
Purpose:
Verify that a node properly rejects CREATE message containing an existing SPI
References:
- [KINK] - Section 3.2
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
568
KINK Test Specification
(2-way handshake)
(3-way handshake)
TN1 (SGW)
initiator
NUT (SGW)
responder
TN1 (SGW)
initiator
NUT (SGW)
responder
Packet #1
Packet #1
CREATE(XID=0), AP_REQ,
E{ISAKMP1(SA(P(SPIi1, T)), Ni, IDi, IDr)}
Judgment #1
Judgment #1
REPLY(XID=0, ACKREQ), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), Nr, IDi, IDr)}
REPLY(XID=0), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), IDi, IDr)}
Packet #2
ACK(XID=0), AP_REQ
NUT (SGW)
responder
TH1 (Host)
TN1 (SGW)
initiator
TH2 (Host)
Pkt #3/Jdg #2
ICMPv6 Echo Request
Pkt #4/Jdg #3
ICMPv6 Echo Reply
IPsec ESP(SPIi1) tunnel
IPsec ESP(SPIr1) tunnel
(Rekeying)
CREATE(XID=1), AP_REQ,
E{ISAKMP(SA(P(SPIi1, T)), Ni, IDi, IDr)}
REPLY(XID=1), AP_REP,
E{ISAKMP(N(INVALID-SPI))}
Packet #5
Judgment #4
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
8. TN1 transmits CREATE message described as Common Transmitted Packet
#1 again.
XID is updated to one.
TAHI Project TECHNICAL DOCUMENT
569
KINK Test Specification
9. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1.
Step 9: (Judgment #4)
The NUT must respond to CREATE with properly formatted IPsec DOI-specific
error described as following.
INVALID-SPI
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
570
KINK Test Specification
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
N Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-ID:
SPI Size:
Notify Message Type:
SPI
Notification Data:
Cksum:
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
N (11)
1
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
4
INVALID-SPI (11)
0x10000000
ANY
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
* The shaded region in Common Observed Packet #6 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
unencrypted INVALID-SPI
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REP:
KINK_ISAKMP Payload
Next Payload:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
raw data of Kerberos AP-REP
KINK_DONE (0)
571
KINK Test Specification
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
N Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-ID:
SPI Size:
Notify Message Type:
SPI
Notification Data:
Cksum:
0
the actual length of this payload in octets
N (11)
1
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
4
INVALID-SPI (11)
0x10000000
ANY
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
572
KINK Test Specification
Group 5: DELETE Message Flow
Scope:
The DELETE command deletes existing SAs.
The following tests cover the DELETE
message flows when the KINK implementation responds to these exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation responds to DELETE message
flows.
TAHI Project TECHNICAL DOCUMENT
573
KINK Test Specification
SGW.SGW.R.5.1: DELETE Message Flow
Purpose:
Verify that a node properly deleates an existing SA
References:
- [KINK] - Section 3.3
- [KINK] - Section 6.4
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
574
KINK Test Specification
(2-way handshake)
NUT (EN)
responder
(3-way handshake)
TN1 (EN)
initiator
NUT (EN)
responder
TN1 (EN)
initiator
Packet #1
Packet #1
CREATE(XID=0), AP_REQ,
E{ISAKMP(SA(P(SPIi1, T)), Ni, IDi, IDr)}
Judgment #1
Judgment #1
REPLY(XID=0, ACKREQ), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), Nr, IDi, IDr)}
REPLY(XID=0), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), IDi, IDr)}
Packet #2
ACK(XID=0), AP_REQ
TN1 (SGW)
initiator
NUT (SGW)
responder
TH1 (Host)
TH2 (Host)
Pkt #3/Jdg #2
ICMPv6 Echo Request
Pkt #4/Jdg #3
ICMPv6 Echo Reply
IPsec ESP(SPIi1) tunnel
IPsec ESP(SPIr1) tunnel
(Deleting)
DELETE(XID=1), AP_REQ,
E{ISAKMP(D(SPIi1))}
REPLY(XID=1), AP_REP,
E{ISAKMP(D(SPIr1)))}
Packet #5
Judgment #4
No response
Pkt #6/Jdg #5
ICMPv6 Echo Request
IPsec ESP(SPIr1) tunnel
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
TAHI Project TECHNICAL DOCUMENT
575
KINK Test Specification
7. Observe the packets transmitted by the NUT on Link A.
8. TN1 transmits DELETE message described as Common Transmitted Packet
#5.
9. Observe the packets transmitted by the NUT on Link A.
10. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
ICMPv6 Identifier is set to one.
11. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1.
Step 9: (Judgment #4)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #7 or 8.
Step 11: (Judgment #5)
The NUT must not decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and must not forward to TH1 because SA has already deleted
at Step 9.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
TAHI Project TECHNICAL DOCUMENT
576
KINK Test Specification
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
577
KINK Test Specification
SGW.SGW.R.5.2: Responding to DELETE with INVALID-SPI
Purpose:
Verify that a node properly rejects DELETE message containing a non-existing SPI
References:
- [KINK] - Section 3.3
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
578
KINK Test Specification
(2-way handshake)
NUT (EN)
responder
(3-way handshake)
TN1 (EN)
initiator
NUT (EN)
responder
TN1 (EN)
initiator
Packet #1
Packet #1
CREATE(XID=0), AP_REQ,
E{ISAKMP(SA(P(SPIi1, T)), Ni, IDi, IDr)}
Judgment #1
Judgment #1
REPLY(XID=0, ACKREQ), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), Nr, IDi, IDr)}
REPLY(XID=0), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), IDi, IDr)}
Packet #2
ACK(XID=0), AP_REQ
TN1 (SGW)
initiator
NUT (SGW)
responder
TH1 (Host)
TH2 (Host)
Pkt #3/Jdg #2
ICMPv6 Echo Request
Pkt #4/Jdg #3
ICMPv6 Echo Reply
IPsec ESP(SPIi1) tunnel
IPsec ESP(SPIr1) tunnel
(Deleting)
DELETE(XID=1), AP_REQ,
E{ISAKMP(D(SPIi2))}
Packet #5
REPLY(XID=1), AP_REP,
E{ISAKMP(N(INVALID-SPI))}
Judgment #4
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
8. TN1 transmits DELETE message described as Common Transmitted Packet
#5.
However SPI is set to 0x20000000.
TAHI Project TECHNICAL DOCUMENT
579
KINK Test Specification
9. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1.
Step 9: (Judgment #4)
The NUT must respond to DELETE with properly formatted IPsec DOI-specific
error described as following.
INVALID-SPI
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
580
KINK Test Specification
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
N Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-ID:
SPI Size:
Notify Message Type:
SPI
Notification Data:
Cksum:
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
N (11)
1
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
4
INVALID-SPI (11)
0x20000000
ANY
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
* The shaded region in Common Observed Packet #6 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
unencrypted INVALID-SPI
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REP:
KINK_ISAKMP Payload
Next Payload:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
raw data of Kerberos AP-REP
KINK_DONE (0)
581
KINK Test Specification
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
N Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-ID:
SPI Size:
Notify Message Type:
SPI
Notification Data:
Cksum:
0
the actual length of this payload in octets
N (11)
1
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
4
INVALID-SPI (11)
0x20000000
ANY
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
582
KINK Test Specification
Group 6: Dead Peer Detection
Scope:
The STATUS flow is used to send any information to a peer or to elicit any information
from a peer.
A STATUS command is also used as a means of dead peer detection. The
following tests cover the STATUS message flows when the KINK implementation
responds to these exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation responds to STATUS message
flows.
TAHI Project TECHNICAL DOCUMENT
583
KINK Test Specification
SGW.SGW.R.6.1: Responding to Liveness Check
Purpose:
Verify that a node properly processes a dead peer detection
References:
- [KINK] - Section 3.4
- [KINK] - Section 3.7
- [KINK] - Section 6.5
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
584
KINK Test Specification
(2-way handshake)
NUT (SGW)
responder
(3-way handshake)
NUT (SGW)
responder
TN1 (SGW)
initiator
Packet #1
TN1 (SGW)
initiator
Packet #1
CREATE(XID=0), AP_REQ(EPOCHi1),
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Judgment #1
Judgment #1
REPLY(XID=0, ACKREQ),
AP_REP(EPOCHr1),
E{ISAKMP(SA(P(T)), Nr, IDi, IDr)}
REPLY(XID=0), AP_REP(EPOCHr1),
E{ISAKMP(SA(P(T)), IDi, IDr)}
Packet #2
ACK(XID=0),
AP_REQ(EPOCHi1)
TH1 (Host)
NUT (SGW)
responder
TN1 (SGW)
initiator
TH2 (Host)
Pkt #3/Jdg #2
ICMPv6 Echo Request
Pkt #4/Jdg #3
ICMPv6 Echo Reply
IPsec ESP tunnel
Packet #5
STATUS(XID=1), AP_REQ
Judgment #4
REPLY(XID=1), AP_REP
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
8. TN1 transmits STATUS message described as Common Transmitted Packet
#6.
TAHI Project TECHNICAL DOCUMENT
585
KINK Test Specification
9. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1.
Step 9: (Judgment #4)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #9.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
586
KINK Test Specification
SGW.SGW.R.6.2: Closing SA when the principal's epoch has changed
Purpose:
Verify that a node properly closes SA when the principal's epoch has changed
References:
- [KINK] - Section 3.7
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
587
KINK Test Specification
(2-way handshake)
NUT (SGW)
responder
(3-way handshake)
NUT (SGW)
responder
TN1 (SGW)
initiator
Packet #1
TN1 (SGW)
initiator
Packet #1
CREATE(XID=0), AP_REQ(EPOCHi1),
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Judgment #1
Judgment #1
REPLY(XID=0, ACKREQ),
AP_REP(EPOCHr1),
E{ISAKMP(SA(P(T)), Nr, IDi, IDr)}
REPLY(XID=0), AP_REP(EPOCHr1),
E{ISAKMP(SA(P(T)), IDi, IDr)}
Packet #2
ACK(XID=0),
AP_REQ(EPOCHi1)
TH1 (Host)
NUT (SGW)
responder
TN1 (SGW)
initiator
TH2 (Host)
Pkt #3/Jdg #2
ICMPv6 Echo Request
Pkt #4/Jdg #3
ICMPv6 Echo Reply
IPsec ESP tunnel
Packet #5
STATUS(XID=1), AP_REQ(EPOCHi2)
Judgment #4
No response
REPLY(XID=1), AP_REP(EPOCHr1)
Pkt #6/Jdg #5
ICMPv6 Echo Request
IPsec ESP tunnel
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
TAHI Project TECHNICAL DOCUMENT
588
KINK Test Specification
7. Observe the packets transmitted by the NUT on Link A.
8. TN1 transmits STATUS message described as Common Transmitted Packet
#6.
However, EPOCH is newly generated with the current time.
9. Observe the packets transmitted by the NUT on Link A.
10. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
ICMPv6 Identifier is set to one.
11. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1.
Step 9: (Judgment #4)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #9.
Step 11: (Judgment #5)
The NUT must not decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and must not forward to TH1 because SA has already been
considered as invalid at Step 8.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
TAHI Project TECHNICAL DOCUMENT
589
KINK Test Specification
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
590
KINK Test Specification
SGW.SGW.R.6.3: Not closing SA by unprotected routing information
Purpose:
Verify that a node properly keeps SA by the receipt of an unprotected routing
information
References:
- [KINK] - Section 3.7
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
591
KINK Test Specification
(2-way handshake)
(3-way handshake)
TN1 (SGW)
initiator
NUT (SGW)
responder
TN1 (SGW)
initiator
NUT (SGW)
responder
Packet #1
Packet #1
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Judgment #1
Judgment #1
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T)), Nr, IDi, IDr)}
REPLY, AP_REP,
E{ISAKMP(SA(P(T)), IDi, IDr)}
Packet #2
ACK, AP_REQ
TH1 (Host)
NUT (SGW)
responder
TR1 (Router)
TN1 (SGW)
initiator
Pkt #3/Jdg #2
Pkt #4/Jdg #3
TH2 (Host)
ICMPv6 Echo Request
ICMPv6 Echo Reply
IPsec ESP tunnel
ICMPv6 Destination Unreachable
(Address unreachable)
Packet #5
Pkt #6/Jdg #4
ICMPv6 Echo Request
Pkt #7/Jdg #5
ICMPv6 Echo Reply
IPsec ESP tunnel
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
TAHI Project TECHNICAL DOCUMENT
592
KINK Test Specification
8. TR1 responds to ICMPv6 Echo Reply with ICMPv6 Destination Unreachable
described as Common Transmitted Packet #8.
9. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
ICMPv6 Identifier is set to one.
10. Observe the packets transmitted by the NUT on Link B.
11. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
ICMPv6 Identifier is set to one.
12. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1.
Step 10: (Judgment #4)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and forward to TH1. However, ICMPv6 Identifier must be set
to one.
Step 12: (Judgment #5)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1. However, ICMPv6
Identifier must be set to one.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
TAHI Project TECHNICAL DOCUMENT
593
The tester must allow
KINK Test Specification
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
594
KINK Test Specification
Group 7: GETTGT Message Flow
Scope:
GETTGT flow is used to retrieve a TGT from the remote peer in User-to-User
authentication mode. The following tests cover the GETTGT message flows when the
KINK implementation responds to these exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation chooses to use User-to-User
authentication mode.
TAHI Project TECHNICAL DOCUMENT
595
KINK Test Specification
SGW.SGW.R.7.1: Receipt of GETTGT Message
Purpose:
Verify that an responder responds to GETTGT message
References:
- [KINK] - Section 3.1
- [KINK] - Section 6.6
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration with enabling User-to-User authentication.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
Both
TN1 and NUT must obtain TGT from their KDC.
Procedure:
TN1 (SGW)
initiator
NUT (SGW)
responder
Packet #1
Judgment #1
GETTGT, TGT_REQ
REPLY, TGT_REP
TAHI Project TECHNICAL DOCUMENT
596
KINK Test Specification
Part A: (ADVANCED)
1. TN1 transmits GETTGT message described as Common Transmitted Packet
#7.
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must respond to GETTGT with properly formatted REPLY message
described as Common Observable Packet #10.
Possible Problems:
- None
TAHI Project TECHNICAL DOCUMENT
597
KINK Test Specification
SGW.SGW.R.7.2: GETTGT Message Flow
Purpose:
Verify that a responder properly establish SA in User-to-User authentication mode
References:
- [KINK] - Section 3.1
- [KINK] - Section 6.6
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration with enabling User-to-User authentication.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
Both
TN1 and NUT must obtain TGT from their KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
598
KINK Test Specification
NUT (SGW)
responder
TN1 (SGW)
initiator
Packet #1
TN2 (KDC)
GETTGT, TGT_REQ
Judgment #1
REPLY, TGT_REP
Kerberos (TGS-REQ)
(tester internal procedure)
Kerberos (TGS-REP)
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)),
Ni, IDi, IDr)}
Packet #2
(optimistic proposal, but Nr was added by the responder)
(2-way handshake)
NUT (SGW)
responder
(3-way handshake)
TN1 (SGW)
initiator
NUT (SGW)
responder
Judgment #2
TN1 (SGW)
initiator
Judgment #2
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T)), Nr, IDi, IDr)}
REPLY, AP_REP,
E{ISAKMP(SA(P(T)), IDi, IDr)}
Packet #3
ACK, AP_REQ
TH1 (Host)
NUT (SGW)
responder
TN1 (SGW)
initiator
TH2 (Host)
Pkt #3/Jdg #3
ICMPv6 Echo Request
Pkt #4/Jdg #4
ICMPv6 Echo Reply
IPsec ESP tunnel
Part A: (ADVANCED)
1. TN1 transmits GETTGT message described as Common Transmitted Packet
#7.
2. Observe the packets transmitted by the NUT on Link A.
3. After the TN1 obtains a service ticket for NUT from TN2 internally, TN1
transmits CREATE message described as Common Transmitted Packet #1
with updating XID to one.
4. Observe the packets transmitted by the NUT on Link A.
TAHI Project TECHNICAL DOCUMENT
599
KINK Test Specification
5. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2
with updating XID to one.
6. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
7. Observe the packets transmitted by the NUT on Link B.
8. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
9. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must respond to GETTGT with properly formatted REPLY message
described as Common Observable Packet #10.
Step 4: (Judgment #2)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4. However, XID must be set to one.
Data
Attributes in Transform payload can be placed in any order excepting that SA
Life Duration Data Attribute is always follow SA Life Type Data Attribute.
Step 7: (Judgment #3)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and forward to TH1.
Step 9: (Judgment #4)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
TAHI Project TECHNICAL DOCUMENT
600
KINK Test Specification
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
601
KINK Test Specification
SGW.SGW.R.7.3: Receipt of a KINK command with a User-to-User ticket that
cannot be decrypted with its TGT
Purpose:
Verify that a node properly processes against dead user-to-user peer
References:
- [KINK] - Subsection 3.7.1
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration with enabling User-to-User authentication.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
Both
TN1 and NUT must obtain TGT from their KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
602
KINK Test Specification
TN1 (SGW)
initiator
NUT (SGW)
responder
Packet #1
Judgment #1
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
REPLY, TGT_REP(TGTr)
Part A: (ADVANCED)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1, even though NUT is configured to use User-to-User authentication.
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must respond to GETTGT with properly formatted REPLY message
described as Common Observable Packet #10.
Possible Problems:
- None
TAHI Project TECHNICAL DOCUMENT
603
KINK Test Specification
SGW.SGW.R.7.4: Sending KINK_U2UDENIED
Purpose:
Verify that a node properly rejects to use User-to-User authentication mode when the
responder is not allowed to return its TGT
References:
- [KINK] - Section 6.6
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TN1 (SGW)
initiator
NUT (SGW)
responder
Packet #1
Judgment #1
GETTGT, TGT_REQ
REPLY, ERROR(KINK_U2UDENIED)
TAHI Project TECHNICAL DOCUMENT
604
KINK Test Specification
Part A: (BASIC)
1. TN1 transmits GETTGT message described as Common Transmitted Packet
#7.
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must respond to GETTGT with REPLY message described as following
to indicate that the NUT is not allowed to return its TGT.
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
REPLY (3)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
the same value as GETTGT message
NextPayload:
KINK_ERROR (8)
ACKREQ:
true (1)
RESERVED2:
0
CksumLen:
0
KINK_ ERROR Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
ErrorCode:
KINK_U2UDENIED (7)
Possible Problems:
- None
TAHI Project TECHNICAL DOCUMENT
605
KINK Test Specification
Group 8: Retransmission
Scope:
KINK implementation must retransmit the request using timer T when this message
expects a response.
The following tests cover the retransmission mechanism.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation responds to retransmission of
KINK messages.
TAHI Project TECHNICAL DOCUMENT
606
KINK Test Specification
SGW.SGW.R.8.1: Responding to retransmitted CREATE
Purpose:
Verify that a node properly responds to retransmitted CREATE message
References:
- [KINK] – Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
607
KINK Test Specification
NUT (SGW)
responder
TN1 (SGW)
initiator
Packet #1
Judgment #1
CREATE(XID=0), AP_REQ(AP-REQ1),
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
REPLY(XID=0), AP_REP(AP-REP1),
E{ISAKMP(SA(P(T)), IDi, IDr)}
or
REPLY(XID=0, ACKREQ), AP_REP(AP-REP1),
E{ISAKMP(SA(P(T)), Nr, IDi, IDr)}
(Retransmission)
Packet #2
Judgment #2
CREATE(XID=0), AP_REQ(AP-REQ2),
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
REPLY(XID=0), AP_REP(AP-REP2),
E{ISAKMP(SA(P(T)), IDi, IDr)}
REPLY(XID=0, ACKREQ), AP_REP(AP-REP2),
E{ISAKMP(SA(P(T)), Nr, IDi, IDr)}
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 newly transmits CREATE message described as Common Transmitted
Packet #1.
4. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 4: (Judgment #2)
The NUT must newly transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
TAHI Project TECHNICAL DOCUMENT
608
KINK Test Specification
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
609
KINK Test Specification
SGW.SGW.R.8.2: Retransmission of REPLY with the ACKREQ bit set
Purpose:
Verify that a node properly retransmit REPLY message
References:
- [KINK] – Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
below.
TN1 will propose multiple Transform payloads as described
Transform #2 will be selected by NUT.
Transform #
1
2
IPsec encryption algorithm
ESP_AES-CBC (12)
ESP_3DES (3)
IPsec authentication algorithm
AES-XCBC-MAC (9)
HMAC-SHA (2)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
610
KINK Test Specification
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However Proposal Payload must be set as following.
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
T Payload
Next Payload:
RESERVED:
TAHI Project TECHNICAL DOCUMENT
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
2
ANY
T (3)
0
the actual length of this payload in octets
1
ESP_AES-CBC (12)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
AES-XCBC-MAC (9)
TV (1)
Key Length (6)
128
NONE (0)
0
611
KINK Test Specification
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
the actual length of this payload in octets
2
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
2. Observe the packets transmitted by the NUT on Link A.
3. After NUT transmits REPLY, observe the packets transmitted by the NUT on
Link A until the timer T expires.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #3 or 4. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 3: (Judgment #3)
The NUT must retransmit properly formatted REPLY message described as
Common Observed Packet #3 or 4. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
TAHI Project TECHNICAL DOCUMENT
612
KINK Test Specification
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TLV (0)
SA Life Duration (2)
ANY
28,800
- A timer T may be implemented with implementation's local policy. The tester must
consider the timer T configurable parameter.
TAHI Project TECHNICAL DOCUMENT
613
KINK Test Specification
SGW.SGW.R.8.3: Stop the retransmission of REPLY with the ACKREQ bit set
Purpose:
Verify that a node properly stops the retransmission of REPLY message
References:
- [KINK] – Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
below.
TN1 will propose multiple Transform payloads as described
Transform #2 will be selected by NUT.
Transform #
1
2
IPsec encryption algorithm
ESP_AES-CBC (12)
ESP_3DES (3)
IPsec authentication algorithm
AES-XCBC-MAC (9)
HMAC-SHA (2)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
614
KINK Test Specification
NUT (SGW)
responder
TN1 (SGW)
initiator
Packet #1
Judgment #1
CREATE, AP_REQ,
E{ISAKMP(SA(P(T1, T2)), Ni, IDi, IDr)}
REPLY(ACKREQ), AP_REP(AP-REP1),
E{ISAKMP(SA(P(T2)), Nr, IDi, IDr)}
(T expires)
(Retransmission)
Judgment #2
Packet #2
REPLY(ACKREQ), AP_REP(AP-REP2),
E{ISAKMP(SA(P(T2)), Nr, IDi, IDr)}
ACK, AP_REQ
(T*2 expires)
Judgment #3
No response
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However Proposal Payload must be set as following.
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
TAHI Project TECHNICAL DOCUMENT
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
2
ANY
T (3)
0
the actual length of this payload in octets
1
ESP_AES-CBC (12)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
AES-XCBC-MAC (9)
TV (1)
615
KINK Test Specification
Attribute Type:
Attribute Value:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Key Length (6)
128
NONE (0)
0
the actual length of this payload in octets
2
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
2. Observe the packets transmitted by the NUT on Link A.
3. After NUT transmits REPLY, observe the packets transmitted by the NUT on
Link A until the timer T expires.
4. TN1 responds to REPLY with ACK described as Common Transmitted Packet
#2.
5. Observe the packets transmitted by the NUT on Link A until doubled T
expires.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #3 or 4. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 3: (Judgment #3)
The NUT must retransmit properly formatted REPLY message described as
Common Observed Packet #3 or 4. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 5: (Judgment #3)
TAHI Project TECHNICAL DOCUMENT
616
KINK Test Specification
The NUT never retransmit REPLY message because message exchange had been
completed at Step 4.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TLV (0)
SA Life Duration (2)
ANY
28,800
- A timer T may be implemented with implementation's local policy. The tester must
consider the timer T configurable parameter.
TAHI Project TECHNICAL DOCUMENT
617
KINK Test Specification
SGW.SGW.R.8.4: Responding to retransmitted DELETE
Purpose:
Verify that a node properly responds to retransmitted DELETE message
References:
- [KINK] – Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
618
KINK Test Specification
(2-way handshake)
NUT (SGW)
responder
(3-way handshake)
NUT (SGW)
responder
TN1 (SGW)
initiator
TN1 (SGW)
initiator
Packet #1
Packet #1
CREATE(XID=0), AP_REQ,
E{ISAKMP(SA(P(SPIi1, T)), Ni, IDi, IDr)}
Judgment #1
Judgment #1
REPLY(XID=0, ACKREQ), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), Nr, IDi, IDr)}
REPLY(XID=0), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), IDi, IDr)}
Packet #2
ACK(XID=0), AP_REQ
NUT (SGW)
responder
TH1 (Host)
TN1 (SGW)
initiator
TH2 (Host)
Pkt #3/Jdg #2
ICMPv6 Echo Request
Pkt #4/Jdg #3
ICMPv6 Echo Reply
IPsec ESP(SPIi1) tunnel
IPsec ESP(SPIr1) tunnel
(Deleting)
DELETE(XID=1), AP_REQ(AP-REQ1),
E{ISAKMP(D(SPIi1))}
REPLY(XID=1), AP_REP,
E{ISAKMP(D(SPIr1)))}
Packet #5
Judgment #4
(Retransmission)
DELETE(XID=1), AP_REQ(AP-REQ2),
E{ISAKMP(D(SPIi1))}
REPLY(XID=1), AP_REP,
E{ISAKMP(D(SPIr1)))}
Packet #6
Judgment #5
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
TAHI Project TECHNICAL DOCUMENT
619
KINK Test Specification
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
8. TN1 transmits DELETE message described as Common Transmitted Packet
#5.
9. Observe the packets transmitted by the NUT on Link A.
10. TN1 retransmits DELETE message described as Common Transmitted
Packet #5.
11. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1.
Step 9: (Judgment #4)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #7 or 8.
Step 11: (Judgment #5)
The NUT must newly transmit properly formatted REPLY message described as
Common Observed Packet #7 or 8.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
TAHI Project TECHNICAL DOCUMENT
620
KINK Test Specification
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
621
KINK Test Specification
SGW.SGW.R.8.5: Responding to retransmitted STATUS
Purpose:
Verify that a node properly responds to retransmitted STATUS message
References:
- [KINK] – Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
622
KINK Test Specification
(2-way handshake)
NUT (SGW)
responder
(3-way handshake)
NUT (SGW)
responder
TN1 (SGW)
initiator
Packet #1
TN1 (SGW)
initiator
Packet #1
CREATE(XID=0), AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Judgment #1
Judgment #1
REPLY(XID=0, ACKREQ), AP_REP,
E{ISAKMP(SA(P(T)), Nr, IDi, IDr)}
REPLY(XID=0), AP_REP,
E{ISAKMP(SA(P(T)), IDi, IDr)}
Packet #2
ACK(XID=0), AP_REQ
TH1 (Host)
NUT (SGW)
responder
TN1 (SGW)
initiator
TH2 (Host)
Pkt #3/Jdg #2
ICMPv6 Echo Request
Pkt #4/Jdg #3
ICMPv6 Echo Reply
IPsec ESP tunnel
Packet #5
STATUS(XID=1), AP_REQ(AP-REQ1)
Judgment #4
REPLY(XID=1), AP_REP
(Retransmission)
Packet #6
STATUS(XID=1), AP_REQ(AP-REQ2)
Judgment #5
REPLY(XID=1), AP_REP
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
TAHI Project TECHNICAL DOCUMENT
623
KINK Test Specification
8. TN1 transmits STATUS message described as Common Transmitted Packet
#6.
9. Observe the packets transmitted by the NUT on Link A.
10. TN1 retransmits STATUS message described as Common Transmitted Packet
#6.
11. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1.
Step 9: (Judgment #4)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #9.
Step 11: (Judgment #5)
The NUT must newly transmit properly formatted REPLY message described as
Common Observed Packet #9.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
TAHI Project TECHNICAL DOCUMENT
624
KINK Test Specification
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
625
KINK Test Specification
SGW.SGW.R.8.6: Responding to retransmitted GETTGT
Purpose:
Verify that a node properly responds to retransmitted GETTGT message
References:
- [KINK] – Chapter 9
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration with enabling User-to-User authentication.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
Both
TN1 and NUT must obtain TGT from their KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
626
KINK Test Specification
Part A: (ADVANCED)
1. TN1 transmits GETTGT message described as Common Transmitted Packet
#7.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 retransmits GETTGT message described as Common Transmitted
Packet #7.
4. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must respond to GETTGT with properly formatted REPLY message
described as Common Observable Packet #10.
Step 4: (Judgment #1)
The NUT must respond to GETTGT with properly formatted REPLY message
described as Common Observable Packet #10 again.
Possible Problems:
- None
TAHI Project TECHNICAL DOCUMENT
627
KINK Test Specification
Group 9: Message Validation
Scope:
The following tests cover the message validation.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation processes of suspicious messages.
TAHI Project TECHNICAL DOCUMENT
628
KINK Test Specification
SGW.SGW.R.9.1: Sending INVALID-PAYLOAD-TYPE against the unrecognized
ISAKMP payload
Purpose:
Verify that a node properly rejects unrecognized ISAKMP payload
References:
- [KINK] - Section 5.5
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
629
KINK Test Specification
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However KINK_ISAKMP Payload must be set as following.
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
TAHI Project TECHNICAL DOCUMENT
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
0x10000000
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Group Description (3)
1024 MODP Group (2)
TV (1)
Encapsulation Mode (4)
630
KINK Test Specification
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
Unrecognized Payload
Next Payload:
RESERVED:
Payload Length:
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
8 bytes length random data
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link Y
(Prefix Y::/64)
unrecognized (0xff)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link B
(Prefix B::/64)
NONE (0)
0
4
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must respond to CREATE with properly formatted IPsec DOI-specific
error described as following.
INVALID-PAYLOAD-TYPE
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
631
KINK Test Specification
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
N Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-ID:
SPI Size:
Notify Message Type:
Notification Data:
Cksum:
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
N (11)
1
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
0
INVALID-PAYLOAD-TYPE (1)
ANY
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
* The shaded region in Common Observed Packet #6 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
unencrypted INVALID-PAYLOAD-TYPE
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
632
KINK Test Specification
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
raw data of Kerberos AP-REP
AP-REP:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
N Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Protocol-ID:
SPI Size:
Notify Message Type:
Notification Data:
Cksum:
KINK_DONE (0)
0
the actual length of this payload in octets
N (11)
1
0
0
NONE (0)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
PROTO_IPSEC_ESP (3)
0
INVALID-PAYLOAD-TYPE (1)
ANY
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
633
KINK Test Specification
SGW.SGW.R.9.2: Checksum Verification
Purpose:
Verify that a node properly rejects the message containing invalid checksum
References:
- [KINK] – Chapter 4
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
634
KINK Test Specification
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However, Cksum is overwritten by the data that all bits set to one.
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must not respond to CREATE message.
Possible Problems:
- None.
TAHI Project TECHNICAL DOCUMENT
635
KINK Test Specification
SGW.SGW.R.9.3: Sending KINK_INVMAJ
Purpose:
Verify that a node properly rejects a message containing unsupported KINK version
number in the header
References:
- [KINK] - Subsection 4.2.8
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
636
KINK Test Specification
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However, MjVer is set to 0xf.
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must respond to CREATE with REPLY message described as following
to indicate KINK error.
KINK_INVMAJ
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
REPLY (3)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
1
NextPayload:
KINK_ERROR (8)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_ERROR Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
ErrorCode:
KINK_INVMAJ (3)
Possible Problems:
TAHI Project TECHNICAL DOCUMENT
637
KINK Test Specification
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
TAHI Project TECHNICAL DOCUMENT
638
KINK Test Specification
SGW.SGW.R.9.4: Sending KINK_BADQMVERS
Purpose:
Verify that a node properly rejects a message containing ISAKMP version which is
greater than the highest currently supported version
References:
- [KINK] – Chapter 12
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
Part A: bad major version (BASIC)
TAHI Project TECHNICAL DOCUMENT
639
KINK Test Specification
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However, QMMaj is set to 0xf.
2. Observe the packets transmitted by the NUT on Link A.
Part B: bad minor version (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However, QMMin is set to 0xf.
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must respond to CREATE with REPLY message described as following
to indicate KINK error.
KINK_BADQMVERS
IPv6
Next Header:
Source Address:
Destination Address:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
640
KINK Test Specification
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
1
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the same value as REPLY message
in CREATE Message Flow
AP-REP:
raw data of Kerberos AP-REP
KINK_ENCRYPT Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length:
the actual length of this payload in octets
InnerNextPload:
KINK_ERROR (8)
RESERVED2:
0
KINK_ERROR Payload
Next Payload:
KINK_ISAKMP (6)
RESERVED:
0
Payload Length: the actual length of this payload in octets
ErrorCode:
KINK_BADQMVERS (6)
KINK_ISAKMP Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
InnerNextPload: NONE (0)
QMMaj:
1
QMMin:
0
RESERVED:
0
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
* The shaded region in Common Observed Packet #6 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
unencrypted KINK_BADQMVERS
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
641
KINK Test Specification
DOI:
Internet IP Security DOI (1)
XID:
1
NextPayload:
KINK_AP_REP (2)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_AP_REP Payload
Next Payload:
KINK_ERROR (8)
RESERVED:
0
Payload Length: the actual length of this payload in octets
EPOCH:
the same value as REPLY message
in CREATE Message Flow
AP-REP:
raw data of Kerberos AP-REP
KINK_ERROR Payload
Next Payload:
KINK_ISAKMP (6)
RESERVED:
0
Payload Length: the actual length of this payload in octets
ErrorCode:
KINK_BADQMVERS (6)
KINK_ISAKMP Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
InnerNextPload: NONE (0)
QMMaj:
1
QMMin:
0
RESERVED:
0
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
642
KINK Test Specification
SGW.SGW.R.9.5: Receipt of unnecessary data after the message
Purpose:
Verify that a node properly proccesses a message which has unnecessary data after
the message
References:
- [KINK] – Chapter 4
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
643
KINK Test Specification
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However, 8 bytes extra UDP data that all bits set to zero is added after
KINK message.
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
TAHI Project TECHNICAL DOCUMENT
644
KINK Test Specification
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
645
KINK Test Specification
SGW.SGW.R.9.6: Receipt of CREATE with non-zero value in reserved field
Purpose:
Verify that a node properly ignores reserved field in CREATE message
References:
- [KINK] – Chapter 4
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
646
KINK Test Specification
TN1 (SGW)
initiator
NUT (SGW)
responder
Packet #1
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
(optimistic proposal, but Nr was added by the responder)
(2-way handshake)
NUT (SGW)
responder
(3-way handshake)
TN1 (SGW)
initiator
NUT (SGW)
responder
Judgment #1
TN1 (SGW)
initiator
Judgment #1
REPLY, AP_REP,
E{ISAKMP(SA(P(T)), IDi, IDr)}
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T)), Nr, IDi, IDr)}
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However, Reserved Field in CREATE message must be set as following.
KINK
RESRVED:
0xf
RESERVED2:
0x7f
KINK_AP_REQ Payload
RESERVED:
0xff
KINK_ENCRYPT Payload
RESERVED:
0xff
RESERVED2:
0xffffff
KINK_ISAKMP Payload
RESERVED: 0xff
RESERVED: 0xffff
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
TAHI Project TECHNICAL DOCUMENT
647
KINK Test Specification
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
648
KINK Test Specification
SGW.SGW.R.9.7: Receipt of ACK with non-zero value in reserved field
Purpose:
Verify that a node properly ignores reserved field in ACK message
References:
- [KINK] – Chapter 4
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
below.
TN1 will propose multiple Transform payloads as described
Transform #2 will be selected by NUT.
Transform #
1
2
IPsec encryption algorithm
ESP_AES-CBC (12)
ESP_3DES (3)
IPsec authentication algorithm
AES-XCBC-MAC (9)
HMAC-SHA (2)
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
649
KINK Test Specification
TN1 (SGW)
initiator
NUT (SGW)
responder
Packet #1
Judgment #1
Packet #2
CREATE, AP_REQ,
E{ISAKMP(SA(P(T1, T2)), Ni, IDi, IDr)}
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T2)), Nr, IDi, IDr)}
ACK, AP_REQ
IPsec ESP tunnel
TH1 (Host)
TH2 (Host)
Pkt #3/Jdg #2
ICMPv6 Echo Request
Pkt #4/Jdg #3
ICMPv6 Echo Reply
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However Proposal Payload must be set as following.
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
TAHI Project TECHNICAL DOCUMENT
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
2
ANY
T (3)
0
the actual length of this payload in octets
1
ESP_AES-CBC (12)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
AES-XCBC-MAC (9)
TV (1)
Key Length (6)
650
KINK Test Specification
Attribute Value:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
128
NONE (0)
0
the actual length of this payload in octets
2
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to REPLY with ACK described as Common Transmitted Packet
#2.
However, Reserved Field in CREATE message must be set as following.
KINK
RESRVED:
0xf
RESERVED2:
0x7f
KINK_AP_REQ Payload
RESERVED:
0xff
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #3 or 4. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
TAHI Project TECHNICAL DOCUMENT
651
KINK Test Specification
follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
652
KINK Test Specification
SGW.SGW.R.9.8: Receipt of GETTGT with non-zero value in reserved field
Purpose:
Verify that a node properly ignores reserved field in GETTGT message
References:
- [KINK] – Chapter 4
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
653
KINK Test Specification
Part A: (BASIC)
1. TN1 transmits GETTGT message described as Common Transmitted Packet
#7.
However, Reserved Field in CREATE message must be set as following.
KINK
RESRVED:
0xf
RESERVED2:
0x7f
KINK_TGT_REQ Payload
RESERVED:
0xff
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must respond to GETTGT with REPLY message described as following
to indicate that the NUT is not allowed to return its TGT.
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
REPLY (3)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
the same value as GETTGT message
NextPayload:
KINK_ERROR (8)
ACKREQ:
true (1)
RESERVED2:
0
CksumLen:
0
KINK_ ERROR Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
ErrorCode:
KINK_U2UDENIED (7)
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
TAHI Project TECHNICAL DOCUMENT
654
The tester must allow
KINK Test Specification
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
655
KINK Test Specification
SGW.SGW.R.9.9: Receipt of unencrypted CREATE
Purpose:
Verify that a node properly processes CREATE message which doesn't encrypted by
KINK_ENCRYPT payload
References:
- [KINK] - Section 6.3
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
656
KINK Test Specification
NUT (SGW)
responder
TN1 (SGW)
initiator
Packet #1
CREATE, AP_REQ, ISAKMP(SA(P(T)), Ni, IDi, IDr)
(optimistic proposal, but Nr was added by the responder)
(2-way handshake)
NUT (SGW)
responder
(3-way handshake)
TN1 (SGW)
initiator
NUT (SGW)
responder
Judgment #1
TN1 (SGW)
initiator
Judgment #1
REPLY, AP_REP,
E{ISAKMP(SA(P(T)), IDi, IDr)}
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T)), Nr, IDi, IDr)}
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
However KINK_ENCRYPT Payload must not appear as described as
following.
KINK
KINK_AP_REQ Payload
KINK_ISAKMP Payload
SA Payload
P Payload
T Payload
Data Attribute
Data Attribute
Data Attribute
Data Attribute
Ni Payload
IDi Payload
IDr Payload
2. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
TAHI Project TECHNICAL DOCUMENT
657
KINK Test Specification
always follow SA Life Type Data Attribute.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
658
KINK Test Specification
SGW.SGW.R.9.10: Receipt of unencrypted DELETE
Purpose:
Verify that a node properly processes DELETE message which doesn't encrypted by
KINK_ENCRYPT payload
References:
- [KINK] - Section 6.4
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
659
KINK Test Specification
(2-way handshake)
NUT (SGW)
responder
(3-way handshake)
NUT (SGW)
responder
TN1 (SGW)
initiator
TN1 (SGW)
initiator
Packet #1
Packet #1
CREATE(XID=0), AP_REQ,
E{ISAKMP(SA(P(SPIi1, T)), Ni, IDi, IDr)}
Judgment #1
Judgment #1
REPLY(XID=0, ACKREQ), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), Nr, IDi, IDr)}
REPLY(XID=0), AP_REP,
E{ISAKMP(SA(P(SPIr1, T)), IDi, IDr)}
Packet #2
ACK(XID=0), AP_REQ
NUT (SGW)
responder
TH1 (Host)
TN1 (SGW)
initiator
TH2 (Host)
Pkt #3/Jdg #2
ICMPv6 Echo Request
Pkt #4/Jdg #3
ICMPv6 Echo Reply
IPsec ESP(SPIi1) tunnel
IPsec ESP(SPIr1) tunnel
(Deleting)
DELETE(XID=1), AP_REQ,
ISAKMP(D(SPIi1))
REPLY(XID=1), AP_REP,
E{ISAKMP(D(SPIr1)))}
Packet #5
Judgment #4
No response
Pkt #6/Jdg #5
ICMPv6 Echo Request
IPsec ESP(SPIr1) tunnel
Part A: (BASIC)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
TAHI Project TECHNICAL DOCUMENT
660
KINK Test Specification
7. Observe the packets transmitted by the NUT on Link A.
8. TN1 transmits DELETE message described as Common Transmitted Packet
#5.
However KINK_ENCRYPT Payload must not appear as described as
following.
KINK
KINK_AP_REQ Payload
KINK_ISAKMP Payload
D Payload
9. Observe the packets transmitted by the NUT on Link A.
10. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
ICMPv6 Identifier is set to one.
11. Observe the packets transmitted by the NUT on Link B.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1.
Step 9: (Judgment #4)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #7 or 8.
Step 11: (Judgment #5)
The NUT must not decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and must not forward to TH1 because SA has already deleted
at Step 9.
Possible Problems:
TAHI Project TECHNICAL DOCUMENT
661
KINK Test Specification
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
662
KINK Test Specification
SGW.SGW.R.9.11: Sending KRB_AP_ERR_SKEW
Purpose:
Verify that a node properly rejects a message when the responder clock and the
initiator clock are off by more than the policy-determinde clock skew limit.
References:
- [KINK] - Section 3.5
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
663
KINK Test Specification
Part A: (BASIC)
1. Set the clock forward 6 minutes on TN1.
2. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
3. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 3: (Judgment #1)
The NUT must respond to CREATE with REPLY message described as following
to indicate Kerberos error.
KRB_AP_ERR_SKEW
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
0
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
664
KINK Test Specification
EPOCH:
the current POSIX time
AP-REP:
raw data of Kerberos AP-REP
KINK_ENCRYPT Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length:
the actual length of this payload in octets
InnerNextPload:
KINK_KRB_ERROR (3)
RESERVED2:
0
KINK_KRB_ERROR Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
KRB-ERROR:
raw Kerberos KRB-ERROR
indicating KRB_AP_ERR_SKEW
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
* The shaded region in Common Observed Packet #6 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
unencrypted KRB_AP_ERR_SKEW
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
REPLY (3)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
0
NextPayload:
KINK_AP_REP (2)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_AP_REP Payload
Next Payload:
KINK_KRB_ERROR (3)
RESERVED:
0
Payload Length: the actual length of this payload in octets
EPOCH:
the current POSIX time
AP-REP:
raw data of Kerberos AP-REP
KINK_KRB_ERROR Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
KRB-ERROR:
raw Kerberos KRB-ERROR
indicating KRB_AP_ERR_SKEW
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Possible Problems:
TAHI Project TECHNICAL DOCUMENT
665
KINK Test Specification
- None.
TAHI Project TECHNICAL DOCUMENT
666
KINK Test Specification
Section 2.2: SGW to EN Tunnel
Scope:
The following tests cover the endpoint to security gateway tunnel mode scenario.
In
this endpoint to security gateway tunnel mode scenario, a protected endpoint connects
back to its network through an IPsec-protected tunnel.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation uses the tunnel mode IPsec to
protect the communication between an endpoint behind the KINK implementation and
an another endpoint.
Default Network Topology:
The logical network topology involves EN, SGW, KDC, Host and Router on each link.
The shaded region labelled as <TN> in Fig 7 is done inside TN node logically.
The
tunnel mode is used in this network topology as shown as Fig 8.
TAHI Project TECHNICAL DOCUMENT
667
KINK Test Specification
Fig 7 SGW to EN Common Network Topology for NUT (SGW)
tunnel mode
NUT (SGW)
Link B
TN1 (EN)
Fig 8 SGW to EN Tunnel Scenario for NUT (SGW)
Default NUT (SGW) Configuration:
- IP configuration:
Address
Default router
NUT - Link A
(Prefix A::<any_interface_ID>)
NUT - Link B
(Prefix B::<any_interface_ID>)
TR1 - Link A
(fe80::f)
- Kerberos configuration:
KDC
Principal Name
Pre-shared Key
Encryption Type
Checksum Type
User-to-User authentication
KDC - Link X
(Prefix X::e)
"kink/[email protected]"
"KINKtest0123456789abcdefABCDEF!?"
AES256-CTS-HMAC-SHA1-96 (18)
HMAC-SHA1-96-AES256 (16)
disable
TAHI Project TECHNICAL DOCUMENT
668
KINK Test Specification
- KINK configuration:
Address
Port
Principal Name
PFS
IDi
IDr
ID Type
Protocol ID
Port
Identification
Data
Local
NUT - Link A
(Prefix A::<any_interface_ID>)
910
"kink/nut.example.com
@EXAMPLE.COM"
disable
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link B
(Prefix B::/64)
Remote
TN1 - Link X
(Prefix X::1)
910
"kink/tn.example.com
@EXAMPLE.COM"
disable
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
- IPsec configuration:
IPsec Security Protocol
IPsec ESP Transform
SA Life Type (1)
SA Life Duration (2)
Encapsulation Mode (4)
Authentication Algorithm (5)
Inbound
Outbound
PROTO_IPSEC_ESP (3) PROTO_IPSEC_ESP (3)
ESP_3DES (3)
ESP_3DES (3)
Seconds (1)
Seconds (1)
28,800
28,800
Tunnel (1)
Tunnel (1)
HMAC-SHA (2)
HMAC-SHA (2)
If NUT is the initiator, above proposal must be one of proposals from NUT.
If NUT is the responder, NUT must select above proposal.
TAHI Project TECHNICAL DOCUMENT
669
KINK Test Specification
Subsection 2.2.1: Initiator
Scope:
In KINK exchanges, either of endpoints initiates the exchange by sending the command
and the another responds to this command with the response.
The following tests
cover KINK exchanges when the KINK implementation initiates these exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation initiates KINK exchanges.
Default Packets:
Packets sent from TN:
Common Packets to be transmitted from TN are defined as the following. Tests in
this test group may refer to these packets.
Common Transmitted Packet #1: REPLY for CREATE
IPv6
Next Header:
Source Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
TAHI Project TECHNICAL DOCUMENT
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
0
KINK_AP_REP (2)
false (0)
the same value as CREATE message
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the current POSIX time
670
KINK Test Specification
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
TAHI Project TECHNICAL DOCUMENT
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
IDi (5)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
0x10000000
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link B
(Prefix B::/64)
NONE (0)
671
KINK Test Specification
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
* The shaded region in Common Transmitted Packet #1 is encrypted by
Kerberos encrypt function with Key Usage Number 39 (KINK_ENCRYPT
payload).
Common Transmitted Packet #2: IPsec ESP { ICMPv6 Echo Request }
IPv6
Next Header:
Source Address:
ESP (50)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
Destination Address:
ESP
SPI:
Sequence Number:
IV:
proposed by CREATE from NUT
1
8 bytes length stream
that all bits are set to zero
IPv6
Next Header:
Source Address:
IPv6-ICMP (58)
TN1 - Link X
(Prefix X::1)
TH1 - Link B
(Prefix B::d)
Destination Address:
ICMPv6
Type:
Code:
Checksum:
Identifier:
Sequence Number:
Data:
Padding:
Pad Length:
Next Header:
ICV:
Echo Request (128)
0
ICMPv6 checksum
0
0
8 bytes length stream
that all bits are set to zero
ANY
the actual length of Pad in octets
IPv6 (41)
calculated by HMAC-SHA1-96
using calculated KEYMAT
* The shaded region in Common Transmitted Packet #2 is encrypted by
TripleDES in CBC mode using calculated KEYMAT.
Common Transmitted Packet #3: ICMPv6 Echo Reply
IPv6
Next Header:
Source Address:
TAHI Project TECHNICAL DOCUMENT
IPv6-ICMP (58)
TH1 - Link B
(Prefix B::d)
672
KINK Test Specification
Destination Address:
TN1 - Link X
(Prefix X::1)
ICMPv6
Type:
Code:
Checksum:
Identifier:
Sequence Number:
Data:
Echo Reply (129)
0
ICMPv6 checksum
0
0
8 bytes length stream
that all bits are set to zero
Packets sent from NUT:
Common Packets to be transmitted from NUT are defined as the following. Tests
in this test group may refer to these packets.
Common Observed Packet #1: CREATE
IPv6
Next Header:
Source Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REQ Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REQ:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
TAHI Project TECHNICAL DOCUMENT
kink (910)
kink (910)
CREATE (1)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
ANY
KINK_AP_REQ (1)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REQ
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Ni (10)
673
KINK Test Specification
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
ANY
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link B
(Prefix B::/64)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
* The shaded region in Common Observed Packet #1 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
TAHI Project TECHNICAL DOCUMENT
674
KINK Test Specification
Common Observed Packet #2: unencrypted CREATE
IPv6
Next Header:
Source Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REQ Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REQ:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
TAHI Project TECHNICAL DOCUMENT
kink (910)
kink (910)
CREATE (1)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
ANY
KINK_AP_REQ (1)
false (0)
0
the actual length of Cksum
KINK_ISAKMP (6)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REQ
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
675
KINK Test Specification
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
ANY
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link B
(Prefix B::/64)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
Common Observed Packet #3: ICMPv6 Echo Request
IPv6
Next Header:
Source Address:
IPv6-ICMP (58)
TN1 - Link X
(Prefix X::1)
TH1 - Link B
(Prefix B::d)
Destination Address:
ICMPv6
Type:
Code:
Checksum:
Identifier:
Sequence Number:
Data:
Echo Request (128)
0
ICMPv6 checksum
0
0
8 bytes length stream
that all bits are set to zero
Common Observed Packet #4: IPsec ESP { ICMPv6 Echo Reply }
IPv6
Next Header:
Source Address:
Destination Address:
ESP (50)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
ESP
TAHI Project TECHNICAL DOCUMENT
676
KINK Test Specification
SPI:
Sequence Number:
IV:
IPv6
Next Header:
Source Address:
0x10000000
ANY
ANY
IPv6-ICMP (58)
TH1 - Link B
(Prefix B::d)
TN1 - Link X
(Prefix X::1)
Destination Address:
ICMPv6
Type:
Code:
Checksum:
Identifier:
Sequence Number:
Data:
Padding:
Pad Length:
Next Header:
ICV:
Echo Reply (129)
0
ICMPv6 checksum
0
0
8 bytes length stream
that all bits are set to zero
ANY
the actual length of Pad in octets
IPv6 (41)
calculated by HMAC-SHA1-96
using calculated KEYMAT
* The shaded region in Common Observed Packet #4 is encrypted by TripleDES
in CBC mode using calculated KEYMAT.
TAHI Project TECHNICAL DOCUMENT
677
KINK Test Specification
Group 1: CREATE Message Flow
Scope:
In KINK exchanges, either of endpoints initiates the exchange by sending the command
and the another responds to this command with the response.
The following tests
cover the CREATE message flows when the KINK implementation initiates these
exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation initiates CREATE message flows.
TAHI Project TECHNICAL DOCUMENT
678
KINK Test Specification
SGW.EN.I.1.1: CREATE Message Flow (2-way handshake)
Purpose:
Verify that an initiator properly establish SA by CREATE message flow
References:
- [KINK] - Section 3.2
- [KINK] - Section 6.3
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
NUT must obtain TN1's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
679
KINK Test Specification
Part A: (ADVANCED)
1. NUT starts to negotiate with TN1 by sending CREATE message.
2. Observe the packets transmitted by the NUT on Link A.
3. TN1 responds to CREATE with REPLY described as Common Transmitted
Packet #1.
4. After responding to CREATE, TN1 transmits ICMPv6 Echo Request
encrypted by ESP described as Common Transmitted Packet #2.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #3.
7. Observe the packets transmitted by the NUT on Link A.
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted CREATE message described as
Common Observed Packet #1 or 2. Data Attributes in Transform payload can be
placed in any order excepting that SA Life Duration Data Attribute is always
follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #3 and forward to TH1.
Step 7: (Judgment #3)
TAHI Project TECHNICAL DOCUMENT
680
KINK Test Specification
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #4 to TN1.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
681
KINK Test Specification
Subsection 2.2.2: Responder
Scope:
In KINK exchanges, either of endpoints initiates the exchange by sending the command
and the another responds to this command with the response.
The following tests
cover KINK exchanges when the KINK implementation responds to these exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation initiates KINK exchanges.
Default Packets:
Packets sent from TN:
Common Packets to be transmitted from TN are defined as the following. Tests in
this test group may refer to these packets.
Common Transmitted Packet #1: CREATE
IPv6
Next Header:
Source Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REQ Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REQ:
TAHI Project TECHNICAL DOCUMENT
kink (910)
kink (910)
CREATE (1)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
0
KINK_AP_REQ (1)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REQ
682
KINK Test Specification
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Ni Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Ni (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
0x10000000
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
8 bytes length random data
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
IDr Payload
TAHI Project TECHNICAL DOCUMENT
683
KINK Test Specification
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link B
(Prefix B::/64)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
* The shaded region in Common Transmitted Packet #1 is encrypted by
Kerberos encrypt function with Key Usage Number 39 (KINK_ENCRYPT
payload).
Common Transmitted Packet #2: ACK
IPv6
Next Header:
Source Address:
Destination Address:
UDP (17)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
UDP
Source Port:
kink (910)
Destination Port:
kink (910)
KINK
Type:
ACK (5)
MjVer:
1
RESRVED:
0
Length:
the actual length of this message in octets
DOI:
Internet IP Security DOI (1)
XID:
0
NextPayload:
KINK_AP_REQ (1)
ACKREQ:
false (0)
RESERVED2:
0
CksumLen:
the actual length of Cksum
KINK_AP_REQ Payload
Next Payload:
KINK_DONE (0)
RESERVED:
0
Payload Length: the actual length of this payload in octets
EPOCH:
the same value as CREATE message
AP-REQ:
raw data of Kerberos AP-REQ
Cksum:
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Common Transmitted Packet #3: IPsec ESP { ICMPv6 Echo Request }
IPv6
Next Header:
Source Address:
Destination Address:
ESP
SPI:
Sequence Number:
TAHI Project TECHNICAL DOCUMENT
ESP (50)
TN1 - Link X
(Prefix X::1)
NUT - Link A
(Prefix A::<any_interface_ID>)
proposed by REPLY from NUT
in CREATE Message Flow
1
684
KINK Test Specification
IV:
8 bytes length stream
that all bits are set to zero
IPv6
Next Header:
Source Address:
IPv6-ICMP (58)
TN1 - Link X
(Prefix X::1)
TH1 - Link B
(Prefix B::d)
Destination Address:
ICMPv6
Type:
Code:
Checksum:
Identifier:
Sequence Number:
Data:
Padding:
Pad Length:
Next Header:
ICV:
Echo Request (128)
0
ICMPv6 checksum
0
0
8 bytes length stream
that all bits are set to zero
ANY
the actual length of Pad in octets
IPv6 (41)
calculated by HMAC-SHA1-96
using calculated KEYMAT
* The shaded region in Common Transmitted Packet #2 is encrypted by
TripleDES in CBC mode using calculated KEYMAT.
Common Transmitted Packet #4: ICMPv6 Echo Reply
IPv6
Next Header:
Source Address:
IPv6-ICMP (58)
TH1 - Link B
(Prefix B::d)
TN1 - Link X
(Prefix X::1)
Destination Address:
ICMPv6
Type:
Code:
Checksum:
Identifier:
Sequence Number:
Data:
Echo Reply (129)
0
ICMPv6 checksum
0
0
8 bytes length stream
that all bits are set to zero
Packets sent from NUT:
Common Packets to be transmitted from NUT are defined as the following. Tests
in this test group may refer to these packets.
Common Observed Packet #1: REPLY for CREATE
IPv6
Next Header:
Source Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
TAHI Project TECHNICAL DOCUMENT
685
KINK Test Specification
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
686
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message
Internet IP Security DOI (1)
0
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
IDi (5)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
KINK Test Specification
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link B
(Prefix B::/64)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
* The shaded region in Common Observed Packet #1 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
Common Observed Packet #2: unencrypted REPLY for CREATE
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REP:
KINK_ISAKMP Payload
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message
Internet IP Security DOI (1)
0
KINK_AP_REP (2)
false (0)
0
the actual length of Cksum
KINK_ISAKMP (6)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REP
687
KINK Test Specification
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
Cksum:
TAHI Project TECHNICAL DOCUMENT
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
IDi (5)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link B
(Prefix B::/64)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
688
KINK Test Specification
Common Observed Packet #3: REPLY with Nr for CREATE
IPv6
Next Header:
Source Address:
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REP:
KINK_ENCRYPT Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
RESERVED2:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
TAHI Project TECHNICAL DOCUMENT
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message in octets
Internet IP Security DOI (1)
0
KINK_AP_REP (2)
true (1)
0
the actual length of Cksum
KINK_ENCRYPT (7)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
KINK_ISAKMP (6)
0
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Nr (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
689
KINK Test Specification
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Nr Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
ANY
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
ANY (0)
TN1 - Link X
(Prefix X::1)
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link B
(Prefix B::/64)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
* The shaded region in Common Observed Packet #3 is encrypted by Kerberos
encrypt function with Key Usage Number 39 (KINK_ENCRYPT payload).
Common Observed Packet #4: unencrypted REPLY with Nr for CREATE
IPv6
Next Header:
Source Address:
Destination Address:
UDP
Source Port:
Destination Port:
KINK
Type:
MjVer:
RESRVED:
Length:
DOI:
XID:
TAHI Project TECHNICAL DOCUMENT
UDP (17)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
kink (910)
kink (910)
REPLY (3)
1
0
the actual length of this message
Internet IP Security DOI (1)
0
690
KINK Test Specification
NextPayload:
ACKREQ:
RESERVED2:
CksumLen:
KINK_AP_REP Payload
Next Payload:
RESERVED:
Payload Length:
EPOCH:
AP-REP:
KINK_ISAKMP Payload
Next Payload:
RESERVED:
Payload Length:
InnerNextPload:
QMMaj:
QMMin:
RESERVED:
SA Payload
Next Payload:
RESERVED:
Payload Length:
DOI:
Situation:
P Payload
Next Payload:
RESERVED:
Payload Length:
Proposal #:
Protocol-Id:
SPI Size:
# of Transforms:
SPI:
T Payload
Next Payload:
RESERVED:
Payload Length:
Transform #:
Transform-Id:
RESERVED2:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Data Attribute
Attribute Format:
Attribute Type:
Attribute Value:
Nr Payload
Next Payload:
RESERVED:
Payload Length:
Nonce Data:
IDi Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
TAHI Project TECHNICAL DOCUMENT
KINK_AP_REP (2)
true (1)
0
the actual length of Cksum
KINK_ISAKMP (6)
0
the actual length of this payload in octets
the current POSIX time
raw data of Kerberos AP-REP
KINK_DONE (0)
0
the actual length of this payload in octets
SA (1)
1
0
0
Nr (10)
0
the actual length of this payload in octets
Internet IP Security DOI (1)
SIT_IDENTITY_ONLY (1)
NONE (0)
0
the actual length of this payload in octets
1
PROTO_IPSEC_ESP (3)
4
1
ANY
NONE (0)
0
the actual length of this payload in octets
1
ESP_3DES (3)
0
TV (1)
SA Life Type (1)
Seconds (1)
TV (1)
SA Life Duration (2)
28,800
TV (1)
Encapsulation Mode (4)
Tunnel (1)
TV (1)
Authentication Algorithm (5)
HMAC-SHA (2)
IDi (5)
0
the actual length of this payload in octets
ANY
IDr (5)
0
the actual length of this payload in octets
ID_IPV6_ADDR (5)
IPv6-ICMP (58)
691
KINK Test Specification
Port:
Identification Data:
ANY (0)
TN1 - Link X
(Prefix X::1)
IDr Payload
Next Payload:
RESERVED:
Payload Length:
ID Type:
Protocol ID:
Port:
Identification Data:
NONE (0)
0
the actual length of this payload in octets
ID_IPV6_ADDR_SUBNET (6)
IPv6-ICMP (58)
ANY (0)
Link B
(Prefix B::/64)
output of the Kerberos 5 get_mic function
with Key Usage Number 40 (Cksum field)
Cksum:
Common Observed Packet #5: ICMPv6 Echo Request
IPv6
Next Header:
Source Address:
IPv6-ICMP (58)
TN1 - Link X
(Prefix X::1)
TH1 - Link B
(Prefix B::d)
Destination Address:
ICMPv6
Type:
Code:
Checksum:
Identifier:
Sequence Number:
Data:
Echo Request (128)
0
ICMPv6 checksum
0
0
8 bytes length stream
that all bits are set to zero
Common Observed Packet #6: IPsec ESP { ICMPv6 Echo Reply }
IPv6
Next Header:
Source Address:
ESP (50)
NUT - Link A
(Prefix A::<any_interface_ID>)
TN1 - Link X
(Prefix X::1)
Destination Address:
ESP
SPI:
Sequence Number:
IV:
IPv6
Next Header:
Source Address:
0x10000000
ANY
ANY
IPv6-ICMP (58)
TH1 - Link B
(Prefix B::d)
TN1 - Link X
(Prefix X::1)
Destination Address:
ICMPv6
Type:
Code:
Checksum:
Identifier:
Sequence Number:
Data:
Padding:
Pad Length:
Next Header:
TAHI Project TECHNICAL DOCUMENT
Echo Reply (129)
0
ICMPv6 checksum
0
0
8 bytes length stream
that all bits are set to zero
ANY
the actual length of Pad in octets
IPv6 (41)
692
KINK Test Specification
ICV:
calculated by HMAC-SHA1-96
using calculated KEYMAT
* The shaded region in Common Observed Packet #4 is encrypted by TripleDES
in CBC mode using calculated KEYMAT.
TAHI Project TECHNICAL DOCUMENT
693
KINK Test Specification
Group 1: CREATE Message Flow
Scope:
In KINK exchanges, either of endpoints initiates the exchange by sending the command
and the another responds to this command with the response.
The following tests
cover the CREATE message flows when the KINK implementation initiates these
exchanges.
Overview:
These tests are designed to verify the readiness of a KINK implementation vis-a-vis the
KINK specification when the KINK implementation responds to CREATE message
flows.
TAHI Project TECHNICAL DOCUMENT
694
KINK Test Specification
SGW.EN.R.1.1: CREATE Message Flow
Purpose:
Verify that a responder properly establish SA by CREATE message flow
References:
- [KINK] - Section 3.2
- [KINK] - Section 6.3
Resource Requirements:
- Packet generator
- Monitor to capture packets
- KDC
Test Setup:
- Network Topology
Connect the devices according to the Default Network Topology.
- Configuration
In each part, configure devices according to the Default NUT (SGW)
Configuration.
- Pre-Procedure and Cleanup Procedure
Before each part, initialize NUT and synchronize TN and NUT clock.
TN1 and NUT must obtain TGT from their KDC.
Both
TN1 must obtain NUT's
service ticket from its KDC.
Procedure:
TAHI Project TECHNICAL DOCUMENT
695
KINK Test Specification
NUT (SGW)
responder
TN1 (EN)
initiator
CREATE, AP_REQ,
E{ISAKMP(SA(P(T)), Ni, IDi, IDr)}
Packet #1
(optimistic proposal, but Nr was added by the responder)
(2-way handshake)
NUT (SGW)
responder
(3-way handshake)
NUT (SGW)
responder
TN1 (EN)
initiator
Judgment #1
TN1 (EN)
initiator
Judgment #1
REPLY(ACKREQ), AP_REP,
E{ISAKMP(SA(P(T)), Nr, IDi, IDr)}
REPLY, AP_REP,
E{ISAKMP(SA(P(T)), IDi, IDr)}
Packet #2
ACK, AP_REQ
TH1 (Host)
NUT (SGW)
responder
TN1 (EN)
initiator
ICMPv6 Echo Request
Pkt #3/Jdg #2
Pkt #4/Jdg #3
ICMPv6 Echo Reply
IPsec ESP tunnel
Part A: (ADVANCED)
1. TN1 transmits CREATE message described as Common Transmitted Packet
#1.
2. Observe the packets transmitted by the NUT on Link A.
3. If REPLY from NUT includes Nonce Payload and ACKREQ bit is set, TN1
responds to REPLY with ACK described as Common Transmitted Packet #2.
4. TN1 transmits ICMPv6 Echo Request encrypted by ESP described as
Common Transmitted Packet #3.
5. Observe the packets transmitted by the NUT on Link B.
6. TH1 responds to ICMPv6 Echo Request with ICMPv6 Echo Reply described as
Common Transmitted Packet #4.
7. Observe the packets transmitted by the NUT on Link A.
TAHI Project TECHNICAL DOCUMENT
696
KINK Test Specification
Observable Results:
Part A:
Step 2: (Judgment #1)
The NUT must transmit properly formatted REPLY message described as
Common Observed Packet #1, 2, 3 or 4.
Data Attributes in Transform payload
can be placed in any order excepting that SA Life Duration Data Attribute is
always follow SA Life Type Data Attribute.
Step 5: (Judgment #2)
The NUT must decapsulate protected ICMPv6 Echo Request as Common
Observed Packet #5 and forward to TH1.
Step 7: (Judgment #3)
The NUT must forward properly formatted ICMPv6 Echo Reply encrypted by
ESP described as Common Observed Packet #6 to TN1.
Possible Problems:
- An implementation may add Notification Payload indicating status (not error) or
Vendor ID Payload into KINK_ISAKMP payload by its policy.
The tester must allow
them.
- SA Life Duration Data Attribute sent from NUT may have Variable-Length format
described as below.
Data Attribute
Attribute Format:
Attribute Type:
Attribute Length:
Attribute Value:
TAHI Project TECHNICAL DOCUMENT
TLV (0)
SA Life Duration (2)
ANY
28,800
697
KINK Test Specification
********************************************************************************
All Rights Reserved. Copyright (C) 2010
Yokogawa Electric Corporation
No part of this documentation may be reproduced for any purpose without prior permission.
TAHI Project TECHNICAL DOCUMENT
698
KINK Test Specification

Similar documents