Subject: Re: [Ietf-krb-wg] the PKU2U DN to Kerberos Principal name mapping

From: Larry Zhu <[email-masked]>
Date: Sat, 26 Jan 2008 16:00:13 -0800

I am reviving this thread.

To summarize the discussion, it seems that constructing a unique mapping need some work and the mapping might not be useful in the ACLs as Martin pointed out.

As Nico put it nicely, the mapping from the DN into a Kerberos principal is like making a square peg (DNs, SANs, ...) fit into a triangular slot (PrincipalName and Realm Kerberos V types). We do not need to do this and PKU2U can work without it.

I think it is important to point out explicitly any arbitrary certificate can be used in PKU2U.

All we need is a binding, and the binding can be maintained separately, it does not need to come from the certificate directly. This is very similar to how Kerberos works today. The Kerberos Principal keys themselves do not carry the bindings, the bindings is maintained in the KDC's database. PKINIT works with any certificate as long as there is a binding that can be verified.

It is no exception for PKU2U, the authenticating peer just need to maintain the binding. If the binding is asserted in the certificate, it maybe be more convenient that way, and the peer needs to trust the CA in order to verify the binding. Either because the peer does not want to maintain a PKI to verify the binding, or because a certificate is issued prior to PKU2U is invented, a binding need to be maintained outside of the certificate.

CITI/UMich folks, the deployment need in the low infrastructure you brought forth means it is preferable to let the peer to maintain the binding, instead of relying on the CA/PKI. So that would suggest to me you would prefer not to have to create the mapping even the mapping is useful in a full-blown PKI deployment, right?

My take away of this discussion is to document issues and potential solutions.

And it is helpful to point out explicitly how to deploy PKU2U with an arbitrary certificate.

With that in mind, I changed the title of section 4 and compiled the text directly from the email discussions here (with acknowledgements to all the individuals who participated in this discussion, see the attached).

Olg, I have explicitly specified in section 4 of -04 the output of export_name() and display_name() per your request.

4.  Bindings for PKU2U Principal Names

   In the classic Kerberos protocol, a principal is authenticated based
   on the proof of possession to a symmetric key, the binding between
   the principal and the authentication key is maintained in a database.
   In this protocol, the identity of a principal (either the initiator
   or the acceptor) is authenticated based on the proof of possession to
   a pair of asymmetric keys, similarly the binding between the Kerberos
   principal name and the authentication key pair can be maintained in a
   table trusted by the authenticating peer.

   However, if a X.509 certificate is used by a peer identity,
   conveniently the binding between the peer's principal name and the
   public key can be asserted in the X.509 certificate directly.  This
   way the authentication peer can verify the binding using the
   certificate, thus the need to maintain a binding table separately is
   obviated.  This section describes the schema that can be used to bind
   a Kerberos principal name and a X.509 certificate.

   o  If the X.509 certificate [RFC3280] of a peer contains an id-
      pkinit-san Subject Alternative Name (SAN) as defined in Section
      3.2.2 of [RFC4556] or an id-ms-sc-logon-upn SAN as defined in
      [REFERALS], then the Kerberos Principal Name for the peer is as
      specified in that SAN in the certificate.  If the realm in the
      KRB5PrincipalName structure is specified, it MUST be the PKU2U
      realm.

   o  If the X.509 certificate of the peer contains a dNSName SAN
      [RFC3280], then unless otherwise specified the peer's Kerberos
      principal name is a two-component NT-SRV-HST type name as defined
      in Section 6.2.1 of [RFC4120], with the first component as "host"
      and the second component as the name in the dNSName SAN of the
      certificate, and the realm of this Kerberos principal is the PKU2U
      realm.

   It should be noted that a certificate that does not have any of the
   above name attributes can be used in PKU2U as long as there is a
   binding between the key pair and the peer principal that can be
   verified, and such bindings can be maintained in a trusted table such
   as a database.

   Some considerations for additional mappings are documented here based
   on discussions in the Kerberos working group mailing list.  In the
   case where a X.509 certificate does not assert the binding as
   described in this section, if there is a mapping from the
   Distinguished Name (DN) in the certificate to a Kerberos principal
   name, because the certificate provides a binding between the DN and
   the public key, the binding between the Kerberos principal name and

Zhu & Altman              Expires July 30, 2008                 [Page 4]

Internet-Draft                    PKU2U                     January 2008

   the public key can then be established transitively.  Intuitively,
   such a mapping can be accomplished by constructing a string
   representation of the Distinguished Name, such that equivalent
   Distinguished Names for the same X.509 entity are mapped to the same
   Kerberos principal name.  To do that, one could start with [RFC4514]
   but add further constraints to guarantee a canonical form: require
   Distinguished Encoding Rules (DER) [X680] [X690] for values of
   unknown syntax, restrict the use of escape characters, force the case
   of case-insensitive string values, etc.  However, it is unclear such
   mapping would be useful in practice.  An arbitrary peers' certificate
   might be available upon authentication, but it is usually not
   available during Access Control List (ACL) maintenance.  Based on
   these considerations, this document maintains the same spirit of
   [RFC4556] and gives the authenticating peer the responsibility to
   maintain the bindings if the Kerberos name is not bound with a
   certificate as specified in this section.  Additional work is
   anticipated in the Kerberos working group to standardize additional
   DN-to-Kerberos-principal-name mappings, and such work is orthogonal
   to this document and it is generic to integrating Distinguished Names
   into GSS-API and Kerberos at large.

   Implementations conforming to this document MUST support the binding
   schema specified in this section.

   The rest of this document assumes there is a binding between a
   Kerberos principal name and the asymmetric key pair used for
   authentication.  The Kerberos principal name (not the certificate, or
   a string representation of the DN) is returned by GSS-API primitives
   such as GSS_Export_name() and GSS_Display_name().

Thank you all for providing the excellent reviews comments and constructive suggestions. I hope this would bring us a closure to this issue.

--larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henry B. Hotz
Sent: Monday, December 10, 2007 5:23 PM
To: Kevin Coffman
Cc: IETF Kerberos Working Group
Subject: Re: [Ietf-krb-wg] the PKU2U DN to Kerberos Principal name mapping

On Dec 7, 2007, at 12:06 PM, Kevin Coffman wrote:

> On Dec 6, 2007 7:04 PM, Larry Zhu <[email-masked]> wrote:
>>
>> In the interest of moving PKU2U forward, and based on the
>> considerations
>> that the mapping methods other than this one strictly based on DN are
>> sufficient from most of the scenarios and the common deployment
>> need, we
>> removed this mapping. It would be interesting to get some
>> discussions going
>> in the krb-wg mailing list.
>>
>
> Hi Larry,
>
> It is my understanding that a majority of government-issued
> certificates, as well as grid certificates, do not, and may never,
> have a pkinit-SAN or a dNSName-SAN.  Without a DN mapping, we are
> leaving all these users out of the game waiting for further
> specifications.
>
> I feel there is a desire to move this ahead for the sake of expediency
> at the cost of interoperability down the road.
>
> K.C.

NASA certs fit this, but JPL certs should contain both the pkinit-SAN
and the Microsoft attribute (with different values).

------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 27 Jan 2008 15:07:18 -0600

On Sat, Jan 26, 2008 at 04:00:13PM -0800, Larry Zhu wrote:
> To summarize the discussion, it seems that constructing a unique
> mapping need some work and the mapping might not be useful in the ACLs
> as Martin pointed out.
> 
> As Nico put it nicely, the mapping from the DN into a Kerberos
> principal is like making a square peg (DNs, SANs, ...) fit into a
> triangular slot (PrincipalName and Realm Kerberos V types). We do not
> need to do this and PKU2U can work without it.

Good summary.

PKU2U is a PKI-based mechanism, with Kerberos V and PKINIT being
internal details.  That is, to all outward appearances PKU2U is a PKI
mechanism having *nothing* to do with Kerberos V.

Therefore a mapping of PKI names to Kerberos V names is completely
irrelevant.

> certificate can be used in PKU2U.

Yes.

> All we need is a binding, and the binding can be maintained
> separately, it does not need to come from the certificate directly.

Binding to... what?

> This is very similar to how Kerberos works today. The Kerberos
> Principal keys themselves do not carry the bindings, the bindings is
> maintained in the KDC's database. PKINIT works with any certificate as
> long as there is a binding that can be verified.

That binding is the certificate itself (and the signature of it).

> It is no exception for PKU2U, the authenticating peer just need to
> maintain the binding. If the binding is asserted in the certificate,
> it maybe be more convenient that way, and the peer needs to trust the
> CA in order to verify the binding. Either because the peer does not
> want to maintain a PKI to verify the binding, or because a certificate
> is issued prior to PKU2U is invented, a binding need to be maintained
> outside of the certificate.

Don't complicate things.  PK using PKI technology but without a PKI
works just fine in other protocols using certificates: just self-sign
certs and pre-share them (or learn them in leap-of-faith ways).

There's no need to invent something new, and anything new would have to
be generic -- the sort of thing that could be made applicable to TLS as
well.

> CITI/UMich folks, the deployment need in the low infrastructure you
> brought forth means it is preferable to let the peer to maintain the
> binding, instead of relying on the CA/PKI. So that would suggest to me
> you would prefer not to have to create the mapping even the mapping is
> useful in a full-blown PKI deployment, right?

See above.  The initiator learns the acceptor's cert (no PKI) or has a
trust anchor (PKI).  The initiator will be stacking LIPKEY atop PKU2U,
so the initiator may have no cert (be anonymous) at the PKU2U level, but
will send a username & password at the LIPKEY level to an authenticated
acceptor.

> My take away of this discussion is to document issues and potential

There are no new issues, nor solutions, provided that you think of PKU2U
as a PKI mechanism.  It uses Kebreros V building blocks, but that's an
internal details that should not be externally visible.

> And it is helpful to point out explicitly how to deploy PKU2U with an

That's a typical PK issue.  See above.

> With that in mind, I changed the title of section 4 and compiled the
> text directly from the email discussions here (with acknowledgements
> to all the individuals who participated in this discussion, see the
> attached).

> Olg, I have explicitly specified in section 4 of -04 the output of
> export_name() and display_name() per your request.
> 
> 
> 

This is not a good way to start the section.  PKU2U is NOT Kerberos.  It
is PK.

>       KRB5PrincipalName structure is specified, it MUST be the PKU2U

PKU2U is a PKI-based GSS-API mechanism.  You need to define principal
names in terms of *PKI* and which fit the GSS-API.  The only thing that
you can use as a )canonical_ principal name, given that, is the cert's
DN.  That's it.  You can provide support for other principal name forms
though.

I.e., you can say that any name that appears in a cert, either as its DN
or as a SAN, can be used to: a) GSS_Import_name() the name, b)
GSS_Acquire_cred() with that name.

In order to do that we do need:

 - a GSS-API name type for each kind of PKI name (DN, and every kind of
   SAN that we think may be useful)

 - and a generic human-readable syntax for each such name-type.

But the cert DN *must* remain as the canonical principal name.  I.e., if
you GSS_Inquire_cred() the name of a CREDENTIAL or GSS_Inquire_context()
the names of a SECURITY CONTEXT's source and/or target names and then
GSS_Export_name() or GSS_Display_name() those names, then the result
will contain only the DN of the cert whence the NAME came.

>    verified, and such bindings can be maintained in a trusted table such

The binding *is* the cert, and either the PKI or the presence of that
cert in a DB of pre-shared certs.

Nico
--

---

From: Larry Zhu <[email-masked]>
Date: Sun, 27 Jan 2008 23:03:35 -0800

Nico, I agree with all your points, how about the following updated text here?

4.  PKU2U Principal Names

   PKU2U Principal names MUST be bound with the authentication keys.
   The binding can be maintained by the authenticating peer, for example
   in a table, such that the peer learns the binding via leap-of-faith
   ways, or it can be verified using PKI.  In the later case, the PKU2U
   principal names can be constructed as follows:

   It should be noted that a certificate that does not have any of the
   above name attributes can be used in PKU2U as long as there is a
   binding between the asymmetric key pair and the peer principal name.
   And the binding MUST be verified securely.

   A Distinguished Name (DN) can be transformed into a string and
   represented as the NT-X500-PRINCIPAL name type, but the current
   definition of this name type in [RFC4120] does not guarantee a
   canonical form.  Additional work is anticipated to start with
   [RFC4514] but add further constraints: require Distinguished Encoding
   Rules (DER) [X680] [X690] for values of unknown syntax, restrict the
   use of escape characters, force the case of case-insensitive string
   values, etc.  It is anticipated that any name that appears in a
   certificate, either as its DN or as a SAN, can be used via
   GSS_Import_name() and GSS_Acquire_cred().  In order to do that, a
   GSS-API name type is expected to be defined for each kind of PKI name
   (DN, and every kind of SAN that may be useful), and a generic human-
   readable syntax is expected to be defined for each such name-type.
   The DN remains, however, as the canonical principal name.  This work
   is out of the scope to this document and it is generic to integrating
   Distinguished Names into GSS-API.

   Implementations conforming to this document MUST support the binding
   schema using PKI specified in this section.

Zhu & Altman              Expires July 31, 2008                 [Page 4]

   The rest of this document assumes there is a binding between a
   Kerberos principal name and the asymmetric key pair used for
   authentication unless otherwise specified.  The Kerberos principal
   name or its transformed representation is returned by GSS-API
   primitives such as GSS_Export_name() and GSS_Display_name().

Thanks,

--larry
-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]]
Sent: Sunday, January 27, 2008 1:07 PM
To: Larry Zhu
Cc: Henry B. Hotz; Kevin Coffman; [email-masked]; [email-masked]; [email-masked]; IETF Kerberos Working Group
Subject: Re: [Ietf-krb-wg] the PKU2U DN to Kerberos Principal name mapping

Good summary.

Yes.

Binding to... what?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 28 Jan 2008 13:42:00 -0600

> Nico, I agree with all your points, how about the following updated text here?

How about this (note the note to you embedded below):

x.  Naming

   This mechanism conforms to GSS-API naming considerations as follows:

    o An exported name token format is provided based on certificate
      DNs.

    o A recommendation for locally- and/or implementation-defined name
      canonicalization functions.  And such a function is provided for
      mapping generic names of the GSS_C_NT_USERNAME and
      GSS_C_NT_HOSTBASED_SERVICE types to DNs.

    o Additional, optional name types and syntaxes are provided that
      correspond to subjectAlternativeNames, although these are of
      limited use without GSS-API naming extensions.

   Extensions to the GSS-API will be required in order to make PKI
   certificate extensions, such as subjectAlternativeNames and
   extendedKeyUsages, fully available to GSS-API applications.  Such
   extensions are out of scope for this document.

x.1.  Exported name token

   The exported name token format for this mechanism's MNs will be the
   DER encoding of a distinguished name (the ASN.1 type being 'Name' as
   described in [RFC3280]).

   When exporting an MN that was obtained from inquiring a credential or
   security context, then the DN will be that of the underlying
   certificate.

x.2.  Name mapping functions

   When exporting an MN produced by calling GSS_Canonicalize_name() then
   the DN will be that which was obtained by GSS_Canonicalize_name().
   In an environment where there are no directories it may be difficult
   or impossible for GSS_Canonicalize_name() to produce useful MNs for
   PKI principals without some function to map human-entered names to
   DNs.  Such functions are out of scope for this document, but
   implementations SHOULD provide configurable functions for mapping
   generic syntax names to DNs, and MAY provide such functions for
   mapping subjectAlternativeNames to DNs.  However, the following
   default functions MUST be provided:

    - The default mapping to DN of GSS_C_NT_HOSTBASED_SERVICE names is:

       CN=<hostnme>

      Where <hostname> is the hostname part of the host-based service
      name input to GSS_Import_name(), fully qualified.  The service
      name is ignored.

      Additionally, default organization (O) and/or organizational unit
      (OU) elements may be locally defined.

    - The default mapping to DN of GSS_C_NT_USERNAME names is:

       CN=<username>

      where <username> is the input to GSS_Import_name().

      Additionally, default organization (O) and/or organizational unit
      (OU) elements may be locally defined.

x.3.  Name types for subjectAlternativeNames (SANs)

   The following name types are provided for representing SANs.  Note
   that the GSS-APIv2u1 does not provide any interfaces for listing the
   attributes of NAME objects, such as SANs, and SANs are not canonical
   names for users identified and authenticated by certificates.

   Therefore these name types are of very limited utility.  Future
   extensions to the GSS-API may make these name types more useful.

   Until then the following name types, when used with this mechanism,
   are not canonical names, and can only be used as follows:

    - Such a name can be imported with GSS_Import_name() and
      canonicalized (i.e., mapped to a DN) via a locally- or
      implementation-defined procedure.

    - Such a name can be imported with GSS_Import_name() and then a
      credential may be acquired with the resulting NAME object as the
      desired_name.  In this case all available credentials will be
      searched and the given name will be checked against every
      credential's SANs.

    - Such a name can be imported with GSS_Import_name(), which can then
      be used as a target principal name for GSS_Init_sec_context().  In
      that case the given name will be used to check whether the
      acceptor's certificate matches the one supplied by the client.

      [Note to Larry et. al.: we need a way to convey to the acceptor
       *any* such SAN in the mechanism's initial context token so that
       the acceptor may select a matching certificate, if one is
       available.]

    - Such a name can be imported with GSS_Import_name(), which be used
      with GSS_Compare_name() to compare against any other such NAME
      object, as well as against any MN obtained by canonicalizing such
      NAME object or from inquiring a credential or security context.

      [Note: here we probably bending the rules a bit, but I think it's
       OK.]

   The name type GSS_C_NT_DN is special: it can match a certificate DN
   and it can match any directoryName SAN, and it is assumed to be
   canonical already (unless a locally- or implementation-defined
   procedure exists for canonicalizing user-provided DNs).

x.3.1.  GSS_C_NT_DER

   The name type GSS_C_NT_DER shall have the following OID:

   <TBD>

   and its generic syntax will be that described in [RFC3280] for
   distinguished names.

   GSS_Display_name() as applied to MNs of this mechanism SHOULD output
   GSS_C_NT_DER as the name type and the MN's DN's human readable
   representation.

x.3.2.  GSS_C_NT_EMAIL_ADDRESS

   The name type GSS_C_NT_EMAIL_ADDRESS shall have the following OID:

   <TBD>

   and its generic syntax will be any e-mail address that may be used as
   an rfc822Name subjectAlternativeName [RFC3280] [RFC822].

x.3.3.  GSS_C_NT_IP_ADDRESS

   The name type GSS_C_NT_IP_ADDRESS shall have the following OID:

   <TBD>

   and its generic syntax will be any IP address expressed in the syntax
   described in [RFC3280] section 4.2.1.7.

x.3.4.  GSS_C_NT_FQDN

   The name type GSS_C_NT_FQDN shall have the following OID:

   <TBD>

   and its generic syntax will be any fully-qualified domain name as
   described in [RFC3280] [RFC1034].

x.3.5.  GSS_KRB5_NT_PRINCIPAL_NAME

   The GSS_KRB5_NT_PRINCIPAL_NAME name type and syntax are described in
   [RFC1964]; its representation in certificates as an id-pkinit-san
   subjectAlternativeName is described in [RFC4556].

x.4.  Future GSS-API naming extensions

   Extensions to the GSS-API should eventually be provided for:

    - Listing the various names of a certificate (represented as a NAME
      object, specifically as an MN), including DN, SANs, and the public
      key itself.

    - Listing the EKUs of a certificate (represented as a NAME object,
      specifically as an MN).

    - Mapping GSS_C_NT_HOSTBASED_SERVICE to dNSName SAN and an EKU
      corresponding to the service name.

    - Listing other extensions of a certificate.

    - Exporting such SANs, etcetera.

    - Exporting MNs as a different sort of exported name token, one
      which includes all or most of the underlying certificate's
      contents.  Such exported name tokens, by their very nature, are
      incompatible with the existing GSS-API exported name token
      facility; in particular it will not be possible to obtain such a
      token from the NAME output of GSS_Canonicalized_name(), but only
      from NAME objects obtained by inquiring on credentials or security
      contexts.  We propose the term Credential Mechanism Name -- CMN --
      for referring to NAME objects that may be exported through such a
      facility.

   This is not an exhaustive list.  See [RFC4768].

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 28 Jan 2008 15:38:17 -0500

> How about this (note the note to you embedded below):

I should note that this is not a krb-wg document, and is getting close to 
off-topic here.  I started the discussion here because I was raising an 
issue specifically related to Kerberos and potentially broader than just 
PKU2U; namely, handling of mapping X.500 DN's to Kerberos principal names. 
It seems that particular issue has been resolved, at least for PKU2U, by 
observing that PKU2U needn't expose Kerberos principal names and so doesn't 
actually need such a mapping.

At this point, I think the remaining issues are not particularly Kerberos 
specific, and in fact much of this seems to touch on things that affect 
other GSS-API mechanisms and the work of the Kitten WG.  I think it might 
be worth taking the discussion of naming issues and especially naming 
extensions to the Kitten list.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 28 Jan 2008 14:42:41 -0600

> extensions to the Kitten list.

KITTEN doesn't work on mechanisms either, but KITTEN is appropriate for
discussion of GSS-API naming issues.  So, yes, we should take this to
the KITTEN list, though eventually PKU2U will be off-topic there also.

Nico

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 28 Jan 2008 17:19:04 -0500

--On Monday, January 28, 2008 02:42:41 PM -0600 Nicolas Williams 
<[email-masked]> wrote:

>> I should note that this is not a krb-wg document, and is getting close
>> to  off-topic here.  I started the discussion here because I was raising
>> an  issue specifically related to Kerberos and potentially broader than
>> just  PKU2U; namely, handling of mapping X.500 DN's to Kerberos
>> principal names.  It seems that particular issue has been resolved, at
>> least for PKU2U, by  observing that PKU2U needn't expose Kerberos
>> principal names and so doesn't  actually need such a mapping.
>>
>> At this point, I think the remaining issues are not particularly
>> Kerberos  specific, and in fact much of this seems to touch on things
>> that affect  other GSS-API mechanisms and the work of the Kitten WG.  I
>> think it might  be worth taking the discussion of naming issues and
>> especially naming  extensions to the Kitten list.
>

I agree, PKU2U is clearly not in KITTEN's charter.  However, IMHO it is an 
appropriate source for expert advice on GSS-API naming issues, and for 
expertise on GSS-API in general.  I believe its members have been asked to 
look at PKU2U in the past, and their comments would certainly be welcome 
now, as it nears completion.

-- Jeff

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 28 Jan 2008 15:46:07 -0800

On Jan 28, 2008, at 12:42 PM, Nicolas Williams wrote:

>> Kerberos

Since I'm not on that list, I'll throw my 2 cents in here:

It would be nice if you could do a gss_compare_name() between  
[email-masked] and uid=smith,ou=People,dc=example,dc=com and get a  
"true" result.  I think the detail you threw out was headed in that  
direction, but it wasn't clear to me if it would get you all the way  
there.