Diff: draft-ietf-cat-kerberos-pk-init-06.txt - draft-ietf-cat-kerberos-pk-init-07.txt

	< draft-ietf-cat-kerberos-pk-init-06.txt	draft-ietf-cat-kerberos-pk-init-07.txt >

	INTERNET-DRAFT Brian Tung	INTERNET-DRAFT Brian Tung

	draft-ietf-cat-kerberos-pk-init-06.txt Clifford Neuman	draft-ietf-cat-kerberos-pk-init-07.txt Clifford Neuman
	Updates: RFC 1510 ISI	Updates: RFC 1510 ISI

	expires September 15, 1998 John Wray	expires May 15, 1999 John Wray
	Digital Equipment Corporation	Digital Equipment Corporation
	Ari Medvinsky	Ari Medvinsky
	Matthew Hur	Matthew Hur

		Sasha Medvinsky
	CyberSafe Corporation	CyberSafe Corporation
	Jonathan Trostle	Jonathan Trostle

	Novell	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. Internet-Drafts are working	This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its	documents of the Internet Engineering Task Force (IETF), its
	areas, and its working groups. Note that other groups may also	areas, and its working groups. Note that other groups may also
	distribute working documents as Internet-Drafts.	distribute working documents as Internet-Drafts.

	Internet-Drafts are draft documents valid for a maximum of six	Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other	months and may be updated, replaced, or obsoleted by other
	documents at any time. It is inappropriate to use Internet-Drafts	documents at any time. It is inappropriate to use Internet-Drafts
	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 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-05.txt, and expires September 15,	draft-ietf-cat-kerberos-pk-init-07.txt, and expires May 15, 1999.
	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 83 ¶	skipping to change at line 84 ¶
	long-term key (which is derived from a password). This	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 as a building block for
		other specifications. PKCROSS [3] utilizes PKINIT for establishing
		the inter-realm key and associated inter-realm policy to be applied
		in issuing cross realm service tickets. As specified in [4], anonymous
		Kerberos tickets can be issued by applying a NULL signature in
		combination with Diffie-Hellman in the PKINIT exchange. Additionally,
		The PKINIT specification may be used for direct peer to peer
	authentication without contacting a central KDC. This application	authentication without contacting a central KDC. This application

	of PKINIT is described in PKTAPP [4] and is based on concepts	of PKINIT is described in PKTAPP [5] and is based on concepts
	introduced in [5, 6]. For direct client-to-server authentication,	introduced in [6, 7]. For direct client-to-server authentication,
	the client uses PKINIT to authenticate to the end server (instead	the client uses PKINIT to authenticate to the end server (instead
	of a central KDC), which then issues a ticket for itself. This	of a central KDC), which then issues a ticket for itself. This

	approach has an advantage over SSL [7] in that the server does not	approach has an advantage over SSL [8] in that the server does not
	need to save state (cache session keys). Furthermore, an	need to save state (cache session keys). Furthermore, an
	additional benefit is that Kerberos tickets can facilitate	additional benefit is that Kerberos tickets can facilitate

	delegation (see [8]).	delegation (see [9]).

	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

	skipping to change at line 125 ¶	skipping to change at line 132 ¶
	conventional cryptography.	conventional cryptography.

	Section 3.1 provides definitions to help specify message formats.	Section 3.1 provides definitions to help specify message formats.
	Section 3.2 and 3.3 describe the extensions for the two initial	Section 3.2 and 3.3 describe the extensions for the two initial
	authentication methods. Section 3.4 describes a way for the user to	authentication methods. Section 3.4 describes a way for the user to
	store and retrieve his private key on the KDC, as an adjunct to the	store and retrieve his private key on the KDC, as an adjunct to the
	initial authentication.	initial authentication.

	3.1. Definitions	3.1. Definitions


	The extensions involve new encryption methods; we propose the
	addition of the following types:

	dsa-sign 8
	rsa-priv 9
	rsa-pub 10
	rsa-pub-md5 11
	rsa-pub-sha1 12

	The proposal of these encryption types notwithstanding, we do not
	mandate the use of any particular public key encryption method.

	The extensions involve new preauthentication fields; we propose the	The extensions involve new preauthentication fields; we propose the
	addition of the following types:	addition of the following types:

	PA-PK-AS-REQ 14	PA-PK-AS-REQ 14
	PA-PK-AS-REP 15	PA-PK-AS-REP 15
	PA-PK-AS-SIGN 16	PA-PK-AS-SIGN 16
	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	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-RFC2253. The full realm name will appear as follows:


	X500-RFC1779:RFC1779Encode(DistinguishedName)	X500-RFC2253:RFC2253Encode(DistinguishedName)


	where DistinguishedName is an X.500 name, and RFC1779Encode is a	where DistinguishedName is an X.500 name, and RFC2253Encode is a
	readable ASCII encoding of an X.500 name, as defined by RFC 1779.	readable ASCII encoding of an X.500 name, as defined by
	To ensure that this encoding is unique, we add the following rules	RFC 2253 [14] (part of LDAPv3). (RFC 2253 obsoleted RFC 1779, which
	to those specified by RFC 1779:	is not supported by this version of PKINIT.)


	* The optional spaces specified in RFC 1779 are not allowed.	To ensure that this encoding is unique, we add the following rule
	* The character that separates relative distinguished names	to those specified by RFC 2253:
	must be ',' (i.e., it must never be ';').
	* Attribute values must not be enclosed in double quotes.	The order in which the attributes appear in the RFC 2253
	* Attribute values must not be specified as hexadecimal	encoding must be the reverse of the order in the ASN.1
	numbers.	encoding of the X.500 name that appears in the public key
	* When an attribute name is specified in the form of an OID,	certificate. The order of the relative distinguished names
	it must start with the 'OID.' prefix, and not the 'oid.'	(RDNs), as well as the order of the AttributeTypeAndValues
	prefix.	within each RDN, will be reversed. (This is despite the fact
	* The order in which the attributes appear in the RFC 1779	that an RDN is defined as a SET of AttributeTypeAndValues, where
	encoding must be the reverse of the order in the ASN.1	an order is normally not important.)
	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. This new name type is defined	shall be set to NT-X500-PRINCIPAL. This new name type is defined
	as:	as:

	#define CSFC5c_NT_X500_PRINCIPAL 6	#define CSFC5c_NT_X500_PRINCIPAL 6

	The name-string shall be set as follows:	The name-string shall be set as follows:


	RFC1779Encode(DistinguishedName)	RFC2253Encode(DistinguishedName)

	as described above.	as described above.

	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

	skipping to change at line 240 ¶	skipping to change at line 215 ¶
	Diffie-Hellman agreement. In the case of Diffie-Hellman, the key	Diffie-Hellman agreement. In the case of Diffie-Hellman, the key
	shall be produced from the agreed bit string as follows:	shall be produced from the agreed bit string as follows:

	* Truncate the bit string to the appropriate length.	* Truncate the bit string to the appropriate length.
	* Rectify parity in each byte (if necessary) to obtain the key.	* Rectify parity in each byte (if necessary) to obtain the key.

	For instance, in the case of a DES key, we take the first eight	For instance, in the case of a DES key, we take the first eight
	bytes of the bit stream, and then adjust the least significant bit	bytes of the bit stream, and then adjust the least significant bit
	of each byte to ensure that each byte has odd parity.	of each byte to ensure that each byte has odd parity.


	RFC 1510, Section 6.1, defines EncryptedData as follows:	3.1.2. Algorithm Identifiers


	EncryptedData ::= SEQUENCE {	PKINIT does not define, but does permit, the algorithm identifiers
	etype [0] INTEGER,	listed below.
	kvno [1] INTEGER OPTIONAL,
	cipher [2] OCTET STRING	3.1.2.1. Signature Algorithm Identifiers
	-- is CipherText
		These are the algorithm identifiers for use in the Signature data
		structure:

		sha-1WithRSAEncryption ALGORITHM PARAMETER NULL
		::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
		pkcs-1(1) 5 }

		dsaWithSHA1 ALGORITHM PARAMETER NULL
		::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3)
		oIWSecAlgorithm(2) dsaWithSHA1(27) }

		md4WithRsaEncryption ALGORITHM PARAMETER NULL
		::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3)
		oIWSecAlgorithm(2) md4WithRSAEncryption(4) }

		md5WithRSAEncryption ALGORITHM PARAMETER NULL
		::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
		pkcs-1(1) md5WithRSAEncryption(4) }

		3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier

		This algorithm identifier is used inside the SubjectPublicKeyInfo
		data structure:

		dhKeyAgreement ALGORITHM PARAMETER DHParameters
		::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
		pkcs-3(3) dhKeyAgreement(1) }

		DHParameters ::= SEQUENCE {
		prime INTEGER,
		-- p
		base INTEGER,
		-- g
		privateValueLength INTEGER OPTIONAL
		} -- as specified by the X.509 recommendation [9]

		3.1.2.3. Algorithm Identifiers for RSA Encryption

		These algorithm identifiers are used inside the EnvelopedData data
		structure, for encrypting the temporary key with a public key:

		rsaEncryption ALGORITHM PARAMETER NULL
		::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
		pkcs-1(1) rsaEncryption(1)

		3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys

		These algorithm identifiers are used inside the EnvelopedData data
		structure, for encrypting the temporary key with a Diffie-Hellman-
		derived key, or for encrypting the reply key:

		desCBC ALGORITHM PARAMETER IV8
		::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3)
		oIWSecAlgorithm(2) desCBC(7) }

		DES-EDE3-CBC ALGORITHM PARAMETER IV8
		::= { iso(1) member-body(2) US(840) rsadsi(113549)
		encryptionAlgorithm(3) desEDE3(7) }

		IV8 ::= OCTET STRING (SIZE(8)) -- initialization vector

		rc2CBC ALGORITHM PARAMETER RC2-CBCParameter
		::= { iso(1) member-body(2) US(840) rsadsi(113549)
		encryptionAlgorithm(3) rc2CBC(2) }

		The rc2CBC algorithm parameters (RC2-CBCParameter) are defined
		in the following section.

		rc4 ALGORITHM PARAMETER NULL
		::= { iso(1) member-body(2) US(840) rsadsi(113549)
		encryptionAlgorithm(3) rc4(4) }

		The rc4 algorithm cannot be used with the Diffie-Hellman-derived
		keys, because its parameters do not specify the size of the key.

		3.1.2.5. rc2CBC Algorithm Parameters

		This definition of the RC2 parameters is taken from a paper by
		Ron Rivest [13]. Refer to [13] for the complete description of the
		RC2 algorithm.

		RC2-CBCParameter ::= CHOICE {
		iv IV,
		params SEQUENCE {
		version RC2Version,
		iv IV
	}	}

		}


	RFC 1510 also defines how CipherText is to be composed. It is not	where
	an ASN.1 data structure, but rather an octet string which is the
	encryption of a plaintext string. This plaintext string is in turn
	a concatenation of the following octet strings: a confounder, a
	checksum, the message, and padding. Details of how these components
	are arranged can be found in RFC 1510.


	The PKINIT protocol introduces several new types of encryption.	IV ::= OCTET STRING -- 8 octets
	Data that is encrypted with a public key will allow only the check	RC2Version ::= INTEGER -- 1-1024
	optional field, as it is defined above. This type of the checksum
	will be specified in the etype field, together with the encryption
	type.


	In order to identify the checksum type, etype will have the	RC2 in CBC mode has two parameters: an 8-byte initialization
	following values:	vector (IV) and a version number in the range 1-1024 which
		specifies in a roundabout manner the number of effective key bits
		to be used for the RC2 encryption/decryption.


	rsa-pub-MD5	The correspondence between effective key bits and version number
	rsa-pub-SHA1	is as follows:


	In the case that etype is set to rsa-pub, the optional 'check'	1. If the number EKB of effective key bits is in the range 1-255,
	field will not be provided.	then the version number is given by Table[EKB], where the
		256-byte translation table is specified below. It specifies a
		permutation on the numbers 0-255.


	Data that is encrypted with a private key will not use any optional	2. If the number EKB of effective key bits is in the range
	fields. PKINIT uses private key encryption only for signatures,	256-1024, then the version number is simply EKB.
	which are encrypted checksums. Therefore, the optional check field
	is not needed.	The default number of effective key bits for RC2 is 32.
		If RC2-CBC is being performed with 32 effective key bits, the
		parameters should be supplied as a simple IV, rather than as a
		SEQUENCE containing a version and an IV.

		0 1 2 3 4 5 6 7 8 9 a b c d e f

		00: bd 56 ea f2 a2 f1 ac 2a b0 93 d1 9c 1b 33 fd d0
		10: 30 04 b6 dc 7d df 32 4b f7 cb 45 9b 31 bb 21 5a
		20: 41 9f e1 d9 4a 4d 9e da a0 68 2c c3 27 5f 80 36
		30: 3e ee fb 95 1a fe ce a8 34 a9 13 f0 a6 3f d8 0c
		40: 78 24 af 23 52 c1 67 17 f5 66 90 e7 e8 07 b8 60
		50: 48 e6 1e 53 f3 92 a4 72 8c 08 15 6e 86 00 84 fa
		60: f4 7f 8a 42 19 f6 db cd 14 8d 50 12 ba 3c 06 4e
		70: ec b3 35 11 a1 88 8e 2b 94 99 b7 71 74 d3 e4 bf
		80: 3a de 96 0e bc 0a ed 77 fc 37 6b 03 79 89 62 c6
		90: d7 c0 d2 7c 6a 8b 22 a3 5b 05 5d 02 75 d5 61 e3
		a0: 18 8f 55 51 ad 1f 0b 5e 85 e5 c2 57 63 ca 3d 6c
		b0: b4 c5 cc 70 b2 91 59 0d 47 20 c8 4f 58 e0 01 e2
		c0: 16 38 c4 6f 3b 0f 65 46 be 7e 2d 7b 82 f9 40 b5
		d0: 1d 73 f8 eb 26 c7 87 97 25 54 b1 28 aa 98 9d a5
		e0: 64 6d 7a d4 10 81 44 ef 49 d6 ae 2e dd 76 5c 2f
		f0: a7 1c c9 09 69 9a 83 cf 29 39 b9 e9 4c ff 43 ab

	3.2. Standard Public Key Authentication	3.2. Standard Public Key Authentication

	Implementation of the changes in this section is REQUIRED for	Implementation of the changes in this section is REQUIRED for
	compliance with PKINIT.	compliance with PKINIT.

	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;
		-- if present, the KDC must use
		-- the public key from this
		-- particular certificate chain to
		-- verify the signature in the
		-- request
	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	serialNumber [3] CertificateSerialNumber OPTIONAL

	-- specifying a particular	-- specifying a particular KDC
	-- certificate if the client	-- certificate if the client
	-- already has it;	-- already has it;
	-- must be accompanied by	-- must be accompanied by
	-- a single trustedCertifier	-- a single trustedCertifier
	}	}

	CertificateSerialNumber ::= INTEGER	CertificateSerialNumber ::= INTEGER

	-- as specified by PKCS 6	-- as specified by PKCS #6 [15]

	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,

	skipping to change at line 339 ¶	skipping to change at line 424 ¶
	pkcsSignature [1] BIT STRING	pkcsSignature [1] BIT STRING
	-- octet-aligned big-endian bit	-- octet-aligned big-endian bit
	-- string (encrypted with signer's	-- string (encrypted with signer's
	-- private key)	-- private key)
	}	}

	SignatureAlgorithmIdentifier ::= AlgorithmIdentifier	SignatureAlgorithmIdentifier ::= AlgorithmIdentifier

	AlgorithmIdentifier ::= SEQUENCE {	AlgorithmIdentifier ::= SEQUENCE {
	algorithm ALGORITHM.&id,	algorithm ALGORITHM.&id,

	-- for DH, equals
	-- dhKeyAgreement
	-- ({iso(1) member-body(2) US(840)
	-- rsadsi(113549) pkcs(1) pkcs-3(3)
	-- 1})
	parameters ALGORITHM.&type	parameters ALGORITHM.&type

	-- for DH, is DHParameter	} -- as specified by the X.509 recommendation [10]
	} -- as specified by the X.509 recommendation [9]

	SubjectPublicKeyInfo ::= SEQUENCE {	SubjectPublicKeyInfo ::= SEQUENCE {
	algorithm AlgorithmIdentifier,	algorithm AlgorithmIdentifier,

		-- dhKeyAgreement
	subjectPublicKey BIT STRING	subjectPublicKey BIT STRING
	-- for DH, equals	-- for DH, equals
	-- public exponent (INTEGER encoded	-- public exponent (INTEGER encoded
	-- as payload of BIT STRING)	-- as payload of BIT STRING)
	} -- as specified by the X.509 recommendation [9]	} -- as specified by the X.509 recommendation [9]


	DHParameter ::= SEQUENCE {
	prime INTEGER,
	-- p
	base INTEGER,
	-- g
	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)

		-- 3 = PKIX (per PKCS #6 [15])
	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,	If the client passes a certificate serial number in the request,
	the KDC is requested to use the referred-to certificate. If none	the KDC is requested to use the referred-to certificate. If none
	exists, then the KDC returns an error of type	exists, then the KDC returns an error of type
	KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the	KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the
	other hand, the client does not pass any trustedCertifiers,	other hand, the client does not pass any trustedCertifiers,
	believing that it has the KDC's certificate, but the KDC has more	believing that it has the KDC's certificate, but the KDC has more
	than one certificate.	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
	of two ways:

	* The Kerberos principal name krbtgt/<realm_name>@<realm_name>,
	where <realm_name> is replaced by the applicable realm name.
	* The name in the KDC's certificate (e.g., an X.500 name, or a
	PGP name).

	Note that the first case requires that the certificate name and the
	Kerberos principal name be bound together (e.g., via an X.509v3
	extension).

	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. If the KDC has no	not possess the KDC's public key certificate. If the KDC has no

	skipping to change at line 468 ¶	skipping to change at line 529 ¶
	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
	within the allowable window. If the local (server) time and the	within the allowable window. If the local (server) time and the
	client time in the authenticator differ by more than the allowable	client time in the authenticator differ by more than the allowable
	clock skew, then the KDC returns an error message of type	clock skew, then the KDC returns an error message of type
	KRB_AP_ERR_SKEW.	KRB_AP_ERR_SKEW.

	Assuming no errors, the KDC replies as per RFC 1510, except as	Assuming no errors, the KDC replies as per RFC 1510, except as

	follows: The user's name in the ticket is as represented in the	follows. The user's name in the ticket is determined by the
	certificate, unless a Kerberos principal name is bound to the name	following decision algorithm:
	in the certificate (e.g., via an X.509v3 extension). The user's
	realm in the ticket shall be the name of the Certification	1. If the KDC has a mapping from the name in the certificate
	Authority that issued the user's public key certificate.	to a Kerberos name, then use that name. Else
		2. If the certificate contains a Kerberos name in an extension
		field, and local KDC policy allows, then use that name.
		Else
		3. Use the name as represented in the certificate, mapping
		as necessary (e.g., as per RFC 2253 for X.500 names). In
		this case the realm in the ticket shall be the name of the
		certification authority that issued the user's certificate.

	The KDC encrypts the reply not with the user's long-term key, but	The KDC encrypts the reply not with the user's long-term key, but
	with a random key generated only for this particular response. This	with a random key generated only for this particular response. This
	random key is sealed in the preauthentication field:	random key is sealed in the preauthentication field:

	PA-PK-AS-REP ::= SEQUENCE {	PA-PK-AS-REP ::= SEQUENCE {
	-- PA TYPE 15	-- PA TYPE 15

	encSignedReplyKeyPack [0] EncryptedData,	encKeyPack [1] EnvelopedKeyPack,
	-- of type SignedReplyKeyPack	-- temporary key is encrypted
	-- using the temporary key
	-- in encTmpKey
	encTmpKeyPack [1] EncryptedData,
	-- of type TmpKeyPack
	-- using either the client public	-- using either the client public
	-- key or the Diffie-Hellman key	-- key or the Diffie-Hellman key

	-- specified by SignedDHPublicValue	-- specified by SignedKDCPublicValue.
	signedKDCPublicValue [2] SignedKDCPublicValue OPTIONAL	-- SignedReplyKeyPack, encrypted
		-- with the temporary key, is also
		-- included.
		signedKDCPublicValue [2] SignedKDCPublicValue OPTIONAL,
	-- if one was passed in the request	-- if one was passed in the request

	kdcCert [3] SEQUENCE OF Certificate OPTIONAL,	kdcCert [3] SEQUENCE OF Certificate OPTIONAL
	-- the KDC's certificate chain	-- the KDC's certificate chain
	}	}


		The EnvelopedKeyPack data type below contains an encrypted
		temporary key (either with the PKINIT client's public key or with a
		symmetric key, resulting from the Diffie-Hellman exchange). It also
		contains a signed and encrypted reply key. This data structure is
		similar to EnvelopedData, defined in CMS [11] and PKCS #7 [12].

		EnvelopedKeyPack ::= SEQUENCE {
		version Version,
		-- Always set to 0.
		recipientInfos RecipientInfos,
		-- This is a SET, which must contain
		-- exactly one member. Contains a
		-- temporary key, encrypted with the
		-- client's public key. This
		-- temporary key is used to encrypt
		-- the reply key.
		encryptedContentInfo EncryptedContentInfo
		-- contains the signed and encrypted
		-- reply key
		}

		Version ::= INTEGER

		RecipientInfos ::= SET OF RecipientInfo

		RecipientInfo ::= SEQUENCE {
		version Version,
		-- shall be 0
		rid RecipientIdentifier,
		-- Since this is an optional field,
		-- it supports both CMS and PKCS #7
		keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
		EncryptedKey OCTET STRING
		-- the temporary key, encrypted with
		-- the PKINIT client's public key
		}

		KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

		RecipientIdentifier ::= IssuerAndSerialNumber
		-- Corresponds to the X.509 V3 extension
		-- SubjectKeyIdentifier.

		IssuerAndSerialNumber ::= SEQUENCE {
		issuer Name,
		-- a distinguished name, as defined
		-- by X.509
		serialNumber CertificateSerialNumber
		}

		CertificateSerialNumber ::= INTEGER

		EncryptedContentInfo ::= SEQUENCE {
		contentType ContentType,
		-- shall be:
		-- iso(1) member-body(2) us(840)
		-- rsadsi(113549) pkcs(1) pkcs7(7)
		-- EnvelopedData(3)
		contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier
		-- Algorithm used to encrypt the
		-- SignedReplyKeyPack.
		encryptedContent OCTET STRING
		-- The encrypted data is of the type
		-- SignedReplyKeyPack.
		}

		ContentType ::= OBJECT IDENTIFIER

		ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

	SignedReplyKeyPack ::= SEQUENCE {	SignedReplyKeyPack ::= SEQUENCE {
	replyKeyPack [0] ReplyKeyPack,	replyKeyPack [0] ReplyKeyPack,
	replyKeyPackSig [1] Signature,	replyKeyPackSig [1] Signature,

	-- of replyEncKeyPack	-- of replyKeyPack
	-- 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	-- 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 {
	tmpKey [0] EncryptionKey,
	-- used to encrypt the
	-- 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
	}	}

	The kdcCert field is a sequence of certificates, the first of which	The kdcCert field is a sequence of certificates, the first of which
	must be the KDC's public key certificate. Any subsequent	must be the KDC's public key certificate. Any subsequent

	skipping to change at line 544 ¶	skipping to change at line 674 ¶
	list of trusted certifiers (the trustedCertifiers field was empty).	list of trusted certifiers (the trustedCertifiers field was empty).

	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. X.509 certificates shall
	this is done as follows. The name of the KDC will be represented	contain the principal name of the KDC as the SubjectAltName version
	as an OtherName, encoded as a GeneralString:	3 extension. Below is the definition of this version 3 extension, as
		specified by the X.509 standard:


	GeneralName ::= CHOICE {	subjectAltName EXTENSION ::= {
	otherName [0] KDCPrincipalName,	SYNTAX GeneralNames
	...	IDENTIFIED BY id-ce-subjectAltName
	}	}


	KDCPrincipalNameTypes OTHER-NAME ::= {	GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
	{ PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst }
	}


	KDCPrincipalName ::= SEQUENCE {	GeneralName ::= CHOICE {
	nameType [0] OTHER-NAME.&id ( { KDCPrincipalNameTypes } ),	otherName [0] INSTANCE OF OTHER-NAME,
	name [1] OTHER-NAME.&type ( { KDCPrincipalNameTypes }	...
		}

		OTHER-NAME ::= TYPE-IDENTIFIER

		In this definition, otherName is a name of any form defined as an
		instance of the OTHER-NAME information object class. For the purpose
		of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will
		be replaced by the type KerberosPrincipalName:

		KerberosPrincipalName ::= SEQUENCE {
		nameType [0] OTHER-NAME.&id ( { PrincipalNameTypes } ),
		name [1] OTHER-NAME.&type ( { PrincipalNameTypes }
	{ @nameType } )	{ @nameType } )
	}	}


		PrincipalNameTypes OTHER-NAME ::= {
		{ PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst }
		}

	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)
	internet (1)	internet (1)
	security (5)	security (5)
	kerberosv5 (2) }	kerberosv5 (2) }

	principalName OBJECT IDENTIFIER ::= { krb5 2 }	principalName OBJECT IDENTIFIER ::= { krb5 2 }

	principalNameSrvInst OBJECT IDENTIFIER ::= { principalName 2 }	principalNameSrvInst OBJECT IDENTIFIER ::= { principalName 2 }


		(This specification can also be used to specify a Kerberos name
		within the user's certificate.)

	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 620 ¶	skipping to change at line 768 ¶
	-- 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	If method-type=5, the client name or realm in the certificate does
	not match the principal name of the client. There is no	not match the principal name of the client. There is no
	method-data field in this case.	method-data field in this case.


		3.2.2. Required Algorithms and Data Formats

		Not all of the algorithms in the PKINIT protocol specification have
		to be implemented in order to comply with the proposed standard.
		Below is a list of the required algorithms and data formats:

		- Diffie-Hellman public/private key pairs
		- SHA1 digest and DSA for signatures
		- X.509 version 3 certificates
		- 3-key triple DES keys derived from the Diffie-Hellman Exchange
		- 3-key triple DES Temporary and Reply keys

	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
	signature key with the KDC instead of an encryption key, then a	signature key with the KDC instead of an encryption key, then a
	separate exchange must be used. The client sends a request for a	separate exchange must be used. The client sends a request for a
	TGT as usual, except that it (rather than the KDC) generates the	TGT as usual, except that it (rather than the KDC) generates the
	random key that will be used to encrypt the KDC response. This key	random key that will be used to encrypt the KDC response. This key
	is sent to the KDC along with the request in a preauthentication	is sent to the KDC along with the request in a preauthentication
	field, encrypted with the KDC's public key:	field, encrypted with the KDC's public key:

	PA-PK-AS-SIGN ::= SEQUENCE {	PA-PK-AS-SIGN ::= SEQUENCE {
	-- PA TYPE 16	-- PA TYPE 16

	encSignedRandomKeyPack [0] EncryptedData,	encKeyPack [1] EnvelopedKeyPack,
	-- of type SignedRandomKeyPack	-- temporary key is encrypted
	-- using the key in encTmpKeyPack	-- using the KDC public
	encTmpKeyPack [1] EncryptedData,	-- key.
	-- of type TmpKeyPack	-- SignedRandomKeyPack, encrypted
	-- using the KDC's public key	-- with the temporary key, is also
		-- included.
	userCert [2] SEQUENCE OF Certificate OPTIONAL	userCert [2] SEQUENCE OF Certificate OPTIONAL

	-- the user's certificate chain	-- the user's certificate chain;
		-- if present, the KDC must use
		-- the public key from this
		-- particular certificate chain to
		-- verify the signature in the
		-- request
	}	}


		In the above message, the content of the encKeyPack is similar to
		the content of the encKeyPack field in the PA-PK-AS-REP message,
		except that it is the KDC's public key and not the client's public
		key that is used to encrypt the temporary key. And, the
		encryptedContentInfo field inside the EnvelopedKeyPack contains
		encrypted data of the type SignedRandomKeyPack instead of the
		SignedReplyKeyPack.

	SignedRandomKeyPack ::= SEQUENCE {	SignedRandomKeyPack ::= SEQUENCE {
	randomkeyPack [0] RandomKeyPack,	randomkeyPack [0] RandomKeyPack,
	randomkeyPackSig [1] Signature	randomkeyPackSig [1] Signature
	-- of keyPack	-- of keyPack
	-- using user's private key	-- using user's private key
	}	}

	RandomKeyPack ::= SEQUENCE {	RandomKeyPack ::= SEQUENCE {
	randomKey [0] EncryptionKey,	randomKey [0] EncryptionKey,
	-- will be used to encrypt reply	-- will be used to encrypt reply
	randomKeyAuth [1] PKAuthenticator	randomKeyAuth [1] PKAuthenticator

	-- nonce copied from AS-REQ
	}	}

	If the KDC does not accept client-generated random keys as a matter	If the KDC does not accept client-generated random keys as a matter
	of policy, then it sends back an error message of type	of policy, then it sends back an error message of type
	KDC_ERR_KEY_TOO_WEAK. Otherwise, it extracts the random key as	KDC_ERR_KEY_TOO_WEAK. Otherwise, it extracts the random key as
	follows.	follows.

	Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies	Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies
	the randomKey. It then replies as per RFC 1510, except that the	the randomKey. It then replies as per RFC 1510, except that the
	reply is encrypted not with a password-derived user key, but with	reply is encrypted not with a password-derived user key, but with
	the randomKey sent in the request. Since the client already knows	the randomKey sent in the request. Since the client already knows
	this key, there is no need to accompany the reply with an extra	this key, there is no need to accompany the reply with an extra
	preauthentication field. The transited field of the ticket should	preauthentication field. The transited field of the ticket should
	specify the certification path as described in Section 3.2.	specify the certification path as described in Section 3.2.

	3.4. Retrieving the User's Private Key from the KDC	3.4. Retrieving the User's Private Key from the KDC

	Implementation of the changes described in this section are OPTIONAL	Implementation of the changes described in this section are OPTIONAL

	for compliance with PKINIT.	for compliance with PKINIT. (This section may or may not fall under
		the purview of a patent for private key storage; please see Section
		8 for more information.)

	When the user's private key is not stored local to the user, he may	When the user's private key is not stored local to the user, he may
	choose to store the private key (normally encrypted using a	choose to store the private key (normally encrypted using a
	password-derived key) on the KDC. In this case, the client makes a	password-derived key) on the KDC. In this case, the client makes a
	request as described above, except that instead of preauthenticating	request as described above, except that instead of preauthenticating
	with his private key, he uses a symmetric key shared with the KDC.	with his private key, he uses a symmetric key shared with the KDC.

	For simplicity's sake, this shared key is derived from the password-	For simplicity's sake, this shared key is derived from the password-
	derived key used to encrypt the private key, in such a way that the	derived key used to encrypt the private key, in such a way that the
	KDC can authenticate the user with the shared key without being able	KDC can authenticate the user with the shared key without being able

	skipping to change at line 848 ¶	skipping to change at line 1023 ¶

	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.


		Lastly, PKINIT calls for randomly generated keys for conventional
		cryptosystems. Many such systems contain systematically "weak"
		keys. PKINIT implementations MUST avoid use of these keys, either
		by discarding those keys when they are generated, or by fixing them
		in some way (e.g., by XORing them with a given mask). These
		precautions vary from system to system; it is not our intention to
		give an explicit recipe for them here.

	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.

	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.


	[3] A. Medvinsky, M. Hur. Addition of Kerberos Cipher Suites to	[3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld,
	Transport Layer Security (TLS).	A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm
	draft-ietf-tls-kerb-cipher-suites-00.txt	Authentication in Kerberos.
		draft-ietf-cat-kerberos-pk-cross-04.txt


	[4] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing	[4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in
		Kerberos.
		draft-ietf-cat-kerberos-anoncred-00.txt

		[5] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing
	Tickets for Application Servers (PKTAPP).	Tickets for Application Servers (PKTAPP).
	draft-ietf-cat-pktapp-00.txt	draft-ietf-cat-pktapp-00.txt


	[5] 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.


	[6] 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.


	[7] Alan O. Freier, Philip Karlton and Paul C. Kocher. The SSL	[8] Alan O. Freier, Philip Karlton and Paul C. Kocher. The SSL
	Protocol, Version 3.0 - IETF Draft.	Protocol, Version 3.0 - IETF Draft.


	[8] B.C. Neuman, Proxy-Based Authorization and Accounting for	[9] B.C. Neuman, Proxy-Based Authorization and Accounting for
	Distributed Systems. In Proceedings of the 13th International	Distributed Systems. In Proceedings of the 13th International
	Conference on Distributed Computing Systems, May 1993.	Conference on Distributed Computing Systems, May 1993.


	[9] ITU-T (formerly CCITT) Information technology - Open Systems	[10] ITU-T (formerly CCITT) Information technology - Open Systems
	Interconnection - The Directory: Authentication Framework	Interconnection - The Directory: Authentication Framework
	Recommendation X.509 ISO/IEC 9594-8	Recommendation X.509 ISO/IEC 9594-8


	7. Acknowledgements	[11] R. Hously. Cryptographic Message Syntax.
		draft-ietf-smime-cms-04.txt, March 1998.


	Sasha Medvinsky contributed several ideas to the protocol changes	[12] PKCS #7: Cryptographic Message Syntax Standard,
	and specifications in this document. His additions have been most	An RSA Laboratories Technical Note Version 1.5
	appreciated.	Revised November 1, 1993

		[13] Ron Rivest, MIT Laboratory for Computer Science and
		RSA Data Security, Inc. A Description of the RC2(r) Encryption
		Algorithm, November 1997.

		[14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
		Protocol (v3): UTF-8 String Representation of Distinguished Names.
		Request for Comments 2253.

		[15] PKCS #6: Cryptographic Message Syntax Standard,
		An RSA Laboratories Technical Note Version 1.5
		Revised November 1, 1993

		7. Patent Issues

		The private key storage and retrieval process described in Section
		3.4 may be covered by U.S. Patent 5,418,854 (Charles Kaufman, Morrie
		Gasser, Butler Lampson, Joseph Tardo, Kannan Alagappan, all then of
		Digital Corporation). At this time, inquiries into this patent are
		inconclusive. We solicit discussion from any party who can illuminate
		the coverage of this particular patent.

		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.


	8. Expiration Date	9. Expiration Date


	This draft expires September 15, 1998.	This draft expires May 15, 1999.


	9. 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

	John Wray	John Wray
	Digital Equipment Corporation	Digital Equipment Corporation
	550 King Street, LKG2-2/Z7	550 King Street, LKG2-2/Z7
	Littleton, MA 01460	Littleton, MA 01460
	Phone: +1 508 486 5210	Phone: +1 508 486 5210
	E-mail: wray@tuxedo.enet.dec.com	E-mail: wray@tuxedo.enet.dec.com

	Ari Medvinsky	Ari Medvinsky
	Matthew Hur	Matthew Hur

		Sasha Medvinsky
	CyberSafe Corporation	CyberSafe Corporation
	1605 NW Sammamish Road Suite 310	1605 NW Sammamish Road Suite 310
	Issaquah WA 98027-5378	Issaquah WA 98027-5378
	Phone: +1 206 391 6000	Phone: +1 206 391 6000

	E-mail: {ari.medvinsky, matt.hur}@cybersafe.com	E-mail: {ari.medvinsky, matt.hur, sasha.medvinsky}@cybersafe.com

	Jonathan Trostle	Jonathan Trostle

	Novell Corporation	170 W. Tasman Dr.
	Provo UT	San Jose, CA 95134
	E-mail: jtrostle@novell.com	E-mail: jtrostle@cisco.com

End of changes. 70 change blocks.
	179 lines changed or deleted	392 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/