Subject: Re: [kitten] I-D Action: draft-ietf-kitten-gssapi-naming-exts-11.txt

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 26 Oct 2011 18:29:00 +0000

Kept meaning to ask about this. There's a sentence at the very end, in
section 9:

"This is analogous to the SAML permanentIdentifier attribute and has
comparable security and privacy properties and implications."

The discussion is around using a naming extension as a unique identifier
in cases where the mechanism is otherwise not exposing a unique peer
identity. There's no such thing as a "permanentIdentifier" in SAML, and
while this might be referring to the NameID format of "persistent", I
think it's not specifically confining itself to directed/pairwise
identifiers.

I'd strike the sentence. If an example is really needed, then the allusion
to SAML here will be more involved than just that.

-- Scott

---

From: Leif Johansson <[email-masked]>
Date: Thu, 27 Oct 2011 09:10:15 +0200

> to SAML here will be more involved than just that.

Why not simply say

"This is analogous to the SAML
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent NameID format and
has comparable security and privacy properties and implications."

I give you that you could (and might want to) include much more detail
to make this a really understandable example wo prior SAML knowledge
but nevertheless I believe it would be good to have something on this
important topic.

	cheers Leif

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 27 Oct 2011 14:38:35 +0000

>has comparable security and privacy properties and implications."

Obviously that's the "fix", but I think that's confusing in context
because that format is about much more than uniqueness, and I think all
you're trying to say in that sentence is that the naming attributes might
themselves provide a unique (possibly omnidirectional) identifier. In
other words, any SAML attribute of NameID might end up in there and be
used for that purpose, not just (or even predominantly) that one.

>but nevertheless I believe it would be good to have something on this

I think I'd avoid the SAML reference, then, and just state something more
general. Or I'd use more than one SAML example, because you don't just
mean a directed ID here.

-- Scott

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 27 Oct 2011 16:56:09 +0000

On 10/27/11 12:48 PM, "Nico Williams" <[email-masked]> wrote:
>
>On the other hand, it's hard to see how to get a name attribute that
>is "permanent identifier" into a credential's anonymous name.  How
>does the permanent identifier get authenticated?

That's up to the mechanism, isn't it?

>I think this calls
>for having a more complete discussion of attribute issuer, and until
>we have that concept in the API I'd feel more comfortable striking the
>whole paragraph (indeed, I'll have to review the whole I-D to make
>sure that's not the only place where we implicitly depend on a notion
>of attribute issuer).

I don't think this paragraph depends on that notion any more than the
whole spec does. Identifiers aren't the only attributes that matter in a
security context.

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Thu, 27 Oct 2011 12:09:38 -0500

> That's up to the mechanism, isn't it?

Sure.  I did not express myself well.  I was thinking of some
credential that's truly anonymous and you want to add this attribute,
and the mechanism lets you.  But adding it hardly implies that the
attribute is authenticated, and an unauthenticated permanent
identifier isn't useful, is it?

Now, I can see something like the Kerberos mechanism using an
authenticated credential to obtain an anonymous credential that
contains authenticated permanent identifier name attributes.  And that
may be the point, but anytime we talk about an authenticated name
attribute I come back to: who's the issuer?  Without a notion of
issuer the issuer has to be the same as the issuer of the credential
(the realm, if there is one, of the name, keeping in mind that realm
here is a mechanism-specific concept).

And that means that you couldn't have an issuer-less anonymous
credential that contains authenticated attributes, because while those
attributes might well be like certificates, the fact that we don't
expose attribute issuers means that an issuer-less anonymous
credential cannot bear any authenticated name attributes.

Maybe I'm making much ado about nothing here.  But I'm rather bothered
by the lack of an issuer concept.  (Moreover, an issuer concept would
make explicit and generic the Kerberos concept of "realm", a nice side
benefit!)

> whole spec does. Identifiers aren't the only attributes that matter in a

Arguably the lack of a concept of issuer is a defect in the GSS-API
v2u1 (see above), and also a defect in name attributes.  That we can
fix it separately is certainly true, but I'd like to have a discussion
as to why not fix it now.

Nico
--

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 27 Oct 2011 17:18:20 +0000

>identifier isn't useful, is it?

It depends on the relationship between the caller of the set operation and
the eventual consumer of the attributes.

>may be the point,

That's definitely the point of the paragraph.

> but anytime we talk about an authenticated name

Yes, this has certainly come up.

>as to why not fix it now.

I'm not saying I think it isn't needed, I was just saying its lack is not
in any way specific to that paragraph. Perhaps the paragraph just
highlights the problem more strongly than other text in the document.

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Thu, 27 Oct 2011 11:48:28 -0500

> general. Or I'd use more than one SAML example, because you don't just

The reference to SAML is not necessary to understand the preceding
sentence, so I agree: remove the SAML reference.

does the permanent identifier get authenticated?  I think this calls

I'd actually feel more comfortable adding a function by which to
obtain the NAME of the issuer of a given attribute.  I believe Sam
does not want to hold up the I-D for that, that he believes that we
can address that later, but I don't see why we could not address it
now.

Nico
--