Subject: Re: [kitten] ID-Action: draft-williams-kitten-generic-naming-attributes-00

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 8 Aug 2013 00:13:22 -0400 (EDT)

[Sorry for the lack of in-reply-to, I lost the original]

I have reviewed this document, comments below.

I don't understand what the second sentence of section 2.1 is trying to 
say.

In section 2.1.1, "obtain a name of an issuer of a mechanism name", are 
there supposed to be multiple issuers of a given mechanism name?  Maybe 
"the issuer" is better.  In the last paragraph, "used as prefix" needs an 
'a' -- "used as a prefix".

"non-display" appears in square brackets in 2.1.1 but not when used later.

(2.1.3) Off the top of my head, I'm not sure how much sense it makes to 
have the non-display form of the service name just be a character string, 
but that may just be because my instincts for GSS names are formed from 
looking at principal names.

(2.1.4) I'm not sure I'm comfortable using "host name" to describe a 
"domain-based service name".  I am just now learning about U-labels and 
A-labels by reading exerpts of RFC 5890, but its page 11 definition of a 
"U-label" seems to indicate that it must include at least one non-ASCII 
character.  Hopefully this is just a misunderstanding based on an 
incomplete reading of the spec, otherwise it would be quite odd.  I'm a 
bit curious what the motivation is for using Unicode for display and ASCII 
for non-display.  I'm also not sure what is meant by "stylized" for the 
display form ... is there a reference to put there?  A-labels have a 
length limit of 59 ASCII characters?  That seems potentially restrictive, 
if I am remembering correctly.

(2.1.5) Similar comments apply.  I guess 2.1.4 should skip the mention of 
domain-based service names and dever to 2.1.5.

Section 2.2 appears to impose very severe constraints on the 
implementation without much fanfare, indicating that retrieving any name 
attributes MUST check for name constraints and reject the request if 
constraints are not satisfied.  I would have expected this restriction to 
be mentioned sooner in the document.  I see there's a "fill in more" note 
in the security considerations on this topic; given that it is an 
implementation constraint, I'm not sreu that that would be sufficient.

Of course, then 2.2.1 provides a way to disable that checking.

In general, my sense is that this document is too short, and contains just 
a part (perhaps even the core) of a complete document.  It throws out a 
few name attributes and gives some sense of how they might be accessed, 
but no motivation for why they might be desirable or how they might be 
used.  Hmm, would fleshing out the introduction be enough?  I guess it 
would be almost all of the way there, but the subsubsections of section 2 
could benefit from a slightly longer description of the meaning of the 
indicated name components.  Having access to name attributes of this 
nature from the GSSAPI layer does seem useful (maybe I am coming at this 
from a Kerberos-centric view?  Other opinions are very welcome), so I 
think that this document should move forward in some form.

-Ben

---

From: Nico Williams <[email-masked]>
Date: Thu, 8 Aug 2013 00:02:29 -0500

> I have reviewed this document, comments below.

Thanks!

> I don't understand what the second sentence of section 2.1 is trying to say.

Ah, that requires having read RFC6680 first.  I'll expand on this.
I'll also provide a fuller introduction (see also below).

> there supposed to be multiple issuers of a given mechanism name?  Maybe "the
> issuer" is better.  In the last paragraph, "used as prefix" needs an 'a' --
> "used as a prefix".

Thanks for noticing these mistakes.

> "non-display" appears in square brackets in 2.1.1 but not when used later.

That's just me not knowing how to deal with a bit of awkwardness in
GSS_Get_name_attribute(): it returns a value and a display_value.  I'm
trying to indicate that when getting the issuer name of an MN or an MN
attribute, the value returned in the 'value' output parameter should
be an exported name token.

> (2.1.3) Off the top of my head, I'm not sure how much sense it makes to have
> the non-display form of the service name just be a character string, but
> that may just be because my instincts for GSS names are formed from looking
> at principal names.

Well, RFC2743 is pretty clear that service names are strings... so
what else could we do here?

[I suppose that if we opened the I18N pandora box we could say that
the display_value's are always in whatever the caller's current
locale's codeset is, while the value of service name attributes would
be in...  well, we'd want UTF-8, but RFC2744 says Latin-1, but with no
real authority (it says "may", not even "MAY", though it also doesn't
use any RFC2119 language, nor does it reference it).  Can we close
this pandora box now?  :/]

> "domain-based service name".  I am just now learning about U-labels and

This is in reference to the host name component of a) host-based
service names, and b) domain-based service names (which have both,
domain and host name components).

> character.  Hopefully this is just a misunderstanding based on an incomplete
> reading of the spec, otherwise it would be quite odd.  I'm a bit curious
> what the motivation is for using Unicode for display and ASCII for
> non-display.  I'm also not sure what is meant by "stylized" for the display
> form ... is there a reference to put there?  A-labels have a length limit of
> 59 ASCII characters?  That seems potentially restrictive, if I am
> remembering correctly.

This is part of the GSS I18N pandora's box.  The problem is
pre-existing and I'm making it no worse, but I'm trying to make it
better.  Yes, I'm not saying anything about codeset for display_value,
and neither does RFC6680, but I refer to U-Labels -- I suppose that
U-Labels can be encoded in non-Unicode encodings, as long as there's
no loss of information in the conversion.  I don't want to resolve the
issue of what codeset to use for either query or display strings at
this time, mostly because it seems like a good way to waste time on an
argument, but if the WG likes we could have this discussion.  Preview:
I'm all for saying that query and display strings are in the codeset
of the caller's locale, primarily because anything else instantly
complicates usage of the API and *also* fails to match reality.

> domain-based service names and dever to 2.1.5.

No, domain-based service names have three components: service,
hostname, and domainname, so section 2.1.4 applies to domain-based
service names too.

> Section 2.2 appears to impose very severe constraints on the implementation
> without much fanfare, indicating that retrieving any name attributes MUST
> check for name constraints and reject the request if constraints are not
> satisfied.  I would have expected this restriction to be mentioned sooner in
> the document.  I see there's a "fill in more" note in the security
> considerations on this topic; given that it is an implementation constraint,
> I'm not sreu that that would be sufficient.

I pondered about this and sought advice while implementing.  I decided
that I wanted three modes of operation:

a) naming constraint check failure -> failure;
b) naming constraint check status indicated;
c) no naming constraint checks.

with (a) as the default.  All three are provided.

You call (a) severe, but I call it "fail closed" or "fail safe".

Formalizing a notion of issuer requires talking about name constraints.

Kerberos has no formal notion of name constraints, but in practice we
have them, in a way, and it's easy enough to create some very simple
rules.

> Of course, then 2.2.1 provides a way to disable that checking.

Right!

> In general, my sense is that this document is too short, and contains just a
> part (perhaps even the core) of a complete document.  It throws out a few

You're absolutely right that it needs a lengthier intro.

> name attributes and gives some sense of how they might be accessed, but no
> motivation for why they might be desirable or how they might be used.  Hmm,
> would fleshing out the introduction be enough?  I guess it would be almost

I will add such text.  For the time being let me just say that there
are many applications that parse Kerberos MN display or exported name
forms, which results in rather unportable code.
GSS_Display_name_ext() turns out to be unsatisfactory and redundant
(since what it does can be done by GSS_Get_name_attribute() to get a
suitably defined attribute) -- unsatisfactory because it has no notion
of name constraints checking or issue.  An attribute model of naming
that reflects reality (i.e., all the components of Kerberos and other
mechanism principal naming) needs to do better.

Consider an application that allows access to, say,
root/client-hostname.fqdn...  (think of NFS servers).  The application
will want to be able to access the service name, the hostname, and
also, _of course_ the realm name (for obvious reasons).  Now, if that
application parses krb5 MN display/exported name token forms then that
application ceases to be generic.  If the application uses
GSS_Get_name_attribute() and the attributes defined in this I-D then
the application can be totally generic *and* safe.

That is, roughly, the motivation.  Other attributes will follow, some
as originally envisioned for the RFC6680 interfaces.

> all of the way there, but the subsubsections of section 2 could benefit from
> a slightly longer description of the meaning of the indicated name
> components.  Having access to name attributes of this nature from the GSSAPI
> layer does seem useful (maybe I am coming at this from a Kerberos-centric
> view?  Other opinions are very welcome), so I think that this document
> should move forward in some form.

It's more than useful.  It's essential.  We didn't know we were
missing these attributes because we were so used to not having them.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 8 Aug 2013 00:18:14 -0500

> this pandora box now?  :/]

I should have added that in practice service names are all US-ASCII,
so we don't need to open that box on account of *this* attribute.

> the application can be totally generic *and* safe.

I should add that typical NFS servers want to grant "root-equivalent"
access to client principals that have a service-like component named
"root" and a hostname-like component that appears in an ACL (and
possibly corresponds to the client's IP address, either via forward or
reverse lookup).  I say "service-like" and "hostname-like" because the
name type may not actually be set to a host-based service name type,
and the client is clearly not a service, but the shoe fits.

I've seen host-based service style client naming in widespread usage
at various companies, FYI.  "Parsing" them is a common thing to do.
It sucks.

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 8 Aug 2013 14:24:30 -0400 (EDT)

> I'll also provide a fuller introduction (see also below).

Yeah, I only realized it was essentialy to have already read RFC6880 about 
halfway through the document.  The longer introduction should help on that 
front.

> be an exported name token.

My emphasis should have been on "not when used later"; I would have 
expected consistent usage throughout.

> this pandora box now?  :/]

What pandora's box?  Lalalalalala I can't see anything... ;)

> domain and host name components).

Ah, okay.  Sorry for my ignorance.

> You call (a) severe, but I call it "fail closed" or "fail safe".

I definitely prefer "fail safe" as written.  I used the word "severe" in 
that this tiny text hidden away in the middle is a large ("severe") 
constraint on implementation behavior, and it doesn't have a big flashing 
sign "behavior constraint here" in front of it.

> have them, in a way, and it's easy enough to create some very simple

I agree that there are things that we can do.  I think such a document 
talking about what we can currently do without more discussion of formal 
notions might run into trouble at (e.g.) IESG review if aiming for 
standards-track.

> I will add such text.  For the time being let me just say that there

Thanks.

> That is, roughly, the motivation.  Other attributes will follow, some

I know that, and you know that ... it just needs to be in the document :)

-Ben

---

From: Nico Williams <[email-masked]>
Date: Thu, 8 Aug 2013 12:39:53 -0500

It's been pointed out to me that RFC5178 addressed the I18N issues.  I
can't believe I forgot that.