Subject: 1510 status post-clarifications

From: "D. R. Evans" <[email-masked]>
Date: Thu, 06 Nov 2003 13:29:09 -0700

When clarifications becomes an RFC, is it intended to cause RFC1510 to 
marked "obsolete"?

   Doc

-- 

-----------------------------------------------------------
Phone:  +1 303 494 0394
Mobile: +1 720 839 8462
Fax:    +1 781 240 0527
-----------------------------------------------------------

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 06 Nov 2003 16:25:40 -0500

> When clarifications becomes an RFC, is it intended to cause RFC1510 to

yes, kerberos-clarifications "obsoletes" RFC1510.  That is, it provides a 
complete, stand-alone specification intended to be used in place of the old 
one.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Sam Hartman <[email-masked]>
Date: Thu, 06 Nov 2003 16:25:49 -0500

>>>>> "D" == D R Evans <[email-masked]> writes:

    D> When clarifications becomes an RFC, is it intended to cause
    D> RFC1510 to marked "obsolete"?

    D>    Doc

Yes.

---

From: "D. R. Evans" <[email-masked]>
Date: Thu, 20 Nov 2003 12:00:12 -0700

Sorry if this appears twice. I sent it earlier this morning, but there 
seems to have been a problem somewhere.

-----

Sam Hartman wrote:
 > It does not bother me if all the realm names you propose as valid end
 > up being considered valid realm names by some or all implementations.
 >
 > If they are valid realm names at all, I believe they are considered
 > domain realm names.
 >
 >

If everyone agrees with that interpretation, then that's fine (although
it does make me wonder why the stuff about "looks like" is in
clarifications -- because without that language your interpretation
would seem to be the natural one. The inclusion of the "looks like"
language seems to suggest that some different interpretation was intended).

Clarifications is pretty vague about all this (unfortunately).
PacketCable will want to be more precise, so I expect that we will add
language that reflects the consensus of this group as to what
clarifications really means. What we don't want to do is to add precise
language only to have someone here later say, "Oh, no, clarifications
doesn't mean that at all".

    Doc

--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Nov 2003 17:02:26 -0500

>>>>> "D" == D R Evans <[email-masked]> writes:

    D> -----

    D> Sam Hartman wrote:
    >> It does not bother me if all the realm names you propose as
    >> valid end up being considered valid realm names by some or all
    >> implementations.
    >> 
    >> If they are valid realm names at all, I believe they are
    >> considered domain realm names.
    >> 
    >> 

    D> If everyone agrees with that interpretation, then that's fine
    D> (although it does make me wonder why the stuff about "looks
    D> like" is in clarifications -- because without that language
    D> your interpretation would seem to be the natural one. The
    D> inclusion of the "looks like" language seems to suggest that
    D> some different interpretation was intended).

Let's be clear on what my interpretation is.  I agree the spec is
vague.  I believe that if I'm trying to write a liberal implementation
I should accept all those realm names.  I believe that no problem
exists with the spec if all those realm names do happen to be valid.

If I'm writing a conservative implementation I'd require domain style
realms correspond to a domain (or at least extension of some domain)
that is actually registered in DNS.  Using actual DNS domains is
clearly the strategy that guarantees interoperability.  If your
implementation happens to accept more than that, up to the examples
you gave, I think that's OK.

    D> Clarifications is pretty vague about all this (unfortunately).

Why is this unfortunate?  There's a large space of realm names--those
that correspond to DNS domains--that are clearly valid realms.  Why
does it matter if there are some things outside that space that may
not work everywhere?

---

From: "D. R. Evans" <[email-masked]>
Date: Thu, 20 Nov 2003 16:57:31 -0700

> does it matter if there are some things outside that space that may

It's unfortunate from our perspective because it means that one can have 
two compliant implementations that behave differently given the same 
input. I guess that the WG (and presumably the IETF in general) doesn't 
care about that, but purchasers of equpiment certainly do -- so from 
PacketCable's perspective, it's unfortunate that clarifications is 
vague, because it means that we can't just say "the requirements are as 
in clarifications", we actually have to through and resolve all the 
ambiguities that we notice. In away, I suppose it's like writing a 
profile, except that normally when one writes a profile one is resolving 
SHOULDs/MAYs into MUSTs or MUST NOTs, not interpreting rather vague 
non-spec language such as "looks like".

   Doc

--

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 20 Nov 2003 23:34:50 -0500

Basically, all strings are valid realm names including the empty 
string.  The only distinction is that in the case of strings which 
contain either ":" or "/" the strings must conform to the specifications 
for an X.500 string. 

There really is nothing ambiguous about it.

The fact that the majority of realm names happen to look like domain 
names is the part which I consider unfortunate because it results in 
people believing that the name space of realm names is supposed to 
behave like the name space for domain names. 

Jeffrey Altman

D. R. Evans wrote:

> It's unfortunate from our perspective because it means that one can 
> have two compliant implementations that behave differently given the 
> same input. I guess that the WG (and presumably the IETF in general) 
> doesn't care about that, but purchasers of equpiment certainly do -- 
> so from PacketCable's perspective, it's unfortunate that 
> clarifications is vague, because it means that we can't just say "the 
> requirements are as in clarifications", we actually have to through 
> and resolve all the ambiguities that we notice. In away, I suppose 
> it's like writing a profile, except that normally when one writes a 
> profile one is resolving SHOULDs/MAYs into MUSTs or MUST NOTs, not 
> interpreting rather vague non-spec language such as "looks like".
>
>   Doc
>

---

From: "D. R. Evans" <[email-masked]>
Date: Fri, 21 Nov 2003 09:03:38 -0700

> There really is nothing ambiguous about it.

Right. Until you actually read what clarifications says. It imposes the 
extra condition that domain-style realm names must look like domain names.

None of the examples I gave are acceptable domain names. Whether they 
"look like" domain names I have no idea, since I don't know what 
algorithm to apply to determine whether something that is not a domain 
name still "looks like" a domain name.

Sam says that it's OK for an implementation to accept any 
otherwise-acceptable name that does not contain a ":" or a "/" as a 
domain-style name. That position can be restated as "the words `looks 
like' are a no-op", because that is exactly what the spec would require 
if those extra words were not there. He also says that it is acceptable 
for an implementor to choose some sort of defensible algorithm and apply 
that to reduce the size of the space of acceptable names.

I just don't understand why the text saying that they must look like 
domain names was added. It must be there for a reason -- i.e., it must 
be there to reduce the size of the set of acceptable realm names. But 
precisely which otherwise-acceptable names it removes from the set isn't 
clear. (And Sam says [I think] that people can just invent their own 
algorithms -- including the no-op algorithm -- and the implementation 
will still meet the spec.)

It's too late to change anything (and you probably don't want an 
outsider suggesting changes anyway), but I do want to get it documented 
here exactly how you guys intended "looks like" to be interpreted, since 
it's non-obvious. My understanding, such as it is, is that you intend it 
to be interpreted as "Hey, we don't care. You have to accept anything 
that is a real, live, bona fide domain name. Beyond that, do whatever 
you want".

So, unless someone says "No, you bozo, that's not what we meant at all", 
that's what I will convert into spec language and ask to be inserted 
into the PacketCable spec.

> behave like the name space for domain names.

Well, I certainly won't argue with that. I sometimes get tired of 
explaining that  realm names aren't the same thing as domain names. 
(Actually, in PacketCable we require realm names to be upper case, which 
does help by emphasizing that they are different from domain names.)

   Doc

--

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 21 Nov 2003 11:36:53 -0500

D. R. Evans wrote:

> (Actually, in PacketCable we require realm names to be upper case, 
> which does help by emphasizing that they are different from domain 
> names.)

This works fine until you have to deal with internationalized names.  
For internationalized names we are most likely going to have to enforce 
the IDN rules to ensure that applications which blindly copy their IDN 
into Kerberos will get something that works.  The end result is that 
realm names based on IDNs will most likely be a mixed bag of lowercase 
for labels containing non-ASCII characters.  It is unclear whether the 
rest of the labels should be upper for lowercased.  What the answer 
should be is simply not clear.

The first question I think packet cable needs to ask itself is whether 
or not you want to require realm names to be equivalent to a registered 
domain name.  If the answer is yes, then that is how you should speak to 
the issue in the Packet Cable specs.

Jeffrey Altman

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 Nov 2003 12:38:32 -0500

D> Sam Hartman wrote:
    >> Why is this unfortunate?  There's a large space of realm
    >> names--those that correspond to DNS domains--that are clearly
    >> valid realms.  Why does it matter if there are some things
    >> outside that space that may not work everywhere?
    >> 

    D> It's unfortunate from our perspective because it means that one
    D> can have two compliant implementations that behave differently
    D> given the same input. I guess that the WG (and presumably the
    D> IETF in general) doesn't care about that, but purchasers of
    D> equpiment certainly do -- so from PacketCable's perspective,
    D> it's unfortunate that clarifications is vague, because it means
    D> that we can't just say "the requirements are as in
    D> clarifications", we actually have to through and resolve all
    D> the ambiguities that we notice. In away, I suppose it's like
    D> writing a profile, except that normally when one writes a
    D> profile one is resolving SHOULDs/MAYs into MUSTs or MUST NOTs,
    D> not interpreting rather vague non-spec language such as "looks
    D> like".

The IETF and every standards organization I know of accepts this as a
fact of life.  Look at the number of undefined or
implementation-defined behaviors in the ANSI C standard sometime.  Yet
people still manage to purchase C without too many complaints at least
along this axis.

Rather than clarifying areas that are vague in the spec, you should
consider giving deployment guidance such that if your guidance is
followed, the inputs to the implementations all fall within the well
defined space.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 Nov 2003 12:44:45 -0500

Let's ignore for the moment what is an invalid domain style realm
name.

When can you ever use a domain style realm name that does not
correspond to a domain or to some string ending in a valid domain?

Consider the following:

   These rules guarantee that there will be no conflicts between the
      various name styles. The following additional constraints apply
      to the assignment of realm names in the domain and X.500
      categories: the name of a realm for the domain or X.500 formats
      must either be used by the organization owning (to whom it was
      assigned) an Internet domain name or X.500 name, or in the case
      that no such names are registered, authority to use a realm name
      MAY be derived from the authority of the parent realm. For
      example, if there is no domain name for E40.MIT.EDU, then the
      administrator of the MIT.EDU realm can authorize the creation of
      a realm with that name.