< draft-ietf-cat-kerberos-pk-init-05.txt		draft-ietf-cat-kerberos-pk-init-06.txt >
	INTERNET-DRAFT Brian Tung		INTERNET-DRAFT Brian Tung
	draft-ietf-cat-kerberos-pk-init-05.txt Clifford Neuman		draft-ietf-cat-kerberos-pk-init-06.txt Clifford Neuman
	Updates: RFC 1510 ISI		Updates: RFC 1510 ISI
	expires May 26, 1998 John Wray		expires September 15, 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 35 ¶		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-05.txt, and expires May 26, 1998.		draft-ietf-cat-kerberos-pk-init-05.txt, and expires September 15,
	Please send comments to the authors.		1998. 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 155 ¶		skipping to change at line 155 ¶
	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		KDC_ERR_CERTIFICATE_MISMATCH 66
			In addition, PKINIT does not define, but does permit, the following
			algorithm identifiers for use with the Signature data structure:
			md4WithRSAEncryption (as defined in PKCS 1)
			md5WithRSAEncryption (as defined in PKCS 1)
			sha-1WithRSAEncryption ::= { iso(1) member-body(2) us(840)
			rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
			dsaWithSHA1 ::= { OIW oIWSecSig(3) oIWSecAlgorithm(2)
			dsaWithSHA1(27) }
			where
			OIW ::= iso(1) identifiedOrganization(3) oIW(14)
	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-RFC1779. The full realm name will appear as follows:		X500-RFC1779. The full realm name will appear as follows:
	X500-RFC1779:RFC1779Encode(DistinguishedName)		X500-RFC1779:RFC1779Encode(DistinguishedName)
	skipping to change at line 313 ¶		skipping to change at line 328 ¶
	kdcName [0] PrincipalName,		kdcName [0] PrincipalName,
	kdcRealm [1] Realm,		kdcRealm [1] Realm,
	cusec [2] INTEGER,		cusec [2] INTEGER,
	-- for replay prevention		-- for replay prevention
	ctime [3] KerberosTime,		ctime [3] KerberosTime,
	-- for replay prevention		-- for replay prevention
	nonce [4] INTEGER		nonce [4] INTEGER
	}		}
	Signature ::= SEQUENCE {		Signature ::= SEQUENCE {
	signedHash [0] EncryptedData		signatureAlgorithm [0] SignatureAlgorithmIdentifier,
	-- of type Checksum		pkcsSignature [1] BIT STRING
			-- octet-aligned big-endian bit
			-- string (encrypted with signer's
			-- private key)
	}		}
	Checksum ::= SEQUENCE {		SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
	cksumtype [0] INTEGER,
	checksum [1] OCTET STRING
	} -- as specified by RFC 1510
	SubjectPublicKeyInfo ::= SEQUENCE {
	algorithm [0] AlgorithmIdentifier,
	subjectPublicKey [1] BIT STRING
	-- for DH, equals
	-- public exponent (INTEGER encoded
	-- as payload of BIT STRING)
	} -- as specified by the X.509 recommendation [9]
	AlgorithmIdentifier ::= SEQUENCE {		AlgorithmIdentifier ::= SEQUENCE {
	algorithm [0] ALGORITHM.&id,		algorithm ALGORITHM.&id,
	-- for DH, equals		-- for DH, equals
	-- dhKeyAgreement		-- dhKeyAgreement
	-- ({iso(1) member-body(2) US(840)		-- ({iso(1) member-body(2) US(840)
	-- rsadsi(113549) pkcs(1) pkcs-3(3)		-- rsadsi(113549) pkcs(1) pkcs-3(3)
	-- 1})		-- 1})
	parameters [1] ALGORITHM.&type		parameters ALGORITHM.&type
	-- for DH, is DHParameter		-- for DH, is DHParameter
	} -- as specified by the X.509 recommendation [9]		} -- as specified by the X.509 recommendation [9]
			SubjectPublicKeyInfo ::= SEQUENCE {
			algorithm AlgorithmIdentifier,
			subjectPublicKey BIT STRING
			-- for DH, equals
			-- public exponent (INTEGER encoded
			-- as payload of BIT STRING)
			} -- as specified by the X.509 recommendation [9]
	DHParameter ::= SEQUENCE {		DHParameter ::= SEQUENCE {
	prime [0] INTEGER,		prime INTEGER,
	-- p		-- p
	base [1] INTEGER,		base INTEGER,
	-- g		-- g
	privateValueLength [2] INTEGER OPTIONAL		privateValueLength INTEGER OPTIONAL
	}		} -- as specified by the X.509 recommendation [9]
	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
	}		}
	skipping to change at line 543 ¶		skipping to change at line 558 ¶
	GeneralName ::= CHOICE {		GeneralName ::= CHOICE {
	otherName [0] KDCPrincipalName,		otherName [0] KDCPrincipalName,
	...		...
	}		}
	KDCPrincipalNameTypes OTHER-NAME ::= {		KDCPrincipalNameTypes OTHER-NAME ::= {
	{ PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst }		{ PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst }
	}		}
	KDCPrincipalName ::= SEQUENCE {		KDCPrincipalName ::= SEQUENCE {
	nameType OTHER-NAME.&id ( { KDCPrincipalNameTypes } ),		nameType [0] OTHER-NAME.&id ( { KDCPrincipalNameTypes } ),
	name OTHER-NAME.&type ( { KDCPrincipalNameTypes }		name [1] OTHER-NAME.&type ( { KDCPrincipalNameTypes }
	{ @nameType } )		{ @nameType } )
	}		}
	PrincipalNameSrvInst ::= GeneralString		PrincipalNameSrvInst ::= GeneralString
	where (from the Kerberos specification) we have		where (from the Kerberos specification) we have
	krb5 OBJECT IDENTIFIER ::= { iso (1)		krb5 OBJECT IDENTIFIER ::= { iso (1)
	org (3)		org (3)
	dod (6)		dod (6)
	skipping to change at line 714 ¶		skipping to change at line 729 ¶
	trustedCertifiers [1] SEQUENCE OF PrincipalName OPTIONAL,		trustedCertifiers [1] SEQUENCE OF PrincipalName OPTIONAL,
	-- CAs that the client trusts		-- CAs that the client trusts
	keyIDList [2] SEQUENCE OF Checksum OPTIONAL		keyIDList [2] SEQUENCE OF Checksum OPTIONAL
	-- payload is hash of public key		-- payload is hash of public key
	-- corresponding to desired		-- corresponding to desired
	-- private key		-- private key
	-- if absent, KDC will return all		-- if absent, KDC will return all
	-- stored private keys		-- stored private keys
	}		}
			Checksum ::= SEQUENCE {
			cksumtype [0] INTEGER,
			checksum [1] OCTET STRING
			} -- as specified by RFC 1510
	SignedPKAuth ::= SEQUENCE {		SignedPKAuth ::= SEQUENCE {
	pkAuth [0] PKAuthenticator,		pkAuth [0] PKAuthenticator,
	pkAuthSig [1] Signature		pkAuthSig [1] Signature
	-- of pkAuth		-- of pkAuth
	-- using the symmetric key K2		-- using the symmetric key K2
	}		}
	If a keyIDList is present, the first identifier should indicate		If a keyIDList is present, the first identifier should indicate
	the primary private key. No public key certificate is required,		the primary private key. No public key certificate is required,
	since the KDC stores the public key along with the private key.		since the KDC stores the public key along with the private key.
	skipping to change at line 806 ¶		skipping to change at line 826 ¶
	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. Security Considerations
			PKINIT raises a few security considerations, which we will address
			in this section.
			First of all, PKINIT introduces a new trust model, where KDCs do not
			(necessarily) certify the identity of those for whom they issue
			tickets. PKINIT does allow KDCs to act as their own CAs, in order
			to simplify key management, but one of the additional benefits is to
			align Kerberos authentication with a global public key
			infrastructure. Anyone using PKINIT in this way must be aware of
			how the certification infrastructure they are linking to works.
			Secondly, PKINIT also introduces the possibility of interactions
			between different cryptosystems, which may be of widely varying
			strengths. Many systems, for instance, allow the use of 512-bit
			public keys. Using such keys to wrap data encrypted under strong
			conventional cryptosystems, such as triple-DES, is inappropriate;
			it adds a weak link to a strong one at extra cost. Implementors
			and administrators should take care to avoid such wasteful and
			deceptive interactions.
	5. Transport Issues		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
	require KDCs to accept requests using TCP as a transport mechanism,		require KDCs to accept requests using TCP as a transport mechanism,
	we make the same recommendation with respect to the PKINIT		we make the same recommendation with respect to the PKINIT
	extensions as well.		extensions as well.
	skipping to change at line 870 ¶		skipping to change at line 912 ¶
	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 May 26, 1998.		This draft expires September 15, 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. 16 change blocks.
	27 lines changed or deleted		68 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/