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

From: [email-masked]
Date: Wed, 09 Feb 2011 04:15:01 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF.

	Title           : GSS-API Naming Extensions
	Author(s)       : N. Williams, L. Johansson
	Filename        : draft-ietf-kitten-gssapi-naming-exts-09.txt
	Pages           : 16
	Date            : 2011-02-09

The Generic Security Services API (GSS-API) provides a simple naming
architecture that supports name-based authorization.  This document
introduces new APIs that extend the GSS-API naming model to support
name attribute transfer between GSS-API peers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Cantor, Scott E." <[email-masked]>
Date: Wed, 9 Feb 2011 16:42:08 +0000

A couple of comments on this draft:

In section 6, I was a little concerned by the paragraph about potential spoofing of attribute names, and wondered why, if that's ultimately going to be a problem, we wouldn't just dictate a "primary" name component at the front of each name string that identifies the "context" (to use the term in the draft).

It already says that names are effectively multi-part, and space-delimited. Why not just make it formally:

"prefix namepart( namepart)*"

Either with a registry, or with an OID/URI to signify the "context".

Also a nit, at the end of section 9:
s/the SAML permanentIdentifier/SAML's "persistent" name identifier format/

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Wed, 09 Feb 2011 13:32:04 -0500

>>>>> "Cantor," == Cantor, Scott E <[email-masked]> writes:

    Cantor,> A couple of comments on this draft: In section 6, I was a
    Cantor,> little concerned by the paragraph about potential spoofing
    Cantor,> of attribute names, and wondered why, if that's ultimately
    Cantor,> going to be a problem, we wouldn't just dictate a "primary"
    Cantor,> name component at the front of each name string that
    Cantor,> identifies the "context" (to use the term in the draft).

I think there are a number of cases where you want one component names:

* local attributes typically should be singletons

* I'd expect things like the name of the SAML assertion from AAA for
  ABFAB to be a singleton. There's no reason to make it multi-component
  as its entire value is dictated by the spec.

* I'd expect that names designed for GSS-API that are URNs might well
  not need multiple components.

That was my reasoning at least.

---

From: "Cantor, Scott E." <[email-masked]>
Date: Wed, 9 Feb 2011 19:14:52 +0000

> I think there are a number of cases where you want one component names:

Sure. I should have clarified, I can imagine allowing for that (though strictly speaking its just an optimization), but I thought it seemed odd to not just propose a comprehensive solution that addressed all the cases. I really wasn't sure, for example, what SAML attributes would be expected to call themselves. Maybe that just has to be discussed yet.

I think its ok to leave the specifics for SAML, PKIX, etc to other places, but I think there needs to be a clear framework to plugin to.

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Wed, 09 Feb 2011 14:33:50 -0500

>> I think there are a number of cases where you want one component
    Cantor,> Sure. I should have clarified, I can imagine allowing for
    Cantor,> that (though strictly speaking its just an optimization),
    Cantor,> but I thought it seemed odd to not just propose a
    Cantor,> comprehensive solution that addressed all the cases. 

I think saying that a document creating name attributes needs to make
sure the prefix is unique is sufficient.  I thought tthat's what I did.

I
    Cantor,> really wasn't sure, for example, what SAML attributes would
    Cantor,> be expected to call themselves. Maybe that just has to be
    Cantor,> discussed yet.

Right.  That's not defined by this draft any more, but will be in an
update to draft-ietf-abfab-gss-eap-naming.  If you think there's enough
there that we want something between that document and the core naming
exts document, let's discuss what would go there.

    Cantor,> I think its ok to leave the specifics for SAML, PKIX, etc
    Cantor,> to other places, but I think there needs to be a clear
    Cantor,> framework to plugin to.

Agreed.
Perhaps I'm missing some layer that's still needed.

---

From: "Cantor, Scott E." <[email-masked]>
Date: Wed, 9 Feb 2011 19:50:56 +0000

> sure the prefix is unique is sufficient.  I thought tthat's what I did.

I didn't exactly read it as being that explicit, so maybe I'm just arguing over the wording. I'll look at it again.
 
> exts document, let's discuss what would go there.

I guess as long as we think its ok for other use cases involving SAML and GSS to reference an EAP-related RFC , that's fine. For example, my SAML mechanism (and Klaas') would want to support this kind of thing, and we certainly want one convention for exposing SAML attributes here.

Or we can factor that bit out, obviously.

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Wed, 09 Feb 2011 15:27:37 -0500

>> I think saying that a document creating name attributes needs to
    >> make sure the prefix is unique is sufficient.  I thought tthat's
    >> what I did.

    Cantor,> I didn't exactly read it as being that explicit, so maybe
    Cantor,> I'm just arguing over the wording. I'll look at it again.

I'm happy to improve the wording.
 
    >> Right.  That's not defined by this draft any more, but will be in
    >> an update to draft-ietf-abfab-gss-eap-naming.  If you think
    >> there's enough there that we want something between that document
    >> and the core naming exts document, let's discuss what would go
    >> there.

    Cantor,> I guess as long as we think its ok for other use cases
    Cantor,> involving SAML and GSS to reference an EAP-related RFC ,
    Cantor,> that's fine. For example, my SAML mechanism (and Klaas')
    Cantor,> would want to support this kind of thing, and we certainly
    Cantor,> want one convention for exposing SAML attributes here.

Do you think your mechanism would actually want the same prefix as
GSS-EAP?  Are the semantics actually that similar?  I'd assumed you'd
want the same basic structure: "prefix saml_name_type saml_name" but a
different prefix.

---

From: "Cantor, Scott E." <[email-masked]>
Date: Wed, 9 Feb 2011 20:33:07 +0000

> I'm happy to improve the wording.

It may be that an example will be sufficient (or in lieu of that just having an existence proof elsewhere).

> want the same basic structure: "prefix saml_name_type saml_name" but a

I don't think there's any significant difference, it's a SAML attribute in an assertion that's obtained in a verifiably secure way from a trusted source as part of an act of authentication (speaking at least of the basic use case in abfab).

The fact that the delivery is quite different and the verification process is different doesn't change the semantic.

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Wed, 09 Feb 2011 15:58:00 -0500

>> Do you think your mechanism would actually want the same prefix
    >> as GSS-EAP?  Are the semantics actually that similar?  I'd
    >> assumed you'd want the same basic structure: "prefix
    >> saml_name_type saml_name" but a different prefix.

    Cantor,> I don't think there's any significant difference, it's a
    Cantor,> SAML attribute in an assertion that's obtained in a
    Cantor,> verifiably secure way from a trusted source as part of an
    Cantor,> act of authentication (speaking at least of the basic use
    Cantor,> case in abfab).

OK, that's different than how I was thinking about this.
I'll ponder while updating gss-eap-naming and may end up recommending
renaming that document if I agree with you.