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

From: Larry Zhu <[email-masked]>
Date: Thu, 6 Dec 2007 16:04:06 -0800

<chair hat off, speak as an individual>

In the course of preparing PKU2U for IESG, we found that the mapping from DNs to Kerberos Principal names based on RFC2253 with additional constraints as defined in PKU2U -03 do not always yield a unique mapping.

More specifically, the following aspects would create a non-unique mapping.

- RFC2253 section 2.3 indicates that attribute types should be encoded

  as strings when present in some table of attribute types, and as OID's

  otherwise, but fails to specify any particular such table (it makes

  reference to RFC2252, which does not include or refer to a table of

  attribute types).

- When there is no string representation for an attribute, the value

  is encoded "as an octothorpe character ('#' ASCII 35) followed by

  the hexadecimal representation of each of the bytes of the BER

  encoding of the X.500 AttributeValue"; however, BER is not a

  canonical encoding.

- If the attribute value does have a string representation, then that

  representation is used, converted to UTF-8.  However, there is no

  guarantee that all attribute types will have syntax which produces

  a unique encoding.

- When a string representation is used for an attribute value, there

  is an escaping mechanism which allows inclusion of characters that

  would otherwise be confused as syntactic elements, such as '+' or

  ','.  However, RFC2253 section 2.4 states "Implementations MAY escape

  other characters", which opens the door to non-unique encodings.

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.

---larry
p.s. the above summary of issues is the curtsey of Jhutz.

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

---

From: Howard Chu <[email-masked]>
Date: Thu, 06 Dec 2007 18:37:01 -0800

(Resending, previous attempt bounced)
Larry Zhu wrote:
> In the course of preparing PKU2U for IESG, we found that the mapping 
> from DNs to Kerberos Principal names based on RFC2253 with additional 
> constraints as defined in PKU2U -03 do not always yield a unique mapping.
> 

Just fyi, RFC2253 has been superseded by RFC4514. No current specs should be 
referring to RFC2251-2256 any more, they should be referencing RFC4510-...

There is no canonical table of attribute types. Some common schema from X.500 
were documented in RFC2256, now RFC4519. But it all depends on whatever 
software was loaded in the software agent generating the DN.

> encoding of the X.500 AttributeValue"; however, BER is not a

Probably should have said DER instead. As defined in RFC4511 section 5.1, the 
encoding used in LDAP is a restricted form of BER that is essentially DER anyway.

> other characters", which opens the door to non-unique encodings.

The string representation is just a convenience for human consumption. RFC4514 
section 3 gives the rules for converting the string representation to an 
actual DN. And since DNs are (by definition) unique, I don't think this 
concern is valid.

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

--    -- Howard Chu
    Chief Architect, Symas Corp.  http://www.symas.com
    Director, Highland Sun        http://highlandsun.com/hyc/
    Chief Architect, OpenLDAP     http://www.openldap.org/project/

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Howard Chu <[email-masked]>
Date: Thu, 06 Dec 2007 18:44:36 -0800

> software was loaded in the software agent generating the DN.

Of course I meant "whatever *schema* was loaded in the software agent." By the 
way, RFC4514 *does* give a table of attribute types that are required to be 
supported.
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Howard Chu <[email-masked]>
Date: Thu, 06 Dec 2007 18:55:30 -0800

> going in the krb-wg mailing list.

Sorry if I've missed the previous discussion context. The mapping described in 
draft 03 didn't make any sense anyway; the X.509 certificate's subjectName is 
already the peer's DN in DER. Why wasn't that used directly? Converting it to 
string format and storing it in an additional certificate field seems like a 
complete waste of effort.
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Howard Chu <[email-masked]>
Date: Fri, 07 Dec 2007 08:26:21 -0800

Jeffrey Hutzelman wrote:
> 
> --On Thursday, December 06, 2007 06:37:01 PM -0800 Howard Chu
> <[email-masked]> wrote:
> 
>> Just fyi, RFC2253 has been superseded by RFC4514.
> 
> Yes, but RFC4120 refers to RFC2253, for obvious reasons.
> 
> Bear in mind that here we are talking about the suitability of the
> representation described in RFC2253 and its successors as a means of
> constructing Kerberos principal names.  So, the bullet points Larry quoted
> (which mostly came from my review of PKU2U) are not unqualified problems
> with RFC2253; they are simply ways in which the representation defined
> there is not a distinguished encoding.

OK, thanks for bringing me up to speed.

> I think what we're looking for here is...
> 
> - How much does the WG believe it matters that the form of a
>   NT_X500_PRINCIPAL name be a distinguished encoding?
> - Do we care about the loss of information; particularly, of which
>   arm of the DirectoryString CHOICE was used for attribute values of
>   that type?

I take it these questions are really about whether there's ambiguity, e.g if
two distinct DNs may get mapped to the same principal name. I guess that may
be possible, especially if your spec is married to RFC2253. In practice the
reverse is more likely; since principal names are case-sensitive and the
common naming attributes used in DNs are case-insensitive, you may find that
multiple representations of the same DN get mapped (incorrectly) to distinct
principals.

At any rate, it's unfortunate that RFC4120 is tied to RFC2253 since the LDAP
representation of X.500 DNs is fundamentally flawed. The RFC4120 language
refers to X.500, and uses the X.500 notation C=US/O=OSF in its example for an
X.500 realm name. That's fine, but in RFC2253 this would be O=OSF,C=US -
slashes aren't used as separators, and RDN components are listed in
least-significant-first order, while the X.500 convention uses slashes and
lists RDN components most-significant-first.

As for the loss of information: the choice of DirectoryString shouldn't be an
issue; you're required to encode the DN using the narrowest type that
accommodates the characters in the string. E.g. "abc" must be a
PrintableString; it would be illegal to encode it as a UniversalString.

> - What can we use that meets these requirements and is somewhat human
>   readable.
> 
> I'm not sure that resolving this issue is within our scope, but we can
> certainly discuss it.

It seems to me that when you're working with an X.509 certificate that already 
contains a DN in DER form, there's no reason to use the DN in lobotomized 
string form. Rereading RFC4120 it seems the NT_X500_PRINCIPAL name form was 
only included to carry the name around when the original X.500 DN wasn't 
present. When the original name *is* present, it ought to be used instead.

I think it would be best to make NT_X500_PRINCIPAL actually mean what it says
- use the X.500 convention and not the LDAP spec. Hm, it looks like RFC4120
already does this:

     X.500 names contain an equals sign (=) and cannot contain a colon (:)
     before the equals sign.  The realm names for X.500 names will be
     string representations of the names with components separated by
     slashes.  Leading and trailing slashes will not be included.  Note
     that the slash separator is consistent with Kerberos implementations
     based on RFC 1510, but it is different from the separator recommended
     in RFC 2253.

Which means it really *isn't* tied to RFC2253 - it's a negative reference; the
recommendations in it are specifically ignored. This subsequent text can only
be considered a bug in the spec:

     A name type of NT-X500-PRINCIPAL SHOULD be used when a name from an
     X.509 certificate is translated into a Kerberos name.  The encoding
     of the X.509 name as a Kerberos principal shall conform to the
     encoding rules specified in RFC 2253.

Because a realm name is a part of the principal name, and the realm name
explicitly does not conform to RFC2253, therefore a principal name cannot
conform to RFC2253.
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 7 Dec 2007 10:37:39 -0600

> explicitly does not conform to RFC2253, therefore a principal name cannot

In RFC4120 Realm and PrincipalName are distinct types, and principal
names aren't treated as encompassing a realm name either.

Nico

---

From: Howard Chu <[email-masked]>
Date: Fri, 07 Dec 2007 08:59:15 -0800

> names aren't treated as encompassing a realm name either.

OK, good point. But it's a strange inconsistency; when using X.500-style names 
you're using a different set of rules to map X.500 names to Realms than to 
PrincipalNames.

Given the convention to print principal names with their realm attached 
"<principal>@<realm>" and following this to the letter, a user
	/c=US/o=Foo/cn=Joe in the realm C=US/O=FOO

would be displayed as CN=JOE,O=FOO,C=US@C=US/O=FOO ?

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 7 Dec 2007 11:04:37 -0600

> you're using a different set of rules to map X.500 names to Realms than to 

It is strange.  Users, sysadmins, developers, the krb5 APIs, all treat
the realm name as part of the principal name.

> would be displayed as CN=JOE,O=FOO,C=US@C=US/O=FOO ?

Hmmmm, good point.  I don't know.

Nico

---

From: Olga Kornievskaia <[email-masked]>
Date: Fri, 07 Dec 2007 14:22:23 -0500

Larry Zhu 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.
>
While moving pku2u2 draft forward is important, I think the lack of 
mapping methods specification will be a problem for implementing pu2u 
draft.

---

From: "Kevin Coffman" <[email-masked]>
Date: Fri, 7 Dec 2007 15:06:59 -0500

On Dec 6, 2007 7:04 PM, Larry Zhu <[email-masked]> wrote:
> 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.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 7 Dec 2007 15:29:47 -0600

> at the cost of interoperability down the road.

Er, why is a mapping needed at all?  PKU2U isn't Kerberos V.  It's a
GSS-API mechanism using PKIX credentials but built with Kerberos V and
PKINIT technologies.

Why, then, must we make a square peg (DNs, SANs, ...) fit into a
triangular slot (PrincipalName and Realm Kerberos V types) when the
consumers of this mechanisms don't need to put anything at all into
those triangular slots??

That we're using Kerberos V messages as the basis for PKU2U is not a
good enough reason for trying this crazy thing.

I.e., I'm saying that GSS_Display_name() on a PKU2U MN should behave
much like you would expect for any PKIX GSS-API mechanism: it should
return a human-readable representation of a canonical PKIX certificate
name.  We quickly run into the lack of such a thing -- is it the DN?  or
some SAN? (that's a rethorical question, please see KITTEN WG's naming
extensions before answering it).

Similarly for GSS_Import_name() followed by GSS_Canonicalize() or
GSS_Init_sec_context() with the PKU2U OID.

We just don't need a generic PKIX->Kebreros V name mapping in order to
have a PKIX GSS-API mechanism.  Such a mapping might be useful in some
contexts, but that would be completely orthogonal to PKU2U.

Nico

---

From: "Kevin Coffman" <[email-masked]>
Date: Fri, 7 Dec 2007 16:42:34 -0500

> contexts, but that would be completely orthogonal to PKU2U.

Fair enough.  Then to re-ask Olga's question, what is the output of
GSS_export_name()?  Is it the der encoded DN, the der encoded cert?

K.C.

---

From: Olga Kornievskaia <[email-masked]>
Date: Fri, 07 Dec 2007 16:57:26 -0500

Nicolas Williams wrote:
> Er, why is a mapping needed at all?  
I think mapping is the wrong term here. I think what pu2u is lacking is 
a description of what should the output of gss_display_name() and 
gss_export_name() be? Note that gss_display_name() can be as it was 
previously proposed an rfc2253 string representation of the DN. What I 
would like to know is what is a canonical name form for the pu2u protocol?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 7 Dec 2007 16:06:20 -0600

> GSS_export_name()?  Is it the der encoded DN, the der encoded cert?

This is a difficult question.  The DN will prove unsatisfactory.  There
is, effectively, no useful canonical certificate name.  But having the
whole certificate be the exported name token's contents will likely
prove unsatisfactory also -- who wants to update name-based ACLs
whenever a principal's public keys change?

If we really must then I say use the encoded certificate.

Other options:

 - Define a type which includes all the thing from the given certificate
   that are reasonable to include in this context.  E.g., an encoded
   TBSCertificate with dummy serialNumber, validity,
   subjectPublicKeyInfo, issuerUniqueID and subjectUniqueID values, or a
   new type based on TBSCertificate minus those fields that are not
   desirable in this context.  (Certificate extensions complicate this.)

 - We could also define a new certificate extension (a SAN, perhaps?)
   that explicitly provides/describes a canonical name representation
   for it.  When absent the implied canonical name representation could
   be one of the options described above.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 7 Dec 2007 16:13:04 -0600

> would like to know is what is a canonical name form for the pu2u protocol?

Yes, that _is_ the problem, but mapping a PKIX cert/DN to Kerberos V
PrincipalName and Realm values doesn't seem like a very good answer to
me.  It is _an_ answer, and it might even make it easier to use PKU2U
with applications that know only about Kerberos V, but I don't think
that's worthwhile.

Now, one of the GSS-API extensions we're considering is a new version of
GSS_Display_name() that takes a desired name type input parameter and
either fails or displays the given MN in the syntax of the given name
type.  E.g., given a krb5 principal name with two components and of
NT-SRV-HST type or of NT-UNKNOWN type but with a first component
matching a known service name, then it could be displayed as a
GSS_C_NT_HOSTBASED_SERVICE name in the generic service@hostname syntax.

But that's not enough -- we still need to consider the exported name
token format.  We could also provide multiple exported name token
formats and a new version of GSS_Export_name() that allows the caller to
select what name form to use (DN, some SAN, the whole cert, the subject
public key [think SSH pubkeys], etc...).

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 7 Dec 2007 16:33:52 -0600

> public key [think SSH pubkeys], etc...).

I should note that even then we must settle on a single canonical (or
default) exported name token format for PKIX certificates.  If we had a
new version of GSS_Export_name() as described above then using the
encoded certificate as the canonical exported name token might not be
too bad.

Though still, it'd be a long time before apps were deployed that knew to
use the new version of GSS_Export_name(), and even then one would have
to consistently pick a suitable exported name token form in order to
have authorization work consistently.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Howard Chu <[email-masked]>
Date: Sat, 08 Dec 2007 01:21:56 -0800

>> public key [think SSH pubkeys], etc...).

If being human-readable is still a requirement, then it seems that a string 
representation of the DN is still the best choice. You just have to define 
what restrictions you want to place on it to guarantee a canonical form; you 
could start with RFC4514 but add further constraints: require DER for values 
of unknown syntax, restrict the use of escape characters, force the case of 
case-insensitive string values, etc.

---

From: Leif Johansson <[email-masked]>
Date: Sat, 08 Dec 2007 23:48:48 +0100

> whenever a principal's public keys change?

Few more options for the exported name:

- Use a hash of the certificate as the identifier IF you are
only interested in the public-key for the purpose of ACLs.
This is the option which is the least likely to introduce
security problems IF you pick a good hashalg AND are
willing to set ACLs per certificate. This effectively disables
PKI-based trust.

- If you want to use PKI-based trust-models in PKU2U
then I think you need the issuer+serial (and this still
leaves the question of how to represent the issuer). In
general you need the entire chain of a certificate up to a
trust-anchor to uniquely identify it!

This touches on real problems of name uniqueness and
how to manage trust in PKI-based applications. In the
identity-federation-space we wrestle with these problems
on a daily basis. The lack of a managed namespace for
PKIX certs have made the use of structured PKIs
difficult to say the least :-)

As has been noted a displayname and string-representation
of a certificate is an issue which transcends this wg. Perhaps
this should go into a separate draft with review from a
larger portion of the community.

    Cheers Leif

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 9 Dec 2007 00:26:49 -0600

> If being human-readable is still a requirement, then it seems that a string 

It's a requirement for GSS_Display_name().  It is not a requirement that
the result GSS_Display_name() be canonical, IIRC.

GSS_Export_name(), on the other hand, outputs an exported name token --
an octet string -- suitable only for octet-wise comparison with other
exported name tokens, and for importing via GSS_Import_name() to obtain
an equivalent MN NAME object again.

> case-insensitive string values, etc.

That will certainly do for GSS_Display_name().

And if it is a canonical and machine-readable representation of DNs then
we can also use it for the exported name token.

The DN will often not be very useful (that's why we have SANs), but
without GSS naming extensions there's not much we can do to improve the
situation, and we shouldn't hold up PKU2U either.  So the DN it must be.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 9 Dec 2007 23:01:34 -0600

> only interested in the public-key for the purpose of ACLs.

Actually, I've realized now that any format that doesn't support this:

GSS_Export_name(
    GSS_Canonicalize_name(
	GSS_Import_name(<some type>, <human-entered name>)))

won't comply with RFC2743.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Leif Johansson <[email-masked]>
Date: Mon, 10 Dec 2007 10:09:22 +0100

> won't comply with RFC2743.
I don't understand. Do you mean that this call must be meaningful,
idempotent or what?

    Cheers Leif

---

From: Martin Rex <[email-masked]>
Date: Mon, 10 Dec 2007 17:03:56 +0100 (MET)

> would like to know is what is a canonical name form for the pu2u protocol?

The two approaches taken by SPKM- and SPKM-derived mechanisms that
I have seen for the exported binary canonical name is
either a string representation (similar to the Kerberos canonical
name) or a ASN.1-DER encoded distinguished name.

A certificate doesn't work, because for ACL maintenance the
procedure is

 gss_export_name(gss_canonicalize_name(gss_import_name(printable_name),mech))

A arbitrary peers' certificate might be available upon authenication,
but it is usually not available during ACL maintenance.

-Martin

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 10 Dec 2007 17:23:00 -0800

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

>> considerations

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]