idnits 2.17.1 draft-ietf-cat-spkmgss-04.txt: 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-25) 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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 2182 lines 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 ([GSSv2], [RFC-1507], [RFC-1422], [KRB5]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 168: '...in algorithms as RECOMMENDED (that is,...' RFC 2119 keyword, line 255: '... This algorithm is RECOMMENDED....' RFC 2119 keyword, line 454: '... certif_data [2] CertificationData OPTIONAL,...' RFC 2119 keyword, line 455: '... auth_data [3] AuthorizationData OPTIONAL...' RFC 2119 keyword, line 481: '... certificationPath [0] CertificationPath OPTIONAL,...' (62 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 (May 25, 1995) is 10563 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 1837, but not defined == Missing Reference: '2' is mentioned on line 1974, but not defined == Missing Reference: '3' is mentioned on line 1975, but not defined == Missing Reference: '0' is mentioned on line 1972, but not defined == Missing Reference: '1' is mentioned on line 1973, but not defined == Missing Reference: '4' is mentioned on line 1976, but not defined == Missing Reference: '5' is mentioned on line 1939, but not defined == Missing Reference: '6' is mentioned on line 1940, but not defined == Missing Reference: '7' is mentioned on line 1941, but not defined == Missing Reference: '8' is mentioned on line 1942, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'Davi89' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-113' == Outdated reference: A later version (-07) exists of draft-ietf-cat-gssv2-01 -- Possible downref: Non-RFC (?) normative reference: ref. 'Juen84' == Outdated reference: A later version (-07) exists of draft-ietf-cat-kerb5gss-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS1' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS3' ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Historic RFC: RFC 1422 ** Downref: Normative reference to an Historic RFC: RFC 1423 ** Downref: Normative reference to an Experimental RFC: RFC 1507 ** Obsolete normative reference: RFC 1508 (Obsoleted by RFC 2078) ** Obsolete normative reference: RFC 1509 (Obsoleted by RFC 2744) ** Obsolete normative reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) -- Possible downref: Non-RFC (?) normative reference: ref. '9798' Summary: 17 errors (**), 0 flaws (~~), 15 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft C. Adams, Bell-Northern Research 2 draft-ietf-cat-spkmgss-04.txt May 25, 1995 4 The Simple Public-Key GSS-API Mechanism (SPKM) 6 STATUS OF THIS MEMO 8 This document is an Internet-Draft. Internet-Drafts are working 9 documents of the Internet Engineering Task Force (IETF), its areas, 10 and its working groups. Note that other groups may also distribute 11 working documents as Internet-Drafts. 13 Internet-Drafts are draft documents valid for a maximum of six 14 months and may be updated, replaced, or obsoleted by 15 other documents at any time. It is inappropriate to use Internet- 16 Drafts as reference material or to cite them other than as 17 "work in progress." 19 To learn the current status of any Internet Draft, please check the 20 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 21 Directories on ds.internic.net (US East Coast), nic.nordu.net 22 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 23 Rim). 25 Comments on this document should be sent to "cat-ietf@mit.edu", the 26 IETF Common Authentication Technology WG discussion list. 28 ABSTRACT 30 This specification defines protocols, procedures, and conventions to 31 be employed by peers implementing the Generic Security Service 32 Application Program Interface (as specified in RFCs 1508 and 1509) 33 when using the Simple Public-Key Mechanism. 35 BACKGROUND 37 Although the Kerberos Version 5 GSS-API mechanism [KRB5] is becoming 38 well-established in many environments, it is important in some 39 applications to have a GSS-API mechanism which is based on a public- 40 key, rather than a symmetric-key, infrastructure. One such mechanism 41 was described as part of the Distributed Authentication Security 42 Service (DASS) in [RFC-1507]. However, the mechanism described in 43 this document has been proposed as an alternative to the DASS 44 mechanism for several reasons. 46 1) The SPKM is simpler than DASS, containing no non-essential 47 functionality. 49 Adams Document Expiration: 25 Nov. 1995 1 51 2) The SPKM allows both unilateral and mutual authentication 52 to be accomplished without the use of secure timestamps, 53 whereas DASS requires timestamps for replay detection. This 54 enables environments which do not have access to secure time 55 to nevertheless have access to secure authentication. 57 3) The SPKM uses Algorithm Identifiers to specify various 58 algorithms to be used by the communicating peers. This allows 59 maximum flexibility for a variety of environments, for future 60 enhancements, and for alternative algorithms. 62 4) The SPKM allows the option of a true, asymmetric algorithm- 63 based, digital signature in the gss_sign() and gss_seal() 64 operations (now called gss_getMIC() and gss_wrap() in [GSSv2], 65 whereas DASS uses an integrity checksum based on a MAC 66 computed with a symmetric algorithm (DES). For some 67 environments, the availability of true digital signatures 68 supporting non-repudiation is a necessity. 70 5) SPKM data formats and procedures are designed to be as similar 71 to those of the Kerberos mechanism as is practical. This is 72 done for ease of implementation in those environments where 73 Kerberos has already been implemented. 75 For the above reasons, it is felt that the SPKM will offer greater 76 flexibility and functionality than DASS, without undue complexity or 77 overhead. 79 KEY MANAGEMENT 81 The key management employed in SPKM is intended to be as compatible 82 as possible with both X.509 [X.509] and PEM [RFC-1422], since these 83 represent large communities of interest and show relative maturity in 84 standards. 86 ACKNOWLEDGMENTS 88 Much of the material in this document is based on the Kerberos 89 Version 5 GSS-API mechanism [KRB5], and is intended to be as 90 compatible with it as possible. This document also owes a great debt 91 to Warwick Ford and Paul Van Oorschot of Bell-Northern Research for 92 many fruitful discussions, to Kelvin Desplanque of Domus Software 93 for implementation-related clarifications, and to John Linn of 94 OpenVision Technologies for helpful comments. 96 Adams Document Expiration: 25 Nov. 1995 2 98 1. OVERVIEW 100 The goal of the Generic Security Service Application Program 101 Interface (GSS-API) is stated in the abstract of [RFC-1508] as 102 follows: 104 "This Generic Security Service Application Program Interface (GSS- 105 API) definition provides security services to callers in a generic 106 fashion, supportable with a range of underlying mechanisms and 107 technologies and hence allowing source-level portability of 108 applications to different environments. This specification defines 109 GSS-API services and primitives at a level independent of 110 underlying mechanism and programming language environment, and is 111 to be complemented by other, related specifications: 113 - documents defining specific parameter bindings for particular 114 language environments; 116 - documents defining token formats, protocols, and procedures to 117 be implemented in order to realize GSS-API services atop 118 particular security mechanisms." 120 The SPKM is an instance of the latter type of document and is 121 therefore termed a "GSS-API Mechanism". This mechanism provides 122 authentication, key establishment, data integrity, and data 123 confidentiality in an on-line distributed application environment 124 using a public-key infrastructure. Because it conforms to the 125 interface defined by [RFC-1508], SPKM can be used as a drop-in 126 replacement by any application which makes use of security services 127 through GSS-API calls (for example, any application which already 128 uses the Kerberos GSS-API for security). The use of a public-key 129 infrastructure allows digital signatures supporting non-repudiation 130 to be employed for message exchanges, and provides other benefits 131 such as scalability to large user populations. 133 The tokens defined in SPKM are intended to be used by application 134 programs according to the GSS API "operational paradigm" (see 135 [RFC-1508] for further details): 137 The operational paradigm in which GSS-API operates is as follows. 138 A typical GSS-API caller is itself a communications protocol [or 139 is an application program which uses a communications protocol], 140 calling on GSS-API in order to protect its communications with 141 authentication, integrity, and/or confidentiality security 142 services. A GSS-API caller accepts tokens provided to it by its 143 local GSS-API implementation [i.e., its GSS-API mechanism] and 144 transfers the tokens to a peer on a remote system; that peer 145 passes the received tokens to its local GSS-API implementation for 146 processing. 148 This document defines two separate GSS-API mechanisms, SPKM-1 and 149 SPKM-2, whose primary difference is that SPKM-2 requires the presence 150 of secure timestamps for the purpose of replay detection during 151 context establishment and SPKM-1 does not. This allows greater 152 flexibility for applications since secure timestamps cannot always 153 be guaranteed to be available in a given environment. 155 Adams Document Expiration: 25 Nov. 1995 3 157 2. ALGORITHMS 159 A number of algorithm types are employed in SPKM. Each type, along 160 with its purpose and a set of specific examples, is described in this 161 section. In order to ensure at least a minimum level of interoper- 162 ability among various implementations of SPKM, one of the integrity 163 algorithms is specified as MANDATORY; all remaining examples (and 164 any other algorithms) may optionally be supported by a given SPKM 165 implementation (note that a GSS-conformant mechanism need not support 166 confidentiality). Making a confidentiality algorithm mandatory may 167 preclude exportability of the mechanism implementation; this document 168 therefore specifies certain algorithms as RECOMMENDED (that is, 169 interoperability will be enhanced if these algorithms are included in 170 all SPKM implementations for which exportability is not a concern). 172 2.1 Integrity Algorithm (I-ALG): 174 Purpose: 176 This algorithm is used to ensure that a message has not been 177 altered in any way after being constructed by the legitimate 178 sender. Depending on the algorithm used, the application of 179 this algorithm may also provide authenticity and support non- 180 repudiation for the message. 182 Examples: 184 md5WithRSA OBJECT IDENTIFIER ::= { 185 iso(1) identified-organization(3) oiw(14) secsig(3) 186 algorithm(2) 3 187 } 189 This algorithm (MANDATORY) provides data integrity and 190 authenticity and supports non-repudiation by computing an 191 RSA signature on the MD5 hash of that data. This is 192 equivalent to md5WithRSAEncryption {1 2 840 113549 1 1 4}, 193 which is defined in [PKCS1]. 195 Note that since this is the only integrity/authenticity 196 algorithm specified to be mandatory at this time, for 197 interoperability reasons it is also stipulated that 198 md5WithRSA be the algorithm used to sign all context 199 establishment tokens (with the possible exception of the 200 initial token in SPKM-1 -- see Section 3.1.1 for details). 201 In future versions of this document, alternate or additional 202 algorithms may be specified to be mandatory and so this 203 stipulation on the context establishment tokens may be 204 removed. 206 Adams Document Expiration: 25 Nov. 1995 4 208 DES-MAC OBJECT IDENTIFIER ::= { 209 iso(1) identified-organization(3) oiw(14) secsig(3) 210 algorithm(2) 10 211 } 213 This algorithm (RECOMMENDED) provides data integrity by 214 computing a DES MAC (as specified by [FIPS-113]) on that 215 data. 217 md5-DES-CBC OBJECT IDENTIFIER ::= { 218 iso(1) identified-organization(3) xx 219 } 221 This algorithm provides data integrity by encrypting, using 222 DES CBC, the MD5 hash of that data. This will typically be 223 faster in practice than computing a DES MAC unless the input 224 data is extremely short (e.g., a few bytes). Note that the 225 strength of this integrity mechanism is (at most) equal to 226 the strength of DES under a known-plaintext attack. 228 sum64-DES-CBC OBJECT IDENTIFIER ::= { 229 iso(1) identified-organization(3) xx 230 } 232 This algorithm provides data integrity by encrypting, using 233 DES CBC, the concatenation of the data and the sum of all 234 the input data blocks (the sum computed using addition 235 modulo 2**64 - 1). Thus, in this algorithm, encryption is a 236 requirement for the integrity to be secure. 238 For comments regarding the security of this integrity 239 algorithm, see [Juen84, Davi89]. 241 2.2 Confidentiality Algorithm (C-ALG): 243 Purpose: 245 This symmetric algorithm is used to generate the encrypted 246 data for gss_seal() / gss_wrap(). 248 Example: 250 DES-CBC OBJECT IDENTIFIER ::= { 251 iso(1) identified-organization(3) oiw(14) secsig(3) 252 algorithm(2) 7 -- carries IV (encoded as an 253 } -- OCTET STRING) as a parameter 255 This algorithm is RECOMMENDED. 257 Adams Document Expiration: 25 Nov. 1995 5 259 2.3 Key Establishment Algorithm (K-ALG): 261 Purpose: 263 This algorithm is used to establish a symmetric key for use 264 by both the initiator and the target over the established 265 context. The keys used for C-ALG and any keyed I-ALGs (for 266 example, DES-MAC) are derived from this context key. As will 267 be seen in Section 3.1, key establishment is done within the 268 X.509 authentication exchange and so the resulting shared 269 symmetric key is authenticated. 271 Examples: 273 RSAEncryption OBJECT IDENTIFIER ::= { 274 iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 275 pkcs-1(1) 1 -- imported from [PKCS1] and [RFC-1423] 276 } 278 In this algorithm (MANDATORY), the context key is generated 279 by the initiator, encrypted with the RSA public key of the 280 target, and sent to the target. The target need not respond 281 to the initiator for the key to be established. 283 id-rsa-key-transport OBJECT IDENTIFIER ::= { 284 iso(1) identified-organization(3) oiw(14) secsig(3) 285 algorithm(2) 22 -- imported from [X9.44] 286 } 288 Similar to RSAEncryption, but source authenticating info. 289 is also encrypted with the target's RSA public key. 291 dhKeyAgreement OBJECT IDENTIFIER ::= { 292 iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 293 pkcs-3(3) 1 294 } 296 In this algorithm, the context key is generated jointly by 297 the initiator and the target using the Diffie-Hellman key 298 establishment algorithm. The target must therefore respond 299 to the initiator for the key to be established (so this 300 K-ALG cannot be used with unilateral authentication in 301 SPKM-2 (see Section 3.1)). 303 During context establishment in SPKM, the initiator offers a set of 304 possible confidentiality algorithms and a set of possible integrity 305 algorithms to the target (note that the term "integrity algorithms" 306 includes digital signature algorithms). The confidentiality 307 algorithms selected by the target become ones that may be used for 308 C-ALG over the established context, and the integrity algorithms 309 selected by the target become ones that may be used for I-ALG over 310 the established context (the target "selects" algorithms by 311 returning, in the same relative order, the subset of each offered 312 list that it supports). Note that any C-ALG and I-ALG may be used 313 for any message over the context and that the first confidentiality 314 algorithm and the first integrity algorithm in the agreed sets become 315 the default algorithms for that context. 316 Adams Document Expiration: 25 Nov. 1995 6 318 The agreed confidentiality and integrity algorithms for a specific 319 context define the valid values of the Quality of Protection (QOP) 320 parameter used in the gss_getMIC() and gss_wrap() calls -- see 321 Section 5.2 for further details. If no response is expected from the 322 target (unilateral authentication in SPKM-2) then the algorithms 323 offered by the initiator are the ones that may be used over the 324 context (if this is unacceptable to the target then a delete token 325 must be sent to the initiator so that the context is never 326 established). 328 Furthermore, in the first context establishment token the initiator 329 offers a set of possible K-ALGs, along with the key (or key half) 330 corresponding to the first algorithm in the set (its preferred 331 algorithm). If this K-ALG is unacceptable to the target then the 332 target must choose one of the other K-ALGs in the set and send this 333 choice along with the key (or key half) corresponding to this choice 334 in its response (otherwise a delete token must be sent so that the 335 context is never established). If necessary (that is, if the target 336 chooses a 2-pass K-ALG such as dhKeyAgreement), the initiator will 337 send its key half in a response to the target. 339 In future versions of SPKM, other algorithms may be specified for any 340 or all of I-ALG, C-ALG, and K-ALG. 342 3. TOKEN FORMATS 344 This section discusses protocol-visible characteristics of the SPKM; 345 it defines elements of protocol for interoperability and is 346 independent of language bindings per [RFC-1509]. 348 The SPKM GSS-API mechanism will be identified by an Object Identifier 349 representing "SPKM-1" or "SPKM-2", having the value: 350 {iso(1) org(3) dod(5) internet(1) security(5) SPKM-1(xx)} 351 or 352 {iso(1) org(3) dod(5) internet(1) security(5) SPKM-2(xx)}, 353 where SPKM-1 uses random numbers for replay detection during context 354 establishment and SPKM-2 uses timestamps (note that for both 355 mechanisms, sequence numbers are used to provide replay and out-of- 356 sequence detection during the context, if this has been requested by 357 the application). 359 Tokens transferred between GSS-API peers (for security context 360 management and per-message protection purposes) are defined. 362 3.1. Context Establishment Tokens 364 Three classes of tokens are defined in this section: "Initiator" 365 tokens, emitted by calls to gss_init_sec_context() and consumed by 366 calls to gss_accept_sec_context(); "Target" tokens, emitted by calls 367 to gss_accept_sec_context() and consumed by calls to 368 gss_init_sec_context(); and "Error" tokens, potentially emitted by 369 calls to gss_init_sec_context() and gss_accept_sec_context(), 370 and potentially consumed by calls to gss_init_sec_context() and 371 gss_accept_sec_context(). 373 Adams Document Expiration: 25 Nov. 1995 7 375 Per RFC-1508, Appendix B, the initial context establishment token 376 will be enclosed within framing as follows: 378 InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE { 379 thisMech MechType, 380 -- MechType is OBJECT IDENTIFIER 381 -- representing "SPKM-1" or "SPKM-2" 382 innerContextToken ANY DEFINED BY thisMech 383 -- contents mechanism-specific 384 } 386 The above GSS-API framing shall be applied to all tokens emitted by 387 the SPKM GSS-API mechanism, including SPKM_REP_TI (the response from 388 the Target to the Initiator), SPKM_REP_IT (the response from the 389 Initiator to the Target), SPKM_ERROR, context-deletion, and 390 per-message tokens, not just to the initial token in a context 391 establishment sequence. While not required by RFC-1508, this enables 392 implementations to perform enhanced error-checking. Furthermore, 393 every innerContextToken will contain a token-id followed by a 394 context-id. See Section 6 for a discussion of these two fields and 395 their use in an SPKM support function. 397 The innerContextToken field of context establishment tokens for the 398 SPKM GSS-API mechanism will consist of a message (SPKM_REQ, 399 SPKM_REP_TI, SPKM_REP_IT or SPKM_ERROR) containing a tok_id field 400 having the value 0100 (hex) for SPKM_REQ messages, 0200 (hex) for 401 SPKM_REP_TI messages, 0300 (hex) for SPKM_REP_IT messages, and 0400 402 (hex) for SPKM_ERROR messages. All innerContextTokens are encoded 403 using Abstract Syntax Notation One Basic Encoding Rules (ASN.1 BER). 405 The SPKM context establishment tokens are defined according to 406 [X.509] Section 10 and are compatible with [9798]. SPKM-1 (random 407 numbers) uses Section 10.3, "Two-way Authentication", when 408 performing unilateral authentication of the target to the initiator 409 and uses Section 10.4, "Three-way Authentication", when mutual 410 authentication is requested by the initiator. SPKM-2 (timestamps) 411 uses Section 10.2, "One-way Authentication", when performing 412 unilateral authentication of the initiator to the target and uses 413 Section 10.3, "Two-way Authentication", when mutual authentication is 414 requested by the initiator. 416 The implication of the above paragraph is that for SPKM-2 unilateral 417 authentication no negotiation of K-ALG can be done (the target either 418 accepts the K-ALG and key given by the initiator or disallows the 419 context). For SPKM-2 mutual or SPKM-1 unilateral authentication some 420 negotiation is possible, but the target can only choose among the 421 one-pass K-ALGs offered by the initiator (or disallow the context). 422 Alternatively, the initiator can request that the target generate and 423 transmit the context key. For SPKM-1 mutual authentication the 424 target can choose any one- or two-pass K-ALG offered by the initiator 425 and, again, can be requested to generate and transmit the key. 427 It is envisioned that typical use of SPKM-1 or SPKM-2 will involve 428 mutual authentication. Although unilateral authentication is avail- 429 able for both mechanisms, its use is not generally recommended. 431 Adams Document Expiration: 25 Nov. 1995 8 433 3.1.1. Context Establishment Tokens - Initiator (first token) 435 In order to accomplish context establishment, it may be necessary 436 that both the initiator and the target have access to the other 437 partys public-key certificate(s). In some environments the 438 initiator may choose to acquire all certificates and send the 439 relevant ones to the target in the first token. In other environ- 440 ments the initiator may request that the target send certificate data 441 in its response token, or each side may individually obtain the 442 certificate data it needs. In any case, however, the SPKM 443 implementation must have the ability to obtain certificates which 444 correspond to a supplied Name. The actual mechanism to be used to 445 achieve this is a local implementation matter and is therefore 446 outside the scope of this specification. 448 Relevant SPKM_REQ syntax is as follows (note that imports from other 449 documents are given in Appendix A): 451 SPKM_REQ ::= SEQUENCE { 452 requestToken REQ_TOKEN, 453 req_integrity Req_Integrity, 454 certif_data [2] CertificationData OPTIONAL, 455 auth_data [3] AuthorizationData OPTIONAL 456 -- see [RFC-1510] for a discussion of auth-data 457 } 459 Req_Integrity ::= CHOICE { 460 sig_integ [0] SIGNATURE REQ_TOKEN, 461 mac_integ [1] MAC REQ_TOKEN 462 } -- the MAC choice can be used only for SPKM-1 and only if 463 -- REQ_TOKEN contains (in key_estb_req) the symmetric key to be 464 -- used over the context. 465 -- Note that the MAC choice reduces processing overhead for SPKM-1 466 -- and allows initiator anonymity in the case of unilateral 467 -- authentication. 469 MAC MACRO ::= 470 BEGIN 471 TYPE NOTATION ::= type ( ToBeMACed ) 472 VALUE NOTATION ::= value ( VALUE SEQUENCE { 473 algId AlgorithmIdentifier, 474 mac BIT STRING } ) 475 -- must be the result of applying the MACing procedure specified 476 -- by algId to the BER-encoded octets of a value of ToBeMACed (the 477 -- context key is to be used as an input to the MACing procedure) 478 END 480 CertificationData ::= SEQUENCE { 481 certificationPath [0] CertificationPath OPTIONAL, 482 certificateRevocationList [1] CertificateList OPTIONAL 483 } -- at least one of the above shall be present 485 Adams Document Expiration: 25 Nov. 1995 9 487 CertificationPath ::= SEQUENCE { 488 userKeyId [0] OCTET STRING OPTIONAL, 489 -- identifier for user's public key 490 userCertif [1] Certificate OPTIONAL, 491 -- certificate containing user's public key 492 verifKeyId [2] OCTET STRING OPTIONAL, 493 -- identifier for user's public verification key 494 userVerifCertif [3] Certificate OPTIONAL, 495 -- certificate containing user's public verification key 496 theCACertificates [4] SEQUENCE OF CertificatePair OPTIONAL 497 -- certification path from target to source 498 } 500 -- Having separate verification fields allows different key pairs 501 -- (possibly corresponding to different algorithms) to be used for 502 -- encryption/decryption and signing/verification. 503 -- Presence of [0] or [1] and absence of [2] and [3] implies that the 504 -- same key pair is to be used for enc/dec and verif/signing (note 505 -- that this practice is not typically recommended). 506 -- Presence of [2] or [3] implies that a separate key pair is to be 507 -- used for verif/signing, and so [0] or [1] must also be present. 508 -- Presence of [4] implies that at least one of [0], [1], [2], and 509 -- [3] must also be present. 511 REQ_TOKEN ::= SEQUENCE { 512 tok_id INTEGER, -- shall contain 0100 (hex) 513 context_id Random_Integer, -- see Section 6.3 514 pvno BIT STRING, -- protocol version number 515 timestamp UTCTime OPTIONAL, -- mandatory for SPKM-2 516 randSrc Random_Integer, 517 targ_name Name, 518 src_name Name, 519 -- may be a value indicating "anonymous" 520 req_data Context_Data, 521 validity [0] Validity OPTIONAL, 522 -- validity interval for key (may be used in the 523 -- computation of security context lifetime) 524 key_estb_set [1] Key_Estb_Algs, 525 -- specifies set of key establishment algorithms 526 key_estb_req BIT STRING OPTIONAL, 527 -- key estb. parameter corresponding to first K-ALG in set 528 -- (not used if initiator is unable or unwilling to 529 -- generate and securely transmit key material to target). 530 -- Established key must be sufficiently long to be used 531 -- with any of the offered confidentiality algorithms. 532 key_src_bind HASHED SEQUENCE { 533 src_name Name, 534 symm_key BIT STRING } OPTIONAL 535 -- used to bind the source name to the symmetric key 536 -- (i.e., the unprotected version of what is trans- 537 -- mitted in key_estb_req). This field must be present 538 -- for the case of SPKM-2 unilateral authentication if 539 -- the K-ALG in use does not provide such a binding (but 540 -- is optional for all other cases). 541 } 543 Adams Document Expiration: 25 Nov. 1995 10 545 HASHED MACRO ::= 546 BEGIN 547 TYPE NOTATION ::= type ( ToBeHashed ) 548 VALUE NOTATION ::= value ( VALUE OCTET STRING ) 549 END -- hash used is the one specified for the MANDATORY I-ALG 551 -- The protocol version number (pvno) parameter is a BIT STRING which 552 -- uses as many bits as necessary to specify all the SPKM protocol 553 -- versions supported by the initiator (one bit per protocol 554 -- version). The protocol specified by this document is version 0. 555 -- Bit 0 of pvno is therefore set if this version is supported; 556 -- similarly, bit 1 is set if version 1 (if defined in the future) is 557 -- supported, and so on. Note that for unilateral authentication 558 -- using SPKM-2, no response token is expected during context 559 -- establishment, so no protocol negotiation can take place. In this 560 -- case, the initiator must set exactly one bit of pvno. 562 -- The "validity" parameter above is the only way within SPKM for 563 -- the initiator to transmit desired context lifetime to the target. 564 -- Since it cannot be guaranteed that the initiator and target have 565 -- synchronized time, the span of time specified by "validity" is to 566 -- be taken as definitive (rather than the actual times given in this 567 -- parameter). 569 Random_Integer ::= BIT STRING 571 -- Each SPKM implementation is responsible for generating a "fresh" 572 -- random number for the purpose of context establishment; that is, 573 -- one which (with high probability) has not been used previously. 574 -- There are no cryptographic requirements on this random number 575 -- (i.e., it need not be unpredictable, it simply needs to be fresh). 577 Context_Data ::= SEQUENCE { 578 channelId ChannelId, -- channel bindings 579 seq_number INTEGER OPTIONAL, -- sequence number 580 options Options, 581 conf_alg Conf_Algs, -- confidentiality. algs. 582 intg_alg Intg_Algs -- integrity algorithm 583 } 585 ChannelId ::= OCTET STRING 587 Options ::= BIT STRING { 588 delegation_state (0), 589 mutual_state (1), 590 replay_det_state (2), -- used for replay det. during context 591 sequence_state (3), -- used for sequencing during context 592 conf_avail (4), 593 integ_avail (5), 594 target_certif_data_required (6) 595 -- used to request targ's certif. data 596 } 598 Adams Document Expiration: 25 Nov. 1995 11 600 Conf_Algs ::= CHOICE { 601 SEQUENCE OF AlgorithmIdentifier, 602 NULL -- used when conf. is not available over context 603 } -- for C-ALG (see Section 5.2 for discussion of QOP) 605 Intg_Algs ::= SEQUENCE OF AlgorithmIdentifier 606 -- for I-ALG (see Section 5.2 for discussion of QOP) 608 Key_Estb_Algs ::= SEQUENCE OF AlgorithmIdentifier 609 -- to allow negotiation of K-ALG 611 A context establishment sequence based on the SPKM will perform 612 unilateral authentication if the mutual_req bit is not set in the 613 application's call to gss_init_sec_context(). SPKM-2 accomplishes 614 this using only SPKM_REQ (thereby authenticating the initiator to the 615 target), while SPKM-1 accomplishes this using both SPKM_REQ and 616 SPKM_REP_TI (thereby authenticating the target to the initiator). 618 Applications requiring authentication of both peers (initiator as 619 well as target) must request mutual authentication, resulting in 620 "mutual_state" being set within SPKM_REQ Options. In response to 621 such a request, the context target will reply to the initiator with 622 an SPKM_REP_TI token. If mechanism SPKM-2 has been chosen, this 623 completes the (timestamp-based) mutual authentication context 624 establishment exchange. If mechanism SPKM-1 has been chosen and 625 SPKM_REP_TI is sent, the initiator will then reply to the target with 626 an SPKM_REP_IT token, completing the (random-number-based) mutual 627 authentication context establishment exchange. 629 Other bits in the Options field of Context_Data are explained in 630 RFC-1508, with the exception of target_certif_data_required, which 631 the initiator sets to TRUE to request that the target return its 632 certification data in the SPKM_REP_TI token. For unilateral authen- 633 tication in SPKM-2 (in which no SPKM_REP_TI token is constructed), 634 this option bit is ignored by both initiator and target. 636 3.1.2. Context Establishment Tokens - Target 638 SPKM_REP_TI ::= SEQUENCE { 639 responseToken REP_TOKEN, 640 certif_data CertificationData OPTIONAL 641 -- included if target_certif_data_required option was 642 -- set to TRUE in SPKM_REQ 643 } 645 Adams Document Expiration: 25 Nov. 1995 12 647 REP_TOKEN ::= SIGNED SEQUENCE { 648 tok_id INTEGER, -- shall contain 0200 (hex) 649 context_id Random_Integer, -- see Section 6.3 650 pvno [0] BIT STRING OPTIONAL, -- prot. version number 651 timestamp [1] UTCTime OPTIONAL, -- mandatory for SPKM-2 652 randTarg [2] Random_Integer, 653 src_name Name, -- the src_name specified in REQ 654 targ_name Name, 655 randSrc Random_Integer, 656 rep_data Context_Data, 657 validity [3] Validity OPTIONAL, 658 -- validity interval for key (used if the target can only 659 -- support a shorter context lifetime than was offered in 660 -- REQ_TOKEN) 661 key_estb_id [4] AlgorithmIdentifier OPTIONAL, 662 -- used if target is changing key estb. algorithm (must be 663 -- a member of initiators key_estb_set) 664 key_estb_str BIT STRING OPTIONAL 665 -- contains (1) the response to the initiators 666 -- key_estb_req (if init. used a 2-pass K-ALG), or (2) the 667 -- key_estb_req corresponding to the K-ALG supplied in 668 -- above key_estb_id, or (3) the key_estb_req corresponding 669 -- to the first K-ALG supplied in initiator's key_estb_id, 670 -- if initiator's (OPTIONAL) key_estb_req was not used 671 -- (target's key_estb_str must be present in this case). 672 -- Established key must be sufficiently long to be 673 -- used with any of the offered conf. algorithms. 674 } 676 -- The protocol version number (pvno) parameter is a BIT STRING which 677 -- uses as many bits as necessary to specify a single SPKM protocol 678 -- version offered by the initiator which is supported by the target 679 -- (one bit per protocol version); that is, the target sets exactly 680 -- one bit of pvno. If none of the versions offered by the initiator 681 -- are supported by the target, a delete token must be returned so 682 -- that the context is never established. If the initiator's pvno 683 -- has only one bit set and the target happens to support this 684 -- protocol version, then this version is used over the context 685 -- and the pvno parameter of REP_TOKEN can be omitted. 687 3.1.3. Context Establishment Tokens - Initiator (second token) 689 Relevant SPKM_REP_IT syntax is as follows: 691 SPKM_REP_IT ::= SIGNED SEQUENCE { 692 tok_id INTEGER, -- shall contain 0300 (hex) 693 context_id Random_Integer, 694 randSrc Random_Integer, 695 randTarg Random_Integer, 696 targ_name Name, -- the targ_name specified in REP_TI 697 src_name Name, -- the src_name specified in REQ 698 key_estb_rep BIT STRING OPTIONAL 699 -- contains the response to targets key_estb_str 700 -- (if target selected a 2-pass K-ALG) 701 } 703 Adams Document Expiration: 25 Nov. 1995 13 705 3.1.4. Error Token 707 The syntax of SPKM_ERROR is as follows: 709 SPKM_ERROR ::= SIGNED SEQUENCE { 710 tok_id INTEGER, -- shall contain 0400 (hex) 711 context_id Random_Integer 712 } 714 The SPKM_ERROR token is used only during the context establishment 715 process. If an SPKM_REQ or SPKM_REP_TI token is received in error, 716 the receiving function (either gss_init_sec_context() or 717 gss_accept_sec_context()) will generate an SPKM_ERROR token to be 718 sent to the peer (if the peer is still in the context establishment 719 process) and will return GSS_S_CONTINUE_NEEDED. If, on the other 720 hand, no context establishment response is expected from the peer 721 (i.e., the peer has completed context establishment), the function 722 will return the appropriate major status code (e.g., GSS_S_BAD_SIG) 723 along with a minor status of GSS_SPKM_S_SG_CONTEXT_ESTB_ABORT and all 724 context-relevant information will be deleted. The output token will 725 not be an SPKM_ERROR token but will instead be an SPKM_DEL token 726 which will be processed by the peer's gss_process_context_token(). 728 If gss_init_sec_context() receives an error token (whether valid or 729 invalid), it will regenerate SPKM_REQ as its output token and return 730 a major status code of GSS_S_CONTINUE_NEEDED. (Note that if the 731 peer's gss_accept_sec_context() receives SPKM_REQ token when it is 732 expecting a SPKM_REP_IT token, it will ignore SPKM_REQ and return a 733 zero-length output token with a major status of 734 GSS_S_CONTINUE_NEEDED.) 736 Similarly, if gss_accept_sec_context() receives an error token 737 (whether valid or invalid), it will regenerate SPKM_REP_TI as its 738 output token and return a major status code of GSS_S_CONTINUE_NEEDED. 740 md5WithRsa is currently stipulated for the signing of context 741 establishment tokens. Discrepancies involving modulus bitlength can 742 be resolved through judicious use of the SPKM_ERROR token. The 743 context initiator signs REQ_TOKEN using the strongest RSA it supports 744 (e.g., 1024 bits). If the target is unable to verify signatures of 745 this length, it sends SPKM_ERROR signed with the strongest RSA that 746 it supports (e.g. 512). 748 At the completion of this exchange, both sides know what RSA 749 bitlength the other supports, since the size of the signature is 750 equal to the size of the modulus. Further exchanges can be made 751 (using successively smaller supported bitlengths) until either an 752 agreement is reached or context establishment is aborted because no 753 agreement is possible. 755 Adams Document Expiration: 25 Nov. 1995 14 757 3.2. Per-Message and Context Deletion Tokens 759 Three classes of tokens are defined in this section: "MIC" tokens, 760 emitted by calls to gss_getMIC() and consumed by calls to 761 gss_verifyMIC(); "Wrap" tokens, emitted by calls to gss_wrap() and 762 consumed by calls to gss_unwrap(); and context deletion tokens, 763 emitted by calls to gss_init_sec_context(), gss_accept_sec_context(), 764 or gss_delete_sec_context() and consumed by calls to 765 gss_process_context_token(). 767 3.2.1. Per-message Tokens - Sign / MIC 769 Use of the gss_sign() / gss_getMIC() call yields a token, separate 770 from the user data being protected, which can be used to verify the 771 integrity of that data as received. The token and the data may be 772 sent separately by the sending application and it is the receiving 773 application's responsibility to associate the received data with the 774 received token. 776 The SPKM_MIC token has the following format: 778 SPKM_MIC ::= SEQUENCE { 779 mic_header Mic_Header, 780 int_cksum BIT STRING 781 -- Checksum over header and data, 782 -- calculated according to algorithm 783 -- specified in int_alg field. 784 } 786 Mic_Header ::= SEQUENCE { 787 tok_id INTEGER, 788 -- shall contain 0101 (hex) 789 context_id Random_Integer, 790 int_alg [0] AlgorithmIdentifier OPTIONAL, 791 -- Integrity algorithm indicator (must 792 -- be one of the agreed integrity 793 -- algorithms for this context). 794 -- field not present = default id. 795 snd_seq [1] SeqNum OPTIONAL -- sequence number field. 796 } 798 SeqNum ::= SEQUENCE { 799 num INTEGER, -- the sequence number itself 800 dir_ind BOOLEAN -- a direction indicator 801 } 803 3.2.1.1. Checksum 805 Checksum calculation procedure (common to all algorithms -- note that 806 for SPKM the term "checksum" includes digital signatures as well as 807 hashes and MACs): Checksums are calculated over the data field, 808 logically prepended by the bytes of the plaintext token header 809 (mic_header). The result binds the data to the entire plaintext 810 header, so as to minimize the possibility of malicious splicing. 812 Adams Document Expiration: 25 Nov. 1995 15 814 For example, if the int_alg specifies the md5WithRSA algorithm, then 815 the checksum is formed by computing an MD5 [RFC-1321] hash over the 816 plaintext data (prepended by the header), and then computing an RSA 817 signature [PKCS1] on the 16-byte MD5 result. The signature is 818 computed using the RSA private key retrieved from the credentials 819 structure and the result (whose length is implied by the "modulus" 820 parameter in the private key) is stored in the int_cksum field. 822 If the int_alg specifies a keyed hashing algorithm (for example, 823 DES-MAC or md5-DES-CBC), then the key to be used is the established 824 context key. Again, the result (whose length is implied by int_alg) 825 is stored in the int_cksum field. 827 3.2.1.2. Sequence Number 829 It is assumed that the underlying transport layers (of whatever pro- 830 tocol stack is being used by the application) will provide adequate 831 communications reliability (that is, non-malicious loss, re-ordering, 832 etc., of data packets will be handled correctly). Therefore, 833 sequence numbers are used in SPKM purely for security, as opposed to 834 reliability, reasons (that is, to avoid malicious loss, replay, or 835 re-ordering of SPKM tokens) -- it is therefore recommended that 836 applications request sequencing and replay detection over all 837 contexts. Note that sequence numbers are used so that there is no 838 requirement for secure timestamps in the message tokens. The 839 initiator's initial sequence number for the current context may be 840 explicitly given in the Context_Data field of SPKM_REQ and the 841 target's initial sequence number may be explicitly given in the 842 Context_Data field of SPKM_REP_TI; if either of these is not given 843 then the default value of 00 is to be used. 845 Sequence number field: The sequence number field is formed from the 846 sender's four-byte sequence number and a Boolean direction- 847 indicator (FALSE - sender is the context initiator, TRUE - sender 848 is the context acceptor). After constructing a gss_sign() or 849 gss_seal() (gss_getMIC() or gss_wrap()) token, the sender's sequence 850 number is incremented by one. 852 3.2.1.3. Sequence Number Processing 854 The receiver of the token will verify the sequence number field by 855 comparing the sequence number with the expected sequence number and 856 the direction indicator with the expected direction indicator. If 857 the sequence number in the token is higher than the expected number, 858 then the expected sequence number is adjusted and GSS_S_GAP_TOKEN is 859 returned. If the token sequence number is lower than the expected 860 number, then the expected sequence number is not adjusted and 861 GSS_S_DUPLICATE_TOKEN or GSS_S_OLD_TOKEN is returned, whichever is 862 appropriate. If the direction indicator is wrong, then the expected 863 sequence number is not adjusted and GSS_S_UNSEQ_TOKEN is returned 865 Since the sequence number is used as part of the input to the 866 integrity checksum, sequence numbers need not be encrypted, and 867 attempts to splice a checksum and sequence number from different 868 messages will be detected. The direction indicator will detect 869 tokens which have been maliciously reflected. 871 Adams Document Expiration: 25 Nov. 1995 16 873 3.2.2. Per-message Tokens - Seal / Wrap 875 Use of the gss_seal() / gss_wrap() call yields a token which 876 encapsulates the input user data (optionally encrypted) along with 877 associated integrity check quantities. The token emitted by 878 gss_seal() / gss_wrap() consists of an integrity header followed by a 879 body portion that contains either the plaintext data (if conf_alg = 880 NULL) or encrypted data (using the key specified in 3.2.2.4 with one 881 of the agreed C-ALGs for this context). 883 The SPKM_WRAP token has the following format: 885 SPKM_WRAP ::= SEQUENCE { 886 wrap_header Wrap_Header, 887 wrap_body Wrap_Body 888 } 890 Wrap_Header ::= SEQUENCE { 891 tok_id INTEGER, 892 -- shall contain 0201 (hex) 893 context_id Random_Integer, 894 int_alg [0] AlgorithmIdentifier OPTIONAL, 895 -- Integrity algorithm indicator (must 896 -- be one of the agreed integrity 897 -- algorithms for this context). 898 -- field not present = default id. 899 conf_alg [1] Conf_Alg OPTIONAL, 900 -- Confidentiality algorithm indicator 901 -- (must be NULL or one of the agreed 902 -- confidentiality algorithms for this 903 -- context). 904 -- field not present = default id. 905 -- NULL = none (no conf. applied). 906 snd_seq [2] SeqNum OPTIONAL 907 -- sequence number field. 908 } 910 Wrap_Body ::= SEQUENCE { 911 int_cksum BIT STRING, 912 -- Checksum of header and data, 913 -- calculated according to algorithm 914 -- specified in int_alg field. 915 data BIT STRING 916 -- encrypted or plaintext data. 917 } 919 Conf_Alg ::= CHOICE { 920 AlgorithmIdentifier, 921 NULL 922 } 924 Adams Document Expiration: 25 Nov. 1995 17 926 3.2.2.1: Confounding 928 As in [KRB5], an 8-byte random confounder is prepended to the data to 929 compensate for the fact that an IV of zero is used for encryption. 930 The result is referred to as the "confounded" data field. 932 3.2.2.2. Checksum 934 Checksum calculation procedure (common to all algorithms): Checksums 935 are calculated over the plaintext data field, logically prepended by 936 the bytes of the plaintext token header (wrap_header). As with 937 gss_sign() / gss_getMIC(), the result binds the data to the entire 938 plaintext header, so as to minimize the possibility of malicious 939 splicing. 941 The examples for md5WithRSA and DES-MAC are exactly as specified in 942 3.2.1.1. 944 If int_alg specifies md5-DES-CBC and conf_alg specifies anything 945 other than DES-CBC, then the checksum is computed according to 946 3.2.1.1 and the result is stored in int_cksum. However, if conf_alg 947 specifies DES-CBC then the encryption and the integrity is done 948 as follows. An MD5 [RFC-1321] hash is computed over the plaintext 949 data (prepended by the header). This 16-byte value is appended to 950 the concatenation of the "confounded" data and 1-8 padding bytes (the 951 padding is as specified in [KRB5] for DES-CBC). The result is 952 then CBC encrypted using the context key and placed in the "data" 953 field of Wrap_Body. The final two blocks of ciphertext (i.e., the 954 encrypted MD5 hash) are also placed in the int_cksum field of 955 Wrap_Body as the integrity checksum. 957 If int_alg specifies sum64-DES-CBC then conf_alg must specify DES-CBC 958 (i.e., confidentiality must be requested by the calling application 959 or SPKM will return an error). Encryption and integrity are done in 960 a single pass using the context key as follows. The sum (modulo 961 2**64 - 1) of all plaintext data blocks (prepended by the header) is 962 computed. This 8-byte value is appended to the concatenation of the 963 "confounded" data and 1-8 padding bytes (the padding is as specified 964 in [KRB5] for DES-CBC). As above, the result is then CBC encrypted 965 and placed in the "data" field of Wrap_Body. The final block of 966 ciphertext (i.e., the encrypted sum) is also placed in the int_cksum 967 field of Wrap_Body as the integrity checksum. 969 3.2.2.3 Sequence Number 971 Sequence numbers are computed and processed for gss_wrap() exactly 972 as specified in 3.2.1.2 and 3.2.1.3. 974 Adams Document Expiration: 25 Nov. 1995 18 976 3.2.2.4: Data Encryption 978 The following procedure is followed unless (a) conf_alg is NULL (no 979 encryption), or (b) conf_alg is DES-CBC and int_alg is md5-DES-CBC 980 (encryption as specified in 3.2.2.2), or (c) int_alg is sum64-DES-CBC 981 (encryption as specified in 3.2.2.2): 983 The "confounded" data is padded and encrypted according to the 984 algorithm specified in the conf_alg field. The data is encrypted 985 using CBC with an IV of zero. The key used is derived from the 986 established context key by XOR-ing the context key with the hexadeci- 987 mal constant F0F0F0...F0 (this ensures that the key used for encryp- 988 tion and the key used for a separate, keyed integrity algorithm -- 989 for example DES-MAC, but not sum64-DES-CBC -- are different). 991 3.2.3. Context deletion token 993 The token emitted by gss_delete_sec_context() is based on the format 994 for tokens emitted by gss_sign() / gss_getMIC(). 996 The SPKM_DEL token has the following format: 998 SPKM_DEL ::= SEQUENCE { 999 del_header Del_Header, 1000 int_cksum BIT STRING 1001 -- Checksum of header, calculated 1002 -- according to algorithm specified 1003 -- in int_alg field. 1004 } 1006 Del_Header ::= SEQUENCE { 1007 tok_id INTEGER, 1008 -- shall contain 0301 (hex) 1009 context_id Random_Integer, 1010 int_alg [0] AlgorithmIdentifier OPTIONAL, 1011 -- Integrity algorithm indicator (must 1012 -- be one of the agreed integrity 1013 -- algorithms for this context). 1014 -- field not present = default id. 1015 snd_seq [1] SeqNum OPTIONAL 1016 -- sequence number field. 1017 } 1019 The field snd_seq will be calculated as for tokens emitted by 1020 gss_sign() / gss_getMIC(). The field int_cksum will be calculated as 1021 for tokens emitted by gss_sign() / gss_getMIC(), except that the 1022 user-data component of the checksum data will be a zero-length 1023 string. 1025 Adams Document Expiration: 25 Nov. 1995 19 1027 If a valid delete token is received, then the SPKM implementation 1028 will delete the context and gss_process_context_token() will return a 1029 major status of GSS_S_COMPLETE and a minor status of 1030 GSS_SPKM_S_SG_CONTEXT_DELETED. If, on the other hand, the delete 1031 token is invalid, the context will not be deleted and 1032 gss_process_context_token() will return the appropriate major status 1033 (GSS_S_BAD_SIG, for example) and a minor status of 1034 GSS_SPKM_S_SG_BAD_DELETE_TOKEN_RECD. The application may wish to 1035 take some action at this point to check the context status (such as 1036 sending a sealed/wrapped test message to its peer and waiting for a 1037 sealed/wrapped response). 1039 4. NAME TYPES AND OBJECT IDENTIFIERS 1041 No mandatory name forms have yet been defined for SPKM. This section 1042 is for further study. 1044 4.1. Optional Name Forms 1046 This section discusses name forms which may optionally be supported 1047 by implementations of the SPKM GSS-API mechanism. It is recognized 1048 that OS-specific functions outside GSS-API are likely to exist in 1049 order to perform translations among these forms, and that GSS-API 1050 implementations supporting these forms may themselves be layered atop 1051 such OS-specific functions. Inclusion of this support within GSS-API 1052 implementations is intended as a convenience to applications. 1054 4.1.1. User Name Form 1056 This name form shall be represented by the Object Identifier {iso(1) 1057 member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) 1058 generic(1) user_name(1)}. The recommended symbolic name for this 1059 type is "GSS_SPKM_NT_USER_NAME". 1061 This name type is used to indicate a named user on a local system. 1062 Its interpretation is OS-specific. This name form is constructed as: 1064 username 1066 4.1.2. Machine UID Form 1068 This name form shall be represented by the Object Identifier {iso(1) 1069 member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) 1070 generic(1) machine_uid_name(2)}. The recommended symbolic name for 1071 this type is "GSS_SPKM_NT_MACHINE_UID_NAME". 1073 This name type is used to indicate a numeric user identifier 1074 corresponding to a user on a local system. Its interpretation is 1075 OS-specific. The gss_buffer_desc representing a name of this type 1076 should contain a locally-significant uid_t, represented in host byte 1077 order. The gss_import_name() operation resolves this uid into a 1078 username, which is then treated as the User Name Form. 1080 Adams Document Expiration: 25 Nov. 1995 20 1082 4.1.3. String UID Form 1084 This name form shall be represented by the Object Identifier {iso(1) 1085 member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) 1086 generic(1) string_uid_name(3)}. The recommended symbolic name for 1087 this type is "GSS_SPKM_NT_STRING_UID_NAME". 1089 This name type is used to indicate a string of digits representing 1090 the numeric user identifier of a user on a local system. Its 1091 interpretation is OS-specific. This name type is similar to the 1092 Machine UID Form, except that the buffer contains a string 1093 representing the uid_t. 1095 5. PARAMETER DEFINITIONS 1097 This section defines parameter values used by the SPKM GSS-API 1098 mechanism. It defines interface elements in support of portability. 1100 5.1. Minor Status Codes 1102 This section recommends common symbolic names for minor_status values 1103 to be returned by the SPKM GSS-API mechanism. Use of these 1104 definitions will enable independent implementors to enhance 1105 application portability across different implementations of the 1106 mechanism defined in this specification. (In all cases, 1107 implementations of gss_display_status() will enable callers to 1108 convert minor_status indicators to text representations.) Each 1109 implementation must make available, through include files or other 1110 means, a facility to translate these symbolic names into the concrete 1111 values which a particular GSS-API implementation uses to represent 1112 the minor_status values specified in this section. It is recognized 1113 that this list may grow over time, and that the need for additional 1114 minor_status codes specific to particular implementations may arise. 1116 5.1.1. Non-SPKM-specific codes (Minor Status Code MSB, bit 31, SET) 1118 5.1.1.1. GSS-Related codes (Minor Status Code bit 30 SET) 1120 GSS_S_G_VALIDATE_FAILED 1121 /* "Validation error" */ 1122 GSS_S_G_BUFFER_ALLOC 1123 /* "Couldn't allocate gss_buffer_t data" */ 1124 GSS_S_G_BAD_MSG_CTX 1125 /* "Message context invalid" */ 1126 GSS_S_G_WRONG_SIZE 1127 /* "Buffer is the wrong size" */ 1128 GSS_S_G_BAD_USAGE 1129 /* "Credential usage type is unknown" */ 1130 GSS_S_G_UNAVAIL_QOP 1131 /* "Unavailable quality of protection specified" */ 1133 5.1.1.2. Implementation-Related codes (Minor Status Code bit 30 OFF) 1135 GSS_S_G_MEMORY_ALLOC 1136 /* "Couldn't perform requested memory allocation" */ 1138 Adams Document Expiration: 25 Nov. 1995 21 1140 5.1.2. SPKM-specific-codes (Minor Status Code MSB, bit 31, OFF) 1142 GSS_SPKM_S_SG_CONTEXT_ESTABLISHED 1143 /* "Context is already fully established" */ 1144 GSS_SPKM_S_SG_BAD_INT_ALG_TYPE 1145 /* "Unknown integrity algorithm type in token" */ 1146 GSS_SPKM_S_SG_BAD_CONF_ALG_TYPE 1147 /* "Unknown confidentiality algorithm type in token" */ 1148 GSS_SPKM_S_SG_BAD_KEY_ESTB_ALG_TYPE 1149 /* "Unknown key establishment algorithm type in token" */ 1150 GSS_SPKM_S_SG_CTX_INCOMPLETE 1151 /* "Attempt to use incomplete security context" */ 1152 GSS_SPKM_S_SG_BAD_INT_ALG_SET 1153 /* "No integrity algorithm in common from offered set" */ 1154 GSS_SPKM_S_SG_BAD_CONF_ALG_SET 1155 /* "No confidentiality algorithm in common from offered set" */ 1156 GSS_SPKM_S_SG_BAD_KEY_ESTB_ALG_SET 1157 /* "No key establishment algorithm in common from offered set" */ 1158 GSS_SPKM_S_SG_NO_PVNO_IN_COMMON 1159 /* "No protocol version number in common from offered set" */ 1160 GSS_SPKM_S_SG_INVALID_TOKEN_DATA 1161 /* "Data is improperly formatted: cannot encode into token" */ 1162 GSS_SPKM_S_SG_INVALID_TOKEN_FORMAT 1163 /* "Received token is improperly formatted: cannot decode" */ 1164 GSS_SPKM_S_SG_CONTEXT_DELETED 1165 /* "Context deleted at peer's request" */ 1166 GSS_SPKM_S_SG_BAD_DELETE_TOKEN_RECD 1167 /* "Invalid delete token received -- context not deleted" */ 1168 GSS_SPKM_S_SG_CONTEXT_ESTB_ABORT 1169 /* "Unrecoverable context establishment error. Context deleted" */ 1171 5.2. Quality of Protection Values 1173 The Quality of Protection (QOP) parameter is used in the SPKM GSS-API 1174 mechanism as input to gss_sign() and gss_seal() (gss_getMIC() and 1175 gss_wrap()) to select among alternate confidentiality and 1176 integrity-checking algorithms. Once these sets of algorithms have 1177 been agreed upon by the context initiator and target, the QOP 1178 parameter simply selects from these ordered sets. 1180 More specifically, the SPKM_REQ token sends an ordered sequence of 1181 Alg. IDs specifying integrity-checking algorithms supported by the 1182 initiator and an ordered sequence of Alg. IDs specifying 1183 confidentiality algorithms supported by the initiator. The target 1184 returns the subset of the offered integrity-checking Alg. IDs which 1185 it supports and the subset of the offered confidentiality Alg. IDs 1186 which it supports in the SPKM_REP_TI token (in the same relative 1187 orders as those given by the initiator). Thus, the initiator and 1188 target each know the algorithms which they themselves support and the 1189 algorithms which both sides support (the latter are defined to be 1190 those supported over the established context). The QOP parameter has 1191 meaning and validity with reference to this knowledge. For example, 1192 an application may request integrity algorithm number 3 as defined by 1193 the mechanism specification. If this algorithm is supported over 1194 this context then it is used; otherwise, GSS_S_FAILURE and an 1195 appropriate minor status code are returned. 1197 Adams Document Expiration: 25 Nov. 1995 22 1199 If the SPKM_REP_TI token is not used (unilateral authentication using 1200 SPKM-2), then the "agreed" sets of Alg. IDs are simply taken to be 1201 the initiator's sets (if this is unacceptable to the target then it 1202 must return an error token so that the context is never established). 1203 Note that, in the interest of interoperability, the initiator is not 1204 required to offer every algorithm it supports; rather, it may offer 1205 only the mandated/recommended SPKM algorithms since these are likely 1206 to be supported by the target. 1208 The QOP parameter for SPKM is defined to be a 32-bit unsigned integer 1209 (an OM_uint32) with the following bit-field assignments: 1211 Confidentiality Integrity 1212 31 (MSB) 16 15 (LSB) 0 1213 ------------------------------------|----------------------------------- 1214 | TS (5) | U(3) | IA (4) | MA (4) | TS (5) | U(3) | IA (4) | MA(4) | 1215 ------------------------------------|----------------------------------- 1217 where 1219 TS is a 5-bit Type Specifier (a semantic qualifier whose value 1220 specifies the type of algorithm which may be used to protect the 1221 corresponding token -- see below for details); 1223 U is a 3-bit Unspecified field (available for future 1224 use/expansion); 1226 IA is a 4-bit field enumerating Implementation-specific 1227 Algorithms; and 1229 MA is a 4-bit field enumerating Mechanism-defined Algorithms. 1231 The interpretation of the QOP parameter is as follows (note that the 1232 same procedure is used for both the confidentiality and the integrity 1233 halves of the parameter). The MA field is examined first. If it is 1234 non-zero then the algorithm used to protect the token is the 1235 mechanism-specified algorithm corresponding to that integer value. 1237 If MA is zero then IA is examined. If this field value is non-zero 1238 then the algorithm used to protect the token is the implementation- 1239 specified algorithm corresponding to that integer value (if this 1240 algorithm is available over the established context). Note that use 1241 of this field may hinder portability since a particular value may 1242 specify one algorithm in one implementation of the mechanism and may 1243 not be supported or may specify a completely different algorithm in 1244 another implementation of the mechanism. 1246 Finally, if both MA and IA are zero then TS is examined. A value of 1247 zero for TS specifies the default algorithm for the established 1248 context, which is defined to be the first algorithm on the 1249 initiator's list of offered algorithms (confidentiality or integrity, 1250 depending on which half of QOP is being examined) which is supported 1251 over the context. A non-zero value for TS corresponds to a 1252 particular algorithm qualifier and selects the first algorithm 1253 supported over the context which satisfies that qualifier. 1255 Adams Document Expiration: 25 Nov. 1995 23 1257 The following TS values (i.e., algorithm qualifiers) are specified; 1258 other values may be added in the future. 1260 For the Confidentiality TS field: 1262 00001 (1) = SPKM_SYM_ALG_STRENGTH_STRONG 1263 00010 (2) = SPKM_SYM_ALG_STRENGTH_MEDIUM 1264 00011 (3) = SPKM_SYM_ALG_STRENGTH_WEAK 1266 For the Integrity TS field: 1268 00001 (1) = SPKM_INT_ALG_NON_REPUDIABLE 1269 00010 (2) = SPKM_INT_ALG_REPUDIABLE 1271 Clearly, qualifiers such as strong, medium, and weak are debatable 1272 and likely to change with time, but for the purposes of this version 1273 of the specification we define these terms as follows. A 1274 confidentiality algorithm is "weak" if the effective key length of 1275 the cipher is 40 bits or less; it is "medium-strength" if the 1276 effective key length is strictly between 40 and 80 bits; and it is 1277 "strong" if the effective key length is 80 bits or greater. (Note 1278 that "effective key length" describes the computational effort 1279 required to break a cipher using the best-known cryptanalytic attack 1280 against that cipher.) 1282 A five-bit TS field allows up to 31 qualifiers for each of 1283 confidentiality and integrity (since "0" is reserved for "default"). 1284 This document specifies three for confidentiality and two for 1285 integrity, leaving a lot of room for future specification. 1286 Suggestions of qualifiers such as "fast", "medium-speed", and "slow" 1287 have been made, but such terms are difficult to quantify (and in any 1288 case are platform- and processor-dependent), and so have been left 1289 out of this initial specification. The intention is that the TS 1290 terms be quantitative, environment-independent qualifiers of 1291 algorithms, as much as this is possible. 1293 Use of the QOP structure as defined above is ultimately meant to be 1294 as follows. 1296 - TS values are specified at the GSS-API level and are therefore 1297 portable across mechanisms. Applications which know nothing about 1298 algorithms are still able to choose "quality" of protection for 1299 their message tokens. 1301 - MA values are specified at the mechanism level and are therefore 1302 portable across implementations of a mechanism. For example, all 1303 implementations of the Kerberos V5 GSS mechanism must support 1305 GSS_KRB5_INTEG_C_QOP_MD5 (value: 1) 1306 GSS_KRB5_INTEG_C_QOP_DES_MD5 (value: 2) 1307 GSS_KRB5_INTEG_C_QOP_DES_MAC (value: 3). 1309 (Note that these Kerberos-specified integrity QOP values do not 1310 conflict with the QOP structure defined above.) 1312 Adams Document Expiration: 25 Nov. 1995 24 1314 - IA values are specified at the implementation level (in user 1315 documentation, for example) and are therefore typically non- 1316 portable. An application which is aware of its own mechanism 1317 implementation and the mechanism implementation of its peer, 1318 however, is free to use these values since they will be perfectly 1319 valid and meaningful over that context and between those peers. 1321 The receiver of a token must pass back to its calling application a 1322 QOP parameter with all relevant fields set. For example, if 1323 triple-DES has been specified by a mechanism as algorithm 8, then 1324 a receiver of a triple-DES-protected token must pass to its 1325 application (QOP Confidentiality TS=1, IA=0, MA=8). In this way, 1326 the application is free to read whatever part of the QOP it 1327 understands (TS or IA/MA). 1329 To aid in implementation and interoperability, the following 1330 stipulation is made. The set of integrity Alg. IDs sent by the 1331 initiator must contain at least one specifying an algorithm which 1332 computes a digital signature supporting non-repudiation, and must 1333 contain at least one specifying any other (repudiable) integrity 1334 algorithm. The subset of integrity Alg. IDs returned by the target 1335 must also contain at least one specifying an algorithm which computes 1336 a digital signature supporting non-repudiation, and at least one 1337 specifying a repudiable integrity algorithm. 1339 The reason for this stipulation is to ensure that every SPKM 1340 implementation will provide an integrity service which supports non- 1341 repudiation and one which does not support non-repudiation. An 1342 application with no knowledge of underlying algorithms can choose one 1343 or the other by passing (QOP Integrity TS=1, IA=MA=0) or (QOP 1344 Integrity TS=2, IA=MA=0). 1346 Finally, in accordance with the MANDATORY and RECOMMENDED algorithms 1347 given in Section 2, the following QOP values are specified for SPKM. 1349 For the Confidentiality MA field: 1351 0001 (1) = DES-CBC 1353 For the Integrity MA field: 1355 0001 (1) = md5WithRSA 1356 0010 (2) = DES-MAC 1358 6. SUPPORT FUNCTIONS 1360 This section describes a mandatory support function for SPKM- 1361 conformant implementations which may, in fact, be of value in all 1362 GSS-API mechanisms. It makes use of the token_id and context_id 1363 fields which are included in SPKM context-establishment, error, 1364 context-deletion, and per-message tokens. The function is defined 1365 in the following section. 1367 Adams Document Expiration: 25 Nov. 1995 25 1369 6.1. SPKM_Parse_token call 1371 Inputs: 1373 o input_token OCTET STRING 1375 Outputs: 1377 o major_status INTEGER, 1379 o minor_status INTEGER, 1381 o mech_type OBJECT IDENTIFIER, 1383 o token_type INTEGER, 1385 o context_handle CONTEXT HANDLE, 1387 Return major_status codes: 1389 o GSS_S_COMPLETE indicates that the input_token could be parsed for 1390 all relevant fields. The resulting values are stored in 1391 mech_type, token_type and context_handle, respectively (with NULLs 1392 in any parameters which are not relevant). 1394 o GSS_S_DEFECTIVE_TOKEN indicates that either the token_id or the 1395 context_id (if one was expected) could not be parsed. A non-NULL 1396 return value in token_type indicates that the latter situation 1397 occurred. 1399 o GSS_S_NO_TYPE indicates that the token_id could be parsed, but it 1400 did not correspond to any valid token_type. 1402 (Note that this major status code has not been defined for GSS in 1403 RFC-1508. Until such a definition is made (if ever), SPKM 1404 implementations should instead return GSS_S_DEFECTIVE_TOKEN with 1405 both token_type and context_handle set to NULL. This essentially 1406 implies that an unrecognized token_id is considered to be 1407 equivalent to a field which could not be parsed.) 1409 o GSS_S_NO_CONTEXT indicates that the context_id could be parsed, 1410 but it did not correspond to any valid context_handle. 1412 o GSS_S_FAILURE indicates that the mechanism type could not be 1413 parsed (for example, the token may be corrupted). 1415 SPKM_Parse_token() is used to return to an application the mechanism 1416 type, token type, and context handle which correspond to a given 1417 input token. Since GSS-API tokens are meant to be opaque to the 1418 calling application, this function allows the application to 1419 determine information about the token without having to violate the 1420 opaqueness intention of GSS. Of primary importance is the token 1421 type, which the application can then use to decide which GSS function 1422 to call in order to have the token processed. 1424 Adams Document Expiration: 25 Nov. 1995 26 1426 If all tokens are framed as suggested in RFC-1508, Appendix B 1427 (specified both in the Kerberos V5 GSS mechanism [KRB5] and in this 1428 document), then any mechanism implementation should be able to return 1429 at least the mech_type parameter (the other parameters being NULL) 1430 for any uncorrupted input token. If the mechanism implementation 1431 whose SPKM_Parse_token() function is being called does recognize the 1432 token, it can return token_type so that the application can 1433 subsequently call the correct GSS function. Finally, if the 1434 mechanism provides a context_id field in its tokens (as SPKM does), 1435 then an implementation can map the context_id to a context_handle and 1436 return this to the application. This is necessary for the situation 1437 where an application has multiple contexts open simultaneously, all 1438 using the same mechanism. When an incoming token arrives, the 1439 application can use this function to determine not only which GSS 1440 function to call, but also which context_handle to use for the call. 1441 Note that this function does no cryptographic processing to determine 1442 the validity of tokens; it simply attempts to parse the mech_type, 1443 token_type, and context_id fields of any token it is given. Thus, it 1444 is conceivable, for example, that an arbitrary buffer of data might 1445 start with random values which look like a valid mech_type and that 1446 SPKM_Parse_token() would return incorrect information if given this 1447 buffer. While conceivable, however, such a situation is unlikely. 1449 The SPKM_Parse_token() function is mandatory for SPKM-conformant 1450 implementations, but it is optional for applications. That is, if 1451 an application has only one context open and can guess which GSS 1452 function to call (or is willing to put up with a few error codes), 1453 then it need never call SPKM_Parse_token(). Furthermore, if this 1454 function ever migrates up to the GSS-API level, then 1455 SPKM_Parse_token() will be deprecated at that time in favour of 1456 GSS_Parse_token(), or whatever the new name and function 1457 specification might be. Note finally that no minor status return 1458 codes have been defined for this function at this time. 1460 6.2. The token_type Output Parameter 1462 The following token types are defined: 1464 GSS_INIT_TOKEN = 1 1465 GSS_ACCEPT_TOKEN = 2 1466 GSS_ERROR_TOKEN = 3 1467 GSS_SIGN_TOKEN = GSS_GETMIC_TOKEN = 4 1468 GSS_SEAL_TOKEN = GSS_WRAP_TOKEN = 5 1469 GSS_DELETE_TOKEN = 6 1471 All SPKM mechanisms shall be able to perform the mapping from the 1472 token_id which is included in every token to one of the above token 1473 types. Applications should be able to decide, on the basis of 1474 token_type, which GSS function to call (for example, if the token is 1475 a GSS_INIT_TOKEN then the application will call 1476 gss_accept_sec_context(), and if the token is a GSS_WRAP_TOKEN then 1477 the application will call gss_unwrap()). 1479 Adams Document Expiration: 25 Nov. 1995 27 1481 6.3. The context_handle Output Parameter 1483 The SPKM mechanism implementation is responsible for maintaining a 1484 mapping between the context_id value which is included in every token 1485 and a context_handle, thus associating an individual token with its 1486 proper context. Clearly the value of context_handle may be locally 1487 determined and may, in fact, be associated with memory containing 1488 sensitive data on the local system, and so having the context_id 1489 actually be set equal to a computed context_handle will not work in 1490 general. Conversely, having the context_handle actually be set equal 1491 to a computed context_id will not work in general either, because 1492 context_handle must be returned to the application by the first call 1493 to gss_init_sec_context() or gss_accept_sec_context(), whereas 1494 uniqueness of the context_id (over all contexts at both ends) 1495 may require that both initiator and target be involved in the 1496 computation. Consequently, context_handle and context_id must be 1497 computed separately and the mechanism implementation must be able to 1498 map from one to the other by the completion of context establishment 1499 at the latest. 1501 Computation of context_id during context establishment is 1502 accomplished as follows. Each SPKM implementation is responsible for 1503 generating a "fresh" random number; that is, one which (with high 1504 probability) has not been used previously. Note that there are no 1505 cryptographic requirements on this random number (i.e., it need not 1506 be unpredictable, it simply needs to be fresh). The initiator passes 1507 its random number to the target in the context_id field of the 1508 SPKM_REQ token. If no further context establishment tokens are 1509 expected (as for unilateral authentication in SPKM-2), then this 1510 value is taken to be the context_id (if this is unacceptable to the 1511 target then an error token must be generated). Otherwise, the target 1512 generates its random number and concatenates it to the end of the 1513 initiator's random number. This concatenated value is then taken to 1514 be the context_id and is used in SPKM_REP_TI and in all subsequent 1515 tokens over that context. 1517 Having both peers contribute to the context_id assures each peer of 1518 freshness and therefore precludes replay attacks between contexts 1519 (where a token from an old context between two peers is maliciously 1520 injected into a new context between the same or different peers). 1521 Such assurance is not available to the target in the case of 1522 unilateral authentication using SPKM-2, simply because it has not 1523 contributed to the freshness of the computed context_id (instead, it 1524 must trust the freshness of the initiator's random number, or reject 1525 the context). The key_src_bind field in SPKM_REQ is required to be 1526 present for the case of SPKM-2 unilateral authentication precisely to 1527 assist the target in trusting the freshness of this token (and its 1528 proposed context key). 1530 7. SECURITY CONSIDERATIONS 1532 Security issues are discussed throughout this memo. 1534 Adams Document Expiration: 25 Nov. 1995 28 1536 8. REFERENCES 1538 [Davi89]: D. W. Davies and W. L. Price, "Security for Computer 1539 Networks", Second Edition, John Wiley and Sons, New York, 1989. 1541 [FIPS-113]: National Bureau of Standards, Federal Information 1542 Processing Standard 113, "Computer Data Authentication", May 1985. 1544 [GSSv2]: J. Linn, "Generic Security Service Application Program 1545 Interface Version 2", Internat Draft: draft-ietf-cat-gssv2-01.txt. 1547 [Juen84]: R. R. Jueneman, C. H. Meyer and S. M. Matyas, Message 1548 Authentication with Manipulation Detection Codes, in Proceedings of 1549 the 1983 IEEE Symposium on Security and Privacy, IEEE Computer 1550 Society Press, 1984, pp.33-54.. 1552 [KRB5]: J. Linn, "The Kerberos Version 5 GSS-API Mechanism", 1553 Internet Draft draft-ietf-cat-kerb5gss-02.txt. 1555 [PKCS1]: RSA Encryption Standard, Version 1.5, RSA Data Security, 1556 Inc., Nov. 1993. 1558 [PKCS3]: Diffie-Hellman Key-Agreement Standard, Version 1.4, RSA 1559 Data Security, Inc., Nov. 1993. 1561 [RFC-1321]: R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321. 1563 [RFC-1422]: S. Kent, "Privacy Enhancement for Internet Electronic 1564 Mail: Part II: Certificate-Based Key Management", RFC 1422. 1566 [RFC-1423]: D. Balenson, "Privacy Enhancement for Internet Elec- 1567 tronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423. 1569 [RFC-1507]: C. Kaufman, "DASS: Distributed Authentication Security 1570 Service", RFC 1507. 1572 [RFC-1508]: J. Linn, "Generic Security Service Application Program 1573 Interface", RFC 1508. 1575 [RFC-1509]: J. Wray, "Generic Security Service Application Program 1576 Interface: C-bindings", RFC 1509. 1578 [RFC-1510]: J. Kohl and C. Neuman, "The Kerberos Network 1579 Authentication Service (V5)", RFC 1510. 1581 [9798]: ISO/IEC 9798-3, "Information technology - Security 1582 Techniques - Entity authentication mechanisms - Part 3: Entitiy 1583 authentication using a public key algorithm", ISO/IEC, 1993. 1585 [X.501]: ISO/IEC 9594-2, "Information Technology - Open Systems 1586 Interconnection - The Directory: Models", CCITT/ITU Recommendation 1587 X.501, 1993. 1589 Adams Document Expiration: 25 Nov. 1995 29 1591 [X.509]: ISO/IEC 9594-8, "Information Technology - Open Systems 1592 Interconnection - The Directory: Authentication Framework", 1593 CCITT/ITU Recommendation X.509, 1993. 1595 [X9.44]: ANSI, "Public Key Cryptography Using Reversible 1596 Algorithms for the Financial Services Industry: Transport of 1597 Symmetric Algorithm Keys Using RSA", X9.44-1993. 1599 9. AUTHOR'S ADDRESS 1601 Carlisle Adams 1602 Bell-Northern Research 1603 P.O.Box 3511, Station C 1604 Ottawa, Ontario, CANADA K1Y 4H7 1606 Phone: +1 613.763.9008 1607 E-mail: cadams@bnr.ca 1609 Adams Document Expiration: 25 Nov. 1995 30 1611 Appendix A: ASN.1 Module Definition 1613 SpkmGssTokens {iso(1) org(3) dod(5) internet(1) security(5) 1614 spkmGssTokens(xx)} 1616 DEFINITIONS ::= 1617 BEGIN 1619 -- EXPORTS ALL -- 1621 IMPORTS 1622 informationFramework, authenticationFramework 1623 FROM UsefulDefinitions {joint-iso-ccitt(2) ds(5) modules(1) 1624 usefulDefinitions(0)} 1626 Name 1627 FROM InformationFramework {joint-iso-ccitt(2) ds(5) modules(1) 1628 informationFramework(1)} 1630 ENCRYPTED, SIGNED, SIGNATURE, Certificate, CertificatePair, 1631 CertificateList, AlgorithmIdentifier 1632 FROM AuthenticationFramework {joint-iso-ccitt(2) ds(5) modules(1) 1633 authenticationFramework(7) 1} ; 1635 -- macros -- 1637 MAC MACRO ::= 1638 BEGIN 1639 TYPE NOTATION ::= type ( ToBeMACed ) 1640 VALUE NOTATION ::= value ( VALUE SEQUENCE { 1641 algId AlgorithmIdentifier, 1642 mac BIT STRING } ) 1643 -- must be the result of applying the MACing procedure specified 1644 -- by algId to the BER-encoded octets of a value of ToBeMACed (the 1645 -- context key is to be used as an input to the MACing procedure) 1646 END 1648 HASHED MACRO ::= 1649 BEGIN 1650 TYPE NOTATION ::= type ( ToBeHashed ) 1651 VALUE NOTATION ::= value ( VALUE OCTET STRING ) 1652 END 1654 -- types -- 1656 SPKM_REQ ::= SEQUENCE { 1657 requestToken REQ_TOKEN, 1658 req_integrity Req_Integrity, 1659 certif_data [2] CertificationData OPTIONAL, 1660 auth_data [3] AuthorizationData OPTIONAL 1661 } 1663 Adams Document Expiration: 25 Nov. 1995 31 1665 Req_Integrity ::= CHOICE { 1666 sig_integ [0] SIGNATURE REQ_TOKEN, 1667 mac_integ [1] MAC REQ_TOKEN 1668 } 1670 CertificationData ::= SEQUENCE { 1671 certificationPath [0] CertificationPath OPTIONAL, 1672 certificateRevocationList [1] CertificateList OPTIONAL 1673 } -- at least one of the above shall be present 1675 CertificationPath ::= SEQUENCE { 1676 userKeyId [0] OCTET STRING OPTIONAL, 1677 userCertif [1] Certificate OPTIONAL, 1678 verifKeyId [2] OCTET STRING OPTIONAL, 1679 userVerifCertif [3] Certificate OPTIONAL, 1680 theCACertificates [4] SEQUENCE OF CertificatePair OPTIONAL 1681 } -- Presence of [2] or [3] implies that [0] or [1] must also be 1682 -- present. Presence of [4] implies that at least one of [0], [1], 1683 -- [2], and [3] must also be present. 1685 REQ_TOKEN ::= SEQUENCE { 1686 tok_id INTEGER, -- shall contain 0100 (hex) 1687 context_id Random_Integer, 1688 pvno BIT STRING, 1689 timestamp UTCTime OPTIONAL, -- mandatory for SPKM-2 1690 randSrc Random_Integer, 1691 targ_name Name, 1692 src_name Name, 1693 req_data Context_Data, 1694 validity [0] Validity OPTIONAL, 1695 key_estb_set [1] Key_Estb_Algs, 1696 key_estb_req BIT STRING OPTIONAL, 1697 key_src_bind HASHED SEQUENCE { 1698 src_name Name, 1699 symm_key BIT STRING } OPTIONAL 1700 -- this field must be present for the case of SPKM-2 1701 -- unilateral authentication if the K-ALG in use does 1702 -- not provide such a binding (but is optional for all 1703 -- other cases) 1704 } 1706 Random_Integer ::= BIT STRING 1708 Context_Data ::= SEQUENCE { 1709 channelId ChannelId, 1710 seq_number INTEGER OPTIONAL, 1711 options Options, 1712 conf_alg Conf_Algs, 1713 intg_alg Intg_Algs 1714 } 1716 Adams Document Expiration: 25 Nov. 1995 32 1718 ChannelId ::= OCTET STRING 1720 Options ::= BIT STRING { 1721 delegation_state (0), 1722 mutual_state (1), 1723 replay_det_state (2), 1724 sequence_state (3), 1725 conf_avail (4), 1726 integ_avail (5), 1727 target_certif_data_required (6) 1728 } 1730 Conf_Algs ::= CHOICE { 1731 SEQUENCE OF AlgorithmIdentifier, 1732 NULL 1733 } 1735 Intg_Algs ::= SEQUENCE OF AlgorithmIdentifier 1737 Key_Estb_Algs ::= SEQUENCE OF AlgorithmIdentifier 1739 SPKM_REP_TI ::= SEQUENCE { 1740 responseToken REP_TOKEN, 1741 certif_data CertificationData OPTIONAL 1742 -- present if target_certif_data_required option was 1743 } -- set to TRUE in SPKM_REQ 1745 REP_TOKEN ::= SIGNED SEQUENCE { 1746 tok_id INTEGER, -- shall contain 0200 (hex) 1747 context_id Random_Integer, 1748 pvno [0] BIT STRING OPTIONAL, 1749 timestamp [1] UTCTime OPTIONAL, -- mandatory for SPKM-2 1750 randTarg [2] Random_Integer, 1751 src_name Name, 1752 targ_name Name, 1753 randSrc Random_Integer, 1754 rep_data Context_Data, 1755 validity [3] Validity OPTIONAL, 1756 key_estb_id [4] AlgorithmIdentifier OPTIONAL, 1757 key_estb_str BIT STRING OPTIONAL 1758 } 1760 SPKM_REP_IT ::= SIGNED SEQUENCE { 1761 tok_id INTEGER, -- shall contain 0300 (hex) 1762 context_id Random_Integer, 1763 randSrc Random_Integer, 1764 randTarg Random_Integer, 1765 targ_name Name, 1766 src_name Name, 1767 key_estb_rep BIT STRING OPTIONAL 1768 } 1770 SPKM_ERROR ::= SIGNED SEQUENCE { 1771 tok_id INTEGER, -- shall contain 0400 (hex) 1772 context_id Random_Integer 1773 } 1775 Adams Document Expiration: 25 Nov. 1995 33 1777 SPKM_MIC ::= SEQUENCE { 1778 mic_header Mic_Header, 1779 int_cksum BIT STRING 1780 } 1782 Mic_Header ::= SEQUENCE { 1783 tok_id INTEGER, -- shall contain 0101 (hex) 1784 context_id Random_Integer, 1785 int_alg [0] AlgorithmIdentifier OPTIONAL, 1786 snd_seq [1] SeqNum OPTIONAL 1787 } 1789 SeqNum ::= SEQUENCE { 1790 num INTEGER, 1791 dir_ind BOOLEAN 1792 } 1794 SPKM_WRAP ::= SEQUENCE { 1795 wrap_header Wrap_Header, 1796 wrap_body Wrap_Body 1797 } 1799 Wrap_Header ::= SEQUENCE { 1800 tok_id INTEGER, -- shall contain 0201 (hex) 1801 context_id Random_Integer, 1802 int_alg [0] AlgorithmIdentifier OPTIONAL, 1803 conf_alg [1] Conf_Alg OPTIONAL, 1804 snd_seq [2] SeqNum OPTIONAL 1805 } 1807 Wrap_Body ::= SEQUENCE { 1808 int_cksum BIT STRING, 1809 data BIT STRING 1810 } 1812 Conf_Alg ::= CHOICE { 1813 AlgorithmIdentifier, 1814 NULL 1815 } 1817 SPKM_DEL ::= SEQUENCE { 1818 del_header Del_Header, 1819 int_cksum BIT STRING 1820 } 1822 Del_Header ::= SEQUENCE { 1823 tok_id INTEGER, -- shall contain 0301 (hex) 1824 context_id Random_Integer, 1825 int_alg [0] AlgorithmIdentifier OPTIONAL, 1826 snd_seq [1] SeqNum OPTIONAL 1827 } 1829 Adams Document Expiration: 25 Nov. 1995 34 1831 -- other types -- 1833 -- from [RFC-1508] -- 1835 MechType ::= OBJECT IDENTIFIER 1837 InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE { 1838 thisMech MechType, 1839 innerContextToken ANY DEFINED BY thisMech 1840 -- contents mechanism-specific 1841 } 1843 --from [PKCS3] (the parameter to be used with dhKeyAgreement) -- 1845 DHParameter ::= SEQUENCE { 1846 prime INTEGER, -- p 1847 base INTEGER, -- g 1848 privateValueLength INTEGER OPTIONAL 1849 } 1851 -- from [RFC-1510] -- 1853 AuthorizationData ::= SEQUENCE OF SEQUENCE { 1854 ad-type INTEGER, 1855 ad-data OCTET STRING 1856 } 1858 -- object identifier assignments -- 1860 md5-DES-CBC OBJECT IDENTIFIER ::= 1861 {iso(1) identified-organization(3) xx} 1863 sum64-DES-CBC OBJECT IDENTIFIER ::= 1864 {iso(1) identified-organization(3) xx} 1866 SPKM-1 OBJECT IDENTIFIER ::= 1867 {iso(1) org(3) dod(5) internet(1) security(5) SPKM-1(xx)} 1869 SPKM-2 OBJECT IDENTIFIER ::= 1870 {iso(1) org(3) dod(5) internet(1) security(5) SPKM-2(xx)} 1872 END 1874 Adams Document Expiration: 25 Nov. 1995 35 1876 Appendix B: Imported Types 1878 This appendix contains, for completeness, the relevant ASN.1 types 1879 imported from InformationFramework and AuthenticationFramework. 1881 AttributeType ::= OBJECT IDENTIFIER 1882 AttributeValue ::= ANY 1883 AttributeValueAssertion ::= SEQUENCE {AttributeType,AttributeValue} 1885 RelativeDistinguishedName ::= SET OF AttributeValueAssertion 1886 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 1887 DistinguishedName ::= RDNSequence 1889 Name ::= CHOICE { --only one for now 1890 DistinguishedName 1891 } 1893 ENCRYPTED MACRO ::= 1894 BEGIN 1895 TYPE NOTATION ::= type(ToBeEnciphered) 1896 VALUE NOTATION ::= value(VALUE BIT STRING) 1897 END -- of ENCRYPTED 1899 SIGNED MACRO ::= 1900 BEGIN 1901 TYPE NOTATION ::= type (ToBeSigned) 1902 VALUE NOTATION ::= value (VALUE 1903 SEQUENCE{ 1904 ToBeSigned, 1905 AlgorithmIdentifier, --of the algorithm used to 1906 --generate the signature 1907 ENCRYPTED OCTET STRING --where the octet string is the 1908 --result of the hashing of the 1909 --value of "ToBeSigned" 1910 } 1911 ) 1912 END -- of SIGNED 1914 SIGNATURE MACRO ::= 1915 BEGIN 1916 TYPE NOTATION ::= type (OfSignature) 1917 VALUE NOTATION ::= value (VALUE 1918 SEQUENCE { 1919 AlgorithmIdentifier, -- of the algorithm used to compute 1920 ENCRYPTED OCTET STRING -- the signature where the octet 1921 -- string is a function (e.g., a 1922 -- compressed or hashed version) 1923 -- of the value 'OfSignature', 1924 -- which may include the 1925 -- identifier of the algorithm 1926 -- used to compute the signature 1927 } 1928 ) 1929 END -- of SIGNATURE 1931 Adams Document Expiration: 25 Nov. 1995 36 1933 Certificate ::= SIGNED SEQUENCE { 1934 version [0] Version DEFAULT v1, 1935 serialNumber [1] CertificateSerialNumber, 1936 signature [2] AlgorithmIdentifier, 1937 issuer [3] Name, 1938 validity [4] Validity, 1939 subject [5] Name, 1940 subjectPublicKeyInfo [6] SubjectPublicKeyInfo, 1941 issuerUID [7] IMPLICIT UID OPTIONAL, -- used in v2 only 1942 subjectUID [8] IMPLICIT UID OPTIONAL -- used in v2 only 1943 } 1945 Version ::= INTEGER {v1(0), v2(1)} 1947 CertificateSerialNumber ::= INTEGER 1949 AlgorithmIdentifier ::= SEQUENCE { 1950 algorithm OBJECT IDENTIFIER, 1951 parameter ANY DEFINED BY algorithm OPTIONAL 1952 } 1954 Validity ::= SEQUENCE { 1955 NotBefore UTCTime, 1956 NotAfter UTCTime 1957 } 1959 SubjectPublicKeyInfo ::= SEQUENCE { 1960 algorithm AlgorithmIdentifier, 1961 subjectPublicKey BIT STRING 1962 } 1964 UID ::= BIT STRING 1966 CertificatePair ::= SEQUENCE { 1967 forward [0] Certificate OPTIONAL, 1968 reverse [1] Certificate OPTIONAL 1969 } -- at least one of the pair shall be present 1971 CertificateList ::= SIGNED SEQUENCE { 1972 signature [0] AlgorithmIdentifier, 1973 issuer [1] Name, 1974 thisUpdate [2] UTCTime, 1975 nextUpdate [3] UTCTime OPTIONAL, 1976 revokedCertificates [4] SEQUENCE OF SEQUENCE { 1977 userCertificate CertificateSerialNumber, 1978 revocationDate UTCTime 1979 } OPTIONAL 1980 } 1982 Adams Document Expiration: 25 Nov. 1995 37