idnits 2.17.1 draft-ietf-ipsec-isakmp-gss-auth-01.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-27) 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. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 abstract seems to contain references ([Harkins97]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 47: '... The keywords MUST, MUST NOT, REQUIR...' RFC 2119 keyword, line 48: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 60: '... initiator MAY provide multiple p...' RFC 2119 keyword, line 61: '... responder MUST reply with only o...' RFC 2119 keyword, line 135: '...by a '*' after the ISAKMP header) MUST...' (9 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 (December 18, 1997) is 9627 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: 'RFC 2119' is mentioned on line 50, but not defined == Missing Reference: 'Pip97' is mentioned on line 101, but not defined == Missing Reference: 'ISAKMP' is mentioned on line 170, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-ipsec-isakmp-oakley-05 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp-oakley (ref. 'Harkins97') == Outdated reference: A later version (-08) exists of draft-ietf-cat-rfc2078bis-01 == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-isakmp-08 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp (ref. 'Maughan97') -- Unexpected draft version: The latest known version of draft-ietf-ipsec-oakley is -01, but you're referring to -02. ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-oakley (ref. 'Orman97') == Outdated reference: A later version (-08) exists of draft-ietf-cat-snego-07 == Outdated reference: A later version (-09) exists of draft-ietf-cat-gssv2-cbind-04 Summary: 15 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Derrell Piper 3 INTERNET-DRAFT Network Alchemy 4 draft-ietf-ipsec-isakmp-gss-auth-01.txt December 18, 1997 6 A GSS-API Authentication Mode for ISAKMP/Oakley 7 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and working groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Australia), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Distribution of this memo is unlimited. This draft will expire six 28 months from date of issue. 30 1. Abstract 32 This document describes an alternate authentication method for 33 ISAKMP/Oakley which makes use of GSS-API to authenticate the Diffie- 34 Hellman exchange. The mechanism described here extends the 35 authentication modes defined in [Harkins97] without introducing any 36 modifications to the ISAKMP/Oakley key exchange protocol. This 37 constraint however, necessarily restricts the number of GSS-API 38 exchanges and may limit the broader applicability of this method. 39 Additional work is needed to provide a fully generalized solution. 40 Such a solution will require ISAKMP/Oakley protocol modifications. 42 For a list of changes since the previous version of the IPSEC DOI, 43 please see Section 5. 45 2. Terms and Definitions 47 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 48 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 49 document, are to be interpreted as described in [RFC 2119]. 51 2.1 Notation 53 [Harkins97] uses the following notation throughout that draft. That 54 notation is included here along with a few additions. 56 HDR is an ISAKMP header whose exchange type is the mode. When 57 written as HDR* it indicates payload encryption. 59 SA is an SA negotiation payload with one or more proposals. An 60 initiator MAY provide multiple proposals for negotiation; a 61 responder MUST reply with only one. 63

_b indicates the body of payload

-- the ISAKMP generic 64 payload is not included. 66 SAi_b is the entire body of the SA payload (minus the ISAKMP 67 generic header)-- i.e. the DOI, situation, all proposals and all 68 transforms offered by the Initiator. 70 CKY-I and CKY-R are the Initiator's cookie and the Responder's 71 cookie, respectively, from the ISAKMP header. 73 g^xi and g^xr are the Diffie-Hellman public values of the 74 initiator and responder respectively. 76 g^xy is the Diffie-Hellman shared secret. 78 GIi and GIr are identity name strings for the GSS-API initiator 79 and responder GSS-API endpoints. These name strings are private 80 to GSS-API. 82 GSSi and GSSr are the initiator and responder GSS-API tokens 83 generated by the local GSS-API's using GSS_Init_sec_context and 84 GSS_Accept_sec_context respectively. 86 GSSIi and GSSIr are the concatenation of optional GSS-API identity 87 strings and either GSSi or GSSr for the initiator and responder 88 respectively. 90 KE is the key exchange payload which contains the public 91 information exchanged in a Diffie-Hellman exchange. There is no 92 particular encoding used for the data of a KE payload. 94 Nx is the nonce payload; x can be: i or r for the ISAKMP initiator 95 and responder respectively. 97 IDx is the identity payload for "x". x can be: "ii" or "ir" for 98 the ISAKMP initiator and responder respectively during phase one 99 negotiation; or "ui" or "ur" for the user initiator and responder 100 respectively during phase two. The ID payload format for the 101 Internet DOI is defined in [Pip97]. 103 HASH (and any derivative such as HASH(2) or HASH_I) is the hash 104 payload. The contents of the hash are specific to the 105 authentication method. 107 prf(key, msg) is the keyed pseudo-random function-- often a keyed 108 hash function-- used to generate a deterministic output that 109 appears pseudo-random. prf's are used both for key derivations 110 and for authentication (i.e. as a keyed MAC). 112 SKEYID is a string derived from secret material known only to the 113 active players in the exchange. 115 SKEYID_e is the keying material used by the ISAKMP SA to protect 116 it's messages. 118 SKEYID_a is the keying material used by the ISAKMP SA to 119 authenticate it's messages. 121 SKEYID_d is the keying material used to derive keys for non-ISAKMP 122 security associations. 124 y indicates that "x" is encrypted with the key "y". 126 --> signifies "initiator to responder" communication (requests). 128 <-- signifies "responder to initiator" communication (replies). 130 | signifies concatenation of information-- e.g. X | Y is the 131 concatenation of X with Y. 133 [x] indicates that x is optional. 135 Payload encryption (when noted by a '*' after the ISAKMP header) MUST 136 begin immediately after the ISAKMP header. When communication is 137 protected, all payloads following the ISAKMP header MUST be 138 encrypted. Encryption keys are generated from SKEYID_e in a manner 139 that is defined for each algorithm. 141 3. Discussion 143 The ISAKMP/Oakley resolution document ([Harkins97]) defines a key 144 negotiation protocol that blends the Oakley key determination 145 protocol ([Orman97]) with ISAKMP ([Maughan97]) to provide 146 authenticated cryptographic key exchange for use with IP security 147 protocols (e.g. AH/ESP). The ISAKMP/Oakley negotiation includes an 148 authentication method negotiation which is used to select a scheme to 149 be used for authenticating a Diffie-Hellman key exchange. There are 150 currently five defined authentication methods: pre-shared key, DSS 151 signature, RSA signature, and two forms of RSA encryption. This 152 document defines a new method that uses the Generic Security Services 153 API ([Linn97]) to provide the necessary authentication. 155 The GSS-API abstraction is that a host operating system provides an 156 API to applications that request security services (e.g. integrity 157 protection or confidentiality) through a formal interface (e.g., 158 [Wray97]). GSS-API provides opaque tokens to applications which are 159 responsible for sending the tokens to peer GSS-API implementations, 160 presumably on remote hosts. A by-product of any GSS-API exchange is 161 a one way or mutual authentication using whatever authentication 162 scheme the application chose to bind to when GSS-API was initialized 163 (or whatever was negotiated by SNEGO ([Pinkas97])). Typical 164 authentication packages include Kerberos and SSL. 166 The ISAKMP/Oakley resolution defines a Main Mode and an Aggressive 167 Mode for establishing Security Associations (SA's) between IPSEC 168 hosts. These modes have a fixed set of round-trips: 4.5 or 5 for 169 Main Mode and 1 or 1.5 for Aggressive (depending on whether the 170 Commit bit ([ISAKMP], Section 3.1) is used by the responder). 172 When using GSS-API, there's a separate protocol being run by the GSS- 173 API packages on the initiator and on the responder. (Initiator and 174 responder are ISAKMP terms, both are GSS-API clients.) The basic 175 model is that the ISAKMP/Oakley initiator calls GSS_Init_sec_context 176 (with mutual_req_flag) to construct a GSS-API token and sends this 177 along with the KE and nonce in the second Main Mode exchange. The 178 responder calls GSS_Accept_sec_context on this token and sends the 179 output of GSS_Accept_sec_context (another token) back along with his 180 KE and his nonce. On receipt of the responder's token, the initiator 181 calls GSS_Init_sec_context a second time to complete the mutual 182 authentication. Finally, each side exchanges a HASH payload which 183 has been wrapped using GSS_Wrap. Successfully calling GSS_Unwrap to 184 unwrap the HASH payloads along with verfiying the hashes proves 185 possesion of the GSS-API shared secret and authenticates the Diffie- 186 Hellman exchange. 188 GSS-API requires that a client identify the target GSS-API endpoint 189 by name. If the initiator does not already know the GSS-API endpoint 190 name of the ISAKMP target, a new Phase 1 attribute can be used to 191 exchange endpoint names during the first Main Mode round trip 192 (Section 4.3). Note that these name string are bound to the exchange 193 but otherwise unauthenticated. The GSS-API endpoint names are also 194 assumed to be opaque. 196 Since the GSS-API tokens are exchanged during Phase 1 along with the 197 KE payloads, they are not protected by the (yet to be formed) ISAKMP 198 SA. To prevent a cut/paste attack on the GSS-API tokens, it's 199 therefore necessary to include the tokens in the HASH_I and HASH_R 200 computation (Section 4.1). This binds the tokens to a particular 201 ISAKMP exchange. If used, the GSS Identity Name strings MUST also be 202 included in these hash calculations. 204 In addition, the output from the prf for each hash is wrapped using 205 GSS_Wrap. Upon receipt of either hash payload, each side MUST 206 successfully call GSS_Unwrap. This proves possession of the GSS-API 207 shared secret by each peer and prevents an active man-in-the-middle 208 attack from simply forwarding on the GSS-API tokens. The choice of 209 whether to use integrity protection only or integrity with 210 confidentiality is somewhat mechanism specific. However, since the 211 strength of the algorithm chosen necessarily determines the outcome 212 of the authentication for ISAKMP, the strongest possible protection 213 SHOULD be chosen. The following flags should be specified to 214 GSS_Init_sec_context on the initiating side: 216 Flag Requirement 217 ---- ----------- 218 mutual_req_flag MUST 219 integ_req_flag MUST 220 conf_req_flag SHOULD 222 If the GSS-API authentication cannot be completed in 1.5 round-trips, 223 the method described in this document will not work. To fully 224 generalize this extension, a new XCHG type will need to be created 225 that allows for any number of GSS-API exchanges but is otherwise 226 similar to the existing Main Mode exchange. A single Main Mode-like 227 XCHG type is probably sufficient since there would be little use for 228 an Aggressive Mode construct given the open ended nature of GSS-API. 230 The primary motivation for this work was to integrate Kerberos 231 authentication into ISAKMP/Oakley in an environment where the host 232 operating system did not expose the underlying Kerberos 233 authentication services except as a GSS-API package. Since the 234 details of the host operating system's Kerberos package were known, 235 the limitations described above were addressed in a reasonable manner 236 by simply failing the ISAKMP/Oakley negotiation when the GSS-API's 237 failed to converge in the requisite number of round-trips. When 238 implemented this way, this event SHOULD be auditable and should 239 clearly differentiate this type of authentication failure from one 240 caused by truly bad credentials. 242 4.1 SKEYID Generation for GSS-API 244 [Harkins97] defines several authentication methods for Main Mode or 245 Aggressive Mode -- digital signatures, authentication using public 246 key encryption, and pre-shared keys. This document introduces 247 another and defines the value of SKEYID for GSS-API authentication as 248 follows. 250 For GSS-API: SKEYID = prf(Ni_b | Nr_b, g^xy) 252 To authenticate either exchange the initiator of the protocol 253 generates HASH_I and the responder generates HASH_R where: 255 HASH_I = GSS_Wrap(prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | 256 IDii_b | GSSIi)) 258 HASH_R = GSS_Wrap(prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | 259 IDir_b | GSSIr)) 261 For authentication using GSS-API, the GSS-API package on either side 262 provides authentication of the GSS-API identities, and HASH_I and 263 HASH_R are used to bind the GSS-API identities and tokens to the Main 264 Mode exchange. The GSS_Wrap (and subsequent GSS_Unwrap) proves 265 possession of the GSS-API shared secret for each peer. The initiator 266 MUST specify the mutual_req_flag to request mutual authentication 267 between the two GSS-API packages. A provision is defined for the 268 GSS-API peers to exchange GSS-API identities during Main Mode, at the 269 expense of identity protection for the GSS-API endpoint identities. 271 4.2 ISAKMP/Oakley Phase 1 Authenticated With GSS-API 273 Using GSS-API, the ancillary information exchanged during the second 274 roundtrip are GSS-API tokens; the exchange is authenticated in GSS- 275 API and the GSS-API tokens are bound to the exchange using HASH_I and 276 HASH_R. 278 If the GSS-API requires that the initiator and responder have prior 279 knowledge of the GSS-API endpoint names for each peer, this 280 information may be exchanged during the first round trip (by 281 including the GSS Identity Name attribute in the SA) at the expense 282 of identity protection for the GSS-API endpoints. When the GSS-API 283 requires the exchange of identity names, Aggressive Mode cannot be 284 used. 286 Initiator Responder 287 ---------- ----------- 288 HDR, SA --> 289 <-- HDR, SA 290 HDR, KE, Ni, GSSi --> 291 <-- HDR, KE, Nr, GSSr 292 HDR*, IDii, HASH_I --> 293 <-- HDR*, IDir, HASH_R 295 Aggressive mode using GSS-API is defined as 297 Initiator Responder 298 ----------- ----------- 299 HDR, SA, KE, Ni, 300 IDii, GSSi --> 301 <-- HDR, SA, KE, Nr, 302 IDir, GSSr, HASH_R 303 HDR, HASH_I --> 305 4.3 GSS-API Identifiers and Attributes 307 Implementations using the GSS-API Authentication Mode will need to 308 agree on the following values. These numbers are simply the 309 beginning of the "private use" range for each particular list. 311 - Authentication Method 312 Authentication with GSS-API 65001 314 Attribute Classes 316 class value type 317 ------------------------------------------------------------ 318 GSS Identity Name 32001 B/V 320 - GSS Identity Name 322 When using the GSS-API authentication mode, the GSS Identity Name 323 attribute may be used to pass the GSS-API endpoint names for the 324 initiator and responder. The format for these name strings are 325 private to GSS-API. 327 5. Change Log 329 5.1 Changes from V0 331 o GSSIi and GSSIr are required; removed optional brackets 332 o added text for GSS_Wrap/GSS_Unwrap over HASH_I and HASH_R 334 6. Security Considerations 336 This entire draft pertains to a negotiated key management protocol, 337 combining Oakley ([Orman97]) with ISAKMP ([Maughan97]), which 338 negotiates and derives keying material for security associations in a 339 secure and authenticated manner. Specific discussion of the various 340 security protocols and transforms identified in this document can be 341 found in the associated base documents, in the cipher references, and 342 throughout this document. 344 Acknowledgments 346 Thanks to Dan Harkins for reviewing the early drafts and for allowing 347 me to liberate the notation from [Harkins97]. Special thanks to Bill 348 Sommerfeld, Ran Canetti, Pau-Chen Cheng, and Hugo Krawczyk for 349 pointing out problems in previous versions of this document. 351 References 353 [Harkins97] Harkins, D., Carrel, D., "The Resolution of ISAKMP with 354 Oakley," draft-ietf-ipsec-isakmp-oakley-05.txt. 356 [Linn97] Linn, J., "Generic Security Service Application Program 357 Interface, Version 2, Update 1," draft-ietf-cat-rfc2078bis-01.txt. 359 [Maughan97] Maughan, D., Schertler, M., Schneider, M., and Turner, 360 J., "Internet Security Association and Key Management Protocol 361 (ISAKMP)," draft-ietf-ipsec-isakmp-08.{ps,txt}. 363 [Orman97] H. K. Orman, "The OAKLEY Key Determination Protocol," 364 draft-ietf-ipsec-oakley-02.txt. 366 [Pinkas97] Pinkas, D., Baize, E., "The Simple and Protected GSS-API 367 Negotiation Mechanism," draft-ietf-cat-snego-07.txt. 369 [Wray97] Wray, J., "Generic Security Service API Version 2 : C- 370 bindings," draft-ietf-cat-gssv2-cbind-04.txt (supercedes RFC-1509). 372 Author's Address: 374 Derrell Piper 375 Network Alchemy 376 1521.5 Pacific Ave 377 Santa Cruz, California, 95060 378 United States of America 379 +1 408 460-3822