idnits 2.17.1 draft-ietf-cat-sskm-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** There are 29 instances of lines with control characters in the document. ** The abstract seems to contain references ([SPKM], [BR94]), 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 250: '..."src-name" field MUST contain a name i...' RFC 2119 keyword, line 264: '...ntext-Data" structure MUST have as its...' 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 (April 20, 2000) is 8764 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) ** Obsolete normative reference: RFC 2078 (ref. 'GSS2') (Obsoleted by RFC 2743) -- Possible downref: Non-RFC (?) normative reference: ref. 'BR94' -- Possible downref: Non-RFC (?) normative reference: ref. 'DES' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group W. Doonan 2 Internet Draft Surety Technologies 3 Expires April 20, 2000 5 SPKM with Shared Secret Keys (SSKM) 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document presents a method for using [SPKM] with exclusively 31 shared secret key technologies. The messages and tokens of [SPKM] are 32 unchanged; the only modifications required are to replace the default 33 public-key cipher suite with ciphers and algorithms suitable for use 34 with shared secret keys. 36 All messages and tokens defined in [SPKM] are preserved; no changes 37 are required to the various authentication modes of [SPKM]. Integrity 38 algorithms and key establishment algorithms suitable for use with 39 secret keys are added to those specified in [SPKM], which are well 40 known and specified for use in other existing IETF standards. We in 41 effect implement the implicit authenticated key exchange protocol 42 proposed in [BR94] using the messages and tokens defined in [SPKM]. 44 An overview and brief discussion of the protocol appears in section 45 1. The specific algorithms and object identifiers are listed in 46 section 2. Discussion of how [SPKM] messages are used with shared 47 secret keys appears in section 3. Security concerns are addressed in 48 section 4. Patent issues are covered in section 5. 50 1. Overview 52 The purpose of [GSS2] is to define and extensible framework for 53 establishing a security context between peers for use in securing 54 communications between those peers. In turn, [SPKM] provides the means 55 for peers to use digital certificates for both authentication and for 56 computing session keys. 58 The token formats and messages defined in [SPKM] are used without 59 modification, but employ only shared secret key technologies for 60 authentication and computation of session keys. The rationale is to 61 provide a bridge between existing secret key (username/password or 62 token-based) infrastructures and more scalable infrastructures based 63 on digital signatures and certificates. 65 Well-known algorithms such as [DES] and [HMAC] are used, which have 66 also been extensively analyzed, and in fact are required by recently- 67 adpoted standards such as [IKE]. By using both existing algorithms 68 and a protocol with a strong existing proof of security, we avoid 69 introducing new cryptographic transforms or protocols requiring 70 extensive new analysis. 72 1.1 Two-Party Authenticated Key Exchange 74 The authentication and key establishment algorithms presented here 75 have been extensively analyzed by Mihir Bellare and Phillip Rogaway in 76 [BR94]. In this paper the authors prove the security of a series of 77 two-party, shared secret key authentication and key exchange protocols 78 against a strong threat model. The protocol variant implemented here 79 is referred to in the paper as AKEP2. The protocol conversation is 80 summarized below: 82 A. The initiator generates a random number and sends it to the target. 84 B. The target generates another random number and sends both random 85 numbers back to the initiator, along with an integrity value 86 computed using both random values and a shared secret key. 88 C. The initiator uses both random values and the shared secret key to 89 compute the expected integrity value. If the integrity value sent 90 by the target matches the computed integrity value, the target is 91 authenticated. 93 D. The initiator sends the target's random value back to the target, 94 along with an integrity value computed using the target's random 95 value and the shared secret key. 97 E. The target uses the random value and the shared secret key to 98 compute the expected integrity value. If the integrity value sent 99 by the initiator matches the computed integrity value, the 100 initiator is authenticated. 102 F. Both initiator and target compute a session key by passing the 103 target's random value through a strong pseudorandom permutation 105 function. The strong pseudorandom permutation function is seeded 106 with the shared secret key. 108 The key exchange algorithm is referred to as "implicit" because the 109 eventual session key is computed using the random values exchanged 110 during mutual authentication. Steps A through E are essentially 111 identical to the SPKM-1 operating mode when used with mutual 112 authentication, hence [SPKM] can be used to implement this portion of 113 AKEP2 directly. 115 Step F is essentially a new key establishment algorithm, and hence can 116 be chosen as the desired K-ALG during initial algorithm negotiation. 117 The key establishment algorithm in step F is based on using a strong 118 pseudorandom permutation function, rather than a simple pseudorandom 119 number generator. [BR94] identifies [DES] as a good candidate for 120 such a function, hence the key establishment algorithm specified here 121 is [DES]. 123 Use of [DES] in this manner is prone to confusion, as [DES] is 124 normally used as a confidentiality algorithm, and is also under fire 125 as being relatively insecure for confidentiality purposes. However, 126 [DES] is only being here used for it's pseudorandom permutation 127 properties, and only for computing a session key, rather than as a 128 means for encrypting actual data traffic. In addition, [BR94] only 129 requires that the key establishment algorithm exhibit strong 130 pseudorandom permutation properties; thus if [DES] is considered 131 unsuitable for use even in this capacity it can be replaced with other 132 functions with better or stronger permutation properties. 134 2. Algorithms, Name Types, and Object Identifiers 136 As mentioned above, no changes to the token formats or messages 137 defined in [SPKM] are required to operate with shared secrey keys, and 138 all existing operating modes are preserved. The only changes to 139 [SPKM] required to operate exclusively with shared secret keys is to 140 augment the choice of integrity and key establishment algorithms. 142 2.1 Integrity Algorithm (I-ALG) 144 The MANDATORY message integrity algorithm specified in [SPKM] is 145 md5WithRSAEncryption. To use [SPKM] with shared secret keys, 146 additional integrity algorithms are needed. When operating this way we 147 allow the I-ALG to be any of the [HMAC] transforms currently defined 148 for use in [IKE]. 150 Examples: 152 HMAC-MD5 OBJECT IDENTIFIER ::= { 153 iso(1) org(3) dod(6) internet(1) security(5) mechanisms(5) 154 ipsec(8) isakmpOakley(1) HMAC-MD5(1) 155 } 157 HMAC-SHA OBJECT IDENTIFIER ::= { 158 iso(1) org(3) dod(6) internet(1) security(5) mechanisms(5) 159 ipsec(8) isakmpOakley(1) HMAC-SHA(2) 160 } 162 HMAC-TIGER OBJECT IDENTIFIER ::= { 163 iso(1) org(3) dod(6) internet(1) security(5) mechanisms(5) 164 ipsec(8) isakmpOakley(1) HMAC-TIGER(3) 165 } 167 HMAC-RIPEMD160 OBJECT IDENTIFIER ::= { 168 iso(1) org(3) dod(6) internet(1) security(5) mechanisms(5) 169 ipsec(8) isakmpOakley(1) HMAC-RIPEMD160(4) 170 } 172 To ensure interoperability, HMAC-SHA is the MANDATORY integrity 173 algorithm. 175 2.2 Confidentiality Algorithm (C-ALG) 177 Using [SPKM] with shared secret keys does not require changes to the 178 set of available confidentiality algorithms. 180 2.3 Key Establishment Algorithm (K-ALG) 182 The MANDATORY algorithm for key establishment specified in [SPKM] is 183 RSAEncryption. To operate exclusively with shared secret keys, the 184 session key is computed by randomizing the exchanged random key 185 material with a suitable strong pseudorandom permutation function. 186 The [DES] algorithm is one such algorithm, and is in fact recommended 187 by [BR94]. 189 DES-CBC OBJECT IDENTIFIER ::= { 190 iso(1) identified-organization(3) oiw(14) secsig(3) 191 algorithm(2) 7 192 } 194 The key establishment algorithm is applied to the random value 195 generated by the target, as in section 1.1.F. 197 2.4 One-Way Function for Subkey Derivation (O-ALG) 199 Using [SPKM] with shared secret keys does not require changes to the 200 set of available one-way functions for subkey derivation. 202 2.5 Name Types 204 When using [SPKM] exclusively with shared secret keys, there are no 205 certificates present and hence various required name fields must be 207 obtained and expressed in some alternate form. We thus express names 208 using the name forms and object identifiers defined in [GSS2]. 210 gss-host-based-services OBJECT IDENTIFIER ::= { 211 iso(1) org(3) dod(6) internet(1) security(5) nametypes(6) 212 gss-host-based-services(2) 213 } 215 user-name OBJECT IDENTIFIER ::= { 216 iso(1) member-body(2) United States(840) mit(113554) 217 infosys(1) gssapi(2) generic(1) user_name(1) 218 } 220 3. Using SPKM with shared secret keys 222 When using [SPKM] with shared secret keys, the purpose of the initial 223 message exchange is to both authenticate the parties to the exchange 224 and to agree upon some randomly-generated key material. The protocol 225 presented in [BR94] can be expressed directly through use of SPKM-1 226 with mutual authentication enabled. However, the additional message 227 exchanges (SPKM-2) and authentication modes (unilateral) supported by 228 [SPKM] can also be used when operating with shared secret keys. 230 All authentication exchanges and modes eventually allow the peers to 231 reliably exchange some random key material. The random key material 232 is used to compute a session key according to the method detailed in 233 section 1.1.F. The session key is computed by encrypting the random 234 key material with [DES], in this case using a subkey derived from the 235 shared secret key according to the agreed upon one-way function and 236 key derivation algorithm. The computed session key is then used to 237 derive all other subkeys according to normal [SPKM] practices. 239 3.1 SPKM-REQ message 241 When using [SPKM] with shared secret keys, various optional fields in 242 the message are always absent. The "certif-data", "auth-data", 243 "validity", and "key-src-bind" fields are all absent, and the 244 "options" field of the "Context-Data" structure cannot have the 245 "target-certif-data-required" bit set. The "key-estb-req" field is 246 also empty, except for unilateral authentication of initiator to 247 target using SPKM-2. In this case the "key-estb-req" field contains 248 the random key material to be used in computing the session key. 250 The "src-name" field MUST contain a name indicating the identity of 251 the initiator, so that the target can find the secret key it shares 252 with the initiator. For example, in applications with existing 253 username/password infrastructures, the "src-name" would be a username 254 encoded in the user-name name form. All other fields are filled with 255 values appropriate for the current [SPKM] operating mode. 257 The "req-integrity" field is formed by computing any of the supported 259 [HMAC] transforms on the "req-contents" field, as with other I-ALGs. 260 The key used by the [HMAC] transform to compute the integrity value is 261 derived from the shared secret key according to the key derivation 262 algorithm defined in Section 2.4 of [SPKM]. 264 The "owf-alg" field of the "Context-Data" structure MUST have as its 265 first element the OID of the one-way function used by the subkey 266 derivation algorithm to compute the key used in the [HMAC] transform. 268 3.2 SPKM-REP-TI message 270 When using [SPKM] with shared secret keys, the optional "certif-data" 271 and "validity" fields are always absent. The "key-estb-str" field 272 contains the random key material used to compute the session key. All 273 other fields are filled with values appropriate to the current [SPKM] 274 operating mode. The "rep-ti-integ" field is formed in the same manner 275 as the "req-integrity" field is formed in section 3.1. 277 The protocol presented in [BR94] and summarized in section 1.1 uses a 278 single random number generated by the target to both authenticate the 279 initiator and target, and for computing the session key. When 280 implemented using [SPKM], we use the "randTarg" value to authenticate 281 the parties, and the "key-estb-str" value as the value from which we 282 compute the session key. Separating the values does not violate the 283 security of the protocol, as both fields are part of the integrity 284 computation. Separating them allows the random values used to 285 authenticate the parties to be fixed length, while allowing the key 286 material exchanged for use in computing session keys to vary in 287 length, to suit the needs of the integrity and confidentiality 288 algorithms negotiated by the parties. Separating the values also 289 follows good cryptographic practice of using a single entity for a 290 single purpose. 292 3.3 SPKM-REP-IT message 294 The "key-estb-rep" field is always absent, while all other fields are 295 filled with values appropriate to the current [SPKM] operating mode. 296 The "rep-it-integ" field is formed in the same manner as the "req- 297 integrity" field is formed in section 3.1. 299 3.4 SPKM-ERROR message 301 All fields are filled with values appropriate to the current [SPKM] 302 operating modes. The "integrity" field is formed in the same manner 303 as the "req-integrity" field is formed in section 3.1. 305 3.5 Other messages 307 Once the initial authentication and key establishment messages have 309 been exchanged, all SPKM-MIC, SPKM-WRAP, and SPKM-DEL messages are 310 unchanged. 312 4. Security Considerations 314 The authentication and key establishment algorithms presented here 315 were proven secure in [BR94] according to the realistic threat model 316 also presented in that paper. The theorems and proofs are presented 317 in the paper and are outside the scope of this document. The paper 318 makes certain cryptographic requirements on various primitives used in 319 constructing the protocol, however. 321 4.1 Random values 323 The protocols presented in [BR94] require that the random challenges 324 be "unpredictable", in the cryptographic sense, rather than simple 325 nonces. The [SPKM] specification, however, requires only that the 326 random challenges be "fresh". Hence, using [SPKM] with shared secret 327 keys imposes additional requirements on the process used to generate 328 the random challenges. 330 While it is impossible to generate "unpredictable" random values 331 algorithmically, one can use software functions that gather entropy 332 to generate "unpredictable" values of reasonable quality. An example 333 of an entropy-based random number generator can be found in the 334 CryptoLib software package, written by Matt Blaze et.al. at AT&T 335 Labs. This package includes a "truerand" function which uses the 336 variability of the number of times a simple calculation can occur 337 within a fixed amount of clock time on common timesharing operating 338 systems. This approach works well compared to other entropy gathering 339 algorithms that capture mouse clicks and keyboard events, and which 340 thus require user interaction. 342 4.2 Shared secret keys 344 As with any cryptosystem, the security of this system is directly 345 related to the strength of the keys in use. The shared secret keys 346 used here should conform to the usual and well-known criteria for 347 selecting strong keys. 349 4.3 Session key computation 351 A strong pseudorandom permutation function is required in order to 352 compute the negotiated session key. [BR94] suggests that the [DES] 353 algorithm, while under strong attack as an encryption algorithm, is 354 suitable for use as a strong pseudorandom permutation function. 355 Rather than invent a new generator, then, we choose to follow this 356 recommendation and use [DES] to compute session keys. 358 4.4 Message integrity 360 The message integrity functions used in [BR94] are based on strong 361 pseudorandom generators, such as DES-MAC or md5-DES-CBC. The paper 362 also lists pure hash functions as possible candidates, but warns that 363 their security characteristics in this application are less well 364 justified. However, in the time since [BR94] was initially published 365 the authors have developed and analyzed the [HMAC] constructions, 366 which in turn have been deemed suitably strong for use in other IETF 367 standards. Hence we add them to the list of recommended integrity 368 algorithms for [SPKM]. 370 4.5 Initial subkey derivation 372 Two keys are needed during initial message exchange, one to compute 373 integrity values on the messages and one to compute the eventual 374 session key. [BR94] uses the same shared secret key both for 375 computing integrity values and for computing the session key. To 376 avoid concerns about using a single cryptographic object for two 377 different purposes, the two keys used during initial message exchange 378 are derived from the single shared secret using the key derivation 379 algorithm specified in Section 2.4 of [SPKM]. An integrity subkey is 380 derived from the single shared secret and used to compute the [HMAC] 381 integrity values on all initial messages. Likewise a confidentiality 382 subkey is derived from the single shared secret and is used to compute 383 the negotiated session key. The one-way function used to derive these 384 initial subkeys is indicated in the "owf-alg" field of the 385 "Context-Data" element included in the initial message exchange. 387 5. Intellectual Property Rights 389 The IETF takes no position regarding the validity or scope of any 390 intellectual property or other rights that might be claimed to per- 391 tain to the implementation or use of the technology described in this 392 document or the extent to which any license under such rights might 393 or might not be available; neither does it represent that it has made 394 any effort to identify any such rights. Information on the IETF's 395 procedures with respect to rights in standards-track and standards- 396 related documentation can be found in BCP-11. Copies of claims of 397 rights made available for publication and any assurances of licenses 398 to be made available, or the result of an attempt made to obtain a 399 general license or permission for the use of such proprietary rights 400 by implementors or users of this specification can be obtained from 401 the IETF Secretariat. 403 The IETF invites any interested party to bring to its attention any 404 copyrights, patents or patent applications, or other proprietary 405 rights which may cover technology that may be required to practice 406 this standard. Please address the information to the IETF Executive 407 Director. 409 6. References 411 [GSS2] J. Linn, "Generic Security Service Application Program 412 Interface, Version 2," RFC 2078, January 1997. 414 [SPKM] C. Adams, "The Simple Public-Key GSS-API Mechanism (SPKM)," 415 RFC 2025, October 1996. 417 [BR94] M. Bellare, P. Rogaway, "Entity Authentication and Key 418 Distribution," Extended abstract in Advances in Cryptology - Crypto 93 419 Proceedings, Lecture Notes in Computer Science Vol. 773, D. Stinson 420 ed, Springer-Verlag, 1994. 422 [DES] ANSI X3.106, "American National Standard for Information 423 Systems-Data Link Encryption," American National Standards Institute, 424 1983. 426 [HMAC] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for 427 Message Authentication," RFC 2104, February 1997. 429 [IKE] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)," 430 RFC 2409, November 1998. 432 7. Authors' Addresses 434 Address comments related to this submission to: 436 cat-ietf@mit.edu 438 Wes Doonan 439 Surety Technologies Inc. 440 1890 Preston White Drive 441 Reston, VA 20191 442 wes@surety.com