diff options
Diffstat (limited to 'third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-23.txt')
| -rw-r--r-- | third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-23.txt | 1511 |
1 files changed, 1511 insertions, 0 deletions
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-23.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-23.txt new file mode 100644 index 00000000000..f0cd9cac4c3 --- /dev/null +++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-init-23.txt @@ -0,0 +1,1511 @@ + + + +NETWORK WORKING GROUP B. Tung +Internet-Draft USC Information Sciences Institute +Expires: August 4, 2005 L. Zhu + Microsoft Corporation + January 31, 2005 + + + Public Key Cryptography for Initial Authentication in Kerberos + draft-ietf-cat-kerberos-pk-init + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of Section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on August 4, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document describes protocol extensions (hereafter called PKINIT) + to the Kerberos protocol specification. These extensions provide a + method for integrating public key cryptography into the initial + authentication exchange, by passing digital certificates and + associated authenticators in pre-authentication data fields. + + + +Tung & Zhu Expires August 4, 2005 [Page 1] + +Internet-Draft PKINIT January 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 + 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1 Definitions, Requirements, and Constants . . . . . . . . . 4 + 3.1.1 Required Algorithms . . . . . . . . . . . . . . . . . 4 + 3.1.2 Defined Message and Encryption Types . . . . . . . . . 5 + 3.1.3 Algorithm Identifiers . . . . . . . . . . . . . . . . 6 + 3.2 PKINIT Pre-authentication Syntax and Use . . . . . . . . . 6 + 3.2.1 Generation of Client Request . . . . . . . . . . . . . 7 + 3.2.2 Receipt of Client Request . . . . . . . . . . . . . . 9 + 3.2.3 Generation of KDC Reply . . . . . . . . . . . . . . . 12 + 3.2.4 Receipt of KDC Reply . . . . . . . . . . . . . . . . . 17 + 3.3 KDC Indication of PKINIT Support . . . . . . . . . . . . . 18 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 7.1 Normative References . . . . . . . . . . . . . . . . . . . 20 + 7.2 Informative References . . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 + A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 21 + Intellectual Property and Copyright Statements . . . . . . . . 27 + + + + + + + + + + + + + + + + + + + + + + + + + + + +Tung & Zhu Expires August 4, 2005 [Page 2] + +Internet-Draft PKINIT January 2005 + + +1. Introduction + + A client typically authenticates itself to a service in Kerberos + using three distinct though related exchanges. First, the client + requests a ticket-granting ticket (TGT) from the Kerberos + authentication server (AS). Then, it uses the TGT to request a + service ticket from the Kerberos ticket-granting server (TGS). + Usually, the AS and TGS are integrated in a single device known as a + Kerberos Key Distribution Center, or KDC. (In this document, 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 exposes his + long-term secrets only once. The TGT and its associated session key + can then be used for any subsequent service ticket requests. One + result of this is that all further authentication is independent of + the method by which the initial authentication was performed. + Consequently, initial authentication provides a convenient place to + integrate public-key cryptography into Kerberos authentication. + + As defined in [CLAR], Kerberos authentication exchanges use + symmetric-key cryptography, in part for performance. One + disadvantage of using symmetric-key cryptography is that the keys + must be shared, so that before a client can authenticate itself, he + must already be registered with the KDC. + + Conversely, public-key cryptography (in conjunction with an + established Public Key Infrastructure) permits authentication without + prior registration with a KDC. Adding it to Kerberos allows the + widespread use of Kerberized applications by clients without + requiring them to register first with a KDC--a requirement that has + no inherent security benefit. + + As noted above, a convenient and efficient place to introduce + public-key cryptography into Kerberos is in the initial + authentication exchange. This document describes the methods and + data formats for integrating public-key cryptography into Kerberos + initial authentication. + +2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + + + + + + +Tung & Zhu Expires August 4, 2005 [Page 3] + +Internet-Draft PKINIT January 2005 + + +3. Extensions + + This section describes extensions to [CLAR] for supporting the use of + public-key cryptography in the initial request for a ticket. + + Briefly, this document defines the following extensions to [CLAR]: + + 1. The client indicates the use of public-key authentication by + including a special preauthenticator in the initial request. This + preauthenticator contains the client's public-key data and a + signature. + + 2. The KDC tests the client's request against its authentication + policy and trusted Certification Authorities (CAs). + + 3. If the request passes the verification tests, the KDC replies as + usual, but the reply is encrypted using either: + + a. a key generated through a Diffie-Hellman (DH) key exchange + [RFC2631] with the client, signed using the KDC's signature + key; or + + b. a symmetric encryption key, signed using the KDC's signature + key and encrypted using the client's public key. + + Any keying material required by the client to obtain the + encryption key for decrypting the KDC reply is returned in a + pre-authentication field accompanying the usual reply. + + 4. The client obtains the encryption key, decrypts the reply, and + then proceeds as usual. + + Section 3.1 of this document enumerates the required algorithms and + necessary extension message types. Section 3.2 describes the + extension messages in greater detail. + +3.1 Definitions, Requirements, and Constants + +3.1.1 Required Algorithms + + All PKINIT implementations MUST support the following algorithms: + + o AS reply key: AES256-CTS-HMAC-SHA1-96 etype [KCRYPTO]. + + o Signature algorithm: sha-1WithRSAEncryption [RFC3279]. + + o KDC AS reply key delivery method: ephemeral-ephemeral + Diffie-Hellman exchange (Diffie-Hellman keys are not cached). + + + +Tung & Zhu Expires August 4, 2005 [Page 4] + + + +3.1.2 Defined Message and Encryption Types + + PKINIT makes use of the following new pre-authentication types: + + PA-PK-AS-REQ 16 + PA-PK-AS-REP 17 + + PKINIT also makes use of the following new authorization data type: + + AD-INITIAL-VERIFIED-CAS 9 + + PKINIT introduces the following new error codes: + + KDC_ERR_CLIENT_NOT_TRUSTED 62 + KDC_ERR_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-TRUSTED-CERTIFIERS 104 + TD-CERTIFICATE-INDEX 105 + TD-DH-PARAMETERS 109 + + PKINIT defines the following encryption types, for use in the AS-REQ + message (to indicate acceptance of the corresponding encryption + Object Identifiers (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 Cryptographic Message Syntax (CMS) + [RFC3852] 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 + + + +Tung & Zhu Expires August 4, 2005 [Page 5] + +Internet-Draft PKINIT January 2005 + + + Appendix A. + + All structures defined in or imported into this document MUST be + encoded using Distinguished Encoding Rules (DER) [X690]. All data + structures wrapped in OCTET STRINGs must be encoded according to the + rules specified in corresponding specifications. + + Interoperability note: Some implementations may not be able to decode + CMS objects encoded with BER but not DER; specifically, they may not + be able to decode infinite length encodings. To maximize + interoperability, implementers SHOULD encode CMS objects used in + PKINIT with DER. + +3.1.3 Algorithm Identifiers + + PKINIT does not define, but does make use of, the following algorithm + identifiers. + + PKINIT uses the following algorithm identifier for Diffie-Hellman key + agreement [RFC3279]: + + dhpublicnumber + + PKINIT uses the following signature algorithm identifiers [RFC3279]: + + sha-1WithRSAEncryption (RSA with SHA1) + md5WithRSAEncryption (RSA with MD5) + id-dsa-with-sha1 (DSA with SHA1) + + PKINIT uses the following encryption algorithm identifiers [RFC3447] + for encrypting the temporary key with a public key: + + rsaEncryption (PKCS1 v1.5) + id-RSAES-OAEP (PKCS1 v2.0) + + PKINIT uses the following algorithm identifiers [RFC3370][RFC3565] + for encrypting the reply key with the temporary key: + + des-ede3-cbc (three-key 3DES, CBC mode) + rc2-cbc (RC2, CBC mode) + id-aes256-CBC (AES-256, CBC mode) + + +3.2 PKINIT Pre-authentication Syntax and Use + + This section defines the syntax and use of the various + pre-authentication fields employed by PKINIT. + + + + +Tung & Zhu Expires August 4, 2005 [Page 6] + +Internet-Draft PKINIT January 2005 + + +3.2.1 Generation of Client Request + + The initial authentication request (AS-REQ) is sent as per [CLAR]; in + addition, a pre-authentication field contains data signed by the + client's private signature key, as follows: + + PA-PK-AS-REQ ::= SEQUENCE { + signedAuthPack [0] IMPLICIT OCTET STRING, + -- Contains a CMS type ContentInfo encoded + -- according to [RFC3852]. + -- The contentType field of the type ContentInfo + -- is id-signedData (1.2.840.113549.1.7.2), + -- and the content field is a SignedData. + -- The eContentType field for the type SignedData is + -- id-pkauthdata (1.3.6.1.5.2.3.1), and the + -- eContent field contains the DER encoding of the + -- type AuthPack. + -- AuthPack is defined below. + trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL, + -- A list of CAs, trusted by the client, that can + -- be used to validate KDC certificates. + kdcCert [2] IMPLICIT OCTET STRING + OPTIONAL, + -- Contains a CMS type IssuerAndSerialNumber encoded + -- according to [RFC3852]. + -- Identifies a particular KDC certificate, if the + -- client already has it. + ... + } + + DHNonce ::= OCTET STRING + + TrustedCA ::= CHOICE { + caName [1] IMPLICIT OCTET STRING, + -- Contains a PKIX type Name encoded according to + -- [RFC3280]. + issuerAndSerial [2] IMPLICIT OCTET STRING, + -- Contains a CMS type IssuerAndSerialNumber encoded + -- according to [RFC3852]. + -- Identifies a specific CA certificate. + ... + } + + AuthPack ::= SEQUENCE { + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, + -- Defined in [RFC3280]. + -- Present only if the client wishes to use the + + + +Tung & Zhu Expires August 4, 2005 [Page 7] + +Internet-Draft PKINIT January 2005 + + + -- Diffie-Hellman key agreement method. + supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier + OPTIONAL, + -- List of CMS encryption types supported by + -- client in order of (decreasing) preference. + clientDHNonce [3] DHNonce OPTIONAL, + -- Present only if the client indicates that it + -- wishes to cache DH keys or to allow the KDC to + -- do so. + ... + } + + PKAuthenticator ::= SEQUENCE { + cusec [0] INTEGER (0..999999), + ctime [1] KerberosTime, + -- cusec and ctime are used as in [CLAR], for replay + -- prevention. + nonce [2] INTEGER (0..4294967295), + -- Chosen randomly; This nonce does not need to + -- match with the nonce in the KDC-REQ-BODY. + paChecksum [3] OCTET STRING, + -- Contains the SHA1 checksum, performed over + -- KDC-REQ-BODY. + ... + } + + The ContentInfo [RFC3852] structure for the signedAuthPack field is + filled out as follows: + + 1. The contentType field of the type ContentInfo is id-signedData + (as defined in [RFC3852]), and the content field is a SignedData + (as defined in [RFC3852]). + + 2. The eContentType field for the type SignedData is id-pkauthdata: + { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) + pkinit(3) pkauthdata(1) }. + + 3. The eContent field for the type SignedData contains the DER + encoding of the type AuthPack. + + 4. The signerInfos field of the type SignedData contains a single + signerInfo, which contains the signature over the type AuthPack. + + 5. The certificates field of the type SignedData contains the + client's certificate and additional certificates intended to + facilitate certification path construction, so that the KDC can + validate the client's certificate and verify the signature over + the type AuthPack. The certificates field MUST NOT contain + + + +Tung & Zhu Expires August 4, 2005 [Page 8] + +Internet-Draft PKINIT January 2005 + + + "root" CA certificates. + + 6. The client's Diffie-Hellman public value (clientPublicValue) is + included if and only if the client wishes to use the + Diffie-Hellman key agreement method. For the Diffie-Hellman key + agreement method, implementations MUST support Oakley 1024-bit + MODP well-known group 2 [RFC2412] and SHOULD support Oakley + 2048-bit MODP well-known group 14 and Oakley 4096-bit MODP + well-known group 16 [RFC3526]. They MAY support Oakley 185-bit + EC2N group 4 [RFC2412]. The Diffie-Hellman group size should be + chosen so as to provide sufficient cryptographic security. The + exponents should have at least twice as many bits as the + symmetric keys that will be derived from them [ODL99]. + + 7. The client may wish to cache DH keys or to allow the KDC to do + so. If so, then the client includes the clientDHNonce field. + This nonce string needs to be as long as the longest key length + of the symmetric key types that the client supports. This nonce + MUST be chosen randomly. + + +3.2.2 Receipt of Client Request + + Upon receiving the client's request, the KDC validates it. This + section describes the steps that the KDC MUST (unless otherwise + noted) take in validating the request. + + The KDC looks for the client's certificate in the signedAuthPack + (based on the signerInfo) and validate this certificate. + + If the KDC cannot find a certification path to validate the client's + certificate, it sends back an error of type + KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for this + error is a TYPED-DATA (as defined in [CLAR]). For this error, the + data-type is TD-TRUSTED-CERTIFIERS, and the data-value is the DER + encoding of + + TrustedCertifiers ::= SEQUENCE OF OCTET STRING + -- The OCTET STRING contains a PKIX type Name encoded + -- according to [RFC3280]. + + If, while processing the certification path, 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 TYPED-DATA, whose + data-type is TD-CERTIFICATE-INDEX, and whose data-value is the DER + encoding of the index into the CertificateSet field, ordered as sent + by the client: + + + +Tung & Zhu Expires August 4, 2005 [Page 9] + +Internet-Draft PKINIT January 2005 + + + CertificateIndex ::= OCTET STRING + -- Contains a CMS type IssuerAndSerialNumber encoded + -- according to [RFC3852]. + -- IssuerAndSerialNumber of certificate with an + -- invalid signature. + + If more than one certificate signature is invalid, the KDC MAY send + one TYPED-DATA per invalid signature. + + The KDC SHOULD also check whether any certificates in the client's + certification path 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 client's certificate, the KDC MUST also + check that this 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 client's + certificate to a Kerberos name, it uses that Kerberos name. + + 2. Otherwise, if the client's 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 KRB5PrincipalName as defined below. + + The type-id field of the type AnotherName is id-pksan: + + id-pksan OBJECT IDENTIFIER ::= + { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) + x509-sanan (2) } + + The value field of the type AnotherName is the DER encoding of the + following ASN.1 type: + + KRB5PrincipalName ::= SEQUENCE { + realm [0] Realm, + principalName [1] PrincipalName + } + + If the KDC does not have its own mapping and there is no Kerberos + name present in the client's certificate, or if the name in the + + + +Tung & Zhu Expires August 4, 2005 [Page 10] + +Internet-Draft PKINIT January 2005 + + + request does not match the name in the certificate (including the + realm name), the KDC MUST return error code + KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for + this error. + + Even if the client's certificate is validated and it is mapped to the + client's principal name, the KDC may decide not to accept the + client's certificate, depending on local policy. + + The KDC MAY require the presence of an Extended Key Usage (EKU) + KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the + client's certificate: + + id-pkekuoid OBJECT IDENTIFIER ::= + { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) + pkinit(3) pkekuoid(4) } + -- PKINIT client authentication. + -- Key usage bits that may be consistent: digitalSignature + -- nonRepudiation, and (keyEncipherment or keyAgreement). + + 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. KDCs + implementing this requirement SHOULD also accept the EKU KeyPurposeId + id-ms-sc-logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, + as there are a large number of client certificates deployed for use + with PKINIT which have this EKU. + + The KDC MUST return the error code KDC_ERR_CLIENT_NOT_TRUSTED if the + client's certificate is not accepted. + + Once the client's certificate is accepted, the KDC can then verify + the client's signature over the type AuthPack according to [RFC3852]. + If the signature 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 [CLAR] apply here. If the check + fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or + KRB_AP_ERR_SKEW, respectively. + + If the clientPublicValue is filled in, indicating that the client + wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD + check to see if the key parameters satisfy its policy. If they do + not, it MUST return error code KDC_ERR_KEY_SIZE. The accompanying + e-data is a TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and + whose data-value is the DER encoding of the following: + + + + +Tung & Zhu Expires August 4, 2005 [Page 11] + +Internet-Draft PKINIT January 2005 + + + TD-DH-PARAMETERS ::= SEQUENCE OF DomainParameters + -- Type DomainParameters is defined in [RFC3279]. + -- Contains a list of Diffie-Hellman group + -- parameters in decreasing preference order. + + TD-DH-PARAMETERS contains a list of Diffie-Hellman group parameters + that the KDC supports in decreasing preference order, from which the + client should pick one 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 Generation of KDC Reply + + Assuming that the client's request has been properly validated, the + KDC proceeds as per [CLAR], except as follows. + + The KDC MUST set the initial flag and include an authorization data + 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] IMPLICIT OCTET STRING, + -- Contains a PKIX type Name encoded according to + -- [RFC3280]. + 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 + [CLAR]). 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. + + + + +Tung & Zhu Expires August 4, 2005 [Page 12] + +Internet-Draft PKINIT January 2005 + + + Application servers that understand this authorization data type + SHOULD apply local policy to determine whether a given ticket bearing + such a type *not* contained within an AD-IF-RELEVANT container is + acceptable. (This corresponds to the AP server checking the + transited field when the TRANSITED-POLICY-CHECKED flag has not been + set [CLAR].) If such a data type is contained within an + AD-IF-RELEVANT container, AP servers MAY apply local policy to + determine whether the authorization data is acceptable. + + The AS-REP is otherwise unchanged from [CLAR]. The KDC encrypts the + reply as usual, but not with the client's long-term key. Instead, it + encrypts it with either a shared key derived from a Diffie-Hellman + exchange, or a generated encryption key. The contents of the + PA-PK-AS-REP indicate which key delivery method is used: + + PA-PK-AS-REP ::= CHOICE { + dhInfo [0] DHRepInfo, + encKeyPack [1] IMPLICIT OCTET STRING, + -- Contains a CMS type ContentInfo encoded + -- according to [RFC3852]. + -- The contentType field of the type ContentInfo is + -- id-envelopedData (1.2.840.113549.1.7.3). + -- The content field is an EnvelopedData. + -- The contentType field for the type EnvelopedData + -- is id-signedData (1.2.840.113549.1.7.2). + -- The eContentType field for the inner type + -- SignedData (when unencrypted) is id-pkrkeydata + -- (1.2.840.113549.1.7.3) and the eContent field + -- contains the DER encoding of the type + -- ReplyKeyPack. + -- ReplyKeyPack is defined below. + ... + } + + DHRepInfo ::= SEQUENCE { + dhSignedData [0] IMPLICIT OCTET STRING, + -- Contains a CMS type ContentInfo encoded according + -- to [RFC3852]. + -- The contentType field of the type ContentInfo is + -- id-signedData (1.2.840.113549.1.7.2), and the + -- content field is a SignedData. + -- The eContentType field for the type SignedData is + -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the + -- eContent field contains the DER encoding of the + -- type KDCDHKeyInfo. + -- KDCDHKeyInfo is defined below. + serverDHNonce [1] DHNonce OPTIONAL + -- Present if and only if dhKeyExpiration is + + + +Tung & Zhu Expires August 4, 2005 [Page 13] + +Internet-Draft PKINIT January 2005 + + + -- present. + } + + KDCDHKeyInfo ::= SEQUENCE { + subjectPublicKey [0] BIT STRING, + -- KDC's public key, y = g^x mod p. + -- MUST be ASN.1 encoded as an INTEGER; + -- This encoding is then used as the contents + -- (i.e., the value) of this BIT STRING field. + nonce [1] INTEGER (0..4294967295), + -- Contains the nonce in the PKAuthenticator of the + -- request if cached DH keys are NOT used, + -- 0 otherwise. + dhKeyExpiration [2] KerberosTime OPTIONAL, + -- Expiration time for KDC's cached values, present + -- if and only if cached DH keys are used. If this + -- field is omitted then the serverDHNonce field + -- MUST also be omitted. + ... + } + + +3.2.3.1 Using Diffie-Hellman Key Exchange + + In this case, the PA-PK-AS-REP contains a DHRepInfo structure. + + The ContentInfo [RFC3852] structure for the dhSignedData field is + filled in as follows: + + 1. The contentType field of the type ContentInfo is id-signedData + (as defined in [RFC3852]), and the content field is a SignedData + (as defined in [RFC3852]). + + 2. The eContentType field for the type SignedData is the OID value + for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1) + security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }. + + 3. The eContent field for the type SignedData contains the DER + encoding of the type KDCDHKeyInfo. + + 4. The signerInfos field of the type SignedData contains a single + signerInfo, which contains the signature over the type + KDCDHKeyInfo. + + 5. The certificates field of the type SignedData contains the KDC's + certificate and additional certificates intended to facilitate + certification path construction, so that the client can validate + the KDC's certificate and verify the KDC's signature over the + + + +Tung & Zhu Expires August 4, 2005 [Page 14] + +Internet-Draft PKINIT January 2005 + + + type KDCDHKeyInfo. This field may only be left empty if the + client did include a kdcCert field in the PA-PK-AS-REQ, + indicating that the client already has the KDC's certificate. + The certificates field MUST NOT contain "root" CA certificates. + + 6. If the client included the clientDHNonce field, then the KDC may + choose to reuse its DH keys. If the server reuses DH keys then + it MUST include an expiration time in the dhKeyExperiation field. + Past the point of the expiration time, the signature over the + type DHRepInfo is considered expired/invalid. When the server + reuses DH keys then it MUST include a serverDHNonce at least as + long as the length of keys for the symmetric encryption system + used to encrypt the AS reply. Note that including the + serverDHNonce changes how the client and server calculate the key + to use to encrypt the reply; see below for details. The KDC + SHOULD NOT reuse DH keys unless the clientDHNonce field is + present in the request. + + The reply key for use to decrypt the KDC reply [CLAR] is derived as + follows: + + 1. Both the KDC and the client calculate the shared secret value + DHKey: + + DHKey = g^(xb * xa) mod p + + where xb and xa are the KDC's and client's private exponents, + respectively. DHKey, padded first with leading zeros as needed to + make it as long as the modulus p, is represented as a string of + octets in big-endian order (such that the size of DHKey in octets + is the size of the modulus p). + + 2. Let K be the key-generation seed length [KCRYPTO] of the reply + key whose enctype is selected according to [CLAR]. + + 3. Define the function octetstring2key() as follows: + + octetstring2key(x) == random-to-key(K-truncate( + SHA1(0x00 | x) | + SHA1(0x01 | x) | + SHA1(0x02 | x) | + ... + )) + + where x is an octet string; | is the concatenation operator; 0x00, + 0x01, 0x02, etc., are each represented as a single octet; + random-to-key() is an operation that generates a protocol key from + a bitstring of length K; and K-truncate truncates its input to the + + + +Tung & Zhu Expires August 4, 2005 [Page 15] + +Internet-Draft PKINIT January 2005 + + + first K bits. Both K and random-to-key() are defined in the + kcrypto profile [KCRYPTO] for the enctype of the reply key. + + 4. When cached DH keys are used, let n_c be the clientDHNonce, and + n_k be the serverDHNonce; otherwise, let both n_c and n_k be empty + octet strings. + + 5. The reply key k is: + + k = octetstring2key(DHKey | n_c | n_k) + + +3.2.3.2 Using Public Key Encryption + + In this case, the PA-PK-AS-REP contains a ContentInfo structure + wrapped in an OCTET STRING. The reply key for use to decrypt the KDC + reply [CLAR] is encrypted in the encKeyPack field, which contains + data of type ReplyKeyPack: + + ReplyKeyPack ::= SEQUENCE { + replyKey [0] EncryptionKey, + -- Contains the session key used to encrypt the + -- enc-part field in the AS-REP. + nonce [1] INTEGER (0..4294967295), + -- Contains the nonce in the PKAuthenticator of the + -- request. + ... + } + + The ContentInfo [RFC3852] structure for the encKeyPack field is + filled in as follows: + + 1. The contentType field of the type ContentInfo is id-envelopedData + (as defined in [RFC3852]), and the content field is an + EnvelopedData (as defined in [RFC3852]). + + 2. The contentType field for the type EnvelopedData is + id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549) + pkcs (1) pkcs7 (7) signedData (2) }. + + 3. The eContentType field for the inner type SignedData (when + decrypted from the encryptedContent field for the type + EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6) + internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }. + + 4. The eContent field for the inner type SignedData contains the DER + encoding of the type ReplyKeyPack. + + + + +Tung & Zhu Expires August 4, 2005 [Page 16] + +Internet-Draft PKINIT January 2005 + + + 5. The signerInfos field of the inner type SignedData contains a + single signerInfo, which contains the signature over the type + ReplyKeyPack. + + 6. The certificates field of the inner type SignedData contains the + KDC's certificate and additional certificates intended to + facilitate certification path construction, so that the client + can validate the KDC's certificate and verify the KDC's signature + over the type ReplyKeyPack. This field may only be left empty if + the client included a kdcCert field in the PA-PK-AS-REQ, + indicating that the client already has the KDC's certificate. + The certificates field MUST NOT contain "root" CA certificates. + + 7. The recipientInfos field of the type EnvelopedData is a SET which + MUST contain exactly one member of type KeyTransRecipientInfo. + The encryptedKey of this member contains the temporary key which + is encrypted using the client's public key. + + 8. The unprotectedAttrs or originatorInfo fields of the type + EnvelopedData MAY be present. + +3.2.4 Receipt of KDC Reply + + Upon receipt of the KDC's reply, the client proceeds as follows. If + the PA-PK-AS-REP contains the dhSignedData field, the client derives + the shared key using the same procedure used by the KDC as defined in + Section 3.2.3.1. Otherwise, the message contains an encKeyPack, and + the client decrypts and verifies the temporary encryption key. + + In either case, the client MUST validate the KDC's certificate and + verify the signature in the SignedData according to [RFC3852]. + Unless the client can otherwise prove that the KDC's certificate is + for the target KDC (i.e., the subject distinguished name in the KDC + certificate is bound to the hostname or IP address of the KDC + authenticating the client), it MUST do the following to verify the + responder's identity: + + 1. The client checks to see if the included certificate contains a + Subject Alternative Name extension [RFC3280] carrying a dNSName or + an iPAddress (if the KDC is specified by an IP address instead of + a name). If it does, it MUST check to see if that name value + matches that of the KDC it believes it is communicating with, with + matching rules specified in [RFC3280]. + + 2. The client verifies that the KDC's certificate MUST contain the + EKU KeyPurposeId [RFC3280] id-pkkdcekuoid: + + + + + +Tung & Zhu Expires August 4, 2005 [Page 17] + +Internet-Draft PKINIT January 2005 + + + + + id-pkkdcekuoid OBJECT IDENTIFIER ::= + { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) + pkinit(3) pkkdcekuoid(5) } + -- Signing KDC responses. + -- Key usage bits that may be consistent: + -- digitalSignature. + + If all applicable checks are satisfied, the client then decrypts the + enc-part of the KDC-REP in the AS_REP with the resulting key, and + then proceeds as described in [CLAR]. + +3.3 KDC Indication of PKINIT Support + + If pre-authentication is required, but was not present in the + request, per [CLAR] an error message with the code + KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be + stored in the e-data field of the KRB-ERROR message to specify which + pre-authentication mechanisms are acceptable. The KDC can then + indicate the support of PKINIT by including a PA-PK-AS-REQ element in + that METHOD-DATA object. + + Otherwise if it is required by the KDC's local policy that the client + must be pre-authenticated using the pre-authentication mechanism + specified in this document, but no PKINIT pre-authentication was + present in the request, an error message with the code + KDC_ERR_PREAUTH_FAILED SHOULD be returned. + + KDCs MUST leave the padata-value of PA-PK-AS-REQ entry in the + KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET + STRING), and clients MUST ignore this and any other value. Future + extensions to this protocol may specify other data to send instead of + an empty OCTET STRING. + +4. Security Considerations + + PKINIT raises certain security considerations beyond those that can + be regulated strictly in protocol definitions. We will address them + in this section. + + PKINIT extends the cross-realm model to the public-key + infrastructure. Users of PKINIT must understand security policies + and procedures appropriate to the use of Public Key Infrastructures. + + Standard Kerberos allows the possibility of interactions between + cryptosystems of varying strengths; this document adds interactions + with public-key cryptosystems to Kerberos. Some administrative + + + +Tung & Zhu Expires August 4, 2005 [Page 18] + +Internet-Draft PKINIT January 2005 + + + policies may allow the use of relatively weak public keys. Using + such keys to wrap data encrypted under stronger conventional + cryptosystems may be inappropriate. + + PKINIT requires keys for symmetric cryptosystems to be generated. + Some such systems contain "weak" keys. For recommendations regarding + these weak keys, see [CLAR]. + + PKINIT uses the same RSA key pair for encryption and signing when + doing RSA encryption based key delivery. This is not recommended + usage of RSA keys [RFC3447], by using DH based key delivery this is + avoided. + + Care should be taken in how certificates are chosen for the purposes + of authentication using PKINIT. Some local policies may require that + key escrow be used for certain certificate types. Deployers of + PKINIT should be aware of the implications of using certificates that + have escrowed keys for the purposes of authentication. + + 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. + +5. Acknowledgements + + The following people have made significant contributions to this + draft: Paul Leach, Phil Hallin, Kelvin Yiu, Sam Hartman, Love + Hornquist Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan + Trostle, Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon and + Karthik Jaganathan. + + Special thanks to Clifford Neuman, Mat Hur and Sasha Medvinsky who + wrote earlier versions of this document. + + The authors are indebt to the Kerberos working group chair Jeffrey + Hutzelman who kept track of various issues and was enormously helpful + during the creation of this document. + + Some of the ideas on which this document is based arose during + discussions over several years between members of the SAAG, the IETF + CAT working group, and the PSRG, regarding integration of Kerberos + + + +Tung & Zhu Expires August 4, 2005 [Page 19] + +Internet-Draft PKINIT January 2005 + + + and SPX. Some ideas have also been drawn from the DASS system. + These changes are by no means endorsed by these groups. This is an + attempt to revive some of the goals of those groups, and this + document approaches those goals primarily from the Kerberos + perspective. + + Lastly, comments from groups working on similar ideas in DCE have + been invaluable. + +6. IANA Considerations + + This document has no actions for IANA. + +7. References + +7.1 Normative References + + [CLAR] RFC-Editor: To be replaced by RFC number for draft-ietf- + krb-wg-kerberos-clarifications. Work in Progress. + + [KCRYPTO] RFC-Editor: To be replaced by RFC number for draft-ietf- + krb-wg-crypto. Work in Progress. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", + RFC 2412, November 1998. + + [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", + RFC 2631, June 1999. + + [RFC3279] Bassham, L., Polk, W. and R. Housley, "Algorithms and + Identifiers for the Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 3279, April 2002. + + [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet + X.509 Public Key Infrastructure Certificate and + Certificate Revocation List (CRL) Profile", RFC 3280, + April 2002. + + [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) + Algorithms", RFC 3370, August 2002. + + [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography + Standards (PKCS) #1: RSA Cryptography Specifications + + + +Tung & Zhu Expires August 4, 2005 [Page 20] + +Internet-Draft PKINIT January 2005 + + + Version 2.1", RFC 3447, February 2003. + + [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) + Diffie-Hellman groups for Internet Key Exchange (IKE)", + RFC 3526, May 2003. + + [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) + Encryption Algorithm in Cryptographic Message Syntax + (CMS)", RFC 3565, July 2003. + + [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", + RFC 3852, July 2004. + + [X690] ASN.1 encoding rules: Specification of Basic Encoding + Rules (BER), Canonical Encoding Rules (CER) and + Distinguished Encoding Rules (DER), ITU-T Recommendation + X.690 (1997) | ISO/IEC International Standard + 8825-1:1998. + +7.2 Informative References + + [ODL99] Odlyzko, A., "Discrete logarithms: The past and the + future, Designs, Codes, and Cryptography (1999)". + +Authors' Addresses + + Brian Tung + USC Information Sciences Institute + 4676 Admiralty Way Suite 1001, Marina del Rey CA + Marina del Rey, CA 90292 + US + + Email: brian@isi.edu + + + Larry Zhu + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + US + + Email: lzhu@microsoft.com + +Appendix A. PKINIT ASN.1 Module + + KerberosV5-PK-INIT-SPEC { + iso(1) identified-organization(3) dod(6) internet(1) + + + +Tung & Zhu Expires August 4, 2005 [Page 21] + +Internet-Draft PKINIT January 2005 + + + security(5) kerberosV5(2) modules(4) pkinit(5) + } DEFINITIONS EXPLICIT TAGS ::= BEGIN + + IMPORTS + SubjectPublicKeyInfo, AlgorithmIdentifier + FROM PKIX1Explicit88 { iso (1) + identified-organization (3) dod (6) internet (1) + security (5) mechanisms (5) pkix (7) id-mod (0) + id-pkix1-explicit (18) } + -- As defined in RFC 3280. + + DomainParameters + FROM PKIX1Algorithms88 { iso(1) + identified-organization(3) dod(6) + internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-pkix1-algorithms(17) } + -- As defined in RFC 3279. + + KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey + FROM KerberosV5Spec2 { iso(1) identified-organization(3) + dod(6) internet(1) security(5) kerberosV5(2) + modules(4) krb5spec2(2) } ; + + id-pkinit OBJECT IDENTIFIER ::= + { iso (1) org (3) dod (6) internet (1) security (5) + kerberosv5 (2) pkinit (3) } + + id-pkauthdata OBJECT IDENTIFIER ::= { id-pkinit 1 } + id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 } + id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 } + id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 } + id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 } + + pa-pk-as-req INTEGER ::= 16 + pa-pk-as-rep INTEGER ::= 17 + + ad-initial-verified-cas INTEGER ::= 9 + + td-trusted-certifiers INTEGER ::= 104 + td-certificate-index INTEGER ::= 105 + td-dh-parameters INTEGER ::= 109 + + PA-PK-AS-REQ ::= SEQUENCE { + signedAuthPack [0] IMPLICIT OCTET STRING, + -- Contains a CMS type ContentInfo encoded + -- according to [RFC3852]. + -- The contentType field of the type ContentInfo + -- is id-signedData (1.2.840.113549.1.7.2), + + + +Tung & Zhu Expires August 4, 2005 [Page 22] + +Internet-Draft PKINIT January 2005 + + + -- and the content field is a SignedData. + -- The eContentType field for the type SignedData is + -- id-pkauthdata (1.3.6.1.5.2.3.1), and the + -- eContent field contains the DER encoding of the + -- type AuthPack. + -- AuthPack is defined below. + trustedCertifiers [1] SEQUENCE OF TrustedCA OPTIONAL, + -- A list of CAs, trusted by the client, that can + -- be used to validate KDC certificates. + kdcCert [2] IMPLICIT OCTET STRING + OPTIONAL, + -- Contains a CMS type IssuerAndSerialNumber encoded + -- according to [RFC3852]. + -- Identifies a particular KDC certificate, if the + -- client already has it. + ... + } + + DHNonce ::= OCTET STRING + + TrustedCA ::= CHOICE { + caName [1] IMPLICIT OCTET STRING, + -- Contains a PKIX type Name encoded according to + -- [RFC3280]. + issuerAndSerial [2] IMPLICIT OCTET STRING, + -- Contains a CMS type IssuerAndSerialNumber encoded + -- according to [RFC3852]. + -- Identifies a specific CA certificate. + ... + } + + AuthPack ::= SEQUENCE { + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, + -- Defined in [RFC3280]. + -- Present only if the client wishes to use the + -- Diffie-Hellman key agreement method. + supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier + OPTIONAL, + -- List of CMS encryption types supported by + -- client in order of (decreasing) preference. + clientDHNonce [3] DHNonce OPTIONAL, + -- Present only if the client indicates that it + -- wishes to cache DH keys or to allow the KDC to + -- do so. + ... + } + + + + +Tung & Zhu Expires August 4, 2005 [Page 23] + +Internet-Draft PKINIT January 2005 + + + PKAuthenticator ::= SEQUENCE { + cusec [0] INTEGER (0..999999), + ctime [1] KerberosTime, + -- cusec and ctime are used as in [CLAR], for replay + -- prevention. + nonce [2] INTEGER (0..4294967295), + -- Chosen randomly; This nonce does not need to + -- match with the nonce in the KDC-REQ-BODY. + paChecksum [3] OCTET STRING, + -- Contains the SHA1 checksum, performed over + -- KDC-REQ-BODY. + ... + } + + TrustedCertifiers ::= SEQUENCE OF OCTET STRING + -- The OCTET STRING contains a PKIX type Name encoded + -- according to [RFC3280]. + + CertificateIndex ::= OCTET STRING + -- Contains a CMS type IssuerAndSerialNumber encoded + -- according to [RFC3852]. + + KRB5PrincipalName ::= SEQUENCE { + realm [0] Realm, + principalName [1] PrincipalName + } + + InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE { + ca [0] IMPLICIT OCTET STRING, + -- Contains a PKIX type Name encoded according to + -- [RFC3280]. + validated [1] BOOLEAN, + ... + } + + PA-PK-AS-REP ::= CHOICE { + dhInfo [0] DHRepInfo, + encKeyPack [1] IMPLICIT OCTET STRING, + -- Contains a CMS type ContentInfo encoded + -- according to [RFC3852]. + -- The contentType field of the type ContentInfo is + -- id-envelopedData (1.2.840.113549.1.7.3). + -- The content field is an EnvelopedData. + -- The contentType field for the type EnvelopedData + -- is id-signedData (1.2.840.113549.1.7.2). + -- The eContentType field for the inner type + -- SignedData (when unencrypted) is id-pkrkeydata + -- (1.2.840.113549.1.7.3) and the eContent field + + + +Tung & Zhu Expires August 4, 2005 [Page 24] + +Internet-Draft PKINIT January 2005 + + + -- contains the DER encoding of the type + -- ReplyKeyPack. + -- ReplyKeyPack is defined below. + ... + } + + DHRepInfo ::= SEQUENCE { + dhSignedData [0] IMPLICIT OCTET STRING, + -- Contains a CMS type ContentInfo encoded according + -- to [RFC3852]. + -- The contentType field of the type ContentInfo is + -- id-signedData (1.2.840.113549.1.7.2), and the + -- content field is a SignedData. + -- The eContentType field for the type SignedData is + -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the + -- eContent field contains the DER encoding of the + -- type KDCDHKeyInfo. + -- KDCDHKeyInfo is defined below. + serverDHNonce [1] DHNonce OPTIONAL + -- Present if and only if dhKeyExpiration is + -- present. + } + + KDCDHKeyInfo ::= SEQUENCE { + subjectPublicKey [0] BIT STRING, + -- KDC's public key, y = g^x mod p. + -- MUST be ASN.1 encoded as an INTEGER; + -- This encoding is then used as the contents + -- (i.e., the value) of this BIT STRING field. + nonce [1] INTEGER (0..4294967295), + -- Contains the nonce in the PKAuthenticator of the + -- request if cached DH keys are NOT used, + -- 0 otherwise. + dhKeyExpiration [2] KerberosTime OPTIONAL, + -- Expiration time for KDC's cached values, present + -- if and only if cached DH keys are used. If this + -- field is omitted then the serverDHNonce field + -- MUST also be omitted. + ... + } + + ReplyKeyPack ::= SEQUENCE { + replyKey [0] EncryptionKey, + -- Contains the session key used to encrypt the + -- enc-part field in the AS-REP. + nonce [1] INTEGER (0..4294967295), + -- Contains the nonce in the PKAuthenticator of the + -- request. + + + +Tung & Zhu Expires August 4, 2005 [Page 25] + +Internet-Draft PKINIT January 2005 + + + ... + } + + TD-DH-PARAMETERS ::= SEQUENCE OF DomainParameters + -- Contains a list of Diffie-Hellman group + -- parameters in decreasing preference order. + END + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Tung & Zhu Expires August 4, 2005 [Page 26] + +Internet-Draft PKINIT January 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Tung & Zhu Expires August 4, 2005 [Page 27] + + |