< draft-ietf-cat-kerberos-pk-init-24.txt		draft-ietf-cat-kerberos-pk-init-25.txt >
	NETWORK WORKING GROUP B. Tung		NETWORK WORKING GROUP B. Tung
	Internet-Draft USC Information Sciences Institute		Internet-Draft USC Information Sciences Institute
	Expires: August 13, 2005 L. Zhu		Expires: August 22, 2005 L. Zhu
	Microsoft Corporation		Microsoft Corporation
	February 9, 2005		February 18, 2005
	Public Key Cryptography for Initial Authentication in Kerberos		Public Key Cryptography for Initial Authentication in Kerberos
	draft-ietf-cat-kerberos-pk-init-24		draft-ietf-cat-kerberos-pk-init-25
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		This document is an Internet-Draft and is subject to all provisions
	of Section 3 of RFC 3667. By submitting this Internet-Draft, each		of Section 3 of RFC 3667. By submitting this Internet-Draft, each
	author represents that any applicable patent or other IPR claims of		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 is aware have been or will be disclosed, and any of
	which he or she become aware will be disclosed, in accordance with		which he or she become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 13, 2005.		This Internet-Draft will expire on August 22, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	This document describes protocol extensions (hereafter called PKINIT)		This document describes protocol extensions (hereafter called PKINIT)
	to the Kerberos protocol specification. These extensions provide a		to the Kerberos protocol specification. These extensions provide a
	method for integrating public key cryptography into the initial		method for integrating public key cryptography into the initial
	skipping to change at page 4, line 47 ¶		skipping to change at page 4, line 47 ¶
	Section 3.1 of this document enumerates the required algorithms and		Section 3.1 of this document enumerates the required algorithms and
	necessary extension message types. Section 3.2 describes the		necessary extension message types. Section 3.2 describes the
	extension messages in greater detail.		extension messages in greater detail.
	3.1 Definitions, Requirements, and Constants		3.1 Definitions, Requirements, and Constants
	3.1.1 Required Algorithms		3.1.1 Required Algorithms
	All PKINIT implementations MUST support the following algorithms:		All PKINIT implementations MUST support the following algorithms:
	o KDC AS reply key enctype: AES256-CTS-HMAC-SHA1-96 etype [KCRYPTO].		o KDC AS reply key enctype: AES256-CTS-HMAC-SHA1-96 etype [RFC3961].
	o Signature algorithm: sha-1WithRSAEncryption [RFC3279].		o Signature algorithm: sha-1WithRSAEncryption [RFC3279].
	o KDC AS reply key delivery method: Diffie-Hellman key exchange		o KDC AS reply key delivery method: Diffie-Hellman key exchange
	[RFC2631].		[RFC2631].
	3.1.2 Defined Message and Encryption Types		3.1.2 Defined Message and Encryption Types
	PKINIT makes use of the following new pre-authentication types:		PKINIT makes use of the following new pre-authentication types:
	skipping to change at page 7, line 41 ¶		skipping to change at page 7, line 41 ¶
	-- public key that the client already has.		-- public key that the client already has.
	...		...
	}		}
	DHNonce ::= OCTET STRING		DHNonce ::= OCTET STRING
	TrustedCA ::= SEQUENCE {		TrustedCA ::= SEQUENCE {
	caName [0] IMPLICIT OCTET STRING,		caName [0] IMPLICIT OCTET STRING,
	-- Contains a PKIX type Name encoded according to		-- Contains a PKIX type Name encoded according to
	-- [RFC3280].		-- [RFC3280].
	-- Specifies the CA distinguished subject name.		-- Identifies a CA by the CA's distinguished subject
			-- name.
	certificateSerialNumber [1] INTEGER OPTIONAL,		certificateSerialNumber [1] INTEGER OPTIONAL,
	-- Specifies the certificate serial number.		-- Specifies the CA certificate's serial number.
	-- The defintion of the certificate serial number		-- The defintion of the certificate serial number
	-- is taken from X.509 [X.509-97].		-- is taken from X.509 [X.509-97].
	subjectKeyIdentifier [2] OCTET STRING OPTIONAL,		subjectKeyIdentifier [2] OCTET STRING OPTIONAL,
	-- Identifies the CA's public key by a key		-- Identifies the CA's public key by a key
	-- identifier. When an X.509 certificate is		-- identifier. When an X.509 certificate is
	-- referenced, this key identifier matches the X.509		-- referenced, this key identifier matches the X.509
	-- subjectKeyIdentifier extension value. When other		-- subjectKeyIdentifier extension value. When other
	-- certificate formats are referenced, the documents		-- certificate formats are referenced, the documents
	-- that specify the certificate format and their use		-- that specify the certificate format and their use
	-- with the CMS must include details on matching the		-- with the CMS must include details on matching the
	-- key identifier to the appropriate certificate		-- key identifier to the appropriate certificate
	-- field.		-- field.
	...		...
	}		}
	AuthPack ::= SEQUENCE {		AuthPack ::= SEQUENCE {
	pkAuthenticator [0] PKAuthenticator,		pkAuthenticator [0] PKAuthenticator,
	clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,		clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
	-- Defined in [RFC3280].		-- Type SubjectPublicKeyInfo is defined in
	-- The pubic key value (the subjectPublicKey field		-- [RFC3280].
			-- Specifies Diffie-Hellman domain parameters
			-- and the client's public key value [IEEE1363].
			-- The public key value (the subjectPublicKey field
	-- of the type SubjectPublicKeyInfo) MUST be encoded		-- of the type SubjectPublicKeyInfo) MUST be encoded
	-- according to [RFC3279].		-- according to [RFC3279].
	-- Present only if the client wishes to use the		-- Present only if the client wishes to use the
	-- Diffie-Hellman key agreement method.		-- Diffie-Hellman key agreement method.
	supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier		supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
	OPTIONAL,		OPTIONAL,
	-- List of CMS encryption types supported by		-- Type AlgorithmIdentifier is defined in
			-- [RFC3280].
			-- List of CMS encryption types supported by the
	-- client in order of (decreasing) preference.		-- client in order of (decreasing) preference.
	clientDHNonce [3] DHNonce OPTIONAL,		clientDHNonce [3] DHNonce OPTIONAL,
	-- Present only if the client indicates that it		-- Present only if the client indicates that it
	-- wishes to reuse DH keys or to allow the KDC to		-- wishes to reuse DH keys or to allow the KDC to
	-- do so (see Section 3.2.3.1).		-- do so (see Section 3.2.3.1).
	...		...
	}		}
	PKAuthenticator ::= SEQUENCE {		PKAuthenticator ::= SEQUENCE {
	cusec [0] INTEGER (0..999999),		cusec [0] INTEGER (0..999999),
	skipping to change at page 9, line 26 ¶		skipping to change at page 9, line 31 ¶
	certificates intended to facilitate certification path		certificates intended to facilitate certification path
	construction, so that the KDC can verify the signature over the		construction, so that the KDC can verify the signature over the
	type AuthPack. For path validation, these certificates SHOULD be		type AuthPack. For path validation, these certificates SHOULD be
	sufficient to construct at least one certification path from the		sufficient to construct at least one certification path from the
	client certificate to one trust anchor acceptable by the KDC		client certificate to one trust anchor acceptable by the KDC
	[CAPATH]. The certificates field MUST NOT contain "root" CA		[CAPATH]. The certificates field MUST NOT contain "root" CA
	certificates.		certificates.
	6. The client's Diffie-Hellman public value (clientPublicValue) is		6. The client's Diffie-Hellman public value (clientPublicValue) is
	included if and only if the client wishes to use the		included if and only if the client wishes to use the
	Diffie-Hellman key agreement method. For the Diffie-Hellman key		Diffie-Hellman key agreement method. The Diffie-Hellman domain
	agreement method, implementations MUST support Oakley 1024-bit		parameters for the client's public key are specified in the
	MODP well-known group 2 [RFC2412] and SHOULD support Oakley		algorithm field of the type SubjectPublicKeyInfo
	2048-bit MODP well-known group 14 and Oakley 4096-bit MODP		[IEEE1363][RFC3279] and the client's Diffie-Hellman public key
	well-known group 16 [RFC3526].		value is mapped to a subjectPublicKey (a BIT STRING) according to
			[RFC3279]. When using the Diffie-Hellman key agreement method,
			implementations MUST support Oakley 1024-bit MODP well-known
			group 2 [RFC2412] and SHOULD support Oakley 2048-bit MODP
			well-known group 14 and Oakley 4096-bit MODP well-known group 16
			[RFC3526].
	The Diffie-Hellman field size should be chosen so as to provide		The Diffie-Hellman field size should be chosen so as to provide
	sufficient cryptographic security. The following table, based on		sufficient cryptographic security. The following table, based on
	[LENSTRA], gives approximate comparable key sizes for symmetric-		[LENSTRA], gives approximate comparable key sizes for symmetric-
	and asymmetric-key cryptosystems based on the best-known		and asymmetric-key cryptosystems based on the best-known
	algorithms for attacking them.		algorithms for attacking them.
	Symmetric | ECC | DH/DSA/RSA		Symmetric | ECC | DH/DSA/RSA
	-------------+---------+------------		-------------+---------+------------
	80 | 163 | 1024		80 | 163 | 1024
	skipping to change at page 11, line 34 ¶		skipping to change at page 11, line 48 ¶
	In addition to validating the client's signature, the KDC MUST also		In addition to validating the client's signature, the KDC MUST also
	check that the client's public key used to verify the client's		check that the client's public key used to verify the client's
	signature is bound to the client's principal name as specified in the		signature is bound to the client's principal name as specified in the
	AS-REQ as follows:		AS-REQ as follows:
	1. If the KDC has its own binding between either the client's		1. If the KDC has its own binding between either the client's
	signature-verification public key or the client's certificate and		signature-verification public key or the client's certificate and
	the client's Kerberos principal name, it uses that binding.		the client's Kerberos principal name, it uses that binding.
	2. Otherwise, if the client's X.509 certificate contains a		2. Otherwise, if the client's X.509 certificate contains a Subject
	SubjectAltName extension with a KRB5PrincipalName (defined below)		Alternative Name (SAN) extension [RFC3280] with a
	in the otherName field, it binds the client's X.509 certificate to		KRB5PrincipalName (defined below) in the otherName field, it binds
	that name.		the client's X.509 certificate to that name.
	The otherName field (of type AnotherName) in the SubjectAltName		The otherName field (of type AnotherName) in the SAN extension
	extension MUST contain KRB5PrincipalName as defined below.		MUST contain KRB5PrincipalName as defined below.
	The type-id field of the type AnotherName is id-pksan:		The type-id field of the type AnotherName is id-pksan:
	id-pksan OBJECT IDENTIFIER ::=		id-pksan OBJECT IDENTIFIER ::=
	{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)		{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
	x509-sanan (2) }		x509-sanan (2) }
	The value field of the type AnotherName is the DER encoding of the		The value field of the type AnotherName is the DER encoding of the
	following ASN.1 type:		following ASN.1 type:
	skipping to change at page 13, line 9 ¶		skipping to change at page 13, line 21 ¶
	If the clientPublicValue is filled in, indicating that the client		If the clientPublicValue is filled in, indicating that the client
	wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD		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		check to see if the key parameters satisfy its policy. If they do
	not, it MUST return an error message with the code		not, it MUST return an error message with the code
	KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a		KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a
	TYPED-DATA that contains an element whose data-type is		TYPED-DATA that contains an element whose data-type is
	TD_DH_PARAMETERS, and whose data-value contains the DER encoding of		TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
	the type TD-DH-PARAMETERS:		the type TD-DH-PARAMETERS:
	TD-DH-PARAMETERS ::= SEQUENCE OF DHDomainParameters		TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
	-- Contains a list of Diffie-Hellman domain		-- Each AlgorithmIdentifier specifies a set of
	-- parameters in decreasing preference order.		-- Diffie-Hellman domain parameters [IEEE1363].
			-- This list is in decreasing preference order.
	DHDomainParameters ::= CHOICE {
	modp [0] DomainParameters,
	-- Type DomainParameters is defined in [RFC3279].
	ec [1] EcpkParameters,
	-- Type EcpkParameters is defined in [RFC3279].
	...
	}
	TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters		TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
	that the KDC supports in decreasing preference order, from which the		that the KDC supports in decreasing preference order, from which the
	client SHOULD pick one to retry the request.		client SHOULD pick one to retry the request.
	If the client included a kdcPkId field in the PA-PK-AS-REQ and the		If the client included a kdcPkId field in the PA-PK-AS-REQ and the
	KDC does not possess the corresponding key, the KDC MUST ignore the		KDC does not possess the corresponding key, the KDC MUST ignore the
	kdcPkId field as if the client did not include one.		kdcPkId field as if the client did not include one.
	If the client included a trustedCertifiers field, and the KDC does		If the client included a trustedCertifiers field, and the KDC does
	skipping to change at page 17, line 20 ¶		skipping to change at page 17, line 20 ¶
	DHSharedSecret is first padded with leading zeros such that the		DHSharedSecret is first padded with leading zeros such that the
	size of DHSharedSecret in octets is the same as that of the		size of DHSharedSecret in octets is the same as that of the
	modulus, then represented as a string of octets in big-endian		modulus, then represented as a string of octets in big-endian
	order.		order.
	Implementation note: Both the client and the KDC can cache the		Implementation note: Both the client and the KDC can cache the
	triple (ya, yb, DHSharedSecret), where ya is the client's public		triple (ya, yb, DHSharedSecret), where ya is the client's public
	key and yb is the KDC's public key. If both ya and yb are the		key and yb is the KDC's public key. If both ya and yb are the
	same in a later exchange, the cached DHSharedSecret can be used.		same in a later exchange, the cached DHSharedSecret can be used.
	2. Let K be the key-generation seed length [KCRYPTO] of the KDC AS		2. Let K be the key-generation seed length [RFC3961] of the KDC AS
	reply key whose enctype is selected according to [CLAR].		reply key whose enctype is selected according to [CLAR].
	3. Define the function octetstring2key() as follows:		3. Define the function octetstring2key() as follows:
	octetstring2key(x) == random-to-key(K-truncate(		octetstring2key(x) == random-to-key(K-truncate(
	SHA1(0x00 | x) |		SHA1(0x00 | x) |
	SHA1(0x01 | x) |		SHA1(0x01 | x) |
	SHA1(0x02 | x) |		SHA1(0x02 | x) |
	...		...
	))		))
	where x is an octet string; | is the concatenation operator; 0x00,		where x is an octet string; | is the concatenation operator; 0x00,
	0x01, 0x02, etc., are each represented as a single octet;		0x01, 0x02, etc., are each represented as a single octet;
	random-to-key() is an operation that generates a protocol key from		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		a bitstring of length K; and K-truncate truncates its input to the
	first K bits. Both K and random-to-key() are as defined in the		first K bits. Both K and random-to-key() are as defined in the
	kcrypto profile [KCRYPTO] for the enctype of the KDC AS reply key.		kcrypto profile [RFC3961] for the enctype of the KDC AS reply key.
	4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be		4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
	the serverDHNonce; otherwise, let both n_c and n_k be empty octet		the serverDHNonce; otherwise, let both n_c and n_k be empty octet
	strings.		strings.
	5. The KDC AS reply key k is:		5. The KDC AS reply key k is:
	k = octetstring2key(DHSharedSecret | n_c | n_k)		k = octetstring2key(DHSharedSecret | n_c | n_k)
	3.2.3.2 Using Public Key Encryption		3.2.3.2 Using Public Key Encryption
	skipping to change at page 19, line 22 ¶		skipping to change at page 19, line 22 ¶
	the KDC AS reply key using the same procedure used by the KDC as		the KDC AS reply key using the same procedure used by the KDC as
	defined in Section 3.2.3.1. Otherwise, the message contains the		defined in Section 3.2.3.1. Otherwise, the message contains the
	encKeyPack field, and the client decrypts and extracts the temporary		encKeyPack field, and the client decrypts and extracts the temporary
	key in the encryptedKey field of the member KeyTransRecipientInfo,		key in the encryptedKey field of the member KeyTransRecipientInfo,
	and then uses that as the KDC AS reply key.		and then uses that as the KDC AS reply key.
	In either case, the client MUST verify the signature in the		In either case, the client MUST verify the signature in the
	SignedData according to [RFC3852]. Unless the client can otherwise		SignedData according to [RFC3852]. Unless the client can otherwise
	prove that the public key used to verify the KDC's signature is bound		prove that the public key used to verify the KDC's signature is bound
	to the target KDC, the KDC's X.509 certificate MUST satisfy at least		to the target KDC, the KDC's X.509 certificate MUST satisfy at least
	one of the follow two requirements:		one of the following two requirements:
	1. The certificate contains a Subject Alternative Name (SAN)		1. The certificate contains a Subject Alternative Name (SAN)
	extension carrying a dNSName and that name value matches the		extension [RFC3280] carrying a dNSName and that name value
	following name format:		matches the following name format:
	_Service._Proto.Realm		_Service._Proto.Realm
	Where the Service name is the string literal "kerberos", the		Where the Service name is the string literal "kerberos", the
	Proto can be "udp" or "tcp", and the Realm is the domain style		Proto can be "udp" or "tcp", and the Realm is the domain style
	Kerberos realm name [CLAR] of the target KDC. This name format		Kerberos realm name [CLAR] of the target KDC. This name format
	is identical to the owner label format used in the DNS SRV		is identical to the owner label format used in the DNS SRV
	records for specifying the KDC location as described in [CLAR].		records for specifying the KDC location as described in [CLAR].
	For example, the X.509 certificate for the KDC of the Kerberos		For example, the X.509 certificate for the KDC of the Kerberos
	realm "EXAMPLE.COM" would contain a dNSName value of		realm "EXAMPLE.COM" would contain a dNSName value of
	skipping to change at page 22, line 24 ¶		skipping to change at page 22, line 24 ¶
	The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does		The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
	permit empty SEQUENCEs to be encoded. Such empty sequences may only		permit empty SEQUENCEs to be encoded. Such empty sequences may only
	be used if the KDC itself vouches for the user's certificate.		be used if the KDC itself vouches for the user's certificate.
	5. Acknowledgements		5. Acknowledgements
	The following people have made significant contributions to this		The following people have made significant contributions to this
	draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist		draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist
	Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle,		Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle,
	Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon and Karthik		Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik Jaganathan
	Jaganathan.		and Chaskiel M Grundman.
	Special thanks to Clifford Neuman, Matthew Hur and Sasha Medvinsky		Special thanks to Clifford Neuman, Matthew Hur and Sasha Medvinsky
	who wrote earlier versions of this document.		who wrote earlier versions of this document.
	The authors are indebt to the Kerberos working group chair Jeffrey		The authors are indebt to the Kerberos working group chair Jeffrey
	Hutzelman who kept track of various issues and was enormously helpful		Hutzelman who kept track of various issues and was enormously helpful
	during the creation of this document.		during the creation of this document.
	Some of the ideas on which this document is based arose during		Some of the ideas on which this document is based arose during
	discussions over several years between members of the SAAG, the IETF		discussions over several years between members of the SAAG, the IETF
	skipping to change at page 23, line 16 ¶		skipping to change at page 23, line 16 ¶
	7.1 Normative References		7.1 Normative References
	[CLAR] RFC-Editor: To be replaced by RFC number for draft-ietf-		[CLAR] RFC-Editor: To be replaced by RFC number for draft-ietf-
	krb-wg-kerberos-clarifications. Work in Progress.		krb-wg-kerberos-clarifications. Work in Progress.
	[IEEE1363]		[IEEE1363]
	IEEE, "Standard Specifications for Public Key		IEEE, "Standard Specifications for Public Key
	Cryptography", IEEE 1363, 2000.		Cryptography", IEEE 1363, 2000.
	[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		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",		[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
	RFC 2412, November 1998.		RFC 2412, November 1998.
	[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",		[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
	RFC 2631, June 1999.		RFC 2631, June 1999.
	[RFC3279] Bassham, L., Polk, W. and R. Housley, "Algorithms and		[RFC3279] Bassham, L., Polk, W. and R. Housley, "Algorithms and
	skipping to change at page 24, line 8 ¶		skipping to change at page 24, line 5 ¶
	Diffie-Hellman groups for Internet Key Exchange (IKE)",		Diffie-Hellman groups for Internet Key Exchange (IKE)",
	RFC 3526, May 2003.		RFC 3526, May 2003.
	[RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES)		[RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES)
	Encryption Algorithm in Cryptographic Message Syntax		Encryption Algorithm in Cryptographic Message Syntax
	(CMS)", RFC 3565, July 2003.		(CMS)", RFC 3565, July 2003.
	[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",		[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
	RFC 3852, July 2004.		RFC 3852, July 2004.
			[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
			Kerberos 5", RFC 3961, February 2005.
	[X.509-97] ITU-T. Recommendation X.509: The Directory - Authentication		[X.509-97] ITU-T. Recommendation X.509: The Directory - Authentication
	Framework. 1997.		Framework. 1997.
	[X690] ASN.1 encoding rules: Specification of Basic Encoding		[X690] ASN.1 encoding rules: Specification of Basic Encoding
	Rules (BER), Canonical Encoding Rules (CER) and		Rules (BER), Canonical Encoding Rules (CER) and
	Distinguished Encoding Rules (DER), ITU-T Recommendation		Distinguished Encoding Rules (DER), ITU-T Recommendation
	X.690 (1997) | ISO/IEC International Standard		X.690 (1997) | ISO/IEC International Standard
	8825-1:1998.		8825-1:1998.
	7.2 Informative References		7.2 Informative References
	skipping to change at page 26, line 34 ¶		skipping to change at page 26, line 34 ¶
	-- public key that the client already has.		-- public key that the client already has.
	...		...
	}		}
	DHNonce ::= OCTET STRING		DHNonce ::= OCTET STRING
	TrustedCA ::= SEQUENCE {		TrustedCA ::= SEQUENCE {
	caName [0] IMPLICIT OCTET STRING,		caName [0] IMPLICIT OCTET STRING,
	-- Contains a PKIX type Name encoded according to		-- Contains a PKIX type Name encoded according to
	-- [RFC3280].		-- [RFC3280].
	-- Identifies a CA.		-- Identifies a CA by the CA's distinguished subject
	-- Prefer the sid field below if that is available.		-- name.
	certificateSerialNumber [1] INTEGER OPTIONAL,		certificateSerialNumber [1] INTEGER OPTIONAL,
	-- Specifies the certificate serial number.		-- Specifies the CA certificate's serial number.
	-- The defintion of the certificate serial number		-- The defintion of the certificate serial number
	-- is taken from X.509 [X.509-97].		-- is taken from X.509 [X.509-97].
	subjectKeyIdentifier [2] OCTET STRING OPTIONAL,		subjectKeyIdentifier [2] OCTET STRING OPTIONAL,
	-- Identifies the CA's public key by a key		-- Identifies the CA's public key by a key
	-- identifier. When an X.509 certificate is		-- identifier. When an X.509 certificate is
	-- referenced, this key identifier matches the X.509		-- referenced, this key identifier matches the X.509
	-- subjectKeyIdentifier extension value. When other		-- subjectKeyIdentifier extension value. When other
	-- certificate formats are referenced, the documents		-- certificate formats are referenced, the documents
	-- that specify the certificate format and their use		-- that specify the certificate format and their use
	-- with the CMS must include details on matching the		-- with the CMS must include details on matching the
	-- key identifier to the appropriate certificate		-- key identifier to the appropriate certificate
	-- field.		-- field.
	...		...
	}		}
	AuthPack ::= SEQUENCE {		AuthPack ::= SEQUENCE {
	pkAuthenticator [0] PKAuthenticator,		pkAuthenticator [0] PKAuthenticator,
	clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,		clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
	-- Defined in [RFC3280].		-- Type SubjectPublicKeyInfo is defined in
	-- The pubic key value (the subjectPublicKey field		-- [RFC3280].
			-- Specifies Diffie-Hellman domain parameters
			-- and the client's public key value [IEEE1363].
			-- The public key value (the subjectPublicKey field
	-- of the type SubjectPublicKeyInfo) MUST be encoded		-- of the type SubjectPublicKeyInfo) MUST be encoded
	-- according to [RFC3279].		-- according to [RFC3279].
	-- Present only if the client wishes to use the		-- Present only if the client wishes to use the
	-- Diffie-Hellman key agreement method.		-- Diffie-Hellman key agreement method.
	supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier		supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
	OPTIONAL,		OPTIONAL,
	-- List of CMS encryption types supported by		-- Type AlgorithmIdentifier is defined in
			-- [RFC3280].
			-- List of CMS encryption types supported by the
	-- client in order of (decreasing) preference.		-- client in order of (decreasing) preference.
	clientDHNonce [3] DHNonce OPTIONAL,		clientDHNonce [3] DHNonce OPTIONAL,
	-- Present only if the client indicates that it		-- Present only if the client indicates that it
	-- wishes to reuse DH keys or to allow the KDC to		-- wishes to reuse DH keys or to allow the KDC to
	-- do so.		-- do so.
	...		...
	}		}
	PKAuthenticator ::= SEQUENCE {		PKAuthenticator ::= SEQUENCE {
	cusec [0] INTEGER (0..999999),		cusec [0] INTEGER (0..999999),
	skipping to change at page 29, line 31 ¶		skipping to change at page 29, line 38 ¶
	ReplyKeyPack ::= SEQUENCE {		ReplyKeyPack ::= SEQUENCE {
	replyKey [0] EncryptionKey,		replyKey [0] EncryptionKey,
	-- Contains the session key used to encrypt the		-- Contains the session key used to encrypt the
	-- enc-part field in the AS-REP.		-- enc-part field in the AS-REP.
	nonce [1] INTEGER (0..4294967295),		nonce [1] INTEGER (0..4294967295),
	-- Contains the nonce in the PKAuthenticator of the		-- Contains the nonce in the PKAuthenticator of the
	-- request.		-- request.
	...		...
	}		}
	TD-DH-PARAMETERS ::= SEQUENCE OF DHDomainParameters		TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
	-- Contains a list of Diffie-Hellman domain		-- Each AlgorithmIdentifier specifies a set of
	-- parameters in decreasing preference order.		-- Diffie-Hellman domain parameters [IEEE1363].
			-- This list is in decreasing preference order.
	DHDomainParameters ::= CHOICE {
	modp [0] DomainParameters,
	-- Type DomainParameters is defined in [RFC3279].
	ec [1] EcpkParameters,
	-- Type EcpkParameters is defined in [RFC3279].
	...
	}
	END		END
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		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		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
End of changes. 25 change blocks.
	59 lines changed or deleted		61 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/