< draft-ietf-cat-kerberos-pk-init-04.txt		draft-ietf-cat-kerberos-pk-init-05.txt >
	INTERNET-DRAFT Brian Tung		INTERNET-DRAFT Brian Tung
	draft-ietf-cat-kerberos-pk-init-04.txt Clifford Neuman		draft-ietf-cat-kerberos-pk-init-05.txt Clifford Neuman
	Updates: RFC 1510 ISI		Updates: RFC 1510 ISI
	expires January 31, 1998 John Wray		expires May 26, 1998 John Wray
	Digital Equipment Corporation		Digital Equipment Corporation
	Ari Medvinsky		Ari Medvinsky
	Matthew Hur		Matthew Hur
	CyberSafe Corporation		CyberSafe Corporation
	Jonathan Trostle		Jonathan Trostle
	Novell		Novell
	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
	skipping to change at line 34 ¶		skipping to change at line 35 ¶
	as reference material or to cite them other than as "work in		as reference material or to cite them other than as "work in
	progress."		progress."
	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 ds.internic.net (US East Coast),		Shadow Directories on ds.internic.net (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-04.txt, and expires January 31,		draft-ietf-cat-kerberos-pk-init-05.txt, and expires May 26, 1998.
	1998. Please send comments to the authors.		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 69 ¶		skipping to change at line 70 ¶
	is the concern of the current document.		is the concern of the current document.
	One of the guiding principles in the design of PKINIT is that		One of the guiding principles in the design of PKINIT is that
	changes should be as minimal as possible. As a result, the basic		changes should be as minimal as possible. As a result, the basic
	mechanism of PKINIT is as follows: The user sends a request to the		mechanism of PKINIT is as follows: The user sends a request to the
	KDC as before, except that if that user is to use public key		KDC as before, except that if that user is to use public key
	cryptography in the initial authentication step, his certificate		cryptography in the initial authentication step, his certificate
	accompanies the initial request, in the preauthentication fields.		accompanies the initial request, in the preauthentication fields.
	Upon receipt of this request, the KDC verifies the certificate and		Upon receipt of this request, the KDC verifies the certificate and
	issues a ticket granting ticket (TGT) as before, except that instead		issues a ticket granting ticket (TGT) as before, except that
	of being encrypted in the user's long-term key (which is derived		the encPart from the AS-REP message carrying the TGT is now
	from a password), it is encrypted in a randomly-generated key. This		encrypted in a randomly-generated key, instead of the user's
			long-term key (which is derived from a password). This
	random key is in turn encrypted using the public key from the		random key is in turn encrypted using the public key from the
	certificate that came with the request and signed using the KDC's		certificate that came with the request and signed using the KDC's
	private key, and accompanies the reply, in the preauthentication		private key, and accompanies the reply, in the preauthentication
	fields.		fields.
	PKINIT also allows for users with only digital signature keys to		PKINIT also allows for users with only digital signature keys to
	authenticate using those keys, and for users to store and retrieve		authenticate using those keys, and for users to store and retrieve
	private keys on the KDC.		private keys on the KDC.
	The PKINIT specification may also be used for direct peer to peer		The PKINIT specification may also be used for direct peer to peer
	skipping to change at line 100 ¶		skipping to change at line 102 ¶
	delegation (see [8]).		delegation (see [8]).
	3. Proposed Extensions		3. Proposed Extensions
	This section describes extensions to RFC 1510 for supporting the		This section describes extensions to RFC 1510 for supporting the
	use of public key cryptography in the initial request for a ticket		use of public key cryptography in the initial request for a ticket
	granting ticket (TGT).		granting ticket (TGT).
	In summary, the following changes to RFC 1510 are proposed:		In summary, the following changes to RFC 1510 are proposed:
	--> Users may authenticate using either a public key pair or a		* Users may authenticate using either a public key pair or a
	conventional (symmetric) key. If public key cryptography is		conventional (symmetric) key. If public key cryptography is
	used, public key data is transported in preauthentication		used, public key data is transported in preauthentication
	data fields to help establish identity.		data fields to help establish identity.
	--> Users may store private keys on the KDC for retrieval during		* Users may store private keys on the KDC for retrieval during
	Kerberos initial authentication.		Kerberos initial authentication.
	This proposal addresses two ways that users may use public key		This proposal addresses two ways that users may use public key
	cryptography for initial authentication. Users may present public		cryptography for initial authentication. Users may present public
	key certificates, or they may generate their own session key,		key certificates, or they may generate their own session key,
	signed by their digital signature key. In either case, the end		signed by their digital signature key. In either case, the end
	result is that the user obtains an ordinary TGT that may be used for		result is that the user obtains an ordinary TGT that may be used for
	subsequent authentication, with such authentication using only		subsequent authentication, with such authentication using only
	conventional cryptography.		conventional cryptography.
	Section 3.1 provides definitions to help specify message formats.		Section 3.1 provides definitions to help specify message formats.
	skipping to change at line 151 ¶		skipping to change at line 153 ¶
	PA-PK-KEY-REQ 17		PA-PK-KEY-REQ 17
	PA-PK-KEY-REP 18		PA-PK-KEY-REP 18
	The extensions also involve new error types; we propose the addition		The extensions also involve new error types; we propose the addition
	of the following types:		of the following types:
	KDC_ERR_CLIENT_NOT_TRUSTED 62		KDC_ERR_CLIENT_NOT_TRUSTED 62
	KDC_ERR_KDC_NOT_TRUSTED 63		KDC_ERR_KDC_NOT_TRUSTED 63
	KDC_ERR_INVALID_SIG 64		KDC_ERR_INVALID_SIG 64
	KDC_ERR_KEY_TOO_WEAK 65		KDC_ERR_KEY_TOO_WEAK 65
			KDC_ERR_CERTIFICATE_MISMATCH 66
	In many cases, PKINIT requires the encoding of an X.500 name as a		In many cases, PKINIT requires the encoding of an X.500 name as a
	Realm. In these cases, the realm will be represented using a		Realm. In these cases, the realm will be represented using a
	different style, specified in RFC 1510 with the following example:		different style, specified in RFC 1510 with the following example:
	NAMETYPE:rest/of.name=without-restrictions		NAMETYPE:rest/of.name=without-restrictions
	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-ASN1-BASE64. The full realm name will appear as follows:		X500-RFC1779. The full realm name will appear as follows:
	X500-ASN1-BASE64:Base64Encode(DistinguishedName)		X500-RFC1779:RFC1779Encode(DistinguishedName)
	where Base64 is an ASCII encoding of binary data as per RFC 1521,		where DistinguishedName is an X.500 name, and RFC1779Encode is a
	and DistinguishedName is the ASN.1 encoding of the X.500		readable ASCII encoding of an X.500 name, as defined by RFC 1779.
	Distinguished Name from the X.509 certificate.		To ensure that this encoding is unique, we add the following rules
			to those specified by RFC 1779:
			* The optional spaces specified in RFC 1779 are not allowed.
			* The character that separates relative distinguished names
			must be ',' (i.e., it must never be ';').
			* Attribute values must not be enclosed in double quotes.
			* Attribute values must not be specified as hexadecimal
			numbers.
			* When an attribute name is specified in the form of an OID,
			it must start with the 'OID.' prefix, and not the 'oid.'
			prefix.
			* The order in which the attributes appear in the RFC 1779
			encoding must be the reverse of the order in the ASN.1
			encoding of the X.500 name that appears in the public key
			certificate, because RFC 1779 requires that the least
			significant relative distinguished name appear first. The
			order of the relative distinguished names, as well as the
			order of the attributes within each relative distinguished
			name, will be reversed.
	Similarly, PKINIT may require the encoding of an X.500 name as a		Similarly, PKINIT may require the encoding of an X.500 name as a
	PrincipalName. In these cases, the name-type of the principal name		PrincipalName. In these cases, the name-type of the principal name
	shall be set to NT-X500-PRINCIPAL, and the name-string shall be set		shall be set to NT-X500-PRINCIPAL. This new name type is defined
	as follows:		as:
			#define CSFC5c_NT_X500_PRINCIPAL 6
	Base64Encode(DistinguishedName)		The name-string shall be set as follows:
	as described above.		RFC1779Encode(DistinguishedName)
	[Similar description needed on how realm names and principal names		as described above.
	are to be derived from PGP names.]
	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.		not preclude the assignment of bitwise identical keys.
	skipping to change at line 212 ¶		skipping to change at line 234 ¶
	RFC 1510, Section 6.1, defines EncryptedData as follows:		RFC 1510, Section 6.1, defines EncryptedData as follows:
	EncryptedData ::= SEQUENCE {		EncryptedData ::= SEQUENCE {
	etype [0] INTEGER,		etype [0] INTEGER,
	kvno [1] INTEGER OPTIONAL,		kvno [1] INTEGER OPTIONAL,
	cipher [2] OCTET STRING		cipher [2] OCTET STRING
	-- is CipherText		-- is CipherText
	}		}
	RFC 1510 suggests that ciphertext is coded as follows:		RFC 1510 also defines how CipherText is to be composed. It is not
			an ASN.1 data structure, but rather an octet string which is the
	CipherText ::= ENCRYPTED SEQUENCE {		encryption of a plaintext string. This plaintext string is in turn
	confounder [0] UNTAGGED OCTET STRING(conf_length)		a concatenation of the following octet strings: a confounder, a
	OPTIONAL,		checksum, the message, and padding. Details of how these components
	check [1] UNTAGGED OCTET STRING(checksum_length)		are arranged can be found in RFC 1510.
	OPTIONAL,
	msg-seq [2] MsgSequence,
	pad [3] UNTAGGED OCTET STRING(pad_length)
	OPTIONAL
	}
	The PKINIT protocol introduces several new types of encryption.		The PKINIT protocol introduces several new types of encryption.
	Data that is encrypted with a public key will allow only the check		Data that is encrypted with a public key will allow only the check
	optional field, as it is defined above. This type of the checksum		optional field, as it is defined above. This type of the checksum
	will be specified in the etype field, together with the encryption		will be specified in the etype field, together with the encryption
	type.		type.
	In order to identify the checksum type, etype will have the		In order to identify the checksum type, etype will have the
	following values:		following values:
	skipping to change at line 259 ¶		skipping to change at line 276 ¶
	It is assumed that all public keys are signed by some certification		It is assumed that all public keys are signed by some certification
	authority (CA). The initial authentication request is sent as per		authority (CA). The initial authentication request is sent as per
	RFC 1510, except that a preauthentication field containing data		RFC 1510, except that a preauthentication field containing data
	signed by the user's private key accompanies the request:		signed by the user's private key accompanies the request:
	PA-PK-AS-REQ ::= SEQUENCE {		PA-PK-AS-REQ ::= SEQUENCE {
	-- PA TYPE 14		-- PA TYPE 14
	signedAuthPack [0] SignedAuthPack		signedAuthPack [0] SignedAuthPack
	userCert [1] SEQUENCE OF Certificate OPTIONAL,		userCert [1] SEQUENCE OF Certificate OPTIONAL,
	-- the user's certificate chain		-- the user's certificate chain
	trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL		trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL,
	-- CAs that the client trusts		-- CAs that the client trusts
			serialNumber [3] CertificateSerialNumber OPTIONAL
			-- specifying a particular
			-- certificate if the client
			-- already has it;
			-- must be accompanied by
			-- a single trustedCertifier
	}		}
			CertificateSerialNumber ::= INTEGER
			-- as specified by PKCS 6
	SignedAuthPack ::= SEQUENCE {		SignedAuthPack ::= SEQUENCE {
	authPack [0] AuthPack,		authPack [0] AuthPack,
	authPackSig [1] Signature,		authPackSig [1] Signature,
	-- of authPack		-- of authPack
	-- using user's private key		-- using user's private key
	}		}
	AuthPack ::= SEQUENCE {		AuthPack ::= SEQUENCE {
	pkAuthenticator [0] PKAuthenticator,		pkAuthenticator [0] PKAuthenticator,
	clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL		clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
	skipping to change at line 333 ¶		skipping to change at line 359 ¶
	Certificate ::= SEQUENCE {		Certificate ::= SEQUENCE {
	certType [0] INTEGER,		certType [0] INTEGER,
	-- type of certificate		-- type of certificate
	-- 1 = X.509v3 (DER encoding)		-- 1 = X.509v3 (DER encoding)
	-- 2 = PGP (per PGP specification)		-- 2 = PGP (per PGP specification)
	certData [1] OCTET STRING		certData [1] OCTET STRING
	-- actual certificate		-- actual certificate
	-- type determined by certType		-- type determined by certType
	}		}
			If the client passes a certificate serial number in the request,
			the KDC is requested to use the referred-to certificate. If none
			exists, then the KDC returns an error of type
			KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the
			other hand, the client does not pass any trustedCertifiers,
			believing that it has the KDC's certificate, but the KDC has more
			than one certificate.
	The PKAuthenticator carries information to foil replay attacks,		The PKAuthenticator carries information to foil replay attacks,
	to bind the request and response, and to optionally pass the		to bind the request and response, and to optionally pass the
	client's Diffie-Hellman public value (i.e. for using DSA in		client's Diffie-Hellman public value (i.e. for using DSA in
	combination with Diffie-Hellman). The PKAuthenticator is signed		combination with Diffie-Hellman). The PKAuthenticator is signed
	with the private key corresponding to the public key in the		with the private key corresponding to the public key in the
	certificate found in userCert (or cached by the KDC).		certificate found in userCert (or cached by the KDC).
	In the PKAuthenticator, the client may specify the KDC name in one		In the PKAuthenticator, the client may specify the KDC name in one
	of two ways:		of two ways:
	skipping to change at line 361 ¶		skipping to change at line 395 ¶
	The userCert field is a sequence of certificates, the first of which		The userCert field is a sequence of certificates, the first of which
	must be the user's public key certificate. Any subsequent		must be the user's public key certificate. Any subsequent
	certificates will be certificates of the certifiers of the user's		certificates will be certificates of the certifiers of the user's
	certificate. These cerificates may be used by the KDC to verify the		certificate. These cerificates may be used by the KDC to verify the
	user's public key. This field may be left empty if the KDC already		user's public key. This field may be left empty if the KDC already
	has the user's certificate.		has the user's certificate.
	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.		not possess the KDC's public key certificate. If the KDC has no
			certificate signed by any of the trustedCertifiers, then it returns
			an error of type KDC_ERR_CERTIFICATE_MISMATCH.
	Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication		Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
	type, the KDC attempts to verify the user's certificate chain		type, the KDC attempts to verify the user's certificate chain
	(userCert), if one is provided in the request. This is done by		(userCert), if one is provided in the request. This is done by
	verifying the certification path against the KDC's policy of		verifying the certification path against the KDC's policy of
	legitimate certifiers. This may be based on a certification		legitimate certifiers. This may be based on a certification
	hierarchy, or it may be simply a list of recognized certifiers in a		hierarchy, or it may be simply a list of recognized certifiers in a
	system like PGP.		system like PGP.
	If verification of the user's certificate fails, the KDC sends back		If verification of the user's certificate fails, the KDC sends back
	an error message of type KDC_ERR_CLIENT_NOT_TRUSTED. The e-data		an error message of type KDC_ERR_CLIENT_NOT_TRUSTED. The e-data
	field contains additional information pertaining to this error, and		field contains additional information pertaining to this error, and
	is formatted as follows:		is formatted as follows:
	METHOD-DATA ::= SEQUENCE {		METHOD-DATA ::= SEQUENCE {
	method-type [0] INTEGER,		method-type [0] INTEGER,
	-- 1 = cannot verify public key		-- 1 = cannot verify public key
	-- 2 = invalid certificate		-- 2 = invalid certificate
	-- 3 = revoked certificate		-- 3 = revoked certificate
	-- 4 = invalid KDC name		-- 4 = invalid KDC name
			-- 5 = client name mismatch
	method-data [1] OCTET STRING OPTIONAL		method-data [1] OCTET STRING OPTIONAL
	} -- syntax as for KRB_AP_ERR_METHOD (RFC 1510)		} -- syntax as for KRB_AP_ERR_METHOD (RFC 1510)
	The values for the method-type and method-data fields are described		The values for the method-type and method-data fields are described
	in Section 3.2.1.		in Section 3.2.1.
	If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC		If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC
	verifies that it has a certificate issued by one of the certifiers		verifies that it has a certificate issued by one of the certifiers
	trusted by the client. If it does not have a suitable certificate,		trusted by the client. If it does not have a suitable certificate,
	the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to		the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to
	the client.		the client.
	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 PKAuthenticator. If that fails, the KDC returns an		signature on AuthPack. If that fails, the KDC returns an error
	error message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses		message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the
	the timestamp in the PKAuthenticator to assure that the request is		timestamp in the PKAuthenticator to assure that the request is not a
	not a replay. The KDC also verifies that its name is specified in		replay. The KDC also verifies that its name is specified in the
	the PKAuthenticator.		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
	checks to see that the parameters satisfy its policy. If they do		checks to see that the parameters satisfy its policy. If they do
	not (e.g., the prime size is insufficient for the expected		not (e.g., the prime size is insufficient for the expected
	encryption type), then the KDC sends back an error message of type		encryption type), then the KDC sends back an error message of type
	KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and		KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and
	private values for the response.		private values for the response.
	The KDC also checks that the timestamp in the PKAuthenticator is		The KDC also checks that the timestamp in the PKAuthenticator is
	skipping to change at line 453 ¶		skipping to change at line 490 ¶
	SignedReplyKeyPack ::= SEQUENCE {		SignedReplyKeyPack ::= SEQUENCE {
	replyKeyPack [0] ReplyKeyPack,		replyKeyPack [0] ReplyKeyPack,
	replyKeyPackSig [1] Signature,		replyKeyPackSig [1] Signature,
	-- of replyEncKeyPack		-- of replyEncKeyPack
	-- using KDC's private key		-- using KDC's private key
	}		}
	ReplyKeyPack ::= SEQUENCE {		ReplyKeyPack ::= SEQUENCE {
	replyKey [0] EncryptionKey,		replyKey [0] EncryptionKey,
	-- used to encrypt main reply		-- used to encrypt main reply
			-- of same ENCTYPE as 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
	-- passed in the PKAuthenticator		-- passed in the PKAuthenticator
	}		}
	TmpKeyPack ::= SEQUENCE {		TmpKeyPack ::= SEQUENCE {
	tmpKey [0] EncryptionKey,		tmpKey [0] EncryptionKey,
	-- used to encrypt the		-- used to encrypt the
	-- SignedReplyKeyPack		-- SignedReplyKeyPack
			-- of same ENCTYPE as session key
	}		}
	SignedKDCPublicValue ::= SEQUENCE {		SignedKDCPublicValue ::= SEQUENCE {
	kdcPublicValue [0] SubjectPublicKeyInfo,		kdcPublicValue [0] SubjectPublicKeyInfo,
	-- as described above		-- as described above
	kdcPublicValueSig [1] Signature		kdcPublicValueSig [1] Signature
	-- of kdcPublicValue		-- of kdcPublicValue
	-- using KDC's private key		-- using KDC's private key
	}		}
	skipping to change at line 491 ¶		skipping to change at line 530 ¶
	Since each certifier in the certification path of a user's		Since each certifier in the certification path of a user's
	certificate is essentially a separate realm, the name of each		certificate is essentially a separate realm, the name of each
	certifier shall be added to the transited field of the ticket. The		certifier shall be added to the transited field of the ticket. The
	format of these realm names is defined in Section 3.1 of this		format of these realm names is defined in Section 3.1 of this
	document. If applicable, the transit-policy-checked flag should be		document. If applicable, the transit-policy-checked flag should be
	set in the issued ticket.		set in the issued ticket.
	The KDC's certificate must bind the public key to a name derivable		The KDC's certificate must bind the public key to a name derivable
	from the name of the realm for that KDC. For an X.509 certificate,		from the name of the realm for that KDC. For an X.509 certificate,
	this is done as follows. The certificate will contain a		this is done as follows. The name of the KDC will be represented
	distinguished X.500 name contains, in addition to other attributes,		as an OtherName, encoded as a GeneralString:
	an extended attribute, called principalName, with the KDC's
	principal name as its value (as the text string
	krbtgt/<realm_name>@<realm_name>, where <realm_name> is the realm
	name of the KDC):
	principalName ATTRIBUTE ::= {		GeneralName ::= CHOICE {
	WITH SYNTAX PrintableString(SIZE(1..ub-prinicipalName))		otherName [0] KDCPrincipalName,
	EQUALITY MATCHING RULE caseExactMatch		...
	ORDERING MATCHING RULE caseExactOrderingMatch
	SINGLE VALUE TRUE
	ID id-at-principalName
	}		}
	ub-principalName INTEGER ::= 1024		KDCPrincipalNameTypes OTHER-NAME ::= {
			{ PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst }
			}
	id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4}		KDCPrincipalName ::= SEQUENCE {
			nameType OTHER-NAME.&id ( { KDCPrincipalNameTypes } ),
			name OTHER-NAME.&type ( { KDCPrincipalNameTypes }
			{ @nameType } )
			}
	id-at-principalName OBJECT IDENTIFIER ::= {id-at 60}		PrincipalNameSrvInst ::= GeneralString
	where ATTRIBUTE is as defined in X.501, and the matching rules are		where (from the Kerberos specification) we have
	as defined in X.520.
	[Still need to register principalName.]		krb5 OBJECT IDENTIFIER ::= { iso (1)
			org (3)
			dod (6)
			internet (1)
			security (5)
			kerberosv5 (2) }
	[Still need to discuss what is done for a PGP certificate.]		principalName OBJECT IDENTIFIER ::= { krb5 2 }
			principalNameSrvInst OBJECT IDENTIFIER ::= { principalName 2 }
	The client then extracts the random key used to encrypt the main		The client then extracts the random key used to encrypt the main
	reply. This random key (in encPaReply) is encrypted with either the		reply. This random key (in encPaReply) is encrypted with either the
	client's public key or with a key derived from the DH values		client's public key or with a key derived from the DH values
	exchanged between the client and the KDC.		exchanged between the client and the KDC.
	3.2.1. Additional Information for Errors		3.2.1. Additional Information for Errors
	This section describes the interpretation of the method-type and		This section describes the interpretation of the method-type and
	method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error.		method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error.
	skipping to change at line 557 ¶		skipping to change at line 601 ¶
	encoding of the integer index of the certificate in question:		encoding of the integer index of the certificate in question:
	CertificateIndex ::= INTEGER		CertificateIndex ::= INTEGER
	-- 0 = 1st certificate,		-- 0 = 1st certificate,
	-- 1 = 2nd certificate, etc		-- 1 = 2nd certificate, etc
	If method-type=4, the KDC name or realm in the PKAuthenticator does		If method-type=4, the KDC name or realm in the PKAuthenticator does
	not match the principal name of the KDC. There is no method-data		not match the principal name of the KDC. There is no method-data
	field in this case.		field in this case.
			If method-type=5, the client name or realm in the certificate does
			not match the principal name of the client. There is no
			method-data field in this case.
	3.3. Digital Signature		3.3. Digital Signature
	Implementation of the changes in this section are OPTIONAL for		Implementation of the changes in this section are OPTIONAL for
	compliance with PKINIT.		compliance with PKINIT.
	We offer this option with the warning that it requires the client to		We offer this option with the warning that it requires the client to
	generate a random key; the client may not be able to guarantee the		generate a random key; the client may not be able to guarantee the
	same level of randomness as the KDC.		same level of randomness as the KDC.
	If the user registered, or presents a certificate for, a digital		If the user registered, or presents a certificate for, a digital
	skipping to change at line 758 ¶		skipping to change at line 806 ¶
	Otherwise, if the first flag is clear, but the second flag is set,		Otherwise, if the first flag is clear, but the second flag is set,
	then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED		then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
	indicating that a preauthentication field of type PA-PK-AS-SIGN must		indicating that a preauthentication field of type PA-PK-AS-SIGN must
	be included in the request.		be included in the request.
	Lastly, if the first two flags are clear, but the third flag is set,		Lastly, if the first two flags are clear, but the third flag is set,
	then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED		then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
	indicating that a preauthentication field of type PA-PK-KEY-REQ must		indicating that a preauthentication field of type PA-PK-KEY-REQ must
	be included in the request.		be included in the request.
	5. Dependence on Transport Mechanisms		5. Transport Issues
	Certificate chains can potentially grow quite large and span several		Certificate chains can potentially grow quite large and span several
	UDP packets; this in turn increases the probability that a Kerberos		UDP packets; this in turn increases the probability that a Kerberos
	message involving PKINIT extensions will be broken in transit. In		message involving PKINIT extensions will be broken in transit. In
	light of the possibility that the Kerberos specification will		light of the possibility that the Kerberos specification will
	allow TCP as a transport mechanism, we solicit discussion on whether		require KDCs to accept requests using TCP as a transport mechanism,
	using PKINIT should encourage the use of TCP.		we make the same recommendation with respect to the PKINIT
			extensions as well.
	6. Bibliography		6. Bibliography
	[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.
	skipping to change at line 821 ¶		skipping to change at line 870 ¶
	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.
	8. Expiration Date		8. Expiration Date
	This draft expires January 31, 1997.		This draft expires May 26, 1998.
	9. Authors		9. 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
End of changes. 36 change blocks.
	65 lines changed or deleted		114 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/