idnits 2.17.1 draft-ietf-cat-lipkey-02.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 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. ** The abstract seems to contain references ([RFC2025], [RFC2078], [RFC2246]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 1999) is 8899 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: 'APPLICATION 0' is mentioned on line 678, but not defined == Unused Reference: 'RFC1832' is defined on line 854, but no explicit reference was found in the text == Unused Reference: 'RSA' is defined on line 908, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'CCITT' -- Possible downref: Non-RFC (?) normative reference: ref. 'Dobbertin' -- Possible downref: Non-RFC (?) normative reference: ref. 'EFF' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKIX' ** Obsolete normative reference: RFC 1831 (Obsoleted by RFC 5531) ** Obsolete normative reference: RFC 1832 (Obsoleted by RFC 4506) ** Obsolete normative reference: RFC 2078 (Obsoleted by RFC 2743) ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 2144 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2437 (Obsoleted by RFC 3447) ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) ** Downref: Normative reference to an Informational RFC: RFC 2612 -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA-IP' -- Possible downref: Non-RFC (?) normative reference: ref. 'Sandberg' -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' -- Possible downref: Non-RFC (?) normative reference: ref. 'Young' Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Eisler 2 Internet Draft Sun Microsystems, Inc. 3 Document: draft-ietf-cat-lipkey-02.txt December 1999 5 LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 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 20 material 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 memorandum describes a method whereby one can use GSS-API 31 [RFC2078] to supply a secure channel between a client and server, 32 authenticating the client with a password, and server with a public 33 key certificate. As such, it is analogous to the common low 34 infrastructure usage of the Transport Layer Service (TLS) protocol 35 [RFC2246]. 37 The method leverages the existing Simple Public Key Mechanism (SPKM) 38 [RFC2025], and is specified as a separate GSS-API mechanism (LIPKEY) 39 layered on top of SPKM. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 44 2. LIPKEY's Requirements of SPKM . . . . . . . . . . . . . . . . 5 45 2.1. Mechanism Type . . . . . . . . . . . . . . . . . . . . . . . 5 46 2.2. Name Type . . . . . . . . . . . . . . . . . . . . . . . . . 6 47 2.3. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 6 48 2.3.1. MANDATORY Algorithms . . . . . . . . . . . . . . . . . . . 6 49 2.3.2. RECOMMENDED Integrity Algorithms (I-ALG) . . . . . . . . . 9 50 2.4. Context Establish Tokens . . . . . . . . . . . . . . . . . . 9 51 2.4.1. REQ-TOKEN Content Requirements . . . . . . . . . . . . . . 9 52 2.4.1.1. algId and req-integrity . . . . . . . . . . . . . . . 10 53 2.4.1.2. Req-contents . . . . . . . . . . . . . . . . . . . . . 10 54 2.4.1.2.1. Options . . . . . . . . . . . . . . . . . . . . . . 10 55 2.4.1.2.2. Conf-Algs . . . . . . . . . . . . . . . . . . . . . 10 56 2.4.1.2.3. Intg-Algs . . . . . . . . . . . . . . . . . . . . . 10 57 2.4.2. REP-TI-TOKEN Content Requirements . . . . . . . . . . . 10 58 2.4.2.1. algId . . . . . . . . . . . . . . . . . . . . . . . . 11 59 2.4.2.2. rep-ti-integ . . . . . . . . . . . . . . . . . . . . . 11 60 2.5. Quality of Protection . . . . . . . . . . . . . . . . . . 11 61 3. How LIPKEY Uses SPKM . . . . . . . . . . . . . . . . . . . . 12 62 3.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 12 63 3.2. Initiator . . . . . . . . . . . . . . . . . . . . . . . . 12 64 3.2.1. GSS_Import_name . . . . . . . . . . . . . . . . . . . . 12 65 3.2.2. GSS_Acquire_cred . . . . . . . . . . . . . . . . . . . . 12 66 3.2.3. GSS_Init_sec_context . . . . . . . . . . . . . . . . . . 13 67 3.2.3.1. LIPKEY Caller Specified anon_req_flag as TRUE . . . . 13 68 3.2.3.2. LIPKEY Caller Specified anon_req_flag as FALSE . . . . 14 69 3.2.4. Other operations . . . . . . . . . . . . . . . . . . . . 15 70 3.3. Target . . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 3.3.1. GSS_Import_name . . . . . . . . . . . . . . . . . . . . 15 72 3.3.2. GSS_Acquire_cred . . . . . . . . . . . . . . . . . . . . 15 73 3.3.3. GSS_Accept_sec_context . . . . . . . . . . . . . . . . . 15 74 4. LIPKEY Description . . . . . . . . . . . . . . . . . . . . . 16 75 4.1. Mechanism Type . . . . . . . . . . . . . . . . . . . . . . 16 76 4.2. Name Types . . . . . . . . . . . . . . . . . . . . . . . . 16 77 4.3. Token Formats . . . . . . . . . . . . . . . . . . . . . . 16 78 4.3.1. Context Tokens . . . . . . . . . . . . . . . . . . . . . 16 79 4.3.1.1. Context Tokens Prior to SPKM-3 Context Establishment . 17 80 4.3.1.2. Post-SPKM-3 Context Establishment Token . . . . . . . 17 81 4.3.2. Tokens from GSS_GetMIC and GSS_Wrap . . . . . . . . . . 18 82 4.4. Quality of Protection . . . . . . . . . . . . . . . . . . 18 83 5. Security Considerations . . . . . . . . . . . . . . . . . . 18 84 5.1. Password Management . . . . . . . . . . . . . . . . . . . 18 85 5.2. Certification Authorities . . . . . . . . . . . . . . . . 19 86 5.3. HMAC-MD5 and MD5 Weaknesses . . . . . . . . . . . . . . . 19 87 5.4. Security of cast5CBC . . . . . . . . . . . . . . . . . . . 19 88 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 89 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 22 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 92 1. Introduction 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 This memorandum describes a new security mechanism under the GSS-API 99 called the Low Infrastructure Public Key Mechanism (LIPKEY). GSS-API 100 provides a way for an application protocol to implement 101 authentication, integrity, and privacy. TLS is another way. While TLS 102 is in many ways simpler for an application to incorporate than GSS- 103 API, there are situations where GSS-API might be more suitable. 104 Certainly this is the case with application protocols that run over 105 connectionless protocols. It is also the case with application 106 protocols such as ONC RPC [RFC1831] [RFC2203], which have their own 107 security architecture, and so do not easily mesh with a protocol like 108 TLS that is implemented as a layer that encapsulates the upper layer 109 application protocol. GSS-API allows the application protocol to 110 encapsulate as much of the application protocol as necessary. 112 Despite the flexibility of GSS-API, it compares unfavorably with TLS 113 with respect to the perception of the amount of infrastructure 114 required to deploy it. The better known GSS-API mechanisms, Kerberos 115 V5 [RFC1964] and SPKM require a great deal of infrastructure to set 116 up. Compare this to the typical TLS deployment scenario, which 117 consists of a client with no public key certificate accessing a 118 server with a public key certificate. The client: 120 * obtains the server's certificate, 122 * verifies that it was signed by a trusted Certification Authority 123 (CA), 125 * generates a random session symmetric key, 127 * encrypts the session key with the server's public key, and 129 * sends the encrypted session key to the server. 131 At this point, the client and server have a secure channel. The 132 client can then provide a user name and password to the server to 133 authenticate the client. For example, when TLS is being used with the 134 http protocol, once there is a secure channel, the http server will 135 present the client with an html page that prompts for a user name and 136 password. This information is then encrypted with the session key and 137 sent to the server. The server then authenticates the client. 139 Note that the client is not required to have a certificate to 140 identify and authenticate it to the server. The only security 141 infrastructure required, other than a TLS implementation, is a public 142 key certificate and password database on the server. Most operating 143 systems that the http server would run on already have a native 144 password database, so the net additional infrastructure is a server 145 certificate. Hence the term "low infrastructure security model" to 146 identify this typical TLS deployment scenario. 148 By using unilateral authentication, and using a mechanism resembling 149 the SPKM-1 mechanism type, SPKM can offer many aspects of the 150 previously described low infrastructure security model. An 151 application that uses GSS-API is certainly free to use GSS-API's 152 GSS_Wrap() routine to encrypt a user name and password and send them 153 to the server, for it to decrypt and verify. 155 Applications often have application protocols associated with them, 156 and there might not be any provision in the protocol to specify a 157 password. Layering a thin GSS-API mechanism over a mechanism 158 resembling SPKM-1 can mitigate this problem. This can be a useful 159 approach to avoid versioning applications that have already bound to 160 GSS-API, assuming the applications have not been written to 161 statically bind to specific GSS-API mechanisms. The remainder of 162 this memorandum defines the thin mechanism: the Low Infrastructure 163 Public Key Mechanism (LIPKEY). 165 2. LIPKEY's Requirements of SPKM 167 SPKM-1 with unilateral authentication is close to the desired low 168 infrastructure model described earlier. This section describes some 169 additional changes to how SPKM-1 operates in order to realize the low 170 infrastructure model. These changes include some minor changes in 171 semantics. While it would be possible to implement these semantic 172 changes within an SPKM-1 implementation (including using the same 173 mechanism type Object Identifier (OID) as SPKM-1), the set of changes 174 stretch the interpretation of RFC 2025 to the point where 175 compatibility would be in danger. A new mechanism type, called SPKM- 176 3, is warranted. LIPKEY requires that the SPKM implementation support 177 SPKM-3. SPKM-3 is equivalent to SPKM-1, except as described in the 178 remainder of this section. 180 2.1. Mechanism Type 182 SPKM-3 has a different mechanism type OID from SPKM-1. The SPKM-3 183 mechanism type's OID is not yet defined. 185 2.2. Name Type 187 RFC 2025 defines no required name types of SPKM. LIPKEY requires that 188 the SPKM-3 implementation support all the mechanism independent name 189 types in RFC 2078. 191 2.3. Algorithms 193 2.3.1. MANDATORY Algorithms 195 RFC 2025 defines various algorithms for integrity, confidentiality, 196 key establishment, and subkey derivation. Except for 197 md5WithRSAEncryption, the REQUIRED Key Establishment (K-ALG), 198 Integrity (I-ALG) and One-Way Functions for Subkey Derivation (O-ALG) 199 algorithms listed in RFC 2025 continue to be REQUIRED. 201 SPKM is designed to be extensible with regard to new algorithms. In 202 order for LIPKEY to work correctly and securely, the following 203 algorithms MUST be implemented in SPKM-3: 205 * Integrity algorithms (I-ALG) 207 NULL-MAC 208 Because the initiator may not have a certificate for itself, 209 nor for the target, it is not possible for it to calculate an 210 Integrity value in the initiator's REQ-TOKEN that is sent to 211 the target. So we define, in ASN.1 [CCITT] syntax, a null I- 212 ALG that returns a zero length bit string regardless of the 213 input passed to it: 215 NULL-MAC OBJECT IDENTIFIER ::= { 216 -- OID to be defined 217 } 219 id-dsa-with-sha1 220 This is the signature algorithm as defined in Section 7.2.2 221 of [RFC2459]. As noted in RFC 2459, the ASN.1 OID used to 222 identify this signature algorithm is: 224 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { 225 iso(1) member-body(2) us(840) x9-57(10040) 226 x9cm(4) 3 227 } 229 Note that there is a work-in-progress [PKIX] to obsolete RFC 230 2459. However that work-in-progress does not change the 231 definition of id-dsa-with-sha1. 233 HMAC-MD5 234 A consequence of the SPKM-3 initiator not having a 235 certificate is that it cannot use a digital signature 236 algorithm like md5WithRSAEncryption, id-dsa-with-sha1, or 237 sha1WithRSAEncryption once the context is established. 238 Instead, a message authentication code (MAC) algorithm is 239 required. DES-MAC is specified as recommended in [RFC2025]. 240 Since the security of 56 bit DES has been shown to be 241 inadequate [EFF], SPKM-3 needs a stronger MAC. Thus, SPKM-3 242 MUST support the HMAC-MD5 algorithm [RFC2104], with this OID 243 [IANA]: 245 HMAC-MD5 OBJECT IDENTIFIER ::= { 246 iso(1) org(3) dod(6) internet(1) security(5) 247 mechanisms(5) ipsec(8) isakmpOakley(1) 248 1 249 } 251 The reference for the algorithm OID of HMAC-MD5 is [IANA]. 252 The reference for the HMAC-MD5 algorithm is [RFC2104]. 254 The HMAC-SHA1 algorithm is not a mandatory SPKM-3 I-ALG MAC 255 because SHA-1 is about half the speed of MD5 [Young]. A MAC 256 based on an encryption algorithm like cast5CBC, DES EDE3, or 257 RC4 is not mandatory because MD5 is 31 percent faster than 258 the fastest of the three encryption algorithms [Young]. 260 * Confidentiality algorithm (C-ALG). 262 RFC 2025 does not have a MANDATORY confidentiality algorithm, 263 and instead has RECOMMENDED a 56 bit DES algorithm. Since the 264 LIPKEY initiator needs to send a password to the target, and 265 since 56 bit DES has been demonstrated as inadequate [EFF], 266 LIPKEY needs stronger encryption. Thus, SPKM-3 MUST support this 267 algorithm: 269 cast5CBC OBJECT IDENTIFIER ::= { 270 iso(1) memberBody(2) usa(840) nt(113533) nsn(7) 271 algorithms(66) 10 272 } 274 Parameters ::= SEQUENCE { 275 iv OCTET STRING DEFAULT 0, -- Initialization vector 276 keyLength INTEGER -- Key length, in bits 278 } 280 The reference for the OID and description of the cast5CBC 281 algorithm is [RFC2144]. The keyLength in the Parameters MUST be 282 set 128 bits. 284 A triple DES (DES EDE3) algorithm is not a mandatory SPKM-3 C- 285 ALG because it is much slower than cast5CBC. One set of 286 measurements [Young] on a Pentium Pro 200 mega hertz processor 287 using the SSLeay code, showed that DES EDE3 performed as high as 288 1,646,210 bytes per second, using 1024 byte blocks. The same 289 test bed yielded performance of 7,147,760 bytes per second for 290 cast5CBC, and 22,419,840 bytes per second for RC4. Most TLS 291 sessions negotiate the RC4 cipher. Given that LIPKEY is targeted 292 at environments similar to that where TLS is deployed, selecting 293 a cipher that is over 13 times slower (and over 13 times more 294 CPU intensive) than RC4 would severely impede the usefulness of 295 LIPKEY. For performance reasons, RC4 would be the preferred 296 mandatory algorithm for SPKM-3. Due to intellectual property 297 considerations with RC4 [Schneier], the combination of 298 cast5CBC's reasonable performance, and its royalty-free 299 licensing terms [RFC2144] make cast5CBC the optimal choice among 300 DES EDE3, RC4, and cast5CBC. 302 * Key Establishment Algorithm (K-ALG) 304 RFC 2025 lists dhKeyAgreement [PKCS-3] as an apparently optional 305 algorithm. As will be described later, the RSAEncryption key 306 establishment algorithm is of no use for a low infrastructure 307 security mechanism as defined by this memorandum. Hence, in 308 SPKM-3, dhKeyAgreement is a REQUIRED key establishment 309 algorithm: 311 dhKeyAgreement OBJECT IDENTIFIER ::= { 312 iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 313 pkcs-3(3) 1 314 } 316 * One-Way Function for Subkey Derivation Algorithm (O-ALG) 318 RFC 2025 lists MD5 as a mandatory algorithm. Since MD5 has been 319 found to have weaknesses when used as a hash [Dobbertin], id- 320 sha1 is a MANDATORY O-ALG in SPKM-3: 322 id-sha1 OBJECT IDENTIFIER ::= { 323 iso(1) identified-organization(3) oiw(14) 324 secsig(3) algorithms(2) 26 325 } 327 The reference for the algorithm OID of id-sha1 is [RFC2437]. 328 The reference for SHA-1 algorithm corresponding to id-sha1 is 329 [FIPS]. 331 2.3.2. RECOMMENDED Integrity Algorithms (I-ALG) 333 md5WithRSAEncryption 334 The md5WithRSAEncryption integrity algorithm is listed in 335 [RFC2025] as mandatory. Due to intellectual property 336 considerations [RSA-IP], SPKM-3 implementations cannot be 337 required to implement it. However, given the proliferation of 338 certificates using RSA public keys, md5WithRSAEncryption is 339 strongly RECOMMENDED. Otherwise, the opportunities for LIPKEY to 340 leverage existing public key infrastructure will be limited. 342 sha1WithRSAEncryption 343 For reasons similar to that for md5WithRSAEncryption, 344 sha1WithRSAEncryption is a RECOMMENDED algorithm. The 345 sha1WithRSAEncryption algorithm is listed in addition to 346 md5WithRSAEncryption due to weaknesses in the MD5 hash algorithm 347 [Dobbertin]. The OID for sha1WithRSAEncryption is: 349 sha1WithRSAEncryption OBJECT IDENTIFIER ::= { 350 iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 351 pkcs-1(1) 5 352 } 354 The reference for the algorithm OID and description of 355 sha1WithRSAEncryption is [RFC2437]. 357 2.4. Context Establish Tokens 359 RFC 2025 sets up a context with an initiator first token (REQ-TOKEN), 360 a target reply (REP-TI-TOKEN), and finally an initiator second token 361 (REP-IT-TOKEN) to reply to the target's reply. Since LIPKEY uses 362 SPKM-3 with unilateral authentication, the REP-IT-TOKEN is not used. 363 LIPKEY has certain requirements on the contents of the REQ-TOKEN and 364 REP-TI-TOKEN, but the syntax of the SPKM-3 tokens is not different 365 from RFC 2025's SPKM-1 tokens. 367 2.4.1. REQ-TOKEN Content Requirements 368 2.4.1.1. algId and req-integrity 370 If the SPKM-3 initiator cannot calculate a req-integrity field due to 371 the lack of a target certificate, it MUST use the NULL-MAC I-ALG 372 described earlier in this memorandum. This will produce a zero length 373 bit string in the Integrity field. 375 2.4.1.2. Req-contents 377 Because RFC 2025 requires that the RSAEncryption K-ALG be present, 378 SPKM-1 must be able to map the target (targ-name) to its public key 379 certificate, and thus SPKM can use the RSAEncryption algorithm to 380 fill in the key-estb-req field. Because LIPKEY assumes a low 381 infrastructure deployment, SPKM-3 MUST be prepared to be unable to 382 map the targ-name field of the Req-contents field. This is a 383 contradiction which is resolved by requiring SPKM-3 to support the 384 dhKeyAgreement algorithm. Note that if an SPKM-3 implementation tries 385 to map the target to a certificate, and succeeds, it is free to use 386 the RSAEncryption K-ALG algorithm. It is also free to use an algID 387 other than NULL-MAC in the REQ-TOKEN type. 389 2.4.1.2.1. Options 391 SPKM-3 implementations MUST set the target-certif-data-required bit 392 to 1 if the only K-ALG in the key-estb-set field of Req-contents is 393 dhKeyAgreement. This would normally occur if the SPKM-3 394 implementation cannot resolve the target name to a certificate. 396 2.4.1.2.2. Conf-Algs 398 If the SPKM-3 implementation supports an algorithm weaker than 399 cast5CBC, cast5CBC MUST be listed before the weaker algorithm to 400 encourage the target to negotiate the stronger algorithm. 402 2.4.1.2.3. Intg-Algs 404 Because the initiator will be anonymous (at the SPKM-3 level) and 405 will not have a certificate for itself, the initiator cannot use an 406 integrity algorithm that supports non-repudiation; it must use a MAC 407 algorithm. If the SPKM-3 implementation supports an algorithm weaker 408 than HMAC-MD5, HMAC-MD5 MUST be listed before the weaker algorithm to 409 encourage the target to negotiate the stronger algorithm. 411 2.4.2. REP-TI-TOKEN Content Requirements 413 With the previously described requirements on REQ-TOKEN, the contents 414 of SPKM-3's REP-TI-TOKEN can for the most part be derived from the 415 specification in RFC 2025. The exceptions are the algId and rep-ti- 416 integ fields. 418 2.4.2.1. algId 420 The SPKM-3 target MUST NOT use a NULL-MAC I-ALG; it MUST use a 421 signature algorithm like id-dsa-with-sha1, md5WithRSAEncryption, or 422 sha1WithRSAEncryption. 424 2.4.2.2. rep-ti-integ 426 If the req-token has an algId of NULL-MAC, then the target MUST 427 compute the rep-ti-integ on the concatenation of the req-contents and 428 rep-ti-contents. 430 2.5. Quality of Protection 432 The SPKM-3 initiator and target negotiate the set of algorithms they 433 mutually support, using the procedure defined in Section 5.2 of RFC 434 2025. If a QOP of zero is specified, then the initiator and target 435 will use the first C-ALG (privacy), and I-ALG (integrity) algorithms 436 negotiated. 438 SPKM breaks the QOP into several fields, as reproduced here from 439 Section 5.2 of RFC 2025: 441 Confidentiality Integrity 442 31 (MSB) 16 15 (LSB) 0 443 -------------------------------|------------------------------- 444 | TS(5) | U(3) | IA(4) | MA(4) | TS(5) | U(3) | IA(4) | MA(4) | 445 -------------------------------|------------------------------- 447 The MA subfields enumerate mechanism-defined algorithms. Since this 448 memorandum introduces a new mechanism, SPKM-3, within the SPKM 449 family, it is appropriate to add algorithms to the MA subfields of 450 the respective Confidentiality and Integrity fields. 452 The complete set of Confidentiality MA algorithms is thus: 454 0001 (1) = DES-CBC 455 0010 (2) = cast5CBC 457 Where "0001" and "0010" are in base 2. An SPKM peer that negotiates 458 a confidentiality MA algorithm value of "0010" MUST use a 128 bit 459 key, i.e. set the keyLength values in the cast5CBC Parameters to 128 460 bits. 462 The complete set of Integrity MA algorithms is thus: 464 0001 (1) = md5WithRSAEncryption 465 0010 (2) = DES-MAC 466 0011 (3) = id-dsa-with-sha1 467 0100 (4) = HMAC-MD5 468 0101 (5) = sha1WithRSAEncryption 470 Where "0001" through "0101" are in base 2. 472 Adding support for cast5CBC, id-dsa-with-sha1, HMAC-MD5, and 473 sha1WithRSAEncryption in the above manner to SPKM-1 and SPKM-2 does 474 not impair SPKM-1 and SPKM-2 backward compatibility because, as noted 475 previously, SPKM negotiates algorithms. An older SPKM-1 or SPKM-2 476 that does not recognize MA values for cast5CBC, id-dsa-with-sha1, or 477 HMAC-MD5 will not select them. 479 3. How LIPKEY Uses SPKM 481 3.1. Tokens 483 LIPKEY will invoke SPKM-3 to produce SPKM tokens. Since the mechanism 484 that the application uses is LIPKEY, LIPKEY will wrap some of the 485 SPKM-3 tokens with LIPKEY prefixes. The exact definition of the 486 tokens is described later in this memorandum. 488 3.2. Initiator 490 3.2.1. GSS_Import_name 492 The initiator uses GSS_Import_name to import the target's name, 493 typically, but not necessarily, using the GSS_C_NT_HOSTBASED_SERVICE 494 name type. Ultimately, the output of GSS_Import_name will apply to 495 an SPKM-3 mechanism type because a LIPKEY target is an SPKM-3 target. 497 3.2.2. GSS_Acquire_cred 499 The initiator calls GSS_Acquire_cred. The credentials that are 500 acquired are LIPKEY credentials, a user name and password. How the 501 user name and password is acquired is dependent upon the operating 502 environment. A application that invokes GSS_Acquire_cred() while the 503 application's user has a graphical user interface running might 504 trigger the appearance of a pop up window that prompts for the 505 information. A application embedded into the operating system, such 506 as an NFS [Sandberg] client implemented as a native file system might 507 broadcast a message to the user's terminals telling him to invoke a 508 command that prompts for the information. 510 3.2.3. GSS_Init_sec_context 512 When a program invokes GSS_Init_sec_context on the LIPKEY mechanism 513 type, if the context handle is NULL, the LIPKEY mechanism will in 514 turn invoke GSS_Init_sec_context on an SPKM-3 mechanism implemented 515 according to the requirements described previously. This call to 516 SPKM-3 MUST have the following attributes: 518 * claimant_cred_handle is NULL 520 * mutual_req_flag is FALSE 522 * anon_req_flag is TRUE 524 * input_token is NULL 526 * mech_type is the OID of the SPKM-3 mechanism 528 Keep in mind the above attributes are in the GSS_Init_sec_context 529 call from the LIPKEY mechanism down to the SPKM-3 mechanism. There 530 are no special restrictions placed on the application invoking 531 LIPKEY's GSS_Init_sec_context routine. All other arguments are 532 derived from the LIPKEY GSS_Init_sec_context arguments. 534 The call to the SPKM-3 GSS_Init_sec_context will create an SPKM-3 535 context handle. The remainder of the description of the LIPKEY 536 GSS_Init_sec_context call depends on whether the caller of the LIPKEY 537 GSS_Init_sec_context sets anon_req_flag to TRUE or FALSE. 539 3.2.3.1. LIPKEY Caller Specified anon_req_flag as TRUE 541 If the caller of LIPKEY's GSS_Init_sec_context sets anon_req_flag to 542 TRUE, it MUST return to the LIPKEY caller all the outputs from the 543 SPKM-3 GSS_Init_sec_context call, including the 544 output_context_handle, output_token, and mech_type. In this way, 545 LIPKEY now "gets out of the way" of GSS-API processing between the 546 application and SPKM-3, because nothing in the returned outputs 547 relates to LIPKEY. This is necessary, because LIPKEY context tokens 548 do not have provision for specifying anonymous initiators. This is 549 because SPKM-3 is sufficient for purpose of supporting anonymous 550 initiators in a low infrastructure environment. 552 Clearly, when the LIPKEY caller desires anonymous authentication, 553 LIPKEY does not add any value, but it is simpler to support the 554 feature, than to insist the caller directly use SPKM-3. 556 If all goes well, the caller of LIPKEY will be returned a major 557 status of GSS_S_CONTINUE_NEEDED via SPKM-3, and so the caller of 558 LIPKEY will send the output_token to the target. The caller of 559 LIPKEY then receives the response token from the target, and directly 560 invokes the SPKM-3 GSS_Init_sec_context. Upon return, the major 561 status should be GSS_S_COMPLETE. 563 3.2.3.2. LIPKEY Caller Specified anon_req_flag as FALSE 565 The LIPKEY mechanism will need to allocate a context handle for 566 itself, and record in the LIPKEY context handle the SPKM-3 context 567 handle that was returned in the output_context_handle parameter from 568 the call to the SPKM-3 GSS_Init_sec_context routine. The LIPKEY 569 GSS_Init_sec_context routine will return in output_context_handle the 570 LIPKEY context handle, and in mech_type, the LIPKEY mechanism type. 571 The output_token is as defined later in this memorandum, in the 572 subsection entitled "Context Tokens Prior to SPKM-3 Context 573 Establishment." All the other returned outputs will be those that 574 the SPKM-3 GSS_Init_sec_context routine returned to LIPKEY. If all 575 went well, the SPKM-3 mechanism will have returned a major status of 576 GSS_S_CONTINUE_NEEDED. 578 The caller of the LIPKEY GSS_Init_sec_context routine will see a 579 major status of GSS_S_CONTINUE_NEEDED, and so the caller of LIPKEY 580 will send the output_token to the target. The caller of LIPKEY then 581 receives the target's response token, and invokes the LIPKEY 582 GSS_Init_sec_context routine for a second time. LIPKEY then invokes 583 the SPKM-3 GSS_Init_sec_context for a second time and upon return, 584 the major status should be GSS_S_COMPLETE. 586 While SPKM-3's context establishment is now complete, LIPKEY's 587 context establishment is not yet complete, because the initiator must 588 send to the target the user name and password that was passed to it 589 via the claimant_cred_handle on the first call to the LIPKEY 590 GSS_Init_sec_context routine. LIPKEY uses the established SPKM-3 591 context handle as the input to GSS_Wrap (with conf_req_flag set to 592 TRUE) to encrypt what the claimant_cred_handle refers to (user name 593 and password), and returns that as the output token to the caller of 594 LIPKEY (provided the conf_state output from call to the SPKM-3 595 GSS_Wrap is TRUE), along with a major status of 596 GSS_S_CONTINUE_NEEDED. 598 The caller of LIPKEY sends its second token to the target, and waits 599 for either a GSS_S_COMPLETE response from the target, indicating that 600 the user name and password was accepted, or an error indicating 601 rejection of the user name and password (GSS_S_NO_CRED), or some 602 other appropriate error. 604 The SPKM-3 context remains established while the LIPKEY context is 605 established. If the SPKM-3 context expires before the LIPKEY context 606 is destroyed, the LIPKEY implementation should expire the LIPKEY 607 context and return the appropriate error on the next GSS-API 608 operation. 610 3.2.4. Other operations 612 For other operations, the LIPKEY context acts as a pass through to 613 the SPKM-3 context. Operations that affect or inquire context state, 614 such as GSS_Delete_sec_context, GSS_Export_sec_context, 615 GSS_Import_sec_context, and GSS_Inquire_context will require a pass 616 through to the SPKM-3 context and a state modification of the LIPKEY 617 context. 619 3.3. Target 621 3.3.1. GSS_Import_name 623 As with the initiator, the imported name will be that of the target. 625 3.3.2. GSS_Acquire_cred 627 The acceptor calls the LIPKEY GSS_Acquire_cred routine to get a 628 credential for an SPKM-3 target, via the SPKM-3 GSS_Acquire_cred 629 routine. The desired_name is the output_name from GSS_Import_name. 631 3.3.3. GSS_Accept_sec_context 633 When a program invokes GSS_Accept_sec_context on the LIPKEY mechanism 634 type, if the context handle is NULL, the LIPKEY mechanism will in 635 turn invoke GSS_Accept_sec_context on an SPKM-3 mechanism implemented 636 according the requirements described previously. This call to SPKM-3 637 is no different than what one would expect for a layered call to 638 GSS_Accept_sec_context. 640 If all goes well, the SPKM-3 GSS_Accept_sec_context call succeeds 641 with GSS_S_COMPLETE, and the LIPKEY GSS_Accept_sec_context call 642 returns the output_token to the caller, but with a major status of 643 GSS_S_CONTINUE_NEEDED because the LIPKEY initiator is still expected 644 to send the user name and password. 646 Once the SPKM-3 context is in a GSS_S_COMPLETE state, the next token 647 the target receives will contain the user name and password, wrapped 648 by the output of an SPKM-3 GSS_Wrap call. The target invokes the 649 LIPKEY GSS_Accept_sec_context, which in turn invokes the SPKM-3 650 GSS_Unwrap routine. The LIPKEY GSS_Accept_sec_context routine then 651 compares the user name and password with its user name name and 652 password database. If the initiator's user name and password are 653 valid, GSS_S_COMPLETE is returned to the caller. Otherwise 654 GSS_S_NO_CRED is returned. In either case, a zero length output_token 655 is returned to the caller. The target should send the major status 656 to the initiator and expect no more context tokens for that context. 658 4. LIPKEY Description 660 4.1. Mechanism Type 662 The OID for LIPKEY is to be defined. 664 4.2. Name Types 666 LIPKEY uses only the mechanism independent name types defined in RFC 667 2078. All the name types defined in RFC 2078 are REQUIRED. 669 4.3. Token Formats 671 4.3.1. Context Tokens 673 GSS-API defines the context tokens as: 675 InitialContextToken ::= 676 -- option indication (delegation, etc.) indicated within 677 -- mechanism-specific token 678 [APPLICATION 0] IMPLICIT SEQUENCE { 679 thisMech MechType, 680 innerContextToken ANY DEFINED BY thisMech 681 -- contents mechanism-specific 682 -- ASN.1 structure not required 683 } 685 SubsequentContextToken ::= innerContextToken ANY 686 -- interpretation based on predecessor InitialContextToken 687 -- ASN.1 structure not required 689 The contents of the innerContextToken depend on whether the SPKM-3 690 context is established or not. 692 4.3.1.1. Context Tokens Prior to SPKM-3 Context Establishment 694 In a LIPKEY InitialContextToken, thisMech will be the Object 695 identifier for LIPKEY. However, as long as LIPKEY has not 696 established the SPKM-3 mechanism, the innerContextToken for both the 697 InitialContextToken and the SubsequentContextToken will be the output 698 of an SPKM-3 GSS_Init_sec_context or GSS_Accept_sec_context. So the 699 LIPKEY innerContextToken would be either: 701 * An InitialContextToken, with thisMech set to the object 702 identifier for SPKM-3, with innerContextToken defined to be an 703 SPKMInnerContextToken, as defined in RFC 2025. 705 * A SubsequentContextToken, with innerContextToken defined to be 706 SPKMInnerContextToken 708 4.3.1.2. Post-SPKM-3 Context Establishment Token 710 Once the SPKM-3 context is established, there is just one token sent 711 from the initiator to the target, and no token returned to initiator. 712 This token is the result of a GSS_Wrap (conf_req is set to TRUE) of a 713 user name and password by the SPKM-3 context. This is the SPKM-WRAP 714 token and is partially reproduced here from RFC 2025: 716 SPKM-WRAP ::= SEQUENCE { 717 wrap-header Wrap-Header, 718 wrap-body Wrap-Body 719 } 721 Wrap-Body ::= SEQUENCE { 722 int-cksum BIT STRING, 723 -- Checksum of header and data, 724 -- calculated according to 725 -- algorithm specified in int-alg 726 -- field of wrap-header 727 data BIT STRING 728 -- encrypted data. 729 } 731 The "data" field of Wrap-Body is contains the result of a GSS_Wrap 732 operation on this type: 734 UserName-Password ::= SEQUENCE { 735 user-name OCTET STRING, 736 -- each octet is an octet of a 737 -- UTF-8 [RFC2279] string 738 password OCTET STRING 739 -- each octet is an octet of a 740 -- UTF-8 [RFC2279] string 741 } 743 4.3.2. Tokens from GSS_GetMIC and GSS_Wrap 745 RFC 2078 defines the token emitted by GSS_GetMIC and GSS_Wrap as: 746 PerMsgToken ::= 747 -- as emitted by GSS_GetMIC and processed by GSS_VerifyMIC 748 -- ASN.1 structure not required 749 innerMsgToken ANY 751 SealedMessage ::= 752 -- as emitted by GSS_Wrap and processed by GSS_Unwrap 753 -- includes internal, mechanism-defined indicator 754 -- of whether or not encrypted 755 -- ASN.1 structure not required 756 sealedUserData ANY 758 As one can see, there are no mechanism independent prefixes in 759 PerMSGToken or SealedMessage, and no explicit mechanism specific 760 information either. Since LIPKEY does not add any value to GSS_GetMIC 761 and GSS_Wrap other than passing the message to the SPKM-3 GSS_GetMIC 762 and GSS_Wrap, LIPKEY's PerMsgToken and SealedMessage tokens are 763 exactly what SPKM-3's GSS_GetMIC and GSS_Wrap routines produce. 765 4.4. Quality of Protection 767 LIPKEY, being a pass through for GSS_Wrap and GSS_GetMIC to SPKM-3, 768 does not interpret or alter the QOPs passed to the aforementioned 769 routines or received from their complements, GSS_Unwrap, and 770 GSS_VerifyMIC. Thus, LIPKEY supports the same set of QOPs as SPKM-3. 772 5. Security Considerations 774 5.1. Password Management 776 LIPKEY sends the clear text password encrypted by 128 bit cast5CBC so 777 the risk in this approach is in how the target manages the password 778 after it is done with it. The approach should be safe, provided the 779 target clears the memory (primary and secondary, such as disk) 780 buffers that contained the password, and any hash of the password 781 immediately after it has verified the user's password. 783 5.2. Certification Authorities 785 The initiator must have a list of trusted Certification Authorities 786 in order to verify the checksum (rep-ti-integ) on the SPKM-3 target's 787 context reply token. If it encounters a certificate signed by an 788 unknown and/or untrusted certificate authority, the initiator MUST 789 NOT silently accept the certificate. If it does wish to accept the 790 certificate, it MUST get confirmation from the user running the 791 application that is using GSS-API. 793 5.3. HMAC-MD5 and MD5 Weaknesses 795 While the MD5 hash algorithm has been found to have weaknesses 796 [Dobbertin], the weaknesses do not impact the security of HMAC-MD5 797 [Dobbertin]. 799 5.4. Security of cast5CBC 801 The cast5CBC encryption algorithm is relatively new compared to 802 established algorithms like triple DES, and RC4. Nonetheless, the 803 choice of cast5CBC as the MANDATORY C-ALG for SPKM-3 is advisable. 804 The cast5CBC algorithm is a 128 bit algorithm that the 256 bit 805 cast6CBC [RFC2612] algorithm is based upon. The cast6CBC algorithm 806 was judged by the U.S. National Institute of Standards and Technology 807 (NIST) to have no known major or minor "security gaps," and to have a 808 "high security margin" [AES]. NIST did note some vulnerabilities 809 related to smart card implementations, but many other algorithms NIST 810 analyzed shared the vulnerabilities, and in any case, LIPKEY is by 811 definition not aimed at smart cards. 813 References 815 [AES] Nechvatal, J., Barker, E., Dodson, D., Dworkin, M., Foti, 816 J., Roback, E. (Undated, but no later than 1999). "Status 817 Report on the First Round of the Development of the 818 Advanced Encryption Standard." 819 http://csrc.nist.gov/encryption/aes/round1/r1report.htm 821 [CCITT] CCITT (1988). "Recommendation X.208: Specification of 822 Abstract Syntax Notation One (ASN.1)." 824 [Dobbertin] 825 Dobbertin, H. (1996). "The Status of Md5 After a Recent 826 Attack," RSA Laboratories' CryptoBytes, Volume 2, Number 2. 827 ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto2n2.pdf 829 [EFF] Electronic Frontier Foundation, John Gilmore (Editor) 830 (1998). "Cracking Des: Secrets of Encryption Research, 831 Wiretap Politics & Chip Design," O'Reilly & Associates, 832 ISBN 1565925203. 834 [FIPS] National Institute of Standards and Technology (1995). 835 "Secure Hash Standard" (SHA-1). 836 http://www.itl.nist.gov/fipspubs/fip180-1.htm 838 [IANA] Internet Assigned Numbers Authority (1999). "Network 839 Management Parameters." 840 http://www.isi.edu/in-notes/iana/assignments/smi-numbers 842 [PKCS-3] RSA Laboratories (1993). "PKCS #3: Diffie-Hellman Key- 843 Agreement Standard, Version 1.4." 844 ftp://ftp.rsa.com/pub/pkcs/ascii/pkcs-3.asc 846 [PKIX] Housley, R., Ford, W., Polk, W., Solo, D. (1999). 847 "Internet X.509 Public Key Infrastructure Certificate and 848 CRL Profile." 850 [RFC1831] Srinivasan, R. (1995). "RPC: Remote Procedure Call Protocol 851 Specification Version 2," RFC 1831. 852 http://www.ietf.org/rfc/rfc1831.txt 854 [RFC1832] Srinivasan, R. (1995). "XDR: External Data Representation 855 Standard," RFC 1832. 856 http://www.ietf.org/rfc/rfc1832.txt 858 [RFC1964] Linn, J. (1996). "The Kerberos Version 5 GSS-API 859 Mechanism," RFC 1964. 861 http://www.ietf.org/rfc/rfc1964.txt 863 [RFC2203] Eisler, M., Chiu, A., Ling L. (1997). "RPCSEC_GSS Protocol 864 Specification," RFC 2203. 865 http://www.ietf.org/rfc/rfc2203.txt 867 [RFC2025] Adams, C. (1996). "The Simple Public-Key GSS-API Mechanism 868 (SPKM)," RFC 2025. 869 http://www.ietf.org/rfc/rfc2025.txt 871 [RFC2078] Linn, J. (1997). "Generic Security Service Application 872 Program Interface, Version 2," RFC 2078. 873 http://www.ietf.org/rfc/rfc2078.txt 875 [RFC2104] Krawczyk, H, Bellare, M., Canetti, R. (1997). "HMAC: 876 Keyed-Hashing for Message Authentication," RFC 2104. 877 http://www.ietf.org/rfc/rfc2104.txt 879 [RFC2119] Bradner, S. (1997). "Key words for use in RFCs to Indicate 880 Requirement Levels," RFC 2119. 881 http://www.ietf.org/rfc/rfc2119.txt 883 [RFC2144] Adams, C. (1997). "The CAST-128 Encryption Algorithm," RFC 884 2144. 885 http://www.ietf.org/rfc/rfc2144.txt 887 [RFC2246] Dierks, T., Allen, C. (1999). "The TLS Protocols Version 888 1.0," RFC 2246. 889 http://www.ietf.org/rfc/rfc2246.txt 891 [RFC2279] Yergeau, F. (1998). "UTF-8, a transformation format of ISO 892 10646," RFC 2279. 893 http://www.ietf.org/rfc/rfc2279.txt 895 [RFC2437] Kaliski, B., Staddon, J. (1998). "PKCS #1: RSA Cryptography 896 Specifications Version 2.0, " RFC 2437. 897 http://www.ietf.org/rfc/rfc2437.txt 899 [RFC2459] Housley, R., Ford, W., Polk, W., Solo, D. (1999). "Internet 900 X.509 Public Key Infrastructure Certificate and CRL 901 Profile," RFC 2459. 902 http://www.ietf.org/rfc/rfc2459.txt 904 [RFC2612] Adams, C., Gilchrist, J. (1999). "The CAST-256 Encryption 905 Algorithm," RFC 2612. 906 http://www.ietf.org/rfc/rfc2612.txt 908 [RSA] S/MIME Editor, RSA Data Security, Inc. (1995). "S/MIME 909 Implementation Guide Interoperability Profile, Version 1." 910 ftp://ftp.rsa.com/pub/S-MIME/smimeimp.txt 912 [RSA-IP] Unidentified member of IETF's Public-Key Infrastructure 913 (X.509) Working Group (Undated, but no later than 1999). 914 "RSA's unofficial statement pertaining to PKIX." 915 http://www.ietf.org/ietf/IPR/PKIX-RSA 917 [Sandberg] 918 Sandberg, R., Goldberg, D., Kleiman, S., Walsh, D., Lyon, 919 B. (1985). "Design and Implementation of the Sun Network 920 Filesystem," Proceedings of the 1985 Summer USENIX 921 Technical Conference. 923 [Schneier] 924 Schneier, B. (1996). "Applied Cryptography," John Wiley & 925 Sons, Inc., ISBN 0-471-11709-9. 927 [Young] Young, E.A. (1997). "Index of /archives/net/Crypto/libeay." 928 http://ring.crl.go.jp/archives/net/Crypto/libeay/ 930 Acknowledgments 932 The author thanks and acknowledges: 934 * Jack Kabat for his patient explanation of the intricacies of 935 SPKM, excellent suggestions, and review comments. 937 * Denis Pinkas for his review comments. 939 * Carlisle Adams for his review comments. 941 * This memorandum includes ASN.1 definitions for GSS-API tokens 942 from RFC 2078, which was authored by John Linn. 944 * This memorandum includes ASN.1 definitions and other text from 945 the SPKM definition in RFC 2025, which was authored by Carlisle 946 Adams. 948 Author's Address 950 Address comments related to this memorandum to: 952 cat-ietf@mit.edu 954 Mike Eisler 955 Sun Microsystems, Inc. 956 5565 Wilson Road 957 Colorado Springs, CO 80919 959 Phone: 1-719-599-9026 960 E-mail: mre@eng.sun.com