< draft-ietf-cat-kerberos-pk-init-27.txt   draft-ietf-cat-kerberos-pk-init-28.txt >
NETWORK WORKING GROUP B. Tung NETWORK WORKING GROUP B. Tung
Internet-Draft USC Information Sciences Institute Internet-Draft USC Information Sciences Institute
Expires: January 20, 2006 L. Zhu Expires: March 16, 2006 L. Zhu
Microsoft Corporation Microsoft Corporation
July 19, 2005 September 12, 2005
Public Key Cryptography for Initial Authentication in Kerberos Public Key Cryptography for Initial Authentication in Kerberos
draft-ietf-cat-kerberos-pk-init-27 draft-ietf-cat-kerberos-pk-init-28
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 20, 2006. This Internet-Draft will expire on March 16, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes protocol extensions (hereafter called PKINIT) This document describes protocol extensions (hereafter called PKINIT)
to the Kerberos protocol specification. These extensions provide a to the Kerberos protocol specification. These extensions provide a
method for integrating public key cryptography into the initial method for integrating public key cryptography into the initial
authentication exchange, by using asymmetric-key signature and/or authentication exchange, by using asymmetric-key signature and/or
encryption algorithms in pre-authentication data fields. encryption algorithms in pre-authentication data fields.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Definitions, Requirements, and Constants . . . . . . . . . 4 3.1. Definitions, Requirements, and Constants . . . . . . . . . 4
3.1.1 Required Algorithms . . . . . . . . . . . . . . . . . 4 3.1.1. Required Algorithms . . . . . . . . . . . . . . . . . 4
3.1.2 Defined Message and Encryption Types . . . . . . . . . 5 3.1.2. Defined Message and Encryption Types . . . . . . . . . 5
3.1.3 Algorithm Identifiers . . . . . . . . . . . . . . . . 6 3.1.3. Algorithm Identifiers . . . . . . . . . . . . . . . . 6
3.2 PKINIT Pre-authentication Syntax and Use . . . . . . . . . 7 3.2. PKINIT Pre-authentication Syntax and Use . . . . . . . . . 7
3.2.1 Generation of Client Request . . . . . . . . . . . . . 7 3.2.1. Generation of Client Request . . . . . . . . . . . . . 7
3.2.2 Receipt of Client Request . . . . . . . . . . . . . . 10 3.2.2. Receipt of Client Request . . . . . . . . . . . . . . 10
3.2.3 Generation of KDC Reply . . . . . . . . . . . . . . . 14 3.2.3. Generation of KDC Reply . . . . . . . . . . . . . . . 14
3.2.4 Receipt of KDC Reply . . . . . . . . . . . . . . . . . 19 3.2.4. Receipt of KDC Reply . . . . . . . . . . . . . . . . . 19
3.3 Interoperability Requirements . . . . . . . . . . . . . . 20 3.3. Interoperability Requirements . . . . . . . . . . . . . . 20
3.4 KDC Indication of PKINIT Support . . . . . . . . . . . . . 21 3.4. KDC Indication of PKINIT Support . . . . . . . . . . . . . 21
4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1 Normative References . . . . . . . . . . . . . . . . . . . 23 7.1. Normative References . . . . . . . . . . . . . . . . . . . 24
7.2 Informative References . . . . . . . . . . . . . . . . . . 24 7.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 25
A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 25 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 34
1. Introduction 1. Introduction
A client typically authenticates itself to a service in Kerberos A client typically authenticates itself to a service in Kerberos
using three distinct though related exchanges. First, the client using three distinct though related exchanges. First, the client
requests a ticket-granting ticket (TGT) from the Kerberos requests a ticket-granting ticket (TGT) from the Kerberos
authentication server (AS). Then, it uses the TGT to request a authentication server (AS). Then, it uses the TGT to request a
service ticket from the Kerberos ticket-granting server (TGS). service ticket from the Kerberos ticket-granting server (TGS).
Usually, the AS and TGS are integrated in a single device known as a Usually, the AS and TGS are integrated in a single device known as a
Kerberos Key Distribution Center, or KDC. Finally, the client uses Kerberos Key Distribution Center, or KDC. Finally, the client uses
skipping to change at page 4, line 42 skipping to change at page 4, line 43
encryption key for decrypting the KDC reply is returned in a pre- encryption key for decrypting the KDC reply is returned in a pre-
authentication field accompanying the usual reply. authentication field accompanying the usual reply.
4. The client validates the KDC's signature, obtains the encryption 4. The client validates the KDC's signature, obtains the encryption
key, decrypts the reply, and then proceeds as usual. key, decrypts the reply, and then proceeds as usual.
Section 3.1 of this document enumerates the required algorithms and Section 3.1 of this document enumerates the required algorithms and
necessary extension message types. Section 3.2 describes the necessary extension message types. Section 3.2 describes the
extension messages in greater detail. extension messages in greater detail.
3.1 Definitions, Requirements, and Constants 3.1. Definitions, Requirements, and Constants
3.1.1 Required Algorithms 3.1.1. Required Algorithms
All PKINIT implementations MUST support the following algorithms: All PKINIT implementations MUST support the following algorithms:
o AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac- o AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-
sha1-96 [RFC3962]. sha1-96 [RFC3962].
o Signature algorithm: sha-1WithRSAEncryption [RFC3279]. o Signature algorithm: sha-1WithRSAEncryption [RFC3279].
o AS reply key delivery method: Diffie-Hellman key exchange o AS reply key delivery method: Diffie-Hellman key exchange
[RFC2631]. [RFC2631].
3.1.2 Defined Message and Encryption Types In addition, implementations of this specification MUST be capable of
processing the Extended Key Usage (EKU) extension and the id-pksan
(as defined in Section 3.2.2) otherName of the Subject Alternative
Name (SAN) extension in X.509 certificates [RFC3280], if present.
3.1.2. Defined Message and Encryption Types
PKINIT makes use of the following new pre-authentication types: PKINIT makes use of the following new pre-authentication types:
PA_PK_AS_REQ 16 PA_PK_AS_REQ 16
PA_PK_AS_REP 17 PA_PK_AS_REP 17
PKINIT also makes use of the following new authorization data type: PKINIT also makes use of the following new authorization data type:
AD_INITIAL_VERIFIED_CAS 9 AD_INITIAL_VERIFIED_CAS 9
skipping to change at page 6, line 21 skipping to change at page 6, line 29
otherwise noted). All data structures carried in OCTET STRINGs must otherwise noted). All data structures carried in OCTET STRINGs must
be encoded according to the rules specified in corresponding be encoded according to the rules specified in corresponding
specifications. specifications.
Interoperability note: Some implementations may not be able to decode Interoperability note: Some implementations may not be able to decode
wrapped CMS objects encoded with BER but not DER; specifically, they wrapped CMS objects encoded with BER but not DER; specifically, they
may not be able to decode infinite length encodings. To maximize may not be able to decode infinite length encodings. To maximize
interoperability, implementers SHOULD encode CMS objects used in interoperability, implementers SHOULD encode CMS objects used in
PKINIT with DER. PKINIT with DER.
3.1.3 Algorithm Identifiers 3.1.3. Algorithm Identifiers
PKINIT does not define, but does make use of, the following algorithm PKINIT does not define, but does make use of, the following algorithm
identifiers. identifiers.
PKINIT uses the following algorithm identifier(s) for Diffie-Hellman PKINIT uses the following algorithm identifier(s) for Diffie-Hellman
key agreement [RFC3279]: key agreement [RFC3279]:
dhpublicnumber (Modular Exponential Diffie-Hellman [RFC2631]) dhpublicnumber (Modular Exponential Diffie-Hellman [RFC2631])
PKINIT uses the following signature algorithm identifiers [RFC3279]: PKINIT uses the following signature algorithm identifiers [RFC3279]:
skipping to change at page 7, line 5 skipping to change at page 7, line 9
rsaEncryption (PKCS1 v1.5) rsaEncryption (PKCS1 v1.5)
id-RSAES-OAEP (PKCS1 v2.0) id-RSAES-OAEP (PKCS1 v2.0)
PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565] PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565]
for encrypting the AS reply key with the temporary key: for encrypting the AS reply key with the temporary key:
des-ede3-cbc (three-key 3DES, CBC mode) des-ede3-cbc (three-key 3DES, CBC mode)
rc2-cbc (RC2, CBC mode) rc2-cbc (RC2, CBC mode)
id-aes256-CBC (AES-256, CBC mode) id-aes256-CBC (AES-256, CBC mode)
3.2 PKINIT Pre-authentication Syntax and Use 3.2. PKINIT Pre-authentication Syntax and Use
This section defines the syntax and use of the various pre- This section defines the syntax and use of the various pre-
authentication fields employed by PKINIT. authentication fields employed by PKINIT.
3.2.1 Generation of Client Request 3.2.1. Generation of Client Request
The initial authentication request (AS-REQ) is sent as per [RFC4120]; The initial authentication request (AS-REQ) is sent as per [RFC4120];
in addition, a pre-authentication data element, whose padata-type is in addition, a pre-authentication data element, whose padata-type is
PA_PK_AS_REQ and whose padata-value contains the DER encoding of the PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
type PA-PK-AS-REQ, is included. type PA-PK-AS-REQ, is included.
PA-PK-AS-REQ ::= SEQUENCE { PA-PK-AS-REQ ::= SEQUENCE {
signedAuthPack [0] IMPLICIT OCTET STRING, signedAuthPack [0] IMPLICIT OCTET STRING,
-- Contains a CMS type ContentInfo encoded -- Contains a CMS type ContentInfo encoded
-- according to [RFC3852]. -- according to [RFC3852].
skipping to change at page 8, line 37 skipping to change at page 8, line 40
} }
AuthPack ::= SEQUENCE { AuthPack ::= SEQUENCE {
pkAuthenticator [0] PKAuthenticator, pkAuthenticator [0] PKAuthenticator,
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
-- Type SubjectPublicKeyInfo is defined in -- Type SubjectPublicKeyInfo is defined in
-- [RFC3280]. -- [RFC3280].
-- Specifies Diffie-Hellman domain parameters -- Specifies Diffie-Hellman domain parameters
-- and the client's public key value [IEEE1363]. -- and the client's public key value [IEEE1363].
-- The DH public key value is encoded as a BIT -- The DH public key value is encoded as a BIT
-- STRING, as specified in Section 2.3.3 of -- STRING according to [RFC3279].
-- [RFC3279].
-- This field is present only if the client wishes -- This field is present only if the client wishes
-- to use the Diffie-Hellman key agreement method. -- to use the Diffie-Hellman key agreement method.
supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
OPTIONAL, OPTIONAL,
-- Type AlgorithmIdentifier is defined in -- Type AlgorithmIdentifier is defined in
-- [RFC3280]. -- [RFC3280].
-- List of CMS encryption types supported by the -- List of CMS encryption types supported by the
-- client in order of (decreasing) preference. -- client in order of (decreasing) preference.
clientDHNonce [3] DHNonce OPTIONAL, clientDHNonce [3] DHNonce OPTIONAL,
-- Present only if the client indicates that it -- Present only if the client indicates that it
skipping to change at page 10, line 25 skipping to change at page 10, line 27
When MODP Diffie-Hellman is used, the exponents should have at When MODP Diffie-Hellman is used, the exponents should have at
least twice as many bits as the symmetric keys that will be least twice as many bits as the symmetric keys that will be
derived from them [ODL99]. derived from them [ODL99].
7. The client may wish to reuse DH keys or to allow the KDC to do so 7. The client may wish to reuse DH keys or to allow the KDC to do so
(see Section 3.2.3.1). If so, then the client includes the (see Section 3.2.3.1). If so, then the client includes the
clientDHNonce field. This nonce string needs to be as long as clientDHNonce field. This nonce string needs to be as long as
the longest key length of the symmetric key types that the client the longest key length of the symmetric key types that the client
supports. This nonce MUST be chosen randomly. supports. This nonce MUST be chosen randomly.
3.2.2 Receipt of Client Request 3.2.2. Receipt of Client Request
Upon receiving the client's request, the KDC validates it. This Upon receiving the client's request, the KDC validates it. This
section describes the steps that the KDC MUST (unless otherwise section describes the steps that the KDC MUST (unless otherwise
noted) take in validating the request. noted) take in validating the request.
The KDC verifies the client's signature in the signedAuthPack field The KDC verifies the client's signature in the signedAuthPack field
according to [RFC3852]. according to [RFC3852].
If, while validating the client's X.509 certificate [RFC3280], the If, while validating the client's X.509 certificate [RFC3280], the
KDC cannot build a certification path to validate the client's KDC cannot build a certification path to validate the client's
skipping to change at page 14, line 5 skipping to change at page 14, line 5
If the client included a kdcPkId field in the PA-PK-AS-REQ and the If the client included a kdcPkId field in the PA-PK-AS-REQ and the
KDC does not possess the corresponding key, the KDC MUST ignore the KDC does not possess the corresponding key, the KDC MUST ignore the
kdcPkId field as if the client did not include one. kdcPkId field as if the client did not include one.
If there is a supportedCMSTypes field in the AuthPack, the KDC must If there is a supportedCMSTypes field in the AuthPack, the KDC must
check to see if it supports any of the listed types. If it supports check to see if it supports any of the listed types. If it supports
more than one of the types, the KDC SHOULD use the one listed first. more than one of the types, the KDC SHOULD use the one listed first.
If it does not support any of them, it MUST return an error message If it does not support any of them, it MUST return an error message
with the code KDC_ERR_ETYPE_NOSUPP [RFC4120]. with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
3.2.3 Generation of KDC Reply 3.2.3. Generation of KDC Reply
Assuming that the client's request has been properly validated, the Assuming that the client's request has been properly validated, the
KDC proceeds as per [RFC4120], except as follows. KDC proceeds as per [RFC4120], except as follows.
The KDC MUST set the initial flag and include an authorization data The KDC MUST set the initial flag and include an authorization data
element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
ticket. The ad-data [RFC4120] field contains the DER encoding of the ticket. The ad-data [RFC4120] field contains the DER encoding of the
type AD-INITIAL-VERIFIED-CAS: type AD-INITIAL-VERIFIED-CAS:
AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
skipping to change at page 15, line 42 skipping to change at page 15, line 42
-- KDCDHKeyInfo is defined below. -- KDCDHKeyInfo is defined below.
serverDHNonce [1] DHNonce OPTIONAL serverDHNonce [1] DHNonce OPTIONAL
-- Present if and only if dhKeyExpiration is -- Present if and only if dhKeyExpiration is
-- present in the KDCDHKeyInfo. -- present in the KDCDHKeyInfo.
} }
KDCDHKeyInfo ::= SEQUENCE { KDCDHKeyInfo ::= SEQUENCE {
subjectPublicKey [0] BIT STRING, subjectPublicKey [0] BIT STRING,
-- KDC's DH public key. -- KDC's DH public key.
-- The DH public key value is encoded as a BIT -- The DH public key value is encoded as a BIT
-- STRING, as specified in Section 2.3.3 of -- STRING according to [RFC3279].
-- [RFC3279].
nonce [1] INTEGER (0..4294967295), nonce [1] INTEGER (0..4294967295),
-- Contains the nonce in the PKAuthenticator of the -- Contains the nonce in the PKAuthenticator of the
-- request if DH keys are NOT reused, -- request if DH keys are NOT reused,
-- 0 otherwise. -- 0 otherwise.
dhKeyExpiration [2] KerberosTime OPTIONAL, dhKeyExpiration [2] KerberosTime OPTIONAL,
-- Expiration time for KDC's key pair, -- Expiration time for KDC's key pair,
-- present if and only if DH keys are reused. If -- present if and only if DH keys are reused. If
-- this field is omitted then the serverDHNonce -- this field is omitted then the serverDHNonce
-- field MUST also be omitted. See Section 3.2.3.1. -- field MUST also be omitted. See Section 3.2.3.1.
... ...
} }
3.2.3.1 Using Diffie-Hellman Key Exchange 3.2.3.1. Using Diffie-Hellman Key Exchange
In this case, the PA-PK-AS-REP contains a DHRepInfo structure. In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
The ContentInfo [RFC3852] structure for the dhSignedData field is The ContentInfo [RFC3852] structure for the dhSignedData field is
filled in as follows: filled in as follows:
1. The contentType field of the type ContentInfo is id-signedData 1. The contentType field of the type ContentInfo is id-signedData
(as defined in [RFC3852]), and the content field is a SignedData (as defined in [RFC3852]), and the content field is a SignedData
(as defined in [RFC3852]). (as defined in [RFC3852]).
skipping to change at page 18, line 13 skipping to change at page 18, line 9
kcrypto profile [RFC3961] for the enctype of the AS reply key. kcrypto profile [RFC3961] for the enctype of the AS reply key.
4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be 4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
the serverDHNonce; otherwise, let both n_c and n_k be empty octet the serverDHNonce; otherwise, let both n_c and n_k be empty octet
strings. strings.
5. The AS reply key k is: 5. The AS reply key k is:
k = octetstring2key(DHSharedSecret | n_c | n_k) k = octetstring2key(DHSharedSecret | n_c | n_k)
3.2.3.2 Using Public Key Encryption 3.2.3.2. Using Public Key Encryption
In this case, the PA-PK-AS-REP contains a ContentInfo structure In this case, the PA-PK-AS-REP contains a ContentInfo structure
wrapped in an OCTET STRING. The AS reply key is encrypted in the wrapped in an OCTET STRING. The AS reply key is encrypted in the
encKeyPack field, which contains data of type ReplyKeyPack: encKeyPack field, which contains data of type ReplyKeyPack:
ReplyKeyPack ::= SEQUENCE { ReplyKeyPack ::= SEQUENCE {
replyKey [0] EncryptionKey, replyKey [0] EncryptionKey,
-- Contains the session key used to encrypt the -- Contains the session key used to encrypt the
-- enc-part field in the AS-REP. -- enc-part field in the AS-REP.
asChecksum [1] Checksum, asChecksum [1] Checksum,
skipping to change at page 19, line 38 skipping to change at page 19, line 35
MUST contain exactly one member of type KeyTransRecipientInfo. MUST contain exactly one member of type KeyTransRecipientInfo.
The encryptedKey of this member contains the temporary key which The encryptedKey of this member contains the temporary key which
is encrypted using the client's public key. is encrypted using the client's public key.
8. The unprotectedAttrs or originatorInfo fields of the type 8. The unprotectedAttrs or originatorInfo fields of the type
EnvelopedData MAY be present. EnvelopedData MAY be present.
Implementations of this RSA encryption key delivery method are Implementations of this RSA encryption key delivery method are
RECOMMENDED to support for RSA keys at least 2048 bits in size. RECOMMENDED to support for RSA keys at least 2048 bits in size.
3.2.4 Receipt of KDC Reply 3.2.4. Receipt of KDC Reply
Upon receipt of the KDC's reply, the client proceeds as follows. If Upon receipt of the KDC's reply, the client proceeds as follows. If
the PA-PK-AS-REP contains the dhSignedData field, the client derives the PA-PK-AS-REP contains the dhSignedData field, the client derives
the AS reply key using the same procedure used by the KDC as defined the AS reply key using the same procedure used by the KDC as defined
in Section 3.2.3.1. Otherwise, the message contains the encKeyPack in Section 3.2.3.1. Otherwise, the message contains the encKeyPack
field, and the client decrypts and extracts the temporary key in the field, and the client decrypts and extracts the temporary key in the
encryptedKey field of the member KeyTransRecipientInfo, and then uses encryptedKey field of the member KeyTransRecipientInfo, and then uses
that as the AS reply key. that as the AS reply key.
If the public key encrytion method is used, the client MUST verify
the asChecksum contained in the ReplyKeyPack.
In either case, the client MUST verify the signature in the In either case, the client MUST verify the signature in the
SignedData according to [RFC3852]. The KDC's X.509 certificate MUST SignedData according to [RFC3852]. The KDC's X.509 certificate MUST
be validated according to [RFC3280]. In addition, unless the client be validated according to [RFC3280]. In addition, unless the client
can otherwise verify that the public key used to verify the KDC's can otherwise verify that the public key used to verify the KDC's
signature is bound to the KDC of the target realm, the KDC's X.509 signature is bound to the KDC of the target realm, the KDC's X.509
certificate MUST contain a Subject Alternative Name extension certificate MUST contain a Subject Alternative Name extension
[RFC3280] carrying an AnotherName whose type-id is id-pksan (as [RFC3280] carrying an AnotherName whose type-id is id-pksan (as
defined in Section 3.2.2) and whose value is a KRB5PrincipalName that defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
matches the name of the TGS of the target realm (as defined in matches the name of the TGS of the target realm (as defined in
Section 7.3 of [RFC4120]). Section 7.3 of [RFC4120]).
Based on local policy, the client MAY require that the KDC Unless the client knows by some other means that the KDC certificate
is intended for a Kerberos KDC, the client MUST require that the KDC
certificate contains the EKU KeyPurposeId [RFC3280] id-pkkdcekuoid: certificate contains the EKU KeyPurposeId [RFC3280] id-pkkdcekuoid:
id-pkkdcekuoid OBJECT IDENTIFIER ::= id-pkkdcekuoid OBJECT IDENTIFIER ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
pkinit(3) pkkdcekuoid(5) } pkinit(3) pkkdcekuoid(5) }
-- Signing KDC responses. -- Signing KDC responses.
-- Key usage bits that MUST be consistent: -- Key usage bits that MUST be consistent:
-- digitalSignature. -- digitalSignature.
If the KDC certificate contains the Kerberos TGS name encoded as an
id-pksan SAN, this certificate is certified by the issuing CA as a
KDC certificate, therefore the id-pkkdcekuoid EKU is not required.
If all applicable checks are satisfied, the client then decrypts the If all applicable checks are satisfied, the client then decrypts the
enc-part field of the KDC-REP in the AS-REP using the AS reply key, enc-part field of the KDC-REP in the AS-REP using the AS reply key,
and then proceeds as described in [RFC4120]. and then proceeds as described in [RFC4120].
Implementation note: CAs issuing KDC certificates SHOULD place all Implementation note: CAs issuing KDC certificates SHOULD place all
"short" and "fully-qualified" Kerberos realm names of the KDC (one "short" and "fully-qualified" Kerberos realm names of the KDC (one
per GeneralName [RFC3280]) into the KDC certificate to allow maximum per GeneralName [RFC3280]) into the KDC certificate to allow maximum
flexibility. flexibility.
3.3 Interoperability Requirements 3.3. Interoperability Requirements
The client MUST be capable of sending a set of certificates The client MUST be capable of sending a set of certificates
sufficient to allow the KDC to construct a certification path for the sufficient to allow the KDC to construct a certification path for the
client's certificate, if the correct set of certificates is provided client's certificate, if the correct set of certificates is provided
through configuration or policy. through configuration or policy.
If the client sends all the X.509 certificates on a certification If the client sends all the X.509 certificates on a certification
path to a trust anchor acceptable by the KDC, and the KDC can not path to a trust anchor acceptable by the KDC, and the KDC can not
verify the client's public key otherwise, the KDC MUST be able to verify the client's public key otherwise, the KDC MUST be able to
process path validation for the client's certificate based on the process path validation for the client's certificate based on the
skipping to change at page 21, line 5 skipping to change at page 21, line 11
to allow the client to construct a certification path for the KDC's to allow the client to construct a certification path for the KDC's
certificate, if the correct set of certificates is provided through certificate, if the correct set of certificates is provided through
configuration or policy. configuration or policy.
If the KDC sends all the X.509 certificates on a certification path If the KDC sends all the X.509 certificates on a certification path
to a trust anchor acceptable by the client, and the client can not to a trust anchor acceptable by the client, and the client can not
verify the KDC's public key otherwise, the client MUST be able to verify the KDC's public key otherwise, the client MUST be able to
process path validation for the KDC's certificate based on the process path validation for the KDC's certificate based on the
certificates in the reply. certificates in the reply.
3.4 KDC Indication of PKINIT Support 3.4. KDC Indication of PKINIT Support
If pre-authentication is required, but was not present in the If pre-authentication is required, but was not present in the
request, per [RFC4120] an error message with the code request, per [RFC4120] an error message with the code
KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
stored in the e-data field of the KRB-ERROR message to specify which stored in the e-data field of the KRB-ERROR message to specify which
pre-authentication mechanisms are acceptable. The KDC can then pre-authentication mechanisms are acceptable. The KDC can then
indicate the support of PKINIT by including an empty element whose indicate the support of PKINIT by including an empty element whose
padata-type is PA_PK_AS_REQ in that METHOD-DATA object. padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
Otherwise if it is required by the KDC's local policy that the client Otherwise if it is required by the KDC's local policy that the client
skipping to change at page 21, line 46 skipping to change at page 22, line 5
PKINIT raises certain security considerations beyond those that can PKINIT raises certain security considerations beyond those that can
be regulated strictly in protocol definitions. We will address them be regulated strictly in protocol definitions. We will address them
in this section. in this section.
PKINIT extends the cross-realm model to the public-key PKINIT extends the cross-realm model to the public-key
infrastructure. Users of PKINIT must understand security policies infrastructure. Users of PKINIT must understand security policies
and procedures appropriate to the use of Public Key Infrastructures and procedures appropriate to the use of Public Key Infrastructures
[RFC3280]. [RFC3280].
In order to trust a KDC certificate that is certified by a CA as a
KDC certificate for a target realm (for example, by asserting the TGS
name of that Kerberos realm as an id-pksan SAN and/or restricting the
certificate usage by using the id-pkkdcekuoid EKU, as described in
Section 3.2.4), the client MUST verify that the KDC certificate's
issuing CA is authorized to issue KDC certificates for that target
realm. Otherwise, the binding between the KDC certificate and the
KDC of the target realm is not established.
How to validate this authorization is a matter of local policy. A
way to achieve this is the configuration of specific sets of
intermediary CAs and trust anchors, one of which must be on the KDC
certificate's certification path [RFC3280]; and for each CA or trust
anchor the realms for which it is allowed to issue certificates.
In addition, if any CA is trusted to issue KDC certificates can also
issue other kinds of certificates, then local policy must be able to
distinguish between them: for example, it could require that KDC
certificates contain the id-pkkdcekuoid EKU or that the realm be
specified with the id-pksan SAN.
It is the responsibility of the PKI administrators for an
organization to ensure that KDC certificates are only issued to KDCs,
and that clients can ascertain this using their local policy.
Standard Kerberos allows the possibility of interactions between Standard Kerberos allows the possibility of interactions between
cryptosystems of varying strengths; this document adds interactions cryptosystems of varying strengths; this document adds interactions
with public-key cryptosystems to Kerberos. Some administrative with public-key cryptosystems to Kerberos. Some administrative
policies may allow the use of relatively weak public keys. Using policies may allow the use of relatively weak public keys. Using
such keys to wrap data encrypted under stronger conventional such keys to wrap data encrypted under stronger conventional
cryptosystems may be inappropriate. cryptosystems may be inappropriate.
PKINIT requires keys for symmetric cryptosystems to be generated. PKINIT requires keys for symmetric cryptosystems to be generated.
Some such systems contain "weak" keys. For recommendations regarding Some such systems contain "weak" keys. For recommendations regarding
these weak keys, see [RFC4120]. these weak keys, see [RFC4120].
skipping to change at page 22, line 41 skipping to change at page 23, line 24
The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
permit empty SEQUENCEs to be encoded. Such empty sequences may only permit empty SEQUENCEs to be encoded. Such empty sequences may only
be used if the KDC itself vouches for the user's certificate. be used if the KDC itself vouches for the user's certificate.
5. Acknowledgements 5. Acknowledgements
The following people have made significant contributions to this The following people have made significant contributions to this
draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist
Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle, Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle,
Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik
Jaganathan, Chaskiel M Grundman and Stefan Santesson. Jaganathan, Chaskiel M Grundman, Stefan Santesson, Andre Scedrov and
Aaron D. Jaggard.
Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
Jonathan Trostle who wrote earlier versions of this document. Jonathan Trostle who wrote earlier versions of this document.
The authors are indebted to the Kerberos working group chair Jeffrey The authors are indebted to the Kerberos working group chair Jeffrey
Hutzelman who kept track of various issues and was enormously helpful Hutzelman who kept track of various issues and was enormously helpful
during the creation of this document. during the creation of this document.
Some of the ideas on which this document is based arose during Some of the ideas on which this document is based arose during
discussions over several years between members of the SAAG, the IETF discussions over several years between members of the SAAG, the IETF
skipping to change at page 23, line 19 skipping to change at page 24, line 7
Lastly, comments from groups working on similar ideas in DCE have Lastly, comments from groups working on similar ideas in DCE have
been invaluable. been invaluable.
6. IANA Considerations 6. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
7. References 7. References
7.1 Normative References 7.1. Normative References
[IEEE1363] [IEEE1363]
IEEE, "Standard Specifications for Public Key IEEE, "Standard Specifications for Public Key
Cryptography", IEEE 1363, 2000. Cryptography", IEEE 1363, 2000.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
RFC 2412, November 1998. RFC 2412, November 1998.
skipping to change at page 24, line 42 skipping to change at page 25, line 29
[X.509-97] ITU-T. Recommendation X.509: The Directory - Authentication [X.509-97] ITU-T. Recommendation X.509: The Directory - Authentication
Framework. 1997. Framework. 1997.
[X690] ASN.1 encoding rules: Specification of Basic Encoding [X690] ASN.1 encoding rules: Specification of Basic Encoding
Rules (BER), Canonical Encoding Rules (CER) and Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER), ITU-T Recommendation Distinguished Encoding Rules (DER), ITU-T Recommendation
X.690 (1997) | ISO/IEC International Standard X.690 (1997) | ISO/IEC International Standard
8825-1:1998. 8825-1:1998.
7.2 Informative References 7.2. Informative References
[CAPATH] RFC-Editor: To be replaced by RFC number for draft-ietf- [CAPATH] RFC-Editor: To be replaced by RFC number for draft-ietf-
pkix-certpathbuild. Work in Progress. pkix-certpathbuild. Work in Progress.
[LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key [LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
Sizes", Journal of Cryptology 14 (2001) 255-293. Sizes", Journal of Cryptology 14 (2001) 255-293.
[ODL99] Odlyzko, A., "Discrete logarithms: The past and the [ODL99] Odlyzko, A., "Discrete logarithms: The past and the
future, Designs, Codes, and Cryptography (1999)". future, Designs, Codes, and Cryptography (1999)".
Authors' Addresses
Brian Tung
USC Information Sciences Institute
4676 Admiralty Way Suite 1001, Marina del Rey CA
Marina del Rey, CA 90292
US
Email: brian@isi.edu
Larry Zhu
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
US
Email: lzhu@microsoft.com
Appendix A. PKINIT ASN.1 Module Appendix A. PKINIT ASN.1 Module
KerberosV5-PK-INIT-SPEC { KerberosV5-PK-INIT-SPEC {
iso(1) identified-organization(3) dod(6) internet(1) iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) pkinit(5) security(5) kerberosV5(2) modules(4) pkinit(5)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN } DEFINITIONS EXPLICIT TAGS ::= BEGIN
IMPORTS IMPORTS
SubjectPublicKeyInfo, AlgorithmIdentifier SubjectPublicKeyInfo, AlgorithmIdentifier
FROM PKIX1Explicit88 { iso (1) FROM PKIX1Explicit88 { iso (1)
identified-organization (3) dod (6) internet (1) identified-organization (3) dod (6) internet (1)
security (5) mechanisms (5) pkix (7) id-mod (0) security (5) mechanisms (5) pkix (7) id-mod (0)
id-pkix1-explicit (18) } id-pkix1-explicit (18) }
-- As defined in RFC 3280. -- As defined in RFC 3280.
DomainParameters KerberosTime, PrincipalName, Realm, EncryptionKey
FROM PKIX1Algorithms88 { iso(1)
identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-algorithms(17) }
-- As defined in RFC 3279.
KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey
FROM KerberosV5Spec2 { iso(1) identified-organization(3) FROM KerberosV5Spec2 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) kerberosV5(2) dod(6) internet(1) security(5) kerberosV5(2)
modules(4) krb5spec2(2) } ; modules(4) krb5spec2(2) } ;
id-pkinit OBJECT IDENTIFIER ::= id-pkinit OBJECT IDENTIFIER ::=
{ iso (1) org (3) dod (6) internet (1) security (5) { iso (1) org (3) dod (6) internet (1) security (5)
kerberosv5 (2) pkinit (3) } kerberosv5 (2) pkinit (3) }
id-pkauthdata OBJECT IDENTIFIER ::= { id-pkinit 1 } id-pkauthdata OBJECT IDENTIFIER ::= { id-pkinit 1 }
id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 } id-pkdhkeydata OBJECT IDENTIFIER ::= { id-pkinit 2 }
id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 } id-pkrkeydata OBJECT IDENTIFIER ::= { id-pkinit 3 }
id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 } id-pkekuoid OBJECT IDENTIFIER ::= { id-pkinit 4 }
id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 } id-pkkdcekuoid OBJECT IDENTIFIER ::= { id-pkinit 5 }
id-pksan OBJECT IDENTIFIER ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
x509-sanan (2) }
pa-pk-as-req INTEGER ::= 16 pa-pk-as-req INTEGER ::= 16
pa-pk-as-rep INTEGER ::= 17 pa-pk-as-rep INTEGER ::= 17
ad-initial-verified-cas INTEGER ::= 9 ad-initial-verified-cas INTEGER ::= 9
td-trusted-certifiers INTEGER ::= 104 td-trusted-certifiers INTEGER ::= 104
td-invalid-certificates INTEGER ::= 105 td-invalid-certificates INTEGER ::= 105
td-dh-parameters INTEGER ::= 109 td-dh-parameters INTEGER ::= 109
PA-PK-AS-REQ ::= SEQUENCE { PA-PK-AS-REQ ::= SEQUENCE {
skipping to change at page 27, line 39 skipping to change at page 28, line 4
-- referenced, this key identifier matches the X.509 -- referenced, this key identifier matches the X.509
-- subjectKeyIdentifier extension value. When other -- subjectKeyIdentifier extension value. When other
-- certificate formats are referenced, the documents -- certificate formats are referenced, the documents
-- that specify the certificate format and their use -- that specify the certificate format and their use
-- with the CMS must include details on matching the -- with the CMS must include details on matching the
-- key identifier to the appropriate certificate -- key identifier to the appropriate certificate
-- field. -- field.
-- RECOMMENDED for TD-TRUSTED-CERTIFIERS. -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
... ...
} }
AuthPack ::= SEQUENCE { AuthPack ::= SEQUENCE {
pkAuthenticator [0] PKAuthenticator, pkAuthenticator [0] PKAuthenticator,
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
-- Type SubjectPublicKeyInfo is defined in -- Type SubjectPublicKeyInfo is defined in
-- [RFC3280]. -- [RFC3280].
-- Specifies Diffie-Hellman domain parameters -- Specifies Diffie-Hellman domain parameters
-- and the client's public key value [IEEE1363]. -- and the client's public key value [IEEE1363].
-- The DH public key value is encoded as a BIT -- The DH public key value is encoded as a BIT
-- STRING, as specified in Section 2.3.3 of -- STRING according to [RFC3279].
-- [RFC3279].
-- This field is present only if the client wishes -- This field is present only if the client wishes
-- to use the Diffie-Hellman key agreement method. -- to use the Diffie-Hellman key agreement method.
supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
OPTIONAL, OPTIONAL,
-- Type AlgorithmIdentifier is defined in -- Type AlgorithmIdentifier is defined in
-- [RFC3280]. -- [RFC3280].
-- List of CMS encryption types supported by the -- List of CMS encryption types supported by the
-- client in order of (decreasing) preference. -- client in order of (decreasing) preference.
clientDHNonce [3] DHNonce OPTIONAL, clientDHNonce [3] DHNonce OPTIONAL,
-- Present only if the client indicates that it -- Present only if the client indicates that it
skipping to change at page 29, line 40 skipping to change at page 30, line 4
-- Contains a CMS type ContentInfo encoded according -- Contains a CMS type ContentInfo encoded according
-- to [RFC3852]. -- to [RFC3852].
-- The contentType field of the type ContentInfo is -- The contentType field of the type ContentInfo is
-- id-signedData (1.2.840.113549.1.7.2), and the -- id-signedData (1.2.840.113549.1.7.2), and the
-- content field is a SignedData. -- content field is a SignedData.
-- The eContentType field for the type SignedData is -- The eContentType field for the type SignedData is
-- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
-- eContent field contains the DER encoding of the -- eContent field contains the DER encoding of the
-- type KDCDHKeyInfo. -- type KDCDHKeyInfo.
-- KDCDHKeyInfo is defined below. -- KDCDHKeyInfo is defined below.
serverDHNonce [1] DHNonce OPTIONAL serverDHNonce [1] DHNonce OPTIONAL
-- Present if and only if dhKeyExpiration is -- Present if and only if dhKeyExpiration is
-- present. -- present.
} }
KDCDHKeyInfo ::= SEQUENCE { KDCDHKeyInfo ::= SEQUENCE {
subjectPublicKey [0] BIT STRING, subjectPublicKey [0] BIT STRING,
-- KDC's DH public key. -- KDC's DH public key.
-- The DH public key value is encoded as a BIT -- The DH public key value is encoded as a BIT
-- STRING, as specified in Section 2.3.3 of -- STRING according to [RFC3279].
-- [RFC3279]. nonce [1] INTEGER (0..4294967295),
nonce [1] INTEGER (0..4294967295),
-- Contains the nonce in the PKAuthenticator of the -- Contains the nonce in the PKAuthenticator of the
-- request if DH keys are NOT reused, -- request if DH keys are NOT reused,
-- 0 otherwise. -- 0 otherwise.
dhKeyExpiration [2] KerberosTime OPTIONAL, dhKeyExpiration [2] KerberosTime OPTIONAL,
-- Expiration time for KDC's key pair, -- Expiration time for KDC's key pair,
-- present if and only if DH keys are reused. If -- present if and only if DH keys are reused. If
-- this field is omitted then the serverDHNonce -- this field is omitted then the serverDHNonce
-- field MUST also be omitted. -- field MUST also be omitted.
... ...
} }
skipping to change at page 31, line 5 skipping to change at page 31, line 5
-- of the AS-REP. -- of the AS-REP.
... ...
} }
TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-- Each AlgorithmIdentifier specifies a set of -- Each AlgorithmIdentifier specifies a set of
-- Diffie-Hellman domain parameters [IEEE1363]. -- Diffie-Hellman domain parameters [IEEE1363].
-- This list is in decreasing preference order. -- This list is in decreasing preference order.
END END
Appendix B. Test Vectors
Function octetstring2key() is defined in Section 3.2.3.1. This
section describes a few sets of test vectors that would be useful for
implementers of octetstring2key().
Set 1
=====
Input octet string x is:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Output of K-truncate() when the key size is 32 octets:
5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83
75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41
Set 2:
=====
Input octet string x is:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Output of K-truncate() when the key size is 32 octets:
ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb
a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e
Set 3:
======
Input octet string x is:
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b
0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a
0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09
0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
Output of K-truncate() when the key size is 32 octets:
c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3
73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e
Set 4:
=====
Input octet string x is:
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
0d 0e 0f 10 00 01 02 03 04 05 06 07 08
Output of K-truncate() when the key size is 32 octets:
00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a
59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc
Authors' Addresses
Brian Tung
USC Information Sciences Institute
4676 Admiralty Way Suite 1001, Marina del Rey CA
Marina del Rey, CA 90292
US
Email: brian@isi.edu
Larry Zhu
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
US
Email: lzhu@microsoft.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 39 change blocks. 
76 lines changed or deleted 192 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/