Subject: [kitten] AD review of draft-ietf-kitten-gssapi-naming-12

From: Stephen Farrell <[email-masked]>
Date: Thu, 08 Mar 2012 14:16:43 +0000

Hi,

Shawn has requested publication of this draft. This is my AD
review of that prior to starting IETF last call.

I've 3 questions that I think need answering. I think a revised
I-D is likely needed before IETF LC to handle those. (If not then
you'll argue about that:-) I've also some other comments that
can be handled before or during IETF LC along with whatever
other comments crop up.

Things that need handling:

1. Shouldn't this UPDATE something? Maybe 2743 and 2744? (I
don't care much really, but others do;-)

2. The IANA considerations section doesn't seem clear enough
for IANA to action. What's the update rule, what's the name
of the registry, ...

3. Nico's address bounces. Please fix unless there's some
good reason - is there?

Other comments/questions, (not blocking):-

- Section 6 is a bit unclear. In particular the "otherwise" in the
2nd para on p8 - does that mean "if there's no colon" or "if there's
no space and no colon"? The clarity of this section could be
improved, maybe by laying it out as a bulleted list.

- I don't really get the 2nd last paragraph of section 6, what's
that saying?

- The last para of section 6 is also a bit unclear, I think you
mean where the administrator controls all aspects (e.g.  both the
KDC and the relying applications) but I'm not 100% sure.

- 7.1, last sentence - would it be better to spell this out some
more? E.g. maybe say that ordering of SET OF OCTET STRING MUST
be preserved.

- The danger in the 2nd last para of 7.6 is not crystal clear.
Might be worth spelling that out some more.

- An example or two would be nice, or a pointer to such if its
easily referenced.

Thanks,
Stephen.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 08 Mar 2012 14:20:35 +0000

Sorry one more thing that can be handled along with IETF
LC - I-D nits complains [1] about some of the references
being unused. Seems worth fixing along with other stuff
as well.

S.

[1] 
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-kitten-gssapi-naming-exts-12.txt

On 03/08/2012 02:16 PM, Stephen Farrell wrote:
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

---

From: Leif Johansson <[email-masked]>
Date: Thu, 08 Mar 2012 15:27:16 +0100

On 03/08/2012 03:16 PM, Stephen Farrell wrote:
> 
> Hi,
> 
> Shawn has requested publication of this draft. This is my AD review
> of that prior to starting IETF last call.
> 
> I've 3 questions that I think need answering. I think a revised I-D
> is likely needed before IETF LC to handle those. (If not then 
> you'll argue about that:-) I've also some other comments that can
> be handled before or during IETF LC along with whatever other
> comments crop up.
> 
> 1. Shouldn't this UPDATE something? Maybe 2743 and 2744? (I don't
> care much really, but others do;-)
> 

Not sure I agree. The API proposed in this draft are completely
orthogonal to base GSS-API. Why is this an update?

> 2. The IANA considerations section doesn't seem clear enough for
> IANA to action. What's the update rule, what's the name of the
> registry, ...

I disagree. The section sais that we may want a registry sometime
in the future not that we are creating one now.

> 
> 3. Nico's address bounces. Please fix unless there's some good
> reason - is there?

Probably not. Nico - which address do you want me to use?

> Other comments/questions, (not blocking):-

Haven't thought about those yet....

	Cheers Leif

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 08 Mar 2012 14:31:35 +0000

On 03/08/2012 02:27 PM, Leif Johansson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

Personally, I don't care much. But it does extend the
GSS-API. I'll go with what the WG want here but other
ADs might want this. (Was that specifically considered by
the WG?)

> in the future not that we are creating one now.

Ah, sorry, my fault. I read "This document creates a namespace
of GSS-API name attributes." as creating a registry.

Maybe say: "This document creates a namespace of GSS-API name
attributes but no new IANA registry" so even dummies like me
don't get confused:-) Consider this one non-blocking now.

> Probably not. Nico - which address do you want me to use?

This I think should be done so the authors can see any IETF
LC discussion.

Thanks,
S

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk9YwcAACgkQ8Jx8FtbMZneo9ACaAueVLwH8liRuiv95cg+NzYBH
> yUgAn0qZp3DsH0KvmPg4lRxzU12dl0YX
> =8xDs
> -----END PGP SIGNATURE-----

---

From: Nico Williams <[email-masked]>
Date: Thu, 8 Mar 2012 10:04:54 -0600

> Probably not. Nico - which address do you want me to use?

[email-masked]

Also, please remove the mailing address.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 8 Mar 2012 10:08:49 -0600

> ADs might want this. (Was that specifically considered by

I've no problem with saying that all extensions to the GSS-API must
update RFC2743 and, if they specify C bindings, also RFC244.

I think an argument can be made this should be true w.r.t. all
Standards-Track API-specifying RFCs.

> don't get confused:-) Consider this one non-blocking now.

Sure.

> This I think should be done so the authors can see any IETF

Yes please (see separate e-mail).  And thanks for noticing (and thanks
to Leif for fixing it).

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 08 Mar 2012 12:56:21 -0500

2) If you have no IANA actions, please state "This specification has no
actions for IANA."
You're much less likely to get questions if you use those exact words.

IANA has complained in the past if an IANA Considerations section
included anything besides current actions for IANA.
My recommendation here would be to start the IANA considerations section
with "This Specification has no  actions for IANA," in its own
paragraph.

Then include whatever text the WG believes is necessary.
However we should be prepared to move that text elsewhere if requested
by IANA.

---

From: Martin Rex <[email-masked]>
Date: Fri, 9 Mar 2012 03:56:21 +0100 (MET)

Nico Williams wrote:
> >>Stephen Farrell wrote:

Actually, I would prefer to not use an "Updates:" for 2743, 2744.

Given the mess there is with updates to STD-13 (DNS 1034/1035),
I'm wondering whether there should be a distinction of metadata
into "Extends:" and "Changes:", rather than lumping that together
under Updates:.

> Standards-Track API-specifying RFCs.

I do not see a big difference between new optional API-calls being
added to an API standard, and new optional protocol features being
added to an existing protocol standard.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 9 Mar 2012 04:21:13 +0100 (MET)

> > > ADs might want this. (Was that specifically considered by

btw.  rfc4401 (GSS-PRF) and rfc5178 (I18N support for names)
do not carry an "Updates: 2743, 2744" either, although both probably
have a much broader applicability than this API extension
(i.e. can be implemented with more gss-api mechanisms than this one).

-Martin

---

From: Leif Johansson <[email-masked]>
Date: Sun, 11 Mar 2012 22:05:29 +0100

On 03/09/2012 04:21 AM, Martin Rex wrote:
> Martin Rex wrote:
>> 
>> Nico Williams wrote:
>>> 
>>> Stephen Farrell wrote:
>>>>> Stephen Farrell wrote:
>>>>>> 
>>>>>> 1. Shouldn't this UPDATE something? Maybe 2743 and 2744?
>>>>>> (I don't care much really, but others do;-)
>>>> 
>>>> GSS-API. I'll go with what the WG want here but other ADs
>>>> might want this. (Was that specifically considered by the
>>>> WG?)
> 
> btw.  rfc4401 (GSS-PRF) and rfc5178 (I18N support for names) do not
> carry an "Updates: 2743, 2744" either, although both probably have
> a much broader applicability than this API extension (i.e. can be
> implemented with more gss-api mechanisms than this one).

For the record I agree with Martin but don't think it is worth holding
up the draft over.

Stephen do you think this is an actual issue with the IESG? If not
I propose we change nothing.

	Cheers Leif

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 11 Mar 2012 21:10:34 +0000

Hi Leif,

> I propose we change nothing.

I'm ok with whatever the WG want as I said.

Probability of a discuss is hard to tell but worst
case is another IETF LC which'll generate zero
comments, so +2 weeks.

Soon's -13 appears with fixed email/affiliation
for Nico I'll push it on.

S

> iEYEARECAAYFAk9dE5kACgkQ8Jx8FtbMZndhTwCfQWroRF8sNMl75SnvAMNbzPUi
> a7sAoLmmXoOStkSJhRqdJ2qk4cezj4dv
> =l07N

---

From: Leif Johansson <[email-masked]>
Date: Sun, 11 Mar 2012 22:16:22 +0100

On 03/08/2012 06:56 PM, Sam Hartman wrote:
> 2) If you have no IANA actions, please state "This specification
> has no actions for IANA." You're much less likely to get questions
> if you use those exact words.
> 
> included anything besides current actions for IANA. My
> recommendation here would be to start the IANA considerations
> section with "This Specification has no  actions for IANA," in its
> own paragraph.

ok, doing that!

---

From: Leif Johansson <[email-masked]>
Date: Sun, 11 Mar 2012 22:45:07 +0100

> improved, maybe by laying it out as a bulleted list.

Actually I think its not. You're supposed to read it as

[<name-form> ] <uri-or-local-name>

I.e you can have a nameform even if you have a local name so
it is actually written correctly. Do we need ABNF (please say no)?

> - I don't really get the 2nd last paragraph of section 6, what's

Nico, I think you wrote that one... can you elaborate?

> more? E.g. maybe say that ordering of SET OF OCTET STRING MUST

Sure, how about "Any implementation of SET OF OCTET STRING for
use by this specification MUST preserve order."

> Might be worth spelling that out some more.

The WG argued over this one extensively. I need a specific suggestion
if we are to argue some more :-)

> - An example or two would be nice, or a pointer to such if its

Example of API calls in C you mean? We could always point to project
moonshot.

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Sun, 11 Mar 2012 23:22:55 +0100

On 03/11/2012 10:10 PM, Stephen Farrell wrote:
> 
> Hi Leif,
> 
> On 03/11/2012 09:05 PM, Leif Johansson wrote: On 03/09/2012 04:21
> AM, Martin Rex wrote:
>>>> Martin Rex wrote:
>>>>> 
>>>>> Nico Williams wrote:
>>>>>> 
>>>>>> Stephen Farrell wrote:
>>>>>>>> Stephen Farrell wrote:
>>>>>>>>> 
>>>>>>>>> 1. Shouldn't this UPDATE something? Maybe 2743 and
>>>>>>>>> 2744? (I don't care much really, but others do;-)
>>>>>>> 
>>>>>>> ADs might want this. (Was that specifically considered
>>>>>>> by the WG?)
>>>> 
>>>> do not carry an "Updates: 2743, 2744" either, although both
>>>> probably have a much broader applicability than this API
>>>> extension (i.e. can be implemented with more gss-api
>>>> mechanisms than this one).
> 
> For the record I agree with Martin but don't think it is worth
> holding up the draft over.
> 
>> Probability of a discuss is hard to tell but worst case is
>> another IETF LC which'll generate zero comments, so +2 weeks.
> 
>> Soon's -13 appears with fixed email/affiliation for Nico I'll
>> push it on.

OK, I don't

---

From: Nico Williams <[email-masked]>
Date: Sun, 11 Mar 2012 18:30:37 -0500

>> 3. Nico's address bounces. Please fix unless there's some

Oh, FYI, please make my company name "Cryptonector, LLC".  This can be
done as a note tot he RFC-Editor.

> [<name-form> ] <uri-or-local-name>

No, more like:

<attribute-name> [<attribute-name> ...]

Where <attribute-name> is

<local-attribute> | <URI>

And <local-attribute> is a sequence of printable ASCII characters not
including space or colon, while <URI> is, well, a URI, and
specifically has a colon and no spaces.

> it is actually written correctly. Do we need ABNF (please say no)?

I think we need some examples, and possibly ABNF yes.

Here are some examples:

tag:foo.example,2012#attr1

local_foo

local_foo tag:foo.example,2012#attr1

local_foo local_bar

tag:bar.example,2012#attrX tag:foo.example,2012#attrY

> Nico, I think you wrote that one... can you elaborate?

Although I do not recall writing that I can explain the text, I think,
though I'm not sure that I can write much better text.  This paragraph
needs to be read in conjunction with section 5, but it belongs in
section 6.

The idea is that an attribute name like "e-mail address" is or may not
be enough and may need some additional contextual information.  This
contextual information is to be "prefixed", effectively, to the part
of the attribute name that says "e-mail address".  In particular, this
paragraph warns not to use ASCII space as this is used to split up the
complete attribute name into a list of attribute names.  What this
paragraph does not (and should not) do is say much more about how to
construct attribute names.

I think part of what causes confusion is the term "prefix"; I think
"affix" would do.

To give a more concrete example, suppose we have e-mail address as
known to a KDC versus e-mail address as known to a CA issuer for a
PKINIT client certificate that is fully trusted by the KDC versus an
e-mail address from a PKINIT client certificate where the KDC does not
trust anything more than the subject public key from the certificate.
Using tag URIs we might then have:

tag:ietf.org,2012#e-mail-address
tag:ietf.org,2012#trusted-pki-e-mail-address
tag:ietf.org,2012#untrusted-e-mail-address

I do think that part of the problem with this is that if we were to
elaborate on a concept of "issuer" then we wouldn't need this
paragraph at all.  I'd much rather do that!!

Note that to elaborate on a concept of issuer is trivial:  specify an
attribute name for "issuer" and specify that its value is an exported
name token for the name of the issuer of the GSS NAME or a given
attribute of the GSS NAME.  For example:

 - GSS_Get_name_attribute(some_name, "tag:ietf.org,2012#GSS-name-issuer")

   should produce an exported name token corresponding to aKerberos
realm name or CA name.

 - GSS_Get_name_attribute(some_name, "tag:ietf.org,2012#e-mail-address")

   should produce an e-mail address.

 - GSS_Get_name_attribute(some_name,
"tag:ietf.org,2012#GSS-name-issuer tag:ietf.org,2012#e-mail-address")

   should produce the name of the issuer of the e-mail address
attribute's value.

   Note that in this example we compose attribute names with an ASCII space.

We can even specify an attribute like the issuer attribute that
indicates whether the given attribute is trusted per-local policy.
Such an attribute must not be delivered with any name on the wire, but
rather evaluated locally.

Sam, do you have any ideas as to how to rewrite that paragraph to be
clearer?  And can you explain why elaborating on issuer wouldn't be
better?

> if we are to argue some more :-)

But we can clarify.  The problem is "deny" ACL entries where the
subject of the entry is an attribute that a given principal might have
but which is not disclosed to the relying party.

The canonical example would be DENY ACL entries where the subject is a
group.  In a Windows Active Directory environment the PAC may not
deliver the SIDs of certain groups that a user may in fact be a member
of (e.g., local groups), thus DENY ACL entries with such groups as the
subject will have no effect!

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Mar 2012 01:52:55 -0500

I spoke to Sam today about this.

>> [<name-form> ] <uri-or-local-name>

I was wrong, it's really:

<prefix><space><attribute-name>

There is one prefix.  The prefix dictates how to interpret the rest of
the attribute name (e.g., whether it too consists of a prefix and an
attribute name).  This is simple enough to not warrant an ABNF.

In theory we could have chains of prefixes, and probably will.

> needs to be read in conjunction with section 5, but it belongs in

There are two particularly confusing aspects of this paragraph: the
fact that the word "prefix" is not used anywhere else in the entire
document, and the phrase "sufficient prefix" -- sufficient for what?
It's clear that prefix refers to the left half of the first space
character, if any.  I believe the "sufficient" modifier here means
"sufficient to identify the context", where "context" is described
earlier.

Sam and I talked about this and we agree on one possible substantive
change to the I-D: to reserve "local" attribute names (those with
neither spaces nor colons).  Specifically we'd reserve attribute names
with '@' in them.  The reason for this change would be that simple,
non-URN attribute names would greatly help write protable and generic
GSS applications, but we don't want to preclude local attributes
either.

I also very much wish that the I-D had some concrete examples of what
these attributes might look like and what their semantics might be.
We do have a list of such possible attributes.  Sam, however, does not
want to spend time adding any such to this draft, preferring that we
add them to a new I-D.  For your benefit, here are some possible
attributes and prefixes:

 - a prefix denoting "validated by some locally-desired policy as
   suitable for authorization decisions" (though the policy may not
   be local, and the entity doing the validation may not be either)

 - a prefix denoting "the name of the issuer of the attribute"

   (This is useful for applications that implement policies of their own.)

 - a prefix denoting "the name of the entity that enforced policy for
this attribute"

 - attributes for a variety of things (e.g., e-mail address, but also
   probably many of the items delivered in the PAC/PAD as discrete
   attributes)

 - attributes for things like "trust transit path"

 - others that I forget right now :)

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Tue, 13 Mar 2012 19:40:19 +0100

On 03/13/2012 07:52 AM, Nico Williams wrote:
> There is one prefix.  The prefix dictates how to interpret the rest
> of the attribute name (e.g., whether it too consists of a prefix
> and an attribute name).  This is simple enough to not warrant an
> ABNF.

Thank you. I was seriously scratching my head there...