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/nut.example.com@EXAMPLE.COM" "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/tn.example.com@EXAMPLE.COM 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/nut.example.com@EXAMPLE.COM 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/nut.example.com@EXAMPLE.COM" "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/nut.example.com@EXAMPLE.COM" "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/tn.example.com@EXAMPLE.COM 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/nut.example.com@EXAMPLE.COM 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/nut.example.com@EXAMPLE.COM" "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