oysteikt/heimdal
0
0
Fork 0
Code Issues 5 Pull Requests Releases Activity

x

Browse Source 
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@13383 ec53bebd-3082-4978-b11e-865c3cabbd6b
This commit is contained in:
Love Hörnquist Åstrand
2004-02-17 22:21:24 +00:00
parent ed2915aca8
commit 05087c906f
4 changed files with 10786 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

893
doc/standardisation/draft-ietf-cat-kerberos-pk-init-18.txt Normal file
View File

@@ -0,0 +1,893 @@
INTERNET-DRAFT Brian Tung
draft-ietf-cat-kerberos-pk-init-18.txt Clifford Neuman
Updates: RFC 1510bis USC/ISI
expires August 20, 2004 Matthew Hur
Ari Medvinsky
Microsoft Corporation
Sasha Medvinsky
Motorola, Inc.
John Wray
Iris Associates, Inc.
Jonathan Trostle
Public Key Cryptography for Initial Authentication in Kerberos
0. Status Of This Memo
This document is an Internet-Draft and is in full conformance with
all provision of Section 10 of RFC 2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
The distribution of this memo is unlimited. It is filed as
draft-ietf-cat-kerberos-pk-init-18.txt and expires August 20, 2004.
Please send comments to the authors.
1. Abstract
This draft describes protocol extensions (hereafter called PKINIT)
to the Kerberos protocol specification (RFC 1510bis [1]). These
extensions provide a method for integrating public key cryptography
into the initial authentication exchange, by passing cryptographic
certificates and associated authenticators in preauthentication data
fields.
2. Introduction
A client typically authenticates itself to a service in Kerberos
using three distinct though related exchanges. First, the client
requests a ticket-granting ticket (TGT) from the Kerberos
authentication server (AS). Then, it uses the TGT to request a
service ticket from the Kerberos ticket-granting server (TGS).
Usually, the AS and TGS are integrated in a single device known as
a Kerberos Key Distribution Center, or KDC. (In this draft, we will
refer to both the AS and the TGS as the KDC.) Finally, the client
uses the service ticket to authenticate itself to the service.
The advantage afforded by the TGT is that the user need only
explicitly request a ticket and expose his credentials once. The
TGT and its associated session key can then be used for any
subsequent requests. One implication of this is that all further
authentication is independent of the method by which the initial
authentication was performed. Consequently, initial authentication
provides a convenient place to integrate public-key cryptography
into Kerberos authentication.
As defined, Kerberos authentication exchanges use symmetric-key
cryptography, in part for performance. (Symmetric-key cryptography
is typically 10-100 times faster than public-key cryptography,
depending on the public-key operations. [cite]) One cost of using
symmetric-key cryptography is that the keys must be shared, so that
before a user can authentication himself, he must already be
registered with the KDC.
Conversely, public-key cryptography--in conjunction with an
established certification infrastructure--permits authentication
without prior registration. Adding it to Kerberos allows the
widespread use of Kerberized applications by users without requiring
them to register first--a requirement that has no inherent security
benefit.
As noted above, a convenient and efficient place to introduce
public-key cryptography into Kerberos is in the initial
authentication exchange. This document describes the methods and
data formats for integrating public-key cryptography into Kerberos
initial authentication. Another document (PKCROSS) describes a
similar protocol for Kerberos cross-realm authentication.
3. Extensions
This section describes extensions to RFC 1510bis for supporting the
use of public-key cryptography in the initial request for a ticket
granting ticket (TGT).
Briefly, the following changes to RFC 1510bis are proposed:
1. If public-key authentication is indicated, the client sends
the user's public-key data and an authenticator in a
preauthentication field accompanying the usual request.
This authenticator is signed by the user's private
signature key.
2. The KDC verifies the client's request against its own
policy and certification authorities.
3. If the request passes the verification tests, the KDC
replies as usual, but the reply is encrypted using either:
a. a randomly generated key, signed using the KDC's
signature key and encrypted using the user's encryption
key; or
b. a key generated through a Diffie-Hellman exchange with
the client, signed using the KDC's signature key.
Any key data required by the client to obtain the encryption
key is returned in a preauthentication field accompanying
the usual reply.
4. The client obtains the encryption key, decrypts the reply,
and then proceeds as usual.
Section 3.1 of this document defines the necessary message formats.
Section 3.2 describes their syntax and use in greater detail.
Implementation of all specified formats and uses in these sections
is REQUIRED for compliance with PKINIT.
3.1. Definitions
3.1.1. Required Algorithms
At minimum, PKINIT must be able to use the following algorithms:
Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype
(as required by clarifications).
Signature algorithm: SHA-1 digest and RSA.
Reply key delivery method: ephemeral-ephemeral Diffie-Hellman
with a non-zero nonce.
Unkeyed checksum type for the paChecksum member of
PKAuthenticator: SHA1 (unkeyed).
3.1.2. Defined Message and Encryption Types
PKINIT makes use of the following new preauthentication types:
PA-PK-AS-REQ TBD
PA-PK-AS-REP TBD
PA-PK-OCSP-REQ TBD
PA-PK-OCSP-REP TBD
PKINIT also makes use of the following new authorization data type:
AD-INITIAL-VERIFIED-CAS TBD
PKINIT introduces the following new error types:
KDC_ERR_CLIENT_NOT_TRUSTED 62
KDC_ERR_KDC_NOT_TRUSTED 63
KDC_ERR_INVALID_SIG 64
KDC_ERR_KEY_TOO_WEAK 65
KDC_ERR_CERTIFICATE_MISMATCH 66
KDC_ERR_CANT_VERIFY_CERTIFICATE 70
KDC_ERR_INVALID_CERTIFICATE 71
KDC_ERR_REVOKED_CERTIFICATE 72
KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
KDC_ERR_CLIENT_NAME_MISMATCH 75
PKINIT uses the following typed data types for errors:
TD-DH-PARAMETERS 102
TD-TRUSTED-CERTIFIERS 104
TD-CERTIFICATE-INDEX 105
PKINIT defines the following encryption types, for use in the AS-REQ
message (to indicate acceptance of the corresponding encryption OIDs
in PKINIT):
dsaWithSHA1-CmsOID 9
md5WithRSAEncryption-CmsOID 10
sha1WithRSAEncryption-CmsOID 11
rc2CBC-EnvOID 12
rsaEncryption-EnvOID (PKCS1 v1.5) 13
rsaES-OAEP-ENV-OID (PKCS1 v2.0) 14
des-ede3-cbc-Env-OID 15
The above encryption types are used (in PKINIT) only within CMS [8]
structures within the PKINIT preauthentication fields. Their use
within Kerberos EncryptedData structures is unspecified.
3.1.3. Algorithm Identifiers
PKINIT does not define, but does make use of, the following
algorithm identifiers.
PKINIT uses the following algorithm identifier for Diffie-Hellman
key agreement [11]:
dhpublicnumber
PKINIT uses the following signature algorithm identifiers [8, 12]:
sha-1WithRSAEncryption (RSA with SHA1)
md5WithRSAEncryption (RSA with MD5)
id-dsa-with-sha1 (DSA with SHA1)
PKINIT uses the following encryption algorithm identifiers [12] for
encrypting the temporary key with a public key:
rsaEncryption (PKCS1 v1.5)
id-RSAES-OAEP (PKCS1 v2.0)
These OIDs are not to be confused with the encryption types listed
above.
PKINIT uses the following algorithm identifiers [8] for encrypting
the reply key with the temporary key:
des-ede3-cbc (three-key 3DES, CBC mode)
rc2-cbc (RC2, CBC mode)
Again, these OIDs are not to be confused with the encryption types
listed above.
3.2. PKINIT Preauthentication Syntax and Use
In this section, we describe the syntax and use of the various
preauthentication fields employed to implement PKINIT.
3.2.1. Client Request
The initial authentication request (AS-REQ) is sent as per RFC
1510bis, except that a preauthentication field containing data
signed by the user's private signature key accompanies the request,
as follows:
PA-PK-AS-REQ ::= SEQUENCE {
-- PAType TBD
signedAuthPack [0] ContentInfo,
-- Defined in CMS.
-- Type is SignedData.
-- Content is AuthPack
-- (defined below).
trustedCertifiers [1] SEQUENCE OF TrustedCAs OPTIONAL,
-- A list of CAs, trusted by
-- the client, used to certify
-- KDCs.
kdcCert [2] IssuerAndSerialNumber OPTIONAL,
-- Defined in CMS.
-- Identifies a particular KDC
-- certificate, if the client
-- already has it.
encryptionCert [3] IssuerAndSerialNumber OPTIONAL,
-- May identify the user's
-- Diffie-Hellman certificate,
-- or an RSA encryption key
-- certificate.
...
}
TrustedCAs ::= CHOICE {
caName [0] Name,
-- Fully qualified X.500 name
-- as defined in X.509 [11].
issuerAndSerial [1] IssuerAndSerialNumber,
-- Identifies a specific CA
-- certificate, if the client
-- only trusts one.
...
}
AuthPack ::= SEQUENCE {
pkAuthenticator [0] PKAuthenticator,
clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
-- Defined in X.509,
-- reproduced below.
-- Present only if the client
-- is using ephemeral-ephemeral
-- Diffie-Hellman.
}
PKAuthenticator ::= SEQUENCE {
cusec [0] INTEGER,
ctime [1] KerberosTime,
-- cusec and ctime are used as
-- in RFC 1510bis, for replay
-- prevention.
nonce [2] INTEGER,
-- Binds reply to request,
-- except is zero when client
-- will accept cached
-- Diffie-Hellman parameters
-- from KDC and MUST NOT be
-- zero otherwise.
-- MUST be < 2^32.
paChecksum [3] Checksum,
-- Defined in [15].
-- Performed over KDC-REQ-BODY,
-- must be unkeyed.
...
}
IMPORTS
-- from X.509
SubjectPublicKeyInfo, AlgorithmIdentifier, DomainParameters,
ValidationParms
FROM PKIX1Explicit88 { iso (1) identified-organization (3)
dod (6) internet (1) security (5) mechanisms (5)
pkix (7) id-mod (0) id-pkix1-explicit-88 (1) }
The ContentInfo in the signedAuthPack is filled out as follows:
1. The eContent field contains data of type AuthPack. It MUST
contain the pkAuthenticator, and MAY also contain the
user's Diffie-Hellman public value (clientPublicValue).
2. The eContentType field MUST contain the OID value for
pkauthdata: { iso (1) org (3) dod (6) internet (1)
security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)}
3. The signerInfos field MUST contain the signature of the
AuthPack.
4. The certificates field MUST contain at least a signature
verification certificate chain that the KDC can use to
verify the signature on the AuthPack. Additionally, the
client may also insert an encryption certificate chain, if
(for example) the client is not using ephemeral-ephemeral
Diffie-Hellman.
5. If a Diffie-Hellman key is being used, the parameters SHOULD
be chosen from the First or Second defined Oakley Groups.
(See RFC 2409 [c].)
6. The KDC may wish to use cached Diffie-Hellman parameters.
To indicate acceptance of caching, the client sends zero in
the nonce field of the pkAuthenticator. Zero is not a valid
value for this field under any other circumstances. Since
zero is used to indicate acceptance of cached parameters,
message binding in this case is performed instead using the
nonce in the main request.
3.2.2. Validation of Client Request
Upon receiving the client's request, the KDC validates it. This
section describes the steps that the KDC MUST (unless otherwise
noted) take in validating the request.
The KDC must look for a user certificate in the signedAuthPack.
If it cannot find one signed by a CA it trusts, it sends back an
error of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying
e-data for this error is a SEQUENCE OF TypedData:
TypedData ::= SEQUENCE {
-- As defined in RFC 1510bis.
data-type [0] INTEGER,
data-value [1] OCTET STRING
}
For this error, the data-type is TD-TRUSTED-CERTIFIERS, and the
data-value is an OCTET STRING containing the DER encoding of
TrustedCertifiers ::= SEQUENCE OF Name
If, while verifying the certificate chain, the KDC determines that
the signature on one of the certificates in the signedAuthPack is
invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.
The accompanying e-data for this error is a SEQUENCE OF TypedData,
whose data-type is TD-CERTIFICATE-INDEX, and whose data-value is an
OCTET STRING containing the DER encoding of the index into the
CertificateSet field, ordered as sent by the client:
CertificateIndex ::= INTEGER
-- 0 = first certificate (in
-- order of encoding),
-- 1 = second certificate, etc.
If more than one signature is invalid, the KDC sends one TypedData
per invalid signature.
The KDC MAY also check whether any of the certificates in the user's
chain have been revoked. If any of them have been revoked, the KDC
returns an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC
attempts to determine the revocation status but is unable to do so,
it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN.
The certificate or certificates affected are identified exactly as
for an error of type KDC_ERR_INVALID_CERTIFICATE (see above).
If the certificate chain is successfully validated, but the user's
certificate is not authorized to the client's principal name in the
AS-REQ (when present), the KDC MUST return an error of type
KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for
this error.
Even if the chain is validated, and the names in the certificate and
the request match, the KDC may decide not to trust the client. For
example, the certificate may include (or not include) an Enhanced
Key Usage (EKU) OID in the extensions field. As a matter of local
policy, the KDC may decide to reject requests on the basis of the
absence or presence of specific EKU OIDs. In this case, the KDC
returns an error of type KDC_ERR_CLIENT_NOT_TRUSTED. For the
benefit of implementors, we define a PKINIT EKU OID as follows:
{ iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2)
pkinit (3) pkekuoid (4) }.
If the certificate chain and usage check out, but the client's
signature on the signedAuthPack fails to verify, the KDC returns an
error of type KDC_ERR_INVALID_SIG. There is no accompanying e-data
for this error.
The KDC must check the timestamp to ensure that the request is not
a replay, and that the time skew falls within acceptable limits.
The recommendations for ordinary (that is, non-PKINIT) skew times
apply here. If the check fails, the KDC returns an error of type
KRB_AP_ERR_REPEAT or KRB_AP_ERR_SKEW, respectively.
Finally, if the clientPublicValue is filled in, indicating that the
client wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC
checks to see if the parameters satisfy its policy. If they do not,
it returns an error of type KDC_ERR_KEY_TOO_WEAK. The accompanying
e-data is a SEQUENCE OF TypedData, whose data-type is
TD-DH-PARAMETERS, and whose data-value is an OCTET STRING containing
the DER encoding of a DomainParameters (see above), including
appropriate Diffie-Hellman parameters with which to retry the
request.
In order to establish authenticity of the reply, the KDC will sign
some key data (either the random key used to encrypt the reply in
the case of a KDCDHKeyInfo, or the Diffie-Hellman parameters used to
generate the reply-encrypting key in the case of a ReplyKeyPack).
The signature certificate to be used is to be selected as follows:
1. If the client included a kdcCert field in the PA-PK-AS-REQ,
use the referred-to certificate, if the KDC has it. If it
does not, the KDC returns an error of type
KDC_ERR_CERTIFICATE_MISMATCH.
2. Otherwise, if the client did not include a kdcCert field,
but did include a trustedCertifiers field, and the KDC
possesses a certificate issued by one of the listed
certifiers, use that certificate. if it does not possess
one, it returns an error of type KDC_ERR_KDC_NOT_TRUSTED.
3. Otherwise, if the client included neither a kdcCert field
nor a trustedCertifiers field, and the KDC has only one
signature certificate, use that certificate. If it has
more than one certificate, it returns an error of type
KDC_ERR_CERTIFICATE_MISMATCH.
3.2.3. KDC Reply
Assuming that the client's request has been properly validated, the
KDC proceeds as per RFC 1510bis, except as follows.
The user's name as represented in the AS-REP must be derived from
the certificate provided in the client's request. If the KDC has
its own mapping from the name in the certificate to a Kerberos name,
it uses that Kerberos name.
Otherwise, if the certificate contains a SubjectAltName extension
with a KerberosName in the otherName field, it uses that name.
AnotherName ::= SEQUENCE {
-- Defined in [11].
type-id OBJECT IDENTIFIER,
value [0] EXPLICIT ANY DEFINED BY type-id
}
KerberosName ::= SEQUENCE {
realm [0] Realm,
principalName [1] PrincipalName
}
with OID
krb5 OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6) internet (1)
security (5) kerberosv5 (2) }
krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }
In this case, the realm in the ticket is that of the local realm (or
some other realm name chosen by that realm). Otherwise, the KDC
returns an error of type KDC_ERR_CLIENT_NAME_MISMATCH.
In addition, the KDC MUST set the initial flag in the issued TGT
*and* add an authorization data of type AD-INITIAL-VERIFIED-CAS to
the TGT. The value is an OCTET STRING containing the DER encoding
of InitialVerifiedCAs:
InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
ca [0] Name,
ocspValidated [1] BOOLEAN,
...
}
The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
containers if the list of CAs satisfies the KDC's realm's policy.
(This corresponds to the TRANSITED-POLICY-CHECKED ticket flag.)
Furthermore, any TGS must copy such authorization data from tickets
used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket,
including the AD-IF-RELEVANT container, if present.
AP servers that understand this authorization data type SHOULD apply
local policy to determine whether a given ticket bearing such a type
(not contained within an AD-IF-RELEVANT container) is acceptable.
(This corresponds to the AP server checking the transited field when
the TRANSITED-POLICY-CHECKED flag has not been set.) If such a data
type *is* contained within an AD-IF-RELEVANT container, AP servers
still MAY apply local policy to determine whether the authorization
data is acceptable.
The AS-REP is otherwise unchanged from RFC 1510bis. The KDC then
encrypts the reply as usual, but not with the user's long-term key.
Instead, it encrypts it with either a random encryption key, or a
key derived from a Diffie-Hellman exchange. Which is the case is
indicated by the contents of the PA-PK-AS-REP (note tags):
PA-PK-AS-REP ::= CHOICE {
-- PAType YY (TBD)
dhSignedData [0] ContentInfo,
-- Type is SignedData.
-- Content is KDCDHKeyInfo
-- (defined below).
encKeyPack [1] ContentInfo,
-- Type is EnvelopedData.
-- Content is ReplyKeyPack
-- (defined below).
...
}
Note that PA-PK-AS-REP is a CHOICE: either a dhSignedData, or an
encKeyPack, but not both. The former contains data of type
KDCDHKeyInfo, and is used only when the reply is encrypted using a
Diffie-Hellman derived key:
KDCDHKeyInfo ::= SEQUENCE {
subjectPublicKey [0] BIT STRING,
-- Equals public exponent
-- (g^a mod p).
-- INTEGER encoded as payload
-- of BIT STRING.
nonce [1] INTEGER,
-- Binds reply to request.
-- Exception: A value of zero
-- indicates that the KDC is
-- using cached values.
dhKeyExpiration [2] KerberosTime OPTIONAL,
-- Expiration time for KDC's
-- cached values.
...
}
The fields of the ContentInfo for dhSignedData are to be filled in
as follows:
1. The eContent field contains data of type KDCDHKeyInfo.
2. The eContentType field contains the OID value for
pkdhkeydata: { iso (1) org (3) dod (6) internet (1)
security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2) }
3. The signerInfos field contains a single signerInfo, which is
the signature of the KDCDHKeyInfo.
4. The certificates field contains a signature verification
certificate chain that the client may use to verify the
KDC's signature over the KDCDHKeyInfo.) It may only be left
empty if the client did not include a trustedCertifiers
field in the PA-PK-AS-REQ, indicating that it has the KDC's
certificate.
5. If the client and KDC agree to use cached parameters, the
KDC SHOULD return a zero in the nonce field and include the
expiration time of the cached values in the dhKeyExpiration
field. If this time is exceeded, the client SHOULD NOT use
the reply. If the time is absent, the client SHOULD NOT use
the reply and MAY resubmit a request with a non-zero nonce,
thus indicating non-acceptance of the cached parameters.
The key is derived as follows: Both the KDC and the client calculate
the value g^(ab) mod p, where a and b are the client's and KDC's
private exponents, respectively. They both take the first k bits of
this secret value as a key generation seed, where the parameter k
(the size of the seed) is dependent on the selected key type, as
specified in the Kerberos crypto draft [15]. The seed is then
converted into a protocol key by applying to it a random-to-key
function, which is also dependent on key type.
The protocol key is used to derive the integrity key Ki and the
encryption key Ke according to [15]. Ke and Ki are used to generate
the encrypted part of the AS-REP.
1. For example, if the encryption type is DES with MD4, k = 64
bits and the random-to-key function consists of replacing
some of the bits with parity bits, according to FIPS PUB 74
[cite]. In this case, the key derivation function for Ke is
the identity function, and Ki is not needed because the
checksum in the EncryptedData is not keyed.
2. If the encryption type is three-key 3DES with HMAC-SHA1,
k = 168 bits and the random-to-key function is
DES3random-to-key as defined in [15]. This function inserts
parity bits to create a 192-bit 3DES protocol key that is
compliant with FIPS PUB 74 [cite]. Ke and Ki are derived
from this protocol key according to [15] with the key usage
number set to 3 (AS-REP encrypted part).
If the KDC and client are not using Diffie-Hellman, the KDC encrypts
the reply with an encryption key, packed in the encKeyPack, which
contains data of type ReplyKeyPack:
ReplyKeyPack ::= SEQUENCE {
replyKey [0] EncryptionKey,
-- Defined in RFC 1510bis.
-- Used to encrypt main reply.
-- MUST be at least as large
-- as session key.
nonce [1] INTEGER,
-- Binds reply to request.
-- MUST be < 2^32.
...
}
The fields of the ContentInfo for encKeyPack MUST be filled in as
follows:
1. The innermost data is of type SignedData. The eContent for
this data is of type ReplyKeyPack.
2. The eContentType for this data contains the OID value for
pkrkeydata: { iso (1) org (3) dod (6) internet (1)
security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3) }
3. The signerInfos field contains a single signerInfo, which is
the signature of the ReplyKeyPack.
4. The certificates field contains a signature verification
certificate chain, which the client may use to verify the
KDC's signature over the ReplyKeyPack.) It may only be left
empty if the client did not include a trustedCertifiers
field in the PA-PK-AS-REQ, indicating that it has the KDC's
certificate.
5. The outer data is of type EnvelopedData. The
encryptedContent for this data is the SignedData described
in items 1 through 4, above.
6. The encryptedContentType for this data contains the OID
value for id-signedData: { iso (1) member-body (2) us (840)
rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) }
7. The recipientInfos field is a SET which MUST contain exactly
one member of type KeyTransRecipientInfo. The encryptedKey
for this member contains the temporary key which is
encrypted using the client's public key.
8. Neither the unprotectedAttrs field nor the originatorInfo
field is required for PKINIT.
3.2.4. Validation of KDC Reply
Upon receipt of the KDC's reply, the client proceeds as follows. If
the PA-PK-AS-REP contains a dhSignedData, the client obtains and
verifies the Diffie-Hellman parameters, and obtains the shared key
as described above. Otherwise, the message contains an encKeyPack,
and the client decrypts and verifies the temporary encryption key.
In either case, the client then decrypts the main reply with the
resulting key, and then proceeds as described in RFC 1510bis.
3.2.5. Support for OCSP
OCSP (Online Certificate Status Protocol) [cite] allows the use of
on-line requests for a client or server to determine the validity of
each other's certificates. It is particularly useful for clients
authenticating each other across a constrained network. These
clients will not have to download the entire CRL to check for the
validity of the KDC's certificate.
In these cases, the KDC generally has better connectivity to the
OCSP server, and it therefore processes the OCSP request and
response and sends the results to the client. The changes proposed
in this section allow a client to request an OCSP response from the
KDC when using PKINIT. This is similar to the way that OCSP is
handled in [cite].
OCSP support is provided in PKINIT through the use of additional
preauthentication data. The following new preauthentication types
are defined:
PA-PK-OCSP-REQ ::= SEQUENCE {
-- PAType TBD
responderIDList [0] SEQUENCE of ResponderID OPTIONAL,
-- ResponderID is a DER-encoded
-- ASN.1 type defined in [cite]
requestExtensions [1] Extensions OPTIONAL
-- Extensions is a DER-encoded
-- ASN.1 type defined in [cite]
}
PA-PK-OCSP-REP ::= SEQUENCE of OCSPResponse
-- OCSPResponse is a DER-encoded
-- ASN.1 type defined in [cite]
A KDC that receives a PA-PK-OCSP-REQ MAY send a PA-PK-OCSP-REP.
KDCs MUST NOT send a PA-PK-OCSP-REP if they do not first receive a
PA-PK-OCSP-REQ from the client. The KDC may either send a cached
OCSP response or send an on-line request to the OCSP server.
When using OCSP, the response is signed by the OCSP server, which is
trusted by the client. Depending on local policy, further
verification of the validity of the OCSP server may need to be done.
4. Security Considerations
PKINIT raises certain security considerations beyond those that can
be regulated strictly in protocol definitions. We will address them
in this section.
PKINIT extends the cross-realm model to the public-key
infrastructure. Anyone using PKINIT must be aware of how the
certification infrastructure they are linking to works.
Also, as in standard Kerberos, PKINIT presents the possibility of
interactions between cryptosystems of varying strengths, and this
now includes public-key cryptosystems. Many systems, for example,
allow the use of 512-bit public keys. Using such keys to wrap data
encrypted under strong conventional cryptosystems, such as 3DES, may
be inappropriate.
PKINIT calls for randomly generated keys for conventional
cryptosystems. Many such systems contain systematically "weak"
keys. For recommendations regarding these weak keys, see RFC
1510bis.
PKINIT allows the use of a zero nonce in the PKAuthenticator when
cached Diffie-Hellman parameters are used. In this case, message
binding is performed using the nonce in the main request in the same
way as it is done for ordinary (that is, non-PKINIT) AS-REQs. The
nonce field in the KDC request body is signed through the checksum
in the PKAuthenticator, and it therefore cryptographically binds the
AS-REQ with the AS-REP. If cached parameters are also used on the
client side, the generated session key will be the same, and a
compromised session key could lead to the compromise of future
cached exchanges. It is desirable to limit the use of cached
parameters to just the KDC, in order to eliminate this exposure.
Care should be taken in how certificates are chosen for the purposes
of authentication using PKINIT. Some local policies may require
that key escrow be applied for certain certificate types. People
deploying PKINIT should be aware of the implications of using
certificates that have escrowed keys for the purposes of
authentication.
PKINIT does not provide for a "return routability" test to prevent
attackers from mounting a denial-of-service attack on the KDC by
causing it to perform unnecessary and expensive public-key
operations. Strictly speaking, this is also true of standard
Kerberos, although the potential cost is not as great, because
standard Kerberos does not make use of public-key cryptography.
It might be possible to address this using a preauthentication field
as part of the proposed Kerberos preauthenticatino framework.
5. Acknowledgements
Some of the ideas on which this proposal is based arose during
discussions over several years between members of the SAAG, the IETF
CAT working group, and the PSRG, regarding integration of Kerberos
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
attempt to revive some of the goals of those groups, and this
proposal approaches those goals primarily from the Kerberos
perspective. Lastly, comments from groups working on similar ideas
in DCE have been invaluable.
6. Expiration Date
This draft expires August 20, 2004.
7. Bibliography
[1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service
(V5). Request for Comments 1510.
[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
for Computer Networks, IEEE Communications, 32(9):33-38. September
1994.
[3] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos
Using Public Key Cryptography. Symposium On Network and Distributed
System Security, 1997.
[4] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction
Protocol. In Proceedings of the USENIX Workshop on Electronic
Commerce, July 1995.
[5] T. Dierks, C. Allen. The TLS Protocol, Version 1.0. Request
for Comments 2246, January 1999.
[6] B.C. Neuman, Proxy-Based Authorization and Accounting for
Distributed Systems. In Proceedings of the 13th International
Conference on Distributed Computing Systems, May 1993.
[7] ITU-T (formerly CCITT) Information technology - Open Systems
Interconnection - The Directory: Authentication Framework
Recommendation X.509 ISO/IEC 9594-8
[8] R. Housley. Cryptographic Message Syntax.
draft-ietf-smime-cms-13.txt, April 1999, approved for publication as
RFC.
[9] PKCS #7: Cryptographic Message Syntax Standard. An RSA
Laboratories Technical Note Version 1.5. Revised November 1, 1993
[10] R. Rivest, MIT Laboratory for Computer Science and RSA Data
Security, Inc. A Description of the RC2(r) Encryption Algorithm.
March 1998. Request for Comments 2268.
[11] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
Key Infrastructure, Certificate and CRL Profile, April 2002.
Request for Comments 3280.
[12] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
Specifications, October 1998. Request for Comments 2437.
[13] ITU-T (formerly CCITT) Information Processing Systems - Open
Systems Interconnection - Specification of Abstract Syntax Notation
One (ASN.1) Rec. X.680 ISO/IEC 8824-1.
[14] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA
Laboratories Technical Note, Version 1.4, Revised November 1, 1993.
[15] K. Raeburn. Encryption and Checksum Specifications for
Kerberos 5, October 2003. draft-ietf-krb-wg-crypto-06.txt.
[16] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and
T. Wright. Transport Layer Security (TLS) Extensions, June 2003.
Request for Comments 3546.
[17] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams.
Internet X.509 Public Key Infrastructure: Online Certificate Status
Protocol - OCSP, June 1999. Request for Comments 2560.
8. Authors
Brian Tung
Clifford Neuman
USC Information Sciences Institute
4676 Admiralty Way Suite 1001
Marina del Rey CA 90292-6695
Phone: +1 310 822 1511
E-mail: {brian,bcn}@isi.edu
Matthew Hur
Ari Medvinsky
Microsoft Corporation
One Microsoft Way
Redmond WA 98052
Phone: +1 425 707 3336
E-mail: matthur@microsoft.com, arimed@windows.microsoft.com
Sasha Medvinsky
Motorola, Inc.
6450 Sequence Drive
San Diego, CA 92121
+1 858 404 2367
E-mail: smedvinsky@motorola.com
John Wray
Iris Associates, Inc.
5 Technology Park Dr.
Westford, MA 01886
E-mail: John_Wray@iris.com
Jonathan Trostle
E-mail: jtrostle@world.std.com

988
doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-06.txt Normal file
View File

@@ -0,0 +1,988 @@
<Network Working Group> Larry Zhu
Internet Draft Karthik Jaganathan
Updates: 1964 Microsoft
Category: Standards Track Sam Hartman
draft-ietf-krb-wg-gssapi-cfx-06.txt MIT
February 16, 2004
Expires: August 16, 2004
The Kerberos Version 5 GSS-API Mechanism: Version 2
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC-2026].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
The distribution of this memo is unlimited. It is filed as
draft-ietf-krb-wg-gssapi-cfx-06.txt, and expires on August 10
2004. Please send comments to: ietf-krb-wg@anl.gov.
Abstract
This document defines protocols, procedures, and conventions to be
employed by peers implementing the Generic Security Service
Application Program Interface (GSS-API) when using the Kerberos
Version 5 mechanism.
RFC-1964 is updated and incremental changes are proposed in response
to recent developments such as the introduction of Kerberos
cryptosystem framework. These changes support the inclusion of new
cryptosystems, by defining new per-message tokens along with their
encryption and checksum algorithms based on the cryptosystem
profiles.
Conventions used in this document
Zhu 1
DRAFT Kerberos Version 5 GSS-API Expires August 2004
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-2119].
The term "little endian order" is used for brevity to refer to the
least-significant-octet-first encoding, while the term "big endian
order" is for the most-significant-octet-first encoding.
Table of Contents
1. Introduction ............................................... 2
2. Key Derivation for Per-Message Tokens ...................... 3
3. Quality of Protection ...................................... 4
4. Definitions and Token Formats .............................. 4
4.1. Context Establishment Tokens ............................. 4
4.1.1. Authenticator Checksum ................................. 5
4.2. Per-Message Tokens ....................................... 8
4.2.1. Sequence Number ........................................ 8
4.2.2. Flags Field ............................................ 8
4.2.3. EC Field ............................................... 9
4.2.4. Encryption and Checksum Operations ..................... 9
4.2.5. RRC Field .............................................. 10
4.2.6. Message Layouts ........................................ 10
4.3. Context Deletion Tokens .................................. 11
4.4. Token Identifier Assignment Considerations ............... 11
5. Parameter Definitions ...................................... 12
5.1. Minor Status Codes ....................................... 12
5.1.1. Non-Kerberos-specific codes ............................ 12
5.1.2. Kerberos-specific-codes ................................ 12
5.2. Buffer Sizes ............................................. 13
6. Backwards Compatibility Considerations ..................... 13
7. Security Considerations .................................... 13
8. Acknowledgments ............................................ 14
9. Intellectual Property Statement ............................ 15
10. References ................................................ 15
10.1. Normative References .................................... 15
10.2. Informative References .................................. 15
11. Author's Address .......................................... 15
Full Copyright Statement ...................................... 17
1. Introduction
[KCRYPTO] defines a generic framework for describing encryption and
checksum types to be used with the Kerberos protocol and associated
protocols.
[RFC-1964] describes the GSS-API mechanism for Kerberos Version 5.
It defines the format of context establishment, per-message and
context deletion tokens and uses algorithm identifiers for each
cryptosystem in per message and context deletion tokens.
The approach taken in this document obviates the need for algorithm
identifiers. This is accomplished by using the same encryption
algorithm, specified by the crypto profile [KCRYPTO] for the session
key or subkey that is created during context negotiation, and its
required checksum algorithm. Message layouts of the per-message
Zhu 2
DRAFT Kerberos Version 5 GSS-API Expires August 2004
tokens are therefore revised to remove algorithm indicators and also
to add extra information to support the generic crypto framework
[KCRYPTO].
Tokens transferred between GSS-API peers for security context
establishment are also described in this document. The data
elements exchanged between a GSS-API endpoint implementation and the
Kerberos Key Distribution Center (KDC) [KRBCLAR] are not specific to
GSS-API usage and are therefore defined within [KRBCLAR] rather than
within this specification.
The new token formats specified in this document MUST be used with
all "newer" encryption types [KRBCLAR] and MAY be used with "older"
encryption types, provided that the initiator and acceptor know,
from the context establishment, that they can both process these new
token formats.
"Newer" encryption types are those which have been specified along
with or since the new Kerberos cryptosystem specification [KCRYPTO],
as defined in section 3.1.3 of [KRBCLAR]. The list of not-newer
encryption types is as follows [KCRYPTO]:
Encryption Type Assigned Number
----------------------------------------------
des-cbc-crc 1
des-cbc-md4 2
des-cbc-md5 3
des3-cbc-md5 5
des3-cbc-sha1 7
dsaWithSHA1-CmsOID 9
md5WithRSAEncryption-CmsOID 10
sha1WithRSAEncryption-CmsOID 11
rc2CBC-EnvOID 12
rsaEncryption-EnvOID 13
rsaES-OAEP-ENV-OID 14
des-ede3-cbc-Env-OID 15
des3-cbc-sha1-kd 16
rc4-hmac 23
2. Key Derivation for Per-Message Tokens
To limit the exposure of a given key, [KCRYPTO] adopted "one-way"
"entropy-preserving" derived keys, for different purposes or key
usages, from a base key or protocol key.
This document defines four key usage values below that are used to
derive a specific key for signing and sealing messages, from the
session key or subkey [KRBCLAR] created during the context
establishment.
Name Value
-------------------------------------
KG-USAGE-ACCEPTOR-SEAL 22
KG-USAGE-ACCEPTOR-SIGN 23
KG-USAGE-INITIATOR-SEAL 24
Zhu 3
DRAFT Kerberos Version 5 GSS-API Expires August 2004
KG-USAGE-INITIATOR-SIGN 25
When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is
used as the usage number in the key derivation function for deriving
keys to be used in MIC tokens (as defined in section 4.2.6.1), and
KG-USAGE-ACCEPTOR-SEAL is used for Wrap tokens(as defined in section
4.2.6.2); similarly when the sender is the context initiator, KG-
USAGE-INITIATOR-SIGN is used as the usage number in the key
derivation function for MIC tokens, KG-USAGE-INITIATOR-SEAL is used
for Wrap Tokens. Even if the Wrap token does not provide for
confidentiality the same usage values specified above are used.
During the context initiation and acceptance sequence, the acceptor
MAY assert a subkey, and if so, subsequent messages MUST use this
subkey as the protocol key and these messages MUST be flagged as
"AcceptorSubkey" as described in section 4.2.2.
3. Quality of Protection
The GSS-API specification [RFC-2743] provides for Quality of
Protection (QOP) values that can be used by applications to request
a certain type of encryption or signing. A zero QOP value is used
to indicate the "default" protection; applications which do not use
the default QOP are not guaranteed to be portable across
implementations or even inter-operate with different deployment
configurations of the same implementation. Using an algorithm that
is different from the one for which the key is defined may not be
appropriate. Therefore, when the new method in this document is
used, the QOP value is ignored.
The encryption and checksum algorithms in per-message tokens are now
implicitly defined by the algorithms associated with the session key
or subkey. Algorithms identifiers as described in [RFC-1964] are
therefore no longer needed and removed from the new token headers.
4. Definitions and Token Formats
This section provides terms and definitions, as well as descriptions
for tokens specific to the Kerberos Version 5 GSS-API mechanism.
4.1. Context Establishment Tokens
All context establishment tokens emitted by the Kerberos Version 5
GSS-API mechanism SHALL have the framing described in section 3.1 of
[RFC-2743], as illustrated by the following pseudo-ASN.1 structures:
GSS-API DEFINITIONS ::=
BEGIN
MechType ::= OBJECT IDENTIFIER
-- representing Kerberos V5 mechanism
GSSAPI-Token ::=
-- option indication (delegation, etc.) indicated within
Zhu 4
DRAFT Kerberos Version 5 GSS-API Expires August 2004
-- mechanism-specific token
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType,
innerToken ANY DEFINED BY thisMech
-- contents mechanism-specific
-- ASN.1 structure not required
}
END
Where the innerToken field starts with a two-octet token-identifier
(TOK_ID) expressed in big endian order, followed by a Kerberos
message.
Here are the TOK_ID values used in the context establishment tokens:
Token TOK_ID Value in Hex
-----------------------------------------
KRB_AP_REQ 01 00
KRB_AP_REP 02 00
KRB_ERROR 03 00
Where Kerberos message KRB_AP_REQUEST, KRB_AP_REPLY, and KRB_ERROR
are defined in [KRBCLAR].
If an unknown token identifier (TOK_ID) is received in the initial
context establishment token, the receiver MUST return
GSS_S_CONTINUE_NEEDED major status, and the returned output token
MUST contain a KRB_ERROR message with the error code
KRB_AP_ERR_MSG_TYPE [KRBCLAR].
4.1.1. Authenticator Checksum
The authenticator in the KRB_AP_REQ message MUST include the
optional sequence number and the checksum field. The checksum field
is used to convey service flags, channel bindings, and optional
delegation information.
The checksum type MUST be 0x8003. When delegation is used, a ticket-
granting ticket will be transferred in a KRB_CRED message. This
ticket SHOULD have its forwardable flag set. The EncryptedData
field of the KRB_CRED message [KRBCLAR] MUST be encrypted in the
session key of the ticket used to authenticate the context.
The authenticator checksum field SHALL have the following format:
Octet Name Description
-----------------------------------------------------------------
0..3 Lgth Number of octets in Bnd field; Represented
in little-endian order; Currently contains
hex value 10 00 00 00 (16).
4..19 Bnd Channel binding information, as described in
section 4.1.1.2.
20..23 Flags Four-octet context-establishment flags in
little-endian order as described in section
Zhu 5
DRAFT Kerberos Version 5 GSS-API Expires August 2004
4.1.1.1.
24..25 DlgOpt The delegation option identifier (=1) in
little-endian order [optional]. This field
and the next two fields are present if and
only if GSS_C_DELEG_FLAG is set as described
in section 4.1.1.1.
26..27 Dlgth The length of the Deleg field in little-
endian order [optional].
28..(n-1) Deleg A KRB_CRED message (n = Dlgth + 28)
[optional].
n..last Exts Extensions [optional].
The length of the checksum field MUST be at least 24 octets when
GSS_C_DELEG_FLAG is not set (as described in section 4.1.1.1), and
at least 28 octets plus Dlgth octets when GSS_C_DELEG_FLAG is set.
When GSS_C_DELEG_FLAG is set, the DlgOpt, Dlgth and Deleg fields
of the checksum data MUST immediately follow the Flags field. The
optional trailing octets (namely the "Exts" field) facilitate
future extensions to this mechanism. When delegation is not used
but the Exts field is present, the Exts field starts at octet 24
(DlgOpt, Dlgth and Deleg are absent).
Initiators that do not support the extensions MUST NOT include more
than 24 octets in the checksum field, when GSS_C_DELEG_FLAG is not
set, or more than 28 octets plus the KRB_CRED in the Deleg field,
when GSS_C_DELEG_FLAG is set. Acceptors that do not understand the
extensions MUST ignore any octets past the Deleg field of the
checksum data, when GSS_C_DELEG_FLAG is set, or past the Flags field
of the checksum data, when GSS_C_DELEG_FLAG is not set.
4.1.1.1. Checksum Flags Field
The checksum "Flags" field is used to convey service options or
extension negotiation information.
The following context establishment flags are defined in [RFC-2744].
Flag Name Value
---------------------------------
GSS_C_DELEG_FLAG 1
GSS_C_MUTUAL_FLAG 2
GSS_C_REPLAY_FLAG 4
GSS_C_SEQUENCE_FLAG 8
GSS_C_CONF_FLAG 16
GSS_C_INTEG_FLAG 32
Context establishment flags are exposed to the calling application.
If the calling application desires a particular service option then
it requests that option via GSS_Init_sec_context() [RFC-2743]. If
the corresponding return state values [RFC-2743] indicate that any
of above optional context level services will be active on the
context, the corresponding flag values in the table above MUST be
set in the checksum Flags field.
Zhu 6
DRAFT Kerberos Version 5 GSS-API Expires August 2004
Flag values 4096..524288 (2^12, 2^13, ..., 2^19) are reserved for
use with legacy vendor-specific extensions to this mechanism.
All other flag values not specified herein are reserved for future
use. Future revisions of this mechanism may use these reserved
flags and may rely on implementations of this version to not use
such flags in order to properly negotiate mechanism versions.
Undefined flag values MUST be cleared by the sender, and unknown
flags MUST be ignored by the receiver.
4.1.1.2. Channel Binding Information
These tags are intended to be used to identify the particular
communications channel for which the GSS-API security context
establishment tokens are intended, thus limiting the scope within
which an intercepted context establishment token can be reused by an
attacker (see [RFC-2743], section 1.1.6).
When using C language bindings, channel bindings are communicated
to the GSS-API using the following structure [RFC-2744]:
typedef struct gss_channel_bindings_struct {
OM_uint32 initiator_addrtype;
gss_buffer_desc initiator_address;
OM_uint32 acceptor_addrtype;
gss_buffer_desc acceptor_address;
gss_buffer_desc application_data;
} *gss_channel_bindings_t;
The member fields and constants used for different address types
are defined in [RFC-2744].
The "Bnd" field contains the MD5 hash of channel bindings, taken
over all non-null components of bindings, in order of declaration.
Integer fields within channel bindings are represented in little-
endian order for the purposes of the MD5 calculation.
In computing the contents of the Bnd field, the following detailed
points apply:
(1) For purposes of MD5 hash computation, each integer field and
input length field SHALL be formatted into four octets, using
little endian octet ordering.
(2) All input length fields within gss_buffer_desc elements of a
gss_channel_bindings_struct even those which are zero-valued, SHALL
be included in the hash calculation; the value elements of
gss_buffer_desc elements SHALL be dereferenced, and the resulting
data SHALL be included within the hash computation, only for the
case of gss_buffer_desc elements having non-zero length specifiers.
(3) If the caller passes the value GSS_C_NO_BINDINGS instead of a
valid channel binding structure, the Bnd field SHALL be set to 16
zero-valued octets.
Zhu 7
DRAFT Kerberos Version 5 GSS-API Expires August 2004
If the caller to GSS_Accept_sec_context [RFC-2743] passes in
GSS_C_NO_CHANNEL_BINDINGS [RFC-2744] as the channel bindings then
the acceptor MAY ignore any channel bindings supplied by the
initiator, returning success even if the initiator did pass in
channel bindings.
If the application supply, in the channel bindings, a buffer with a
length field larger than 4294967295 (2^32 - 1), the implementation
of this mechanism MAY chose to reject the channel bindings
altogether, using major status GSS_S_BAD_BINDINGS [RFC-2743]. In
any case, the size of channel binding data buffers that can be used
(interoperable, without extensions) with this specification is
limited to 4294967295 octets.
4.2. Per-Message Tokens
Two classes of tokens are defined in this section: "MIC" tokens,
emitted by calls to GSS_GetMIC() and consumed by calls to
GSS_VerifyMIC(), "Wrap" tokens, emitted by calls to GSS_Wrap() and
consumed by calls to GSS_Unwrap().
The new per-message tokens introduced here do not include the
generic GSS-API token framing used by the context establishment
tokens. These new tokens are designed to be used with newer crypto
systems that can, for example, have variable-size checksums.
4.2.1. Sequence Number
To distinguish intentionally-repeated messages from maliciously-
replayed ones, per-message tokens contain a sequence number field,
which is a 64 bit integer expressed in big endian order. After
sending a GSS_GetMIC() or GSS_Wrap() token, the sender's sequence
numbers SHALL be incremented by one.
4.2.2. Flags Field
The "Flags" field is a one-octet integer used to indicate a set of
attributes for the protected message. For example, one flag is
allocated as the direction-indicator, thus preventing an adversary
from sending back the same message in the reverse direction and
having it accepted.
The meanings of bits in this field (the least significant bit is
bit 0) are as follows:
Bit Name Description
---------------------------------------------------------------
0 SentByAcceptor When set, this flag indicates the sender
is the context acceptor. When not set,
it indicates the sender is the context
initiator.
1 Sealed When set in Wrap tokens, this flag
indicates confidentiality is provided
for. It SHALL NOT be set in MIC tokens.
2 AcceptorSubkey A subkey asserted by the context acceptor
Zhu 8
DRAFT Kerberos Version 5 GSS-API Expires August 2004
is used to protect the message.
The rest of available bits are reserved for future use and MUST be
cleared. The receiver MUST ignore unknown flags.
4.2.3. EC Field
The "EC" (Extra Count) field is a two-octet integer field expressed
in big endian order.
In Wrap tokens with confidentiality, the EC field SHALL be used to
encode the number of octets in the filler, as described in section
4.2.4.
In Wrap tokens without confidentiality, the EC field SHALL be used
to encode the number of octets in the trailing checksum, as
described in section 4.2.4.
4.2.4. Encryption and Checksum Operations
The encryption algorithms defined by the crypto profiles provide for
integrity protection [KCRYPTO]. Therefore no separate checksum is
needed.
The result of decryption can be longer than the original plaintext
[KCRYPTO] and the extra trailing octets are called "crypto-system
garbage" in this document. However, given the size of any plaintext
data, one can always find a (possibly larger) size so that, when
padding the to-be-encrypted text to that size, there will be no
crypto-system garbage added [KCRYPTO].
In Wrap tokens that provide for confidentiality, the first 16 octets
of the Wrap token (the "header", as defined in section 4.2.6), SHALL
be appended to the plaintext data before encryption. Filler octets
MAY be inserted between the plaintext data and the "header", and the
values and size of the filler octets are chosen by implementations,
such that there SHALL be no crypto-system garbage present after the
decryption. The resulting Wrap token is {"header" |
encrypt(plaintext-data | filler | "header")}, where encrypt() is the
encryption operation (which provides for integrity protection)
defined in the crypto profile [KCRYPTO], and the RRC field (as
defined in section 4.2.5) in the to-be-encrypted header contain the
hex value 00 00.
In Wrap tokens that do not provide for confidentiality, the checksum
SHALL be calculated first over the to-be-signed plaintext data, and
then the first 16 octets of the Wrap token (the "header", as defined
in section 4.2.6). Both the EC field and the RRC field in the token
header SHALL be filled with zeroes for the purpose of calculating
the checksum. The resulting Wrap token is {"header" | plaintext-
data | get_mic(plaintext-data | "header")}, where get_mic() is the
checksum operation for the required checksum mechanism of the chosen
encryption mechanism defined in the crypto profile [KCRYPTO].
Zhu 9
DRAFT Kerberos Version 5 GSS-API Expires August 2004
The parameters for the key and the cipher-state in the encrypt() and
get_mic() operations have been omitted for brevity.
For MIC tokens, the checksum SHALL be calculated as follows: the
checksum operation is calculated first over the to-be-signed
plaintext data, and then the first 16 octets of the MIC token, where
the checksum mechanism is the required checksum mechanism of the
chosen encryption mechanism defined in the crypto profile [KCRYPTO].
The resulting Wrap and MIC tokens bind the data to the token header,
including the sequence number and the direction indicator.
4.2.5. RRC Field
The "RRC" (Right Rotation Count) field in Wrap tokens is added to
allow the data to be encrypted in-place by existing SSPI (Security
Service Provider Interface) [SSPI] applications that do not provide
an additional buffer for the trailer (the cipher text after the in-
place-encrypted data) in addition to the buffer for the header (the
cipher text before the in-place-encrypted data). The resulting Wrap
token in the previous section, excluding the first 16 octets of the
token header, is rotated to the right by "RRC" octets. The net
result is that "RRC" octets of trailing octets are moved toward the
header. Consider the following as an example of this rotation
operation: Assume that the RRC value is 3 and the token before the
rotation is {"header" | aa | bb | cc | dd | ee | ff | gg | hh}, the
token after rotation would be {"header" | ff | gg | hh | aa | bb |
cc | dd | ee }, where {aa | bb | cc |...| hh} is used to indicate
the octet sequence.
The RRC field is expressed as a two-octet integer in big endian
order.
The rotation count value is chosen by the sender based on
implementation details, and the receiver MUST be able to interpret
all possible rotation count values, including rotation counts
greater than the length of the token.
4.2.6. Message Layouts
Per-message tokens start with a two-octet token identifier (TOK_ID)
field, expressed in big endian order. These tokens are defined
separately in subsequent sub-sections.
4.2.6.1. MIC Tokens
Use of the GSS_GetMIC() call yields a token (referred as the MIC
token in this document), separate from the user
data being protected, which can be used to verify the integrity of
that data as received. The token has the following format:
Octet no Name Description
-----------------------------------------------------------------
0..1 TOK_ID Identification field. Tokens emitted by
GSS_GetMIC() contain the hex value 04 04
Zhu 10
DRAFT Kerberos Version 5 GSS-API Expires August 2004
expressed in big endian order in this field.
2 Flags Attributes field, as described in section
4.2.2.
3..7 Filler Contains five octets of hex value FF.
8..15 SND_SEQ Sequence number field in clear text,
expressed in big endian order.
16..last SGN_CKSUM Checksum of the "to-be-signed" data and
octet 0..15, as described in section 4.2.4.
The Filler field is included in the checksum calculation for
simplicity.
4.2.6.2. Wrap Tokens
Use of the GSS_Wrap() call yields a token (referred as the Wrap
token in this document), which consists of a descriptive header,
followed by a body portion that contains either the input user data
in plaintext concatenated with the checksum, or the input user data
encrypted. The GSS_Wrap() token SHALL have the following format:
Octet no Name Description
---------------------------------------------------------------
0..1 TOK_ID Identification field. Tokens emitted by
GSS_Wrap() contain the the hex value 05 04
expressed in big endian order in this field.
2 Flags Attributes field, as described in section
4.2.2.
3 Filler Contains the hex value FF.
4..5 EC Contains the "extra count" field, in big
endian order as described in section 4.2.3.
6..7 RRC Contains the "right rotation count" in big
endian order, as described in section 4.2.5.
8..15 SND_SEQ Sequence number field in clear text,
expressed in big endian order.
16..last Data Encrypted data for Wrap tokens with
confidentiality, or plaintext data followed
by the checksum for Wrap tokens without
confidentiality, as described in section
4.2.4.
4.3. Context Deletion Tokens
Context deletion tokens are empty in this mechanism. Both peers to
a security context invoke GSS_Delete_sec_context() [RFC-2743]
independently, passing a null output_context_token buffer to
indicate that no context_token is required. Implementations of
GSS_Delete_sec_context() should delete relevant locally-stored
context information.
4.4. Token Identifier Assignment Considerations
Token identifiers (TOK_ID) from 0x60 0x00 through 0x60 0xFF
inclusive are reserved and SHALL NOT be assigned. Thus by examining
the first two octets of a token, one can tell unambiguously if it is
wrapped with the generic GSS-API token framing.
Zhu 11
DRAFT Kerberos Version 5 GSS-API Expires August 2004
5. Parameter Definitions
This section defines parameter values used by the Kerberos V5 GSS-
API mechanism. It defines interface elements in support of
portability, and assumes use of C language bindings per [RFC-2744].
5.1. Minor Status Codes
This section recommends common symbolic names for minor_status
values to be returned by the Kerberos V5 GSS-API mechanism. Use of
these definitions will enable independent implementers to enhance
application portability across different implementations of the
mechanism defined in this specification. (In all cases,
implementations of GSS_Display_status() will enable callers to
convert minor_status indicators to text representations.) Each
implementation should make available, through include files or other
means, a facility to translate these symbolic names into the
concrete values which a particular GSS-API implementation uses to
represent the minor_status values specified in this section.
It is recognized that this list may grow over time, and that the
need for additional minor_status codes specific to particular
implementations may arise. It is recommended, however, that
implementations should return a minor_status value as defined on a
mechanism-wide basis within this section when that code is
accurately representative of reportable status rather than using a
separate, implementation-defined code.
5.1.1. Non-Kerberos-specific codes
GSS_KRB5_S_G_BAD_SERVICE_NAME
/* "No @ in SERVICE-NAME name string" */
GSS_KRB5_S_G_BAD_STRING_UID
/* "STRING-UID-NAME contains nondigits" */
GSS_KRB5_S_G_NOUSER
/* "UID does not resolve to username" */
GSS_KRB5_S_G_VALIDATE_FAILED
/* "Validation error" */
GSS_KRB5_S_G_BUFFER_ALLOC
/* "Couldn't allocate gss_buffer_t data" */
GSS_KRB5_S_G_BAD_MSG_CTX
/* "Message context invalid" */
GSS_KRB5_S_G_WRONG_SIZE
/* "Buffer is the wrong size" */
GSS_KRB5_S_G_BAD_USAGE
/* "Credential usage type is unknown" */
GSS_KRB5_S_G_UNKNOWN_QOP
/* "Unknown quality of protection specified" */
5.1.2. Kerberos-specific-codes
GSS_KRB5_S_KG_CCACHE_NOMATCH
/* "Client principal in credentials does not match
specified name" */
Zhu 12
DRAFT Kerberos Version 5 GSS-API Expires August 2004
GSS_KRB5_S_KG_KEYTAB_NOMATCH
/* "No key available for specified service principal" */
GSS_KRB5_S_KG_TGT_MISSING
/* "No Kerberos ticket-granting ticket available" */
GSS_KRB5_S_KG_NO_SUBKEY
/* "Authenticator has no subkey" */
GSS_KRB5_S_KG_CONTEXT_ESTABLISHED
/* "Context is already fully established" */
GSS_KRB5_S_KG_BAD_SIGN_TYPE
/* "Unknown signature type in token" */
GSS_KRB5_S_KG_BAD_LENGTH
/* "Invalid field length in token" */
GSS_KRB5_S_KG_CTX_INCOMPLETE
/* "Attempt to use incomplete security context" */
5.2. Buffer Sizes
All implementations of this specification MUST be capable of
accepting buffers of at least 16K octets as input to GSS_GetMIC(),
GSS_VerifyMIC(), and GSS_Wrap(), and MUST be capable of accepting
the output_token generated by GSS_Wrap() for a 16K octet input
buffer as input to GSS_Unwrap(). Implementations SHOULD support 64K
octet input buffers, and MAY support even larger input buffer sizes.
6. Backwards Compatibility Considerations
The new token formats defined in this document will only be
recognized by new implementations. To address this, implementations
can always use the explicit sign or seal algorithm in [RFC-1964]
when the key type corresponds to "older" enctypes. An alternative
approach might be to retry sending the message with the sign or seal
algorithm explicitly defined as in [RFC-1964]. However this would
require either the use of a mechanism such as [RFC-2478] to securely
negotiate the method or the use out of band mechanism to choose
appropriate mechanism. For this reason, it is RECOMMENDED that the
new token formats defined in this document SHOULD be used only if
both peers are known to support the new mechanism during context
negotiation because of, for example, the use of "new" enctypes.
GSS_Unwrap() or GSS_VerifyMIC() can process a message token as
follows: it can look at the first octet of the token header, if it
is 0x60 then the token must carry the generic GSS-API pseudo ASN.1
framing, otherwise the first two octets of the token contain the
TOK_ID that uniquely identify the token message format.
7. Security Considerations
Channel bindings are validated by the acceptor. The acceptor can
ignore the channel bindings restriction supplied by the initiator
and carried in the authenticator checksum, if channel bindings are
not used by GSS_Accept_sec_context [RFC-2743], and the acceptor does
not prove to the initiator that it has the same channel bindings as
the initiator, even if the client requested mutual authentication.
This limitation should be taken into consideration by designers of
applications that would use channel bindings, whether to limit the
Zhu 13
DRAFT Kerberos Version 5 GSS-API Expires August 2004
use of GSS-API contexts to nodes with specific network addresses, to
authenticate other established, secure channels using Kerberos
Version 5, or for any other purpose.
Session key types are selected by the KDC. Under the current
mechanism, no negotiation of algorithm types occurs, so server-side
(acceptor) implementations cannot request that clients not use
algorithm types not understood by the server. However,
administrators can control what enctypes can be used for session
keys for this mechanism by controlling the set of the ticket session
key enctypes which the KDC is willing to use in tickets for a given
acceptor principal. The KDC could therefore be given the task of
limiting session keys for a given service to types actually
supported by the Kerberos and GSSAPI software on the server. This
does have a drawback for cases where a service principal name is
used both for GSSAPI-based and non-GSSAPI-based communication (most
notably the "host" service key), if the GSSAPI implementation does
not understand (for example) AES [AES-KRB5] but the Kerberos
implementation does. It means that AES session keys cannot be
issued for that service principal, which keeps the protection of
non-GSSAPI services weaker than necessary. KDC administrators
desiring to limit the session key types to support interoperability
with such GSSAPI implementations should carefully weigh the
reduction in protection offered by such mechanisms against the
benefits of interoperability.
8. Acknowledgments
Ken Raeburn and Nicolas Williams corrected many of our errors in the
use of generic profiles and were instrumental in the creation of
this document.
The text for security considerations was contributed by Nicolas
Williams and Ken Raeburn.
Sam Hartman and Ken Raeburn suggested the "floating trailer" idea,
namely the encoding of the RRC field.
Sam Hartman and Nicolas Williams recommended the replacing our
earlier key derivation function for directional keys with different
key usage numbers for each direction as well as retaining the
directional bit for maximum compatibility.
Paul Leach provided numerous suggestions and comments.
Scott Field, Richard Ward, Dan Simon, Kevin Damour, and Simon
Josefsson also provided valuable inputs on this document.
Jeffrey Hutzelman provided comments and clarifications for the text
related to the channel bindings.
Jeffrey Hutzelman and Russ Housley suggested many editorial changes.
Zhu 14
DRAFT Kerberos Version 5 GSS-API Expires August 2004
Luke Howard provided implementations of this document for the
Heimdal code base, and helped inter-operability testing with the
Microsoft code base, together with Love Hornquist Astrand. These
experiments formed the basis of this document.
Martin Rex provided suggestions of TOK_ID assignment recommendations
thus the token tagging in this document is unambiguous if the token
is wrapped with the pseudo ASN.1 header.
This document retains some of the text of RFC-1964 in relevant
sections.
9. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
10. References
10.1. Normative References
[RFC-2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC-2744] Wray, J., "Generic Security Service API Version 2: C-
bindings", RFC 2744, January 2000.
[RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, June 1996.
Zhu 15
DRAFT Kerberos Version 5 GSS-API Expires August 2004
[KCRYPTO] RFC-Editor: To be replaced by RFC number for draft-ietf-
krb-wg-crypto. Work in Progress.
[KRBCLAR] RFC-Editor: To be replaced by RFC number for draft-ietf-
krb-wg-kerberos-clarifications. Work in Progress.
10.2. Informative References
[SSPI] Leach, P., "Security Service Provider Interface", Microsoft
Developer Network (MSDN), April 2003.
[AES-KRB5] RFC-Editor: To be replaced by RFC number for draft-
raeburn-krb-rijndael-krb. Work in Progress.
[RFC-2478] Baize, E., Pinkas D., "The Simple and Protected GSS-API
Negotiation Mechanism", RFC 2478, December 1998.
11. Author's Address
Larry Zhu
One Microsoft Way
Redmond, WA 98052 - USA
EMail: LZhu@microsoft.com
Karthik Jaganathan
One Microsoft Way
Redmond, WA 98052 - USA
EMail: karthikj@microsoft.com
Sam Hartman
Massachusetts Institute of Technology
77 Massachusetts Avenue
Cambridge, MA 02139 - USA
Email: hartmans@MIT.EDU
Zhu 16
DRAFT Kerberos Version 5 GSS-API Expires August 2004
Full Copyright Statement
Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Zhu 17

8267
doc/standardisation/draft-ietf-krb-wg-kerberos-clarifications-05.txt Normal file
View File

File diff suppressed because it is too large Load Diff

638
doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-03.txt Normal file
View File

@@ -0,0 +1,638 @@
Kerberos Working Group Karthik
Jaganathan
Internet Draft Larry Zhu
Document: draft-ietf-krb-wg-kerberos-referrals-03.txt John Brezak
Category: Standards Track Microsoft
Mike Swift
University of
Washington
Jonathan Trostle
Cisco Systems
Expires: August
2004
Generating KDC Referrals to locate Kerberos realms
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
The draft documents a new method for a Kerberos Key Distribution
Center (KDC) to respond to client requests for kerberos tickets when
the client does not have detailed configuration information on the
realms of users or services. The KDC will handle requests for
principals in other realms by returning either a referral error or a
cross-realm TGT to another realm on the referral path. The clients
will use this referral information to reach the realm of the target
principal and then receive the ticket.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
Jaganathan Category - Standards Track 1
KDC Referrals August 2004
3. Introduction
Current implementations of the Kerberos AS and TGS protocols, as
defined in [3], use principal names constructed from a known user or
service name and realm. A service name is typically constructed from
a name of the service and the DNS host name of the computer that is
providing the service. Many existing deployments of Kerberos use a
single Kerberos realm where all users and services would be using
the same realm. However in an environment where there are multiple
trusted Kerberos realms, the client needs to be able to determine
what realm a particular user or service is in before making an AS or
TGS request. Traditionally this requires client configuration to
make this possible.
When having to deal with multiple trusted realms, users are forced
to know what realm they are in before they can obtain a ticket
granting ticket (TGT) with an AS request. However, in many cases the
user would like to use a more familiar name that is not directly
related to the realm of their Kerberos principal name. A good
example of this is an RFC-822 style email name. This document
describes a mechanism that would allow a user to specify a user
principal name that is an alias for the user's Kerberos principal
name. In practice this would be the name that the user specifies to
obtain a TGT from a Kerberos KDC. The user principal name no longer
has a direct relationship with the Kerberos principal or realm. Thus
the administrator is able to move the user's principal to other
realms without the user having to know that it happened.
Once a user has a TGT, they would like to be able to access services
in any trusted Kerberos realm. To do this requires that the client
be able to determine what realm the target service's host is in
before making the TGS request. Current implementations of Kerberos
typically have a table that maps DNS host names to corresponding
Kerberos realms. In order for this to work on the client, each
application canonicalizes the host name of the service by doing a
DNS lookup followed by a reverse lookup using the returned IP
address. The returned primary host name is then used in the
construction of the principal name for the target service. In order
for the correct realm to be added for the target host, the mapping
table [domain_to_realm] is consulted for the realm corresponding to
the DNS host name. The corresponding realm is then used to complete
the target service principal name.
This traditional mechanism requires that each client have very
detailed configuration information about the hosts that are
providing services and their corresponding realms. Having client
side configuration information can be very costly from an
administration point of view - especially if there are many realms
and computers in the environment.
There are also cases where specific DNS aliases (local names) have
been setup in an organization to refer to a server in another
organization (remote server). The server has different DNS names in
Jaganathan Category - Standards Track 2
KDC Referrals August 2004
each organization and each organization has a Kerberos realm that is
configured to service DNS names within that organization. Ideally
users are able to authenticate to the server in the other
organization using the local server name. This would mean that the
local realm be able to produce a ticket to the remote server under
its name. You could give that remote server an identity in the local
realm and then have that remote server maintain a separate secret
for each alias it is known as. Alternatively you could arrange to
have the local realm issue a referral to the remote realm and notify
the requesting client of the server's remote name that should be
used in order to request a ticket.
This draft proposes a solution for these problems and simplifies
administration by minimizing the configuration information needed on
each computer using Kerberos. Specifically it describes a mechanism
to allow the KDC to handle Canonicalization of names, provide for
principal aliases for users and services and provide a mechanism for
the KDC to determine the trusted realm authentication path by being
able to generate referrals to other realms in order to locate
principals.
To rectify these problems, this draft introduces three new kinds of
KDC referrals:
1. AS ticket referrals, in which the client doesn't know which realm
contains a user account.
2. TGS ticket referrals, in which the client doesn't know which
realm contains a server account.
3. Cross realm shortcut referrals, in which the KDC chooses the next
path on a referral chain
4. Realm Organization Model
This draft assumes that the world of principals is arranged on
multiple levels: the realm, the enterprise, and the world. A KDC may
issue tickets for any principal in its realm or cross-realm tickets
for realms with which it has a direct trust relationship. The KDC
also has access to a trusted name service that can resolve any name
from within its enterprise into a realm. This trusted name service
removes the need to use an untrusted DNS lookup for name resolution.
For example, consider the following configuration, where lines
indicate trust relationships:
MS.COM
/ \
/ \
OFFICE.MS.COM NT.MS.COM
In this configuration, all users in the MS.COM enterprise could have
a principal name such as alice@MS.COM, with the same realm portion.
In addition, servers at MS.COM should be able to have DNS host names
Jaganathan Category - Standards Track 3
KDC Referrals August 2004
from any DNS domain independent of what Kerberos realm their
principal resides in.
5. Client Name Canonicalization
A client account may have multiple principal names. More useful,
though, is a globally unique name that allows unification of email
and security principal names. For example, all users at MS may have
a client principal name of the form "joe@MS.COM" even though the
principals are contained in multiple realms. This global name is
again an alias for the true client principal name, which indicates
what realm contains the principal. Thus, accounts "alice" in the
realm NT.MS.COM and "bob" in OFFICE.MS.COM may logon as
"alice@MS.COM" and "bob@MS.COM".
This utilizes a new client principal name type, as the AS-REQ
message only contains a single realm field, and the realm portion of
this name doesn't correspond to any Kerberos realm. Thus, the entire
name "alice@MS.COM" is transmitted in the client name field of the
AS-REQ message, with a name type of KRB-NT-ENTERPRISE-PRINCIPAL.
KRB-NT-ENTERPRISE-PRINCIPAL 10
The KDC will recognize this name type and then transform the
requested name into the true principal name. The true principal name
can be using a name type different from the requested name type.
Typically the returned principal name will be a KRB-NT-PRINCIPAL.
The returned name will be the same in the AS response and in the
ticket. The KDC will always return a different name type than KRB-
NT-ENTERPRISE-PRINCIPAL. This is regardless of the presence of the
"canonicalize" KDC option.
If the "canonicalize" KDC option is set, then the KDC MAY change the
client principal name and type in the AS response and ticket
regardless of the name type of the client name in the request. For
example the AS request may specify a client name of "fred@MS.COM" as
an KRB-NT-PRINCIPAL with the "canonicalize" KDC option set and the
KDC will return with a client name of "104567" as a KRB-NT-UID.
6. Requesting a referral
In order to request referrals, the Kerberos client must explicitly
request the canonicalize KDC option (bit 15) in the KDC options for
the TGS-REQ. This flag indicates to the KDC that the client is
prepared to receive a reply that contains a principal name other
than the one requested. Thus, the KDCOptions types is redefined as:
KDCOptions ::= BIT STRING {
reserved(0),
forwardable(1),
forwarded(2),
proxiable(3),
proxy(4),
Jaganathan Category - Standards Track 4
KDC Referrals August 2004
allow-postdate(5),
postdated(6),
unused7(7),
renewable(8),
unused9(9),
unused10(10),
unused11(11),
canonicalize(15),
renewable-ok(27),
enc-tkt-in-skey(28),
renew(30),
validate(31)
}
The client should expect, when sending names with the "canonicalize"
KDC option, that names in the KDC's reply will be different than the
name in the request.
6.1 Client Referrals
The simplest form of ticket referral is for a user requesting a
ticket using an AS-REQ. In this case, the client machine will send
the AS request to a convenient trusted realm, either the realm of
the client machine or the realm of the client name. In the case of
the name Alice@MS.COM, the client may optimistically choose to send
the request to MS.COM. The realm in the AS request is always the
name of the realm that the request is for as specified in [3].
The client will send the string "alice@MS.COM" in the client
principal name field using the KRB-NT-ENTERPRISE-PRINCIPAL name type
with the crealm set to MS.COM. The KDC will try to lookup the name
in its local account database. If the account is present in the
realm of the request, it MUST return a KDC reply structure with the
appropriate ticket.
If the account is not present in the realm specified in the request
and the "canonicalize" KDC option is set, the KDC will try to lookup
the entire name, Alice@MS.COM, using a name service. If this lookup
is unsuccessful, it MUST return the error
KDC_ERR_C_PRINCIPAL_UNKNOWN. If the lookup is successful, it MUST
return an error KDC_ERR_WRONG_REALM (0x44) and in the error message
the crealm field will contain the the true realm of the client or
another realm that has better information about the client's true
realm. The client MUST NOT use a cname returned from a referral.
If the KDC contains the account locally and "canonicalize" KDC
option is not set, it MUST return a normal ticket. The client name
and realm portions of the ticket and KDC reply message MUST be the
client's true name in the realm, not the globally unique name.
If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
new AS request with the same client principal name used to generate
the first referral to the realm specified by the realm field of the
Jaganathan Category - Standards Track 5
KDC Referrals August 2004
kerberos error message from the first request. This request MUST
produce a valid AS response with a ticket for the canonical user
name.
An implementation should limit the number of referrals that it
processes to avoid infinite referral loops. A suggested limit is 5
referrals before giving up. In Microsoft<66>s implementation the
default limit is 3 since through the use of the global catalog any
domain in one forest is reachable from any other domain in another
trusting forest with 3 or less referrals.
6.2 Service Referrals
The primary problem is that the KDC must return a referral ticket
rather than an error message as is done in AS request referrals.
There needs to be a place to include in the TGS response information
about what realm contains the service. This is done by returning
information about the service name in the pre-auth data field of the
KDC reply.
If the KDC resolves the service principal name into a principal in
the realm specified by the service realm name, it will return a
normal ticket. When using canonicalization, the client can omit the
service realm name. If it is supplied, it is used as a hint by the
KDC, but the service principal lookup is not constrained to locating
the service principal name in that specified realm. If the
"canonicalize" flag in the KDC options is not set, then the KDC MUST
only look up the name as a normal principal name in the specified
service realm.
If the "canonicalize" flag in the KDC options is set and the KDC
doesn't find the principal locally, the KDC can return a cross-realm
ticket granting ticket to the next hop on the trust path towards a
realm that may be able to resolve the principal name.
If the KDC can determine the service principal's realm, it SHOULD
return the service realm as KDC supplied pre-authentication data
element. The preauth data MUST be encrypted using the sub-session
key from the authenticator if present or the session key from the
ticket.
The data itself is an ASN.1 encoded structure containing the
server's realm, and if known, the real principal name.
PA-SERVER-REFERRAL-INFO 25
PA-SERVER-REFERRAL :: = KERB-ENCRYPTED-DATA
-- PA-SERVER-REFERRAL-DATA
PA-SERVER-REFERRAL-DATA ::= SEQUENCE {
referred-server-realm[0] KERB-REALM
referred-name[1] PrincipalName OPTIONAL
...
Jaganathan Category - Standards Track 6
KDC Referrals August 2004
}
If applicable to the encryption type, the key derivation value will
for the PA-SERVER-REFERRAL is 22.
If the referred-name field is present, the client MUST use that name
in a subsequent TGS request to the service realm when following the
referral.
The client will use this information to request a chain of cross-
realm ticket granting tickets until it reaches the realm of the
service, and can then expect to receive a valid service ticket.
However an implementation should limit the number of referrals that
it processes to avoid infinite referral loops. A suggested limit is
5 referrals before giving up.
This is an example of a client requesting a service ticket for a
service in realm NT.MS.COM where the client is in OFFICE.MS.COM.
+NC = Canonicalize KDCOption set
+PA-REFERRAL = returned PA-SERVER-REFERRAL-INFO
C: TGS-REQ sname=server/foo.nt.ms.com srealm=NULL +NC to
OFFICE.MS.COM
S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL
containing NT.MS.COM
C: TGS-REQ sname=krbtgt/NT.MS.COM@MS.COM +NC to MS.COM
S: TGS-REP sname=krbtgt/NT.MS.COM@MS.COM
C: TGS-REQ sname=server/foo.nt.ms.com srealm=NT.MS.COM +NC to
NT.MS.COM
S: TGS-REP sname=server/foo.nt.ms.com@NT.MS.COM
Notice that the client only specifies the service name in the
initial and final TGS request.
7. Cross Realm Routing
The current Kerberos protocol requires the client to explicitly
request a cross-realm TGT for each pair of realms on a referral
chain. As a result, the client need to be aware of the trust
hierarchy and of any short-cut trusts (those that aren't parent-
child trusts). Instead, the client should be able to request a TGT
to the target realm from each realm on the route. The KDC will
determine the best path for the client and return a cross-realm TGT.
The client has to be aware that a request for a cross-realm TGT may
return a TGT for a realm different from the one requested.
For compatibility, the client MUST use the "canonicalize" KDC option
if it is able to use cross-realm routing from the KDC.
8. Compatibility with earlier implementations of name canonicalization
Jaganathan Category - Standards Track 7
KDC Referrals August 2004
The Microsoft Windows 2000 release included an earlier form of name-
canonicalization [4]. It has these differences:
1) The TGS referral data was returned inside of the KDC message as
"encrypted pre auth data".
KERB-ENCRYPTED-KDC-REPLY ::= SEQUENCE {
session-key[0] KERB-ENCRYPTION-KEY,
last-request[1] PKERB-LAST-REQUEST,
nonce[2] INTEGER,
key-expiration[3] KERB-TIME OPTIONAL,
flags[4] KERB-TICKET-FLAGS,
authtime[5] KERB-TIME,
starttime[6] KERB-TIME OPTIONAL,
endtime[7] KERB-TIME,
renew-until[8] KERB-TIME OPTIONAL,
server-realm[9] KERB-REALM,
server-name[10] KERB-PRINCIPAL-NAME,
client-addresses[11] PKERB-HOST-ADDRESSES
OPTIONAL,
encrypted-pa-data[12] SEQUENCE OF KERB-PA-DATA
OPTIONAL
}
2) The preauth data type definition in the encrypted preauth data is
as follows:
PA-SVR-REFERRAL-INFO 20
PA-SVR-REFERRAL-DATA ::= SEQUENCE {
referred-server-name[1] PrincipalName OPTIONAL
referred-server-realm[0] KERB-REALM
}
9. Security Considerations
In the case of TGS requests the client may be vulnerable to a denial
of service attack by an attacker that replays replies from previous
requests. The client can verify that the request was one of its own
by checking the client-address field or authtime field, though, so
the damage is limited and detectable. Clients MUST NOT process cross
realm referral TGTs if the KDC reply does not include the encrypted
PA-SERVER-REFERRAL-INFO.
For the AS exchange case, it is important that the logon mechanism
not trust a name that has not been used to authenticate the user.
For example, the name that the user enters as part of a logon
exchange may not be the name that the user authenticates as, given
that the KDC_ERR_WRONG_REALM error may have been returned. The
relevant Kerberos naming information for logon (if any), is the
Jaganathan Category - Standards Track 8
KDC Referrals August 2004
client name and client realm in the service ticket targeted at the
workstation that was obtained using the user's initial TGT.
How the client name and client realm is mapped into a local account
for logon is a local matter, but the client logon mechanism MUST use
additional information such as the client realm and/or authorization
attributes from the service ticket presented to the workstation by
the user, when mapping the logon credentials to a local account on
the workstation.
10. Acknowledgements
The authors wish to thank Ken Raeburn for his comments and
suggestions.
11.1 Normative References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
3 Neuman, C., Kohl, J., Ts'o, T., Yu, T., Hartman, S., and K.
Raeburn, "The Kerberos Network Authentication Service (V5)",
draft-ietf-krb-wg-kerberos-clarifications-00.txt, February 22,
2002. Work in progress.
11.2 Informative References
4 J. Trostle, I. Kosinovsky, and M. Swift,"Implementation of
Crossrealm Referral Handling in the MIT Kerberos Client", In
Network and Distributed System Security Symposium, February 2001.
12. Author's Addresses
Karthik Jaganathan
Microsoft
One Microsoft Way
Redmond, Washington
Email: karthikj@Microsoft.com
Larry Zhu
Microsoft
One Microsoft Way
Redmond, Washington
Email: lzhu@Microsoft.com
Michael Swift
University of Washington
Jaganathan Category - Standards Track 9
KDC Referrals August 2004
Seattle, Washington
Email: mikesw@cs.washington.edu
John Brezak
Microsoft
One Microsoft Way
Redmond, Washington
Email: jbrezak@Microsoft.com
Jonathan Trostle
Cisco Systems
170 W. Tasman Dr.
San Jose, CA 95134
Email: jtrostle@cisco.com
Jaganathan Category - Standards Track 10
KDC Referrals August 2004
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Jaganathan Category - Standards Track 11