< draft-ietf-cat-kerberos-pk-init-10.txt		draft-ietf-cat-kerberos-pk-init-11.txt >
	INTERNET-DRAFT Brian Tung		INTERNET-DRAFT Brian Tung
	draft-ietf-cat-kerberos-pk-init-10.txt Clifford Neuman		draft-ietf-cat-kerberos-pk-init-11.txt Clifford Neuman
	Updates: RFC 1510 ISI		Updates: RFC 1510 USC/ISI
	expires April 30, 2000 Matthew Hur		expires September 15, 2000 Matthew Hur
	CyberSafe Corporation		CyberSafe Corporation
	Ari Medvinsky		Ari Medvinsky
	Excite		Keen.com, Inc.
	Sasha Medvinsky		Sasha Medvinsky
	General Instrument		Motorola
	John Wray		John Wray
	Iris Associates, Inc.		Iris Associates, Inc.
	Jonathan Trostle		Jonathan Trostle
	Cisco		Cisco
	Public Key Cryptography for Initial Authentication in Kerberos		Public Key Cryptography for Initial Authentication in Kerberos
	0. Status Of This Memo		0. Status Of This Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	skipping to change at line 44 ¶		skipping to change at line 44 ¶
	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.
	To learn the current status of any Internet-Draft, please check		To learn the current status of any Internet-Draft, please check
	the "1id-abstracts.txt" listing contained in the Internet-Drafts		the "1id-abstracts.txt" listing contained in the Internet-Drafts
	Shadow Directories on ftp.ietf.org (US East Coast),		Shadow Directories on ftp.ietf.org (US East Coast),
	nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or		nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
	munnari.oz.au (Pacific Rim).		munnari.oz.au (Pacific Rim).
	The distribution of this memo is unlimited. It is filed as		The distribution of this memo is unlimited. It is filed as
	draft-ietf-cat-kerberos-pk-init-10.txt, and expires April 30,		draft-ietf-cat-kerberos-pk-init-11.txt, and expires September 15,
	2000. Please send comments to the authors.		2000. Please send comments to the authors.
	1. Abstract		1. Abstract
	This document defines extensions (PKINIT) to the Kerberos protocol		This document defines extensions (PKINIT) to the Kerberos protocol
	specification (RFC 1510 [1]) to provide a method for using public		specification (RFC 1510 [1]) to provide a method for using public
	key cryptography during initial authentication. The methods		key cryptography during initial authentication. The methods
	defined specify the ways in which preauthentication data fields and		defined specify the ways in which preauthentication data fields and
	error data fields in Kerberos messages are to be used to transport		error data fields in Kerberos messages are to be used to transport
	public key data.		public key data.
	skipping to change at line 184 ¶		skipping to change at line 184 ¶
	rsaEncryption-EnvOID (PKCS#1 v1.5) 13		rsaEncryption-EnvOID (PKCS#1 v1.5) 13
	rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14		rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14
	des-ede3-cbc-Env-OID 15		des-ede3-cbc-Env-OID 15
	These mappings are provided so that a client may send the		These mappings are provided so that a client may send the
	appropriate enctypes in the AS-REQ message in order to indicate		appropriate enctypes in the AS-REQ message in order to indicate
	support for the corresponding OIDs (for performing PKINIT).		support for the corresponding OIDs (for performing PKINIT).
	In many cases, PKINIT requires the encoding of the X.500 name of a		In many cases, PKINIT requires the encoding of the X.500 name of a
	certificate authority as a Realm. When such a name appears as		certificate authority as a Realm. When such a name appears as
	a ream it will be represented using the "other" form of the realm		a realm it will be represented using the "other" form of the realm
	name as specified in the naming constraints section of RFC1510.		name as specified in the naming constraints section of RFC1510.
	For a realm derived from an X.500 name, NAMETYPE will have the value		For a realm derived from an X.500 name, NAMETYPE will have the value
	X500-RFC2253. The full realm name will appear as follows:		X500-RFC2253. The full realm name will appear as follows:
	<nametype> + ":" + <string>		<nametype> + ":" + <string>
	where nametype is "X500-RFC2253" and string is the result of doing		where nametype is "X500-RFC2253" and string is the result of doing
	an RFC2253 encoding of the distinguished name, i.e.		an RFC2253 encoding of the distinguished name, i.e.
	"X500-RFC2253:" + RFC2253Encode(DistinguishedName)		"X500-RFC2253:" + RFC2253Encode(DistinguishedName)
	skipping to change at line 238 ¶		skipping to change at line 238 ¶
	name using the X500-RFC2253 realm name format described earlier in		name using the X500-RFC2253 realm name format described earlier in
	this section		this section
	RFC 1510 specifies the ASN.1 structure for PrincipalName as follows:		RFC 1510 specifies the ASN.1 structure for PrincipalName as follows:
	PrincipalName ::= SEQUENCE {		PrincipalName ::= SEQUENCE {
	name-type[0] INTEGER,		name-type[0] INTEGER,
	name-string[1] SEQUENCE OF GeneralString		name-string[1] SEQUENCE OF GeneralString
	}		}
	For the purposes of encoding an X.500 name within this structure,		For the purposes of encoding an X.500 name as a Kerberos name for
	the name-string shall be encoded as a single GeneralString.		use in Kerberos structures, the name-string shall be encoded as a
			single GeneralString. The name-type should be KRB_NT_X500_PRINCIPAL,
			as noted above. All Kerberos names must conform to validity
			requirements as given in RFC 1510. Note that name mapping may be
			required or optional, based on policy.
	Note that name mapping may be required or optional based on		We also define the following similar ASN.1 structure:
	policy. All names must conform to validity requirements as given
	in RFC 1510.		CertPrincipalName ::= SEQUENCE {
			name-type[0] INTEGER,
			name-string[1] SEQUENCE OF UTF8String
			}
			When a Kerberos PrincipalName is to be placed within an X.509 data
			structure, the CertPrincipalName structure is to be used, with the
			name-string encoded as a single UTF8String. The name-type should be
			as identified in the original PrincipalName structure. The mapping
			between the GeneralString and UTF8String formats can be found in
			[19].
			The following rules relate to the the matching of PrincipalNames (or
			corresponding CertPrincipalNames) with regard to the PKI name
			constraints for CAs as laid out in RFC 2459 [15]. In order to be
			regarded as a match (for permitted and excluded name trees), the
			following must be satisfied.
			1. If the constraint is given as a user plus realm name, or
			as a user plus instance plus realm name (as specified in
			RFC 1510), the realm name must be valid (see 2.a-d below)
			and the match must be exact, byte for byte.
			2. If the constraint is given only as a realm name, matching
			depends on the type of the realm:
			a. If the realm contains a colon (':') before any equal
			sign ('='), it is treated as a realm of type Other,
			and must match exactly, byte for byte.
			b. Otherwise, if the realm contains an equal sign, it
			is treated as an X.500 name. In order to match, every
			component in the constraint MUST be in the principal
			name, and have the same value. For example, 'C=US'
			matches 'C=US/O=ISI' but not 'C=UK'.
			c. Otherwise, if the realm name conforms to rules regarding
			the format of DNS names, it is considered a realm name of
			type Domain. The constraint may be given as a realm
			name 'FOO.BAR', which matches any PrincipalName within
			the realm 'FOO.BAR' but not those in subrealms such as
			'CAR.FOO.BAR'. A constraint of the form '.FOO.BAR'
			matches PrincipalNames in subrealms of the form
			'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself.
			d. Otherwise, the realm name is invalid and does not match
			under any conditions.
	3.1.1. Encryption and Key Formats		3.1.1. Encryption and Key Formats
	In the exposition below, we use the terms public key and private		In the exposition below, we use the terms public key and private
	key generically. It should be understood that the term "public		key generically. It should be understood that the term "public
	key" may be used to refer to either a public encryption key or a		key" may be used to refer to either a public encryption key or a
	signature verification key, and that the term "private key" may be		signature verification key, and that the term "private key" may be
	used to refer to either a private decryption key or a signature		used to refer to either a private decryption key or a signature
	generation key. The fact that these are logically distinct does		generation key. The fact that these are logically distinct does
	not preclude the assignment of bitwise identical keys for RSA		not preclude the assignment of bitwise identical keys for RSA
	skipping to change at line 333 ¶		skipping to change at line 383 ¶
	trusted authority. Note that the latter mode does not require the		trusted authority. Note that the latter mode does not require the
	use of certificates.		use of certificates.
	The initial authentication request is sent as per RFC 1510, except		The initial authentication request is sent as per RFC 1510, except
	that a preauthentication field containing data signed by the user's		that a preauthentication field containing data signed by the user's
	private key accompanies the request:		private key accompanies the request:
	PA-PK-AS-REQ ::= SEQUENCE {		PA-PK-AS-REQ ::= SEQUENCE {
	-- PA TYPE 14		-- PA TYPE 14
	signedAuthPack [0] SignedData		signedAuthPack [0] SignedData
	-- defined in CMS [11]		-- Defined in CMS [11];
	-- AuthPack (below) defines the data		-- AuthPack (below) defines the
	-- that is signed		-- data that is signed.
	trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL,		trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL,
	-- CAs that the client trusts		-- This is a list of CAs that the
			-- client trusts and that certify
			-- KDCs.
	kdcCert [2] IssuerAndSerialNumber OPTIONAL		kdcCert [2] IssuerAndSerialNumber OPTIONAL
	-- as defined in CMS [11]		-- As defined in CMS [11];
	-- specifies a particular KDC		-- specifies a particular KDC
	-- certificate if the client		-- certificate if the client
	-- already has it;		-- already has it.
	encryptionCert [3] IssuerAndSerialNumber OPTIONAL		encryptionCert [3] IssuerAndSerialNumber OPTIONAL
	-- For example, this may be the		-- For example, this may be the
	-- client's Diffie-Hellman		-- client's Diffie-Hellman
	-- certificate, or it may be the		-- certificate, or it may be the
	-- client's RSA encryption		-- client's RSA encryption
	-- certificate.		-- certificate.
	}		}
	TrustedCas ::= CHOICE {		TrustedCas ::= CHOICE {
	principalName [0] KerberosName,		principalName [0] KerberosName,
	skipping to change at line 364 ¶		skipping to change at line 416 ¶
	caName [1] Name		caName [1] Name
	-- fully qualified X.500 name		-- fully qualified X.500 name
	-- as defined by X.509		-- as defined by X.509
	issuerAndSerial [2] IssuerAndSerialNumber		issuerAndSerial [2] IssuerAndSerialNumber
	-- Since a CA may have a number of		-- Since a CA may have a number of
	-- certificates, only one of which		-- certificates, only one of which
	-- a client trusts		-- a client trusts
	}		}
	Usage of SignedData:		Usage of SignedData:
	The SignedData data type is specified in the Cryptographic
	Message Syntax, a product of the S/MIME working group of the IETF.		The SignedData data type is specified in the Cryptographic
	- The encapContentInfo field must contain the PKAuthenticator		Message Syntax, a product of the S/MIME working group of the
	and, optionally, the client's Diffie Hellman public value.		IETF. The following describes how to fill in the fields of
	- The eContentType field shall contain the OID value for		this data:
	id-data: iso(1) member-body(2) us(840) rsadsi(113549)
	pkcs(1) pkcs7(7) data(1)		1. The encapContentInfo field must contain the PKAuthenticator
	- The eContent field is data of the type AuthPack (below).		and, optionally, the client's Diffie Hellman public value.
	- The signerInfos field contains the signature of AuthPack.
	- The Certificates field, when non-empty, contains the client's		a. The eContentType field shall contain the OID value for
	certificate chain. If present, the KDC uses the public key from		pkdata: iso (1) org (3) dod (6) internet (1) security (5)
	the client's certificate to verify the signature in the request.		kerberosv5 (2) pkinit (3) pkdata (1)
	Note that the client may pass different certificates that are used
	for signing or for encrypting. Thus, the KDC may utilize a		b. The eContent field is data of the type AuthPack (below).
	different client certificate for signature verification than the
	one it uses to encrypt the reply to the client. For example, the		2. The signerInfos field contains the signature of AuthPack.
	client may place a Diffie-Hellman certificate in this field in
	order to convey its static Diffie Hellman certificate to the KDC to		3. The Certificates field, when non-empty, contains the client's
	enable static-ephemeral Diffie-Hellman mode for the reply; in this		certificate chain. If present, the KDC uses the public key
	case, the client does NOT place its public value in the AuthPack		from the client's certificate to verify the signature in the
	(defined below). As another example, the client may place an RSA		request. Note that the client may pass different certificate
	encryption certificate in this field. However, there must always		chains that are used for signing or for encrypting. Thus,
	be (at least) a signature certificate.		the KDC may utilize a different client certificate for
			signature verification than the one it uses to encrypt the
			reply to the client. For example, the client may place a
			Diffie-Hellman certificate in this field in order to convey
			its static Diffie Hellman certificate to the KDC to enable
			static-ephemeral Diffie-Hellman mode for the reply; in this
			case, the client does NOT place its public value in the
			AuthPack (defined below). As another example, the client may
			place an RSA encryption certificate in this field. However,
			there must always be (at least) a signature certificate.
	AuthPack ::= SEQUENCE {		AuthPack ::= SEQUENCE {
	pkAuthenticator [0] PKAuthenticator,		pkAuthenticator [0] PKAuthenticator,
	clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL		clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
	-- if client is using Diffie-Hellman		-- if client is using Diffie-Hellman
	-- (ephemeral-ephemeral only)		-- (ephemeral-ephemeral only)
	}		}
	PKAuthenticator ::= SEQUENCE {		PKAuthenticator ::= SEQUENCE {
	kdcName [0] PrincipalName,		kdcName [0] PrincipalName,
	skipping to change at line 506 ¶		skipping to change at line 567 ¶
	or realm as given in the PKAuthenticator does not match the KDC's		or realm as given in the PKAuthenticator does not match the KDC's
	actual principal name, then the KDC returns an error of type		actual principal name, then the KDC returns an error of type
	KDC_ERR_KDC_NAME_MISMATCH. The accompanying e-data field is again		KDC_ERR_KDC_NAME_MISMATCH. The accompanying e-data field is again
	a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or		a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or
	TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET		TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET
	STRING whose data-value is the DER encoding of a PrincipalName or		STRING whose data-value is the DER encoding of a PrincipalName or
	Realm as defined in RFC 1510 revisions.		Realm as defined in RFC 1510 revisions.
	Even if all succeeds, the KDC may--for policy reasons--decide not		Even if all succeeds, the KDC may--for policy reasons--decide not
	to trust the client. In this case, the KDC returns an error message		to trust the client. In this case, the KDC returns an error message
	of type KDC_ERR_CLIENT_NOT_TRUSTED.		of type KDC_ERR_CLIENT_NOT_TRUSTED. One specific case of this is
			the presence or absence of an Enhanced Key Usage (EKU) OID within
			the certificate extensions. The rules regarding acceptability of
			an EKU sequence (or the absence of any sequence) are a matter of
			local policy. For the benefit of implementers, we define a PKINIT
			EKU OID as the following: iso (1) org (3) dod (6) internet (1)
			security (5) kerberosv5 (2) pkinit (3) pkekuoid (2).
	If a trust relationship exists, the KDC then verifies the client's		If a trust relationship exists, the KDC then verifies the client's
	signature on AuthPack. If that fails, the KDC returns an error		signature on AuthPack. If that fails, the KDC returns an error
	message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the		message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the
	timestamp (ctime and cusec) in the PKAuthenticator to assure that		timestamp (ctime and cusec) in the PKAuthenticator to assure that
	the request is not a replay. The KDC also verifies that its name		the request is not a replay. The KDC also verifies that its name
	is specified in the PKAuthenticator.		is specified in the PKAuthenticator.
	If the clientPublicValue field is filled in, indicating that the		If the clientPublicValue field is filled in, indicating that the
	client wishes to use Diffie-Hellman key agreement, then the KDC		client wishes to use Diffie-Hellman key agreement, then the KDC
	skipping to change at line 557 ¶		skipping to change at line 624 ¶
	record in a security database based on local policy, for example		record in a security database based on local policy, for example
	the subject alt name may be kerberos/principal@realm format. In		the subject alt name may be kerberos/principal@realm format. In
	this case the realm name is not that of the CA but that of the		this case the realm name is not that of the CA but that of the
	local realm doing the mapping (or some realm name chosen by that		local realm doing the mapping (or some realm name chosen by that
	realm).		realm).
	If a non-KDC X.509 certificate contains the principal name within		If a non-KDC X.509 certificate contains the principal name within
	the subjectAltName version 3 extension , that name may utilize		the subjectAltName version 3 extension , that name may utilize
	KerberosName as defined below, or, in the case of an S/MIME		KerberosName as defined below, or, in the case of an S/MIME
	certificate [17], may utilize the email address. If the KDC		certificate [17], may utilize the email address. If the KDC
	is presented with as S/MIME certificate, then the email address		is presented with an S/MIME certificate, then the email address
	within subjectAltName will be interpreted as a principal and realm		within subjectAltName will be interpreted as a principal and realm
	separated by the "@" sign, or as a name that needs to be		separated by the "@" sign, or as a name that needs to be
	canonicalized. If the resulting name does not correspond to a		canonicalized. If the resulting name does not correspond to a
	registered principal name, then the principal name is formed as		registered principal name, then the principal name is formed as
	defined in section 3.1.		defined in section 3.1.
	The trustedCertifiers field contains a list of certification		The trustedCertifiers field contains a list of certification
	authorities trusted by the client, in the case that the client does		authorities trusted by the client, in the case that the client does
	not possess the KDC's public key certificate. If the KDC has no		not possess the KDC's public key certificate. If the KDC has no
	certificate signed by any of the trustedCertifiers, then it returns		certificate signed by any of the trustedCertifiers, then it returns
	skipping to change at line 607 ¶		skipping to change at line 674 ¶
	-- Defined in CMS		-- Defined in CMS
	-- The temporary key is encrypted		-- The temporary key is encrypted
	-- using the client public key		-- using the client public key
	-- key		-- key
	-- SignedReplyKeyPack, encrypted		-- SignedReplyKeyPack, encrypted
	-- with the temporary key, is also		-- with the temporary key, is also
	-- included.		-- included.
	}		}
	Usage of SignedData:		Usage of SignedData:
	If the Diffie-Hellman option is used, dhSignedData in PA-PK-AS-REP
	provides authenticated Diffie-Hellman parameters of the KDC. The		When the Diffie-Hellman option is used, dhSignedData in
	reply key used to encrypt part of the KDC reply message is derived		PA-PK-AS-REP provides authenticated Diffie-Hellman parameters
	from the Diffie-Hellman exchange:		of the KDC. The reply key used to encrypt part of the KDC reply
	- Both the KDC and the client calculate a secret value (g^ab mod p),		message is derived from the Diffie-Hellman exchange:
	where a is the client's private exponent and b is the KDC's
	private exponent.		1. Both the KDC and the client calculate a secret value
	- Both the KDC and the client take the first N bits of this secret		(g^ab mod p), where a is the client's private exponent and
	value and convert it into a reply key. N depends on the reply key		b is the KDC's private exponent.
	type.
	- If the reply key is DES, N=64 bits, where some of the bits are		2. Both the KDC and the client take the first N bits of this
	replaced with parity bits, according to FIPS PUB 74.		secret value and convert it into a reply key. N depends on
	- If the reply key is (3-key) 3-DES, N=192 bits, where some of the		the reply key type.
	bits are replaced with parity bits, according to FIPS PUB 74.
	- The encapContentInfo field must contain the KdcDHKeyInfo as		3. If the reply key is DES, N=64 bits, where some of the bits
	defined below.		are replaced with parity bits, according to FIPS PUB 74.
	- The eContentType field shall contain the OID value for
	id-data: iso(1) member-body(2) us(840) rsadsi(113549)		4. If the reply key is (3-key) 3-DES, N=192 bits, where some
	pkcs(1) pkcs7(7) data(1)		of the bits are replaced with parity bits, according to
	- The certificates field must contain the certificates necessary		FIPS PUB 74.
	for the client to establish trust in the KDC's certificate
	based on the list of trusted certifiers sent by the client in		5. The encapContentInfo field must contain the KdcDHKeyInfo as
	the PA-PK-AS-REQ. This field may be empty if the client did		defined below.
	not send to the KDC a list of trusted certifiers (the
	trustedCertifiers field was empty, meaning that the client		a. The eContentType field shall contain the OID value for
	already possesses the KDC's certificate).		pkdata: iso (1) org (3) dod (6) internet (1) security (5)
	- The signerInfos field is a SET that must contain at least one		kerberosv5 (2) pkinit (3) pkdata (1)
	member, since it contains the actual signature.
			b. The eContent field is data of the type KdcDHKeyInfo
			(below).
			6. The certificates field must contain the certificates
			necessary for the client to establish trust in the KDC's
			certificate based on the list of trusted certifiers sent by
			the client in the PA-PK-AS-REQ. This field may be empty if
			the client did not send to the KDC a list of trusted
			certifiers (the trustedCertifiers field was empty, meaning
			that the client already possesses the KDC's certificate).
			7. The signerInfos field is a SET that must contain at least
			one member, since it contains the actual signature.
	KdcDHKeyInfo ::= SEQUENCE {		KdcDHKeyInfo ::= SEQUENCE {
	-- used only when utilizing Diffie-Hellman		-- used only when utilizing Diffie-Hellman
	nonce [0] INTEGER,		nonce [0] INTEGER,
	-- binds responce to the request		-- binds responce to the request
	subjectPublicKey [2] BIT STRING		subjectPublicKey [2] BIT STRING
	-- Equals public exponent (g^a mod p)		-- Equals public exponent (g^a mod p)
	-- INTEGER encoded as payload of		-- INTEGER encoded as payload of
	-- BIT STRING		-- BIT STRING
	}		}
	Usage of EnvelopedData:		Usage of EnvelopedData:
	The EnvelopedData data type is specified in the Cryptographic
	Message Syntax, a product of the S/MIME working group of the IETF.		The EnvelopedData data type is specified in the Cryptographic
	It contains an temporary key encrypted with the PKINIT		Message Syntax, a product of the S/MIME working group of the
	client's public key. It also contains a signed and encrypted		IETF. It contains a temporary key encrypted with the PKINIT
	reply key.		client's public key. It also contains a signed and encrypted
	- The originatorInfo field is not required, since that information		reply key.
	may be presented in the signedData structure that is encrypted
	within the encryptedContentInfo field.		1. The originatorInfo field is not required, since that
	- The optional unprotectedAttrs field is not required for PKINIT.		information may be presented in the signedData structure
	- The recipientInfos field is a SET which must contain exactly one		that is encrypted within the encryptedContentInfo field.
	member of the KeyTransRecipientInfo type for encryption
	with an RSA public key.		2. The optional unprotectedAttrs field is not required for
	- The encryptedKey field (in KeyTransRecipientInfo) contains		PKINIT.
	the temporary key which is encrypted with the PKINIT client's
	public key.		3. The recipientInfos field is a SET which must contain exactly
	- The encryptedContentInfo field contains the signed and encrypted		one member of the KeyTransRecipientInfo type for encryption
	reply key.		with an RSA public key.
	- The contentType field shall contain the OID value for
	id-signedData: iso(1) member-body(2) us(840) rsadsi(113549)		a. The encryptedKey field (in KeyTransRecipientInfo)
	pkcs(1) pkcs7(7) signedData(2)		contains the temporary key which is encrypted with the
	- The encryptedContent field is encrypted data of the CMS type		PKINIT client's public key.
	signedData as specified below.
	- The encapContentInfo field must contains the ReplyKeyPack.		4. The encryptedContentInfo field contains the signed and
	- The eContentType field shall contain the OID value for		encrypted reply key.
	id-data: iso(1) member-body(2) us(840) rsadsi(113549)
	pkcs(1) pkcs7(7) data(1)		a. The contentType field shall contain the OID value for
	- The eContent field is data of the type ReplyKeyPack (below).		id-signedData: iso (1) member-body (2) us (840)
	- The certificates field must contain the certificates necessary		rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2)
	for the client to establish trust in the KDC's certificate
	based on the list of trusted certifiers sent by the client in		b. The encryptedContent field is encrypted data of the CMS
	the PA-PK-AS-REQ. This field may be empty if the client did		type signedData as specified below.
	not send to the KDC a list of trusted certifiers (the
	trustedCertifiers field was empty, meaning that the client		i. The encapContentInfo field must contains the
	already possesses the KDC's certificate).		ReplyKeyPack.
	- The signerInfos field is a SET that must contain at least one
	member, since it contains the actual signature.		* The eContentType field shall contain the OID value
			for pkdata: iso (1) org (3) dod (6) internet (1)
			security (5) kerberosv5 (2) pkinit (3) pkdata (1)
			* The eContent field is data of the type ReplyKeyPack
			(below).
			ii. The certificates field must contain the certificates
			necessary for the client to establish trust in the
			KDC's certificate based on the list of trusted
			certifiers sent by the client in the PA-PK-AS-REQ.
			This field may be empty if the client did not send
			to the KDC a list of trusted certifiers (the
			trustedCertifiers field was empty, meaning that the
			client already possesses the KDC's certificate).
			iii. The signerInfos field is a SET that must contain at
			least one member, since it contains the actual
			signature.
	ReplyKeyPack ::= SEQUENCE {		ReplyKeyPack ::= SEQUENCE {
	-- not used for Diffie-Hellman		-- not used for Diffie-Hellman
	replyKey [0] EncryptionKey,		replyKey [0] EncryptionKey,
	-- used to encrypt main reply		-- used to encrypt main reply
	-- ENCTYPE is at least as strong as		-- ENCTYPE is at least as strong as
	-- ENCTYPE of session key		-- ENCTYPE of session key
	nonce [1] INTEGER,		nonce [1] INTEGER,
	-- binds response to the request		-- binds response to the request
	-- must be same as the nonce		-- must be same as the nonce
	skipping to change at line 718 ¶		skipping to change at line 816 ¶
	as specified by the X.509 standard:		as specified by the X.509 standard:
	subjectAltName EXTENSION ::= {		subjectAltName EXTENSION ::= {
	SYNTAX GeneralNames		SYNTAX GeneralNames
	IDENTIFIED BY id-ce-subjectAltName		IDENTIFIED BY id-ce-subjectAltName
	}		}
	GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName		GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
	GeneralName ::= CHOICE {		GeneralName ::= CHOICE {
	otherName [0] INSTANCE OF OTHER-NAME,		otherName [0] OtherName,
	...		...
	}		}
	OTHER-NAME ::= TYPE-IDENTIFIER		OtherName ::= SEQUENCE {
			type-id OBJECT IDENTIFIER,
			value [0] EXPLICIT ANY DEFINED BY type-id
			}
	In this definition, otherName is a name of any form defined as an		For the purpose of specifying a Kerberos principal name, the value
	instance of the OTHER-NAME information object class. For the purpose		in OtherName shall be a KerberosName as defined in RFC 1510, but with
	of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will		the PrincipalName replaced by CertPrincipalName as mentioned in
	be chosen and replaced by the type KerberosName:		Section 3.1:
	KerberosName ::= SEQUENCE {		KerberosName ::= SEQUENCE {
	realm [0] Realm,		realm [0] Realm,
	-- as defined in RFC 1510		principalName [1] CertPrincipalName -- defined above
	principalName [1] PrincipalName,
	-- as defined in RFC 1510
	}		}
	This specific syntax is identified within subjectAltName by setting		This specific syntax is identified within subjectAltName by setting
	the OID id-ce-subjectAltName to krb5PrincipalName, where (from the		the type-id in OtherName to krb5PrincipalName, where (from the
	Kerberos specification) we have		Kerberos specification) we have
	krb5 OBJECT IDENTIFIER ::= { iso (1)		krb5 OBJECT IDENTIFIER ::= { iso (1)
	org (3)		org (3)
	dod (6)		dod (6)
	internet (1)		internet (1)
	security (5)		security (5)
	kerberosv5 (2) }		kerberosv5 (2) }
	krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }		krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }
	skipping to change at line 768 ¶		skipping to change at line 867 ¶
	exchanged between the client and the KDC. The client uses this		exchanged between the client and the KDC. The client uses this
	random key to decrypt the main reply, and subsequently proceeds as		random key to decrypt the main reply, and subsequently proceeds as
	described in RFC 1510.		described in RFC 1510.
	3.2.3. Required Algorithms		3.2.3. Required Algorithms
	Not all of the algorithms in the PKINIT protocol specification have		Not all of the algorithms in the PKINIT protocol specification have
	to be implemented in order to comply with the proposed standard.		to be implemented in order to comply with the proposed standard.
	Below is a list of the required algorithms:		Below is a list of the required algorithms:
	- Diffie-Hellman public/private key pairs		* Diffie-Hellman public/private key pairs
	- utilizing Diffie-Hellman ephemeral-ephemeral mode		* utilizing Diffie-Hellman ephemeral-ephemeral mode
	- SHA1 digest and DSA for signatures		* SHA1 digest and DSA for signatures
	- 3-key triple DES keys derived from the Diffie-Hellman Exchange		* 3-key triple DES keys derived from the Diffie-Hellman Exchange
	- 3-key triple DES Temporary and Reply keys		* 3-key triple DES Temporary and Reply keys
	4. Logistics and Policy		4. Logistics and Policy
	This section describes a way to define the policy on the use of		This section describes a way to define the policy on the use of
	PKINIT for each principal and request.		PKINIT for each principal and request.
	The KDC is not required to contain a database record for users		The KDC is not required to contain a database record for users
	who use public key authentication. However, if these users are		who use public key authentication. However, if these users are
	registered with the KDC, it is recommended that the database record		registered with the KDC, it is recommended that the database record
	for these users be modified to an additional flag in the attributes		for these users be modified to an additional flag in the attributes
	skipping to change at line 796 ¶		skipping to change at line 895 ¶
	type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication		type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication
	field of type PA-PK-AS-REQ must be included in the request.		field of type PA-PK-AS-REQ must be included in the request.
	5. Security Considerations		5. Security Considerations
	PKINIT raises a few security considerations, which we will address		PKINIT raises a few security considerations, which we will address
	in this section.		in this section.
	First of all, PKINIT introduces a new trust model, where KDCs do not		First of all, PKINIT introduces a new trust model, where KDCs do not
	(necessarily) certify the identity of those for whom they issue		(necessarily) certify the identity of those for whom they issue
	tickets. PKINIT does allow KDCs to act as their own CAs, in order		tickets. PKINIT does allow KDCs to act as their own CAs, in the
	to simplify key management, but one of the additional benefits is to		limited capacity of self-signing their certificates, but one of the
	align Kerberos authentication with a global public key		additional benefits is to align Kerberos authentication with a global
	infrastructure. Anyone using PKINIT in this way must be aware of		public key infrastructure. Anyone using PKINIT in this way must be
	how the certification infrastructure they are linking to works.		aware of how the certification infrastructure they are linking to
			works.
	Secondly, PKINIT also introduces the possibility of interactions		Secondly, PKINIT also introduces the possibility of interactions
	between different cryptosystems, which may be of widely varying		between different cryptosystems, which may be of widely varying
	strengths. Many systems, for instance, allow the use of 512-bit		strengths. Many systems, for instance, allow the use of 512-bit
	public keys. Using such keys to wrap data encrypted under strong		public keys. Using such keys to wrap data encrypted under strong
	conventional cryptosystems, such as triple-DES, is inappropriate;		conventional cryptosystems, such as triple-DES, is inappropriate;
	it adds a weak link to a strong one at extra cost. Implementors		it adds a weak link to a strong one at extra cost. Implementors
	and administrators should take care to avoid such wasteful and		and administrators should take care to avoid such wasteful and
	deceptive interactions.		deceptive interactions.
	skipping to change at line 840 ¶		skipping to change at line 940 ¶
	[1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service		[1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service
	(V5). Request for Comments 1510.		(V5). Request for Comments 1510.
	[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service		[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
	for Computer Networks, IEEE Communications, 32(9):33-38. September		for Computer Networks, IEEE Communications, 32(9):33-38. September
	1994.		1994.
	[3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld,		[3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld,
	A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm		A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm
	Authentication in Kerberos.		Authentication in Kerberos. draft-ietf-cat-kerberos-pk-cross-04.txt
	draft-ietf-cat-kerberos-pk-cross-04.txt
	[4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in		[4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in
	Kerberos.		Kerberos. draft-ietf-cat-kerberos-anoncred-00.txt
	draft-ietf-cat-kerberos-anoncred-00.txt
	[5] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing		[5] Ari Medvinsky, M. Hur, Alexander Medvinsky, B. Clifford Neuman.
	Tickets for Application Servers (PKTAPP).		Public Key Utilizing Tickets for Application Servers (PKTAPP).
	draft-ietf-cat-pktapp-00.txt		draft-ietf-cat-pktapp-02.txt
	[6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos		[6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos
	Using Public Key Cryptography. Symposium On Network and Distributed		Using Public Key Cryptography. Symposium On Network and Distributed
	System Security, 1997.		System Security, 1997.
	[7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction		[7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction
	Protocol. In Proceedings of the USENIX Workshop on Electronic		Protocol. In Proceedings of the USENIX Workshop on Electronic
	Commerce, July 1995.		Commerce, July 1995.
	[8] T. Dierks, C. Allen. The TLS Protocol, Version 1.0		[8] T. Dierks, C. Allen. The TLS Protocol, Version 1.0
	skipping to change at line 901 ¶		skipping to change at line 999 ¶
	[16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography		[16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
	Specifications, October 1998. Request for Comments 2437.		Specifications, October 1998. Request for Comments 2437.
	[17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. S/MIME		[17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. S/MIME
	Version 2 Certificate Handling, March 1998. Request for		Version 2 Certificate Handling, March 1998. Request for
	Comments 2312.		Comments 2312.
	[18] M. Wahl, T. Howes, S. Kille. Lightweight Directory Access		[18] M. Wahl, T. Howes, S. Kille. Lightweight Directory Access
	Protocol (v3), December 1997. Request for Comments 2251.		Protocol (v3), December 1997. Request for Comments 2251.
			[19] ITU-T (formerly CCITT) Information Processing Systems - Open
			Systems Interconnection - Specification of Abstract Syntax Notation
			One (ASN.1) Rec. X.680 ISO/IEC 8824-1
	8. Acknowledgements		8. Acknowledgements
	Some of the ideas on which this proposal is based arose during		Some of the ideas on which this proposal 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
	CAT working group, and the PSRG, regarding integration of Kerberos		CAT working group, and the PSRG, regarding integration of Kerberos
	and SPX. Some ideas have also been drawn from the DASS system.		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		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		attempt to revive some of the goals of those groups, and this
	proposal approaches those goals primarily from the Kerberos		proposal approaches those goals primarily from the Kerberos
	perspective. Lastly, comments from groups working on similar ideas		perspective. Lastly, comments from groups working on similar ideas
	in DCE have been invaluable.		in DCE have been invaluable.
	9. Expiration Date		9. Expiration Date
	This draft expires April 30, 2000.		This draft expires September 15, 2000.
	10. Authors		10. Authors
	Brian Tung		Brian Tung
	Clifford Neuman		Clifford Neuman
	USC Information Sciences Institute		USC Information Sciences Institute
	4676 Admiralty Way Suite 1001		4676 Admiralty Way Suite 1001
	Marina del Rey CA 90292-6695		Marina del Rey CA 90292-6695
	Phone: +1 310 822 1511		Phone: +1 310 822 1511
	E-mail: {brian, bcn}@isi.edu		E-mail: {brian, bcn}@isi.edu
	Matthew Hur		Matthew Hur
	CyberSafe Corporation		CyberSafe Corporation
	1605 NW Sammamish Road		1605 NW Sammamish Road
	Issaquah WA 98027-5378		Issaquah WA 98027-5378
	Phone: +1 425 391 6000		Phone: +1 425 391 6000
	E-mail: matt.hur@cybersafe.com		E-mail: matt.hur@cybersafe.com
	Ari Medvinsky		Ari Medvinsky
	Excite		Keen.com, Inc.
	555 Broadway		150 Independence Drive
	Redwood City, CA 94063		Menlo Park CA 94025
	Phone +1 650 569 2119		Phone: +1 650 289 3134
	E-mail: amedvins@excitecorp.com		E-mail: ari@keen.com
	Sasha Medvinsky		Sasha Medvinsky
	General Instrument		Motorola
	6450 Sequence Drive		6450 Sequence Drive
	San Diego, CA 92121		San Diego, CA 92121
	Phone +1 619 404 2825		Phone +1 619 404 2825
	E-mail: smedvinsky@gi.com		E-mail: smedvinsky@gi.com
	John Wray		John Wray
	Iris Associates, Inc.		Iris Associates, Inc.
	5 Technology Park Dr.		5 Technology Park Dr.
	Westford, MA 01886		Westford, MA 01886
	E-mail: John_Wray@iris.com		E-mail: John_Wray@iris.com
End of changes. 30 change blocks.
	142 lines changed or deleted		244 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/