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

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

On Mon, Jan 28, 2008 at 03:38:17PM -0500, Jeffrey Hutzelman 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.

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

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

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: Nicolas Williams <[email-masked]>
Date: Mon, 28 Jan 2008 17:55:04 -0600

On Mon, Jan 28, 2008 at 03:46:07PM -0800, Henry B. Hotz wrote:
> Since I'm not on that list, I'll throw my 2 cents in here:

[Cc'ing the KITTEN list and you, dropping the KRB WG list.]

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

Well, that might work given the text I gave Larry in a very specific
context, namely that if one of the arguments to GSS_Compare_name() is a
NAME object imported with GSS_Import_name() but not canonicalized and
the other argument is a NAME object that is what I called a CMN (and
therefore there's an underlying cert) then the comparison could be true
if that cert had a id-pkinit-san SAN with that krb5 principal name.

I'm not sure that we actually want GSS_Compare_name() to sport such
behaviour, as opposed to having a new function that does, because it's
pushing things a bit to say that the two NAME objects passed to it are
equal representations of the same principal.  They are representations
of the same principal name, just not _equal_ representations of it.

I think I'd want a GSS_Match_name() function, or something, to embody
this kind of functionality.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 29 Jan 2008 12:42:35 -0500

> of the same principal name, just not _equal_ representations of it.

That's OK.  GSS_Compare_name is defined to return a true result when the 
names represent the same entity, not only when they are the same.  This 
appears to be exactly what GSS_Compare_name is for, so no, I don't think we 
need a new interface for this.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 29 Jan 2008 13:20:37 -0600

> need a new interface for this.

OK, good.  Then I think the text I gave Larry is pretty close.

I suppose we need to decide what name-types *must* be supported.  I
propose:

 - GSS_C_NT_DN (because that's what the canonical names will be based
   on!  it simply must be supported)

 - GSS_C_NT_HOSTBASED_SERVICE (because most acceptors will be hosts and
   generic GSS apps will be using this name-type)

 - GSS_KRB5_PRINCIPAL_NAME (because, PKU2U being built on PKINIT
   technology, it should be trivial to support this when id-pkinit-san
   is present)

The other name-types should all be optional.

---

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

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