From 533895bcaabb28870ed43450b98c8809ee1e02c6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Love=20H=C3=B6rnquist=20=C3=85strand?= Date: Wed, 21 Jul 2004 09:28:20 +0000 Subject: [PATCH] x git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@14060 ec53bebd-3082-4978-b11e-865c3cabbd6b --- .../draft-ietf-cat-kerberos-pk-init-20.txt | 1110 ++++++++++ ...aft-ietf-krb-wg-kerberos-set-passwd-02.txt | 1793 +++++++++++++++++ ...draft-ietf-krb-wg-preauth-framework-01.txt | 1165 +++++++++++ 3 files changed, 4068 insertions(+) create mode 100644 doc/standardisation/draft-ietf-cat-kerberos-pk-init-20.txt create mode 100644 doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-02.txt create mode 100644 doc/standardisation/draft-ietf-krb-wg-preauth-framework-01.txt diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-20.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-20.txt new file mode 100644 index 000000000..3f494f27e --- /dev/null +++ b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-20.txt @@ -0,0 +1,1110 @@ +INTERNET-DRAFT Brian Tung +draft-ietf-cat-kerberos-pk-init-20.txt Clifford Neuman +Updates: CLARIFICATIONS USC/ISI +expires January 25, 2005 Matthew Hur + Ari Medvinsky + Microsoft Corporation + Sasha Medvinsky + Motorola, Inc. + John Wray + Iris Associates, Inc. + Jonathan Trostle + + + + Public Key Cryptography for Initial Authentication in Kerberos + + + +0. Status Of This Memo + + +By submitting this Internet-Draft, I certify that any applicable +patent or other IPR claims of which I am aware have been disclosed, +or will be disclosed, and any of which I become aware will be +disclosed, in accordance with RFC 3668. + + +This document is an Internet-Draft and is in full conformance with +all provision of Section 10 of RFC 2026. Internet-Drafts are +working documents of the Internet Engineering Task Force (IETF), its +areas, and its working groups. Note that other groups may also +distribute working documents as Internet-Drafts. + + +Internet-Drafts are draft documents valid for a maximum of six +months and may be updated, replaced, or obsoleted by other documents +at any time. It is inappropriate to use Internet-Drafts as +reference material or to cite them other than as "work in progress." + + +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt + + +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html + + +The distribution of this memo is unlimited. It is filed as +draft-ietf-cat-kerberos-pk-init-20.txt and expires January 25, 2005. +Please send comments to the authors. + + + +1. Abstract + + +This document describes protocol extensions (hereafter called +PKINIT) to the Kerberos protocol specification ([1], hereafter +called CLARIFICATIONS). These extensions provide a method for +integrating public key cryptography into the initial authentication +exchange, by passing digital certificates and associated +authenticators in preauthentication data fields. + + + +2. Introduction + + +A client typically authenticates itself to a service in Kerberos +using three distinct though related exchanges. First, the client +requests a ticket-granting ticket (TGT) from the Kerberos +authentication server (AS). Then, it uses the TGT to request a +service ticket from the Kerberos ticket-granting server (TGS). +Usually, the AS and TGS are integrated in a single device known as +a Kerberos Key Distribution Center, or KDC. (In this document, we +will refer to both the AS and the TGS as the KDC.) Finally, the +client uses the service ticket to authenticate itself to the +service. + + +The advantage afforded by the TGT is that the client need explicitly +request a ticket and expose his credentials only once. The TGT and +its associated session key can then be used for any subsequent +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, Kerberos authentication exchanges use symmetric-key +cryptography, in part for performance. One cost 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. + + + +3. Extensions + + +This section describes extensions to CLARIFICATIONS for supporting +the use of public-key cryptography in the initial request for a +ticket. + + +Briefly, this document defines the following extensions to +CLARIFICATIONS: + + + 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 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 symmetric encryption key, signed using the KDC's + signature key and encrypted using the client's encryption + key; or + + + b. a key generated through a Diffie-Hellman exchange with + the client, signed using the KDC's signature key. + + + Any keying material required by the client to obtain the + Encryption key is returned in a preauthentication field + accompanying the usual reply. + + + 4. The client obtains the encryption key, decrypts the reply, + and then proceeds as usual. + + +Section 3.1 of this document defines the necessary message formats. +Section 3.2 describes their syntax and use in greater detail. + + + +3.1. Definitions + + + +3.1.1. Required Algorithms + + +All PKINIT implementations MUST support the following algorithms: + + + - Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype. + + + - Signature algorithm: SHA-1 digest and RSA. + + + - Reply key delivery method: ephemeral-ephemeral Diffie-Hellman + with a non-zero nonce. + + + - Unkeyed checksum type for the paChecksum member of + PKAuthenticator: SHA1 (unkeyed). + + + +3.1.2. Defined Message and Encryption Types + + +PKINIT makes use of the following new preauthentication types: + + + PA-PK-AS-REQ TBD + PA-PK-AS-REP TBD + + +PKINIT also makes use of the following new authorization data type: + + + AD-INITIAL-VERIFIED-CAS TBD + + +PKINIT introduces the following new error codes: + + + KDC_ERR_CLIENT_NOT_TRUSTED 62 + KDC_ERR_KDC_NOT_TRUSTED 63 + KDC_ERR_INVALID_SIG 64 + KDC_ERR_KEY_SIZE 65 + KDC_ERR_CERTIFICATE_MISMATCH 66 + KDC_ERR_CANT_VERIFY_CERTIFICATE 70 + KDC_ERR_INVALID_CERTIFICATE 71 + KDC_ERR_REVOKED_CERTIFICATE 72 + KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 + KDC_ERR_CLIENT_NAME_MISMATCH 75 + + +PKINIT uses the following typed data types for errors: + + + TD-DH-PARAMETERS TBD + TD-TRUSTED-CERTIFIERS 104 + TD-CERTIFICATE-INDEX 105 + + +PKINIT defines the following encryption types, for use in the AS-REQ +message (to indicate acceptance of the corresponding encryption OIDs +in PKINIT): + + + dsaWithSHA1-CmsOID 9 + md5WithRSAEncryption-CmsOID 10 + sha1WithRSAEncryption-CmsOID 11 + rc2CBC-EnvOID 12 + rsaEncryption-EnvOID (PKCS1 v1.5) 13 + rsaES-OAEP-EnvOID (PKCS1 v2.0) 14 + des-ede3-cbc-EnvOID 15 + + +The above encryption types are used by the client only within the +KDC-REQ-BODY to indicate which CMS [2] algorithms it supports. Their +use within Kerberos EncryptedData structures is not specified by this +document. + + +The ASN.1 module for all structures defined in this document (plus +IMPORT statements for all imported structures) are given in Appendix +A. All structures MUST be encoded using Distinguished Encoding +Rules (DER). + + + +3.1.3. Algorithm Identifiers + + +PKINIT does not define, but does make use of, the following +algorithm identifiers. + + +PKINIT uses the following algorithm identifier for Diffie-Hellman +key agreement [9]: + + + dhpublicnumber + + +PKINIT uses the following signature algorithm identifiers [8, 12]: + + + sha-1WithRSAEncryption (RSA with SHA1) + md5WithRSAEncryption (RSA with MD5) + id-dsa-with-sha1 (DSA with SHA1) + + +PKINIT uses the following encryption algorithm identifiers [5] 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 [2] for encrypting +the reply key with the temporary key: + + + des-ede3-cbc (three-key 3DES, CBC mode) + rc2-cbc (RC2, CBC mode) + + +Kerberos data structures require the use of integer etypes, while CMS +objects use OIDs. Therefore, each cryptographic algorithm supported +by PKINIT is identified both by a CMS OID and by an equivalent +Kerberos etype (defined in section 3.1.2). + + + +3.2. PKINIT Preauthentication Syntax and Use + + +This section defines the syntax and use of the various +preauthentication fields employed by PKINIT. + + + +3.2.1. Client Request + + +The initial authentication request (AS-REQ) is sent as per RFC +1510bis; in addition, a preauthentication field contains data signed +by the client's private signature key, as follows: + + + PA-PK-AS-REQ ::= SEQUENCE { + signedAuthPack [0] ContentInfo, + -- Defined in CMS [2]. + -- Type is SignedData. + -- Content is AuthPack + -- (defined below). + trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL, + -- A list of CAs, trusted by + -- the client, used to certify + -- KDCs. + kdcCert [2] IssuerAndSerialNumber OPTIONAL, + -- Defined in CMS [2]. + -- Identifies a particular KDC + -- certificate, if the client + -- already has it. + ... + } + + + TrustedCA ::= CHOICE { + caName [0] Name, + -- Fully qualified X.500 name + -- as defined in RFC 3280 [4]. + issuerAndSerial [2] IssuerAndSerialNumber, + -- Identifies a specific CA + -- certificate. + ... + } + + + AuthPack ::= SEQUENCE { + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, + -- Defined in RFC 3280 [4]. + -- Present only if the client + -- is using ephemeral-ephemeral + -- Diffie-Hellman. + supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier + OPTIONAL, + -- List of CMS encryption types + -- supported by client in order + -- of (decreasing) preference. + ... + } + + + PKAuthenticator ::= SEQUENCE { + cusec [0] INTEGER, + ctime [1] KerberosTime, + -- cusec and ctime are used as + -- in CLARIFICATIONS, for replay + -- prevention. + nonce [2] INTEGER (0..4294967295), + -- Binds reply to request, + -- MUST be zero when client + -- will accept cached + -- Diffie-Hellman parameters + -- from KDC. MUST NOT be + -- zero otherwise. + paChecksum [3] Checksum, + -- Defined in CLARIFICATIONS. + -- Performed over KDC-REQ-BODY, + -- MUST be unkeyed. + ... + } + + +The ContentInfo in the signedAuthPack is filled out as follows: + + + 1. The eContent field contains data of type AuthPack. It MUST + contain the pkAuthenticator, and MAY also contain the + client's Diffie-Hellman public value (clientPublicValue). + + + 2. The eContentType field MUST contain the OID value for + id-pkauthdata: { iso(1) org(3) dod(6) internet(1) + security(5) kerberosv5(2) pkinit(3) pkauthdata(1)} + + + 3. The signerInfos field MUST contain the signature over the + AuthPack. + + + 4. The certificates field MUST contain at least a signature + verification certificate chain that the KDC can use to + verify the signature over the AuthPack. Additionally, the + client MAY insert an encryption certificate chain, if + (for example) the client is not using ephemeral-ephemeral + Diffie-Hellman. + + + 5. If a Diffie-Hellman key is being used, the parameters SHOULD + be chosen from the First or Second defined Oakley Groups. + (See RFC 2409 [10].) + + + 6. The KDC may wish to use cached Diffie-Hellman parameters. + To indicate acceptance of caching, the client sends zero in + the nonce field of the pkAuthenticator. Zero is not a valid + value for this field under any other circumstances. Since + zero is used to indicate acceptance of cached parameters, + message binding in this case is performed using only the + nonce in the main request. + + + +3.2.2. Validation of Client Request + + +Upon receiving the client's request, the KDC validates it. This +section describes the steps that the KDC MUST (unless otherwise +noted) take in validating the request. + + +The KDC must look for a client certificate in the signedAuthPack. +If it cannot find one signed by a CA it trusts, it sends back an +error of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying +e-data for this error is a SEQUENCE OF TYPED-DATA (as defined in RFC +1510bis). For this error, the data-type is TD-TRUSTED-CERTIFIERS, +and the data-value is an OCTET STRING containing the DER encoding of + + + TrustedCertifiers ::= SEQUENCE OF Name + + +If, while verifying the certificate chain, the KDC determines that +the signature on one of the certificates in the signedAuthPack is +invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE. +The accompanying e-data for this error is a SEQUENCE OF TYPED-DATA, +whose data-type is TD-CERTIFICATE-INDEX, and whose data-value is an +OCTET STRING containing the DER encoding of the index into the +CertificateSet field, ordered as sent by the client: + + + CertificateIndex ::= IssuerAndSerialNumber + -- IssuerAndSerialNumber of + -- certificate with invalid signature + + +If more than one certificate signature is invalid, the KDC MAY send +one TYPED-DATA per invalid signature. + + +The KDC MAY also check whether any certificates in the client's +chain have been revoked. If any of them have been revoked, the KDC +MUST return an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC +attempts to determine the revocation status but is unable to do so, +it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN. +The certificate or certificates affected are identified exactly as +for an error of type KDC_ERR_INVALID_CERTIFICATE (see above). + + +In addition to validating the certificate chain, the KDC MUST also +check that the certificate properly maps to the client's principal name +as specified in the AS-REQ as follows: + + + 1. If the KDC has its own mapping from the name in the + certificate to a Kerberos name, it uses that Kerberos + name. + + + 2. Otherwise, if the certificate contains a SubjectAltName + extension with a Kerberos name in the otherName field, + it uses that name. The otherName field (of type AnotherName) + in the SubjectAltName extension MUST contain the following: + + + The type-id is: + + + krb5PrincipalName OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6) + internet (1) security (5) kerberosv5 (2) 2 } + + + The value is: + + + KRB5PrincipalName ::= SEQUENCE { + realm [0] Realm, + principalName [1] PrincipalName + } + + +If the KDC does not have its own mapping and there is no Kerberos +name present in the certificate, or if the name in the request does +not match the name in the certificate (including the realm name), or +if there is no name in the request, the KDC MUST return error code +KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data +for this error. + + +Even if the chain is validated, and the names in the certificate and +the request match, the KDC may decide not to trust the client. For +example, the certificate may include an Enxtended Key Usage (EKU) OID +in the extensions field. As a matter of local policy, the KDC may +decide to reject requests on the basis of the absence or presence of +specific EKU OIDs. In this case, the KDC MUST return error code +KDC_ERR_CLIENT_NOT_TRUSTED. The PKINIT EKU OID is defined as: + + + { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) + pkinit(3) pkekuoid(4) } + + +If the client's signature on the signedAuthPack fails to verify, the KDC +MUST return error KDC_ERR_INVALID_SIG. There is no accompanying +e-data for this error. + + +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 clock skew times in CLARIFICATIONS apply here. +If the check fails, the KDC MUSTreturn 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 ephemeral-ephemeral Diffie-Hellman, the KDC checks to +see if the parameters satisfy its policy. If they do not, it MUST +return error code KDC_ERR_KEY_SIZE. The accompanying e-data is a +SEQUENCE OF TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and +whose data-value is an OCTET STRING containing the DER encoding of a +DomainParameters (see [3]), including appropriate Diffie-Hellman +parameters with which to retry the request. + + +The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the +client included a kdcCert field in the PA-PK-AS-REQ and the KDC does +not have the corresponding certificate. + + +The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client +did not include a kdcCert field, but did include a trustedCertifiers +field, and the KDC does not possesses a certificate issued by one of +the listed certifiers. + + +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 of type +KRB5KDC_ERR_ETYPE_NOSUPP. + + + +3.2.3. KDC Reply + + +Assuming that the client's request has been properly validated, the +KDC proceeds as per CLARIFICATIONS, except as follows. + + +The KDC MUST set the initial flag and include an authorization data +of type AD-INITIAL-VERIFIED-CAS in the issued ticket. The value is +an OCTET STRING containing the DER encoding of InitialVerifiedCAs: + + + InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE { + ca [0] Name, + Validated [1] BOOLEAN, + ... + } + + +The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT +containers if the list of CAs satisfies the KDC's realm's policy. +(This corresponds to the TRANSITED-POLICY-CHECKED ticket flag.) +Furthermore, any TGS must copy such authorization data from tickets +used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket, +including the AD-IF-RELEVANT container, if present. + + +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.) 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 AS-REP is otherwise unchanged from CLARIFICATIONS. The KDC +encrypts the reply as usual, but not with the client's long-term +key. Instead, it encrypts it with either a generated encryption +key, or a key derived from a Diffie-Hellman exchange. The contents +of the PA-PK-AS-REP indicate the type of encryption key that was +used: + + + PA-PK-AS-REP ::= CHOICE { + dhSignedData [0] ContentInfo, + -- Type is SignedData. + -- Content is KDCDHKeyInfo + -- (defined below). + encKeyPack [1] ContentInfo, + -- Type is EnvelopedData. + -- Content is SignedData over + -- ReplyKeyPack (defined below). + ... + } + + + KDCDHKeyInfo ::= SEQUENCE { + subjectPublicKey [0] BIT STRING, + -- Equals public exponent + -- (g^a mod p). + -- INTEGER encoded as payload + -- of BIT STRING. + nonce [1] INTEGER, + -- Binds reply to request. + -- Exception: A value of zero + -- indicates that the KDC is + -- using cached values. + dhKeyExpiration [2] KerberosTime OPTIONAL, + -- Expiration time for KDC's + -- cached values. + ... + } + + +The fields of the ContentInfo for dhSignedData are to be filled in +as follows: + + + 1. The eContent field contains data of type KDCDHKeyInfo. + + + 2. The eContentType field contains the OID value for + id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1) + security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) } + + + 3. The signerInfos field contains a single signerInfo, which is + the signature of the KDCDHKeyInfo. + + + 4. The certificates field contains a signature verification + certificate chain that the client will use to verify the + KDC's signature over the KDCDHKeyInfo. This field may only + be left empty if the client did include a kdcCert field in + the PA-PK-AS-REQ, indicating that it has the KDC's + certificate. + + + 5. If the client and KDC agree to use cached parameters, the + KDC MUST return a zero in the nonce field and include the + expiration time of the cached values in the dhKeyExpiration + field. If this time is exceeded, the client MUST NOT use + the reply. If the time is absent, the client MUST NOT use + the reply and MAY resubmit a request with a non-zero nonce, + thus indicating non-acceptance of the cached parameters. + + +The key is derived as follows: Both the KDC and the client calculate +the value g^(ab) mod p, where a and b are the client's and KDC's +private exponents, respectively. They both take the first k bits of +this secret value as a key generation seed, where the parameter k +(the size of the seed) is dependent on the selected key type, as +specified in [6]. The seed is then converted into a protocol key by +applying to it a random-to-key function, which is also dependent on +key type. + + +If the KDC and client are not using Diffie-Hellman, the KDC encrypts +the reply with an encryption key, packed in the encKeyPack, which +contains data of type ReplyKeyPack: + + + ReplyKeyPack ::= SEQUENCE { + replyKey [0] EncryptionKey, + -- Defined in CLARIFICATIONS. + -- Used to encrypt main reply. + -- MUST be at least as strong + -- as session key. (Using the + -- same enctype and a strong + -- prng should suffice, if no + -- stronger encryption system + -- is available.) + nonce [1] INTEGER (0..4294967295), + -- Binds reply to request. + ... + } + + +The fields of the ContentInfo for encKeyPack MUST be filled in as +follows: + + + 1. The content is of type SignedData. The eContent for + the SignedData is of type ReplyKeyPack. + + + 2. The eContentType for the SignedData contains the OID value + for id-pkrkeydata: { iso(1) org(3) dod(6) internet(1) + security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) } + + + 3. The signerInfos field contains a single signerInfo, which is + the signature of the ReplyKeyPack. + + + 4. The certificates field contains a signature verification + certificate chain that the client will use to verify the + KDC's signature over the ReplyKeyPack. This field may only + be left empty if the client included a kdcCert field in the + PA-PK-AS-REQ, indicating that it has the KDC's certificate. + + + 5. The contentType for the EnvelopedData contains the OID value + for id-signedData: { iso (1) member-body (2) us (840) rsadsi + (113549) pkcs (1) pkcs7 (7) signedData (2) } + + + 6. The recipientInfos field is a SET which MUST contain exactly + one member of type KeyTransRecipientInfo. The encryptedKey + for this member contains the temporary key which is + encrypted using the client's public key. + + + 7. The unprotectedAttrs or originatorInfo fields MAY be + present. + + + +3.2.4. Validation of KDC Reply + + +Upon receipt of the KDC's reply, the client proceeds as follows. If +the PA-PK-AS-REP contains a dhSignedData, the client obtains and +verifies the Diffie-Hellman parameters, and obtains the shared key +as described above. Otherwise, the message contains an encKeyPack, +and the client decrypts and verifies the temporary encryption key. + + +In either case, the client MUST check to see if the included +certificate contains a subjectAltName extension of type dNSName or +iPAddress (if the KDC is specified by IP address instead of name). +If it does, it MUST check to see if that extension matches the KDC +it believes it is communicating with, with matching rules specified +in RFC 2459. Exception: If the client has some external information +as to the identity of the KDC, this check MAY be omitted. + + +The client also MUST check that the KDC's certificate contains an +extendedKeyUsage OID of id-pkkdcekuoid: + + + { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) + pkinit(3) pkkdcekuoid(5) } + + +If all applicable checks are satisfied, the client then decrypts the +main reply with the resulting key, and then proceeds as described in +CLARIFICATIONS. + + + +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. + + +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 CLARIFICATIONS. + + +PKINIT allows the use of a zero nonce in the PKAuthenticator when +cached Diffie-Hellman keys are used. In this case, message binding +is performed using the nonce in the main request in the same way as +it is done for ordinary AS-REQs (without the PKINIT +pre-authenticator). The nonce field in the KDC request body is +signed through the checksum in the PKAuthenticator, which +cryptographically binds the PKINIT pre-authenticator to the main +body of the AS Request and also provides message integrity for the +full AS Request. + + +However, when a PKINIT pre-authenticator in the AS-REP has a +zero-nonce, and an attacker has somehow recorded this +pre-authenticator and discovered the corresponding Diffie-Hellman +private key (e.g., with a brute-force attack), the attacker will be +able to fabricate his own AS-REP messages that impersonate the KDC +with this same pre-authenticator. This compromised pre-authenticator +will remain valid as long as its expiration time has not been reached +and it is therefore important for clients to check this expiration +time and for the expiration time to be reasonably short, which +depends on the size of the Diffie-Hellman group. + + +If a client also caches its Diffie-Hellman keys, then the session key +could remain the same during multiple AS-REQ/AS-REP exchanges and an +attacker which compromised the session key could fabricate his own +AS-REP messages with a pre-recorded pre-authenticator until the +client starts using a new Diffie-Hellman key pair and while the KDC +pre-authenticator has not yet expired. It is therefore not +recommended for KDC clients to also cache their Diffie-Hellman keys. + + +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. + + +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. + + +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. [This +seems to reflect the consensus of the Kerberos working group.] + + + +5. Acknowledgements + + +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. Expiration Date + + +This draft expires January 25, 2004. + + + +7. Bibliography + + +[1] RFC-Editor: To be replaced by RFC number for +draft-ietf-krb-wg-kerberos-clarifications. + + +[2] R. Housley. Cryptographic Message Syntax., April 1999. +Request For Comments 2630. + + +[3] W. Polk, R. Housley, and L. Bassham. Algorithms and Identifiers +for the Internet X.509 Public Key Infrastructure Certificate and +Certificate Revocation List (CRL) Profile, April 2002. Request For +Comments 3279. + + +[4] R. Housley, W. Polk, W. Ford, D. Solo. Internet X.509 Public +Key Infrastructure Certificate and Certificate Revocation List +(CRL) Profile, April 2002. Request for Comments 3280. + + +[5] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography +Specifications, October 1998. Request for Comments 2437. + + +[6] RFC-Editor: To be replaced by RFC number for +draft-ietf-krb-wg-crypto. + + +[7] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and +T. Wright. Transport Layer Security (TLS) Extensions, June 2003. +Request for Comments 3546. + + +[8] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams. +Internet X.509 Public Key Infrastructure: Online Certificate Status +Protocol - OCSP, June 1999. Request for Comments 2560. + + +[9] NIST, Guidelines for Implementing and Using the NBS Encryption +Standard, April 1981. FIPS PUB 74. + + +[10] D. Harkins and D. Carrel. The Internet Key Exchange (IKE), +November 1998. Request for Comments 2409. + + + +8. Authors + + +Brian Tung +Clifford Neuman +USC Information Sciences Institute +4676 Admiralty Way Suite 1001 +Marina del Rey CA 90292-6695 +Phone: +1 310 822 1511 +E-mail: {brian,bcn}@isi.edu + + +Matthew Hur +Ari Medvinsky +Microsoft Corporation +One Microsoft Way +Redmond WA 98052 +Phone: +1 425 707 3336 +E-mail: matthur@microsoft.com, arimed@windows.microsoft.com + + +Sasha Medvinsky +Motorola, Inc. +6450 Sequence Drive +San Diego, CA 92121 ++1 858 404 2367 +E-mail: smedvinsky@motorola.com + + +John Wray +Iris Associates, Inc. +5 Technology Park Dr. +Westford, MA 01886 +E-mail: John_Wray@iris.com + + +Jonathan Trostle +E-mail: jtrostle@world.std.com + + + +Appendix A. PKINIT ASN.1 Module + + +KerberosV5-PK-INIT-SPEC { + iso(1) identified-organization(3) dod(6) internet(1) + security(5) kerberosV5(2) modules(4) pkinit(TBD) +} DEFINITIONS EXPLICIT TAGS ::= BEGIN + + + IMPORTS + SubjectPublicKeyInfo, AlgorithmIdentifier, Name + FROM PKIX1Explicit88 { iso (1) identified-organization (3) + dod (6) internet (1) security (5) mechanisms (5) + pkix (7) id-mod (0) id-pkix1-explicit (18) } + + + ContentInfo, IssuerAndSerialNumber + FROM CryptographicMessageSyntax { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) + modules(0) cms(1) } + + + KerberosTime, Checksum, 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-pkdhkeydata 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 ::= TBD + pa-pk-as-rep INTEGER ::= TBD + pa-pk-ocsp-req INTEGER ::= TBD + pa-pk-ocsp-rep INTEGER ::= TBD + + + ad-initial-verified-cas INTEGER ::= TBD + + + td-dh-parameters INTEGER ::= TBD + td-trusted-certifiers INTEGER ::= 104 + td-certificate-index INTEGER ::= 105 + + + PA-PK-AS-REQ ::= SEQUENCE { + signedAuthPack [0] ContentInfo, + trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL, + kdcCert [2] IssuerAndSerialNumber OPTIONAL, + ... + } + + + TrustedCA ::= CHOICE { + caName [0] Name, + issuerAndSerial [2] IssuerAndSerialNumber, + ... + } + + + AuthPack ::= SEQUENCE { + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, + supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier + OPTIONAL, + ... + } + + + PKAuthenticator ::= SEQUENCE { + cusec [0] INTEGER, + ctime [1] KerberosTime, + nonce [2] INTEGER (0..4294967295), + paChecksum [3] Checksum, + ... + } + + + TrustedCertifiers ::= SEQUENCE OF Name + + + CertificateIndex ::= IssuerAndSerialNumber + + + KRB5PrincipalName ::= SEQUENCE { + realm [0] Realm, + principalName [1] PrincipalName + } + + + InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE { + ca [0] Name, + validated [1] BOOLEAN, + ... + } + + + PA-PK-AS-REP ::= CHOICE { + dhSignedData [0] ContentInfo, + encKeyPack [1] ContentInfo, + ... + } + + + KDCDHKeyInfo ::= SEQUENCE { + subjectPublicKey [0] BIT STRING, + nonce [1] INTEGER, + dhKeyExpiration [2] KerberosTime OPTIONAL, + ... + } + + + ReplyKeyPack ::= SEQUENCE { + replyKey [0] EncryptionKey, + nonce [1] INTEGER (0..4294967295), + ... + } + + +END + + +Copyright (C) The Internet Society (2004). 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. + + +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. \ No newline at end of file diff --git a/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-02.txt b/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-02.txt new file mode 100644 index 000000000..a25d8096c --- /dev/null +++ b/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-02.txt @@ -0,0 +1,1793 @@ + +Kerberos Working Group Nicolas Williams +INTERNET-DRAFT Sun Microsystems +Category: Standards Track Jonathan Trostle + Cisco Systems + + + + 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 January 12, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2004). 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 et. al. [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 et. al. [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 et. al. [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 et. al. [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 et. al. [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 et. al. [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 et. al. [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 et. al. [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 et. al. [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 et. al. [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 et. al. [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 et. al. [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 et. al. [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 et. al. [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 et. al. [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 et. al. [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 et. al. [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 et. al. [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 et. al. [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 et. al. [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 et. al. [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 et. al. [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 et. al. [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 et. al. [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 et. al. [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 et. al. [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 et. al. [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 et. al. [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 et. al. [Page 29] + +DRAFT Kerberos Set/Change Password v2 Expires January 2005 + + Email: nicolas.williams@sun.com + + Jonathan Trostle + Cisco Systems + 170 W. Tasman Dr. + San Jose, CA 95134 + Email: jtrostle@cisco.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 et. al. [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 (2004). 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. + + + + + + + + +N. Williams et. al. [Page 31] + diff --git a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-01.txt b/doc/standardisation/draft-ietf-krb-wg-preauth-framework-01.txt new file mode 100644 index 000000000..a98e7e658 --- /dev/null +++ b/doc/standardisation/draft-ietf-krb-wg-preauth-framework-01.txt @@ -0,0 +1,1165 @@ +Kerberos Working Group S. Hartman +Internet-Draft MIT +Expires: January 17, 2005 July 19, 2004 + + + + A Generalized Framework for Kerberos Pre-Authentication + draft-ietf-krb-wg-preauth-framework-01 + + +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 January 17, 2005. + + +Copyright Notice + + + Copyright (C) The Internet Society (2004). All Rights Reserved. + + +Abstract + + + Kerberos is a protocol for verifying the identity of principals + (e.g., a workstation user or a network server) on an open network. + The Kerberos protocol provides a mechanism called pre-authentication + for proving the identity of a principal and for better protecting + the long-term secret of the principal. + + + This document describes a model for Kerberos pre-authentication + mechanisms. The model describes what state in the Kerberos request a + pre-authentication mechanism is likely to change. It also describes + how multiple pre-authentication mechanisms used in the same request + will interact. + + + + +Hartman Expires January 17, 2005 [Page 1] +Internet-Draft Kerberos Preauth Framework July 2004 + + + + This document also provides common tools needed by multiple + pre-authentication mechanisms. + + + 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 [1]. + + +Table of Contents + + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Model for Pre-Authentication . . . . . . . . . . . . . . . . . 4 + 2.1 Information Managed by Model . . . . . . . . . . . . . . . 5 + 2.2 The Preauth_Required Error . . . . . . . . . . . . . . . . 7 + 2.3 Client to KDC . . . . . . . . . . . . . . . . . . . . . . 7 + 2.4 KDC to Client . . . . . . . . . . . . . . . . . . . . . . 8 + 3. Pre-Authentication Facilities . . . . . . . . . . . . . . . . 9 + 3.1 Client Authentication . . . . . . . . . . . . . . . . . . 10 + 3.2 Strengthen Reply Key . . . . . . . . . . . . . . . . . . . 10 + 3.3 Replace Reply Key . . . . . . . . . . . . . . . . . . . . 11 + 3.4 Verify Response . . . . . . . . . . . . . . . . . . . . . 11 + 4. Requirements for Pre-Authentication Mechanisms . . . . . . . . 12 + 5. Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 13 + 5.1 Combine Keys . . . . . . . . . . . . . . . . . . . . . . . 13 + 5.2 Signing Requests/Responses . . . . . . . . . . . . . . . . 13 + 5.3 Managing State for the KDC . . . . . . . . . . . . . . . . 13 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 17 + 9.2 Informative References . . . . . . . . . . . . . . . . . . . 17 + A. Todo List . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + Intellectual Property and Copyright Statements . . . . . . . . 19 + + + + + + + + + + + + + + + + + + +Hartman Expires January 17, 2005 [Page 2] +Internet-Draft Kerberos Preauth Framework July 2004 + + + +1. Introduction + + + The core Kerberos specification treats pre-authentication data as an + opaque typed hole in the messages to the KDC that may influence the + reply key used to encrypt the KDC response. This generality has been + useful: pre-authentication data is used for a variety of extensions + to the protocol, many outside the expectations of the initial + designers. However, this generality makes designing the more common + types of pre-authentication mechanisms difficult. Each mechanism + needs to specify how it interacts with other mechanisms. Also, + problems like combining a key with the long-term secret or proving + the identity of the user are common to multiple mechanisms. Where + there are generally well-accepted solutions to these problems, it is + desirable to standardize one of these solutions so mechanisms can + avoid duplication of work. In other cases, a modular approach to + these problems is appropriate. The modular approach will allow new + and better solutions to common pre-authentication problems to be used + by existing mechanisms as they are developed. + + + This document specifies a framework for Kerberos pre-authentication + mechanisms. IT defines the common set of functions + pre-authentication mechanisms perform as well as how these functions + affect the state of the request and response. In addition several + common tools needed by pre-authentication mechanisms are provided. + Unlike [3], this framework is not complete--it does not describe all + the inputs and outputs for the pre-authentication mechanisms. + Mechanism designers should try to be consistent with this framework + because doing so will make their mechanisms easier to implement. + Kerberos implementations are likely to have plugin architectures for + pre-authentication; such architectures are likely to support + mechanisms that follow this framework plus commonly used extensions. + + + This document should be read only after reading the documents + describing the Kerberos cryptography framework [3] and the core + Kerberos protocol [2]. This document freely uses terminology and + notation from these documents without reference or further + explanation. + + + + + + + + + + + + + + + +Hartman Expires January 17, 2005 [Page 3] +Internet-Draft Kerberos Preauth Framework July 2004 + + + +2. Model for Pre-Authentication + + + when a Kerberos client wishes to obtain a ticket using the + authentication server, it sends an initial AS request. If + pre-authentication is being used, then the KDC will respond with a + KDC_ERR_PREAUTH_REQUIRED error. Alternatively, if the client knows + what pre-authentication to use, it MAY optimize a round-trip and send + an initial request with padata included. If the client includes the + wrong padata, the server MAY return KDC_ERR_PREAUTH_FAILED with no + indication of what padata should have been included. For + interoperability reasons, clients that include optimistic + pre-authentication MUST retry with no padata and examine the + KDC_ERR_PREAUTH_REQUIRED if they receive a KDC_ERR_PREAUTH_FAILED in + response to their initial optimistic request. + + + The KDC maintains no state between two requests; subsequent requests + may even be processed by a different KDC. On the other hand, the + client treats a series of exchanges with KDCs as a single + authentication session. Each exchange accumulates state and + hopefully brings the client closer to a successful authentication. + + + These models for state management are in apparent conflict. For many + of the simpler pre-authentication scenarios, the client uses one + round trip to find out what mechanisms the KDC supports. Then the + next request contains sufficient pre-authentication for the KDC to be + able to return a successful response. For these simple scenarios, + the client only sends one request with pre-authentication data and so + the authentication session is trivial. For more complex + authentication sessions, the KDC needs to provide the client with a + cookie to include in future requests to capture the current state of + the authentication session. Handling of multiple round-trip + mechanisms is discussed in Section 5.3. + + + This framework specifies the behavior of Kerberos pre-authentication + mechanisms used to identify users or to modify the reply key used to + encrypt the KDC response. The padata typed hole may be used to carry + extensions to Kerberos that have nothing to do with proving the + identity of the user or establishing a reply key. These extensions + are outside the scope of this framework. However mechanisms that do + accomplish these goals should follow this framework. + + + This framework specifies the minimum state that a Kerberos + implementation needs to maintain while handling a request in order to + process pre-authentication. It also specifies how Kerberos + implementations process the pre-authentication data at each step of + the AS request process. + + + + + + +Hartman Expires January 17, 2005 [Page 4] +Internet-Draft Kerberos Preauth Framework July 2004 + + + +2.1 Information Managed by Model + + + The following information is maintained by the client and KDC as each + request is being processed: + o The reply key used to encrypt the KDC response + o How strongly the identity of the client has been authenticated + o Whether the reply key has been used in this authentication session + o Whether the reply key has been replaced in this authentication + session + o Whether the contents of the KDC response can be verified by the + client principal + o Whether the contents of the KDC response can be verified by the + client machine + + + Conceptually, the reply key is initially the long-term key of the + principal. However, principals can have multiple long-term keys + because of support for multiple encryption types, salts and + string2key parameters. As described in section 5.2.7.5 of the + Kerberos protocol [2], the KDC sends PA-ETYPe-INFO2 to notify the + client what types of keys are available. Thus in full generality, + the reply key in the pre-authentication model is actually a set of + keys. At the beginning of a request, it is initialized to the set of + long-term keys advertised in the PA-ETYPE-INFO2 element on the KDC. + If multiple reply keys are available, the client chooses which one to + use. Thus the client does not need to treat the reply key as a set. + At the beginning of a handling a request, the client picks a reply + key to use. + + + KDC implementations MAY choose to offer only one key in the + PA-ETYPE-INFO2 element. Since the KDC already knows the client's + list of supported enctypes from the request, no interoperability + problems are created by choosing a single possible reply key. This + way, the KDC implementation avoids the complexity of treating the + reply key as a set. + + + At the beginning of handling a message on both the client and KDC, + the client's identity is not authenticated. A mechanism may indicate + that it has successfully authenticated the client's identity. This + information is useful to keep track of on the client in order to + know what pre-authentication mechanisms should be used. The KDC + needs to keep track of whether the client is authenticated because + the primary purpose of pre-authentication is to authenticate the + client identity before issuing a ticket. Implementations that have + pre-authentication mechanisms offering significantly different + strengths of client authentication MAY choose to keep track of the + strength of the authentication used as an input into policy + decisions. For example, some principals might require strong + pre-authentication, while less sensitive principals can use + + + + +Hartman Expires January 17, 2005 [Page 5] +Internet-Draft Kerberos Preauth Framework July 2004 + + + + relatively weak forms of pre-authentication like encrypted timestamp. + + + Initially the reply key has not been used. A pre-authentication + mechanism that uses the reply key either directly to encrypt or + checksum some data or indirectly in the generation of new keys MUST + indicate that the reply key is used. This state is maintained by the + client and KDC to enforce the security requirement stated in Section + 3.3 that the reply key cannot be replaced after it is used. + + + Initially the reply key has not been replaced. If a mechanism + implements the Replace Reply Key facility discussed in Section 3.3, + then the state MUST be updated to indicate that the reply key has + been replaced. Once the reply key has been replaced, knowledge of the + reply key is insufficient to authenticate the client. The reply key + is marked replaced in exactly the same situations as the KDC reply + is marked as not being verified to the client principal. However, + while mechanisms can verify the KDC request to the client, once the + reply key is replaced, then the reply key remains replaced for the + remainder of the authentication session. + + + Without pre-authentication, the client knows that the KDC request is + authentic and has not been modified because it is encrypted in the + long-term key of the client. Only the KDC and client know that key. + So at the start of handling any message the KDC request is presumed + to be verified to the client principal. Any pre-authentication + mechanism that sets a new reply key not based on the principal's + long-term secret MUST either verify the KDC response some other way + or indicate that the response is not verified. If a mechanism + indicates that the response is not verified then the client + implementation MUST return an error unless a subsequent mechanism + verifies the response. The KDC needs to track this state so it can + avoid generating a response that is not verified. + + + The typical Kerberos request does not provide a way for the client + machine to know that it is talking to the correct KDC. Someone who + can inject packets into the network between the client machine and + the KDC and who knows the password that the user will give to the + client machine can generate a KDC response that will decrypt + properly. So, if the client machine needs to authenticate that the + user is in fact the named principal, then the client machine needs to + do a TGS request for itself as a service. Some pre-authentication + mechanisms may provide a way for the client to authenticate the KDC. + Examples of this include signing the response with a well-known + public key or providing a ticket for the client machine as a service + in addition to the requested ticket. + + + + + + + +Hartman Expires January 17, 2005 [Page 6] +Internet-Draft Kerberos Preauth Framework July 2004 + + + +2.2 The Preauth_Required Error + + + Typically a client starts an authentication session by sending an + initial request with no pre-authentication. If the KDC requires + pre-authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED + message. This message MAY also be returned for pre-authentication + configurations that use multi-round-trip mechanisms. This error + contains a sequence of padata. Typically the padata contains the + pre-authentication type IDs of all the available pre-authentication + mechanisms. IN the initial error response, most mechanisms do not + contain data. If a mechanism requires multiple round trips or starts + with a challenge from the KDC to the client, then it will likely + contain data in the initial error response. + + + The KDC SHOULD NOT send data that is encrypted in the long-term + password-based key of the principal. Doing so has the same security + exposures as the Kerberos protocol without pre-authentication. There + are few situations where pre-authentication is desirable and where + the KDC needs to expose ciphertext encrypted in a weak key before the + client has proven knowledge of that key. + + + In order to generate the error response, the KDC first starts by + initializing the pre-authentication state. Then it processes any + padata in the client's request in the order provided by the client. + Mechanisms that are not understood by the KDC are ignored. + Mechanisms that are inappropriate for the client principal or request + SHOULD also be ignored. Next, it generates padata for the error + response, modifying the pre-authentication state appropriately as + each mechanism is processed. The KDC chooses the order in which it + will generated padata (and thus the order of padata in the response), + but it needs to modify the pre-authentication state consistently with + the choice of order. For example, if some mechanism establishes an + authenticated client identity, then the mechanisms subsequent in the + generated response receive this state as input. After the padata is + generated, the error response is sent. + + +2.3 Client to KDC + + + This description assumes a client has already received a + KDC_ERR_PREAUTH_REQUIRED from the KDC. If the client performs + optimistic pre-authentication then the client needs to optimisticly + choose the information it would normally receive from that error + response. + + + The client starts by initializing the pre-authentication state as + specified. It then processes the pdata in the + KDC_ERR_PREAUTH_REQUIRED. + + + + + +Hartman Expires January 17, 2005 [Page 7] +Internet-Draft Kerberos Preauth Framework July 2004 + + + + After processing the pdata in the KDC error, the client generates a + new request. It processes the pre-authentication mechanisms in the + order in which they will appear in the next request, updating the + state as appropriate. When the request is complete it is sent. + + +2.4 KDC to Client + + + When a KDC receives an AS request from a client, it needs to + determine whether it will respond with an error or a AS reply. + There are many causes for an error to be generated that have nothing + to do with pre-authentication; they are discussed in the Kerberos + specification. + + + From the standpoint of evaluating the pre-authentication, the KDC + first starts by initializing the pre-authentication state. IT then + processes the padata in the request. AS mentioned in Section 2.2, + the KDC MAY ignore padata that is inappropriate for the configuration + and MUST ignore padata of an unknown type. + + + At this point the KDC decides whether it will issue a + pre-authentication required error or a reply. Typically a KDC will + issue a reply if the client's identity has been authenticated to a + sufficient degree. The processing of the pre-authentication required + error is described in Section 2.2. + + + The KDC generates the pdata modifying the pre-authentication state as + necessary. Then it generates the final response, encrypting it in + the current pre-authentication reply key. + + + + + + + + + + + + + + + + + + + + + + + + +Hartman Expires January 17, 2005 [Page 8] +Internet-Draft Kerberos Preauth Framework July 2004 + + + +3. Pre-Authentication Facilities + + + Pre-Authentication mechanisms can be thought of as providing various + conceptual facilities. This serves two useful purposes. First, + mechanism authors can choose only to solve one specific small + problem. It is often useful for a mechanism designed to offer key + management not to directly provide client authentication but instead + to allow one or more other mechanisms to handle this need. Secondly, + thinking about the abstract services that a 2mechanism provides + yields a minimum set of security requirements that all mechanisms + providing that facility must meet. These security requirements are + not complete; mechanisms will have additional security requirements + based on the specific protocol they employ. + + + A mechanism is not constrained to only offering one of these + facilities. While such mechanisms can be designed and are sometimes + useful, many pre-authentication mechanisms implement several + facilities. By combining multiple facilities in a single mechanism, + it is often easier to construct a secure, simple solution than by + solving the problem in full generality. Even when mechanisms provide + multiple facilities, they need to meet the security requirements for + all the facilities they provide. + + + According to Kerberos extensibility rules (section 1.4.2 of the + Kerberos specification [2]), an extension MUST NOT change the + semantics of a message unless a recipient is known to understand that + extension. Because a client does not know that the KDC supports a + particular pre-authentication mechanism when it sends an initial + request, a preauth mechanism MUST NOT change the semantics of the + request in a way that will break a KDC that does not understand that + mechanism. Similarly, KDCs MUST not send messages to clients that + affect the core semantics unless the clients have indicated support + for the message. + + + The only state in this model that would break the interpretation of a + message is changing the expected reply key. If one mechanism changed + the reply key and a later mechanism used that reply key, then a KDC + that interpreted the second mechanism but not the first would fail to + interpret the request correctly. In order to avoid this problem, + extensions that change core semantics are typically divided into two + parts. The first part proposes a change to the core semantic--for + example proposes a new reply key. The second part acknowledges that + the extension is understood and that the change takes effect. Section + 3.2 discusses how to design mechanisms that modify the reply key to + be split into a proposal and acceptance without requiring additional + round trips to use the new reply key in subsequent + pre-authentication. Other changes in the state described in Section + 2.1 can safely be ignored by a KDC that does not understand a + + + + +Hartman Expires January 17, 2005 [Page 9] +Internet-Draft Kerberos Preauth Framework July 2004 + + + + mechanism. Mechanisms that modify the behavior of the request + outside the scope of this framework need to carefully consider the + Kerberos extensibility rules to avoid similar problems. + + +3.1 Client Authentication + + + The client authentication facility proves the identity of a user to + the KDC before a ticket is issued. Examples of mechanisms + implementing this facility include the encrypted timestamp facility + defined in Section 5.2.7.2 of the Kerberos specification [2] and the + single-use mechanism defined in [5]. Mechanisms that provide this + facility are expected to mark the client as authenticated. + + + Mechanisms implementing this facility SHOULD require the client to + prove knowledge of the reply key before transmitting a successful + KDC reply. Otherwise, an attacker can intercept the + pre-authentication exchange and get a reply to attack. One way of + proving the client knows the reply key is to implement the Replace + Reply Key facility along with this facility. The Pkinit mechanism + [6] implements Client Authentication along side Replace Reply Key. + + + If the reply key has been replaced, then mechanisms such as encrypted + timestamp that rely on knowledge of the reply key to authenticate the + client MUST NOT be used. + + +3.2 Strengthen Reply Key + + + Particularly, when dealing with keys based on passwords, it is + desirable to increase the strength of the key by adding additional + secrets to it. Examples of sources of additional secrets include the + results of a Diffie-Hellman key exchange or key bits from the output + of a smart card [5]. Typically these additional secrets are + converted into a Kerberos protocol key. Then they are combined with + the existing reply key as discussed in Section 5.1. + + + If a mechanism implementing this facility wishes to modify the reply + key before knowing that the other party in the exchange supports the + mechanism, it proposes modifying the reply key. The other party then + includes a message indicating that the proposal is accepted if it is + understood and meets policy. In many cases it is desirable to use + the new reply key for client authentication and for other facilities. + Waiting for the other party to accept the proposal and actually + modify the reply key state would add an additional round trip to the + exchange. Instead, mechanism designers are encouraged to include a + typed hole for additional padata in the message that proposes the + reply key change. The padata included in the typed hole are + generated assuming the new reply key. If the other party accepts the + proposal, then these padata are interpreted as if they were included + + + + +Hartman Expires January 17, 2005 [Page 10] +Internet-Draft Kerberos Preauth Framework July 2004 + + + + immediately following the proposal. The party generating the + proposal can determine whether the padata were processed based on + whether the proposal for the reply key is accepted. + + + The specific formats of the proposal message, including where padata + are are included is a matter for the mechanism specification. + Similarly, the format of the message accepting the proposal is + mechanism-specific. + + + Mechanisms implementing this facility and including a typed hole for + additional padata MUST checksum that padata using a keyed checksum or + encrypt the padata. Typically the reply key is used to protect the + padata. XXX If you are only minimally increasing the strength of the + reply key, this may give the attacker access to something too close + to the original reply key. However, binding the padata to the new + reply key seems potentially important from a security standpoint. + There may also be objections to this from a double encryption + standpoint because we also recommend client authentication facilities + be tied to the reply key. + + +3.3 Replace Reply Key + + + The Replace Reply Key facility replaces the key in which a successful + AS reply will be encrypted. This facility can only be used in + cases where knowledge of the reply key is not used to authenticate + the client. The new reply key MUST be communicated to the client and + KDC in a secure manner. Mechanisms implementing this facility MUST + mark the reply key as replaced in the pre-authentication state. + Mechanisms implementing this facility MUST either provide a mechanism + to verify the KDC reply to the client or mark the reply as unverified + in the pre-authentication state. Mechanisms implementing this + facility SHOULD NOT be used if a previous mechanism has used the + reply key. + + + As with the Strengthen Reply Key facility, Kerberos extensibility + rules require that the reply key not be changed unless both sides of + the exchange understand the extension. In the case of this facility + it will likely be more common for both sides to know that the + facility is available by the time that the new key is available to be + used. However, mechanism designers can use a container for padata in + a proposal message as discussed in Section 3.2 if appropriate. + + +3.4 Verify Response + + + + + + + + + +Hartman Expires January 17, 2005 [Page 11] +Internet-Draft Kerberos Preauth Framework July 2004 + + + +4. Requirements for Pre-Authentication Mechanisms + + + State management for multi-round-trip mechs + Security interactions with other mechs + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hartman Expires January 17, 2005 [Page 12] +Internet-Draft Kerberos Preauth Framework July 2004 + + + +5. Tools for Use in Pre-Authentication Mechanisms + + +5.1 Combine Keys + + +5.2 Signing Requests/Responses + + +5.3 Managing State for the KDC + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hartman Expires January 17, 2005 [Page 13] +Internet-Draft Kerberos Preauth Framework July 2004 + + + +6. IANA Considerations + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hartman Expires January 17, 2005 [Page 14] +Internet-Draft Kerberos Preauth Framework July 2004 + + + +7. Security Considerations + + + Very little of the AS request is authenticated. Same for padata + in the reply or error. Discuss implications + Table of security requirements stated elsewhere in the document + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hartman Expires January 17, 2005 [Page 15] +Internet-Draft Kerberos Preauth Framework July 2004 + + + +8. Acknowledgements + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hartman Expires January 17, 2005 [Page 16] +Internet-Draft Kerberos Preauth Framework July 2004 + + + +9. References + + +9.1 Normative References + + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", RFC 2119, BCP 14, March 1997. + + + [2] Neuman, C., Yu, T., Hartman, S. and K. Raeburn, "The Kerberos + Network Authentication Service (V5)", + draft-ietf-krb-wg-kerberos-clarifications-06.txt (work in + progress), June 2004. + + + [3] Raeburn, K., "Encryption and Checksum Specifications for + Kerberos 5", draft-ietf-krb-wg-crypto-03.txt (work in progress). + + + [4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC + 2279, January 1998. + + +9.2 Informative References + + + [5] Hornstein, K., Renard, K., Neuman, C. and G. Zorn, "Integrating + Single-use Authentication Mechanisms with Kerberos", + draft-ietf-krb-wg-kerberos-sam-02.txt (work in progress), + October 2003. + + + [6] Tung, B., Neuman, C., Hur, M., Medvinsky, A. and S. Medvinsky, + "Public Key Cryptography for Initial Authentication in + Kerberos", draft-ietf-cat-kerberos-pk-init-19.txt (work in + progress), April 2004. + + + +Author's Address + + + Sam hartman + MIT + + + EMail: hartmans@mit.edu + + + + + + + + + + + + + + + +Hartman Expires January 17, 2005 [Page 17] +Internet-Draft Kerberos Preauth Framework July 2004 + + + +Appendix A. Todo List + + + Flesh out sections that are still outlines + Discuss cookies and multiple-round-trip mechanisms. + Talk about checksum contributions from each mechanism + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hartman Expires January 17, 2005 [Page 18] +Internet-Draft Kerberos Preauth Framework July 2004 + + + +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 IETF's procedures with respect to rights in IETF 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 (2004). 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. + + + + +Hartman Expires January 17, 2005 [Page 19] \ No newline at end of file