idnits 2.17.1 draft-ietf-cat-spkmgss-06.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-19) 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 2417 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-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 161: '...in algorithms as RECOMMENDED (that is,...' RFC 2119 keyword, line 253: '... This algorithm is RECOMMENDED....' RFC 2119 keyword, line 560: '... certif-data [0] CertificationData OPTIONAL,...' RFC 2119 keyword, line 561: '... auth-data [1] AuthorizationData OPTIONAL...' RFC 2119 keyword, line 566: '... certificationPath [0] CertificationPath OPTIONAL,...' (70 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- 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: 'PKCS-1' is mentioned on line 328, but not defined == Missing Reference: 'APPLICATION 0' is mentioned on line 2011, but not defined == Missing Reference: '0' is mentioned on line 2111, but not defined == Missing Reference: '1' is mentioned on line 2112, but not defined == Missing Reference: '2' is mentioned on line 2091, but not defined == Missing Reference: '3' is mentioned on line 2020, but not defined == Missing Reference: '4' is mentioned on line 2021, but not defined == Missing Reference: '5' is mentioned on line 2022, but not defined == Missing Reference: '6' is mentioned on line 2023, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'Davi89' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-113' -- No information found for draft-ietf-cat-gssv2-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'GSSv2' -- Possible downref: Non-RFC (?) normative reference: ref. 'Juen84' -- No information found for draft-ietf-cat-kerb5gss-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'KRB5' -- 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 ** 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: 16 errors (**), 0 flaws (~~), 12 warnings (==), 13 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-06.txt Jan. 19, 1996 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. The mechanism 41 described in this document has been proposed to meet this need and to 42 provide the following features. 44 1) The SPKM allows both unilateral and mutual authentication 45 to be accomplished without the use of secure timestamps. This 46 enables environments which do not have access to secure time 47 to nevertheless have access to secure authentication. 49 Adams Document Expiration: 19 July 1996 1 51 2) The SPKM uses Algorithm Identifiers to specify various 52 algorithms to be used by the communicating peers. This allows 53 maximum flexibility for a variety of environments, for future 54 enhancements, and for alternative algorithms. 56 3) The SPKM allows the option of a true, asymmetric algorithm- 57 based, digital signature in the gss_sign() and gss_seal() 58 operations (now called gss_getMIC() and gss_wrap() in 59 [GSSv2]), rather than an integrity checksum based on a MAC 60 computed with a symmetric algorithm (e.g., DES). For some 61 environments, the availability of true digital signatures 62 supporting non-repudiation is a necessity. 64 4) SPKM data formats and procedures are designed to be as similar 65 to those of the Kerberos mechanism as is practical. This is 66 done for ease of implementation in those environments where 67 Kerberos has already been implemented. 69 For the above reasons, it is felt that the SPKM will offer 70 flexibility and functionality, without undue complexity or overhead. 72 KEY MANAGEMENT 74 The key management employed in SPKM is intended to be as compatible 75 as possible with both X.509 [X.509] and PEM [RFC-1422], since these 76 represent large communities of interest and show relative maturity in 77 standards. 79 ACKNOWLEDGMENTS 81 Much of the material in this document is based on the Kerberos 82 Version 5 GSS-API mechanism [KRB5], and is intended to be as 83 compatible with it as possible. This document also owes a great debt 84 to Warwick Ford and Paul Van Oorschot of Bell-Northern Research for 85 many fruitful discussions, to Kelvin Desplanque for implementation- 86 related clarifications, to John Linn of OpenVision Technologies for 87 helpful comments, and to Bancroft Scott of OSS for ASN.1 assistance. 89 Adams Document Expiration: 19 July 1996 2 91 1. OVERVIEW 93 The goal of the Generic Security Service Application Program 94 Interface (GSS-API) is stated in the abstract of [RFC-1508] as 95 follows: 97 "This Generic Security Service Application Program Interface (GSS- 98 API) definition provides security services to callers in a generic 99 fashion, supportable with a range of underlying mechanisms and 100 technologies and hence allowing source-level portability of 101 applications to different environments. This specification defines 102 GSS-API services and primitives at a level independent of 103 underlying mechanism and programming language environment, and is 104 to be complemented by other, related specifications: 106 - documents defining specific parameter bindings for particular 107 language environments; 109 - documents defining token formats, protocols, and procedures to 110 be implemented in order to realize GSS-API services atop 111 particular security mechanisms." 113 The SPKM is an instance of the latter type of document and is 114 therefore termed a "GSS-API Mechanism". This mechanism provides 115 authentication, key establishment, data integrity, and data 116 confidentiality in an on-line distributed application environment 117 using a public-key infrastructure. Because it conforms to the 118 interface defined by [RFC-1508], SPKM can be used as a drop-in 119 replacement by any application which makes use of security services 120 through GSS-API calls (for example, any application which already 121 uses the Kerberos GSS-API for security). The use of a public-key 122 infrastructure allows digital signatures supporting non-repudiation 123 to be employed for message exchanges, and provides other benefits 124 such as scalability to large user populations. 126 The tokens defined in SPKM are intended to be used by application 127 programs according to the GSS API "operational paradigm" (see 128 [RFC-1508] for further details): 130 The operational paradigm in which GSS-API operates is as follows. 131 A typical GSS-API caller is itself a communications protocol [or 132 is an application program which uses a communications protocol], 133 calling on GSS-API in order to protect its communications with 134 authentication, integrity, and/or confidentiality security 135 services. A GSS-API caller accepts tokens provided to it by its 136 local GSS-API implementation [i.e., its GSS-API mechanism] and 137 transfers the tokens to a peer on a remote system; that peer 138 passes the received tokens to its local GSS-API implementation for 139 processing. 141 This document defines two separate GSS-API mechanisms, SPKM-1 and 142 SPKM-2, whose primary difference is that SPKM-2 requires the presence 143 of secure timestamps for the purpose of replay detection during 144 context establishment and SPKM-1 does not. This allows greater 145 flexibility for applications since secure timestamps cannot always 146 be guaranteed to be available in a given environment. 148 Adams Document Expiration: 19 July 1996 3 150 2. ALGORITHMS 152 A number of algorithm types are employed in SPKM. Each type, along 153 with its purpose and a set of specific examples, is described in this 154 section. In order to ensure at least a minimum level of interoper- 155 ability among various implementations of SPKM, one of the integrity 156 algorithms is specified as MANDATORY; all remaining examples (and 157 any other algorithms) may optionally be supported by a given SPKM 158 implementation (note that a GSS-conformant mechanism need not support 159 confidentiality). Making a confidentiality algorithm mandatory may 160 preclude exportability of the mechanism implementation; this document 161 therefore specifies certain algorithms as RECOMMENDED (that is, 162 interoperability will be enhanced if these algorithms are included in 163 all SPKM implementations for which exportability is not a concern). 165 2.1 Integrity Algorithm (I-ALG): 167 Purpose: 169 This algorithm is used to ensure that a message has not been 170 altered in any way after being constructed by the legitimate 171 sender. Depending on the algorithm used, the application of 172 this algorithm may also provide authenticity and support non- 173 repudiation for the message. 175 Examples: 177 md5WithRSAEncryption OBJECT IDENTIFIER ::= { 178 iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 179 pkcs-1(1) 4 -- imported from [PKCS1] 180 } 182 This algorithm (MANDATORY) provides data integrity and 183 authenticity and supports non-repudiation by computing an 184 RSA signature on the MD5 hash of that data. This is 185 essentially equivalent to md5WithRSA {1 3 14 3 2 3}, 186 which is defined by OIW (the Open Systems Environment 187 Implementors' Workshop). 189 Note that since this is the only integrity/authenticity 190 algorithm specified to be mandatory at this time, for 191 interoperability reasons it is also stipulated that 192 md5WithRSA be the algorithm used to sign all context 193 establishment tokens which are signed rather than MACed -- 194 see Section 3.1.1 for details. In future versions of this 195 document, alternate or additional algorithms may be 196 specified to be mandatory and so this stipulation on the 197 context establishment tokens may be removed. 199 Adams Document Expiration: 19 July 1996 4 201 DES-MAC OBJECT IDENTIFIER ::= { 202 iso(1) identified-organization(3) oiw(14) secsig(3) 203 algorithm(2) 10 -- carries length in bits of the MAC as 204 } -- an INTEGER parameter, constrained to 205 -- multiples of eight from 16 to 64 207 This algorithm (RECOMMENDED) provides integrity by computing 208 a DES MAC (as specified by [FIPS-113]) on that data. 210 md5-DES-CBC OBJECT IDENTIFIER ::= { 211 iso(1) identified-organization(3) dod(6) internet(1) 212 security(5) integrity(3) md5-DES-CBC(1) 213 } 215 This algorithm provides data integrity by encrypting, using 216 DES CBC, the "confounded" MD5 hash of that data (see Section 217 3.2.2.1 for the definition and purpose of confounding). 218 This will typically be faster in practice than computing a 219 DES MAC unless the input data is extremely short (e.g., a 220 few bytes). Note that without the confounder the strength 221 of this integrity mechanism is (at most) equal to the 222 strength of DES under a known-plaintext attack. 224 sum64-DES-CBC OBJECT IDENTIFIER ::= { 225 iso(1) identified-organization(3) dod(6) internet(1) 226 security(5) integrity(3) sum64-DES-CBC(2) 227 } 229 This algorithm provides data integrity by encrypting, using 230 DES CBC, the concatenation of the confounded data and the 231 sum of all the input data blocks (the sum computed using 232 addition modulo 2**64 - 1). Thus, in this algorithm, 233 encryption is a requirement for the integrity to be secure. 235 For comments regarding the security of this integrity 236 algorithm, see [Juen84, Davi89]. 238 2.2 Confidentiality Algorithm (C-ALG): 240 Purpose: 242 This symmetric algorithm is used to generate the encrypted 243 data for gss_seal() / gss_wrap(). 245 Example: 247 DES-CBC OBJECT IDENTIFIER ::= { 248 iso(1) identified-organization(3) oiw(14) secsig(3) 249 algorithm(2) 7 -- carries IV (OCTET STRING) as a parameter; 250 } -- this (optional) parameter is unused in 251 -- SPKM due to the use of confounding 253 This algorithm is RECOMMENDED. 255 Adams Document Expiration: 19 July 1996 5 257 2.3 Key Establishment Algorithm (K-ALG): 259 Purpose: 261 This algorithm is used to establish a symmetric key for use 262 by both the initiator and the target over the established 263 context. The keys used for C-ALG and any keyed I-ALGs (for 264 example, DES-MAC) are derived from this context key. As will 265 be seen in Section 3.1, key establishment is done within the 266 X.509 authentication exchange and so the resulting shared 267 symmetric key is authenticated. 269 Examples: 271 RSAEncryption OBJECT IDENTIFIER ::= { 272 iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 273 pkcs-1(1) 1 -- imported from [PKCS1] and [RFC-1423] 274 } 276 In this algorithm (MANDATORY), the context key is generated 277 by the initiator, encrypted with the RSA public key of the 278 target, and sent to the target. The target need not respond 279 to the initiator for the key to be established. 281 id-rsa-key-transport OBJECT IDENTIFIER ::= { 282 iso(1) identified-organization(3) oiw(14) secsig(3) 283 algorithm(2) 22 -- imported from [X9.44] 284 } 286 Similar to RSAEncryption, but source authenticating info. 287 is also encrypted with the target's RSA public key. 289 dhKeyAgreement OBJECT IDENTIFIER ::= { 290 iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 291 pkcs-3(3) 1 292 } 294 In this algorithm, the context key is generated jointly by 295 the initiator and the target using the Diffie-Hellman key 296 establishment algorithm. The target must therefore respond 297 to the initiator for the key to be established (so this 298 K-ALG cannot be used with unilateral authentication in 299 SPKM-2 (see Section 3.1)). 301 Adams Document Expiration: 19 July 1996 6 303 2.4 One-Way Function (O-ALG) for Subkey Derivation Algorithm: 305 Purpose: 307 Having established a context key using the negotiated K-ALG, 308 both initiator and target must be able to derive a set of 309 subkeys for the various C-ALGs and keyed I-ALGs supported over 310 the context. Let the (ordered) list of agreed C-ALGs be 311 numbered consecutively, so that the first algorithm (the 312 "default") is numbered "0", the next is numbered "1", and so 313 on. Let the numbering for the (ordered) list of agreed I-ALGs 314 be identical. Finally, let the context key be a binary string 315 of arbitrary length "M", subject to the following constraint: 316 L <= M <= U (where the lower limit "L" is the bit length of 317 the longest key needed by any agreed C-ALG or keyed I-ALG, and 318 the upper limit "U" is the largest bit size which will fit 319 within the K-ALG parameters). 321 For example, if DES and two-key-triple-DES are the negotiated 322 confidentiality algorithms and DES-MAC is the negotiated keyed 323 integrity algorithm (note that digital signatures do not use a 324 context key), then the context key must be at least 112 bits 325 long. If 512-bit RSAEncryption is the K-ALG in use then the 326 originator can randomly generate a context key of any greater 327 length up to 424 bits (the longest allowable RSA input 328 specified in [PKCS-1]) -- the target can determine the length 329 which was chosen by removing the padding bytes during the RSA 330 decryption operation. On the other hand, if dhKeyAgreement is 331 the K-ALG in use then the context key is the result of the 332 Diffie-Hellman computation (with the exception of the high- 333 order byte, which is discarded for security reasons), so that 334 its length is that of the Diffie-Hellman modulus, p, minus 8 335 bits. 337 The derivation algorithm for a k-bit subkey is specified as 338 follows: 340 rightmost_k_bits (OWF(context_key || x || n || s || context_key)) 342 where 344 - "x" is the ASCII character "C" (0x43) if the subkey is 345 for a confidentiality algorithm or the ASCII character "I" 346 (0x49) if the subkey is for a keyed integrity algorithm; 347 - "n" is the number of the algorithm in the appropriate agreed 348 list for the context (the ASCII character "0" (0x30), "1" 349 (0x31), and so on); 350 - "s" is the "stage" of processing -- always the ASCII 351 character "0" (0x30), unless "k" is greater than the output 352 size of OWF, in which case the OWF is computed repeatedly 353 with increasing ASCII values of "stage" (each OWF output 354 being concatenated to the end of previous OWF outputs), 355 until "k" bits have been generated; 356 - "||" is the concatenation operation; and 357 - "OWF" is any appropriate One-Way Function. 359 Adams Document Expiration: 19 July 1996 7 361 Examples: 363 MD5 OBJECT IDENTIFIER ::= { 364 iso(1) member-body(2) US(840) rsadsi(113549) 365 digestAlgorithm(2) 5 366 } 368 This algorithm is MANDATORY. 370 SHA OBJECT IDENTIFIER ::= { 371 iso(1) identified-organization(3) oiw(14) secsig(3) 372 algorithm(2) 18 373 } 375 It is recognized that existing hash functions may not satisfy 376 all required properties of OWFs. This is the reason for 377 allowing negotiation of the O-ALG OWF during the context 378 establishment process (see Section 2.5), since in this way 379 future improvements in OWF design can easily be accommodated. 380 For example, in some environments a preferred OWF technique 381 might be an encryption algorithm which encrypts the input 382 specified above using the context_key as the encryption key. 384 2.5 Negotiation: 386 During context establishment in SPKM, the initiator offers a set of 387 possible confidentiality algorithms and a set of possible integrity 388 algorithms to the target (note that the term "integrity algorithms" 389 includes digital signature algorithms). The confidentiality 390 algorithms selected by the target become ones that may be used for 391 C-ALG over the established context, and the integrity algorithms 392 selected by the target become ones that may be used for I-ALG over 393 the established context (the target "selects" algorithms by 394 returning, in the same relative order, the subset of each offered 395 list that it supports). Note that any C-ALG and I-ALG may be used 396 for any message over the context and that the first confidentiality 397 algorithm and the first integrity algorithm in the agreed sets become 398 the default algorithms for that context. 400 The agreed confidentiality and integrity algorithms for a specific 401 context define the valid values of the Quality of Protection (QOP) 402 parameter used in the gss_getMIC() and gss_wrap() calls -- see 403 Section 5.2 for further details. If no response is expected from the 404 target (unilateral authentication in SPKM-2) then the algorithms 405 offered by the initiator are the ones that may be used over the 406 context (if this is unacceptable to the target then a delete token 407 must be sent to the initiator so that the context is never 408 established). 410 Adams Document Expiration: 19 July 1996 8 412 Furthermore, in the first context establishment token the initiator 413 offers a set of possible K-ALGs, along with the key (or key half) 414 corresponding to the first algorithm in the set (its preferred 415 algorithm). If this K-ALG is unacceptable to the target then the 416 target must choose one of the other K-ALGs in the set and send this 417 choice along with the key (or key half) corresponding to this choice 418 in its response (otherwise a delete token must be sent so that the 419 context is never established). If necessary (that is, if the target 420 chooses a 2-pass K-ALG such as dhKeyAgreement), the initiator will 421 send its key half in a response to the target. 423 Finally, in the first context establishment token the initiator 424 offers a set of possible O-ALGs (only a single O-ALG if no response 425 is expected). The (single) O-ALG chosen by the target becomes the 426 subkey derivation algorithm OWF to be used over the context. 428 In future versions of SPKM, other algorithms may be specified for any 429 or all of I-ALG, C-ALG, K-ALG, and O-ALG. 431 3. TOKEN FORMATS 433 This section discusses protocol-visible characteristics of the SPKM; 434 it defines elements of protocol for interoperability and is 435 independent of language bindings per [RFC-1509]. 437 The SPKM GSS-API mechanism will be identified by an Object Identifier 438 representing "SPKM-1" or "SPKM-2", having the value {spkm spkm-1(1)} 439 or {spkm spkm-2(2)}, where spkm has the value 440 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 441 mechanisms(5) spkm(1)}. SPKM-1 uses random numbers for replay 442 detection during context establishment and SPKM-2 uses timestamps 443 (note that for both mechanisms, sequence numbers are used to provide 444 replay and out-of-sequence detection during the context, if this has 445 been requested by the application). 447 Tokens transferred between GSS-API peers (for security context 448 management and per-message protection purposes) are defined. 450 3.1. Context Establishment Tokens 452 Three classes of tokens are defined in this section: "Initiator" 453 tokens, emitted by calls to gss_init_sec_context() and consumed by 454 calls to gss_accept_sec_context(); "Target" tokens, emitted by calls 455 to gss_accept_sec_context() and consumed by calls to 456 gss_init_sec_context(); and "Error" tokens, potentially emitted by 457 calls to gss_init_sec_context() or gss_accept_sec_context(), and 458 potentially consumed by calls to gss_init_sec_context() or 459 gss_accept_sec_context(). 461 Per RFC-1508, Appendix B, the initial context establishment token 462 will be enclosed within framing as follows: 464 Adams Document Expiration: 19 July 1996 9 466 InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE { 467 thisMech MechType, 468 -- MechType is OBJECT IDENTIFIER 469 -- representing "SPKM-1" or "SPKM-2" 470 innerContextToken ANY DEFINED BY thisMech 471 } -- contents mechanism-specific 473 When thisMech is SPKM-1 or SPKM-2, innerContextToken is defined as 474 follows: 476 SPKMInnerContextToken ::= CHOICE { 477 req [0] SPKM-REQ, 478 rep-ti [1] SPKM-REP-TI, 479 rep-it [2] SPKM-REP-IT, 480 error [3] SPKM-ERROR, 481 mic [4] SPKM-MIC, 482 wrap [5] SPKM-WRAP, 483 del [6] SPKM-DEL 484 } 486 The above GSS-API framing shall be applied to all tokens emitted by 487 the SPKM GSS-API mechanism, including SPKM-REP-TI (the response from 488 the Target to the Initiator), SPKM-REP-IT (the response from the 489 Initiator to the Target), SPKM-ERROR, context-deletion, and 490 per-message tokens, not just to the initial token in a context 491 establishment exchange. While not required by RFC-1508, this enables 492 implementations to perform enhanced error-checking. The tag values 493 provided in SPKMInnerContextToken ("[0]" through "[6]") specify a 494 token-id for each token; similar information is contained in each 495 token's tok-id field. While seemingly redundant, the tag value and 496 tok-id actually perform different tasks: the tag ensures that 497 InitialContextToken can be properly decoded; tok-id ensures, among 498 other things, that data associated with the per-message tokens is 499 cryptographically linked to the intended token type. Every 500 innerContextToken also includes a context-id field; see Section 6 for 501 a discussion of both token-id and context-id information and their 502 use in an SPKM support function). 504 The innerContextToken field of context establishment tokens for the 505 SPKM GSS-API mechanism will contain one of the following messages: 506 SPKM-REQ; SPKM-REP-TI; SPKM-REP-IT; and SPKM-ERROR. Furthermore, all 507 innerContextTokens are encoded using ASN.1 BER (constrained, in the 508 interests of parsing simplicity, to the DER subset defined in 509 [X.509], clause 8.7). 511 The SPKM context establishment tokens are defined according to 512 [X.509] Section 10 and are compatible with [9798]. SPKM-1 (random 513 numbers) uses Section 10.3, "Two-way Authentication", when 514 performing unilateral authentication of the target to the initiator 515 and uses Section 10.4, "Three-way Authentication", when mutual 516 authentication is requested by the initiator. SPKM-2 (timestamps) 517 uses Section 10.2, "One-way Authentication", when performing 518 unilateral authentication of the initiator to the target and uses 519 Section 10.3, "Two-way Authentication", when mutual authentication is 520 requested by the initiator. 522 Adams Document Expiration: 19 July 1996 10 524 The implication of the previous paragraph is that for SPKM-2 525 unilateral authentication no negotiation of K-ALG can be done (the 526 target either accepts the K-ALG and context key given by the 527 initiator or disallows the context). For SPKM-2 mutual or SPKM-1 528 unilateral authentication some negotiation is possible, but the 529 target can only choose among the one-pass K-ALGs offered by the 530 initiator (or disallow the context). Alternatively, the initiator 531 can request that the target generate and transmit the context key. 532 For SPKM-1 mutual authentication the target can choose any one- or 533 two-pass K-ALG offered by the initiator and, again, can be requested 534 to generate and transmit the context key. 536 It is envisioned that typical use of SPKM-1 or SPKM-2 will involve 537 mutual authentication. Although unilateral authentication is avail- 538 able for both mechanisms, its use is not generally recommended. 540 3.1.1. Context Establishment Tokens - Initiator (first token) 542 In order to accomplish context establishment, it may be necessary 543 that both the initiator and the target have access to the other 544 partys public-key certificate(s). In some environments the 545 initiator may choose to acquire all certificates and send the 546 relevant ones to the target in the first token. In other environ- 547 ments the initiator may request that the target send certificate data 548 in its response token, or each side may individually obtain the 549 certificate data it needs. In any case, however, the SPKM 550 implementation must have the ability to obtain certificates which 551 correspond to a supplied Name. The actual mechanism to be used to 552 achieve this is a local implementation matter and is therefore 553 outside the scope of this specification. 555 Relevant SPKM-REQ syntax is as follows (note that imports from other 556 documents are given in Appendix A): 558 SPKM-REQ ::= SEQUENCE { 559 requestToken REQ-TOKEN, 560 certif-data [0] CertificationData OPTIONAL, 561 auth-data [1] AuthorizationData OPTIONAL 562 -- see [RFC-1510] for a discussion of auth-data 563 } 565 CertificationData ::= SEQUENCE { 566 certificationPath [0] CertificationPath OPTIONAL, 567 certificateRevocationList [1] CertificateList OPTIONAL 568 } -- at least one of the above shall be present 570 Adams Document Expiration: 19 July 1996 11 572 CertificationPath ::= SEQUENCE { 573 userKeyId [0] OCTET STRING OPTIONAL, 574 -- identifier for user's public key 575 userCertif [1] Certificate OPTIONAL, 576 -- certificate containing user's public key 577 verifKeyId [2] OCTET STRING OPTIONAL, 578 -- identifier for user's public verification key 579 userVerifCertif [3] Certificate OPTIONAL, 580 -- certificate containing user's public verification key 581 theCACertificates [4] SEQUENCE OF CertificatePair OPTIONAL 582 } -- certification path from target to source 584 Having separate verification fields allows different key pairs 585 (possibly corresponding to different algorithms) to be used for 586 encryption/decryption and signing/verification. Presence of [0] or 587 [1] and absence of [2] and [3] implies that the same key pair is to 588 be used for enc/dec and verif/signing (note that this practice is not 589 typically recommended). Presence of [2] or [3] implies that a 590 separate key pair is to be used for verif/signing, and so [0] or [1] 591 must also be present. Presence of [4] implies that at least one of 592 [0], [1], [2], and [3] must also be present. 594 REQ-TOKEN ::= SEQUENCE { 595 req-contents Req-contents, 596 algId AlgorithmIdentifier, 597 req-integrity Integrity -- "token" is Req-contents 598 } 600 Integrity ::= BIT STRING 601 -- If corresponding algId specifies a signing algorithm, 602 -- "Integrity" holds the result of applying the signing procedure 603 -- specified in algId to the BER-encoded octet string which results 604 -- from applying the hashing procedure (also specified in algId) to 605 -- the DER-encoded octets of "token". 606 -- Alternatively, if corresponding algId specifies a MACing 607 -- algorithm, "Integrity" holds the result of applying the MACing 608 -- procedure specified in algId to the DER-encoded octets of 609 -- "token" (note that for MAC, algId must be one of the integrity 610 -- algorithms offered by the initiator with the appropriate subkey 611 -- derived from the context key (see Section 2.4) used as the key 612 -- input) 614 It is envisioned that typical use of the Integrity field for each of 615 REQ-TOKEN, REP-TI-TOKEN, and REP-IT-TOKEN will be a true digital 616 signature, providing unilateral or mutual authentication along with 617 replay protection, as required. However, there are situations in 618 which the MAC choice will be appropriate. One example is the case in 619 which the initiator wishes to remain anonymous (so that the first, or 620 first and third, token(s) will be MACed and the second token will be 621 signed). Another example is the case in which a previously authenti- 622 cated, established, and cached context is being re-established at 623 some later time (here all exchanged tokens will be MACed). 625 Adams Document Expiration: 19 July 1996 12 627 The primary advantage of the MAC choice is that it reduces processing 628 overhead for cases in which either authentication is not required 629 (e.g., anonymity) or authentication is established by some other 630 means (e.g., ability to form the correct MAC on a "fresh" token in 631 context re-establishment). 633 Req-contents ::= SEQUENCE { 634 tok-id INTEGER (256), -- shall contain 0100(hex) 635 context-id Random-Integer, -- see Section 6.3 636 pvno BIT STRING, -- protocol version number 637 timestamp UTCTime OPTIONAL, -- mandatory for SPKM-2 638 randSrc Random-Integer, 639 targ-name Name, 640 src-name [0] Name OPTIONAL, 641 -- must be supplied unless originator is "anonymous" 642 req-data Context-Data, 643 validity [1] Validity OPTIONAL, 644 -- validity interval for key (may be used in the 645 -- computation of security context lifetime) 646 key-estb-set Key-Estb-Algs, 647 -- specifies set of key establishment algorithms 648 key-estb-req BIT STRING OPTIONAL, 649 -- key estb. parameter corresponding to first K-ALG in set 650 -- (not used if initiator is unable or unwilling to 651 -- generate and securely transmit key material to target). 652 -- Established key must satisfy the key length constraints 653 -- specified in Section 2.4. 654 key-src-bind OCTET STRING OPTIONAL 655 -- Used to bind the source name to the symmetric key. 656 -- This field must be present for the case of SPKM-2 657 -- unilateral authen. if the K-ALG in use does not provide 658 -- such a binding (but is optional for all other cases). 659 -- The octet string holds the result of applying the 660 -- mandatory hashing procedure MD5 (in MANDATORY I-ALG; 661 -- see Section 2.1) as follows: MD5(src || context_key), 662 -- where "src" is the DER-encoded octets of src-name, 663 -- "context-key" is the symmetric key (i.e., the 664 -- unprotected version of what is transmitted in 665 -- key-estb-req), and "||" is the concatenation operation. 666 } 668 -- The protocol version number (pvno) parameter is a BIT STRING which 669 -- uses as many bits as necessary to specify all the SPKM protocol 670 -- versions supported by the initiator (one bit per protocol 671 -- version). The protocol specified by this document is version 0. 672 -- Bit 0 of pvno is therefore set if this version is supported; 673 -- similarly, bit 1 is set if version 1 (if defined in the future) is 674 -- supported, and so on. Note that for unilateral authentication 675 -- using SPKM-2, no response token is expected during context 676 -- establishment, so no protocol negotiation can take place; in this 677 -- case, the initiator must set exactly one bit of pvno. The version 678 -- of REQ-TOKEN must correspond to the highest bit set in pvno. 680 Adams Document Expiration: 19 July 1996 13 682 -- The "validity" parameter above is the only way within SPKM for 683 -- the initiator to transmit desired context lifetime to the target. 684 -- Since it cannot be guaranteed that the initiator and target have 685 -- synchronized time, the span of time specified by "validity" is to 686 -- be taken as definitive (rather than the actual times given in this 687 -- parameter). 689 Random-Integer ::= BIT STRING 691 -- Each SPKM implementation is responsible for generating a "fresh" 692 -- random number for the purpose of context establishment; that is, 693 -- one which (with high probability) has not been used previously. 694 -- There are no cryptographic requirements on this random number 695 -- (i.e., it need not be unpredictable, it simply needs to be fresh). 697 Context-Data ::= SEQUENCE { 698 channelId ChannelId OPTIONAL, -- channel bindings 699 seq-number INTEGER OPTIONAL, -- sequence number 700 options Options, 701 conf-alg Conf-Algs, -- confidentiality. algs. 702 intg-alg Intg-Algs, -- integrity algorithm 703 owf-alg OWF-Algs -- for subkey derivation 704 } 706 ChannelId ::= OCTET STRING 708 Options ::= BIT STRING { 709 delegation-state (0), 710 mutual-state (1), 711 replay-det-state (2), -- used for replay det. during context 712 sequence-state (3), -- used for sequencing during context 713 conf-avail (4), 714 integ-avail (5), 715 target-certif-data-required (6) 716 -- used to request targ's certif. data 717 } 719 Conf-Algs ::= CHOICE { 720 algs [0] SEQUENCE OF AlgorithmIdentifier, 721 null [1] NULL 722 -- used when conf. is not available over context 723 } -- for C-ALG (see Section 5.2 for discussion of QOP) 725 Intg-Algs ::= SEQUENCE OF AlgorithmIdentifier 726 -- for I-ALG (see Section 5.2 for discussion of QOP) 728 OWF-Algs ::= SEQUENCE OF AlgorithmIdentifier 729 -- Contains exactly one algorithm in REQ-TOKEN for SPKM-2 730 -- unilateral, and contains at least one algorithm otherwise. 731 -- Always contains exactly one algorithm in REP-TOKEN. 733 Key-Estb-Algs ::= SEQUENCE OF AlgorithmIdentifier 734 -- to allow negotiation of K-ALG 736 Adams Document Expiration: 19 July 1996 14 738 A context establishment sequence based on the SPKM will perform 739 unilateral authentication if the mutual-req bit is not set in the 740 application's call to gss_init_sec_context(). SPKM-2 accomplishes 741 this using only SPKM-REQ (thereby authenticating the initiator to the 742 target), while SPKM-1 accomplishes this using both SPKM-REQ and 743 SPKM-REP-TI (thereby authenticating the target to the initiator). 745 Applications requiring authentication of both peers (initiator as 746 well as target) must request mutual authentication, resulting in 747 "mutual-state" being set within SPKM-REQ Options. In response to 748 such a request, the context target will reply to the initiator with 749 an SPKM-REP-TI token. If mechanism SPKM-2 has been chosen, this 750 completes the (timestamp-based) mutual authentication context 751 establishment exchange. If mechanism SPKM-1 has been chosen and 752 SPKM-REP-TI is sent, the initiator will then reply to the target with 753 an SPKM-REP-IT token, completing the (random-number-based) mutual 754 authentication context establishment exchange. 756 Other bits in the Options field of Context-Data are explained in 757 RFC-1508, with the exception of target-certif-data-required, which 758 the initiator sets to TRUE to request that the target return its 759 certification data in the SPKM-REP-TI token. For unilateral authen- 760 tication in SPKM-2 (in which no SPKM-REP-TI token is constructed), 761 this option bit is ignored by both initiator and target. 763 3.1.2. Context Establishment Tokens - Target 765 SPKM-REP-TI ::= SEQUENCE { 766 responseToken REP-TI-TOKEN, 767 certif-data CertificationData OPTIONAL 768 -- included if target-certif-data-required option was 769 -- set to TRUE in SPKM-REQ 770 } 772 REP-TI-TOKEN ::= SEQUENCE { 773 rep-ti-contents Rep-ti-contents, 774 algId AlgorithmIdentifier, 775 rep-ti-integ Integrity -- "token" is Rep-ti-contents 776 } 778 Adams Document Expiration: 19 July 1996 15 780 Rep-ti-contents ::= SEQUENCE { 781 tok-id INTEGER (512), -- shall contain 0200 (hex) 782 context-id Random-Integer, -- see Section 6.3 783 pvno [0] BIT STRING OPTIONAL, -- prot. version number 784 timestamp UTCTime OPTIONAL, -- mandatory for SPKM-2 785 randTarg Random-Integer, 786 src-name [1] Name OPTIONAL, 787 -- must contain whatever value was supplied in REQ-TOKEN 788 targ-name Name, 789 randSrc Random-Integer, 790 rep-data Context-Data, 791 validity [2] Validity OPTIONAL, 792 -- validity interval for key (used if the target can only 793 -- support a shorter context lifetime than was offered in 794 -- REQ-TOKEN) 795 key-estb-id AlgorithmIdentifier OPTIONAL, 796 -- used if target is changing key estb. algorithm (must be 797 -- a member of initiators key-estb-set) 798 key-estb-str BIT STRING OPTIONAL 799 -- contains (1) the response to the initiators 800 -- key-estb-req (if init. used a 2-pass K-ALG), or (2) the 801 -- key-estb-req corresponding to the K-ALG supplied in 802 -- above key-estb-id, or (3) the key-estb-req corresponding 803 -- to the first K-ALG supplied in initiator's key-estb-id, 804 -- if initiator's (OPTIONAL) key-estb-req was not used 805 -- (target's key-estb-str must be present in this case). 806 -- Established key must satisfy the key length constraints 807 -- specified in Section 2.4. 808 } 810 The protocol version number (pvno) parameter is a BIT STRING which 811 uses as many bits as necessary to specify a single SPKM protocol 812 version offered by the initiator which is supported by the target 813 (one bit per protocol version); that is, the target sets exactly one 814 bit of pvno. If none of the versions offered by the initiator are 815 supported by the target, a delete token must be returned so that the 816 context is never established. If the initiator's pvno has only one 817 bit set and the target happens to support this protocol version, 818 then this version is used over the context and the pvno parameter of 819 REP-TOKEN can be omitted. Finally, if the initiator and target do 820 have one or more versions in common but the version of the REQ-TOKEN 821 received is not supported by the target, a REP-TOKEN must be sent 822 with a desired version bit set in pvno (and dummy values used for 823 all subsequent token fields). The initiator can then respond with a 824 new REQ-TOKEN of the proper version (essentially starting context 825 establishment anew). 827 Adams Document Expiration: 19 July 1996 16 829 3.1.3. Context Establishment Tokens - Initiator (second token) 831 Relevant SPKM-REP-IT syntax is as follows: 833 SPKM-REP-IT ::= SEQUENCE { 834 responseToken REP-IT-TOKEN, 835 algId AlgorithmIdentifier, 836 rep-it-integ Integrity -- "token" is REP-IT-TOKEN 837 } 839 REP-IT-TOKEN ::= SEQUENCE { 840 tok-id INTEGER (768), -- shall contain 0300 (hex) 841 context-id Random-Integer, 842 randSrc Random-Integer, 843 randTarg Random-Integer, 844 targ-name Name, -- the targ-name specified in REP-TI 845 src-name Name OPTIONAL, 846 -- must contain whatever value was supplied in REQ-TOKEN 847 key-estb-rep BIT STRING OPTIONAL 848 -- contains the response to targets key-estb-str 849 -- (if target selected a 2-pass K-ALG) 850 } 852 3.1.4. Error Token 854 The syntax of SPKM-ERROR is as follows: 856 SPKM-ERROR ::= SEQUENCE { 857 error-token ERROR-TOKEN, 858 algId AlgorithmIdentifier, 859 integrity Integrity -- "token" is ERROR-TOKEN 860 } 862 ERROR-TOKRN ::= SEQUENCE { 863 tok-id INTEGER (1024), -- shall contain 0400 (hex) 864 context-id Random-Integer 865 } 867 The SPKM-ERROR token is used only during the context establishment 868 process. If an SPKM-REQ or SPKM-REP-TI token is received in error, 869 the receiving function (either gss_init_sec_context() or 870 gss_accept_sec_context()) will generate an SPKM-ERROR token to be 871 sent to the peer (if the peer is still in the context establishment 872 process) and will return GSS_S_CONTINUE_NEEDED. If, on the other 873 hand, no context establishment response is expected from the peer 874 (i.e., the peer has completed context establishment), the function 875 will return the appropriate major status code (e.g., GSS_S_BAD_SIG) 876 along with a minor status of GSS_SPKM_S_SG_CONTEXT_ESTB_ABORT and all 877 context-relevant information will be deleted. The output token will 878 not be an SPKM-ERROR token but will instead be an SPKM-DEL token 879 which will be processed by the peer's gss_process_context_token(). 881 Adams Document Expiration: 19 July 1996 17 883 If gss_init_sec_context() receives an error token (whether valid or 884 invalid), it will regenerate SPKM-REQ as its output token and return 885 a major status code of GSS_S_CONTINUE_NEEDED. (Note that if the 886 peer's gss_accept_sec_context() receives SPKM-REQ token when it is 887 expecting a SPKM-REP-IT token, it will ignore SPKM-REQ and return a 888 zero-length output token with a major status of 889 GSS_S_CONTINUE_NEEDED.) 891 Similarly, if gss_accept_sec_context() receives an error token 892 (whether valid or invalid), it will regenerate SPKM-REP-TI as its 893 output token and return a major status code of GSS_S_CONTINUE_NEEDED. 895 md5WithRsa is currently stipulated for the signing of context 896 establishment tokens. Discrepancies involving modulus bitlength can 897 be resolved through judicious use of the SPKM-ERROR token. The 898 context initiator signs REQ-TOKEN using the strongest RSA it supports 899 (e.g., 1024 bits). If the target is unable to verify signatures of 900 this length, it sends SPKM-ERROR signed with the strongest RSA that 901 it supports (e.g. 512). 903 At the completion of this exchange, both sides know what RSA 904 bitlength the other supports, since the size of the signature is 905 equal to the size of the modulus. Further exchanges can be made 906 (using successively smaller supported bitlengths) until either an 907 agreement is reached or context establishment is aborted because no 908 agreement is possible. 910 3.2. Per-Message and Context Deletion Tokens 912 Three classes of tokens are defined in this section: "MIC" tokens, 913 emitted by calls to gss_getMIC() and consumed by calls to 914 gss_verifyMIC(); "Wrap" tokens, emitted by calls to gss_wrap() and 915 consumed by calls to gss_unwrap(); and context deletion tokens, 916 emitted by calls to gss_init_sec_context(), gss_accept_sec_context(), 917 or gss_delete_sec_context() and consumed by calls to 918 gss_process_context_token(). 920 3.2.1. Per-message Tokens - Sign / MIC 922 Use of the gss_sign() / gss_getMIC() call yields a token, separate 923 from the user data being protected, which can be used to verify the 924 integrity of that data as received. The token and the data may be 925 sent separately by the sending application and it is the receiving 926 application's responsibility to associate the received data with the 927 received token. 929 Adams Document Expiration: 19 July 1996 18 931 The SPKM-MIC token has the following format: 933 SPKM-MIC ::= SEQUENCE { 934 mic-header Mic-Header, 935 int-cksum BIT STRING 936 -- Checksum over header and data, 937 -- calculated according to algorithm 938 -- specified in int-alg field. 939 } 941 Mic-Header ::= SEQUENCE { 942 tok-id INTEGER (257), 943 -- shall contain 0101 (hex) 944 context-id Random-Integer, 945 int-alg [0] AlgorithmIdentifier OPTIONAL, 946 -- Integrity algorithm indicator (must 947 -- be one of the agreed integrity 948 -- algorithms for this context). 949 -- field not present = default id. 950 snd-seq [1] SeqNum OPTIONAL -- sequence number field. 951 } 953 SeqNum ::= SEQUENCE { 954 num INTEGER, -- the sequence number itself 955 dir-ind BOOLEAN -- a direction indicator 956 } 958 3.2.1.1. Checksum 960 Checksum calculation procedure (common to all algorithms -- note that 961 for SPKM the term "checksum" includes digital signatures as well as 962 hashes and MACs): Checksums are calculated over the data field, 963 logically prepended by the bytes of the plaintext token header 964 (mic-header). The result binds the data to the entire plaintext 965 header, so as to minimize the possibility of malicious splicing. 967 For example, if the int-alg specifies the md5WithRSA algorithm, then 968 the checksum is formed by computing an MD5 [RFC-1321] hash over the 969 plaintext data (prepended by the header), and then computing an RSA 970 signature [PKCS1] on the 16-byte MD5 result. The signature is 971 computed using the RSA private key retrieved from the credentials 972 structure and the result (whose length is implied by the "modulus" 973 parameter in the private key) is stored in the int-cksum field. 975 If the int-alg specifies a keyed hashing algorithm (for example, 976 DES-MAC or md5-DES-CBC), then the key to be used is the appropriate 977 subkey derived from the context key (see Section 2.4). Again, the 978 result (whose length is implied by int-alg) is stored in the 979 int-cksum field. 981 Adams Document Expiration: 19 July 1996 19 983 3.2.1.2. Sequence Number 985 It is assumed that the underlying transport layers (of whatever pro- 986 tocol stack is being used by the application) will provide adequate 987 communications reliability (that is, non-malicious loss, re-ordering, 988 etc., of data packets will be handled correctly). Therefore, 989 sequence numbers are used in SPKM purely for security, as opposed to 990 reliability, reasons (that is, to avoid malicious loss, replay, or 991 re-ordering of SPKM tokens) -- it is therefore recommended that 992 applications request sequencing and replay detection over all 993 contexts. Note that sequence numbers are used so that there is no 994 requirement for secure timestamps in the message tokens. The 995 initiator's initial sequence number for the current context may be 996 explicitly given in the Context-Data field of SPKM-REQ and the 997 target's initial sequence number may be explicitly given in the 998 Context-Data field of SPKM-REP-TI; if either of these is not given 999 then the default value of 00 is to be used. 1001 Sequence number field: The sequence number field is formed from the 1002 sender's four-byte sequence number and a Boolean direction-indicator 1003 (FALSE - sender is the context initiator, TRUE - sender is the 1004 context acceptor). After constructing a gss_sign/getMIC() or 1005 gss_seal/wrap() token, the sender's seq. number is incremented by 1. 1007 3.2.1.3. Sequence Number Processing 1009 The receiver of the token will verify the sequence number field by 1010 comparing the sequence number with the expected sequence number and 1011 the direction indicator with the expected direction indicator. If 1012 the sequence number in the token is higher than the expected number, 1013 then the expected sequence number is adjusted and GSS_S_GAP_TOKEN is 1014 returned. If the token sequence number is lower than the expected 1015 number, then the expected sequence number is not adjusted and 1016 GSS_S_DUPLICATE_TOKEN, GSS_S_UNSEQ_TOKEN, or GSS_S_OLD_TOKEN is 1017 returned, whichever is appropriate. If the direction indicator is 1018 wrong, then the expected sequence number is not adjusted and 1019 GSS_S_UNSEQ_TOKEN is returned. 1021 Since the sequence number is used as part of the input to the 1022 integrity checksum, sequence numbers need not be encrypted, and 1023 attempts to splice a checksum and sequence number from different 1024 messages will be detected. The direction indicator will detect 1025 tokens which have been maliciously reflected. 1027 3.2.2. Per-message Tokens - Seal / Wrap 1029 Use of the gss_seal() / gss_wrap() call yields a token which 1030 encapsulates the input user data (optionally encrypted) along with 1031 associated integrity check quantities. The token emitted by 1032 gss_seal() / gss_wrap() consists of an integrity header followed by a 1033 body portion that contains either the plaintext data (if conf-alg = 1034 NULL) or encrypted data (using the appropriate subkey specified in 1035 Section 2.4 for one of the agreed C-ALGs for this context). 1037 Adams Document Expiration: 19 July 1996 20 1039 The SPKM-WRAP token has the following format: 1041 SPKM-WRAP ::= SEQUENCE { 1042 wrap-header Wrap-Header, 1043 wrap-body Wrap-Body 1044 } 1046 Wrap-Header ::= SEQUENCE { 1047 tok-id INTEGER (513), 1048 -- shall contain 0201 (hex) 1049 context-id Random-Integer, 1050 int-alg [0] AlgorithmIdentifier OPTIONAL, 1051 -- Integrity algorithm indicator (must 1052 -- be one of the agreed integrity 1053 -- algorithms for this context). 1054 -- field not present = default id. 1055 conf-alg [1] Conf-Alg OPTIONAL, 1056 -- Confidentiality algorithm indicator 1057 -- (must be NULL or one of the agreed 1058 -- confidentiality algorithms for this 1059 -- context). 1060 -- field not present = default id. 1061 -- NULL = none (no conf. applied). 1062 snd-seq [2] SeqNum OPTIONAL 1063 -- sequence number field. 1064 } 1066 Wrap-Body ::= SEQUENCE { 1067 int-cksum BIT STRING, 1068 -- Checksum of header and data, 1069 -- calculated according to algorithm 1070 -- specified in int-alg field. 1071 data BIT STRING 1072 -- encrypted or plaintext data. 1073 } 1075 Conf-Alg ::= CHOICE { 1076 algId [0] AlgorithmIdentifier, 1077 null [1] NULL 1078 } 1080 3.2.2.1: Confounding 1082 As in [KRB5], an 8-byte random confounder is prepended to the data to 1083 compensate for the fact that an IV of zero is used for encryption. 1084 The result is referred to as the "confounded" data field. 1086 Adams Document Expiration: 19 July 1996 21 1088 3.2.2.2. Checksum 1090 Checksum calculation procedure (common to all algorithms): Checksums 1091 are calculated over the plaintext data field, logically prepended by 1092 the bytes of the plaintext token header (wrap-header). As with 1093 gss_sign() / gss_getMIC(), the result binds the data to the entire 1094 plaintext header, so as to minimize the possibility of malicious 1095 splicing. 1097 The examples for md5WithRSA and DES-MAC are exactly as specified in 1098 3.2.1.1. 1100 If int-alg specifies md5-DES-CBC and conf-alg specifies anything 1101 other than DES-CBC, then the checksum is computed according to 1102 3.2.1.1 and the result is stored in int-cksum. However, if conf-alg 1103 specifies DES-CBC then the encryption and the integrity are done 1104 as follows. An MD5 [RFC-1321] hash is computed over the plaintext 1105 data (prepended by the header). This 16-byte value is appended to 1106 the concatenation of the "confounded" data and 1-8 padding bytes (the 1107 padding is as specified in [KRB5] for DES-CBC). The result is 1108 then CBC encrypted using the DES-CBC subkey (see Section 2.4) and 1109 placed in the "data" field of Wrap-Body. The final two blocks of 1110 ciphertext (i.e., the encrypted MD5 hash) are also placed in the 1111 int-cksum field of Wrap-Body as the integrity checksum. 1113 If int-alg specifies sum64-DES-CBC then conf-alg must specify DES-CBC 1114 (i.e., confidentiality must be requested by the calling application 1115 or SPKM will return an error). Encryption and integrity are done in 1116 a single pass using the DES-CBC subkey as follows. The sum 1117 (modulo 2**64 - 1) of all plaintext data blocks (prepended by the 1118 header) is computed. This 8-byte value is appended to the 1119 concatenation of the "confounded" data and 1-8 padding bytes (the 1120 padding is as specified in [KRB5] for DES-CBC). As above, the result 1121 is then CBC encrypted and placed in the "data" field of Wrap-Body. 1122 The final block of ciphertext (i.e., the encrypted sum) is also 1123 placed in the int-cksum field of Wrap-Body as the integrity checksum. 1125 3.2.2.3 Sequence Number 1127 Sequence numbers are computed and processed for gss_wrap() exactly 1128 as specified in 3.2.1.2 and 3.2.1.3. 1130 Adams Document Expiration: 19 July 1996 22 1132 3.2.2.4: Data Encryption 1134 The following procedure is followed unless (a) conf-alg is NULL (no 1135 encryption), or (b) conf-alg is DES-CBC and int-alg is md5-DES-CBC 1136 (encryption as specified in 3.2.2.2), or (c) int-alg is sum64-DES-CBC 1137 (encryption as specified in 3.2.2.2): 1139 The "confounded" data is padded and encrypted according to the 1140 algorithm specified in the conf-alg field. The data is encrypted 1141 using CBC with an IV of zero. The key used is the appropriate subkey 1142 derived from the established context key using the subkey derivation 1143 algorithm described in Section 2.4 (this ensures that the subkey used 1144 for encryption and the subkey used for a separate, keyed integrity 1145 algorithm -- for example DES-MAC, but not sum64-DES-CBC -- are 1146 different). 1148 3.2.3. Context deletion token 1150 The token emitted by gss_delete_sec_context() is based on the format 1151 for tokens emitted by gss_sign() / gss_getMIC(). 1153 The SPKM-DEL token has the following format: 1155 SPKM-DEL ::= SEQUENCE { 1156 del-header Del-Header, 1157 int-cksum BIT STRING 1158 -- Checksum of header, calculated 1159 -- according to algorithm specified 1160 -- in int-alg field. 1161 } 1163 Del-Header ::= SEQUENCE { 1164 tok-id INTEGER (769), 1165 -- shall contain 0301 (hex) 1166 context-id Random-Integer, 1167 int-alg [0] AlgorithmIdentifier OPTIONAL, 1168 -- Integrity algorithm indicator (must 1169 -- be one of the agreed integrity 1170 -- algorithms for this context). 1171 -- field not present = default id. 1172 snd-seq [1] SeqNum OPTIONAL 1173 -- sequence number field. 1174 } 1176 The field snd-seq will be calculated as for tokens emitted by 1177 gss_sign() / gss_getMIC(). The field int-cksum will be calculated as 1178 for tokens emitted by gss_sign() / gss_getMIC(), except that the 1179 user-data component of the checksum data will be a zero-length 1180 string. 1182 Adams Document Expiration: 19 July 1996 23 1184 If a valid delete token is received, then the SPKM implementation 1185 will delete the context and gss_process_context_token() will return a 1186 major status of GSS_S_COMPLETE and a minor status of 1187 GSS_SPKM_S_SG_CONTEXT_DELETED. If, on the other hand, the delete 1188 token is invalid, the context will not be deleted and 1189 gss_process_context_token() will return the appropriate major status 1190 (GSS_S_BAD_SIG, for example) and a minor status of 1191 GSS_SPKM_S_SG_BAD_DELETE_TOKEN_RECD. The application may wish to 1192 take some action at this point to check the context status (such as 1193 sending a sealed/wrapped test message to its peer and waiting for a 1194 sealed/wrapped response). 1196 4. NAME TYPES AND OBJECT IDENTIFIERS 1198 No mandatory name forms have yet been defined for SPKM. This section 1199 is for further study. 1201 4.1. Optional Name Forms 1203 This section discusses name forms which may optionally be supported 1204 by implementations of the SPKM GSS-API mechanism. It is recognized 1205 that OS-specific functions outside GSS-API are likely to exist in 1206 order to perform translations among these forms, and that GSS-API 1207 implementations supporting these forms may themselves be layered atop 1208 such OS-specific functions. Inclusion of this support within GSS-API 1209 implementations is intended as a convenience to applications. 1211 4.1.1. User Name Form 1213 This name form shall be represented by the Object Identifier {iso(1) 1214 member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) 1215 generic(1) user_name(1)}. The recommended symbolic name for this 1216 type is "GSS_SPKM_NT_USER_NAME". 1218 This name type is used to indicate a named user on a local system. 1219 Its interpretation is OS-specific. This name form is constructed as: 1221 username 1223 4.1.2. Machine UID Form 1225 This name form shall be represented by the Object Identifier {iso(1) 1226 member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) 1227 generic(1) machine_uid_name(2)}. The recommended symbolic name for 1228 this type is "GSS_SPKM_NT_MACHINE_UID_NAME". 1230 This name type is used to indicate a numeric user identifier 1231 corresponding to a user on a local system. Its interpretation is 1232 OS-specific. The gss_buffer_desc representing a name of this type 1233 should contain a locally-significant uid_t, represented in host byte 1234 order. The gss_import_name() operation resolves this uid into a 1235 username, which is then treated as the User Name Form. 1237 Adams Document Expiration: 19 July 1996 24 1239 4.1.3. String UID Form 1241 This name form shall be represented by the Object Identifier {iso(1) 1242 member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) 1243 generic(1) string_uid_name(3)}. The recommended symbolic name for 1244 this type is "GSS_SPKM_NT_STRING_UID_NAME". 1246 This name type is used to indicate a string of digits representing 1247 the numeric user identifier of a user on a local system. Its 1248 interpretation is OS-specific. This name type is similar to the 1249 Machine UID Form, except that the buffer contains a string 1250 representing the uid_t. 1252 5. PARAMETER DEFINITIONS 1254 This section defines parameter values used by the SPKM GSS-API 1255 mechanism. It defines interface elements in support of portability. 1257 5.1. Minor Status Codes 1259 This section recommends common symbolic names for minor_status values 1260 to be returned by the SPKM GSS-API mechanism. Use of these 1261 definitions will enable independent implementors to enhance 1262 application portability across different implementations of the 1263 mechanism defined in this specification. (In all cases, 1264 implementations of gss_display_status() will enable callers to 1265 convert minor_status indicators to text representations.) Each 1266 implementation must make available, through include files or other 1267 means, a facility to translate these symbolic names into the concrete 1268 values which a particular GSS-API implementation uses to represent 1269 the minor_status values specified in this section. It is recognized 1270 that this list may grow over time, and that the need for additional 1271 minor_status codes specific to particular implementations may arise. 1273 5.1.1. Non-SPKM-specific codes (Minor Status Code MSB, bit 31, SET) 1275 5.1.1.1. GSS-Related codes (Minor Status Code bit 30 SET) 1277 GSS_S_G_VALIDATE_FAILED 1278 /* "Validation error" */ 1279 GSS_S_G_BUFFER_ALLOC 1280 /* "Couldn't allocate gss_buffer_t data" */ 1281 GSS_S_G_BAD_MSG_CTX 1282 /* "Message context invalid" */ 1283 GSS_S_G_WRONG_SIZE 1284 /* "Buffer is the wrong size" */ 1285 GSS_S_G_BAD_USAGE 1286 /* "Credential usage type is unknown" */ 1287 GSS_S_G_UNAVAIL_QOP 1288 /* "Unavailable quality of protection specified" */ 1290 5.1.1.2. Implementation-Related codes (Minor Status Code bit 30 OFF) 1292 GSS_S_G_MEMORY_ALLOC 1293 /* "Couldn't perform requested memory allocation" */ 1295 Adams Document Expiration: 19 July 1996 25 1297 5.1.2. SPKM-specific-codes (Minor Status Code MSB, bit 31, OFF) 1299 GSS_SPKM_S_SG_CONTEXT_ESTABLISHED 1300 /* "Context is already fully established" */ 1301 GSS_SPKM_S_SG_BAD_INT_ALG_TYPE 1302 /* "Unknown integrity algorithm type in token" */ 1303 GSS_SPKM_S_SG_BAD_CONF_ALG_TYPE 1304 /* "Unknown confidentiality algorithm type in token" */ 1305 GSS_SPKM_S_SG_BAD_KEY_ESTB_ALG_TYPE 1306 /* "Unknown key establishment algorithm type in token" */ 1307 GSS_SPKM_S_SG_CTX_INCOMPLETE 1308 /* "Attempt to use incomplete security context" */ 1309 GSS_SPKM_S_SG_BAD_INT_ALG_SET 1310 /* "No integrity algorithm in common from offered set" */ 1311 GSS_SPKM_S_SG_BAD_CONF_ALG_SET 1312 /* "No confidentiality algorithm in common from offered set" */ 1313 GSS_SPKM_S_SG_BAD_KEY_ESTB_ALG_SET 1314 /* "No key establishment algorithm in common from offered set" */ 1315 GSS_SPKM_S_SG_NO_PVNO_IN_COMMON 1316 /* "No protocol version number in common from offered set" */ 1317 GSS_SPKM_S_SG_INVALID_TOKEN_DATA 1318 /* "Data is improperly formatted: cannot encode into token" */ 1319 GSS_SPKM_S_SG_INVALID_TOKEN_FORMAT 1320 /* "Received token is improperly formatted: cannot decode" */ 1321 GSS_SPKM_S_SG_CONTEXT_DELETED 1322 /* "Context deleted at peer's request" */ 1323 GSS_SPKM_S_SG_BAD_DELETE_TOKEN_RECD 1324 /* "Invalid delete token received -- context not deleted" */ 1325 GSS_SPKM_S_SG_CONTEXT_ESTB_ABORT 1326 /* "Unrecoverable context establishment error. Context deleted" */ 1328 5.2. Quality of Protection Values 1330 The Quality of Protection (QOP) parameter is used in the SPKM GSS-API 1331 mechanism as input to gss_sign() and gss_seal() (gss_getMIC() and 1332 gss_wrap()) to select among alternate confidentiality and 1333 integrity-checking algorithms. Once these sets of algorithms have 1334 been agreed upon by the context initiator and target, the QOP 1335 parameter simply selects from these ordered sets. 1337 More specifically, the SPKM-REQ token sends an ordered sequence of 1338 Alg. IDs specifying integrity-checking algorithms supported by the 1339 initiator and an ordered sequence of Alg. IDs specifying 1340 confidentiality algorithms supported by the initiator. The target 1341 returns the subset of the offered integrity-checking Alg. IDs which 1342 it supports and the subset of the offered confidentiality Alg. IDs 1343 which it supports in the SPKM-REP-TI token (in the same relative 1344 orders as those given by the initiator). Thus, the initiator and 1345 target each know the algorithms which they themselves support and the 1346 algorithms which both sides support (the latter are defined to be 1347 those supported over the established context). The QOP parameter has 1348 meaning and validity with reference to this knowledge. For example, 1349 an application may request integrity algorithm number 3 as defined by 1350 the mechanism specification. If this algorithm is supported over 1351 this context then it is used; otherwise, GSS_S_FAILURE and an 1352 appropriate minor status code are returned. 1354 Adams Document Expiration: 19 July 1996 26 1356 If the SPKM-REP-TI token is not used (unilateral authentication using 1357 SPKM-2), then the "agreed" sets of Alg. IDs are simply taken to be 1358 the initiator's sets (if this is unacceptable to the target then it 1359 must return an error token so that the context is never established). 1360 Note that, in the interest of interoperability, the initiator is not 1361 required to offer every algorithm it supports; rather, it may offer 1362 only the mandated/recommended SPKM algorithms since these are likely 1363 to be supported by the target. 1365 The QOP parameter for SPKM is defined to be a 32-bit unsigned integer 1366 (an OM_uint32) with the following bit-field assignments: 1368 Confidentiality Integrity 1369 31 (MSB) 16 15 (LSB) 0 1370 ------------------------------------|----------------------------------- 1371 | TS (5) | U(3) | IA (4) | MA (4) | TS (5) | U(3) | IA (4) | MA(4) | 1372 ------------------------------------|----------------------------------- 1374 where 1376 TS is a 5-bit Type Specifier (a semantic qualifier whose value 1377 specifies the type of algorithm which may be used to protect the 1378 corresponding token -- see below for details); 1380 U is a 3-bit Unspecified field (available for future 1381 use/expansion); 1383 IA is a 4-bit field enumerating Implementation-specific 1384 Algorithms; and 1386 MA is a 4-bit field enumerating Mechanism-defined Algorithms. 1388 The interpretation of the QOP parameter is as follows (note that the 1389 same procedure is used for both the confidentiality and the integrity 1390 halves of the parameter). The MA field is examined first. If it is 1391 non-zero then the algorithm used to protect the token is the 1392 mechanism-specified algorithm corresponding to that integer value. 1394 If MA is zero then IA is examined. If this field value is non-zero 1395 then the algorithm used to protect the token is the implementation- 1396 specified algorithm corresponding to that integer value (if this 1397 algorithm is available over the established context). Note that use 1398 of this field may hinder portability since a particular value may 1399 specify one algorithm in one implementation of the mechanism and may 1400 not be supported or may specify a completely different algorithm in 1401 another implementation of the mechanism. 1403 Finally, if both MA and IA are zero then TS is examined. A value of 1404 zero for TS specifies the default algorithm for the established 1405 context, which is defined to be the first algorithm on the 1406 initiator's list of offered algorithms (confidentiality or integrity, 1407 depending on which half of QOP is being examined) which is supported 1408 over the context. A non-zero value for TS corresponds to a 1409 particular algorithm qualifier and selects the first algorithm 1410 supported over the context which satisfies that qualifier. 1412 Adams Document Expiration: 19 July 1996 27 1414 The following TS values (i.e., algorithm qualifiers) are specified; 1415 other values may be added in the future. 1417 For the Confidentiality TS field: 1419 00001 (1) = SPKM_SYM_ALG_STRENGTH_STRONG 1420 00010 (2) = SPKM_SYM_ALG_STRENGTH_MEDIUM 1421 00011 (3) = SPKM_SYM_ALG_STRENGTH_WEAK 1423 For the Integrity TS field: 1425 00001 (1) = SPKM_INT_ALG_NON_REP_SUPPORT 1426 00010 (2) = SPKM_INT_ALG_REPUDIABLE 1428 Clearly, qualifiers such as strong, medium, and weak are debatable 1429 and likely to change with time, but for the purposes of this version 1430 of the specification we define these terms as follows. A 1431 confidentiality algorithm is "weak" if the effective key length of 1432 the cipher is 40 bits or less; it is "medium-strength" if the 1433 effective key length is strictly between 40 and 80 bits; and it is 1434 "strong" if the effective key length is 80 bits or greater. (Note 1435 that "effective key length" describes the computational effort 1436 required to break a cipher using the best-known cryptanalytic attack 1437 against that cipher.) 1439 A five-bit TS field allows up to 31 qualifiers for each of 1440 confidentiality and integrity (since "0" is reserved for "default"). 1441 This document specifies three for confidentiality and two for 1442 integrity, leaving a lot of room for future specification. 1443 Suggestions of qualifiers such as "fast", "medium-speed", and "slow" 1444 have been made, but such terms are difficult to quantify (and in any 1445 case are platform- and processor-dependent), and so have been left 1446 out of this initial specification. The intention is that the TS 1447 terms be quantitative, environment-independent qualifiers of 1448 algorithms, as much as this is possible. 1450 Use of the QOP structure as defined above is ultimately meant to be 1451 as follows. 1453 - TS values are specified at the GSS-API level and are therefore 1454 portable across mechanisms. Applications which know nothing about 1455 algorithms are still able to choose "quality" of protection for 1456 their message tokens. 1458 - MA values are specified at the mechanism level and are therefore 1459 portable across implementations of a mechanism. For example, all 1460 implementations of the Kerberos V5 GSS mechanism must support 1462 GSS_KRB5_INTEG_C_QOP_MD5 (value: 1) 1463 GSS_KRB5_INTEG_C_QOP_DES_MD5 (value: 2) 1464 GSS_KRB5_INTEG_C_QOP_DES_MAC (value: 3). 1466 (Note that these Kerberos-specified integrity QOP values do not 1467 conflict with the QOP structure defined above.) 1469 Adams Document Expiration: 19 July 1996 28 1471 - IA values are specified at the implementation level (in user 1472 documentation, for example) and are therefore typically non- 1473 portable. An application which is aware of its own mechanism 1474 implementation and the mechanism implementation of its peer, 1475 however, is free to use these values since they will be perfectly 1476 valid and meaningful over that context and between those peers. 1478 The receiver of a token must pass back to its calling application a 1479 QOP parameter with all relevant fields set. For example, if 1480 triple-DES has been specified by a mechanism as algorithm 8, then 1481 a receiver of a triple-DES-protected token must pass to its 1482 application (QOP Confidentiality TS=1, IA=0, MA=8). In this way, 1483 the application is free to read whatever part of the QOP it 1484 understands (TS or IA/MA). 1486 To aid in implementation and interoperability, the following 1487 stipulation is made. The set of integrity Alg. IDs sent by the 1488 initiator must contain at least one specifying an algorithm which 1489 computes a digital signature supporting non-repudiation, and must 1490 contain at least one specifying any other (repudiable) integrity 1491 algorithm. The subset of integrity Alg. IDs returned by the target 1492 must also contain at least one specifying an algorithm which computes 1493 a digital signature supporting non-repudiation, and at least one 1494 specifying a repudiable integrity algorithm. 1496 The reason for this stipulation is to ensure that every SPKM 1497 implementation will provide an integrity service which supports non- 1498 repudiation and one which does not support non-repudiation. An 1499 application with no knowledge of underlying algorithms can choose one 1500 or the other by passing (QOP Integrity TS=1, IA=MA=0) or (QOP 1501 Integrity TS=2, IA=MA=0). Although an initiator who wishes to remain 1502 anonymous will never actually use the non-repudiable digital 1503 signature, this integrity service must be available over the context 1504 so that the target can use it if desired. 1506 Finally, in accordance with the MANDATORY and RECOMMENDED algorithms 1507 given in Section 2, the following QOP values are specified for SPKM. 1509 For the Confidentiality MA field: 1511 0001 (1) = DES-CBC 1513 For the Integrity MA field: 1515 0001 (1) = md5WithRSA 1516 0010 (2) = DES-MAC 1518 6. SUPPORT FUNCTIONS 1520 This section describes a mandatory support function for SPKM- 1521 conformant implementations which may, in fact, be of value in all 1522 GSS-API mechanisms. It makes use of the token-id and context-id 1523 information which is included in SPKM context-establishment, error, 1524 context-deletion, and per-message tokens. The function is defined 1525 in the following section. 1527 Adams Document Expiration: 19 July 1996 29 1529 6.1. SPKM_Parse_token call 1531 Inputs: 1533 o input_token OCTET STRING 1535 Outputs: 1537 o major_status INTEGER, 1539 o minor_status INTEGER, 1541 o mech_type OBJECT IDENTIFIER, 1543 o token_type INTEGER, 1545 o context_handle CONTEXT HANDLE, 1547 Return major_status codes: 1549 o GSS_S_COMPLETE indicates that the input_token could be parsed for 1550 all relevant fields. The resulting values are stored in 1551 mech_type, token_type and context_handle, respectively (with NULLs 1552 in any parameters which are not relevant). 1554 o GSS_S_DEFECTIVE_TOKEN indicates that either the token-id or the 1555 context-id (if it was expected) information could not be parsed. 1556 A non-NULL return value in token_type indicates that the latter 1557 situation occurred. 1559 o GSS_S_NO_TYPE indicates that the token-id information could be 1560 parsed, but it did not correspond to any valid token_type. 1562 (Note that this major status code has not been defined for GSS in 1563 RFC-1508. Until such a definition is made (if ever), SPKM 1564 implementations should instead return GSS_S_DEFECTIVE_TOKEN with 1565 both token_type and context_handle set to NULL. This essentially 1566 implies that unrecognized token-id information is considered to be 1567 equivalent to token-id information which could not be parsed.) 1569 o GSS_S_NO_CONTEXT indicates that the context-id could be parsed, 1570 but it did not correspond to any valid context_handle. 1572 o GSS_S_FAILURE indicates that the mechanism type could not be 1573 parsed (for example, the token may be corrupted). 1575 SPKM_Parse_token() is used to return to an application the mechanism 1576 type, token type, and context handle which correspond to a given 1577 input token. Since GSS-API tokens are meant to be opaque to the 1578 calling application, this function allows the application to 1579 determine information about the token without having to violate the 1580 opaqueness intention of GSS. Of primary importance is the token 1581 type, which the application can then use to decide which GSS function 1582 to call in order to have the token processed. 1584 Adams Document Expiration: 19 July 1996 30 1586 If all tokens are framed as suggested in RFC-1508, Appendix B 1587 (specified both in the Kerberos V5 GSS mechanism [KRB5] and in this 1588 document), then any mechanism implementation should be able to return 1589 at least the mech_type parameter (the other parameters being NULL) 1590 for any uncorrupted input token. If the mechanism implementation 1591 whose SPKM_Parse_token() function is being called does recognize the 1592 token, it can return token_type so that the application can 1593 subsequently call the correct GSS function. Finally, if the 1594 mechanism provides a context-id field in its tokens (as SPKM does), 1595 then an implementation can map the context-id to a context_handle and 1596 return this to the application. This is necessary for the situation 1597 where an application has multiple contexts open simultaneously, all 1598 using the same mechanism. When an incoming token arrives, the 1599 application can use this function to determine not only which GSS 1600 function to call, but also which context_handle to use for the call. 1601 Note that this function does no cryptographic processing to determine 1602 the validity of tokens; it simply attempts to parse the mech_type, 1603 token_type, and context-id fields of any token it is given. Thus, it 1604 is conceivable, for example, that an arbitrary buffer of data might 1605 start with random values which look like a valid mech_type and that 1606 SPKM_Parse_token() would return incorrect information if given this 1607 buffer. While conceivable, however, such a situation is unlikely. 1609 The SPKM_Parse_token() function is mandatory for SPKM-conformant 1610 implementations, but it is optional for applications. That is, if 1611 an application has only one context open and can guess which GSS 1612 function to call (or is willing to put up with some error codes), 1613 then it need never call SPKM_Parse_token(). Furthermore, if this 1614 function ever migrates up to the GSS-API level, then 1615 SPKM_Parse_token() will be deprecated at that time in favour of 1616 GSS_Parse_token(), or whatever the new name and function 1617 specification might be. Note finally that no minor status return 1618 codes have been defined for this function at this time. 1620 6.2. The token_type Output Parameter 1622 The following token types are defined: 1624 GSS_INIT_TOKEN = 1 1625 GSS_ACCEPT_TOKEN = 2 1626 GSS_ERROR_TOKEN = 3 1627 GSS_SIGN_TOKEN = GSS_GETMIC_TOKEN = 4 1628 GSS_SEAL_TOKEN = GSS_WRAP_TOKEN = 5 1629 GSS_DELETE_TOKEN = 6 1631 All SPKM mechanisms shall be able to perform the mapping from the 1632 token-id information which is included in every token (through the 1633 tag values in SPKMInnerContextToken or through the tok-id field) to 1634 one of the above token types. Applications should be able to decide, 1635 on the basis of token_type, which GSS function to call (for example, 1636 if the token is a GSS_INIT_TOKEN then the application will call 1637 gss_accept_sec_context(), and if the token is a GSS_WRAP_TOKEN then 1638 the application will call gss_unwrap()). 1640 Adams Document Expiration: 19 July 1996 31 1642 6.3. The context_handle Output Parameter 1644 The SPKM mechanism implementation is responsible for maintaining a 1645 mapping between the context-id value which is included in every token 1646 and a context_handle, thus associating an individual token with its 1647 proper context. Clearly the value of context_handle may be locally 1648 determined and may, in fact, be associated with memory containing 1649 sensitive data on the local system, and so having the context-id 1650 actually be set equal to a computed context_handle will not work in 1651 general. Conversely, having the context_handle actually be set equal 1652 to a computed context-id will not work in general either, because 1653 context_handle must be returned to the application by the first call 1654 to gss_init_sec_context() or gss_accept_sec_context(), whereas 1655 uniqueness of the context-id (over all contexts at both ends) 1656 may require that both initiator and target be involved in the 1657 computation. Consequently, context_handle and context-id must be 1658 computed separately and the mechanism implementation must be able to 1659 map from one to the other by the completion of context establishment 1660 at the latest. 1662 Computation of context-id during context establishment is 1663 accomplished as follows. Each SPKM implementation is responsible for 1664 generating a "fresh" random number; that is, one which (with high 1665 probability) has not been used previously. Note that there are no 1666 cryptographic requirements on this random number (i.e., it need not 1667 be unpredictable, it simply needs to be fresh). The initiator passes 1668 its random number to the target in the context-id field of the 1669 SPKM-REQ token. If no further context establishment tokens are 1670 expected (as for unilateral authentication in SPKM-2), then this 1671 value is taken to be the context-id (if this is unacceptable to the 1672 target then an error token must be generated). Otherwise, the target 1673 generates its random number and concatenates it to the end of the 1674 initiator's random number. This concatenated value is then taken to 1675 be the context-id and is used in SPKM-REP-TI and in all subsequent 1676 tokens over that context. 1678 Having both peers contribute to the context-id assures each peer of 1679 freshness and therefore precludes replay attacks between contexts 1680 (where a token from an old context between two peers is maliciously 1681 injected into a new context between the same or different peers). 1682 Such assurance is not available to the target in the case of 1683 unilateral authentication using SPKM-2, simply because it has not 1684 contributed to the freshness of the computed context-id (instead, it 1685 must trust the freshness of the initiator's random number, or reject 1686 the context). The key-src-bind field in SPKM-REQ is required to be 1687 present for the case of SPKM-2 unilateral authentication precisely to 1688 assist the target in trusting the freshness of this token (and its 1689 proposed context key). 1691 7. SECURITY CONSIDERATIONS 1693 Security issues are discussed throughout this memo. 1695 Adams Document Expiration: 19 July 1996 32 1697 8. REFERENCES 1699 [Davi89]: D. W. Davies and W. L. Price, "Security for Computer 1700 Networks", Second Edition, John Wiley and Sons, New York, 1989. 1702 [FIPS-113]: National Bureau of Standards, Federal Information 1703 Processing Standard 113, "Computer Data Authentication", May 1985. 1705 [GSSv2]: J. Linn, "Generic Security Service Application Program 1706 Interface Version 2", Internat Draft: draft-ietf-cat-gssv2-xx.txt 1707 (work in progress). 1709 [Juen84]: R. R. Jueneman, C. H. Meyer and S. M. Matyas, Message 1710 Authentication with Manipulation Detection Codes, in Proceedings of 1711 the 1983 IEEE Symposium on Security and Privacy, IEEE Computer 1712 Society Press, 1984, pp.33-54. 1714 [KRB5]: J. Linn, "The Kerberos Version 5 GSS-API Mechanism", 1715 Internet Draft draft-ietf-cat-kerb5gss-xx.txt 1716 (work in progress). 1718 [PKCS1]: RSA Encryption Standard, Version 1.5, RSA Data Security, 1719 Inc., Nov. 1993. 1721 [PKCS3]: Diffie-Hellman Key-Agreement Standard, Version 1.4, RSA 1722 Data Security, Inc., Nov. 1993. 1724 [RFC-1321]: R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321. 1726 [RFC-1422]: S. Kent, "Privacy Enhancement for Internet Electronic 1727 Mail: Part II: Certificate-Based Key Management", RFC 1422. 1729 [RFC-1423]: D. Balenson, "Privacy Enhancement for Internet Elec- 1730 tronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423. 1732 [RFC-1508]: J. Linn, "Generic Security Service Application Program 1733 Interface", RFC 1508. 1735 [RFC-1509]: J. Wray, "Generic Security Service Application Program 1736 Interface: C-bindings", RFC 1509. 1738 [RFC-1510]: J. Kohl and C. Neuman, "The Kerberos Network 1739 Authentication Service (V5)", RFC 1510. 1741 [9798]: ISO/IEC 9798-3, "Information technology - Security 1742 Techniques - Entity authentication mechanisms - Part 3: Entitiy 1743 authentication using a public key algorithm", ISO/IEC, 1993. 1745 [X.501]: ISO/IEC 9594-2, "Information Technology - Open Systems 1746 Interconnection - The Directory: Models", CCITT/ITU Recommendation 1747 X.501, 1993. 1749 Adams Document Expiration: 19 July 1996 33 1751 [X.509]: ISO/IEC 9594-8, "Information Technology - Open Systems 1752 Interconnection - The Directory: Authentication Framework", 1753 CCITT/ITU Recommendation X.509, 1993. 1755 [X9.44]: ANSI, "Public Key Cryptography Using Reversible 1756 Algorithms for the Financial Services Industry: Transport of 1757 Symmetric Algorithm Keys Using RSA", X9.44-1993. 1759 9. AUTHOR'S ADDRESS 1761 Carlisle Adams 1762 Bell-Northern Research 1763 P.O.Box 3511, Station C 1764 Ottawa, Ontario, CANADA K1Y 4H7 1766 Phone: +1 613.763.9008 1767 E-mail: cadams@bnr.ca 1769 Adams Document Expiration: 19 July 1996 34 1771 Appendix A: ASN.1 Module Definition 1773 SpkmGssTokens {iso(1) identified-organization(3) dod(6) internet(1) 1774 security(5) mechanisms(5) spkm(1) spkmGssTokens(10)} 1776 DEFINITIONS IMPLICIT TAGS ::= 1777 BEGIN 1779 -- EXPORTS ALL -- 1781 IMPORTS 1783 Name 1784 FROM InformationFramework {joint-iso-ccitt(2) ds(5) module(1) 1785 informationFramework(1) 2} 1787 Certificate, CertificateList, CertificatePair, AlgorithmIdentifier, 1788 Validity 1789 FROM AuthenticationFramework {joint-iso-ccitt(2) ds(5) module(1) 1790 authenticationFramework(7) 2} ; 1792 -- types -- 1794 SPKM-REQ ::= SEQUENCE { 1795 requestToken REQ-TOKEN, 1796 certif-data [0] CertificationData OPTIONAL, 1797 auth-data [1] AuthorizationData OPTIONAL 1798 } 1800 CertificationData ::= SEQUENCE { 1801 certificationPath [0] CertificationPath OPTIONAL, 1802 certificateRevocationList [1] CertificateList OPTIONAL 1803 } -- at least one of the above shall be present 1805 CertificationPath ::= SEQUENCE { 1806 userKeyId [0] OCTET STRING OPTIONAL, 1807 userCertif [1] Certificate OPTIONAL, 1808 verifKeyId [2] OCTET STRING OPTIONAL, 1809 userVerifCertif [3] Certificate OPTIONAL, 1810 theCACertificates [4] SEQUENCE OF CertificatePair OPTIONAL 1811 } -- Presence of [2] or [3] implies that [0] or [1] must also be 1812 -- present. Presence of [4] implies that at least one of [0], [1], 1813 -- [2], and [3] must also be present. 1815 Adams Document Expiration: 19 July 1996 35 1817 REQ-TOKEN ::= SEQUENCE { 1818 req-contents Req-contents, 1819 algId AlgorithmIdentifier, 1820 req-integrity Integrity -- "token" is Req-contents 1821 } 1823 Integrity ::= BIT STRING 1824 -- If corresponding algId specifies a signing algorithm, 1825 -- "Integrity" holds the result of applying the signing procedure 1826 -- specified in algId to the BER-encoded octet string which results 1827 -- from applying the hashing procedure (also specified in algId) to 1828 -- the DER-encoded octets of "token". 1829 -- Alternatively, if corresponding algId specifies a MACing 1830 -- algorithm, "Integrity" holds the result of applying the MACing 1831 -- procedure specified in algId to the DER-encoded octets of 1832 -- "token" 1834 Req-contents ::= SEQUENCE { 1835 tok-id INTEGER (256), -- shall contain 0100 (hex) 1836 context-id Random-Integer, 1837 pvno BIT STRING, 1838 timestamp UTCTime OPTIONAL, -- mandatory for SPKM-2 1839 randSrc Random-Integer, 1840 targ-name Name, 1841 src-name [0] Name OPTIONAL, 1842 req-data Context-Data, 1843 validity [1] Validity OPTIONAL, 1844 key-estb-set Key-Estb-Algs, 1845 key-estb-req BIT STRING OPTIONAL, 1846 key-src-bind OCTET STRING OPTIONAL 1847 -- This field must be present for the case of SPKM-2 1848 -- unilateral authen. if the K-ALG in use does not provide 1849 -- such a binding (but is optional for all other cases). 1850 -- The octet string holds the result of applying the 1851 -- mandatory hashing procedure (in MANDATORY I-ALG; 1852 -- see Section 2.1) as follows: MD5(src || context_key), 1853 -- where "src" is the DER-encoded octets of src-name, 1854 -- "context-key" is the symmetric key (i.e., the 1855 -- unprotected version of what is transmitted in 1856 -- key-estb-req), and "||" is the concatenation operation. 1857 } 1859 Random-Integer ::= BIT STRING 1861 Context-Data ::= SEQUENCE { 1862 channelId ChannelId OPTIONAL, 1863 seq-number INTEGER OPTIONAL, 1864 options Options, 1865 conf-alg Conf-Algs, 1866 intg-alg Intg-Algs, 1867 owf-alg OWF-Algs 1868 } 1870 ChannelId ::= OCTET STRING 1872 Adams Document Expiration: 19 July 1996 36 1874 Options ::= BIT STRING { 1875 delegation-state (0), 1876 mutual-state (1), 1877 replay-det-state (2), 1878 sequence-state (3), 1879 conf-avail (4), 1880 integ-avail (5), 1881 target-certif-data-required (6) 1882 } 1884 Conf-Algs ::= CHOICE { 1885 algs [0] SEQUENCE OF AlgorithmIdentifier, 1886 null [1] NULL 1887 } 1889 Intg-Algs ::= SEQUENCE OF AlgorithmIdentifier 1891 OWF-Algs ::= SEQUENCE OF AlgorithmIdentifier 1893 Key-Estb-Algs ::= SEQUENCE OF AlgorithmIdentifier 1895 SPKM-REP-TI ::= SEQUENCE { 1896 responseToken REP-TI-TOKEN, 1897 certif-data CertificationData OPTIONAL 1898 -- present if target-certif-data-required option was 1899 } -- set to TRUE in SPKM-REQ 1901 REP-TI-TOKEN ::= SEQUENCE { 1902 rep-ti-contents Rep-ti-contents, 1903 algId AlgorithmIdentifier, 1904 rep-ti-integ Integrity -- "token" is Rep-ti-contents 1905 } 1907 Rep-ti-contents ::= SEQUENCE { 1908 tok-id INTEGER (512), -- shall contain 0200 (hex) 1909 context-id Random-Integer, 1910 pvno [0] BIT STRING OPTIONAL, 1911 timestamp UTCTime OPTIONAL, -- mandatory for SPKM-2 1912 randTarg Random-Integer, 1913 src-name [1] Name OPTIONAL, 1914 targ-name Name, 1915 randSrc Random-Integer, 1916 rep-data Context-Data, 1917 validity [2] Validity OPTIONAL, 1918 key-estb-id AlgorithmIdentifier OPTIONAL, 1919 key-estb-str BIT STRING OPTIONAL 1920 } 1922 SPKM-REP-IT ::= SEQUENCE { 1923 responseToken REP-IT-TOKEN, 1924 algId AlgorithmIdentifier, 1925 rep-it-integ Integrity -- "token" is REP-IT-TOKEN 1926 } 1928 Adams Document Expiration: 19 July 1996 37 1930 REP-IT-TOKEN ::= SEQUENCE { 1931 tok-id INTEGER (768), -- shall contain 0300 (hex) 1932 context-id Random-Integer, 1933 randSrc Random-Integer, 1934 randTarg Random-Integer, 1935 targ-name Name, 1936 src-name Name OPTIONAL, 1937 key-estb-rep BIT STRING OPTIONAL 1938 } 1940 SPKM-ERROR ::= SEQUENCE { 1941 errorToken ERROR-TOKEN, 1942 algId AlgorithmIdentifier, 1943 integrity Integrity -- "token" is ERROR-TOKEN 1944 } 1946 ERROR-TOKEN ::= SEQUENCE { 1947 tok-id INTEGER (1024), -- shall contain 0400 (hex) 1948 context-id Random-Integer 1949 } 1951 SPKM-MIC ::= SEQUENCE { 1952 mic-header Mic-Header, 1953 int-cksum BIT STRING 1954 } 1956 Mic-Header ::= SEQUENCE { 1957 tok-id INTEGER (257), -- shall contain 0101 (hex) 1958 context-id Random-Integer, 1959 int-alg [0] AlgorithmIdentifier OPTIONAL, 1960 snd-seq [1] SeqNum OPTIONAL 1961 } 1963 SeqNum ::= SEQUENCE { 1964 num INTEGER, 1965 dir-ind BOOLEAN 1966 } 1968 SPKM-WRAP ::= SEQUENCE { 1969 wrap-header Wrap-Header, 1970 wrap-body Wrap-Body 1971 } 1973 Wrap-Header ::= SEQUENCE { 1974 tok-id INTEGER (513), -- shall contain 0201 (hex) 1975 context-id Random-Integer, 1976 int-alg [0] AlgorithmIdentifier OPTIONAL, 1977 conf-alg [1] Conf-Alg OPTIONAL, 1978 snd-seq [2] SeqNum OPTIONAL 1979 } 1981 Wrap-Body ::= SEQUENCE { 1982 int-cksum BIT STRING, 1983 data BIT STRING 1984 } 1986 Adams Document Expiration: 19 July 1996 38 1988 Conf-Alg ::= CHOICE { 1989 algId [0] AlgorithmIdentifier, 1990 null [1] NULL 1991 } 1993 SPKM-DEL ::= SEQUENCE { 1994 del-header Del-Header, 1995 int-cksum BIT STRING 1996 } 1998 Del-Header ::= SEQUENCE { 1999 tok-id INTEGER (769), -- shall contain 0301 (hex) 2000 context-id Random-Integer, 2001 int-alg [0] AlgorithmIdentifier OPTIONAL, 2002 snd-seq [1] SeqNum OPTIONAL 2003 } 2005 -- other types -- 2007 -- from [RFC-1508] -- 2009 MechType ::= OBJECT IDENTIFIER 2011 InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE { 2012 thisMech MechType, 2013 innerContextToken SPKMInnerContextToken 2014 } -- when thisMech is SPKM-1 or SPKM-2 2016 SPKMInnerContextToken ::= CHOICE { 2017 req [0] SPKM-REQ, 2018 rep-ti [1] SPKM-REP-TI, 2019 rep-it [2] SPKM-REP-IT, 2020 error [3] SPKM-ERROR, 2021 mic [4] SPKM-MIC, 2022 wrap [5] SPKM-WRAP, 2023 del [6] SPKM-DEL 2024 } 2026 -- from [RFC-1510] -- 2028 AuthorizationData ::= SEQUENCE OF SEQUENCE { 2029 ad-type INTEGER, 2030 ad-data OCTET STRING 2031 } 2033 -- object identifier assignments -- 2035 md5-DES-CBC OBJECT IDENTIFIER ::= 2036 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 2037 integrity(3) md5-DES-CBC(1)} 2039 Adams Document Expiration: 19 July 1996 39 2041 sum64-DES-CBC OBJECT IDENTIFIER ::= 2042 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 2043 integrity(3) sum64-DES-CBC(2)} 2045 spkm-1 OBJECT IDENTIFIER ::= 2046 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 2047 mechanisms(5) spkm(1) spkm-1(1)} 2049 spkm-2 OBJECT IDENTIFIER ::= 2050 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 2051 mechanisms(5) spkm(1) spkm-2(2)} 2053 END 2055 Appendix B: Imported Types 2057 This appendix contains, for completeness, the relevant ASN.1 types 2058 imported from InformationFramework (1993), AuthenticationFramework 2059 (1993), and [PKCS3]. 2061 AttributeType ::= OBJECT IDENTIFIER 2062 AttributeValue ::= ANY 2063 AttributeValueAssertion ::= SEQUENCE {AttributeType,AttributeValue} 2064 RelativeDistinguishedName ::= SET OF AttributeValueAssertion 2065 -- note that the 1993 InformationFramework module uses 2066 -- different syntax for the above constructs 2067 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 2068 DistinguishedName ::= RDNSequence 2069 Name ::= CHOICE { -- only one for now 2070 rdnSequence RDNSequence 2071 } 2073 Certificate ::= SEQUENCE { 2074 certContents CertContents, 2075 algID AlgorithmIdentifier, 2076 sig BIT STRING 2077 } -- sig holds the result of applying the signing procedure 2078 -- specified in algId to the BER-encoded octet string which 2079 -- results from applying the hashing procedure (also specified in 2080 -- algId) to the DER-encoded octets of CertContents 2082 CertContents ::= SEQUENCE { 2083 version [0] Version DEFAULT v1, 2084 serialNumber CertificateSerialNumber, 2085 signature AlgorithmIdentifier, 2086 issuer Name, 2087 validity Validity, 2088 subject Name, 2089 subjectPublicKeyInfo SubjectPublicKeyInfo, 2090 issuerUID [1] IMPLICIT UID OPTIONAL, -- used in v2 only 2091 subjectUID [2] IMPLICIT UID OPTIONAL -- used in v2 only 2092 } 2094 Adams Document Expiration: 19 July 1996 40 2096 Version ::= INTEGER {v1(0), v2(1)} 2097 CertificateSerialNumber ::= INTEGER 2098 UID ::= BIT STRING 2100 Validity ::= SEQUENCE { 2101 notBefore UTCTime, 2102 notAfter UTCTime 2103 } 2105 SubjectPublicKeyInfo ::= SEQUENCE { 2106 algorithm AlgorithmIdentifier, 2107 subjectPublicKey BIT STRING 2108 } 2110 CertificatePair ::= SEQUENCE { 2111 forward [0] Certificate OPTIONAL, 2112 reverse [1] Certificate OPTIONAL 2113 } -- at least one of the pair shall be present 2115 CertificateList ::= SEQUENCE { 2116 certListContents CertListContents, 2117 algId AlgorithmIdentifier, 2118 sig BIT STRING 2119 } -- sig holds the result of applying the signing procedure 2120 -- specified in algId to the BER-encoded octet string which 2121 -- results from applying the hashing procedure (also specified in 2122 -- algId) to the DER-encoded octets of CertListContents 2124 CertListContents ::= SEQUENCE { 2125 signature AlgorithmIdentifier, 2126 issuer Name, 2127 thisUpdate UTCTime, 2128 nextUpdate UTCTime OPTIONAL, 2129 revokedCertificates SEQUENCE OF SEQUENCE { 2130 userCertificate CertificateSerialNumber, 2131 revocationDate UTCTime } OPTIONAL 2132 } 2134 AlgorithmIdentifier ::= SEQUENCE { 2135 algorithm OBJECT IDENTIFIER, 2136 parameter ANY DEFINED BY algorithm OPTIONAL 2137 } -- note that the 1993 AuthenticationFramework module uses 2138 -- different syntax for this construct 2140 --from [PKCS3] (the parameter to be used with dhKeyAgreement) -- 2142 DHParameter ::= SEQUENCE { 2143 prime INTEGER, -- p 2144 base INTEGER, -- g 2145 privateValueLength INTEGER OPTIONAL 2146 } 2148 Adams Document Expiration: 19 July 1996 41