idnits 2.17.1 draft-ietf-ipsec-isakmp-gss-auth-07.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 71: '... The keywords MUST, MUST NOT, REQUIR...' RFC 2119 keyword, line 72: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 84: '... initiator MAY provide multiple p...' RFC 2119 keyword, line 85: '... responder MUST reply with only o...' RFC 2119 keyword, line 166: '...by a '*' after the ISAKMP header) MUST...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 14, 2001) is 8322 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Bra96' is mentioned on line 13, but not defined == Missing Reference: 'RFC 2119' is mentioned on line 74, but not defined == Missing Reference: 'RFC2478' is mentioned on line 396, but not defined ** Obsolete undefined reference: RFC 2478 (Obsoleted by RFC 4178) == Missing Reference: 'RFC1964' is mentioned on line 403, but not defined == Missing Reference: 'RFC2025' is mentioned on line 408, but not defined -- Looks like a reference, but probably isn't: '2' on line 426 Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Derrell Piper 2 INTERNET-DRAFT Nokia 3 draft-ietf-ipsec-isakmp-gss-auth-07.txt Brian Swander 4 Microsoft 5 July 14, 2001 7 A GSS-API Authentication Method for IKE 8 10 Status of this Memo 12 This document is an Internet Draft and is in full conformance with 13 all provisions of Section 10 of RFC-2026 [Bra96]. Internet Drafts are 14 working documents of the Internet Engineering Task Force (IETF), its 15 areas, and working groups. Note that other groups may also 16 distribute working documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/1id-abstracts.html 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 To learn the current status of any Internet Draft, please check the 30 "1id-abstracts.txt" listing contained in the Internet Drafts Shadow 31 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 32 munnari.oz.au (Australia), ds.internic.net (US East Coast), or 33 ftp.isi.edu (US West Coast). 35 Table of Contents 37 1. Abstract......................................................2 38 2. Terms and Definitions.........................................2 39 3. Discussion....................................................4 40 3.1 SKEYID Generation for GSS-API.................................6 41 3.2 IKE Phase 1 Authentication for GSS-API........................7 42 3.3 GSS-API Identifiers: Method, Attribute, and Payload...........8 43 3.4 The GSS-API Authentication Method Vendor ID Signature.........10 44 4. Change Log....................................................10 45 5. Security Considerations.......................................11 46 Acknowledgments...................................................12 47 References........................................................12 48 Authors' Address..................................................12 50 1. Abstract 52 This document describes an alternate authentication method for IKE 53 which makes use of GSS-API to authenticate the Diffie-Hellman 54 exchange. The mechanism described here extends the authentication 55 methods defined in RFC-2409 without introducing any modifications to 56 the IKE key exchange protocol. 58 It also documents the Microsoft Windows 2000 implementation of this 59 protocol, which uses Kerberos via the Microsoft SSPI interface to 60 authenticate Windows 2000 machines within a Window 2000 domain, 61 within trusted Windows 2000 domains, and when Windows 2000 is 62 operating in MIT-Kerberos compatibility mode, such that Windows 2000 63 systems are members of the MIT-KDC realm or the MIT-KDC realm has 64 Kerberos trust with the Windows 2000 domain. 66 For a list of changes since the previous version of this document, 67 please see Section 4. 69 2. Terms and Definitions 71 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 72 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 73 document, are to be interpreted as described in [RFC 2119]. 75 2.1 Notation 77 RFC-2409 uses the following notation throughout that draft. That 78 notation is included here along with a few additions. 80 HDR is an ISAKMP header whose exchange type is the method. When 81 written as HDR* it indicates payload encryption. 83 SA is an SA negotiation payload with one or more proposals. An 84 initiator MAY provide multiple proposals for negotiation; a 85 responder MUST reply with only one. 87

_b indicates the body of payload

-- the ISAKMP generic 88 payload is not included. 90 SAi_b is the entire body of the SA payload (minus the ISAKMP 91 generic header)-- i.e. the DOI, situation, all proposals and all 92 transforms offered by the Initiator. 94 CKY-I and CKY-R are the Initiator's cookie and the Responder's 95 cookie, respectively, from the ISAKMP header. 97 g^xi and g^xr are the Diffie-Hellman public values of the 98 initiator and responder respectively. 100 g^xy is the Diffie-Hellman shared secret. 102 GIi and GIr are identity name strings for the GSS-API initiator 103 and responder GSS-API endpoints. These name strings are private 104 to GSS-API. 106 GSSi and GSSr are initiator and responder GSS-API tokens generated 107 by the local GSS-API's using GSS_Init_sec_context and 108 GSS_Accept_sec_context respectively. 110 GSSi(n) and GSSr(n) are optional tokens which may be included for 111 additional GSS-API token exchanges in IKE Main Mode when either 112 side encounters GSS_S_CONTINUE_NEEDED from its underlying GSS-API 113 mechanism. 115 KE is the key exchange payload which contains the public 116 information exchanged in a Diffie-Hellman exchange. There is no 117 particular encoding used for the data of a KE payload. 119 Nx is the nonce payload; x can be: i or r for the ISAKMP initiator 120 and responder respectively. 122 IDx is the identity payload for "x". x can be: "ii" or "ir" for 123 the ISAKMP initiator and responder respectively during phase one 124 negotiation; or "ui" or "ur" for the user initiator and responder 125 respectively during phase two. The ID payload format for the 126 Internet DOI is defined in RFC-2407. 128 HASH (and any derivative such as HASH(2) or HASH_I) is the hash 129 payload. The contents of the hash are specific to the 130 authentication method. 132 prf(key, msg) is the keyed pseudo-random function-- often a keyed 133 hash function-- used to generate a deterministic output that 134 appears pseudo-random. prf's are used both for key derivations 135 and for authentication (i.e. as a keyed MAC). 137 SKEYID is a string derived from secret material known only to the 138 active players in the exchange. 140 SKEYID_e is the keying material used by the ISAKMP SA to protect 141 it's messages. 143 SKEYID_a is the keying material used by the ISAKMP SA to 144 authenticate it's messages. 146 SKEYID_d is the keying material used to derive keys for non-ISAKMP 147 security associations. 149 y indicates that "x" is encrypted with the key "y". 151 --> signifies "initiator to responder" communication (requests). 153 <-- signifies "responder to initiator" communication (replies). 155 | signifies concatenation of information-- e.g. X | Y is the 156 concatenation of X with Y. 158 [ x ] indicates that x is optional. 160 < x | y > indicates that one of "x" or "y" will be chosen. 162 (n) indicates that this is the n-th instance of this item. 164 2.2 Payload Encryption 166 Payload encryption (when noted by a '*' after the ISAKMP header) MUST 167 begin immediately after the ISAKMP header. When communication is 168 protected, all payloads following the ISAKMP header MUST be 169 encrypted. Encryption keys are generated from SKEYID_e in a manner 170 that is defined for each algorithm. 172 3. Discussion 174 The ISAKMP/Oakley resolution document (RFC-2409) defines a key 175 negotiation protocol that blends the Oakley key determination 176 protocol (RFC-2412) with ISAKMP (RFC-2408) to provide authenticated 177 cryptographic key exchange for use with IP security protocols (e.g. 178 AH/ESP). The IKE negotiation includes an authentication method 179 negotiation which is used to select a scheme to be used for 180 authenticating a Diffie-Hellman key exchange. There are currently 181 five defined authentication methods: pre-shared key, DSS signature, 182 RSA signature, and two forms of RSA encryption. This document 183 defines a new method that uses the Generic Security Services API 184 ([Linn98]) to provide the necessary authentication. 186 The GSS-API abstraction is that a host operating system provides an 187 API to applications that request security services (e.g. integrity 188 protection or confidentiality) through a formal interface (e.g., 189 [Wray98]). GSS-API provides opaque tokens to applications which are 190 responsible for sending the tokens to peer GSS-API implementations, 191 presumably on remote hosts. A by-product of any GSS-API exchange is 192 a one way or mutual authentication using whatever authentication 193 scheme the application chose to bind to when GSS-API was initialized 194 (or whatever was negotiated by SPNEGO (RFC-2478)). Typical 195 authentication packages include Kerberos and SSL. 197 The ISAKMP/Oakley resolution defines a Main Mode and an Aggressive 198 Mode for establishing Security Associations (SA's) between IPSEC 199 hosts. These modes have a fixed set of round-trips: 4.5 or 5 for 200 Main Mode and 1 or 1.5 for Aggressive (depending on whether the 201 Commit bit (RFC-2408, Section 3.1) is used by the responder). 203 When using GSS-API, there's a separate protocol being run by the GSS- 204 API packages on the initiator and on the responder. (Initiator and 205 responder are ISAKMP terms, both are GSS-API clients.) The basic 206 model is that the IKE initiator calls GSS_Init_sec_context (with 207 mutual_req_flag) to construct a GSS-API token and sends this along 208 with the KE and nonce in the second Main Mode exchange. The 209 responder calls GSS_Accept_sec_context on this token and sends the 210 output of GSS_Accept_sec_context (another token) back along with his 211 KE and his nonce. On receipt of the responder's token, the initiator 212 calls GSS_Init_sec_context a second time to complete the mutual 213 authentication. Finally, each side exchanges a HASH payload which 214 has been wrapped using GSS_Wrap. Successfully calling GSS_Unwrap to 215 unwrap the HASH payloads along with verifying the hashes proves 216 possession of the GSS-API shared secret and authenticates the Diffie- 217 Hellman exchange. 219 GSS-API requires that a client identify the target GSS-API endpoint 220 by name. If the initiator does not already know the GSS-API endpoint 221 name of the ISAKMP target, a new Phase 1 attribute can be used to 222 exchange endpoint names during the first Main Mode round trip 223 (Section 3.2). Note that these name string are bound to the exchange 224 but otherwise unauthenticated. The GSS-API endpoint names are also 225 assumed to be opaque. 227 For Windows 2000 compatibility, these opaque blobs are encoded as 228 unicode strings. For instance, for machine 'briansw' in domain 229 'IPSEC.MICROSOFT.COM', the identity is 'briansw@IPSEC.MICROSOFT.COM' 230 (in unicode). This identity is just a particular example, and it 231 should not be assumed that the GSS-API identity is necessarily the 232 machine name + domain name. 234 Since the GSS-API tokens are exchanged during Phase 1 along with the 235 KE payloads, they are not protected by the (yet to be formed) ISAKMP 236 SA. To prevent a cut/paste attack on the GSS-API tokens, it's 237 therefore necessary to include the tokens in the HASH_I and HASH_R 238 computation (Section 3.1). This binds the tokens to a particular 239 ISAKMP exchange. If used, the GSS Identity Name strings MUST also be 240 included in these hash calculations. 242 In addition, the output from the prf for each hash is wrapped using 243 GSS_Wrap. Upon receipt of either hash payload, each side MUST 244 successfully call GSS_Unwrap. This proves possession of the GSS-API 245 shared secret by each peer and prevents an active man-in-the-middle 246 attack from simply forwarding on the GSS-API tokens. The choice of 247 whether to use integrity protection only or integrity with 248 confidentiality is somewhat mechanism specific. However, since the 249 strength of the algorithm chosen necessarily determines the outcome 250 of the authentication for ISAKMP, the strongest possible protection 251 SHOULD be chosen. The following flags should be specified to 252 GSS_Init_sec_context on the initiating side: 254 Flag Requirement 255 ---- ----------- 256 mutual_req_flag MUST 257 integ_req_flag MUST 258 conf_req_flag SHOULD 260 The number of messages in this protocol is dictated by whether or not 261 either endpoint chooses to return GSS_S_CONTINUE_NEEDED. Depending 262 on this, a message could be one of two possible outcomes. This 263 choice in denoted by < opt1 | opt2>. For instance, in Main Mode, the 264 Responder's third message may be either another GSS token or his 265 final HASH payload. This is denoted as, < GSSr(n) | HASH_R >. 267 3.1 SKEYID Generation for GSS-API 269 RFC-2409 defines several authentication methods for Main Mode or 270 Aggressive Mode -- digital signatures, authentication using public 271 key encryption, and pre-shared keys. This document introduces 272 another and defines the value of SKEYID for GSS-API authentication as 273 follows. 275 For GSS-API: SKEYID = prf(Ni_b | Nr_b, g^xy) 277 To authenticate either exchange the initiator of the protocol 278 generates HASH_I and the responder generates HASH_R where: 280 HASH_I = GSS_Wrap(prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | 281 IDii_b [ | GIi ] | GSSi [ | GSSi(n) ... ])) 283 HASH_R = GSS_Wrap(prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | 284 IDir_b [ | GIr ] | GSSr [ | GSSr(n) ... ])) 286 For authentication using GSS-API, the GSS-API package on either side 287 provides authentication of the GSS-API identities, and HASH_I and 288 HASH_R are used to bind the GSS-API identities and tokens to the Main 289 Mode exchange. The GSS_Wrap (and subsequent GSS_Unwrap) proves 290 possession of the GSS-API shared secret for each peer. The initiator 291 MUST specify the mutual_req_flag to request mutual authentication 292 between the two GSS-API packages. A provision is defined for the 293 GSS-API peers to exchange GSS-API identities during Main Mode, at the 294 expense of identity protection for the GSS-API endpoint identities. 296 The content of the HASH_I and HASH_R ISAKMP payloads are the output 297 tokens from GSS_Wrap. The input to GSS_Wrap is the output of the 298 negotiated IKE hash function (prf) over the specified data. In other 299 words, you take the data, hash it with the negotiated hash function, 300 and then call GSS_Wrap on the hash digest. The output of GSS_Wrap is 301 placed in the HASH_I and HASH_R payloads. 303 When the optional GSSi(n) and GSSr(n) tokens are sent in a Main Mode 304 exchange (see Section 3.2). All of the GSS-API tokens exchanged MUST 305 be included in the subsequent HASH_I/HASH_R calculations defined 306 above. 308 3.2 IKE Phase 1 Authentication for GSS-API 310 Using GSS-API, the ancillary information exchanged during the second 311 round-trip are GSS-API tokens; the exchange is authenticated in GSS- 312 API and the GSS-API tokens are bound to the exchange using HASH_I and 313 HASH_R. 315 If the GSS-API requires that the initiator and responder have prior 316 knowledge of the GSS-API endpoint names for each peer, this 317 information may be exchanged during the first round trip (by 318 including the GSS Identity Name attribute in the SA) at the expense 319 of identity protection for the GSS-API endpoints. When the GSS-API 320 requires the exchange of identity names, Aggressive Mode cannot be 321 used. For Windows 2000 compatibility, these entities MUST be 322 exchanged. 324 Additionally, the local GSS-API may choose to make use of additional 325 GSS-API token exchanges, using the optional GSSi2 and GSSr2 tokens, 326 based on local criteria. For example, a GSS-API implementation using 327 Kerberos may choose to make use of an extra round-trip for clock 328 synchronization reasons. These extra round-trips can only be done in 329 Main Mode. When extra messages are used, the HASH_I computation is 330 deferred until each side is "done". 332 Main Mode using GSS-API is defined as 334 Initiator Responder 335 ----------- ----------- 336 HDR, SA --> 337 <-- HDR, SA 339 HDR, KE, Ni, GSSi --> 340 <-- HDR, KE, Nr, GSSr 341 HDR*, IDii, 342 < GSSI(n) | HASH_I> --> 343 <-- HDR*, IDir, 344 < GSSR(n) | HASH_R > 345 [ HDR*, < GSSI(n) | HASH_I > --> 346 <-- HDR*, ] 348 The Main Mode exchange terminates when each side has generated and 349 sent their corresponding HASH token and has successfully processed 350 the other side's HASH token. The HASH token is generated when the 351 underlying GSS-API mechanism returns GSS_S_COMPLETE (as opposed to 352 GSS_S_CONTINUE_NEEDED). The receipt of a HASH token necessarily 353 indicates that the peer is prepared to terminate the GSS-API 354 exchange. 356 Aggressive Mode using GSS-API is defined as 358 Initiator Responder 359 ----------- ----------- 360 HDR, SA, KE, Ni, 361 IDii, GSSi --> 362 <-- HDR, SA, KE, Nr, 363 IDir, GSSr, HASH_R 364 HDR, HASH_I --> 366 Aggressive Mode works only for a single token exchange. If either 367 the initiator's second call or any of the responder's calls encounter 368 GSS_S_CONTINUE_NEEDED, Aggressive Mode cannot be used and each side 369 should fall back to Main Mode. When this occurs, the side 370 encountering the unexpected GSS_S_CONTINUE_NEEDED MUST send an ISAKMP 371 Notify (UNSUPPORTED-EXCHANGE-TYPE) and terminate the Aggressive Mode 372 exchange. 374 3.3 GSS-API Identifiers: Authentication Method, Attribute, and Payload 376 Implementations using the GSS-API Authentication Method will need to 377 agree on the values for the following items, after exchanging 378 recognizable ISAKMP Vendor ID payloads (Section 3.4). 380 3.3.1 Authentication Method (IKE) 382 GSS-API using Kerberos 65001 383 Generic GSS-API 65002 384 GSS-API with SPNEGO 65003 385 GSS-API using SPKM 65004 386 Generic GSS-API 388 Specifies generic GSS-API authentication. The underlying 389 GSS-API implementation is not constrained to use any 390 particular mechanism. The two parties must agree on the 391 underlying mechanism using some out-of-band method. 393 GSS-API with SPNEGO 395 Specifies GSS-API authentication using The Simple and 396 Protected GSS-API Negotiation Mechanism [RFC2478]. SPNEGO 397 ensures that the two parties agree upon a mutually acceptable 398 mechanism. 400 GSS-API using Kerberos 402 Specifies GSS-API authentication using The Kerberos Version 5 403 GSS-API Mechanism [RFC1964]. 405 GSS-API using SPKM 407 Specifies GSS-API authentication using The Simple Public-Key 408 GSS-API Mechanism (SPKM) [RFC2025]. 410 3.3.2 Attribute Classes 412 class value type 413 ------------------------------------------------------------ 414 GSS Identity Name 16384 B/V 416 GSS Identity Name Attribute (IKE) 418 When using the GSS-API authentication method, the GSS Identity 419 Name attribute may be used to pass the GSS-API endpoint names 420 for the initiator and responder. The format for these name 421 strings are private to the underlying GSS-API mechanism. 423 3.3.3 GSS-API Token Payload (ISAKMP) 425 When using the GSS-API authentication method, the GSS Token Payload 426 is used to pass the content of the GSSi[2] and GSSr[2] tokens. The 427 Next Payload value for the GSS-API Token Payload is 129. 429 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 ! Next Payload ! RESERVED ! Payload Length ! 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Vendor | Token Data ~ 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 Figure 1: GSS-API Token Payload (ISAKMP) 438 o Next Payload (1 octet) - Identifier for the payload type of 439 the next payload in the message. If the current payload is 440 the last in the message, this field will be zero (0). 442 o RESERVED (1 octet) - Unused, must be zero (0). 444 o Payload Length (2 octets) - Length in octets of the current 445 payload, including the generic payload header. 447 o Vendor Encoding (1 octet) - Vendor-specific encoding or 448 versioning prefix, may be non-zero. 450 o Token Data (variable length) - GSS-API token data (private 451 to the local GSS-API). 453 3.4 The GSS-API Authentication Method ISAKMP Vendor ID Signature 455 This memo describes a protocol that lives on top of RFC-2408 and as a 456 companion to RFC-2409. These standards-track protocols reserve some 457 of their "magic number" space for private use by mutually consenting 458 parties. It is from this number space that this memo obtains some of 459 the "magic numbers" it needs (payload types, authentication method, 460 attributes). As part of the "mutually consenting parties" part of 461 the requirement implementors of this protocol are encouraged to use a 462 Vendor ID payload to announce willingness to engage in this protocol. 463 The contents of the Vendor ID payload will be the following 464 hexadecimal string: 0xb46d8914f3aaa3f2fedeb7c7db2943ca, which is the 465 result of an MD5 hash of "A GSS-API Authentication Method for IKE". 466 An RFC-2409 implementation which implements this protocol and 467 receives a Vendor ID payload with this string in the body of the 468 payload can assume that the sender of the Vendor ID payload has 469 likewise implemented this protocol and is therefore a "mutually 470 consenting party". 472 For Windows 2000 compatibility, the contents of the Vendor ID payload 473 is instead the result of an MD5 hash over the ASCII string "GSSAPI". 474 Microsoft's IKE implementation does not send this payload, but MUST 475 receive either this Vendor ID or the generic Microsoft Vendor ID (an 476 MD5 hash over the ASCII string "MS NT5 ISAKMPOAKLEY"). 478 If this protocol is advanced to standards-track status IANA will 479 assign new "magic numbers" out of the appropriate number spaces (the 480 "magic numbers" will no longer be from the private use ranges) and 481 the requirement to use a Vendor ID payload will cease. 483 4. Change Log 485 4.1 Changes from -06/07 487 o No changes. Draft resubmitted to make ID current again. 489 4.2 Changes from -05 491 o Specify unicode encoding for opaque endpoint ID's in Section 3 492 for Windows 2000 compatibility. 493 o Make endpoint ID exchange in Section 3.2 mandatory for Windows 494 2000 compatibility. 495 o Added extra reserved byte proceeding token payload format for 496 Windows 2000 compatibility. 497 o Added Vendor ID usage guidelines for Windows 2000 compatibility. 499 4.3 Changes from -04 501 o Cleanup Section 3.2 description of GSS_S_CONTINUE_NEEDED 502 handling with Aggressive Mode. 504 4.4 Changes from -03 506 o Restore private use numbers to V2 values (Microsoft Windows 507 2000). 509 4.5 Changes from -02 511 o Generalize exchange for "n" round-trips. 512 o Remove GSSIi and GSSIr nomenclature; use GIi and GIr explicitly. 513 o Move magic numbers into mutual consent range; add Section 3.4. 514 o Add second paragraph to Security Considerations. 515 o Update document references. 516 o Update preamble language (RFC-2026). 518 4.6 Changes from -01 520 o Add optional GSSi2 and GSSr2 token definitions to Section 3.1. 521 o Add optional GSSi2 and GSSr2 tokens to Main Mode diagram. 522 o Add GSS Token Payload Figure to Section 3.3. 523 o Update document references to reflect IPSEC RFC status (!). 524 o Update most references to ISAKMP/Oakley to IKE. 526 4.7 Changes from -00 528 o GSSIi and GSSIr are required; remove optional brackets. 529 o Add text for GSS_Wrap/GSS_Unwrap over HASH_I and HASH_R. 531 5. Security Considerations 533 This entire draft pertains to a negotiated key management protocol, 534 combining Oakley (RFC-2412) with ISAKMP (RFC-2408), which negotiates 535 and derives keying material for security associations in a secure and 536 authenticated manner. Specific discussion of the various security 537 protocols and transforms identified in this document can be found in 538 the associated base documents, in the cipher references, and 539 throughout this document. 541 This draft defines an authentication method that is based on GSS-API. 542 The strength of the authentication is therefore completely dependent 543 on the underlying GSS-API mechanism definition. This document 544 defines a protocol which provides mutual authentication between the 545 GSS-API peers and binds the IKE exchange to the GSS-API shared 546 secrets. It does not provide any additional authentication beyond 547 that provided by the GSS-API mechanism. 549 Acknowledgments 551 Thanks to Dan Harkins for reviewing the early drafts and for allowing 552 me to liberate the notation from RFC-2409. Special thanks to Bill 553 Sommerfeld, Ran Canetti, Pau-Chen Cheng, and Hugo Krawczyk for 554 pointing out serious problems in the first version of this document. 556 References 558 [Linn98] Linn, J., "Generic Security Service Application Program 559 Interface, Version 2, Update 1," draft-ietf-cat-rfc2078bis-08.txt 560 (supersedes RFC-2078). Work in progress. 562 [Wray98] Wray, J., "Generic Security Service API Version 2 : C- 563 bindings," draft-ietf-cat-gssv2-cbind-09.txt (supersedes RFC-1509). 564 Work in progress. 566 Author's Address: 568 Derrell Piper 569 Nokia Corporation 570 1538 Pacific Ave 571 Santa Cruz, CA 95060 572 United States of America 573 +1 831 460-3800 x3822 575 Brian Swander 576 Microsoft Corporation 577 One Microsoft Way 578 Redmond, WA 98052 579 United States of America 580 +1 425 703-8182