From 193e69bf8761b046e8ca39c606d49130e0389cd8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Love=20H=C3=B6rnquist=20=C3=85strand?= Date: Mon, 24 Nov 2003 22:17:15 +0000 Subject: [PATCH] x git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@13153 ec53bebd-3082-4978-b11e-865c3cabbd6b --- .../draft-ietf-cat-kerberos-pk-init-17.txt | 807 ++++++++++++++++ .../draft-ietf-krb-wg-gssapi-cfx-04.txt | 884 ++++++++++++++++++ 2 files changed, 1691 insertions(+) create mode 100644 doc/standardisation/draft-ietf-cat-kerberos-pk-init-17.txt create mode 100644 doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-04.txt diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-17.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-17.txt new file mode 100644 index 000000000..29c4ad6b2 --- /dev/null +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-17.txt @@ -0,0 +1,807 @@ + +INTERNET-DRAFT Brian Tung +draft-ietf-cat-kerberos-pk-init-17.txt Clifford Neuman +Updates: RFC 1510bis USC/ISI +expires May 31, 2004 Matthew Hur + Ari Medvinsky + Microsoft Corporation + Sasha Medvinsky + Motorola, Inc. + John Wray + Iris Associates, Inc. + Jonathan Trostle + + Public Key Cryptography for Initial Authentication in Kerberos + +0. Status Of This Memo + +This document is an Internet-Draft and is in full conformance with +all provision of Section 10 of RFC 2026. Internet-Drafts are +working documents of the Internet Engineering Task Force (IETF), its +areas, and its working groups. Note that other groups may also +distribute working documents as Internet-Drafts. + +Internet-Drafts are draft documents valid for a maximum of six +months and may be updated, replaced, or obsoleted by other documents +at any time. It is inappropriate to use Internet-Drafts as +reference material or to cite them other than as "work in progress." + +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt + +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html + +The distribution of this memo is unlimited. It is filed as +draft-ietf-cat-kerberos-pk-init-17.txt and expires May 31, 2004. +Please send comments to the authors. + + +1. Abstract + +This draft describes protocol extensions (hereafter called PKINIT) +to the Kerberos protocol specification (RFC 1510bis [1]). These +extensions provide a method for integrating public key cryptography +into the initial authentication exchange, by passing cryptographic +certificates and associated authenticators in preauthentication data +fields. + + +2. Introduction + +A client typically authenticates itself to a service in Kerberos +using three distinct though related exchanges. First, the client +requests a ticket-granting ticket (TGT) from the Kerberos +authentication server (AS). Then, it uses the TGT to request a +service ticket from the Kerberos ticket-granting server (TGS). +Usually, the AS and TGS are integrated in a single device known as +a Kerberos Key Distribution Center, or KDC. (In this draft, we will +refer to both the AS and the TGS as the KDC.) Finally, the client +uses the service ticket to authenticate itself to the service. + +The advantage afforded by the TGT is that the user need only +explicitly request a ticket and expose his credentials once. The +TGT and its associated session key can then be used for any +subsequent requests. One implication of this is that all further +authentication is independent of the method by which the initial +authentication was performed. Consequently, initial authentication +provides a convenient place to integrate public-key cryptography +into Kerberos authentication. + +As defined, Kerberos authentication exchanges use symmetric-key +cryptography, in part for performance. (Symmetric-key cryptography +is typically 10-100 times faster than public-key cryptography, +depending on the public-key operations. [c]) One cost of using +symmetric-key cryptography is that the keys must be shared, so that +before a user can authentication himself, he must already be +registered with the KDC. + +Conversely, public-key cryptography--in conjunction with an +established certification infrastructure--permits authentication +without prior registration. Adding it to Kerberos allows the +widespread use of Kerberized applications by users without requiring +them to register first--a requirement that has no inherent security +benefit. + +As noted above, a convenient and efficient place to introduce +public-key cryptography into Kerberos is in the initial +authentication exchange. This document describes the methods and +data formats for integrating public-key cryptography into Kerberos +initial authentication. Another document (PKCROSS) describes a +similar protocol for Kerberos cross-realm authentication. + + +3. Extensions + +This section describes extensions to RFC 1510bis for supporting the +use of public-key cryptography in the initial request for a ticket +granting ticket (TGT). + +Briefly, the following changes to RFC 1510bis are proposed: + + 1. If public-key authentication is indicated, the client sends + the user's public-key data and an authenticator in a + preauthentication field accompanying the usual request. + This authenticator is signed by the user's private + signature key. + + 2. The KDC verifies the client's request against its own + policy and certification authorities. + + 3. If the request passes the verification tests, the KDC + replies as usual, but the reply is encrypted using either: + + a. a randomly generated key, signed using the KDC's + signature key and encrypted using the user's encryption + key; or + + b. a key generated through a Diffie-Hellman exchange with + the client, signed using the KDC's signature key. + + Any key data required by the client to obtain the encryption + key is returned in a preauthentication field accompanying + the usual reply. + + 4. The client obtains the encryption key, decrypts the reply, + and then proceeds as usual. + +Section 3.1 of this document defines the necessary message formats. +Section 3.2 describes their syntax and use in greater detail. +Implementation of all specified formats and uses in these sections +is REQUIRED for compliance with PKINIT. + + +3.1. Definitions + + +3.1.1. Required Algorithms + +[What is the current list of required algorithm? --brian] + + +3.1.2. Defined Message and Encryption Types + +PKINIT makes use of the following new preauthentication types: + + PA-PK-AS-REQ TBD + PA-PK-AS-REP TBD + +PKINIT introduces the following new error types: + + KDC_ERR_CLIENT_NOT_TRUSTED 62 + KDC_ERR_KDC_NOT_TRUSTED 63 + KDC_ERR_INVALID_SIG 64 + KDC_ERR_KEY_TOO_WEAK 65 + KDC_ERR_CERTIFICATE_MISMATCH 66 + KDC_ERR_CANT_VERIFY_CERTIFICATE 70 + KDC_ERR_INVALID_CERTIFICATE 71 + KDC_ERR_REVOKED_CERTIFICATE 72 + KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 + KDC_ERR_CLIENT_NAME_MISMATCH 75 + +PKINIT uses the following typed data types for errors: + + TD-DH-PARAMETERS 102 + TD-TRUSTED-CERTIFIERS 104 + TD-CERTIFICATE-INDEX 105 + +PKINIT defines the following encryption types, for use in the AS-REQ +message (to indicate acceptance of the corresponding encryption OIDs +in PKINIT): + + dsaWithSHA1-CmsOID 9 + md5WithRSAEncryption-CmsOID 10 + sha1WithRSAEncryption-CmsOID 11 + rc2CBC-EnvOID 12 + rsaEncryption-EnvOID (PKCS1 v1.5) 13 + rsaES-OAEP-ENV-OID (PKCS1 v2.0) 14 + des-ede3-cbc-Env-OID 15 + +The above encryption types are used (in PKINIT) only within CMS [8] +structures within the PKINIT preauthentication fields. Their use +within Kerberos EncryptedData structures is unspecified. + + +3.1.3. Algorithm Identifiers + +PKINIT does not define, but does make use of, the following +algorithm identifiers. + +PKINIT uses the following algorithm identifier for Diffie-Hellman +key agreement [11]: + + dhpublicnumber + +PKINIT uses the following signature algorithm identifiers [8, 12]: + + sha-1WithRSAEncryption (RSA with SHA1) + md5WithRSAEncryption (RSA with MD5) + id-dsa-with-sha1 (DSA with SHA1) + +PKINIT uses the following encryption algorithm identifiers [12] for +encrypting the temporary key with a public key: + + rsaEncryption (PKCS1 v1.5) + id-RSAES-OAEP (PKCS1 v2.0) + +These OIDs are not to be confused with the encryption types listed +above. + +PKINIT uses the following algorithm identifiers [8] for encrypting +the reply key with the temporary key: + + des-ede3-cbc (three-key 3DES, CBC mode) + rc2-cbc (RC2, CBC mode) + +Again, these OIDs are not to be confused with the encryption types +listed above. + + +3.2. PKINIT Preauthentication Syntax and Use + +In this section, we describe the syntax and use of the various +preauthentication fields employed to implement PKINIT. + + +3.2.1. Client Request + +The initial authentication request (AS-REQ) is sent as per RFC +1510bis, except that a preauthentication field containing data +signed by the user's private signature key accompanies the request, +as follows: + + PA-PK-AS-REQ ::= SEQUENCE { + -- PAType TBD + signedAuthPack [0] ContentInfo, + -- Defined in CMS. + -- Type is SignedData. + -- Content is AuthPack + -- (defined below). + trustedCertifiers [1] SEQUENCE OF TrustedCAs OPTIONAL, + -- A list of CAs, trusted by + -- the client, used to certify + -- KDCs. + kdcCert [2] IssuerAndSerialNumber OPTIONAL, + -- Defined in CMS. + -- Identifies a particular KDC + -- certificate, if the client + -- already has it. + encryptionCert [3] IssuerAndSerialNumber OPTIONAL, + -- May identify the user's + -- Diffie-Hellman certificate, + -- or an RSA encryption key + -- certificate. + ... + } + + TrustedCAs ::= CHOICE { + caName [0] Name, + -- Fully qualified X.500 name + -- as defined in X.509 [11]. + issuerAndSerial [1] IssuerAndSerialNumber, + -- Identifies a specific CA + -- certificate, if the client + -- only trusts one. + ... + } + +[Should we even allow principalName as a choice? --brian] + + AuthPack ::= SEQUENCE { + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL + -- Defined in X.509, + -- reproduced below. + -- Present only if the client + -- is using ephemeral-ephemeral + -- Diffie-Hellman. + } + + PKAuthenticator ::= SEQUENCE { + cusec [0] INTEGER, + ctime [1] KerberosTime, + -- cusec and ctime are used as + -- in RFC 1510bis, for replay + -- prevention. + nonce [2] INTEGER, + -- Binds reply to request, + -- except is zero when client + -- will accept cached + -- Diffie-Hellman parameters + -- from KDC and MUST NOT be + -- zero otherwise. + paChecksum [3] Checksum, + -- Defined in RFC 1510bis. + -- Performed over KDC-REQ-BODY, + -- must be unkeyed. + ... + } + + SubjectPublicKeyInfo ::= SEQUENCE { + -- As defined in X.509. + algorithm AlgorithmIdentifier, + -- Equals dhpublicnumber (see + -- AlgorithmIdentifier, below) + -- for PKINIT. + subjectPublicKey BIT STRING + -- Equals public exponent + -- (INTEGER encoded as payload + -- of BIT STRING) for PKINIT. + } + + AlgorithmIdentifier ::= SEQUENCE { + -- As defined in X.509. + algorithm OBJECT IDENTIFIER, + -- dhpublicnumber is + -- { iso (1) member-body (2) + -- US (840) ansi-x942 (10046) + -- number-type (2) 1 } + -- From RFC 2459 [11]. + parameters ANY DEFINED BY algorithm OPTIONAL + -- Content is DomainParameters + -- (see below) for PKINIT. + } + + DomainParameters ::= SEQUENCE { + -- As defined in RFC 2459. + p INTEGER, + -- p is the odd prime, equals + -- jq+1. + g INTEGER, + -- Generator. + q INTEGER, + -- Divides p-1. + j INTEGER OPTIONAL, + -- Subgroup factor. + validationParms ValidationParms OPTIONAL + } + + ValidationParms ::= SEQUENCE { + -- As defined in RFC 2459. + seed BIT STRING, + -- Seed for the system parameter + -- generation process. + pgenCounter INTEGER + -- Integer value output as part + -- of the system parameter + -- generation process. + } + +The ContentInfo in the signedAuthPack is filled out as follows: + + 1. The eContent field contains data of type AuthPack. It MUST + contain the pkAuthenticator, and MAY also contain the + user's Diffie-Hellman public value (clientPublicValue). + + 2. The eContentType field MUST contain the OID value for + pkauthdata: { iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)} + + 3. The signerInfos field MUST contain the signature of the + AuthPack. + + 4. The certificates field MUST contain at least a signature + verification certificate chain that the KDC can use to + verify the signature on the AuthPack. Additionally, the + client may also insert an encryption certificate chain, if + (for example) the client is not using ephemeral-ephemeral + Diffie-Hellman. + + 5. If a Diffie-Hellman key is being used, the parameters SHOULD + be chosen from the First or Second defined Oakley Groups. + (See RFC 2409 [c].) + + 6. The KDC may wish to use cached Diffie-Hellman parameters. + To indicate acceptance of caching, the client sends zero in + the nonce field of the pkAuthenticator. Zero is not a valid + value for this field under any other circumstances. Since + zero is used to indicate acceptance of cached parameters, + message binding in this case is performed instead using the + nonce in the main request. + + +3.2.2. Validation of Client Request + +Upon receiving the client's request, the KDC validates it. This +section describes the steps that the KDC MUST (unless otherwise +noted) take in validating the request. + +The KDC must look for a user certificate in the signedAuthPack. +If it cannot find one signed by a CA it trusts, it sends back an +error of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying +e-data for this error is a SEQUENCE OF TypedData: + + TypedData ::= SEQUENCE { + -- As defined in RFC 1510bis. + data-type [0] INTEGER, + data-value [1] OCTET STRING + } + +For this error, the data-type is TD-TRUSTED-CERTIFIERS, and the +data-value is an OCTET STRING containing the DER encoding of + + TrustedCertifiers ::= SEQUENCE OF Name + +If, while verifying the certificate chain, the KDC determines that +the signature on one of the certificates in the signedAuthPack is +invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE. +The accompanying e-data for this error is a SEQUENCE OF TypedData, +whose data-type is TD-CERTIFICATE-INDEX, and whose data-value is an +OCTET STRING containing the DER encoding of the index into the +CertificateSet field, ordered as sent by the client: + + CertificateIndex ::= INTEGER + -- 0 = first certificate (in + -- order of encoding), + -- 1 = second certificate, etc. + +If more than one signature is invalid, the KDC sends one TypedData +per invalid signature. + +The KDC MAY also check whether any of the certificates in the user's +chain have been revoked. If any of them have been revoked, the KDC +returns an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC +attempts to determine the revocation status but is unable to do so, +it returns an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN. In +either case, the certificate or certificates affected are identified +exactly as for an error of type KDC_ERR_INVALID_CERTIFICATE (see +above). + +If the certificate chain is successfully validated, but the name in +the user's certificate does not match the name given in the request, +the KDC returns an error of type KDC_ERR_CLIENT_NAME_MISMATCH. There +is no accompanying e-data for this error. + +Even if the chain is validated, and the names in the certificate and +the request match, the KDC may decide not to trust the client. For +example, the certificate may include (or not include) an Enhanced +Key Usage (EKU) OID in the extensions field. As a matter of local +policy, the KDC may decide to reject requests on the basis of the +absence or presence of specific EKU OIDs. In this case, the KDC +returns an error of type KDC_ERR_CLIENT_NOT_TRUSTED. For the +benefit of implementors, we define a PKINIT EKU OID as follows: +{ iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2) +pkinit (3) pkekuoid (2) }. + +If the certificate chain and usage check out, but the client's +signature on the signedAuthPack fails to verify, the KDC returns an +error of type KDC_ERR_INVALID_SIG. There is no accompanying e-data +for this error. + +[What about the case when all this checks out but one or more +certificates is rejected for other reasons? For example, perhaps +the key is too short for local policy. --DRE] + +The KDC must check the timestamp to ensure that the request is not +a replay, and that the time skew falls within acceptable limits. If +the check fails, the KDC returns an error of type KRB_AP_ERR_REPEAT +or KRB_AP_ERR_SKEW, respectively. + +Finally, if the clientPublicValue is filled in, indicating that the +client wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC +checks to see if the parameters satisfy its policy. If they do not, +it returns an error of type KDC_ERR_KEY_TOO_WEAK. The accompanying +e-data is a SEQUENCE OF TypedData, whose data-type is +TD-DH-PARAMETERS, and whose data-value is an OCTET STRING containing +the DER encoding of a DomainParameters (see above), including +appropriate Diffie-Hellman parameters with which to retry the +request. + +[This makes no sense. For example, maybe the key is too strong for +local policy. --DRE] + +In order to establish authenticity of the reply, the KDC will sign +some key data (either the random key used to encrypt the reply in +the case of a KDCDHKeyInfo, or the Diffie-Hellman parameters used to +generate the reply-encrypting key in the case of a ReplyKeyPack). +The signature certificate to be used is to be selected as follows: + + 1. If the client included a kdcCert field in the PA-PK-AS-REQ, + use the referred-to certificate, if the KDC has it. If it + does not, the KDC returns an error of type + KDC_ERR_CERTIFICATE_MISMATCH. + + 2. Otherwise, if the client did not include a kdcCert field, + but did include a trustedCertifiers field, and the KDC + possesses a certificate issued by one of the listed + certifiers, use that certificate. if it does not possess + one, it returns an error of type KDC_ERR_KDC_NOT_TRUSTED. + + 3. Otherwise, if the client included neither a kdcCert field + nor a trustedCertifiers field, and the KDC has only one + signature certificate, use that certificate. If it has + more than one certificate, it returns an error of type + KDC_ERR_CERTIFICATE_MISMATCH. + + +3.2.3. KDC Reply + +Assuming that the client's request has been properly validated, the +KDC proceeds as per RFC 1510bis, except as follows. + +The user's name as represented in the AS-REP must be derived from +the certificate provided in the client's request. If the KDC has +its own mapping from the name in the certificate to a Kerberos name, +it uses that Kerberos name. + +Otherwise, if the certificate contains a subjectAltName extension +with PrincipalName, it uses that name. In this case, the realm in +the ticket is that of the local realm (or some other realm name +chosen by that realm). (OID and syntax for this extension to be +specified here.) Otherwise, the KDC returns an error of type +KDC_ERR_CLIENT_NAME_MISMATCH. + +In addition, the certifiers in the certification path of the user's +certificate MUST be added to an authdata (to be specified at a later +time). + +The AS-REP is otherwise unchanged from RFC 1510bis. The KDC then +encrypts the reply as usual, but not with the user's long-term key. +Instead, it encrypts it with either a random encryption key, or a +key derived through a Diffie-Hellman exchange. Which is the case is +indicated by the contents of the PA-PK-AS-REP (note tags): + + PA-PK-AS-REP ::= CHOICE { + -- PAType YY (TBD) + dhSignedData [0] ContentInfo, + -- Type is SignedData. + -- Content is KDCDHKeyInfo + -- (defined below). + encKeyPack [1] ContentInfo, + -- Type is EnvelopedData. + -- Content is ReplyKeyPack + -- (defined below). + ... + } + +Note that PA-PK-AS-REP is a CHOICE: either a dhSignedData, or an +encKeyPack, but not both. The former contains data of type +KDCDHKeyInfo, and is used only when the reply is encrypted using a +Diffie-Hellman derived key: + + KDCDHKeyInfo ::= SEQUENCE { + subjectPublicKey [0] BIT STRING, + -- Equals public exponent + -- (g^a mod p). + -- INTEGER encoded as payload + -- of BIT STRING. + nonce [1] INTEGER, + -- Binds reply to request. + -- Exception: A value of zero + -- indicates that the KDC is + -- using cached values. + dhKeyExpiration [2] KerberosTime OPTIONAL, + -- Expiration time for KDC's + -- cached values. + ... + } + +The fields of the ContentInfo for dhSignedData are to be filled in +as follows: + + 1. The eContent field contains data of type KDCDHKeyInfo. + + 2. The eContentType field contains the OID value for + pkdhkeydata: { iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2) } + + 3. The signerInfos field contains a single signerInfo, which is + the signature of the KDCDHKeyInfo. + + 4. The certificates field contains a signature verification + certificate chain that the client may use to verify the + KDC's signature over the KDCDHKeyInfo.) It may only be left + empty if the client did not include a trustedCertifiers + field in the PA-PK-AS-REQ, indicating that it has the KDC's + certificate. + + 5. If the client and KDC agree to use cached parameters, the + KDC SHOULD return a zero in the nonce field and include the + expiration time of the cached values in the dhKeyExpiration + field. If this time is exceeded, the client SHOULD NOT use + the reply. If the time is absent, the client SHOULD NOT use + the reply and MAY resubmit a request with a non-zero nonce, + thus indicating non-acceptance of the cached parameters. + +The key is derived as follows: Both the KDC and the client calculate +the value g^(ab) mod p, where a and b are the client and KDC's +private exponents, respectively. They both take the first N bits of +this secret value and convert it into a reply key, where N depends +on the key type. + + 1. For example, if the key type is DES, N = 64 bits, where some + of the bits are replaced with parity bits, according to FIPS + PUB 74 [c]. + + 2. If the key type is (three-key) 3DES, N = 192 bits, where + some of the bits are replaced with parity bits, again + according to FIPS PUB 74. + +If the KDC and client are not using Diffie-Hellman, the KDC encrypts +the reply with an encryption key, packed in the encKeyPack, which +contains data of type ReplyKeyPack: + + ReplyKeyPack ::= SEQUENCE { + replyKey [0] EncryptionKey, + -- Defined in RFC 1510bis. + -- Used to encrypt main reply. + -- MUST be at least as strong as + -- enctype of session key. + nonce [1] INTEGER, + -- Binds reply to request. + ... + } + +[What exactly does "at least as strong" mean? --DRE] + +The fields of the ContentInfo for encKeyPack MUST be filled in as +follows: + + 1. The innermost data is of type SignedData. The eContent for + this data is of type ReplyKeyPack. + + 2. The eContentType for this data contains the OID value for + pkrkeydata: { iso (1) org (3) dod (6) internet (1) + security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3) } + + 3. The signerInfos field contains a single signerInfo, which is + the signature of the ReplyKeyPack. + + 4. The certificates field contains a signature verification + certificate chain, which the client may use to verify the + KDC's signature over the ReplyKeyPack.) It may only be left + empty if the client did not include a trustedCertifiers + field in the PA-PK-AS-REQ, indicating that it has the KDC's + certificate. + + 5. The outer data is of type EnvelopedData. The + encryptedContent for this data is the SignedData described + in items 1 through 4, above. + + 6. The encryptedContentType for this data contains the OID + value for id-signedData: { iso (1) member-body (2) us (840) + rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) } + + 7. The recipientInfos field is a SET which MUST contain exactly + one member of type KeyTransRecipientInfo. The encryptedKey + for this member contains the temporary key which is + encrypted using the client's public key. + + 8. Neither the unprotectedAttrs field nor the originatorInfo + field is required for PKINIT. + + +3.2.4. Validation of KDC Reply + +Upon receipt of the KDC's reply, the client proceeds as follows. If +the PA-PK-AS-REP contains a dhSignedData, the client obtains and +verifies the Diffie-Hellman parameters, and obtains the shared key +as described above. Otherwise, the message contains an encKeyPack, +and the client decrypts and verifies the temporary encryption key. +In either case, the client then decrypts the main reply with the +resulting key, and then proceeds as described in RFC 1510bis. + + +4. Security Considerations + +PKINIT raises certain security considerations beyond those that can +be regulated strictly in protocol definitions. We will address them +in this section. + +PKINIT extends the cross-realm model to the public-key +infrastructure. Anyone using PKINIT must be aware of how the +certification infrastructure they are linking to works. + +Also, as in standard Kerberos, PKINIT presents the possibility of +interactions between cryptosystems of varying strengths, and this +now includes public-key cryptosystems. Many systems, for example, +allow the use of 512-bit public keys. Using such keys to wrap data +encrypted under strong conventional cryptosystems, such as 3DES, may +be inappropriate. + +PKINIT calls for randomly generated keys for conventional +cryptosystems. Many such systems contain systematically "weak" +keys. For recommendations regarding these weak keys, see RFC +1510bis. + +Care should be taken in how certificates are chosen for the purposes +of authentication using PKINIT. Some local policies may require +that key escrow be applied for certain certificate types. People +deploying PKINIT should be aware of the implications of using +certificates that have escrowed keys for the purposes of +authentication. + +PKINIT does not provide for a "return routability" test to prevent +attackers from mounting a denial-of-service attack on the KDC by +causing it to perform unnecessary and expensive public-key +operations. Strictly speaking, this is also true of standard +Kerberos, although the potential cost is not as great, because +standard Kerberos does not make use of public-key cryptography. + + +5. Acknowledgements + +Some of the ideas on which this proposal is based arose during +discussions over several years between members of the SAAG, the IETF +CAT working group, and the PSRG, regarding integration of Kerberos +and SPX. Some ideas have also been drawn from the DASS system. +These changes are by no means endorsed by these groups. This is an +attempt to revive some of the goals of those groups, and this +proposal approaches those goals primarily from the Kerberos +perspective. Lastly, comments from groups working on similar ideas +in DCE have been invaluable. + + +6. Expiration Date + +This draft expires May 31, 2004. + + +7. Bibliography + +[1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service +(V5). Request for Comments 1510. + +[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service +for Computer Networks, IEEE Communications, 32(9):33-38. September +1994. + +[3] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos +Using Public Key Cryptography. Symposium On Network and Distributed +System Security, 1997. + +[4] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction +Protocol. In Proceedings of the USENIX Workshop on Electronic +Commerce, July 1995. + +[5] T. Dierks, C. Allen. The TLS Protocol, Version 1.0. Request +for Comments 2246, January 1999. + +[6] B.C. Neuman, Proxy-Based Authorization and Accounting for +Distributed Systems. In Proceedings of the 13th International +Conference on Distributed Computing Systems, May 1993. + +[7] ITU-T (formerly CCITT) Information technology - Open Systems +Interconnection - The Directory: Authentication Framework +Recommendation X.509 ISO/IEC 9594-8 + +[8] R. Housley. Cryptographic Message Syntax. +draft-ietf-smime-cms-13.txt, April 1999, approved for publication as +RFC. + +[9] PKCS #7: Cryptographic Message Syntax Standard. An RSA +Laboratories Technical Note Version 1.5. Revised November 1, 1993 + +[10] R. Rivest, MIT Laboratory for Computer Science and RSA Data +Security, Inc. A Description of the RC2(r) Encryption Algorithm. +March 1998. Request for Comments 2268. + +[11] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public +Key Infrastructure, Certificate and CRL Profile, January 1999. +Request for Comments 2459. + +[12] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography +Specifications, October 1998. Request for Comments 2437. + +[13] ITU-T (formerly CCITT) Information Processing Systems - Open +Systems Interconnection - Specification of Abstract Syntax Notation +One (ASN.1) Rec. X.680 ISO/IEC 8824-1 + +[14] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA +Laboratories Technical Note, Version 1.4, Revised November 1, 1993. + + +8. Authors + +Brian Tung +Clifford Neuman +USC Information Sciences Institute +4676 Admiralty Way Suite 1001 +Marina del Rey CA 90292-6695 +Phone: +1 310 822 1511 +E-mail: {brian,bcn}@isi.edu + +Matthew Hur +Ari Medvinsky +Microsoft Corporation +One Microsoft Way +Redmond WA 98052 +Phone: +1 425 707 3336 +E-mail: matthur@microsoft.com, arimed@windows.microsoft.com + +Sasha Medvinsky +Motorola, Inc. +6450 Sequence Drive +San Diego, CA 92121 ++1 858 404 2367 +E-mail: smedvinsky@motorola.com + +John Wray +Iris Associates, Inc. +5 Technology Park Dr. +Westford, MA 01886 +E-mail: John_Wray@iris.com + +Jonathan Trostle +E-mail: jtrostle@world.std.com + diff --git a/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-04.txt b/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-04.txt new file mode 100644 index 000000000..7d4071865 --- /dev/null +++ b/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-04.txt @@ -0,0 +1,884 @@ + + + Larry Zhu +Internet Draft Karthik Jaganathan +Updates: 1964 Microsoft +Category: Standards Track Sam Hartman +draft-ietf-krb-wg-gssapi-cfx-04.txt MIT + November 21, 2003 + Expires: May 21, 2004 + + The Kerberos Version 5 GSS-API Mechanism: Version 2 + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of [RFC-2026]. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. Internet-Drafts are draft documents valid for a maximum of + six months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +Abstract + + This memo defines protocols, procedures, and conventions to be + employed by peers implementing the Generic Security Service + Application Program Interface (GSS-API as specified in [RFC-2743]) + when using the Kerberos Version 5 mechanism (as specified in + [KRBCLAR]). + + [RFC-1964] is updated and incremental changes are proposed in + response to recent developments such as the introduction of Kerberos + crypto framework [KCRYPTO]. These changes support the inclusion of + new cryptosystems based on crypto profiles [KCRYPTO], by defining + new per-message tokens along with their encryption and checksum + algorithms. + +Conventions used in this document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC-2119]. + +1. Introduction + + + +Zhu Internet Draft 1 + Kerberos Version 5 GSS-API November 2003 + + + [KCRYPTO] defines a generic framework for describing encryption and + checksum types to be used with the Kerberos protocol and associated + protocols. + + [RFC-1964] describes the GSS-API mechanism for Kerberos Version 5. + It defines the format of context establishment, per-message and + context deletion tokens and uses algorithm identifiers for each + cryptosystem in per message and context deletion tokens. + + The approach taken in this document obviates the need for algorithm + identifiers. This is accomplished by using the same encryption + algorithm, specified by the crypto profile [KCRYPTO] for the session + key or subkey that is created during context negotiation, and its + required checksum algorithm. Message layouts of the per-message + tokens are therefore revised to remove algorithm indicators and also + to add extra information to support the generic crypto framework + [KCRYPTO]. + + Tokens transferred between GSS-API peers for security context + establishment are also described in this document. The data + elements exchanged between a GSS-API endpoint implementation and the + Kerberos KDC are not specific to GSS-API usage and are therefore + defined within [KRBCLAR] rather than within this specification. + + The new token formats specified in this memo MUST be used with all + "newer" encryption types [KRBCLAR] and MAY be used with "older" + encryption types, provided that the initiator and acceptor know, + from the context establishment, that they can both process these new + token formats. + + "Newer" encryption types are those which have been specified along + with or since the new Kerberos cryptosystem specification [KCRYPTO], + as defined in section 3.1.3 of [KRBCLAR]. The list of not-newer + encryption types is as follows [KCRYPTO]: + + Encryption Type Assigned Number + ---------------------------------------------- + des-cbc-crc 1 + des-cbc-md4 2 + des-cbc-md5 3 + des3-cbc-md5 5 + des3-cbc-sha1 7 + dsaWithSHA1-CmsOID 9 + md5WithRSAEncryption-CmsOID 10 + sha1WithRSAEncryption-CmsOID 11 + rc2CBC-EnvOID 12 + rsaEncryption-EnvOID 13 + rsaES-OAEP-ENV-OID 14 + des-ede3-cbc-Env-OID 15 + des3-cbc-sha1-kd 16 + rc4-hmac 23 + + Note that in this document, the term "little endian order" is used + for brevity to refer to the least-significant-octet-first encoding, + + +Zhu Internet Draft 2 + Kerberos Version 5 GSS-API November 2003 + + + while the term "big endian order" is for the most-significant-octet- + first encoding. + +2. Key Derivation for Per-Message Tokens + + To limit the exposure of a given key, [KCRYPTO] adopted "one-way" + "entropy-preserving" derived keys, for different purposes or key + usages, from a base key or protocol key. + + This document defines four key usage values below that are used to + derive a specific key for signing and sealing messages, from the + session key or subkey [KRBCLAR] created during the context + establishment. + + Name Value + ------------------------------------- + KG-USAGE-ACCEPTOR-SEAL 22 + KG-USAGE-ACCEPTOR-SIGN 23 + KG-USAGE-INITIATOR-SEAL 24 + KG-USAGE-INITIATOR-SIGN 25 + + When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is + used as the usage number in the key derivation function for deriving + keys to be used in MIC tokens, and KG-USAGE-ACCEPTOR-SEAL is used + for Wrap tokens; similarly when the sender is the context initiator, + KG-USAGE-INITIATOR-SIGN is used as the usage number in the key + derivation function for MIC tokens, KG-USAGE-INITIATOR-SEAL is used + for Wrap Tokens. Even if the Wrap token does not provide for + confidentiality the same usage values specified above are used. + + During the context initiation and acceptance sequence, the acceptor + MAY assert a subkey, and if so, subsequent messages MUST use this + subkey as the protocol key and these messages MUST be flagged as + "AcceptorSubkey" as described in section 4.2.2. + +3. Quality of Protection + + The GSS-API specification [RFC-2743] provides for Quality of + Protection (QOP) values that can be used by applications to request + a certain type of encryption or signing. A zero QOP value is used + to indicate the "default" protection; applications which do not use + the default QOP are not guaranteed to be portable across + implementations or even inter-operate with different deployment + configurations of the same implementation. Using an algorithm that + is different from the one for which the key is defined may not be + appropriate. Therefore, when the new method in this document is + used, the QOP value is ignored. + + The encryption and checksum algorithms in per-message tokens are now + implicitly defined by the algorithms associated with the session key + or subkey. Algorithms identifiers as described in [RFC-1964] are + therefore no longer needed and removed from the new token headers. + +4. Definitions and Token Formats + + +Zhu Internet Draft 3 + Kerberos Version 5 GSS-API November 2003 + + + + This section provides terms and definitions, as well as descriptions + for tokens specific to the Kerberos Version 5 GSS-API mechanism. + +4.1. Context Establishment Tokens + + All context establishment tokens emitted by the Kerberos V5 GSS-API + mechanism will have the framing shown below: + + GSS-API DEFINITIONS ::= + + BEGIN + + MechType ::= OBJECT IDENTIFIER + -- representing Kerberos V5 mechanism + + GSSAPI-Token ::= + -- option indication (delegation, etc.) indicated within + -- mechanism-specific token + [APPLICATION 0] IMPLICIT SEQUENCE { + thisMech MechType, + innerToken ANY DEFINED BY thisMech + -- contents mechanism-specific + -- ASN.1 structure not required + } + + END + + Where the notation and encoding of this pseudo ASN.1 header, which + is referred as the generic GSS-API token framing later in this + document, are described in [RFC-2743], and the innerToken field + starts with a two-octet token-identifier (TOK_ID) expressed in big + endian order, followed by a Kerberos message. + + Here are the TOK_ID values used in the context establishment tokens: + + Token TOK_ID Value in Hex + ----------------------------------------- + KRB_AP_REQUEST 01 00 + KRB_AP_REPLY 02 00 + KRB_ERROR 03 00 + + Where Kerberos message KRB_AP_REQUEST, KRB_AP_REPLY, and KRB_ERROR + are defined in [KRBCLAR]. + + If an unknown token identifier (TOK_ID) is received in the initial + context estalishment token, the receiver MUST return + GSS_S_CONTINUE_NEEDED major status, and the returned output token + MUST contain a KRB_ERROR message with the error code + KRB_AP_ERR_MSG_TYPE [KRBCLAR]. + +4.1.1. Authenticator Checksum + + +Zhu Internet Draft 4 + Kerberos Version 5 GSS-API November 2003 + + + The authenticator in the KRB_AP_REQ message MUST include the + optional sequence number and the checksum field. The checksum field + is used to convey service flags, channel bindings, and optional + delegation information. The checksum type MUST be 0x8003. The + length of the checksum MUST be 24 octets when delegation is not + used. When delegation is used, a ticket-granting ticket will be + transferred in a KRB_CRED message. This ticket SHOULD have its + forwardable flag set. The KRB_CRED message MUST be encrypted in the + session key of the ticket used to authenticate the context. + + The format of the authenticator checksum field is as follows. + + Octet Name Description + ----------------------------------------------------------------- + 0..3 Lgth Number of octets in Bnd field; Currently + contains hex value 10 00 00 00 (16, represented + in little-endian order) + 4..19 Bnd Channel binding information, as described in + section 4.1.1.2. + 20..23 Flags Four-octet context-establishment flags in little- + endian order as described in section 4.1.1.1. + 24..25 DlgOpt The Delegation Option identifier (=1) [optional] + 26..27 Dlgth The length of the Deleg field [optional] + 28..n Deleg A KRB_CRED message (n = Dlgth + 29) [optional] + +4.1.1.1. Checksum Flags Field + + The checksum "Flags" field is used to convey service options or + extension negotiation information. The following context + establishment flags are defined in [RFC-2744]. + + Flag Name Value + --------------------------------- + GSS_C_DELEG_FLAG 1 + GSS_C_MUTUAL_FLAG 2 + GSS_C_REPLAY_FLAG 4 + GSS_C_SEQUENCE_FLAG 8 + GSS_C_CONF_FLAG 16 + GSS_C_INTEG_FLAG 32 + + Context establishment flags are exposed to the calling application. + If the calling application desires a particular service option then + it requests that option via GSS_Init_sec_context() [RFC-2743]. An + implementation that supports a particular option or extension SHOULD + then set the appropriate flag in the checksum Flags field. + + The most significant eight bits of the checksum flags are reserved + for future use. The receiver MUST ignore unknown checksum flags. + +4.1.1.2. Channel Binding Information + + Channel bindings are user-specified tags to identify a given context + to the peer application. These tags are intended to be used to + + +Zhu Internet Draft 5 + Kerberos Version 5 GSS-API November 2003 + + + identify the particular communications channel that carries the + context [RFC-2743] [RFC-2744]. + + When using C language bindings, channel bindings are communicated to + the GSS-API using the following structure [RFC-2744]: + + typedef struct gss_channel_bindings_struct { + OM_uint32 initiator_addrtype; + gss_buffer_desc initiator_address; + OM_uint32 acceptor_addrtype; + gss_buffer_desc acceptor_address; + gss_buffer_desc application_data; + } *gss_channel_bindings_t; + + The member fields and constants used for different address types are + defined in [RFC-2744]. + + The "Bnd" field contains the MD5 hash of channel bindings, taken + over all non-null components of bindings, in order of declaration. + Integer fields within channel bindings are represented in little- + endian order for the purposes of the MD5 calculation. + + In computing the contents of the Bnd field, the following detailed + points apply: + + (1) Each integer field shall be formatted into four octets, using + little endian octet ordering, for purposes of MD5 hash computation. + + (2) All input length fields within gss_buffer_desc elements of a + gss_channel_bindings_struct even those which are zero-valued, shall + be included in the hash calculation; the value elements of + gss_buffer_desc elements shall be dereferenced, and the resulting + data shall be included within the hash computation, only for the + case of gss_buffer_desc elements having non-zero length specifiers. + + (3) If the caller passes the value GSS_C_NO_BINDINGS instead of a + valid channel binding structure, the Bnd field shall be set to 16 + zero-valued octets. + +4.2. Per-Message Tokens + + Two classes of tokens are defined in this section: "MIC" tokens, + emitted by calls to GSS_GetMIC() and consumed by calls to + GSS_VerifyMIC(), "Wrap" tokens, emitted by calls to GSS_Wrap() and + consumed by calls to GSS_Unwrap(). + + The new per-message tokens introduced here do not include the + generic GSS-API token framing used by the context establishment + tokens. These new tokens are designed to be used with newer crypto + systems that can, for example, have variable-size checksums. + +4.2.1. Sequence Number + + +Zhu Internet Draft 6 + Kerberos Version 5 GSS-API November 2003 + + + To distinguish intentionally-repeated messages from maliciously- + replayed ones, per-message tokens contain a sequence number field, + which is a 64 bit integer expressed in big endian order. After + sending a GSS_GetMIC() or GSS_Wrap() token, the sender's sequence + numbers are incremented by one. + +4.2.2. Flags Field + + The "Flags" field is a one-octet integer used to indicate a set of + attributes for the protected message. For example, one flag is + allocated as the direction-indicator, thus preventing an adversary + from sending back the same message in the reverse direction and + having it accepted. + + The meanings of bits in this field (the least significant bit is bit + 0) are as follows: + + Bit Name Description + --------------------------------------------------------------- + 0 SentByAcceptor When set, this flag indicates the sender + is the context acceptor. When not set, + it indicates the sender is the context + initiator. + 1 Sealed When set in Wrap tokens, this flag + indicates confidentiality is provided + for. It SHALL NOT be set in MIC tokens. + 2 AcceptorSubkey A subkey asserted by the context acceptor + is used to protect the message. + + The rest of available bits are reserved for future use and MUST be + cleared. The receiver MUST ignore unknown flags. + +4.2.3. EC Field + + The "EC" (Extra Count) field is a two-octet integer field expressed + in big endian order. + + In Wrap tokens with confidentiality, the EC field is used to encode + the number of octets in the filler, as described in section 4.2.4. + + In Wrap tokens without confidentiality, the EC field is used to + encode the number of octets in the trailing checksum, as described + in section 4.2.4. + +4.2.4. Encryption and Checksum Operations + + The encryption algorithms defined by the crypto profiles provide for + integrity protection [KCRYPTO]. Therefore no separate checksum is + needed. + + The result of decryption can be longer than the original plaintext + [KCRYPTO] and the extra trailing octets are called "crypto-system + garbage". However, given the size of any plaintext data, one can + always find the next (possibly larger) size so that, when padding + + +Zhu Internet Draft 7 + Kerberos Version 5 GSS-API November 2003 + + + the to-be-encrypted text to that size, there will be no crypto- + system garbage added [KCRYPTO]. + + In Wrap tokens that provide for confidentiality, the first 16 octets + of the Wrap token (the "header", as defined in section 4.2.6), are + appended to the plaintext data before encryption. Filler octets can + be inserted between the plaintext data and the "header", and the + values and size of the filler octets are chosen by implementations, + such that there is no crypto-system garbage present after the + decryption. The resulting Wrap token is {"header" | + encrypt(plaintext-data | filler | "header")}, where encrypt() is the + encryption operation (which provides for integrity protection) + defined in the crypto profile [KCRYPTO], and the RRC field in the + to-be-encrypted header contains the hex value 00 00. + + In Wrap tokens that do not provide for confidentiality, the checksum + is calculated first over the to-be-signed plaintext data, and then + the first 16 octets of the Wrap token (the "header", as defined in + section 4.2.6). Both the EC field and the RRC field in the token + header are filled with zeroes for the purpose of calculating the + checksum. The resulting Wrap token is {"header" | plaintext-data | + get_mic(plaintext-data | "header")}, where get_mic() is the + checksum operation for the required checksum mechanism of the chosen + encryption mechanism defined in the crypto profile [KCRYPTO]. + + The parameters for the key and the cipher-state in the encrypt() and + get_mic() operations have been omitted for brevity. + + For MIC tokens, the checksum is first calculated over the to-be- + signed plaintext data, and then the first 16 octets of the MIC + token, where the checksum mechanism is the required checksum + mechanism of the chosen encryption mechanism defined in the crypto + profile [KCRYPTO]. + + The resulting Wrap and MIC tokens bind the data to the token header, + including the sequence number and the direction indicator. + +4.2.5. RRC Field + + The "RRC" (Right Rotation Count) field in Wrap tokens is added to + allow the data to be encrypted in-place by existing [SSPI] + applications that do not provide an additional buffer for the + trailer (the cipher text after the in-place-encrypted data) in + addition to the buffer for the header (the cipher text before the + in-place-encrypted data). The resulting Wrap token in the previous + section, excluding the first 16 octets of the token header, is + rotated to the right by "RRC" octets. The net result is that "RRC" + octets of trailing octets are moved toward the header. Consider the + following as an example of this rotation operation: Assume that the + RRC value is 3 and the token before the rotation is {"header" | aa | + bb | cc | dd | ee | ff | gg | hh}, the token after rotation would be + {"header" | ff | gg | hh | aa | bb | cc | dd | ee }, where {aa | bb + | cc |...| hh} is used to indicate the octet sequence. + + +Zhu Internet Draft 8 + Kerberos Version 5 GSS-API November 2003 + + + The RRC field is expressed as a two-octet integer in big endian + order. + + The rotation count value is chosen by the sender based on + implementation details, and the receiver MUST be able to interpret + all possible rotation count values. + +4.2.6. Message Layouts + + Per-message tokens start with a two-octet token identifier (TOK_ID) + field, expressed in big endian order. These tokens are defined + separately in subsequent sub-sections. + +4.2.6.1. MIC Tokens + + Use of the GSS_GetMIC() call yields a token, separate from the user + data being protected, which can be used to verify the integrity of + that data as received. The token has the following format: + + Octet no Name Description + ----------------------------------------------------------------- + 0..1 TOK_ID Identification field. Tokens emitted by + GSS_GetMIC() contain the hex value 04 04 + expressed in big endian order in this field. + 2 Flags Attributes field, as described in section + 4.2.2. + 3..7 Filler Contains five octets of hex value FF. + 8..15 SND_SEQ Sequence number field in clear text, + expressed in big endian order. + 16..last SGN_CKSUM Checksum of octet 0..15 and the "to-be- + signed" data, as described in section 4.2.4. + + The Filler field is included in the checksum calculation for + simplicity. + +4.2.6.2. Wrap Tokens + + Use of the GSS_Wrap() call yields a token, which consists of a + descriptive header, followed by a body portion that contains either + the input user data in plaintext concatenated with the checksum, or + the input user data encrypted. The GSS_Wrap() token has the + following format: + + Octet no Name Description + --------------------------------------------------------------- + 0..1 TOK_ID Identification field. Tokens emitted by + GSS_Wrap() contain the the hex value 05 04 + expressed in big endian order in this field. + 2 Flags Attributes field, as described in section + 4.2.2. + 3 Filler Contains the hex value FF. + 4..5 EC Contains the "extra count" field, in big + endian order as described in section 4.2.3. + 6..7 RRC Contains the "right rotation count" in big + + +Zhu Internet Draft 9 + Kerberos Version 5 GSS-API November 2003 + + + endian order, as described in section 4.2.5. + 8..15 SND_SEQ Sequence number field in clear text, + expressed in big endian order. + 16..last Data Encrypted data for Wrap tokens with + confidentiality, or plaintext data followed + by the checksum for Wrap tokens without + confidentiality, as described in section + 4.2.4. + +4.3. Context Deletion Tokens + + Context deletion tokens are empty in this mechanism. Both peers to + a security context invoke GSS_Delete_sec_context() [RFC-2743] + independently, passing a null output_context_token buffer to + indicate that no context_token is required. Implementations of + GSS_Delete_sec_context() should delete relevant locally-stored + context information. + +4.4. Token Identifier Assignment Considerations + + Token identifiers (TOK_ID) from 0x60 0x00 through 0x60 0xFF + inclusive are reserved and SHALL NOT be assigned. Thus by examining + the first two octets of a token, one can tell unambiguously if it is + wrapped with the generic GSS-API token framing. + +5. Parameter Definitions + + This section defines parameter values used by the Kerberos V5 GSS- + API mechanism. It defines interface elements in support of + portability, and assumes use of C language bindings per [RFC-2744]. + +5.1. Minor Status Codes + + This section recommends common symbolic names for minor_status + values to be returned by the Kerberos V5 GSS-API mechanism. Use of + these definitions will enable independent implementers to enhance + application portability across different implementations of the + mechanism defined in this specification. (In all cases, + implementations of GSS_Display_status() will enable callers to + convert minor_status indicators to text representations.) Each + implementation should make available, through include files or other + means, a facility to translate these symbolic names into the + concrete values which a particular GSS-API implementation uses to + represent the minor_status values specified in this section. + + It is recognized that this list may grow over time, and that the + need for additional minor_status codes specific to particular + implementations may arise. It is recommended, however, that + implementations should return a minor_status value as defined on a + mechanism-wide basis within this section when that code is + accurately representative of reportable status rather than using a + separate, implementation-defined code. + +5.1.1. Non-Kerberos-specific codes + + +Zhu Internet Draft 10 + Kerberos Version 5 GSS-API November 2003 + + + + GSS_KRB5_S_G_BAD_SERVICE_NAME + /* "No @ in SERVICE-NAME name string" */ + GSS_KRB5_S_G_BAD_STRING_UID + /* "STRING-UID-NAME contains nondigits" */ + GSS_KRB5_S_G_NOUSER + /* "UID does not resolve to username" */ + GSS_KRB5_S_G_VALIDATE_FAILED + /* "Validation error" */ + GSS_KRB5_S_G_BUFFER_ALLOC + /* "Couldn't allocate gss_buffer_t data" */ + GSS_KRB5_S_G_BAD_MSG_CTX + /* "Message context invalid" */ + GSS_KRB5_S_G_WRONG_SIZE + /* "Buffer is the wrong size" */ + GSS_KRB5_S_G_BAD_USAGE + /* "Credential usage type is unknown" */ + GSS_KRB5_S_G_UNKNOWN_QOP + /* "Unknown quality of protection specified" */ + +5.1.2. Kerberos-specific-codes + + GSS_KRB5_S_KG_CCACHE_NOMATCH + /* "Client principal in credentials does not match + specified name" */ + GSS_KRB5_S_KG_KEYTAB_NOMATCH + /* "No key available for specified service principal" */ + GSS_KRB5_S_KG_TGT_MISSING + /* "No Kerberos ticket-granting ticket available" */ + GSS_KRB5_S_KG_NO_SUBKEY + /* "Authenticator has no subkey" */ + GSS_KRB5_S_KG_CONTEXT_ESTABLISHED + /* "Context is already fully established" */ + GSS_KRB5_S_KG_BAD_SIGN_TYPE + /* "Unknown signature type in token" */ + GSS_KRB5_S_KG_BAD_LENGTH + /* "Invalid field length in token" */ + GSS_KRB5_S_KG_CTX_INCOMPLETE + /* "Attempt to use incomplete security context" */ + +5.2. Buffer Sizes + + All implementations of this specification shall be capable of + accepting buffers of at least 16K octets as input to GSS_GetMIC(), + GSS_VerifyMIC(), and GSS_Wrap(), and shall be capable of accepting + the output_token generated by GSS_Wrap() for a 16K octet input + buffer as input to GSS_Unwrap(). Support for larger buffer sizes is + optional but recommended. + +6. Backwards Compatibility Considerations + + The new token formats defined in this document will only be + recognized by new implementations. To address this, implementations + can always use the explicit sign or seal algorithm in [RFC-1964] + + +Zhu Internet Draft 11 + Kerberos Version 5 GSS-API November 2003 + + + when the key type corresponds to "older" enctypes. An alternative + approach might be to retry sending the message with the sign or seal + algorithm explicitly defined as in [RFC-1964]. However this would + require either the use of a mechanism such as [RFC-2478] to securely + negotiate the method or the use out of band mechanism to choose + appropriate mechanism. For this reason, it is RECOMMENDED that the + new token formats defined in this document SHOULD be used only if + both peers are known to support the new mechanism during context + negotiation because of, for example, the use of "new" enctypes. + + GSS_Unwrap() or GSS_Verify_MIC() can process a message token as + follows: it can look at the first octet of the token header, if it + is 0x60 then the token must carry the generic GSS-API pseudo ASN.1 + framing, otherwise the first two octets of the token contain the + TOK_ID that uniquely identify the token message format. + +7. Security Considerations + + Under the current mechanism, no negotiation of algorithm types + occurs, so server-side (acceptor) implementations cannot request + that clients not use algorithm types not understood by the server. + However, administration of the server's Kerberos data (e.g., the + service key) has to be done in communication with the KDC, and it is + from the KDC that the client will request credentials. The KDC + could therefore be given the task of limiting session keys for a + given service to types actually supported by the Kerberos and GSSAPI + software on the server. + + This does have a drawback for cases where a service principal name + is used both for GSSAPI-based and non-GSSAPI-based communication + (most notably the "host" service key), if the GSSAPI implementation + does not understand (for example) AES [AES-KRB5] but the Kerberos + implementation does. It means that AES session keys cannot be + issued for that service principal, which keeps the protection of + non-GSSAPI services weaker than necessary. KDC administrators + desiring to limit the session key types to support interoperability + with such GSSAPI implementations should carefully weigh the + reduction in protection offered by such mechanisms against the + benefits of interoperability. + +8. Acknowledgments + + Ken Raeburn and Nicolas Williams corrected many of our errors in the + use of generic profiles and were instrumental in the creation of this + memo. + + The text for security considerations was contributed by Ken Raeburn. + + Sam Hartman and Ken Raeburn suggested the "floating trailer" idea, + namely the encoding of the RRC field. + + Sam Hartman and Nicolas Williams recommended the replacing our + earlier key derivation function for directional keys with different + + +Zhu Internet Draft 12 + Kerberos Version 5 GSS-API November 2003 + + + key usage numbers for each direction as well as retaining the + directional bit for maximum compatibility. + + Paul Leach provided numerous suggestions and comments. + + Scott Field, Richard Ward, Dan Simon, and Kevin Damour also provided + valuable inputs on this memo. + + Jeffrey Hutzelman provided comments on channel bindings and suggested + many editorial changes. + + Luke Howard provided implementations of this memo for the Heimdal + code base, and helped inter-operability testing with the Microsoft + code base, together with Love Hornquist Astrand. These experiments + formed the basis of this memo. + + Martin Rex provided suggestions of TOK_ID assignment recommendations + thus the token tagging in this memo is unambiguous if the token is + wrapped with the pseudo ASN.1 header. + + This document retains some of the text of RFC-1964 in relevant + sections. + +9. References + +9.1. Normative References + + [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, October 1996. + + [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC-2743] Linn, J., "Generic Security Service Application Program + Interface Version 2, Update 1", RFC 2743, January 2000. + + [RFC-2744] Wray, J., "Generic Security Service API Version 2: C- + bindings", RFC 2744, January 2000. + + [RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", + RFC 1964, June 1996. + + [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for + Kerberos 5", draft-ietf-krb-wg-crypto-05.txt, June, 2003. Work in + progress. + + [KRBCLAR] Neuman, C., Kohl, J., Ts'o T., Yu T., Hartman, S., + Raeburn, K., "The Kerberos Network Authentication Service (V5)", + draft-ietf-krb-wg-kerberos-clarifications-04.txt, February 2002. + Work in progress. + + [AES-KRB5] Raeburn, K., "AES Encryption for Kerberos 5", draft- + raeburn-krb-rijndael-krb-05.txt, June 2003. Work in progress. + + +Zhu Internet Draft 13 + Kerberos Version 5 GSS-API November 2003 + + + + [RFC-2478] Baize, E., Pinkas D., "The Simple and Protected GSS-API + Negotiation Mechanism", RFC 2478, December 1998. + +9.2. Informative References + + [SSPI] Leach, P., "Security Service Provider Interface", Microsoft + Developer Network (MSDN), April 2003. + +10. Author's Address + + Larry Zhu + One Microsoft Way + Redmond, WA 98052 - USA + EMail: LZhu@microsoft.com + + Karthik Jaganathan + One Microsoft Way + Redmond, WA 98052 - USA + EMail: karthikj@microsoft.com + + Sam Hartman + Massachusetts Institute of Technology + 77 Massachusetts Avenue + Cambridge, MA 02139 - USA + Email: hartmans@MIT.EDU + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhu Internet Draft 14 + Kerberos Version 5 GSS-API November 2003 + + + +Full Copyright Statement + + Copyright (C) The Internet Society (date). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph + are included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhu Internet Draft 15