< draft-zhu-pku2u-08.txt   draft-zhu-pku2u-09.txt >
NETWORK WORKING GROUP L. Zhu NETWORK WORKING GROUP L. Zhu
Internet-Draft Microsoft Corporation Internet-Draft Microsoft Corporation
Intended status: Standards Track J. Altman Intended status: Standards Track J. Altman
Expires: March 12, 2009 Secure Endpoints Expires: May 7, 2009 Secure Endpoints
N. Williams N. Williams
Sun Sun
September 8, 2008 November 3, 2008
Public Key Cryptography Based User-to-User Authentication - (PKU2U) Public Key Cryptography Based User-to-User Authentication - (PKU2U)
draft-zhu-pku2u-08 draft-zhu-pku2u-09
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 12, 2009. This Internet-Draft will expire on May 7, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document defines a Generic Security Services Application Program This document defines a Generic Security Services Application Program
Interface (GSS-API) mechanism based on Public Key Infrastructure Interface (GSS-API) mechanism based on Public Key Infrastructure
(PKI) - PKU2U. This mechanism is based on Kerberos V messages and the (PKI) - PKU2U. This mechanism is based on Kerberos V messages and the
Kerberos V GSS-API mechanism, but without requiring a Kerberos Key Kerberos V GSS-API mechanism, but without requiring a Kerberos Key
Distribution Center (KDC). Distribution Center (KDC).
Table of Contents Table of Contents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
3. The PKU2U Realm Name . . . . . . . . . . . . . . . . . . . . . 3 3. The PKU2U Realm Name . . . . . . . . . . . . . . . . . . . . . 3
4. The NULL Principal Name . . . . . . . . . . . . . . . . . . . 4 4. The NULL Principal Name . . . . . . . . . . . . . . . . . . . 4
5. PKU2U Principal Naming . . . . . . . . . . . . . . . . . . . . 4 5. PKU2U Principal Naming . . . . . . . . . . . . . . . . . . . . 4
5.1. GSS_C_NT_DN . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. GSS_C_NT_DN . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. GSS_C_NT_HOSTNAME . . . . . . . . . . . . . . . . . . . . 6 5.2. GSS_C_NT_HOSTNAME . . . . . . . . . . . . . . . . . . . . 6
5.3. GSS_C_NT_EMAIL_ADDR . . . . . . . . . . . . . . . . . . . 7 5.3. GSS_C_NT_EMAIL_ADDR . . . . . . . . . . . . . . . . . . . 7
5.4. GSS_KRB5_NT_PRINCIPAL_NAME . . . . . . . . . . . . . . . . 7 5.4. GSS_KRB5_NT_PRINCIPAL_NAME . . . . . . . . . . . . . . . . 7
5.5. GSS_C_NT_ANONYMOUS . . . . . . . . . . . . . . . . . . . . 9 5.5. GSS_C_NT_ANONYMOUS . . . . . . . . . . . . . . . . . . . . 9
5.6. GSS_C_NT_HOSTBASED_SERVICE - Matching Host-based 5.6. GSS_C_NT_HOSTBASED_SERVICE - Matching Host-based
Principal Names to Acceptor Certificates . . . . . . . . . 9 Principal Names to Acceptor Certificates . . . . . . . . . 9
5.7. Unspecified Target Names . . . . . . . . . . . . . . . . . 10
6. The Protocol Description and the Context Establishment 6. The Protocol Description and the Context Establishment
Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Context Token Derived from KRB-AS-REQ . . . . . . . . . . 12 6.1. Context Token Derived from KRB_AS_REQ . . . . . . . . . . 12
6.2. Context Token Derived from KRB-AS-REP . . . . . . . . . . 15 6.2. Context Token Derived from KRB_AS_REP . . . . . . . . . . 15
6.3. Context Tokens Imported from RFC4121 . . . . . . . . . . . 17 6.3. Context Tokens Imported from RFC4121 . . . . . . . . . . . 16
6.4. Authorization-Data Type to Aid Acceptor Implementors . . . 18 7. Guidelines for Credentials Selection . . . . . . . . . . . . . 17
6.5. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. Guidelines for Credentials Selection . . . . . . . . . . . . . 20 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 11. Normative References . . . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
11. Normative References . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 25
1. Introduction 1. Introduction
The Generic Security Services Application Programming Interface (GSS- The Generic Security Services Application Programming Interface (GSS-
API) is a generic protocol and API for providing authentication and API) is a generic protocol and API for providing authentication and
session protection to applications. It is generic in that it session protection to applications. It is generic in that it
supports multiple authentication mechanisms. Today there exists only supports multiple authentication mechanisms. Today there exists only
one workable, widely deployed, standards-track GSS-API mechanism: the one workable, widely deployed, standards-track GSS-API mechanism: the
Kerberos V GSS-API mechanism [RFC1964] [RFC4121], which is based on Kerberos V GSS-API mechanism [RFC1964] [RFC4121], which is based on
Kerberos V [RFC4120]. There is a need to provide a GSS-API mechanism Kerberos V [RFC4120]. There is a need to provide a GSS-API mechanism
skipping to change at page 3, line 49 skipping to change at page 3, line 49
In this document, the GSS-API initiator or acceptor is referred to as In this document, the GSS-API initiator or acceptor is referred to as
the peer when the description is applicable to both the initiator and the peer when the description is applicable to both the initiator and
the acceptor. the acceptor.
3. The PKU2U Realm Name 3. The PKU2U Realm Name
The PKU2U realm name is defined as a reserved Kerberos realm name per The PKU2U realm name is defined as a reserved Kerberos realm name per
[KRB-NAMING], and it has the value of "WELLKNOWN:PKU2U". [KRB-NAMING], and it has the value of "WELLKNOWN:PKU2U".
The PKU2U realm name has no meaning, but is intended to be used in The PKU2U realm name has no meaning, but is intended to be used in
the Kebreros V PDUs that are re-used by PKU2U wherever realm names the Kebreros V Protocol Data Units (PDUs) that are re-used by PKU2U
are needed. Unless otherwise specified, the realm name in any wherever realm names are needed. Unless otherwise specified, the
Kerberos message used by PKU2U is the PKU2U realm name. realm name in any Kerberos message used by PKU2U is the PKU2U realm
name.
4. The NULL Principal Name 4. The NULL Principal Name
The NULL Kerberos principal name is defined as a well-known Kerberos The NULL Kerberos principal name is defined as a well-known Kerberos
principal name based on [KRB-NAMING]. The value of the name-type principal name based on [KRB-NAMING]. The value of the name-type
field is KRB_NT_WELLKNOWN [KRB-NAMING], and the value of the name- field is KRB_NT_WELLKNOWN [KRB-NAMING], and the value of the name-
string field is a sequence of two KerberosString components: string field is a sequence of two KerberosString components:
"WELLKNOWN", "NULL". "WELLKNOWN", "NULL".
The NULL Kerberos principal name is used in the Kerberos messages The NULL Kerberos principal name is used in the Kerberos messages
where there is no Kerberos representation of the principal name, for where there is no Kerberos representation of the principal name, for
example, when the client name is a Distinguished Name. When the NULL example, when the client name is a Distinguished Name. When the NULL
principal name is used in the Kerberos messages, the principal name principal name is used in the Kerberos messages, the principal name
is either not used or provided separately (for example in the PA- is either not used or provided separately (for example in the
PKU2U-NAME padata defined in Section 6.1). PA_PKU2U_NAME padata defined in Section 6.1).
5. PKU2U Principal Naming 5. PKU2U Principal Naming
The GSS-API targ_name supplied for the initiator MUST NOT be
GSS_C_NO_NAME in PKU2U.
PKU2U principal names can be Kerberos principal names, and they can PKU2U principal names can be Kerberos principal names, and they can
also be distiguished names, or subject alternative names [RFC5280] as also be distiguished names, or subject alternative names [RFC5280] as
they appear in the certificate of any PKU2U peer, as well as any they appear in the certificate of any PKU2U peer, as well as any
names agreed to out of band that do not appear in the peer names agreed to out of band that do not appear in the peer
certificates. certificates.
Certificates may be associated with multiple principal names. This Certificates may be associated with multiple principal names. This
presents problems for the GSS-API bindings of a PKI-based mechanism presents problems for the GSS-API bindings of a PKI-based mechanism
because, for example, for any given, established GSS-API security because, for example, for any given, established GSS-API security
mechanism there can be only one initiator name, and one acceptor mechanism there can be only one initiator name, and one acceptor
name, and credential handles may be associated with only one name. name, and credential handles may be associated with only one name.
We resolve these problems as follows: We resolve these problems as follows:
o We define multiple GSS-API name types corresponding to several o We define multiple GSS-API name types corresponding to several
GeneralName choices [RFC5280], along with syntaxes, display forms, GeneralName choices [RFC5280], along with syntaxes, display forms,
and exported name token formats for each. For most of the name- and exported name token formats for each. For most of the name-
types listed below the exported name token formats consists of a types listed below the exported name token formats consists of a
DER-encoded GeneralName with the usual exported name token header GeneralName with the usual exported name token header as per-
as per-RFC2743. Two name-types are shared with the Kerberos V RFC2743. Two name-types are shared with the Kerberos V mechanism
mechanism and use the Kerberos V mechanism's query and display and use the Kerberos V mechanism's query and display syntaxes,
syntaxes, canonicalization rules, and exported name token format. canonicalization rules, and exported name token format.
o The cred_name of a credential handle acquired with o The cred_name of a credential handle acquired with
GSS_C_NT_NO_NAME as the desired_name SHOULD be the DN of the GSS_C_NT_NO_NAME as the desired_name SHOULD be the Distinguished
certificate underlying the credential. If there are multiple Name (DN) of the certificate underlying the credential. If there
certificates and private keys, then either one MUST be selected as are multiple certificates and private keys, then either one MUST
the default credential by local, implementation-specific means, or be selected by local, implementation-specific means, or credential
credential acquisition with GSS_C_NT_NO_NAME MUST fail acquisition with GSS_C_NT_NO_NAME MUST fail (implementers may
(implementors may choose which of these two behaviors to provide). choose which of these two behaviors to provide).
o When using desired_name values other than GSS_C_NT_NO_NAME for o When using desired_name values other than GSS_C_NT_NO_NAME for
credential handle acquisition then the implementation MUST use credential handle acquisition then the implementation MUST use
exact matching of the given desired_name to a certificate's DN or exact matching of the given desired_name to a certificate's DN or
SANs for all name-types given below, except for GSS_C_NT_DN, where Subject Alternative Names (SANs) for all name-types given below,
matching rules are fuzzier and given below. The names of a cert except for GSS_C_NT_DN, where matching rules are fuzzier and given
will be compared to the given desired_name in this order: below. The names of a X.509 certificate will be compared to the
certificate DN first, then subjectAlternativeNames in the order in given desired_name in this order: certificate DN first, then SANs
which they appear in the certificate. When multiple certificates in the order in which they appear in the certificate. When
and private keys are available the order in which the various multiple certificates and private keys are available the order in
certificates are searched is significant; no canonical certificate which the various certificates are searched is significant; no
collation order is defined herein. canonical certificate collation order is defined herein.
o The cred_name of a credential object acquired with a desired_name o The cred_name of a credential object acquired with a desired_name
other than GSS_C_NT_NO_NAME MUST be equal to the certificate DN or other than GSS_C_NT_NO_NAME MUST be equal to the certificate DN or
SAN matched by the given desired_name. SAN matched by the given desired_name.
o We provide a method (see below) by which initiators can assert, in o We provide a method (see below) by which initiators can assert, in
their context tokens, one of these names of the initiator. We their context tokens, one of these names of the initiator. We
also provide a method of asserting names that do not appear in a also provide a method of asserting names that do not appear in a
X.509 certificate, in which case the binding of X.509 certificate X.509 certificate, in which case the binding of X.509 certificate
to the asserted name is done out-of band. The name to be to the asserted name is done out-of band. The name to be
asserted, of course, is the cred_name of the cred_handle passed to asserted, of course, is the cred_name of the cred_handle passed to
GSS_Init_sec_context(). GSS_Init_sec_context().
o The initiator's context tokens may also indicate what is the o The initiator's context tokens may also indicate what is the
expected name of the acceptor -- the targ_name passed in to expected name of the acceptor -- the targ_name passed in to
GSS_Init_sec_context(). GSS_Init_sec_context().
o We provide support for targ_name = GSS_C_NO_NAME in
GSS_Init_sec_context(). In this case the resulting security
context's acceptor's name will be the DN of its certificate.
o No attempt is made to map Kerberos V realm names to trust anchor o No attempt is made to map Kerberos V realm names to trust anchor
certificate authority (CA) names. certificate authority (CA) names.
o We provide a method of matching host-based service principal names o We provide a method of matching host-based service principal names
to acceptor certificates, so that: a) initiators need not know the to acceptor certificates, so that: a) initiators need not know the
particulars of an acceptor's certificates' names a priori, b) particulars of an acceptor's certificates' names a priori, b)
acceptors can select a credential to accept a security context acceptors can select a credential to accept a security context
with that the initiator will accept, c) existing certificates for with that the initiator will accept, c) existing certificates for
web servers, may be used as host-based service principal names as web servers, may be used as host-based service principal names as
though the service name were "HTTP". though the service name were "HTTP".
skipping to change at page 6, line 18 skipping to change at page 6, line 19
And portable GSS-API initiator applications using And portable GSS-API initiator applications using
GSS_C_NT_HOSTBASED_SERVICE for naming acceptors (i.e., for importing GSS_C_NT_HOSTBASED_SERVICE for naming acceptors (i.e., for importing
a name to use as the targ_name input argument of a name to use as the targ_name input argument of
GSS_Init_sec_context()) will have a reasonable chance of success in GSS_Init_sec_context()) will have a reasonable chance of success in
authenticating peers with X.509 certificates predating this authenticating peers with X.509 certificates predating this
specification. specification.
5.1. GSS_C_NT_DN 5.1. GSS_C_NT_DN
The name type GSS_C_NT_DN, with OID <TBD> (see Section 10), is The name type GSS_C_NT_DN, with Object Identifier (OID) <TBD> (see
defined. This corresponds to the 'directoryName' choice of the Section 10), is defined. This corresponds to the 'directoryName'
'GeneralName' ASN.1 [CCITT.X680.2002] type defined in [RFC5280]. choice of the 'GeneralName' Abstract Syntax Notation One (ASN.1)
[CCITT.X680.2002] type defined in [RFC5280].
The query syntax and display form for names of this type SHALL be as The query syntax and display form for names of this type SHALL be as
described in [RFC4514]. described in [RFC4514].
As RFC4514 says, "[c]omparison of DNs for equality is to be performed As RFC4514 says, "[c]omparison of DNs for equality is to be performed
in accordance with the distinguishedNameMatch matching rule in accordance with the distinguishedNameMatch matching rule
[RFC4517]. [RFC4517]".
There is no reasonable way to canonicalize names of this type without There is no reasonable way to canonicalize names of this type without
providing certificates to match query forms of GSS_C_NT_DN against, providing certificates to match query forms of GSS_C_NT_DN against,
such as in the form of a directory. Therefore such as in the form of a directory. Therefore
GSS_Canonicalize_name() as applied to names imported with the GSS_Canonicalize_name() as applied to names imported with the
GSS_C_NT_DN name-type MUST search available certificate databases, or GSS_C_NT_DN name-type MUST search available certificate databases, or
directories, or MUST fail. No method of locating and searching directories, or MUST fail. No method of locating and searching
directories for matching certificate DNs is specified herein. Note directories for matching certificate DNs is specified herein. Note
though that GSS_Inquire_cred_by_mech() and GSS_Inquire_sec_context() though that GSS_Inquire_cred_by_mech() and GSS_Inquire_sec_context()
can and, indeed, MUST return "mechanism names" (MN; ; see [RFC2743]). can and, indeed, MUST return "mechanism names" (MN) (see [RFC2743]).
The exported name token format for names of this type SHALL be the The exported name token format for names of this type SHALL be the
DER [CCITT.X680.2002] [CCITT.X690.2002] encoding of a GeneralName Distinguished Encoding Rules (DER) [CCITT.X680.2002]
with directoryName as the choice. [CCITT.X690.2002] encoding of a GeneralName with directoryName as the
choice.
Implementation support for this name type is REQUIRED. Implementation support for this name type is REQUIRED.
5.2. GSS_C_NT_HOSTNAME 5.2. GSS_C_NT_HOSTNAME
The name type GSS_C_NT_HOSTNAME, with OID <TBD>, is defined. This The name type GSS_C_NT_HOSTNAME, with OID <TBD>, is defined. This
corresponds to the 'dNSName' choice of the 'GeneralName' ASN.1 type corresponds to the 'dNSName' choice of the 'GeneralName' ASN.1 type
defined in [RFC5280]. defined in [RFC5280].
The query syntax for names of this type SHALL be a DNS name [RFC1034] The query syntax for names of this type SHALL be a DNS name [RFC1034]
in either ACE or Unicode form [RFC3490]. in either ACE or Unicode form [RFC3490].
The display and canonical form of names of this type SHALL be a DNS The display and canonical form of names of this type SHALL be a DNS
domainname in ACE form, with character case folded down. domain name in ACE form, with character case folded down.
Canonicalization consists merely of applying the toACE() function and Canonicalization consists merely of applying the ToASCII() function
case-folding the result. and case-folding the result.
The exported name token format for names of this type SHALL be the The exported name token format for names of this type SHALL be the
DER encoding of a GeneralName with dNSName as the choice and the DNS DER encoding of a GeneralName with dNSName as the choice and the DNS
domainname in ACE form and case folded down. domain name in ACE form and case folded down.
Implementation support for this name type is OPTIONAL. Implementation support for this name type is OPTIONAL.
5.3. GSS_C_NT_EMAIL_ADDR 5.3. GSS_C_NT_EMAIL_ADDR
The name type GSS_C_NT_EMAIL_ADDR, with OID <TBD>, is defined. This The name type GSS_C_NT_EMAIL_ADDR, with OID <TBD>, is defined. This
corresponds to the 'rfc822Name' choice of the 'GeneralName' ASN.1 corresponds to the 'rfc822Name' choice of the 'GeneralName' ASN.1
type defined in [RFC5280]. type defined in [RFC5280].
The query syntax and display form for names of this type SHALL be the The query syntax and display form for names of this type SHALL be the
text representation of an 'addr-spec' as defined in [RFC0822]. text representation of an 'addr-spec' as defined in [RFC0822].
The canonical form of names of this type SHALL be the query form with The canonical form of names of this type SHALL be the query form with
case folded down. Note that the domainname part of an addr-spec is a case folded down. Note that the domain name part of an addr-spec is
"domainname slot" and so the canonicalization rules for a "domain name slot" and so the canonicalization rules for
GSS_C_NT_HOSTNAME given above apply here as well. GSS_C_NT_HOSTNAME given above apply here as well.
The exported name token form for this name type SHALL be the DER- The exported name token form for this name type SHALL be the DER-
encoding of a GeneralName with the rfc822Name choice. encoding of a GeneralName with the rfc822Name choice.
Implementation support for this name type is OPTIONAL. Implementation support for this name type is OPTIONAL.
5.4. GSS_KRB5_NT_PRINCIPAL_NAME 5.4. GSS_KRB5_NT_PRINCIPAL_NAME
PKU2U supports the use of GSS_KRB5_NT_PRINCIPAL_NAME names [RFC1964]. PKU2U supports the use of GSS_KRB5_NT_PRINCIPAL_NAME names [RFC1964].
The query, display, canonical and exported name token forms of names The query, display, canonical and exported name token forms of names
of this type SHALL be as specified in RFC4121. The realm name part of this type SHALL be as specified in RFC4121. The realm name part
of GSS_KRB5_NT_PRINCIPAL_NAME names is optional for the query syntax; of GSS_KRB5_NT_PRINCIPAL_NAME names is optional for the query syntax;
when canonicalized, names of this type lacking a realm name will have when canonicalized, names of this type lacking a realm name will have
the well-known PKU2U realm name affixed. the well-known PKU2U realm name affixed.
When the realm name of a GSS_KRB5_NT_PRINCIPAL_NAME NAME is defaulted When the realm name of a GSS_KRB5_NT_PRINCIPAL_NAME NAME is defaulted
or otherwise is the well-known PKU2U realm name, then the ''cname'' or otherwise is the well-known PKU2U realm name, then the "cname"' or
or sname fields of the Kerberos V PDUs used to construct PKU2U sname fields of the Kerberos V PDUs used to construct PKU2U security
security context tokens MUST be set to the principal name part of the context tokens MUST be set to the principal name part of the given
given NAME. Otherwise the PA-PKU2U-NAME pre-authentication data MUST NAME. Otherwise the PA_PKU2U_NAME pre-authentication data MUST be
be used to indicate a name of id-pkinit-san type [RFC4556] used to indicate a name of id-pkinit-san type [RFC4556] corresponding
corresponding to the given NAME. See Section 5.4. to the given NAME. See Section 5.4.
No attempt is made to map Kerberos V realm names to trust anchor No attempt is made to map Kerberos V realm names to trust anchor
certificate authority (CA) names. certificate authority (CA) names.
Note that having more than one mechanism share name-types has Note that having more than one mechanism share name-types has
implications for multi-mechanism, pluggable GSS-API implementations implications for multi-mechanism, pluggable GSS-API implementations
(commonly referred to as "mechglue"). Specifically: (commonly referred to as "mechglue"). Specifically:
o It must be the responsibility of the mechanism, not of the o It must be the responsibility of the mechanism, not of the
mechglue, to ensure that the standard exported name token header mechglue, to ensure that the standard exported name token header
(which includes a mechanism OID), is included in exported name (which includes a mechanism OID), is included in exported name
tokens. Otherwise the exported name token for a tokens. The exported name token for a GSS_KRB5_NT_PRINCIPAL_NAME
GSS_KRB5_NT_PRINCIPAL_NAME MN produced by PKU2U would have PKU2U's MN produced by PKU2U would have PKU2U's mechanism OID in the
mechanism OID in the header, instead of the Kerberos V mechanism's header.
OID.
o A pluggable mechglue must be able to find a mechanism that can o A pluggable mechglue must be able to find a mechanism that can
import an exported name token if an available mechanism can import an exported name token if an available mechanism can
produce that exported name token. For example, a pluggable produce that exported name token. For example, a pluggable
mechglue where PKU2U is available but where the Kerberos V mechglue where PKU2U is available but where the Kerberos V
mechanism [RFC1964] is not should still be able to import exported mechanism [RFC1964] is not should still be able to import exported
Kerberos V name tokens since PKU2U can create such tokens. One Kerberos V name tokens since PKU2U can create such tokens. One
way to do this would be for the mechglue to try the mechanism way to do this would be for the mechglue to try the mechanism
named in the exported name token header, if it is available, else named in the exported name token header, if it is available, else
try all other available mechanisms until one succeeds or all fail. try all other available mechanisms until one succeeds or all fail.
It would be reasonable for a mechglue implementor to require that It would be reasonable for a mechglue implementer to require that
the Kerberos V mechanism be available if PKU2U is too. the Kerberos V mechanism be available if PKU2U is too.
o It must be possible for GSS_Acquire_cred(), GSS_Add_cred() to use o It must be possible for GSS_Acquire_cred(), GSS_Add_cred() to use
a Kerberos V "mechanism name" (MN; see [RFC2743]) as desired_name a Kerberos V "mechanism name" (MN; see [RFC2743]) as desired_name
argument value to acquire a PKU2U credential. Similarly, it must argument value to acquire a PKU2U credential. Similarly, it must
be possible to use a Kerberos V MN as the target_name in a call to be possible to use a Kerberos V MN as the target_name in a call to
GSS_Init_sec_context with PKU2U as the mech OID. A multi- GSS_Init_sec_context with PKU2U as the mech OID. A multi-
mechanism mechglue implementor would likely have a mechglue-layer mechanism mechglue implementer would likely have a mechglue-layer
NAME object that internally keeps a reference to a NAME object NAME object that internally keeps a reference to a NAME object
produced by the underlying mechanism, but a pluggable mechglue produced by the underlying mechanism, but a pluggable mechglue
could not expect two different mechanisms to be able to share could not expect two different mechanisms to be able to share
their internal NAME objects. A clever implementor can work around their internal NAME objects. A clever implementer can work around
this by exporting the one mechanism's MN and then re-importing this by exporting the one mechanism's MN and then re-importing
using the target mechanism's GSS_Import_name() service function. using the target mechanism's GSS_Import_name() service function.
o It must be possible for the credential inquiry functions (e.g., o It must be possible for the credential inquiry functions (e.g.,
GSS_Inquire_cred() and GSS_Inquire_cred_by_mech()) to return a GSS_Inquire_cred() and GSS_Inquire_cred_by_mech()) to return a
cred_name that is an MN of a different mechanism than the cred_name that is an MN of a different mechanism than the
credential element being inquired. credential element being inquired.
Implementation support for this name type, with defaulted realm name Implementation support for this name type, with defaulted realm name
or with the PKU2U realm name is REQUIRED, but it is OPTIONAL for use or with the PKU2U realm name is REQUIRED, but it is OPTIONAL for use
with any other realm names. with any other realm names.
5.5. GSS_C_NT_ANONYMOUS 5.5. GSS_C_NT_ANONYMOUS
skipping to change at page 10, line 21 skipping to change at page 10, line 25
4. Implementations SHOULD, subject to local configuration, allow 4. Implementations SHOULD, subject to local configuration, allow
matches where the single-component cn of the DN of a X.509 matches where the single-component cn of the DN of a X.509
certificate matches the hostname part of the host-based service certificate matches the hostname part of the host-based service
name, for some or all service names. This feature is needed to name, for some or all service names. This feature is needed to
allow the use of existing X.509 web certificates. allow the use of existing X.509 web certificates.
Implementation support for this name type as an acceptor name is Implementation support for this name type as an acceptor name is
REQUIRED. Implementation support for this name type as an initiator REQUIRED. Implementation support for this name type as an initiator
name is OPTIONAL. name is OPTIONAL.
5.7. Unspecified Target Names
When the initiator uses GSS_C_NO_NAME as the target name then it MUST
use the NULL name (see Section 4). See Section 6.1 for information
on naming padata in this case.
The acceptor name associated with the resulting security context MUST
be the DN of the acceptor's certificate.
6. The Protocol Description and the Context Establishment Tokens 6. The Protocol Description and the Context Establishment Tokens
The PKU2U mechanism is a GSS-API mechanism based on [RFC4120], The PKU2U mechanism is a GSS-API mechanism based on [RFC4120],
[RFC4556] and [RFC4121]. [RFC4556] and [RFC4121].
The per-message tokens of the PKU2U mechanism are the same as those The per-message tokens of the PKU2U mechanism are the same as those
of the Kerberos V GSS-API mechanism [RFC4121]. of the Kerberos V GSS-API mechanism [RFC4121].
The GSS_Pseudo_random() function [RFC4401] of the PKU2U is the same The GSS_Pseudo_random() function [RFC4401] of the PKU2U is the same
as that of the Kerberos V GSS-API mechanism [RFC4402]. as that of the Kerberos V GSS-API mechanism [RFC4402].
The PKU2U security context token exchange consists of KRB-AS-REQ and The PKU2U security context token exchange consists of KRB_AS_REQ and
KRB-AS-REP (and KRB-ERROR) Kerberos KDC PDUs (with no changes to KRB_AS_REP (and KRB_ERROR) Kerberos KDC PDUs (with no changes to
their ASN.1 description, but with other minor changes/requirements their ASN.1 description, but with other minor changes/requirements
described below) as context tokens, with the acceptor as the KDC, described below) as context tokens, with the acceptor as the KDC,
followed by context tokens from [RFC4121] using the Kerberos V Ticket followed by context tokens from [RFC4121] using the Kerberos V Ticket
PDU issued by the acceptor-as-KDC. PKINIT [RFC4556] is the only PDU issued by the acceptor-as-KDC. PKINIT [RFC4556] is the only
acceptable pre-authentication method in this document. Caching the acceptable pre-authentication method in this document. Caching the
ticket issued by the acceptor allows subsequent security context ticket issued by the acceptor allows subsequent security context
exchanges between the same to peers to use a single context token exchanges between the same to peers to use a single context token
round-trip -- a "fast reconnect" feature. round-trip -- a "fast reconnect" feature.
PKU2U differs from Kerberos V with PKINIT in several minor ways as PKU2U differs from Kerberos V with PKINIT in several minor ways as
skipping to change at page 12, line 18 skipping to change at page 12, line 18
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2) { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
pku2u(7) } pku2u(7) }
All context establishment tokens consist of some Kerberos V PDU or All context establishment tokens consist of some Kerberos V PDU or
another, prefixed with a two-octet token type ID, and the another, prefixed with a two-octet token type ID, and the
InitialContextToken header (see above). InitialContextToken header (see above).
The innerToken described in section 3.1 of [RFC2743] and subsequent The innerToken described in section 3.1 of [RFC2743] and subsequent
GSS-API mechanism tokens have the following formats: it starts with a GSS-API mechanism tokens have the following formats: it starts with a
two-octet token-identifier (TOK_ID), followed by a Kerberos message. two-octet token-identifier (TOK_ID), followed by a Kerberos message.
The TOK_ID values for the KRB-AS-REQ message and the KRB-AS-REP The TOK_ID values for the AS-REQ message and the AS-REP message are
message are defined in the table blow: defined in the table blow:
Token TOK_ID Value in Hex Token TOK_ID Value in Hex
----------------------------------------------- -----------------------------------------------
KRB_AS_REQ 05 00 KRB_AS_REQ 05 00
KRB_AS_REP 06 00 KRB_AS_REP 06 00
The TOK_ID values for all other Kerberos messages are the same as The TOK_ID values for all other Kerberos messages are the same as
defined in [RFC4121]. defined in [RFC4121].
It should be noted that by using anonymous PKINIT [KRB-ANON], PKU2U It should be noted that by using anonymous PKINIT [KRB-ANON], PKU2U
can authenticate the acceptor without revealing the initiator's can authenticate the acceptor without revealing the initiator's
identity identity
6.1. Context Token Derived from KRB-AS-REQ 6.1. Context Token Derived from KRB_AS_REQ
When the initiator does not have a service ticket to the acceptor, it When the initiator does not have a service ticket to the acceptor, it
requests a ticket from the acceptor instead of from the KDC by requests a ticket from the acceptor instead of from the KDC by
constructing a KRB-AS-REQ PDU [RFC4120] and using it as the context constructing a KRB_AS_REQ PDU [RFC4120] and using it as the context
token, with a token type ID prefixed. This will be the initiator's token, with a token type ID prefixed. This will be the initiator's
initial context token, therefore it MUST also have the standard initial context token, therefore it MUST also have the standard
header bearing the OID of the mechanism being used (in this case, header bearing the OID of the mechanism being used (in this case,
PKU2U's OID). PKU2U's OID).
The initiator MUST NOT set any KDC options in the 'kdc-options' field The initiator MUST NOT set any KDC options in the 'kdc-options' field
of the AS-REQ. of the AS-REQ.
The 'from', 'rtime', 'addresses', 'enc-authorization-data', and
'additional-tickets' fields of the AS-REQ MUST be absent.
The 'till' field of the AS-REQ MUST be set to either
"19700101000000Z" (see [RFC4120], section 5.4.1), or
"19700101000001Z". The latter indicates that the initiator would
like a ticket valid for a single use.
The 'realm' field of the AS-REQ MUST be set to the PKU2U well-known The 'realm' field of the AS-REQ MUST be set to the PKU2U well-known
PKU2U realm name ("WELLKNOWN:PKU2U" [KRB-NAMING]. PKU2U realm name ("WELLKNOWN:PKU2U" [KRB-NAMING].
If the initiator wishes to assert a name of type GSS_C_NT_ANONYMOUS If the initiator wishes to assert a name of type
then it MUST set the AS-REQ's 'cname' field to the anonymous
principal name [KRB-ANON], and it MUST NOT use a X.509 certificate
[KRB-ANON]. If the initiator wishes to assert a name of type
GSS_KRB5_NT_PRINCIPAL_NAME or GSS_C_NT_HOSTBASED_SERVICE, then it GSS_KRB5_NT_PRINCIPAL_NAME or GSS_C_NT_HOSTBASED_SERVICE, then it
MUST set the 'cname' field of the AS-REQ accordingly if and only if MUST set the 'cname' field of the AS-REQ accordingly if and only if
the realm name part of the given name object is defaulted or the the realm name part of the given name object is defaulted or the
well-known PKU2U realm name. Otherwise the initiator MUST add a pa- well-known PKU2U realm name. Otherwise the initiator MUST add a pa-
data element (see below) stating the name that the initiator wishes data element (see below) stating the name that the initiator wishes
to assert, it MUST set the cname field to the NULL principal name as to assert, it MUST set the cname field to the NULL principal name as
defined in Section 4. defined in Section 4.
If the targ_name passed to GSS_Init_sec_context() is of type If the targ_name passed to GSS_Init_sec_context() is of type
GSS_C_NT_HOSTBASED_NAME then the initiator sets the 'sname' field of GSS_C_NT_HOSTBASED_NAME then the initiator sets the 'sname' field of
the AS-REQ to match the parsed name as per [RFC4121]. If the target the AS-REQ to match the parsed name as per [RFC4121]. If the target
name is not sepecified (GSS_C_NO_NAME) or does not have a name does not have a representation as a Kerberos principal name per
representation as a Kerberos principal name per [RFC1964], then the [RFC1964], then the initiator MUST add a pa-data element (see below)
initiator MUST add a pa-data element (see below) stating the given stating the given targ_name and the initiator MUST set the 'sname'
targ_name and the initiator MUST set the 'sname' field of the AS-REQ field of the AS-REQ to the NULL principal name as defined in
to the NULL principal name as defined in Section 4. Section 4.
The padata used to convey initiator and target names is of type PA- The padata used to convey initiator and target names is of type
PKU2U-NAME and it's value consists of the DER [CCITT.X680.2002] PA_PKU2U_NAME <136> and it's value consists of the DER
[CCITT.X690.2002] encoding of the ASN.1 type InitiatorNameAssertion [CCITT.X680.2002] [CCITT.X690.2002] encoding of the ASN.1 type
(with explicit tagging). InitiatorNameAssertion (with explicit tagging).
InitiatorName ::= CHOICE { InitiatorName ::= CHOICE {
-- -1 -> certificate DN -- -1 -> certificate DN
-- 0..16384 -> subjectAltName named by -- 0..16384 -> subjectAltName named by
-- this index -- this index
sanIndex INTEGER (-1..16384), -- DN or SAN sanIndex INTEGER (-1..16384), -- DN or SAN
nameNotInCert GeneralName, -- name not present in cert nameNotInCert GeneralName, -- name not present in cert
-- (see RFC5280 for definition -- (see RFC5280 for definition
of GeneralName) of GeneralName)
... ...
skipping to change at page 15, line 4 skipping to change at page 14, line 23
SubjectAltName, the security context establishment attempt MUST fail. SubjectAltName, the security context establishment attempt MUST fail.
The nameNotInCert field, if present, contains the initiator's The nameNotInCert field, if present, contains the initiator's
GeneralName. GeneralName.
If an initiator name assertion is included, the acceptor MUST verify If an initiator name assertion is included, the acceptor MUST verify
that this asserted name is either present in the initiator's that this asserted name is either present in the initiator's
certificate or otherwise bound to the initiator's certificate by out- certificate or otherwise bound to the initiator's certificate by out-
of-band provisioning (e.g., by a table lookup). Failure to validate of-band provisioning (e.g., by a table lookup). Failure to validate
the asserted initiator's name MUST cause GSS_Accept_sec_context() to the asserted initiator's name MUST cause GSS_Accept_sec_context() to
return an error and, optionally, to output a KRB-ERROR context token return an error and, optionally, to output a KRB_ERROR context token
as per-RFC4121. as per-RFC4121.
The initiatorName field MUST NOT be present if the initiator is The initiatorName field MUST NOT be present if the initiator is
anonymous or if the 'cname' field of the AS-REQ is not the NULL name anonymous or if the 'cname' field of the AS-REQ is not the NULL name
(see Section 4). (see Section 4).
Target names passed to GSS_Init_sec_context() that can be represented Target names passed to GSS_Init_sec_context() that can be represented
as Kerberos V principal names, namely, names of as Kerberos V principal names, namely, names of
GSS_KRB5_NT_PRINCIPAL_NAME and GSS_C_NT_HOSTBASED_SERVICE, MUST be GSS_KRB5_NT_PRINCIPAL_NAME and GSS_C_NT_HOSTBASED_SERVICE, MUST be
represented as the 'sname' field of the AS-REQ or as the represented as the 'sname' field of the AS-REQ or as the
exportedTargName choice of TargetName (if the realm part is not the exportedTargName choice of TargetName (if the realm part is not the
PKU2U realm name). The contents of the exportedTargName octet string PKU2U realm name). The contents of the exportedTargName octet string
MUST be an exported name token for the Kerberos V mechanism MUST be an exported name token for the Kerberos V mechanism
containing a Kerberos V principal name. containing a Kerberos V principal name.
Other target names are represented as a generalName choice of Other target names are represented as a generalName choice of
TargetName. These may be present in an acceptor certificiate, or TargetName. These may be present in an acceptor certificate, or
agreed out of band. agreed out of band.
The acceptor MUST select an appropriate acceptor credential that The acceptor MUST select an appropriate acceptor credential that
matches the AS-REQ's 'sname' (if not NULL) or the targetName provided matches the AS-REQ's 'sname' (if not NULL) or the targetName provided
in the InitiatorNameAssertion, when present. If the 'sname' is NULL in the InitiatorNameAssertion, when present.
and the targetName is not present then any certificate will do.
The targetName field MUST NOT be present if the 'sname' field of the The targetName field MUST NOT be present if the 'sname' field of the
AS-REQ is not the NULL name. The targetName field MUST be present if AS-REQ is not the NULL name. The targetName field MUST be present if
the 'sname' field of the AS-REQ is the NULL name and targ_name is not the 'sname' field of the AS-REQ is the NULL name.
GSS_C_NO_NAME.
The PA-PKU2U-NAME padata SHOULD NOT be present when the initiatorName The PA_PKU2U_NAME padata SHOULD NOT be present when the initiatorName
and targetName both shouldn't be present. Acceptors MUST ignore PA- and targetName both shouldn't be present.
PKU2U-NAME padata when it should not be present (but it must still be
integrity protected).
Implementation note: the encrypted part of a PKU2U Ticket can be Implementation note: the encrypted part of a PKU2U Ticket can be
anything at all since the only entity that will consumer a given anything at all since the only entity that will consumer a given
PKU2U Ticket is the same entity that issued it. Implementors may PKU2U Ticket is the same entity that issued it. Implementers may
choose to use the traditional EncTicketPart ASN.1 type [RFC4120] and choose to use the traditional EncTicketPart ASN.1 type [RFC4120] and
DER encoding DER encoding.
6.2. Context Token Derived from KRB-AS-REP 6.2. Context Token Derived from KRB_AS_REP
When the initiator's initial context token is a KRB-AS-REQ then the When the initiator's initial context token is a AS-REQ then the
acceptor MUST reply with either a KRB-ERROR token as per [RFC4121] or acceptor MUST reply with either a KRB-ERROR token as per [RFC4121] or
a token derived from a KRB-AS-REP PDU [RFC4120] constructed to a token derived from a KRB_AS_REP PDU [RFC4120] constructed to
respond to the initiator's KRB-AS-REQ. respond to the initiator's KRB_AS_REQ.
The initiator MUST use PKINIT pre-authentication and the acceptor The initiator MUST use PKINIT pre-authentication and the acceptor
MUST require it. If the initiator does not use PKINIT pre- MUST require it. If the initiator does not use PKINIT pre-
authentication then the acceptor MAY respond with a KRB-ERROR, and authentication then the acceptor MUST respond with a KRB-ERROR and
MAY, but need not indicate that PKINIT is required. indicate that PKINIT is required.
If the initiator's KRB-AS-REQ token is valid, and the asserted If the initiator's KRB_AS_REQ token is valid, and the asserted
initiator's name, if present, is bound with the initiator's initiator's name, if present, is bound with the initiator's
certificate, and the acceptor can select a certificate based on the certificate, and the acceptor can select a certificate based on the
initiator's asserted targ_name, the acceptor then constructs a KRB- initiator's asserted targ_name, the acceptor then constructs a
AS-REP using PKINIT as described in [RFC4556], except that the KRB_AS_REP using PKINIT as described in [RFC4556], except that the
acceptor's certificate is used in the place of the KDC certificate. acceptor's certificate is used in the place of the KDC certificate.
If and only if the initiator's X.509 certficate is validated using If and only if the initiator's X.509 certficate is validated using
PKI, the acceptor SHOULD include an authorization element PKI, the acceptor SHOULD include an authorization element
AD_INITIAL_VERIFIED_CAS in the returned ticket [XXX - Why do we care AD_INITIAL_VERIFIED_CAS [RFC4556] in the returned ticket. If an
what authz-data is on PKU2U Tickets?]. InitiatorName is included in the PA_PKU2U_NAME padata in the request,
an authorization element of the type ad-pku2u-client-name <143> MUST
be included in the returned ticet and this authorization element
contains the DER encoded InitiatorName in the request.
The initiator then validates the KRB-AS-REP reply context token The initiator then validates the KRB-AS-REP reply context token
according to Section 3.1.5 of [RFC4120] and Section 3.2.4 of according to Section 3.1.5 of [RFC4120] and Section 3.2.4 of
[RFC4556]. The inclusion of the EKU KeyPurposeId [RFC5280] id- [RFC4556]. The inclusion of the EKU KeyPurposeId [RFC5280] id-
pkinit-KPKdc in the X.509 certificate in the response is not pkinit-KPKdc in the X.509 certificate in the response is not
applicable when PKU2U is used because there is no KDC involved in applicable when PKU2U is used because there is no KDC involved in
this protocol. The initiator MUST verify that the acceptor's this protocol. The initiator MUST verify that the acceptor's
certificate is bound with the targ_name passed in to certificate is bound with the targ_name passed in to
GSS_Init_sec_context(), by verifying either the targ_name matches GSS_Init_sec_context(), by verifying either the targ_name matches
with either the subject DN or one instance of the SubjectAltName name with either the subject DN or one instance of the SubjectAltName name
in the acceptor's certificate, or otherwise the targ_name is bound in the acceptor's certificate, or otherwise the targ_name is bound
with the acceptor's certificate by out-of-band provisioning (e.g., by with the acceptor's certificate by out-of-band provisioning (e.g., by
a table lookup). Failure to validate this name binding MUST cause a table lookup). Failure to validate this name binding MUST cause
the authentication to be rejected. the authentication to be rejected.
The 'last-req' field of the AS-REP MUST be an empty SEQUENCE.
The 'key-expiration' field of the AS-REP MUST be absent.
The 'flags' field of the AS-REP MUST have only the 'initial' and The 'flags' field of the AS-REP MUST have only the 'initial' and
'pre-authent' flags set. 'pre-authent' flags set.
The 'authtime' field of the AS-REP MUST be set to the acceptor's The 'authtime' field of the AS-REP MUST be set to the acceptor's
current time as it is when it formats the AS-REP. The 'starttime' current time as it is when it formats the AS-REP.
and 'renew-till' fields of the AS-REP MUST be absent. As usual with
Kerberos V, the 'endtime' field of the AS-REP indicates when the
issued Ticket will expire, but the acceptor MAY set it to the same
time as the starttime field to indicate that the issued Ticket may
not be reused for other security context establishment attempts.
The 'caddr' field of the AS-REP MUST be absent.
Otherwise all other aspects of the AS-REP are as described in Otherwise all other aspects of the AS-REP are as described in
[RFC4120]. [RFC4120].
The values of the tkt-vno, realm and 'sname' fields of the Ticket The values of the tkt-vno, realm and 'sname' fields of the Ticket
issued by the acceptor are unspecified. The initiator MUST NOT issued by the acceptor are unspecified. The initiator MUST NOT
examine them for correctness. Cut-n-paste attacks are prevented by examine them for correctness. Cut-n-paste attacks are prevented by
the fact that PKU2U provides integrity protection for all cleartext the fact that PKU2U provides integrity protection for all cleartext
in Kerberos V PDUS used by PKU2U (and for the mechanism OID). in Kerberos V PDUs used by PKU2U (and for the mechanism OID).
6.3. Context Tokens Imported from RFC4121 6.3. Context Tokens Imported from RFC4121
Once the initiator has a Kerberos V Ticket for the acceptor the Once the initiator has a Kerberos V Ticket for the acceptor the
security context token exchange will continue with those of the security context token exchange will continue with those of the
Kerberos V GSS-API mechanism [RFC4121] with the following Kerberos V GSS-API mechanism [RFC4121] with the following
modifications: modifications:
o The mechanism OID of PKU2U SHALL be used instead of that of the o The mechanism OID of PKU2U SHALL be used instead of that of the
Kerberos V GSS-API mechanism; Kerberos V GSS-API mechanism;
o The 'cname' and 'crealm' fields of the initiator's Authenticator o The 'crealm' field of the initiator's Authenticator MUST be set to
MUST be set to the NULL name and the PKU2U realm name, the PKU2U realm name and if the 'cname" field is the NULL
respectively; principal name, an authorization element of the type ad-pku2u-
client-name <143> MUST be included in the authenticator and this
o The sub-session key MUST be included in the initiator's authorization element contains the DER encoded InitiatorName in
Authenticator; the AS-REQ based on which the ticket was obtained;
o The 'ap-options' field of the AP-REQ MUST have the 'use-session- o The sub-session key MUST be used in the initiator's Authenticator;
key' (see above) and 'mutual-required' flags set.
o The contents of the encrypted part of the Ticket can be o The contents of the encrypted part of the Ticket can be
implementation specific since the only entity consuming it will be implementation specific since the only entity consuming it will be
the same entity that issues it; the same entity that issues it;
o If the initiator's initial context token is a KRB-AS-REQ token o If the initiator's initial context token is a KRB_AS_REQ token
(i.e., not KRB-AP-REQ token), then the Exts field in the (i.e., not KRB_AP_REQ token), then the Exts field in the
Authenticator of the KRB-AP-REQ-derived token MUST contain an Authenticator of the KRB_AP_REQ-derived token MUST contain an
extension [GSS-EXTS] of the type GSS_EXTS_FINISHED as defined next extension [GSS-EXTS] of the type GSS_EXTS_FINISHED <2> as defined
in this section. next in this section.
The 'cusec', 'ctime', 'seq-number' and 'authorization-data' fields of The 'cusec', 'ctime', 'seq-number' and 'authorization-data' fields of
the Authenticator are set as per [RFC4121] and [RFC4120]. the Authenticator are set as per [RFC4121] and [RFC4120].
The 'cksum' field of the Authenticator MUST be set as per [RFC4121]. The 'cksum' field of the Authenticator MUST be set as per [RFC4121].
The extension data of the GSS_EXTS_FINISHED extension type [GSS-EXTS] The extension data of the GSS_EXTS_FINISHED extension type [GSS-EXTS]
contains the DER encoding of the ASN.1 structure KRB-FINISHED. contains the DER encoding of the ASN.1 structure KRB-FINISHED.
GSS_EXTS_FINISHED 2 GSS_EXTS_FINISHED 2
--- The type for the checksum extension. --- The type for the checksum extension.
skipping to change at page 18, line 25 skipping to change at page 17, line 25
... ...
} }
The gss-mic field contains a Kerberos checksum [RFC3961] that is The gss-mic field contains a Kerberos checksum [RFC3961] that is
computed over all the preceding context tokens of this GSS-API computed over all the preceding context tokens of this GSS-API
context (including the InitialContextToken header), concatenated in context (including the InitialContextToken header), concatenated in
chronological order (note that GSS-API context token exchanges are chronological order (note that GSS-API context token exchanges are
synchronous). The checksum type is the required checksum type of the synchronous). The checksum type is the required checksum type of the
enctype of the subkey in the authenticator, the protocol key for the enctype of the subkey in the authenticator, the protocol key for the
checksum operation is the authenticator subkey, and the key usage checksum operation is the authenticator subkey, and the key usage
number is KEY_USAGE_FINISHED. number is KEY_USAGE_FINISHED <41>.
KEY_USAGE_FINISHED 41
The acceptor MUST process the KRB-AP-REQ token as usual for RFC4121, The acceptor MUST process the KRB_AP_REQ token as usual for RFC4121,
except that if the context token exchange included an AS eschange, except that if the context token exchange included an AS exchange,
then the acceptor MUST also validate the GSS_EXTS_FINISHED and return then the acceptor MUST also validate the GSS_EXTS_FINISHED and return
an error if it is not valid or not present. But if a KRB-AP-REQ an error if it is not valid or not present. But if a KRB_AP_REQ
context token is the initial context token then the acceptor MUST context token is the initial context token then the acceptor MUST
return an error if GSS_EXTS_FINISHED is present. return an error if GSS_EXTS_FINISHED is present.
The GSS_EXTS_FINISHED (along with the ticket) binds the second part The GSS_EXTS_FINISHED (along with the ticket) binds the second part
of the context token exchange to the first, and it binds the pa-data of the context token exchange to the first, and it binds the pa-data
used in the request as well (this needs to be done because PKINIT used in the request as well (this needs to be done because PKINIT
does not bind pa-data other than PKINIT pa-data from the request). does not bind pa-data other than PKINIT pa-data from the request).
GSS_EXTS_FINISHED also protects all otherwise unauthenticated GSS_EXTS_FINISHED also protects all otherwise unauthenticated
plaintext in Kerberos V PDUs. Note that GSS_EXTS_FINISHED also plaintext in Kerberos V PDUs. Note that GSS_EXTS_FINISHED also
protects the mechanism OID in the InitialContextToken header. protects the mechanism OID in the InitialContextToken header.
6.4. Authorization-Data Type to Aid Acceptor Implementors The acceptor MUST verify that the ad-pku2u-client-name authorization
element is present in the authenticator if and only there is an
The issuer of a PKU2U Ticket is the only possible consumer for it. authorization element of the same type in the ticket and the values
Therefore the contents of the encrypted part of a PKU2U Ticket can be of these two elements MUST match exactly based on bit-wise
anything at all, to the convenience of the implementor. comparison.
However, many PKU2U implementors will likely begin with a Kerberos V
implementation and will likely re-use the EncTicketPart ASN.1 type
from [RFC4120]. Such implementors, if they wish to support PKU2U
Ticket re-use, will need a way to store information about the
initiator, as well as the acceptor name that should be associated
with any security context established with a re-used PKU2U Ticket.
As an aid to implementors, we reserve three Kerberos V authorization-
data types, AD-PKU2U-INFO-1, AD-PKU2U-INFO-2, and AD-PKU2U-INFO-3.
An implementor might, for example, store the initiator's certificate
in AD-PKU2U-INFO-1, an exported name token for the initiator's name
in AD-PKU2U-INFO-2, and an exported name token for the acceptor's
name in AD-PKU2U-INFO-3.
The numbers for these three authorization-data types are:
o <TBD> (AD-PKU2U-INFO-1)
o <TBD> (AD-PKU2U-INFO-2)
o <TBD> (AD-PKU2U-INFO-3)
6.5. Errors
Some Kerberos V error codes in KRB-ERROR replies to AP-REQ initial
security context tokens are fatal, and some are not. All Kerberos V
error codes in KRB-ERROR replies to AP-REQ non-initial security
context tokens are fatal. All Kerberos V error codes in KRB-ERROR
replies to AS-REQ initial security context tokens are non-fatal. All
error codes in KRB-ERROR replies to AS-REQ non-initial security
context tokens are fatal.
When the acceptor produces a KRB-ERROR PDU with a fatal error code
then GSS_Accept_sec_context() GSS_S_FAILURE, and the
GSS_Init_sec_context() MUST return GSS_S_FAILURE upon consuming the
KRB-ERROR.
The following Kerberos V error codes in KRB-ERROR replies to AP-REQ
initial security context tokens are non-fatal:
o KRB_AP_ERR_TKT_EXPIRED
o KRB_AP_ERR_REPEAT
o KRB_AP_ERR_BADMATCH
o KRB_AP_ERR_BADVERSION
o KRB_AP_ERR_MSG_TYPE
o KRB_AP_ERR_MODIFIED
o KRB_AP_ERR_BADKEYVER
o KRB_AP_ERR_NOKEY
o KRB_AP_ERR_MUT_FAIL
All other Kerberos V KRB_AP_ERR_* error codes in KRB-ERROR replies to
AP-REQ initial security context tokens are fatal.
Implementation note: PKU2U acceptors may use the KRB_AP_ERR_BADKEYVER
error code to indicate that the Ticket used by the initiator is
stale. PKU2U Tickets may become stale at any time due to
implementation specific events (e.g., when the application starts it
generates ephemeral keys for encrypting the encrypted parts of PKU2U
Kerberos V Tickets, and it loses the previous keys whenever it
restarts).
7. Guidelines for Credentials Selection 7. Guidelines for Credentials Selection
If a peer, either the initiator or the acceptor, has multiple pairs If a peer, either the initiator or the acceptor, has multiple pairs
of public-key private keys and certificates, a choice is to be made of public-key private keys and certificates, a choice is to be made
in choosing the best fit. The trustedCertifiers field in the PA-PK- in choosing the best fit. The trustedCertifiers field in the PA-PK-
AS-REQ structure [RFC4556] SHOULD be filled by the initiator, to AS-REQ structure [RFC4556] SHOULD be filled by the initiator, to
provide hints for guiding the selection of an appropriate certificate provide hints for guiding the selection of an appropriate certificate
chain by the acceptor. chain by the acceptor.
If the initiator's X.509 certificate cannot be validated according to If the initiator's X.509 certificate cannot be validated according to
[RFC5280], the acceptor SHOULD send back the TD-TRUSTED-CERTIFIERS [RFC5280], the acceptor SHOULD send back the TD-TRUSTED-CERTIFIERS
structure [RFC4556] that provides hints for guiding the selection of structure [RFC4556] that provides hints for guiding the selection of
an appropriate certificate by the initiator. In this case an appropriate certificate by the initiator. In this case
GSS_Accept_sec_context() returns GSS_S_CONTINUE_NEEDED, and the GSS_Accept_sec_context() returns GSS_S_CONTINUE_NEEDED, and the
initiator gets to try again in its subsequent AS-REQ token. initiator gets to try again in its subsequent AS-REQ token.
The GSS-API does not provide a programming interface to make this The GSS-API does not provide a programming interface to make this
credential selection interactive, though implementors may provide credential selection interactive, though implementers may provide
methods for user interaction related to credential selection and methods for user interaction related to credential selection and
acquisition (e.g., name and password/PIN prompts). Whenever the acquisition (e.g., name and password/PIN prompts). Whenever the
execution context allows for direct interaction of the mechanism with execution context allows for direct interaction of the mechanism with
the user then it is RECOMMENDED that implementations interact with the user then it is RECOMMENDED that implementations interact with
the user to select a credential whenever multiple credentials are the user to select a credential whenever multiple credentials are
equally usable and no other mechanism is available to inform the equally usable and no other mechanism is available to inform the
credential selection. credential selection.
If the certificates cannot be selected interactively, multiple If the certificates cannot be selected interactively, multiple
certificates are equally usable, and there is no other mechanism certificates are equally usable, and there is no other mechanism
skipping to change at page 25, line 44 skipping to change at line 1023
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 64 change blocks. 
233 lines changed or deleted 137 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/