diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-25.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-25.txt new file mode 100644 index 000000000..cb13ed0bb --- /dev/null +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-25.txt @@ -0,0 +1,1674 @@ + + +NETWORK WORKING GROUP B. Tung +Internet-Draft USC Information Sciences Institute +Expires: August 22, 2005 L. Zhu + Microsoft Corporation + February 18, 2005 + + + Public Key Cryptography for Initial Authentication in Kerberos + draft-ietf-cat-kerberos-pk-init-25 + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of Section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + 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. + + This Internet-Draft will expire on August 22, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document describes protocol extensions (hereafter called PKINIT) + to the Kerberos protocol specification. These extensions provide a + method for integrating public key cryptography into the initial + authentication exchange, by using asymmetric-key signature and/or + encryption algorithms in pre-authentication data fields. + + + +Tung & Zhu Expires August 22, 2005 [Page 1] + +Internet-Draft PKINIT February 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 + 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1 Definitions, Requirements, and Constants . . . . . . . . . 4 + 3.1.1 Required Algorithms . . . . . . . . . . . . . . . . . 4 + 3.1.2 Defined Message and Encryption Types . . . . . . . . . 5 + 3.1.3 Algorithm Identifiers . . . . . . . . . . . . . . . . 6 + 3.2 PKINIT Pre-authentication Syntax and Use . . . . . . . . . 6 + 3.2.1 Generation of Client Request . . . . . . . . . . . . . 6 + 3.2.2 Receipt of Client Request . . . . . . . . . . . . . . 10 + 3.2.3 Generation of KDC Reply . . . . . . . . . . . . . . . 13 + 3.2.4 Receipt of KDC Reply . . . . . . . . . . . . . . . . . 19 + 3.3 Interoperability Requirements . . . . . . . . . . . . . . 20 + 3.4 KDC Indication of PKINIT Support . . . . . . . . . . . . . 20 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 7.1 Normative References . . . . . . . . . . . . . . . . . . . 23 + 7.2 Informative References . . . . . . . . . . . . . . . . . . 24 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 + A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 25 + Intellectual Property and Copyright Statements . . . . . . . . 30 + + + + + + + + + + + + + + + + + + + + + + + + + + +Tung & Zhu Expires August 22, 2005 [Page 2] + +Internet-Draft PKINIT February 2005 + + +1. 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 document, both + the AS and the TGS are referred to 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 client exposes his + long-term secrets only once. The TGT and its associated session key + can then be used for any subsequent service ticket requests. One + result 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 in [CLAR], Kerberos authentication exchanges use + symmetric-key cryptography, in part for performance. One + disadvantage of using symmetric-key cryptography is that the keys + must be shared, so that before a client can authenticate itself, he + must already be registered with the KDC. + + Conversely, public-key cryptography (in conjunction with an + established Public Key Infrastructure) permits authentication without + prior registration with a KDC. Adding it to Kerberos allows the + widespread use of Kerberized applications by clients without + requiring them to register first with a KDC--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. + +2. 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 [RFC2119]. + + In this document, the encryption key used to encrypt the enc-part + field of the KDC-REP in the AS-REP [CLAR] is referred to as the KDC + AS reply key. + + + +Tung & Zhu Expires August 22, 2005 [Page 3] + +Internet-Draft PKINIT February 2005 + + +3. Extensions + + This section describes extensions to [CLAR] for supporting the use of + public-key cryptography in the initial request for a ticket. + + Briefly, this document defines the following extensions to [CLAR]: + + 1. The client indicates the use of public-key authentication by + including a special preauthenticator in the initial request. This + preauthenticator contains the client's public-key data and a + signature. + + 2. The KDC tests the client's request against its authentication + policy and trusted Certification Authorities (CAs). + + 3. If the request passes the verification tests, the KDC replies as + usual, but the reply is encrypted using either: + + a. a key generated through a Diffie-Hellman (DH) key exchange + [RFC2631][IEEE1363] with the client, signed using the KDC's + signature key; or + + b. a symmetric encryption key, signed using the KDC's signature + key and encrypted using the client's public key. + + Any keying material required by the client to obtain the + encryption key for decrypting the KDC reply is returned in a + pre-authentication field accompanying the usual reply. + + 4. The client validates the KDC's signature, obtains the encryption + key, decrypts the reply, and then proceeds as usual. + + Section 3.1 of this document enumerates the required algorithms and + necessary extension message types. Section 3.2 describes the + extension messages in greater detail. + +3.1 Definitions, Requirements, and Constants + +3.1.1 Required Algorithms + + All PKINIT implementations MUST support the following algorithms: + + o KDC AS reply key enctype: AES256-CTS-HMAC-SHA1-96 etype [RFC3961]. + + o Signature algorithm: sha-1WithRSAEncryption [RFC3279]. + + o KDC AS reply key delivery method: Diffie-Hellman key exchange + [RFC2631]. + + + +Tung & Zhu Expires August 22, 2005 [Page 4] + + + +3.1.2 Defined Message and Encryption Types + + PKINIT makes use of the following new pre-authentication types: + + PA_PK_AS_REQ 16 + PA_PK_AS_REP 17 + + PKINIT also makes use of the following new authorization data type: + + AD_INITIAL_VERIFIED_CAS 9 + + PKINIT introduces the following new error codes: + + KDC_ERR_CLIENT_NOT_TRUSTED 62 + KDC_ERR_INVALID_SIG 64 + KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65 + 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 + KDC_ERR_INCONSISTENT_KEY_PURPOSE 76 + + PKINIT uses the following typed data types for errors: + + TD_TRUSTED_CERTIFIERS 104 + TD_INVLID_CERTIFICATES 105 + TD_DH_PARAMETERS 109 + + PKINIT defines the following encryption types, for use in the AS-REQ + message to indicate acceptance of the corresponding algorithms that + can used by Cryptographic Message Syntax (CMS) [RFC3852] messages in + the reply: + + dsaWithSHA1-CmsOID 9 + md5WithRSAEncryption-CmsOID 10 + sha1WithRSAEncryption-CmsOID 11 + rc2CBC-EnvOID 12 + rsaEncryption-EnvOID (PKCS1 v1.5) 13 + rsaES-OAEP-EnvOID (PKCS1 v2.0) 14 + des-ede3-cbc-EnvOID 15 + + The ASN.1 module for all structures defined in this document (plus + IMPORT statements for all imported structures) is given in + Appendix A. + + All structures defined in or imported into this document MUST be + encoded using Distinguished Encoding Rules (DER) [X690] (unless + otherwise noted). All data structures carried in OCTET STRINGs must + + + +Tung & Zhu Expires August 22, 2005 [Page 5] + +Internet-Draft PKINIT February 2005 + + + be encoded according to the rules specified in corresponding + specifications. + + Interoperability note: Some implementations may not be able to decode + wrapped CMS objects encoded with BER but not DER; specifically, they + may not be able to decode infinite length encodings. To maximize + interoperability, implementers SHOULD encode CMS objects used in + PKINIT with DER. + +3.1.3 Algorithm Identifiers + + PKINIT does not define, but does make use of, the following algorithm + identifiers. + + PKINIT uses the following algorithm identifiers for Diffie-Hellman + key agreement [RFC3279]: + + dhpublicnumber (Diffie-Hellman modulo a prime p [RFC2631]) + id-ecPublicKey (Elliptic Curve Diffie-Hellman [IEEE1363]) + + PKINIT uses the following signature algorithm identifiers [RFC3279]: + + sha-1WithRSAEncryption (RSA with SHA1) + md5WithRSAEncryption (RSA with MD5) + id-dsa-with-sha1 (DSA with SHA1) + + PKINIT uses the following encryption algorithm identifiers [RFC3447] + for encrypting the temporary key with a public key: + + rsaEncryption (PKCS1 v1.5) + id-RSAES-OAEP (PKCS1 v2.0) + + PKINIT uses the following algorithm identifiers [RFC3370][RFC3565] + for encrypting the KDC AS reply key with the temporary key: + + des-ede3-cbc (three-key 3DES, CBC mode) + rc2-cbc (RC2, CBC mode) + id-aes256-CBC (AES-256, CBC mode) + + +3.2 PKINIT Pre-authentication Syntax and Use + + This section defines the syntax and use of the various + pre-authentication fields employed by PKINIT. + +3.2.1 Generation of Client Request + + The initial authentication request (AS-REQ) is sent as per [CLAR]; in + + + +Tung & Zhu Expires August 22, 2005 [Page 6] + +Internet-Draft PKINIT February 2005 + + + addition, a pre-authentication data element, whose padata-type is + PA_PK_AS_REQ and whose padata-value contains the DER encoding of the + type PA-PK-AS-REQ, is included. + + PA-PK-AS-REQ ::= SEQUENCE { + signedAuthPack [0] IMPLICIT OCTET STRING, + -- Contains a CMS type ContentInfo encoded + -- according to [RFC3852]. + -- The contentType field of the type ContentInfo + -- is id-signedData (1.2.840.113549.1.7.2), + -- and the content field is a SignedData. + -- The eContentType field for the type SignedData is + -- id-pkauthdata (1.3.6.1.5.2.3.1), and the + -- eContent field contains the DER encoding of the + -- type AuthPack. + -- AuthPack is defined below. + trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL, + -- A list of CAs, trusted by the client, that can + -- be used as the trust anchor to validate the KDC's + -- signature. + -- Each TrustedCA identifies a CA or a CA + -- certificate (thereby its public key). + kdcPkId [2] IMPLICIT OCTET STRING + OPTIONAL, + -- Contains a CMS type SignerIdentifier encoded + -- according to [RFC3852]. + -- Identifies, if present, a particular KDC + -- public key that the client already has. + ... + } + + DHNonce ::= OCTET STRING + + TrustedCA ::= SEQUENCE { + caName [0] IMPLICIT OCTET STRING, + -- Contains a PKIX type Name encoded according to + -- [RFC3280]. + -- Identifies a CA by the CA's distinguished subject + -- name. + certificateSerialNumber [1] INTEGER OPTIONAL, + -- Specifies the CA certificate's serial number. + -- The defintion of the certificate serial number + -- is taken from X.509 [X.509-97]. + subjectKeyIdentifier [2] OCTET STRING OPTIONAL, + -- Identifies the CA's public key by a key + -- identifier. When an X.509 certificate is + -- referenced, this key identifier matches the X.509 + -- subjectKeyIdentifier extension value. When other + + + +Tung & Zhu Expires August 22, 2005 [Page 7] + +Internet-Draft PKINIT February 2005 + + + -- certificate formats are referenced, the documents + -- that specify the certificate format and their use + -- with the CMS must include details on matching the + -- key identifier to the appropriate certificate + -- field. + ... + } + + AuthPack ::= SEQUENCE { + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, + -- Type SubjectPublicKeyInfo is defined in + -- [RFC3280]. + -- Specifies Diffie-Hellman domain parameters + -- and the client's public key value [IEEE1363]. + -- The public key value (the subjectPublicKey field + -- of the type SubjectPublicKeyInfo) MUST be encoded + -- according to [RFC3279]. + -- Present only if the client wishes to use the + -- Diffie-Hellman key agreement method. + supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier + OPTIONAL, + -- Type AlgorithmIdentifier is defined in + -- [RFC3280]. + -- List of CMS encryption types supported by the + -- client in order of (decreasing) preference. + clientDHNonce [3] DHNonce OPTIONAL, + -- Present only if the client indicates that it + -- wishes to reuse DH keys or to allow the KDC to + -- do so (see Section 3.2.3.1). + ... + } + + PKAuthenticator ::= SEQUENCE { + cusec [0] INTEGER (0..999999), + ctime [1] KerberosTime, + -- cusec and ctime are used as in [CLAR], for replay + -- prevention. + nonce [2] INTEGER (0..4294967295), + -- Chosen randomly; This nonce does not need to + -- match with the nonce in the KDC-REQ-BODY. + paChecksum [3] OCTET STRING, + -- Contains the SHA1 checksum, performed over + -- KDC-REQ-BODY. + ... + } + + The ContentInfo [RFC3852] structure for the signedAuthPack field is + + + +Tung & Zhu Expires August 22, 2005 [Page 8] + +Internet-Draft PKINIT February 2005 + + + filled out as follows: + + 1. The contentType field of the type ContentInfo is id-signedData + (as defined in [RFC3852]), and the content field is a SignedData + (as defined in [RFC3852]). + + 2. The eContentType field for the type SignedData is id-pkauthdata: + { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) + pkinit(3) pkauthdata(1) }. + + 3. The eContent field for the type SignedData contains the DER + encoding of the type AuthPack. + + 4. The signerInfos field of the type SignedData contains a single + signerInfo, which contains the signature over the type AuthPack. + + 5. The certificates field of the type SignedData contains + certificates intended to facilitate certification path + construction, so that the KDC can verify the signature over the + type AuthPack. For path validation, these certificates SHOULD be + sufficient to construct at least one certification path from the + client certificate to one trust anchor acceptable by the KDC + [CAPATH]. The certificates field MUST NOT contain "root" CA + certificates. + + 6. The client's Diffie-Hellman public value (clientPublicValue) is + included if and only if the client wishes to use the + Diffie-Hellman key agreement method. The Diffie-Hellman domain + parameters for the client's public key are specified in the + algorithm field of the type SubjectPublicKeyInfo + [IEEE1363][RFC3279] and the client's Diffie-Hellman public key + value is mapped to a subjectPublicKey (a BIT STRING) according to + [RFC3279]. When using the Diffie-Hellman key agreement method, + implementations MUST support Oakley 1024-bit MODP well-known + group 2 [RFC2412] and SHOULD support Oakley 2048-bit MODP + well-known group 14 and Oakley 4096-bit MODP well-known group 16 + [RFC3526]. + + The Diffie-Hellman field size should be chosen so as to provide + sufficient cryptographic security. The following table, based on + [LENSTRA], gives approximate comparable key sizes for symmetric- + and asymmetric-key cryptosystems based on the best-known + algorithms for attacking them. + + + + + + + + +Tung & Zhu Expires August 22, 2005 [Page 9] + +Internet-Draft PKINIT February 2005 + + + Symmetric | ECC | DH/DSA/RSA + -------------+---------+------------ + 80 | 163 | 1024 + 112 | 233 | 2048 + 128 | 283 | 3072 + 192 | 409 | 7680 + 256 | 571 | 15360 + + Table 1: Comparable key sizes (in bits) + + When Diffie-Hellma modulo a prime p is used, the exponents should + have at least twice as many bits as the symmetric keys that will + be derived from them [ODL99]. + + 7. The client may wish to reuse DH keys or to allow the KDC to do so + (see Section 3.2.3.1). If so, then the client includes the + clientDHNonce field. This nonce string needs to be as long as + the longest key length of the symmetric key types that the client + supports. This nonce MUST be chosen randomly. + + +3.2.2 Receipt 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 verifies the client's signature in the signedAuthPack field + according to [RFC3852]. + + If, while validating the client's X.509 certificate [RFC3280], the + KDC cannot build a certification path to validate the client's + certificate, it sends back a KRB-ERROR [CLAR] message with the code + KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for this + error message is a TYPED-DATA (as defined in [CLAR]) that contains an + element whose data-type is TD_TRUSTED_CERTIFIERS, and whose + data-value contains the DER encoding of the type + TD-TRUSTED-CERTIFIERS: + + TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA + -- Identifies a list of CAs trusted by the KDC. + -- Each TrustedCA identifies a CA or a CA + -- certificate (thereby its public key). + + Upon receiving this error message, the client SHOULD retry only if it + has a different set of certificates (from those of the previous + requests) that form a certification path (or a partial path) from one + of the trust anchors selected by the KDC to its own certificate. + + + +Tung & Zhu Expires August 22, 2005 [Page 10] + +Internet-Draft PKINIT February 2005 + + + If, while processing the certification path, the KDC determines that + the signature on one of the certificates in the signedAuthPack field + is invalid, it returns a KRB-ERROR [CLAR] message with the code + KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error + message is a TYPED-DATA that contains an element whose data-type is + TD_INVALID_CERTIFICATES, and whose data-value contains the DER + encoding of the type TD-INVALID-CERTIFICATES: + + TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING + -- Each OCTET STRING contains a CMS type + -- IssuerAndSerialNumber encoded according to + -- [RFC3852]. + -- Each IssuerAndSerialNumber indentifies a + -- certificate (sent by the client) with an invalid + -- signature. + + If more than one X.509 certificate signature is invalid, the KDC MAY + send one TYPED-DATA element per invalid signature. + + Based on local policy, the KDC may also check whether any X.509 + certificates in the certification path validating the client's + certificate have been revoked. If any of them have been revoked, the + KDC MUST return an error message with the code + KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the + revocation status but is unable to do so, it SHOULD return an error + message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN. The + certificate or certificates affected are identified exactly as for + the error code KDC_ERR_INVALID_CERTIFICATE (see above). + + The client's public key is then used to verify the signature. If the + signature fails to verify, the KDC MUST return an error message with + the code KDC_ERR_INVALID_SIG. There is no accompanying e-data for + this error message. + + In addition to validating the client's signature, the KDC MUST also + check that the client's public key used to verify the client's + signature is bound to the client's principal name as specified in the + AS-REQ as follows: + + 1. If the KDC has its own binding between either the client's + signature-verification public key or the client's certificate and + the client's Kerberos principal name, it uses that binding. + + 2. Otherwise, if the client's X.509 certificate contains a Subject + Alternative Name (SAN) extension [RFC3280] with a + KRB5PrincipalName (defined below) in the otherName field, it binds + the client's X.509 certificate to that name. + + + + +Tung & Zhu Expires August 22, 2005 [Page 11] + +Internet-Draft PKINIT February 2005 + + + The otherName field (of type AnotherName) in the SAN extension + MUST contain KRB5PrincipalName as defined below. + + The type-id field of the type AnotherName is id-pksan: + + id-pksan OBJECT IDENTIFIER ::= + { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) + x509-sanan (2) } + + The value field of the type AnotherName is the DER encoding of the + following ASN.1 type: + + KRB5PrincipalName ::= SEQUENCE { + realm [0] Realm, + principalName [1] PrincipalName + } + + If the KDC does not have its own binding and there is no + KRB5PrincipalName name present in the client's X.509 certificate, and + if the Kerberos name in the request does not match the + KRB5PrincipalName in the client's X.509 certificate (including the + realm name), the KDC MUST return an error message with the code + KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for + this error message. + + The KDC MAY require the presence of an Extended Key Usage (EKU) + KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the + client's X.509 certificate: + + id-pkekuoid OBJECT IDENTIFIER ::= + { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) + pkinit(3) pkekuoid(4) } + -- PKINIT client authentication. + -- Key usage bits that MUST be consistent: + -- digitalSignature; + -- Key usage bits that MAY be consistent: + -- nonRepudiation, and (keyEncipherment or keyAgreement). + + If this EKU is required but is missing, the KDC MUST return an error + message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There is no + accompanying e-data for this error message. KDCs implementing this + requirement SHOULD also accept the EKU KeyPurposeId id-ms-sc-logon + (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there are a + large number of X.509 client certificates deployed for use with + PKINIT which have this EKU. + + If for any other reasons, the client's public key is not accepted, + the KDC MUST return an error message with the code + + + +Tung & Zhu Expires August 22, 2005 [Page 12] + +Internet-Draft PKINIT February 2005 + + + KDC_ERR_CLIENT_NOT_TRUSTED. + + The KDC MUST check the timestamp to ensure that the request is not a + replay, and that the time skew falls within acceptable limits. The + recommendations for clock skew times in [CLAR] apply here. If the + check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or + KRB_AP_ERR_SKEW, respectively. + + If the clientPublicValue is filled in, indicating that the client + wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD + check to see if the key parameters satisfy its policy. If they do + not, it MUST return an error message with the code + KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a + TYPED-DATA that contains an element whose data-type is + TD_DH_PARAMETERS, and whose data-value contains the DER encoding of + the type TD-DH-PARAMETERS: + + TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier + -- Each AlgorithmIdentifier specifies a set of + -- Diffie-Hellman domain parameters [IEEE1363]. + -- This list is in decreasing preference order. + + TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters + that the KDC supports in decreasing preference order, from which the + client SHOULD pick one to retry the request. + + If the client included a kdcPkId field in the PA-PK-AS-REQ and the + KDC does not possess the corresponding key, the KDC MUST ignore the + kdcPkId field as if the client did not include one. + + If the client included a trustedCertifiers field, and the KDC does + not possesses the private key for any one of the listed certifiers, + the KDC MUST ignore the trustedCertifiers field as if the client did + not include any. + + If there is a supportedCMSTypes field in the AuthPack, the KDC must + check to see if it supports any of the listed types. If it supports + more than one of the types, the KDC SHOULD use the one listed first. + If it does not support any of them, it MUST return an error message + with the code KDC_ERR_ETYPE_NOSUPP [CLAR]. + +3.2.3 Generation of KDC Reply + + Assuming that the client's request has been properly validated, the + KDC proceeds as per [CLAR], except as follows. + + The KDC MUST set the initial flag and include an authorization data + element of ad-type [CLAR] AD_INITIAL_VERIFIED_CAS in the issued + + + +Tung & Zhu Expires August 22, 2005 [Page 13] + +Internet-Draft PKINIT February 2005 + + + ticket. The ad-data [CLAR] field contains the DER encoding of the + type AD-INITIAL-VERIFIED-CAS: + + AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA + -- Identifies the certification path based on which + -- the client certificate was validated. + -- Each TrustedCA identifies a CA or a CA + -- certificate (thereby its public key). + + The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT + containers if the list of CAs satisfies the AS' realm's local policy + (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag + [CLAR]). Furthermore, any TGS MUST copy such authorization data from + tickets used in a PA-TGS-REQ [CLAR] of the TGS-REQ to the resulting + ticket, and it can wrap or unwrap the data into or out-of the + AD-IF-RELEVANT container, depends on if the list of CAs satisfies the + TGS' realm's local policy. + + Application servers that understand this authorization data type + SHOULD apply local policy to determine whether a given ticket bearing + such a type *not* contained within an AD-IF-RELEVANT container is + acceptable. (This corresponds to the AP server checking the + transited field when the TRANSITED-POLICY-CHECKED flag has not been + set [CLAR].) If such a data type is contained within an + AD-IF-RELEVANT container, AP servers MAY apply local policy to + determine whether the authorization data is acceptable. + + The content of the AS-REP is otherwise unchanged from [CLAR]. The + KDC encrypts the reply as usual, but not with the client's long-term + key. Instead, it encrypts it with either a shared key derived from a + Diffie-Hellman exchange, or a generated encryption key. The contents + of the PA-PK-AS-REP indicate which key delivery method is used: + + PA-PK-AS-REP ::= CHOICE { + dhInfo [0] DHRepInfo, + -- Selected when Diffie-Hellman key exchange is + -- used. + encKeyPack [1] IMPLICIT OCTET STRING, + -- Selected when public key encryption is used. + -- Contains a CMS type ContentInfo encoded + -- according to [RFC3852]. + -- The contentType field of the type ContentInfo is + -- id-envelopedData (1.2.840.113549.1.7.3). + -- The content field is an EnvelopedData. + -- The contentType field for the type EnvelopedData + -- is id-signedData (1.2.840.113549.1.7.2). + -- The eContentType field for the inner type + -- SignedData (when unencrypted) is id-pkrkeydata + + + +Tung & Zhu Expires August 22, 2005 [Page 14] + +Internet-Draft PKINIT February 2005 + + + -- (1.2.840.113549.1.7.3) and the eContent field + -- contains the DER encoding of the type + -- ReplyKeyPack. + -- ReplyKeyPack is defined in Section 3.2.3.2. + ... + } + + DHRepInfo ::= SEQUENCE { + dhSignedData [0] IMPLICIT OCTET STRING, + -- Contains a CMS type ContentInfo encoded according + -- to [RFC3852]. + -- The contentType field of the type ContentInfo is + -- id-signedData (1.2.840.113549.1.7.2), and the + -- content field is a SignedData. + -- The eContentType field for the type SignedData is + -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the + -- eContent field contains the DER encoding of the + -- type KDCDHKeyInfo. + -- KDCDHKeyInfo is defined below. + serverDHNonce [1] DHNonce OPTIONAL + -- Present if and only if dhKeyExpiration is + -- present in the KDCDHKeyInfo. + } + + KDCDHKeyInfo ::= SEQUENCE { + subjectPublicKey [0] BIT STRING, + -- KDC's DH public key. + -- The DH pubic key value is mapped to a BIT STRING + -- according to [RFC3279]. + nonce [1] INTEGER (0..4294967295), + -- Contains the nonce in the PKAuthenticator of the + -- request if DH keys are NOT reused, + -- 0 otherwise. + dhKeyExpiration [2] KerberosTime OPTIONAL, + -- Expiration time for KDC's key pair, + -- present if and only if DH keys are reused. If + -- this field is omitted then the serverDHNonce + -- field MUST also be omitted. See Section 3.2.3.1. + ... + } + + +3.2.3.1 Using Diffie-Hellman Key Exchange + + In this case, the PA-PK-AS-REP contains a DHRepInfo structure. + + The ContentInfo [RFC3852] structure for the dhSignedData field is + filled in as follows: + + + +Tung & Zhu Expires August 22, 2005 [Page 15] + +Internet-Draft PKINIT February 2005 + + + 1. The contentType field of the type ContentInfo is id-signedData + (as defined in [RFC3852]), and the content field is a SignedData + (as defined in [RFC3852]). + + 2. The eContentType field for the type SignedData is the OID value + for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1) + security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }. + + 3. The eContent field for the type SignedData contains the DER + encoding of the type KDCDHKeyInfo. + + 4. The signerInfos field of the type SignedData contains a single + signerInfo, which contains the signature over the type + KDCDHKeyInfo. + + 5. The certificates field of the type SignedData contains + certificates intended to facilitate certification path + construction, so that the client can verify the KDC's signature + over the type KDCDHKeyInfo. This field may only be left empty if + the KDC public key specified by the kdcPkId field in the + PA-PK-AS-REQ was used for signing. Otherwise, for path + validation, these certificates SHOULD be sufficient to construct + at least one certification path from the KDC certificate to one + trust anchor acceptable by the client [CAPATH]. The certificates + field MUST NOT contain "root" CA certificates. + + 6. If the client included the clientDHNonce field, then the KDC may + choose to reuse its DH keys (see Section 3.2.3.1). If the server + reuses DH keys then it MUST include an expiration time in the + dhKeyExperiation field. Past the point of the expiration time, + the signature over the type DHRepInfo is considered + expired/invalid. When the server reuses DH keys then it MUST + include a serverDHNonce at least as long as the length of keys + for the symmetric encryption system used to encrypt the AS reply. + Note that including the serverDHNonce changes how the client and + server calculate the key to use to encrypt the reply; see below + for details. The KDC SHOULD NOT reuse DH keys unless the + clientDHNonce field is present in the request. + + The KDC AS reply key is derived as follows: + + 1. Both the KDC and the client calculate the shared secret value as + follows: + + a) When Diffie-Hellman modulo a prime p ([RFC2631]) is used, let + DHSharedSecret be the shared secret value. + + + + + +Tung & Zhu Expires August 22, 2005 [Page 16] + +Internet-Draft PKINIT February 2005 + + + b) When Elliptic Curve Diffie-Hellman (ECDH) (with each party + contributing one key pair) [IEEE1363] is used, let + DHSharedSecret be the x-coordinate of the shared secret value + (an elliptic curve point). + + DHSharedSecret is first padded with leading zeros such that the + size of DHSharedSecret in octets is the same as that of the + modulus, then represented as a string of octets in big-endian + order. + + Implementation note: Both the client and the KDC can cache the + triple (ya, yb, DHSharedSecret), where ya is the client's public + key and yb is the KDC's public key. If both ya and yb are the + same in a later exchange, the cached DHSharedSecret can be used. + + 2. Let K be the key-generation seed length [RFC3961] of the KDC AS + reply key whose enctype is selected according to [CLAR]. + + 3. Define the function octetstring2key() as follows: + + octetstring2key(x) == random-to-key(K-truncate( + SHA1(0x00 | x) | + SHA1(0x01 | x) | + SHA1(0x02 | x) | + ... + )) + + where x is an octet string; | is the concatenation operator; 0x00, + 0x01, 0x02, etc., are each represented as a single octet; + random-to-key() is an operation that generates a protocol key from + a bitstring of length K; and K-truncate truncates its input to the + first K bits. Both K and random-to-key() are as defined in the + kcrypto profile [RFC3961] for the enctype of the KDC AS reply key. + + 4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be + the serverDHNonce; otherwise, let both n_c and n_k be empty octet + strings. + + 5. The KDC AS reply key k is: + + k = octetstring2key(DHSharedSecret | n_c | n_k) + + +3.2.3.2 Using Public Key Encryption + + In this case, the PA-PK-AS-REP contains a ContentInfo structure + wrapped in an OCTET STRING. The KDC AS reply key is encrypted in the + encKeyPack field, which contains data of type ReplyKeyPack: + + + +Tung & Zhu Expires August 22, 2005 [Page 17] + +Internet-Draft PKINIT February 2005 + + + ReplyKeyPack ::= SEQUENCE { + replyKey [0] EncryptionKey, + -- Contains the session key used to encrypt the + -- enc-part field in the AS-REP. + nonce [1] INTEGER (0..4294967295), + -- Contains the nonce in the PKAuthenticator of the + -- request. + ... + } + + The ContentInfo [RFC3852] structure for the encKeyPack field is + filled in as follows: + + 1. The contentType field of the type ContentInfo is id-envelopedData + (as defined in [RFC3852]), and the content field is an + EnvelopedData (as defined in [RFC3852]). + + 2. The contentType field for the type EnvelopedData is + id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549) + pkcs (1) pkcs7 (7) signedData (2) }. + + 3. The eContentType field for the inner type SignedData (when + decrypted from the encryptedContent field for the type + EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6) + internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }. + + 4. The eContent field for the inner type SignedData contains the DER + encoding of the type ReplyKeyPack. + + 5. The signerInfos field of the inner type SignedData contains a + single signerInfo, which contains the signature over the type + ReplyKeyPack. + + 6. The certificates field of the inner type SignedData contains + certificates intended to facilitate certification path + construction, so that the client can verify the KDC's signature + over the type ReplyKeyPack. This field may only be left empty if + the KDC public key specified by the kdcPkId field in the + PA-PK-AS-REQ was used for signing. Otherwise, for path + validation, these certificates SHOULD be sufficient to construct + at least one certification path from the KDC certificate to one + trust anchor acceptable by the client [CAPATH]. The certificates + field MUST NOT contain "root" CA certificates. + + 7. The recipientInfos field of the type EnvelopedData is a SET which + MUST contain exactly one member of type KeyTransRecipientInfo. + The encryptedKey of this member contains the temporary key which + is encrypted using the client's public key. + + + +Tung & Zhu Expires August 22, 2005 [Page 18] + + + 8. The unprotectedAttrs or originatorInfo fields of the type + EnvelopedData MAY be present. + +3.2.4 Receipt of KDC Reply + + Upon receipt of the KDC's reply, the client proceeds as follows. If + the PA-PK-AS-REP contains the dhSignedData field, the client derives + the KDC AS reply key using the same procedure used by the KDC as + defined in Section 3.2.3.1. Otherwise, the message contains the + encKeyPack field, and the client decrypts and extracts the temporary + key in the encryptedKey field of the member KeyTransRecipientInfo, + and then uses that as the KDC AS reply key. + + In either case, the client MUST verify the signature in the + SignedData according to [RFC3852]. Unless the client can otherwise + prove that the public key used to verify the KDC's signature is bound + to the target KDC, the KDC's X.509 certificate MUST satisfy at least + one of the following two requirements: + + 1. The certificate contains a Subject Alternative Name (SAN) + extension [RFC3280] carrying a dNSName and that name value + matches the following name format: + + _Service._Proto.Realm + + Where the Service name is the string literal "kerberos", the + Proto can be "udp" or "tcp", and the Realm is the domain style + Kerberos realm name [CLAR] of the target KDC. This name format + is identical to the owner label format used in the DNS SRV + records for specifying the KDC location as described in [CLAR]. + For example, the X.509 certificate for the KDC of the Kerberos + realm "EXAMPLE.COM" would contain a dNSName value of + "_kerberos._tcp.EXAMPLE.COM" or "_kerberos._udp.EXAMPLE.COM". + + 2. The certificate contains the EKU KeyPurposeId [RFC3280] + id-pkkdcekuoid (defined below) and an SAN extension [RFC3280] + carrying an AnotherName whose type-id is id-pksan (as defined in + Section 3.2.2) and whose value contains a KRB5PrincipalName name, + and the realm name of that KRB5PrincipalName matches the realm + name of the target KDC. + + id-pkkdcekuoid OBJECT IDENTIFIER ::= + { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) + pkinit(3) pkkdcekuoid(5) } + -- Signing KDC responses. + -- Key usage bits that MUST be consistent: + -- digitalSignature. + + If no SAN id-pksan extension is present (but the id-pkkdcekuoid + EKU is) in the KDC's X.509 certificate, and the client has a + + + +Tung & Zhu Expires August 22, 2005 [Page 19] + +Internet-Draft PKINIT February 2005 + + + priori knowledge of the KDC's hostname (or IP address), the + client SHOULD accept the KDC's X.509 certificate if that + certificate contains an SAN extension carrying a dNSName and the + dNSName value matches the hostname (or the IP address) of the KDC + with which the client believes it is communicating. + + Matching rules used for the dNSName value are specified in [RFC3280]. + + If all applicable checks are satisfied, the client then decrypts the + enc-part field of the KDC-REP in the AS-REP using the KDC AS reply + key, and then proceeds as described in [CLAR]. + + Implementation note: CAs issuing KDC certificates SHOULD place all + "short" and "fully-qualified" Kerberos realm names of the KDC (one + per SAN extension) into the KDC certificate to allow maximum + flexibility. + +3.3 Interoperability Requirements + + The client MUST be capable of sending a set of certificates + sufficient to allow the KDC to construct a certification path for the + client's certificate, if the correct set of certificates is provided + through configuration or policy. + + If the client sends all the X.509 certificates on a certification + path to a trust anchor acceptable by the KDC, and the KDC can not + verify the client's public key otherwise, the KDC MUST be able to + process path validation for the client's certificate based on the + certificates in the request. + + The KDC MUST be capable of sending a set of certificates sufficient + to allow the client to construct a certification path for the KDC's + certificate, if the correct set of certificates is provided through + configuration or policy. + + If the KDC sends all the X.509 certificates on a certification path + to a trust anchor acceptable by the client, and the client can not + verify the KDC's public key otherwise, the client MUST be able to + process path validation for the KDC's certificate based on the + certificates in the reply. + +3.4 KDC Indication of PKINIT Support + + If pre-authentication is required, but was not present in the + request, per [CLAR] an error message with the code + KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be + stored in the e-data field of the KRB-ERROR message to specify which + pre-authentication mechanisms are acceptable. The KDC can then + + + +Tung & Zhu Expires August 22, 2005 [Page 20] + +Internet-Draft PKINIT February 2005 + + + indicate the support of PKINIT by including an empty element whose + padata-type is PA_PK_AS_REQ in that METHOD-DATA object. + + Otherwise if it is required by the KDC's local policy that the client + must be pre-authenticated using the pre-authentication mechanism + specified in this document, but no PKINIT pre-authentication was + present in the request, an error message with the code + KDC_ERR_PREAUTH_FAILED SHOULD be returned. + + KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in + the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET + STRING), and clients MUST ignore this and any other value. Future + extensions to this protocol may specify other data to send instead of + an empty OCTET STRING. + +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. Users of PKINIT must understand security policies + and procedures appropriate to the use of Public Key Infrastructures + [RFC3280]. + + Standard Kerberos allows the possibility of interactions between + cryptosystems of varying strengths; this document adds interactions + with public-key cryptosystems to Kerberos. Some administrative + policies may allow the use of relatively weak public keys. Using + such keys to wrap data encrypted under stronger conventional + cryptosystems may be inappropriate. + + PKINIT requires keys for symmetric cryptosystems to be generated. + Some such systems contain "weak" keys. For recommendations regarding + these weak keys, see [CLAR]. + + PKINIT allows the use of the same RSA key pair for encryption and + signing when doing RSA encryption based key delivery. This is not + recommended usage of RSA keys [RFC3447], by using DH based key + delivery this is avoided. + + 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 used for certain certificate types. Deployers of + PKINIT should be aware of the implications of using certificates that + have escrowed keys for the purposes of authentication. Because + signing only certificates are normally not escrowed, by using DH + + + +Tung & Zhu Expires August 22, 2005 [Page 21] + +Internet-Draft PKINIT February 2005 + + + based key delivery this is avoided. + + 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. By + using DH based key delivery and reusing DH keys, the necessary crypto + processing cost per request can be minimized. + + The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does + permit empty SEQUENCEs to be encoded. Such empty sequences may only + be used if the KDC itself vouches for the user's certificate. + +5. Acknowledgements + + The following people have made significant contributions to this + draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist + Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle, + Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik Jaganathan + and Chaskiel M Grundman. + + Special thanks to Clifford Neuman, Matthew Hur and Sasha Medvinsky + who wrote earlier versions of this document. + + The authors are indebt to the Kerberos working group chair Jeffrey + Hutzelman who kept track of various issues and was enormously helpful + during the creation of this document. + + Some of the ideas on which this document 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 + document approaches those goals primarily from the Kerberos + perspective. + + Lastly, comments from groups working on similar ideas in DCE have + been invaluable. + +6. IANA Considerations + + This document has no actions for IANA. + + + + + + +Tung & Zhu Expires August 22, 2005 [Page 22] + +Internet-Draft PKINIT February 2005 + + +7. References + +7.1 Normative References + + [CLAR] RFC-Editor: To be replaced by RFC number for draft-ietf- + krb-wg-kerberos-clarifications. Work in Progress. + + [IEEE1363] + IEEE, "Standard Specifications for Public Key + Cryptography", IEEE 1363, 2000. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", + RFC 2412, November 1998. + + [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", + RFC 2631, June 1999. + + [RFC3279] Bassham, L., Polk, W. and R. Housley, "Algorithms and + Identifiers for the Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 3279, April 2002. + + [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet + X.509 Public Key Infrastructure Certificate and + Certificate Revocation List (CRL) Profile", RFC 3280, + April 2002. + + [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) + Algorithms", RFC 3370, August 2002. + + [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography + Standards (PKCS) #1: RSA Cryptography Specifications + Version 2.1", RFC 3447, February 2003. + + [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) + Diffie-Hellman groups for Internet Key Exchange (IKE)", + RFC 3526, May 2003. + + [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) + Encryption Algorithm in Cryptographic Message Syntax + (CMS)", RFC 3565, July 2003. + + [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", + RFC 3852, July 2004. + + + +Tung & Zhu Expires August 22, 2005 [Page 23] + +Internet-Draft PKINIT February 2005 + + + [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for + Kerberos 5", RFC 3961, February 2005. + + [X.509-97] ITU-T. Recommendation X.509: The Directory - Authentication + Framework. 1997. + + [X690] ASN.1 encoding rules: Specification of Basic Encoding + Rules (BER), Canonical Encoding Rules (CER) and + Distinguished Encoding Rules (DER), ITU-T Recommendation + X.690 (1997) | ISO/IEC International Standard + 8825-1:1998. + +7.2 Informative References + + [CAPATH] RFC-Editor: To be replaced by RFC number for draft-ietf- + pkix-certpathbuild. Work in Progress. + + [LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key + Sizes", Journal of Cryptology 14 (2001) 255-293. + + [ODL99] Odlyzko, A., "Discrete logarithms: The past and the + future, Designs, Codes, and Cryptography (1999)". + +Authors' Addresses + + Brian Tung + USC Information Sciences Institute + 4676 Admiralty Way Suite 1001, Marina del Rey CA + Marina del Rey, CA 90292 + US + + Email: brian@isi.edu + + + Larry Zhu + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + US + + Email: lzhu@microsoft.com + +Appendix A. PKINIT ASN.1 Module + + + +Tung & Zhu Expires August 22, 2005 [Page 24] + +Internet-Draft PKINIT February 2005 + + + KerberosV5-PK-INIT-SPEC { + iso(1) identified-organization(3) dod(6) internet(1) + security(5) kerberosV5(2) modules(4) pkinit(5) + } DEFINITIONS EXPLICIT TAGS ::= BEGIN + + IMPORTS + SubjectPublicKeyInfo, AlgorithmIdentifier + FROM PKIX1Explicit88 { iso (1) + identified-organization (3) dod (6) internet (1) + security (5) mechanisms (5) pkix (7) id-mod (0) + id-pkix1-explicit (18) } + -- As defined in RFC 3280. + + DomainParameters, EcpkParameters + FROM PKIX1Algorithms88 { iso(1) + identified-organization(3) dod(6) + internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-pkix1-algorithms(17) } + -- As defined in RFC 3279. + + KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey + FROM KerberosV5Spec2 { iso(1) identified-organization(3) + dod(6) internet(1) security(5) kerberosV5(2) + modules(4) krb5spec2(2) } ; + + id-pkinit OBJECT IDENTIFIER ::= + { iso (1) org (3) dod (6) internet (1) security (5) + kerberosv5 (2) pkinit (3) } + + id-pkauthdata OBJECT IDENTIFIER ::= { id-pkinit 1 } + id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 } + id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 } + id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 } + id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 } + + pa-pk-as-req INTEGER ::= 16 + pa-pk-as-rep INTEGER ::= 17 + + ad-initial-verified-cas INTEGER ::= 9 + + td-trusted-certifiers INTEGER ::= 104 + td-invalid-certificates INTEGER ::= 105 + td-dh-parameters INTEGER ::= 109 + + PA-PK-AS-REQ ::= SEQUENCE { + signedAuthPack [0] IMPLICIT OCTET STRING, + -- Contains a CMS type ContentInfo encoded + -- according to [RFC3852]. + + + +Tung & Zhu Expires August 22, 2005 [Page 25] + +Internet-Draft PKINIT February 2005 + + + -- The contentType field of the type ContentInfo + -- is id-signedData (1.2.840.113549.1.7.2), + -- and the content field is a SignedData. + -- The eContentType field for the type SignedData is + -- id-pkauthdata (1.3.6.1.5.2.3.1), and the + -- eContent field contains the DER encoding of the + -- type AuthPack. + -- AuthPack is defined below. + trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL, + -- A list of CAs, trusted by the client, that can + -- be used as the trust anchor to validate the KDC's + -- signature. + -- Each TrustedCA identifies a CA or a CA + -- certificate (thereby its public key). + kdcPkId [2] IMPLICIT OCTET STRING + OPTIONAL, + -- Contains a CMS type SignerIdentifier encoded + -- according to [RFC3852]. + -- Identifies, if present, a particular KDC + -- public key that the client already has. + ... + } + + DHNonce ::= OCTET STRING + + TrustedCA ::= SEQUENCE { + caName [0] IMPLICIT OCTET STRING, + -- Contains a PKIX type Name encoded according to + -- [RFC3280]. + -- Identifies a CA by the CA's distinguished subject + -- name. + certificateSerialNumber [1] INTEGER OPTIONAL, + -- Specifies the CA certificate's serial number. + -- The defintion of the certificate serial number + -- is taken from X.509 [X.509-97]. + subjectKeyIdentifier [2] OCTET STRING OPTIONAL, + -- Identifies the CA's public key by a key + -- identifier. When an X.509 certificate is + -- referenced, this key identifier matches the X.509 + -- subjectKeyIdentifier extension value. When other + -- certificate formats are referenced, the documents + -- that specify the certificate format and their use + -- with the CMS must include details on matching the + -- key identifier to the appropriate certificate + -- field. + ... + } + + + + +Tung & Zhu Expires August 22, 2005 [Page 26] + +Internet-Draft PKINIT February 2005 + + + AuthPack ::= SEQUENCE { + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, + -- Type SubjectPublicKeyInfo is defined in + -- [RFC3280]. + -- Specifies Diffie-Hellman domain parameters + -- and the client's public key value [IEEE1363]. + -- The public key value (the subjectPublicKey field + -- of the type SubjectPublicKeyInfo) MUST be encoded + -- according to [RFC3279]. + -- Present only if the client wishes to use the + -- Diffie-Hellman key agreement method. + supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier + OPTIONAL, + -- Type AlgorithmIdentifier is defined in + -- [RFC3280]. + -- List of CMS encryption types supported by the + -- client in order of (decreasing) preference. + clientDHNonce [3] DHNonce OPTIONAL, + -- Present only if the client indicates that it + -- wishes to reuse DH keys or to allow the KDC to + -- do so. + ... + } + + PKAuthenticator ::= SEQUENCE { + cusec [0] INTEGER (0..999999), + ctime [1] KerberosTime, + -- cusec and ctime are used as in [CLAR], for replay + -- prevention. + nonce [2] INTEGER (0..4294967295), + -- Chosen randomly; This nonce does not need to + -- match with the nonce in the KDC-REQ-BODY. + paChecksum [3] OCTET STRING, + -- Contains the SHA1 checksum, performed over + -- KDC-REQ-BODY. + ... + } + + TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA + -- Identifies a list of CAs trusted by the KDC. + -- Each TrustedCA identifies a CA or a CA + -- certificate (thereby its public key). + + TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING + -- Each OCTET STRING contains a CMS type + -- IssuerAndSerialNumber encoded according to + -- [RFC3852]. + + + +Tung & Zhu Expires August 22, 2005 [Page 27] + +Internet-Draft PKINIT February 2005 + + + -- Each IssuerAndSerialNumber indentifies a + -- certificate (sent by the client) with an invalid + -- signature. + + KRB5PrincipalName ::= SEQUENCE { + realm [0] Realm, + principalName [1] PrincipalName + } + + AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA + -- Identifies the certification path based on which + -- the client certificate was validated. + -- Each TrustedCA identifies a CA or a CA + -- certificate (thereby its public key). + + PA-PK-AS-REP ::= CHOICE { + dhInfo [0] DHRepInfo, + -- Selected when Diffie-Hellman key exchange is + -- used. + encKeyPack [1] IMPLICIT OCTET STRING, + -- Selected when public key encryption is used. + -- Contains a CMS type ContentInfo encoded + -- according to [RFC3852]. + -- The contentType field of the type ContentInfo is + -- id-envelopedData (1.2.840.113549.1.7.3). + -- The content field is an EnvelopedData. + -- The contentType field for the type EnvelopedData + -- is id-signedData (1.2.840.113549.1.7.2). + -- The eContentType field for the inner type + -- SignedData (when unencrypted) is id-pkrkeydata + -- (1.2.840.113549.1.7.3) and the eContent field + -- contains the DER encoding of the type + -- ReplyKeyPack. + -- ReplyKeyPack is defined below. + ... + } + + DHRepInfo ::= SEQUENCE { + dhSignedData [0] IMPLICIT OCTET STRING, + -- Contains a CMS type ContentInfo encoded according + -- to [RFC3852]. + -- The contentType field of the type ContentInfo is + -- id-signedData (1.2.840.113549.1.7.2), and the + -- content field is a SignedData. + -- The eContentType field for the type SignedData is + -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the + -- eContent field contains the DER encoding of the + -- type KDCDHKeyInfo. + + + +Tung & Zhu Expires August 22, 2005 [Page 28] + +Internet-Draft PKINIT February 2005 + + + -- KDCDHKeyInfo is defined below. + serverDHNonce [1] DHNonce OPTIONAL + -- Present if and only if dhKeyExpiration is + -- present. + } + + KDCDHKeyInfo ::= SEQUENCE { + subjectPublicKey [0] BIT STRING, + -- KDC's DH public key. + -- The DH pubic key value is mapped to a BIT STRING + -- according to [RFC3279]. + nonce [1] INTEGER (0..4294967295), + -- Contains the nonce in the PKAuthenticator of the + -- request if DH keys are NOT reused, + -- 0 otherwise. + dhKeyExpiration [2] KerberosTime OPTIONAL, + -- Expiration time for KDC's key pair, + -- present if and only if DH keys are reused. If + -- this field is omitted then the serverDHNonce + -- field MUST also be omitted. + ... + } + + ReplyKeyPack ::= SEQUENCE { + replyKey [0] EncryptionKey, + -- Contains the session key used to encrypt the + -- enc-part field in the AS-REP. + nonce [1] INTEGER (0..4294967295), + -- Contains the nonce in the PKAuthenticator of the + -- request. + ... + } + + TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier + -- Each AlgorithmIdentifier specifies a set of + -- Diffie-Hellman domain parameters [IEEE1363]. + -- This list is in decreasing preference order. + END + + + + + + + + + + + + + +Tung & Zhu Expires August 22, 2005 [Page 29] + +Internet-Draft PKINIT February 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Tung & Zhu Expires August 22, 2005 [Page 30] + + diff --git a/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-03.txt b/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-03.txt new file mode 100644 index 000000000..3a923d00d --- /dev/null +++ b/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-03.txt @@ -0,0 +1,1816 @@ + +Kerberos Working Group Nicolas Williams +INTERNET-DRAFT Sun Microsystems +Expires: August 22, 2005 February 21, 2005 + + + + + Kerberos Set/Change Password: Version 2 + + +Status of this Memo + + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + and any of which I become aware will be disclosed, in accordance with + RFC 3668. + + 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. + + This Internet-Draft will expire on August 22, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). All Rights Reserved. + +Abstract + + This document specifies an extensible protocol for setting keys and + changing the passwords of Kerberos V principals. + +Table of Contents + + 1 Introduction + 2 The Protocol + 2.1 Transports + 2.2 Protocol Framing + 2.3 Protocol version negotiation + 2.3.1 Protocol Major Version Negotiation + 2.3.2 Protocol Minor Version Negotiation + 2.4 Use of Kerberos V + +N. Williams [Page 1] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + 2.5 Use of ASN.1 + 2.6 Internationalization + 2.6.1 Normalization Forms for UTF-8 Strings + 2.6.2 Language Negotiation + 2.7 Protocol Extensibility + 2.8 Protocol Subsets + 3 Protocol Elements + 3.1 PDUs + 3.2 Operations + 3.2.1 Null + 3.2.2 Change Kerberos Password + 3.2.3 Set Kerberos Password + 3.2.4 Set Kerberos Keys + 3.2.5 Generate Kerberos Keys + 3.2.6 Get New Keys + 3.2.7 Commit New Keys + 3.2.8 Get Password Quality Policy + 3.2.9 Get Principal Aliases + 3.2.10 Get Realm's Supported Kerberos V Version and Features + 4 ASN.1 Module + 6 IANA Considerations + 7 Security Considerations + 8 Acknowledgements + 9 References + 9.1 Normative References + 9.2 Informative References + 10 Authors' Addresses + 11 Notes to the RFC Editor + +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 [RFC2119]. + +1 Introduction + + Up to this point Kerberos V has lacked a single, standard protocol + for changing passwords and keys. While several vendor-specific + protocols exist for changing Kerberos passwords/keys, none are + properly internationalized and all are incomplete in one respect or + another and none are sufficiently extensible to cope with new + features that may be added to Kerberos V at some future time. + + This document defines a protocol that is somewhat backward-compatible + with the "kpasswd" protocol defined in [RFC3244] that uses more or + less the same protocol framing. + + This new protocol is designed to be extensible and properly + internationalized. + +2 The Protocol + + +N. Williams [Page 2] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + The structure of the protocol is quite similar to that of typical RPC + protocols. Each transaction consists of a data structure specific to + an operation which is then wrapped in a data structure which is + general to all operations of the protocol. These data structures are + defined with the Abstract Syntax Notation 1 (ASN.1) [X680] and they + are encoded using the Distinguished Encoding Rules (DER) [X690]. + + All protocol data is wrapped KRB-PRIV messages, or, in some cases, a + KRB-ERROR, and framed in a header that is backwards compatible with + [RFC3244]. + +2.1 Transports + + The service supports only connection-oriented transports, + specifically TCP, and MUST accept requests on TCP port 464, the same + as in [RFC3244]. + +2.2 Protocol Framing + + Requests and responses are exchanged using the same framing as in + [RFC3244], but with the following differences: + + - the protocol number field MUST be set to 0x2 (not 0xff80 or 0x1) + + - the 'AP-REQ length' field of the request can be set to 0x0, in + which case the 'AP-REQ' field of the request is excluded + + - the 'KRB-PRIV' field of the request and reply is mutually + exclusive with the 'AP-REQ' field of the request + + - the 'AP-REP length' field of the reply can be set to 0x0, in + which case the 'AP-REP' field of the reply is excluded + + - all errors MUST be sent in a KRB-PRIV if the client's AP-REQ can + be or has been accepted by the server + + - any KRB-ERROR messages are framed and sent in the 'AP-REP' field + of the reply + + The initial message from the client MUST carry an AP-REQ and the + response to any request bearing an AP-REQ MUST carry an AP-REP or + MUST be a KRB-ERROR. + + Subsequent messages exchanged on the same TCP connection MAY involve + Kerberos V AP exchanges, but generally the client SHOULD NOT initiate + a new AP exchange except when it desires to authenticate as a + different principal, when the ticket last used for authentication + expires or when the server responds with an error indicating that the + client must re-authenticate. + +2.3 Protocol Version Negotiation + + There are several major versions of this protocol. Version 2 also + +N. Williams [Page 3] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + introduces a notion of protocol minor versions for use in negotiating + protocol extensions. As of this time only one minor version is + defined for major version 2: minor version 0, defined herein. + +2.3.1 Protocol Major Version Negotiation + + Version 2 clients that also support other versions, such as 0xff80, + as in [RFC3244], SHOULD attempt to use version 2 of the protocol + first. + + Servers which do not support version 2 of this protocol typically + include their preferred version number in the reply and/or may + include a reply in the e-data of a KRB-ERROR, or in a KRB-PRIV with a + status code of KRB5_KPASSWD_MALFORMED. + + Note that some [RFC3244] server implementations close the TCP + connection without returning any other response. Note also that + there is no integrity protection for the major version number in the + protocol framing or for any data in a KRB-ERROR. + + As a result change password protocol major version negotiation is + subject to downgrade attacks. Therefore major version negotiation is + NOT RECOMMENDED. + + Where the server indicates that it does not support version 2, the + client MAY, but SHOULD NOT, unless configured to do so, fall back on + another major version of this protocol. + + Version 2 servers MAY respond to non-v2 requests using whatever + response is appropriate for the versions used by the clients, but if + a server does not do this or know how to do this then it MUST respond + with an error framed as in section 2.2, using an AP-REP and KRB-PRIV + if the client's AP-REQ can be accepted, or a KRB-ERROR otherwise and + using a ProtocolErrorCode value of unsupported-major-version. + + It is expected that implementations of as yet unspecified future + major versions of this protocol will be required to support version 2 + integrity protected error replies for properly indicating no support + for version 2 of the protocl. We also hope that no further major + versions of this protocol will be needed. + +2.3.2 Protocol Minor Version Negotiation + + Version 2 clients are free to use whatever protocol minor version and + message extensions are available to them in their initial messages to + version 2 servers, provided that the minor versions (other than 0) + have been defined through IETF documents. + + Version 2 servers MUST answer with the highest protocol minor version + number supported by the server and the client. + + Version 2 clients MUST use the protocol minor version used in a + server's reply for any subsequent messages in the same TCP session. + +N. Williams [Page 4] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + + See section 2.7 for further description of the protocol's + extensibility and its relation to protocol minor versions and the + negotiation thereof. + +2.4 Use of Kerberos V and Key Exchange + + This protocol makes use of messages defined in [RFC1510] and + [clarifications]. Specifically, AP-REQ, AP-REP, KRB-ERROR and + KRB-PRIV. + + All operations are to be performed by the server on behalf of the + client principal. + + Clients SHOULD use "kadmin/setpw" as the principal name of the server + for all requests except when changing the client principal's own + expired password, for which they should use "kadmin/changepw". The + "kadmin/changepw" service exists to allow KDCs to limit principals + with expired passwords to getting initial tickets to the password + changing service only and only for changing expired passwords. + + Servers MUST limit clients that used the "kadmin/changepw" service + principal name to changing the password of the client principal. + + The client MUST request mutual authentication and the client MUST + MUST request the use of sequence numbers. + + Clients SHOULD use INITIAL tickets for requests whose target + principal is the client's principal. Servers SHOULD force the use of + INITIAL tickets for such requests and MAY force the use of INITIAL + for all others - see section 3.2. + + Servers MUST specify a sub-session key. + + The encrypted part of KRB-PRIVs MUST be encrypted with the server's + sub-session key and key usage 20 (client->server) or 21 + (server->client). + + After each new AP exchange the client and server MUST destroy the + session keys, if any, resulting from the previous AP exchange. + +2.5 Use of ASN.1 + + This protocol's messages are defined in ASN.1, using only features + from [X680]. All ASN.1 types defined herein are to be encoded in + DER [X690]. A complete ASN.1 module is given in section 4. + + The DER encoding of the ASN.1 PDUs are exchanged wrapped in a + KRB-PRIV as described above and/or as e-data in KRB-ERROR messages. + +2.6 Internationalization + + This protocol's request PDU carries an optional field indicating the + +N. Williams [Page 5] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + languages spoken by the client user; the client SHOULD send its list + of spoken languages to the server (once per-TCP session). + + The server SHOULD localize all strings intended for display to users + to a language in common with the languages spoken by the client user. + + Strings for Kerberos principal and realm names used in this protocol + are be constrained as per [clarifications]. + +2.6.1 Normalization Forms for UTF-8 Strings + + Because Kerberos V [clarifications] restricts principal names, realm + names and passwords to IA5String, this protocol uses UTF8String with + an extensible constraint to IA5String. + + Future versions of Kerberos may relax this constraint; if so then a + minor version of this protocol should relax this constraint + accordingly. + +2.6.2 Language Negotiation + + The server MUST pick a language from the client's input list or + the default language tag (see [RFC3066]) for text in its responses + which is meant for the user to read. + + The server SHOULD use a language selection algorithm such that + consideration is first given to exact matches between the client's + spoken languages and the server's available locales, followed by + "fuzzy" matches where only the first sub-tags of the client's + language tag list are used for matching against the servers available + locales. + + Servers MUST cache the optional language tag lists from prior + requests for use with subsequent requests that exclude the language + tag list. Clients MAY expect such server behaviour and send the + language tag lists only once per-TCP session. Clients SHOULD send + the server the language tag list at least once. + + When the server has a message catalog for one of the client's spoken + languages the server SHOULD localize any text strings intended for + display to users. + +2.7 Protocol Extensibility + + The protocol is defined in ASN.1 and uses extensibility markers + throughout. As such, the module presented herein can be extended + within the framework of [X680]. + + Typed holes are not used in this protocol as it is very simple and + does not require the ability to deal with abstract data types defined + in different layers. For this reason, the only way to extend this + protocol is by extending the ASN.1 module within the framework of the + IETF; all future extensions to this protocol have to be defined in + +N. Williams [Page 6] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + IETF documents unless otherwise specified in a future IETF revision + of this protocol. + + A protocol minor version number is used to negotiate use of + extensions. See section 2.3.2 for the minor version negotiation. + + Servers SHOULD ignore unknown additions to the ASN.1 types, in + initial requests, where the syntax allows them, except for extensions + to the "Op-req" type, which MUST result in an error. + + Servers MUST respond with an error (ProtocolErrorCode value of + unsupported-minor-version) to clients that use operations unknown to + the server. + +2.8 Protocol Subsets + + The structure of the protocol is such that the ASN.1 syntaxes for the + various operations supported by the protocol are independent of the + each other. Client and server implementations MAY implement subsets + of the overall protocol by removing some alternatives to the Op-req, + Op-rep and Op-err CHOICEs from the ASN.1 module given in section 4. + + For example, it should be possible to have a password-change only + client that cannot set principal's keys - and vice versa. + +3 Protocol Elements + + The protocol as defined herein supports the following operations + relating to the management of Kerberos principal's passwords or keys: + + [NOTE: New since last version of this I-D.] + - get principal's current and preferred string-to-key parameters + + - change password (or enctypes and string-to-key parameters) + - set password (administrative) + - set new keys + - generate new keys + - get new, un-committed keys + - commit new keys + - get password policy name and/or description of principal + - list aliases of a principal + - list enctypes and version of Kerberos V supported by realm + + The operation for retrieving a list of aliases of a principal is + needed where KDCs implement aliasing of principal names and allows + clients to properly setup their key databases when principal aliasing + is in use. + + Operations such as creation or deletion of principals are outside the + scope of this document, and should be performed via other means, such + as through directories or other Kerberos administration protocols. + + The individual operations are described in section 3.2. + +N. Williams [Page 7] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + +3.1 PDUs + + The types "Request," "Response" and "Error-Response" are the ASN.1 + module's PDUs. + + The "Request" and "Response" PDUs are always to be sent wrapped in + KRB-PRIV messages, except for the "Error-Response" PDU which MUST be + sent as KRB-ERROR e-data (see section 2.4.1) when AP exchanges fail, + otherwise it MUST be sent wrapped in a KRB-PRIV. + + The ASN.1 syntax for the PDUs is given in section 4. + + Note that the first field of each PDU is the major version of the + protocol, defaulted to 2, meaning that it is never included in + version 2 exchanges. Similarly, the second field of each PDU is the + minor version, defaulted to 0. + + The request, responses and error PDUs consist of an outer structure + ("Request," "Response" and "Error-Response") containing fields common + to all requests, responses and errors, respectively, and an inner + structure for fields that are specific to each operation's + requests/responses. The inner structure is optional in the case of + the Error-Response PDU and need not be included when generic errors + occur for which there is a suitable ProtocolErrorCode. + + Specifically, the outer Request structure has a field for passing a + client user's spoken (read) languages to the server. It also has two + optional fields for identifying the requested operation's target + principal's name and realm (if not sent then the server MUST use the + client's principal name and realm as the target). A boolean field + for indicating whether or not the request should be dry-run is also + included; dry-runs can be used to test server policies, and servers + MUST NOT modify any principals when processing dry-run requests. + + The Response and Error PDUs' outer structures include a field + indicating the language that the server has chosen for localization + of text intended to be displayed to users; this field is defaulted to + "i-default". This language tag applies to all UTF8 strings in the + inner structure (Op-rep and Op-err) that are meant to be displayed to + users. + + The protocol error codes are: + + - proto-generic-error + + An operation-specific error ocurred, see the inner Op-error. + + - proto-format-error + - proto-unsupported-major-version + - proto-unsupported-minor-version + - proto-unsupported-operation + + +N. Williams [Page 8] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + - proto-wrong-service-principal + + Use kadmin/setpw for the server's principal name. + + - proto-re-authentication-required + + The server demands that the client re-authenticate through a new + AP exchange. + + - proto-initial-ticket-required + + Use of an INITIAL ticket is required for the requested + operation. + + - proto-client-and-target-realm-mismatch + + The server requires that the client's principal name and the + target principal of the operation share the same realm name. + + - proto-target-principal-unknown + - proto-authorization-failed + +3.2 Operations + + This section describes the semantics of each operation request and + response defined in the ASN.1 module in section 4. + +3.2.1 Null + + NAME + + null - Null or "ping" operation + + DESCRIPTION + + The null request is intended for use with TCP; its purpose is + similar to RPC null procedures and is akin to a "ping" operation. + + ERRORS + + None. + +3.2.2 Change Kerberos Password + + NAME + + change-pw - Change password operation + + SYNOPSIS + + Req-change-pw(old-pw, [languages], [new-pw], + [commit], [etypes]) -> + Rep-change-pw([info-text], [new-pw], [etypes]) | + +N. Williams [Page 9] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + Err-change-pw([help-text], error code, [error info]) + + DESCRIPTION + + Change a principal's password. + + The change password request has one required, three optional and + one defaulted arguments: "old-pw" (required), "languages," + "new-pw", "commit" (defaults to "TRUE") and "etypes", + corresponding to the target principal's old password, its + preferred languages, its new password, a boolean indicating + whether or not to make the new long-term key available for + immediate use, and the desired enctypes for the new long-term + keys. + + The server MUST validate the old password and MUST check the + quality of the new password, if sent, according the password + quality policy associated with the target principal. + + If the old and new passwords in the request are the same strings, + and the principal is not currently required to change its + password, then the server MAY permit the password change as way to + change a principal's enctypes and string-to-key parameters. This + feature provides a way to, for example, add enctypes to a + principals' password-derived long-term keys without forcing a + password change following an upgrade to the KDC that adds support + for new enctypes. + + A client MAY request that the server generate a new password by + excluding the new password from its request, in which case the + server MUST either generate a new password or respond with an + error indicating that it does not support this feature. + + Server-generated passwords MUST meet the target principal's + password quality policy. It is RECOMMENDED that server-generated + passwords be user-friendly, that is, memorable and that the target + principal's preferred languages be taken into account by the + password generation alogrithm used by the server. + + Uncommitted password changes are commited using the commit-keys + operation. + + RETURN + + Upon successful password changes the server responds with a + Rep-change-pw. The fields of Rep-change-pw are all optional and + include: + + - 'info-text' which the server can use to send a message to the + user such as "Your new password will expire in 90 days," for + example. + + - 'new-pw' which the server MUST include if the client + +N. Williams [Page 10] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + requested that the server generate a new password; generated + passwords MUST pass the target principal's password quality + policy. + + - 'etypes' which the server MAY include to indicate which types + of long-term keys it created for the target principal and + which the server MUST include if the client specified a set + of enctypes in its request. + + ERRORS + + The server may respond to change password requests with protocol + or operation errors. See section 3.1 for a description of + protocol error codes. + + All operation errors include an optional 'help-text' field by + which the server can describe the error in a human-readable, + localizaed string. + + Change password error codes include: + + - generic-error + + - old-pw-incorrect + + - wont-generate-new-pw + + The server will not generate a new password for this + principal or does not support password generation in general. + + - new-pw-rejected-generic + + The client's proposed new password failed the target + principal's password quality policy. + + The server MUST include a description of the password quality + policy or aspect of it that the client's proposed new + password failed to meet. + + The server MAY generate and send a new password that the + client can then use as a new password and which is guaranteed + to pass the target principal's current password quality + policy. + + The server MAY include a set of policy error code hints. + + - etype-not-supported + + The client requested an enctype that the KDC does not + support. + +3.2.3 Set Kerberos Password + + +N. Williams [Page 11] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + NAME + + set-pw - Set password operation + + SYNOPSIS + + Req-set-pw([languages], [new-pw], [commit], [etypes]) -> + Rep-set-pw([info-text], [new-pw], [etypes]) | + Err-set-pw([help-text], error code, [error info]) + + DESCRIPTION + + Administratively set a principal's password. + + The set password request has three optional and one defaulted + arguments: "languages", "new-pw," "commit" (defaulted to "TRUE") + and "etypes", corresponding to the target principal's preferred + languages, new password, a boolean indicating whether or not to + make the new long-term key available for immediate use, and the + desired enctypes for the new long-term keys. + + The server MUST check the quality of the new password, if sent, + according the password quality policy associated with the target + principal. + + The server SHOULD require that the client use the change-pw + operation instead of set-pw when the client principal and the + target principal are the same. + + A client MAY request that the server generate a new password by + excluding the new password from its request, in which case the + server MUST either generate a new password or respond with an + error indicating that it does not support this feature. + + Server-generated passwords MUST meet the target principal's + password quality policy. It is RECOMMENDED that server-generated + passwords be user-friendly, that is, memorable and that the target + principal's preferred languages be taken into account by the + password generation alogrithm used by the server. + + RETURN + + Upon successfully setting a password the server responds with a + Rep-set-pw. The fields of Rep-set-pw are all optional and + include: + + - 'info-text' which the server can use to send a message to the + user such as "Your new password will expire in 90 days," for + example. + + - 'new-pw' which the server MUST include if the client + requested that the server generate a new password; generated + passwords MUST pass the target principal's password quality + +N. Williams [Page 12] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + policy. + + - 'etypes' which the server MAY include to indicate which types + of long-term keys it created for the target principal and + which the server MUST include if the client specified a set + of enctypes in its request. + + ERRORS + + The server may respond to set password requests with protocol or + operation errors. See section XYZ for a description of protocol + error codes. + + All operation errors include an optional 'help-text' field by + which the server can describe the error in a human-readable, + localizaed string. + + Set password error codes include: + + - generic-error + + - use-change-pw + + The server demands that the client use the change-pw + operation for the target principal of the set-pw request. + + - wont-generate-new-pw + + The server will not generate a new password for this + principal or does not support password generation in general. + + - new-pw-rejected-generic + + The client's proposed new password failed the target + principal's password quality policy. + + The server MUST include a description of the password quality + policy or aspect of it that the client's proposed new + password failed to meet. + + The server MAY generate and send a new password that the + client can then use as a new password and which is guaranteed + to pass the target principal's current password quality + policy. + + The server MAY include a set of policy error code hints. + + - etype-not-supported + + The client requested an enctype that the KDC does not + support. + +3.2.4 Set Kerberos Keys + +N. Williams [Page 13] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + + NAME + + set-keys + + SYNOPSIS + + Req-set-keys(new-keys, commit?, [isupport]) -> + Rep-set-keys([info-text], kvno, aliases, [isupport]) + + DESCRIPTION + + The set-keys request consists of two required fields and one + optional field: "new-keys", "commit" (a boolean field - see below) + and "isupport", an optional field for indicating to the KDC what + Kerberos V features are supported by the target principal. + + When "commit" is true the KDC makes the new keys available for + issueing tickets encrypted in them immediately. Otherwise the + client MUST follow up with a commit-keys request to make the keys + available. This feature is useful for changing keys shared by + multiple hosts, in clustered services, for example, in an atomic + manner; see section 3.2.6 and 3.2.7. + + If a principal has keys are awaiting commitment when a new + set-keys request for that principal s made then the KDC MUST + overwrite the deferred keys. + + RETURN + + For successful set-keys operations the server returns: + + - Informational text, optional. + + - The new kvno for the target principal. + + - A list of aliases of the target principal known to the KDC + (optional). + + - The set of Kerberos V features supported by the KDC + (optional). + + ERRORS + + The server may respond with the following errors: + + - generic + - deferred-commit-no-support + - etype-no-support + +3.2.5 Generate Kerberos Keys + + NAME + +N. Williams [Page 14] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + + gen-keys + + SYNOPSIS + + Req-gen-keys(etypes, [entropy], commit?, [isupport]) -> + Rep-set-keys([info-text], key, kvno, aliases, [isupport]) + + DESCRIPTION + + The gen-keys is similar to the set-keys request (see section + 3.2.4) but differs in that the server generates keys of + client-requested enctypes, rather than the client providing + specific keys. + + The gen-keys request consists of two required fields and two + optional fields: "etypes" (the enctypes of the new keys), + "entropy", "commit" and "isupport" (see section 3.2.4). + + If a principal has keys are awaiting commitment when a new + set-keys request for that principal s made then the KDC MUST + overwrite the deferred keys. + + RETURN + + For successful set-keys operations the server returns: + + - Informational text, optional. + + - The new kvno for the target principal. + + - The new key (only one is needed). + + - A list of aliases of the target principal known to the KDC + (optional). + + - The set of Kerberos V features supported by the KDC + (optional). + + ERRORS + + The server may respond with the following errors: + + - generic + - deferred-commit-no-support + - etype-no-support + +3.2.6 Get New Keys + + NAME + + get-keys + + +N. Williams [Page 15] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + SYNOPSIS + + Req-get-keys(kvno) -> + Rep-get-keys([info-text], keys, aliases, [isupport]) | + Err-get-keys([help-text], error code, [error info]) + + DESCRIPTION + + This request allows a client to get the keys set or generated in a + previous set-keys or gen-keys request with deferred commitment.. + + RETURN + + If the target principal and kvno correspond to uncommitted keys + the server MUST respond with the actual keys that would be set by + a subsequent commit-keys request. Otherwise the server MUST + respond with an error (meaning that this operation cannot be used + to extract keys from the KDC that may be in use). + + ERRORS + + - generic + - kvno-committed + - no-such-kvno + +3.2.7 Commit New Keys + + NAME + + commit-keys + + SYNOPSIS + + Req-commit-keys(kvno) -> + Rep-commit-keys() | + Err-commit-keys([help-text], error code, [error info]) + + DESCRIPTION + + The commit-keys operation allows a client to bring a principal's + new keys into use at the KDC. + + Clients should make a commit-keys request corresponding to a + deferred commitment set-keys/gen-keys operation as soon as the + local key database for the target principal is updated. + + The target principal name and the kvno MUST match those from a + prior set-keys or gen-keys operation. + + Servers MAY expire delayed key commitments at will. Servers + SHOULD expire uncommitted new keys after a reasonable amount of + time (600 seconds is RECOMMENDED). + + +N. Williams [Page 16] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + Servers MUST respond to new set-keys requests for principals with + pending, uncommitted new keys by expiring the uncommitted new keys + and proceeding as if there had been no expired new keys. + + ERRORS + + - generic + - op-kvno-expired + - op-kvno-unknown + - new-keys-conflict (A set-keys or gen-keys request succeeded + subsequent to the request that matches this + {principal, kvno} tuple.) + +3.2.8 Get Password Quality Policy + + NAME + + get-pw-policy + + SYNOPSIS + + Req-get-pw-policy() -> + Rep-get-pw-policy([policy name], [policy description]) + + DESCRIPTION + + Returns a description of the target principal's associated + password quality policy, if any, as a list of localized + UTF8String values. + + Clients can use this operation in conjunction with the change-pw + operation to obtain text that can be displayed to the user before + the user actually enters a new password. + + It is common for sites to set policies with respect to password + quality. It is beyond the scope of this document to describe such + policies. Management of password quality policies' actual content + is also beyond the scope of this protocol. + + ERRORS + + No operation errors are defined. + + +3.2.9 Get Principal Aliases + + NAME + + get-print-aliases + + SYNOPSIS + + Req-get-princ-aliases() -> + +N. Williams [Page 17] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + Rep-get-princ-aliases(aliases) + + DESCRIPTION + + Returns a list of aliases of the target principal. + + ERRORS + + No operation-specific errors. + +3.2.10 Get Realm's Supported Kerberos V Version and Features + + NAME + + get-realm-krb5-support + + SYNOPSIS + + Req-get-realm-krb5-support() -> + Rep-get-realm-krb5-support(isupport) + + DESCRIPTION + + Returns set of Kerberos V features support by the target + principal's realm's KDCs. + + ERRORS + + No operation-specific errors. + +3.2.11 Retrieve Principal's S2K Params and Preferred Params + + NAME + + get-s2kparams + + SYNOPSIS + + Req-get-s2kparams() -> + Rep-get-s2kparams([princ-s2kparams], [preferred-s2kparams]) + + DESCRIPTION + + Returns the string2key parameters for the principal's current + password-derived long-term keys, if any, and the parameters that + the realm would prefer, if they differ from the former. + + This operation is intended for use with the change-pw() operation. + When surprised by a KDC's PA-ETYPE-INFO2 a client SHOULD check if + the principal's long-term secret keys' string2key parameters (and + enctype list) should be changed and, if so, change them. + + If the 'princ-s2kparams' return value is missing then the + +N. Williams [Page 18] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + principal does not have a password-derived long-term key. + + The 'preferred-s2kparams' MUST be excluded if the principal's + string2key parameters satisfy the realm's policy. + + ERRORS + + No operation-specific errors. + +3.3 Principal Aliases + + Applications that use Kerberos often have to derive acceptor + principal names from hostnames entered by users. Such hostnames may + be aliases, they may be fully qualified, partially qualified or not + qualified at all. Some implementations have resorted to deriving + principal names from such hostnames by utilizing the names services + to canonicalize the hostname first; such practices are not secure + unless the name service are secure, which often aren't. + + One method for securely deriving principal names from hostnames is to + alias principals at the KDC such that the KDC will issue tickets for + principal names which are aliases of others. It is helpful for + principals to know what are their aliases as known by the KDCs. + + Note that changing a principal's aliases is out of scope for this + protocol. + +3.4 Kerberos V Feature Negotiation + + Principals and realms' KDCs may need to know about additional + Kerberos V features and extensions that they each support. Several + operations (see above) provide a way for clients and servers to + exchange such infomration, in the form of lists of types supported + for the various typed holes used in Kerberos V. + +4 ASN.1 Module + + DEFINITIONS EXPLICIT TAGS ::= BEGIN + -- + -- Note: EXPLICIT tagging is in use by default throughout this + -- module. + + -- From [clarifications] with modifications + PrincipalName ::= SEQUENCE { + name-string [1] SEQUENCE OF UTF8String (IA5String, ...) + } + Realm ::= UTF8String (IA5String, ...) + Salt ::= UTF8String (IA5String, ...) + Password ::= UTF8String (IA5String, ...) + + -- NOTE WELL: Principal and realm names MUST be constrained by the + -- specification of the version of Kerberos V used by the + -- client. + +N. Williams [Page 19] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + -- + -- [Perhaps PrincipalName should be a SEQUENCE of an optional name + -- type and a UTF8String, for simplicity.] + + -- From [clarifications] + Int32 ::= INTEGER (-2147483648..2147483647) + UInt32 ::= INTEGER (0..4294967295) + + -- Based on [clarifications] + Etype ::= Int32 + Etype-Info-Entry ::= SEQUENCE { + etype [0] Etype, + salt [1] Salt OPTIONAL, + s2kparams [2] OCTET STRING OPTIONAL, + ... + } + Key ::= SEQUENCE { + enc-type [0] Etype, -- from Kerberos + key [1] OCTET STRING, + ... + } + + Language-Tag ::= UTF8String -- Constrained by [RFC3066] + + -- Empty, extensible SEQUENCEs are legal ASN.1 + Extensible-NULL ::= SEQUENCE { + ... + } + + -- Kerberos clients negotiate some parameters relating to their peers + -- indirectly through the KDC. Today this is true of ticket session + -- key enctypes, but in the future this indirect negotiation may also + -- occur with respect to the minor version of Kerberos V to be used + -- between clients and servers. Additionally, KDCs may need to know + -- what authorization-data types are supported by service principals, + -- both, for compatibility with legacy software and for optimization. + -- + -- Thesefore it is important for KDCs to know what features of + -- Kerberos V each service principal supports. + -- + -- In version 2.0 of this protocol the clients and servers may notify + -- each other of their support for: + -- + -- - enctypes + -- - authorization data types + -- - transited encoding data types + -- + -- All authorization-data types defined in [clarifications] are + -- assumed to be supported if the minor version is 1 and do not need + -- to be included in the ad-type list. + -- + -- Int32 is used for enctype and transited encoding data type + -- identifiers. + +N. Williams [Page 20] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + -- + -- An extensible CHOICE of Int32 is used for authorization data + -- types. + + KerberosV-TR-ID ::= Int32 + + KerberosV-AD-ID ::= CHOICE { + ad-int [0] Int32, + ... + } + + KerberosVSupportNego ::= SEQUENCE { + enc-types [0] SEQUENCE OF Etype, + ad-types [1] SEQUENCE OF KerberosV-AD-ID OPTIONAL, + -- authorization data types + tr-enc-types [2] SEQUENCE OF KerberosV-TR-ID OPTIONAL, + -- transited encoding types + ... + } + + Request ::= [APPLICATION 0] SEQUENCE { + pvno-minor [0] INTEGER DEFAULT 0, + languages [1] SEQUENCE OF Language-Tag OPTIONAL, + -- Should be defaulted to the SEQUENCE of "i-default" + targ-name [2] PrincipalName OPTIONAL, + targ-realm [3] Realm OPTIONAL, + -- If targ-name/realm are missing then the request + -- applies to the principal of the client + dry-run [4] BOOLEAN DEFAULT FALSE, + operation [5] Op-req, + ... + } + + Response ::= [APPLICATION 1] SEQUENCE { + pvno-minor [0] INTEGER DEFAULT 0, + language [1] Language-Tag DEFAULT "i-default", + result [2] Op-rep, + ... + } + + Error-Response ::= [APPLICATION 2] SEQUENCE { + pvno-minor [0] INTEGER DEFAULT 0, + language [1] Language-Tag DEFAULT "i-default", + error-code [2] ProtocolErrorCode, + help-text [3] UTF8String OPTIONAL, + op-error [4] Op-err OPTIONAL, + ... + } + + Op-req ::= CHOICE { + null [0] Req-null, + change-pw [1] Req-change-pw, + set-pw [2] Req-set-pw, + +N. Williams [Page 21] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + set-keys [3] Req-set-keys, + gen-keys [4] Req-gen-keys, + get-keys [5] Req-get-keys, + commit-keys [6] Req-commit-keys, + get-pw-policy [7] Req-get-pw-policy, + get-princ-aliases [8] Req-get-princ-aliases, + get-realm-krb5-support [9] Req-get-realm-krb5-support, + get-s2kparams [10] Req-get-s2kparams, + ... + } + + Op-rep ::= CHOICE { + null [0] Rep-null, + change-pw [1] Rep-change-pw, + set-pw [2] Rep-set-pw, + set-keys [3] Rep-set-keys, + gen-keys [4] Req-gen-keys, + get-keys [5] Req-get-keys, + commit-keys [6] Rep-commit-keys, + get-pw-policy [7] Rep-get-pw-policy, + get-princ-aliases [8] Rep-get-princ-aliases, + get-realm-krb5-support [9] Rep-get-realm-krb5-support, + get-s2kparams [10] Rep-get-s2kparams, + ... + } + + Op-err ::= CHOICE { + null [0] Err-null, + change-pw [1] Err-change-pw, + set-pw [2] Err-set-pw, + set-keys [3] Err-set-keys, + gen-keys [4] Err-gen-keys, + get-keys [5] Err-get-keys, + commit-keys [6] Err-commit-keys, + get-pw-policy [7] Err-get-pw-policy, + get-princ-aliases [8] Err-get-princ-aliases, + get-realm-krb5-support [9] Err-get-realm-krb5-support, + get-s2kparams [10] Err-get-s2kparams, + ... + } + + ProtocolErrorCode ::= ENUM { + proto-format-error, + proto-unsupported-major-version, + proto-unsupported-minor-version, + proto-unsupported-operation, -- Request CHOICE tag unknown + proto-generic-see-op-error, -- See Op-error + proto-wrong-service-principal, -- Use kadmin/setpw + proto-re-authentication-required, + proto-initial-ticket-required, + proto-client-and-target-realm-mismatch, + proto-target-principal-unknown, + proto-authorization-failed, + +N. Williams [Page 22] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + proto-dry-run-not-permitted, + ... + } + + -- These codes are hints for clients, primarily for when they are + -- used for changing the passwords of automated principals; error + -- replies carry password quality policy help text that is more + -- appropriate for clients to display to users. + PW-Quality-Codes ::= ENUM { + pwq-generic, + pwq-too-soon, + pwq-repeated, + pwq-too-short, + pwq-dictionary-words, + pwq-prohibited-codepoints, + pwq-need-more-char-classes, + ... + } + + -- + -- Requests and responses + -- + + -- NULL request, much like ONC RPC's NULL procedure - NOT extensible + Req-null ::= NULL + + Rep-null ::= NULL + + Err-null ::= NULL + + -- Change password + Req-change-pw ::= SEQUENCE { + old-pw [0] Password, + new-pw [1] Password OPTIONAL, + commit [2] BOOLEAN DEFAULT TRUE, + etypes [3] SEQUENCE (1..) OF Etype OPTIONAL, + ... + } + + Rep-change-pw ::= SEQUENCE { + info-text [0] UTF8String OPTIONAL, + new-pw [1] Password OPTIONAL, + -- generated by the server if present + -- (and requested by the client) + etypes [2] SEQUENCE (1..) OF Etype OPTIONAL, + ... + } + + Err-change-pw ::= SEQUENCE { + help-text [0] UTF8String OPTIONAL, + error [1] CHOICE { + op-generic-error [0] Extensible-NULL, + op-old-pw-incorrect [1] Extensible-NULL, + +N. Williams [Page 23] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + op-wont-generate-new-pw [2] Extensible-NULL, + op-new-pw-rejected-generic [3] SEQUENCE { + policy [1] SEQUENCE OF UTF8String, + suggested-pw [2] Password OPTIONAL, + policy-codes [3] SET OF PW-Quality-Codes + OPTIONAL, + ... + } + op-etype-not-supported [4] SEQUENCE { + supported-etypes [1] SEQUENCE OF Etype, + ... + }, + ... + }, + ... + } + + -- Set password + Req-set-pw ::= SEQUENCE { + languages [0] SEQUENCE OF Language-Tag OPTIONAL, + new-pw [1] Password OPTIONAL, + commit [2] BOOLEAN DEFAULT TRUE, + etypes [3] SEQUENCE (1..) OF Etype OPTIONAL, + ... + } + + Rep-set-pw ::= SEQUENCE { + info-text [0] UTF8String OPTIONAL, + new-pw [1] Password OPTIONAL, + -- generated by the server if present + -- (and requested by the client) + etypes [2] SEQUENCE (1..) OF Etype OPTIONAL, + ... + } + + Err-set-pw ::= Err-change-pw + + -- Set keys + Req-set-keys ::= SEQUENCE { + keys [0] SEQUENCE OF Key, + commit [1] BOOLEAN DEFAULT TRUE, + -- TRUE -> install keys now + -- + -- FALSE -> require set-keys-commit + -- before issuing tickets + -- encrypted with these keys. + -- + -- See commit-keys op + isupport [2] KerberosVSupportNego OPTIONAL, + -- For future Kerberos V extensions KDCs + -- may need to know what krb5 version is + -- supported by individual service + -- principals. This field provides a + +N. Williams [Page 24] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + -- way to tell the KDC what version of + -- Kerberos V the target principal + -- supports. + ... + } + + Rep-set-keys ::= SEQUENCE { + info-text [0] UTF8String OPTIONAL, + kvno [1] UInt32, + aliases [2] SEQUENCE OF SEQUENCE { + name [0] PrincipalName, + realm [1] Realm OPTIONAL, + ... + }, + isupport [3] KerberosVSupportNego OPTIONAL, + ... + -- Should there be ETYPE-INFO2 stuff here? + } + + Err-set-keys ::= SEQUENCE { + help-text [0] UTF8String OPTIONAL, -- Reason for rejection + error [1] CHOICE { + op-generic [0] Extensible-NULL, + op-deferred-commit-no-support [1] Extensible-NULL, + op-etype-no-support [2] SEQUENCE OF { + supported-etypes [1] SEQUENCE OF Etype, + ... + } + ... + } + } + + -- Generate keys + Req-gen-keys ::= SEQUENCE { + etypes [0] SEQUENCE (1..) OF Etype, + entropy [1] OCTET STRING OPTIONAL, + commit [2] BOOLEAN DEFAULT TRUE, + -- TRUE -> install keys now + -- + -- FALSE -> require set-keys-commit + -- before issuing tickets + -- encrypted with these keys. + -- + -- See commit-keys op + isupport [3] KerberosVSupportNego OPTIONAL, + -- For future Kerberos V extensions KDCs + -- may need to know what krb5 version is + -- supported by individual service + -- principals. This field provides a + -- way to tell the KDC what version of + -- Kerberos V the target principal + -- supports. + ... + +N. Williams [Page 25] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + } + + Rep-gen-keys ::= SEQUENCE { + info-text [0] UTF8String OPTIONAL, + kvno [1] UInt32, + key [2] Key, + aliases [3] SEQUENCE OF SEQUENCE { + name [0] PrincipalName, + realm [1] Realm OPTIONAL, + ... + }, + isupport [4] KerberosVSupportNego OPTIONAL, + ... + -- Should there be ETYPE-INFO2 stuff here? + } + + Err-gen-keys ::= Err-set-keys + + -- Get un-committed key request + Req-get-keys ::= SEQUENCE { + kvno [0] UInt32, + ... + } + + Rep-get-keys ::= SEQUENCE { + info-text [0] UTF8String OPTIONAL, + keys [1] SEQUENCE OF Key, + aliases [2] SEQUENCE OF SEQUENCE { + name [0] PrincipalName, + realm [1] Realm OPTIONAL, + ... + }, + isupport [3] KerberosVSupportNego OPTIONAL, + ... + -- Should there be ETYPE-INFO2 stuff here? + } + + Err-get-keys ::= SEQUENCE { + help-text [0] UTF8String OPTIONAL, -- Reason for rejection + error [1] CHOICE { + op-generic [0] Extensible-NULL, + op-kvno-committed [1] Extensible-NULL, + op-no-such-kvno [1] Extensible-NULL, + ... + } + } + + -- Commit a set keys request + Req-commit-keys ::= SEQUENCE { + kvno [0] UInt32, + ... + } + + +N. Williams [Page 26] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + Rep-commit-keys ::= Extensible-NULL + + Err-commit-keys ::= SEQUENCE { + help-text [0] UTF8String OPTIONAL, -- Reason for rejection + error [1] CHOICE { + op-generic [0] Extensible-NULL, + op-kvno-expired [1] Extensible-NULL, + -- The client took too long to respond. + op-kvno-unknown [2] Extensible-NULL, + -- The targ princ/kvno is invalid or unknown to the + -- server (perhaps it lost track of state) + op-new-keys-conflict [3] Extensible-NULL, + -- A new-keys/commit-keys request subsequent to the + -- new-keys that produced the kvno has completed + -- and incremented the principal's kvno + ... + } + ... + } + + -- Get password policy + Req-get-pw-policy ::= Extensible-NULL + + Rep-get-pw-policy ::= SEQUENCE { + policy-name [0] UTF8String OPTIONAL, + description [1] SEQUENCE OF UTF8String OPTIONAL, + ... + } + + Err-get-pw-policy ::= Extensible-NULL + + -- Get principal aliases + Req-get-princ-aliases ::= Extensible-NULL + + Rep-get-princ-aliases ::= SEQUENCE { + help-text [0] UTF8String OPTIONAL, + aliases [1] SEQUENCE OF SEQUENCE { + name [0] PrincipalName, + realm [1] Realm OPTIONAL, + ... + }, + ... + } + + Err-get-princ-aliases ::= Extensible-NULL + + -- Get list of enctypes supported by KDC for new keys + Req-get-realm-krb5-support ::= Extensible-NULL + + Rep-get-realm-krb5-support ::= SEQUENCE { + isupport [0] KerberosVSupportNego, + -- Version of Kerberos V supported by + -- the target realm. + +N. Williams [Page 27] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + ... + } + + Err-get-realm-krb5-support ::= Extensible-NULL + + -- Get s2kparams + Req-get-s2kparams ::= Extensible-NULL + + Rep-get-s2kparams ::= SEQUENCE { + help-text [0] UTF8String OPTIONAL, + s2kparams [1] SEQUENCE OF Etype-Info-Entry, + ... + } + + Err-get-s2kparams ::= Extensible-NULL + + END + + +6 IANA Considerations + + There are no IANA considerations for this document. + +7 Security Considerations + + Implementors and site administrators should note that the redundancy + of UTF-8 encodings of passwords varies by language. Password quality + policies SHOULD, therefore, take this into account when estimating + the amount of redundancy and entropy in a proposed new password. [?? + It's late at night - I think this is correct.] + + Kerberos set/change password/key protocol major version negotiation + cannot be done securely; a downgrade attack is possible against + clients that attempt to negotiate the protocol major version to use + with a server. It is not clear at this time that the attacker would + gain much from such a downgrade attack other than denial of service + (DoS) by forcing the client to use a protocol version which does not + support some feature needed by the client (Kerberos V in general is + subject to a variety of DoS attacks anyways [RFC1510]). Clients + SHOULD NOT negotiate support for legacy major versions of this + protocol unless configured otherwise. + + This protocol does not have Perfect Forward Security (PFS). As a + result, any passive network snooper watching password/key changing + operations who has stolen a principal's password or long-term keys + can find out what the new ones are. + + [More text needed?] + +8 Acknowledgements + + The authors would like to thank Bill GossmanMike Swift, John Brezak, + Ken Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony Andrea, Paul W. + +N. Williams [Page 28] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + Nelson, Marcus Watts, Love, Joel N. Weber II, Jeffrey Hutzelman and + other participants from the IETF Kerberos Working Group for their + assistance. + +9 References + +9.1 Normative References + + [RFC2026] + S. Bradner, RFC2026: "The Internet Standard Process - Revision + 3," October 1996, Obsoletes - RFC 1602, Status: Best Current + Practice. + + [RFC2119] + S. Bradner, RFC2119 (BCP14): "Key words for use in RFCs to + Indicate Requirement Levels," March 1997, Status: Best Current + Practice. + + [X680] + Abstract Syntax Notation One (ASN.1): Specification of Basic + Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC + International Standard 8824-1:1998. + http://www.itu.int/ITU-T/studygroups/com17/languages/X680_0702.pdf + + [X690] + ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), + Canonical Encoding Rules (CER) and Distinguished Encoding Rules + (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International + Standard 8825-1:1998. + http://www.itu.int/ITU-T/studygroups/com17/languages/X690_0702.pdf + + [clarifications] + RFC-Editor: To be replaced by RFC number for + draft-ietf-krb-wg-kerberos-clarifications. + + [RFC3066] + H. Alvestrand, RFC3066 (BCP47): "Tags for the Identification of + Languages," January 2001, Obsoletes RFC1766, Status: Best Current + Practice. + +9.2 Informative References + + [RFC3244] + M. Swift, J. Trostle, J. Brezak, RFC3244: "Microsoft Windows 2000 + Kerberos Change Password and Set Password Protocols," February + 2002, Status: Informational. + +10 Authors' Addresses + + Nicolas Williams + Sun Microsystems + 5300 Riata Trace Ct + Austin, TX 78727 + +N. Williams [Page 29] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + Email: nicolas.williams@sun.com + + +11 Notes to the RFC Editor + + This document has two KRB WG drafts as normative references and + cannot progress until those drafts progress, but no other draft + depends on this one. + +12 Change History + + -01 -> -02 + + - Removed Bill Gossman, Mike Swift and John Brezak as authors. + + - Removed UDP as a transport for this protocol. + + - Replaced redundant copies of framing ASCII art with reference to + RFC3244. + + - Made all name/password strings UTF8String with an extensible + constraint to IA5String. + + - Added a method for doing dry runs of operations. This is helpful + in testing passwords against password quality policies. + + - Added an operation for retrieving a principal's current and + preferred string-to-key parameters, and a way to change them + without changing the principal's password. + + - Added password quality codes as hints for smart clients, but + these are optional and not to be used instead of messages to be + displayed to useds. + + - Added a 'commit' option to change-pw and set-pw (as requested by + Larry). + + - Removed "version" field of the Kerberos V feature negotiation + struture. + + + +N. Williams [Page 30] + + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Williams Expires August 22, 2005 [Page 31] + +