Subject: Testing the concensus of the krb-wg on IDN

From: "Douglas E. Engert" <[email-masked]>
Date: Wed, 15 Oct 2003 10:56:29 -0500

Jeff Altman sent the following text to me as a statement of what he feels is the 
WG consensus on the recent IDN issues. I tend to concur, but want to give members 
a chance to submit a counter statement. 

---

Several members of the IDN community have approached individual members of the
working group indicating a desire to be able to use ACE-encoding of IDN names
(Internationalized Domain Names) as an user input mechanism to Kerberos when
Unicode input mechanisms are not available.  It is the opinion of the Kerberos
working group that this approach is fatally flawed.  

Even in the pre-IDN world, the DNS namespace and the Kerberos namespace are not
interchangable.  The DNS namespace is a proper subset of the Kerberos namespace
combined with different sensitivity to character case.  As Kerberos use is not
restricted to environments which require the use of DNS it is inappropriate for
Kerberos to restrict its namespace to match that of DNS.

In the IDN world, the namespace issues become more complex.  Unlike ASCII based
DNS names which are case-insensitive but case-preserving, the process of
converting a Unicode name to
ACE-encoding requires case-folding and the removal of characters which are legal
in the
Kerberos name space.  Therefore, we have a situation in which for a given
"UnicodeName":

   saslPrep(toUnicode(ACE(UnicodeName)))  !=  saslPrep(UnicodeName)

The IDN community is arguing that because many vendors auto-generate Kerberos
Realms and Kerberos Service Principal names from domain name and host names, that
the Kerberos protocol must be altered to allow ACE encodings of Unicode strings to
be valid input to Kerberos.  In other words, they want the above equation to be ==
not !=. 

The Kerberos WG objects to this assertion.  Kerberos Realm names are not Domain 
names and host names are not service principal names.  Kerberos does not make any 
such association. Even if this is how many vendors choose to utilize Kerberos convention,
it is not a Kerberos protocol issue.  Instead the WG views the problem as a User 
Interface issue which is beyond the scope of the IETF and its RFCs.  The Kerberos RFCs 
do not define Programming Interfaces and they do not define User Interfaces.

Vendors require the ability to provide an alternate method of inputting Unicode
strings when the UI only supports 7-bit ASCII input mechanisms.  This may be the
result of a lack of Unicode support within a logon API, the lack of necessary font
support, etc.  The IDN community appears to have decided to use ACE-encoding as
this alternative because:

  1.it is a 7-bit ASCII encoding 
  2.they anticipate that the only strings which will require such input are based on 
    Domain names and host names 
  3.it is assumed that ACE encoded hostnames will be leaked to the end user through 
    the browser

The Kerberos WG agrees that there needs to be an alternate input encoding for IDN
strings for use when direct Unicode input cannot be supported.  However, the
Kerberos WG believes the use of ACE-encodings outside of the internal workings of
DNS either in the database or in the resolver is misplaced.  ACE-encodings cannot
be used to provide a transitive set of functions to convert to and from Unicode
because by its definition the conversion to ACE encoding is lossy.  The fact that
there are differences between the DNS namespace and the Kerberos namespace most
likely indicates that there will be other namespace conflicts discovered in the
future within other protocols.  The Kerberos WG believes that the alternate
encoding of Unicode strings must be lossless if is going be successfully
implemented at the user interface level.  This encoding can then be translated to
the required Unicode format as needed prior to the use of the string by DNS,
Kerberos or any other protocol.

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Derek Atkins <[email-masked]>
Date: 15 Oct 2003 13:18:56 -0400

>    saslPrep(toUnicode(ACE(UnicodeName)))  !=  saslPrep(UnicodeName)

Is the inverse true or false?  E.g.:

    ACE(UnicodeName) ??? ACE(toUnicode(saslPrep(UnicodeName)))

Is ??? an "equals" or "not-equal"?

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 15 Oct 2003 10:45:22 -0700

>     ACE(UnicodeName) ??? ACE(toUnicode(saslPrep(UnicodeName)))

ToUnicode() is the identity function for non-ACE names, and since
saslPrep() outputs Unicode this can be re-written as:

    ACE(UnicodeName) ??? ACE(saslPrep(UnicodeName))

(ACE() presumably means ToAscii(), and "UnicodeName" presumably means
 "non-ASCII, Unicode name.")

> Is ??? an "equals" or "not-equal"?

I'm pretty sure that'd be equal.  To be unequal there'd have to be some
discrepancies in the nameprep and saslprep mapping tables that allow
some code point to mapped by saslprep to some other code point which in
turn is not mapped by nameprep to the same code point as nameprep would
map the original.  I.e., as long as there is no Unicode code point such
that nameprep(c) != nameprep(saslprep(c)).

Cheers,

Nico
--

---

From: Derek Atkins <[email-masked]>
Date: 15 Oct 2003 14:12:42 -0400

>     ACE(UnicodeName) ??? ACE(saslPrep(UnicodeName))

Sure, I was just being thorough..

> that nameprep(c) != nameprep(saslprep(c)).

That's my _hope_ which is why I asked.  If "???" is equal then I don't
see any problems at all.  However if it's "not-equal" then we have a
clear problem that we need to solve.

-derek

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 15 Oct 2003 22:24:17 +0200

> Is ??? an "equals" or "not-equal"?

Answering the question is a matter of comparing the SASLprep tables
with the Nameprep tables, and the definition of ACE.  From the
differences, you can derive examples.  Here is one that would occur
even in ISO-8859-1 environments (recall U+00AA is Latin-1 0xAA).

ACE(U+0044 U+00AA) != ACE(toUnicode(saslPrep(U+0044 U+00AA)))

The details are:

ACE(Dª) = da

saslPrep(Dª) = Da
toUnicode(Da) = Da
ACE(Da) = Da

Regards,
Simon

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 15 Oct 2003 13:32:18 -0700

> ACE(U+0044 U+00AA) != ACE(toUnicode(saslPrep(U+0044 U+00AA)))

This has nothing to do with U+00AA and everything to do with what ACE(D)
returns - and your example shows two different behaviours for ACE(D), so
yoiur example must be wrong (or am I missing something?).

I take it that by ACE() we mean ToASCII().

Cheers,

Nico
--

---

From: Derek Atkins <[email-masked]>
Date: 15 Oct 2003 16:37:34 -0400

> ACE(U+0044 U+00AA) != ACE(toUnicode(saslPrep(U+0044 U+00AA)))

Wait, how does ACE(Dª) -> da?  Wouldn't that be Da?
Or are there some cases where ACE(U+0044) -> 0x64?

> ACE(Da) = Da

This makes sense...

-derek

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 15 Oct 2003 13:39:19 -0700

>ACE(U+0044 U+00AA) != ACE(toUnicode(saslPrep(U+0044 U+00AA)))
I am not sure why this equivalence is necessary?  KerberosStrings are not
used as input to DNS queries.  Even if they were, the fact that "da" != "Da"
would not be a problem since DNS queries are case-insensitive.  Therefore,
the fact that the case folding does not occur is not an issue.  At least not
an issue for this example.

We would need an example which demonstrates that the lack of case folding
would produce output strings consisting of code points which would be 
considered
unique by a DNS query.  Assuming of course that KerberosStrings were being
used as input to DNS.

Jeffrey Altman

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 15 Oct 2003 22:51:31 +0200

> I take it that by ACE() we mean ToASCII().

Yes.  I believe you are missing RFC 3490 section 4.1 step 1.  U+00AA
is critical in the example.

> Or are there some cases where ACE(U+0044) -> 0x64?

Nameprep, part of ACE, folds case using table B.2.  However, Nameprep
is not always invoked, see above.

B.2 Mapping for case-folding used with NFKC.  See RFC 3454:

   ----- Start Table B.2 -----
   0041; 0061; Case map
   0042; 0062; Case map
   0043; 0063; Case map
   0044; 0064; Case map
...

Regards,
Simon

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 15 Oct 2003 14:01:35 -0700

> is critical in the example.

Ah, yes, you're correct.  For ToASCII() The presense of U+00AA triggers
the application of nameprep.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 17 Oct 2003 21:15:43 -0700

I would add the following:

 - RFC1510 (section 7.2.1) recommends that hostnames, when used as the
   second component of NT-SRV-HST, be case-folded to lower case.

 - Clarifications (section 6.1) recommends that realm names, when
   derived from DNS domain names, be case-folded to upper case.

These recommendations seem to me to add up to having two optional
stringpreps for use where appropriate, except that sometimes it is only
users that can apply the stringprep (e.g., for atypical principal naming
conventions that reference host/domain names).

I believe that we should keep these recommendations, perhaps using
stringprep profiles instead of "fold the case" descriptions, though the
first one should be more general:

 - "When a DNS hostname or, more precisely, domain name is used in any
   component of a principal name, that component SHOULD be case-folded
   to lower case [or we should say that that component should be prepped
   with nameprep].  Unfortunately, sometimes only a user may know that a
   given component of a given principal name contains a DNS domain name;
   in such cases either the user must know to fold the case down, or
   there is a risk that the resulting principal name will not match the
   intended principal's name and so the user will fail to obtain the
   desired behaviour - and if the user enters and domain name with ACE
   encoded labels and the UI does not expect these, the resulting
   principal will not match the intended principal name."

Further, I believe the use of ACE encoded domain names in principal name
components (but NOT realm names) could be allowed provided that: a)
non-ACE encoded version of such principal name exist in the same realm,
b) use of ACEs for this be optional, c) the purpose of the ACE encoded
version be to deal with "leakage" of ACE encoded domain names [labels]
to contexts where they are not permitted but cannot be detected or
prevented.  Such use of ACE should not be recommended and should be
discouraged - and perhaps it should be left as an implementation- or
deployment-specific detail, as long as the requirement that non-ACE
versions of such principal names exist be maintained.

In any case, ACE encoded names should NOT be allowed as realm names.

We may want to reference nameprep as the recommended transformation for
principal name components that are host/domain names, and if we do we'll
have to define an upper-case version of nameprep for use with realm
names.

Cheers,

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sat, 18 Oct 2003 10:39:13 -0400

> conventions that reference host/domain names).

It should be noted that the realm-naming convention is just that -- a 
convention.  Realm names are chosen by administrators, and they don't do it 
by taking a DNS domain name and applying a stringprep profile.  They say 
"Hm; my domain is cs.cmu.edu, and the documentation says I should use the 
uppercase form of my domain name, so I'll call my realm CS.CMU.EDU".

> versions of such principal names exist be maintained.

I think what you're suggesting is that some implementations might want to 
consider two principal names to be the same if one contains a component 
that is an ACE encoding of some string, and the other contains a component 
that is a UTF-8 encoding of the same string.

Suppose I ask for a ticket for 
host/[email-masked].
What should the KDC give me?

(1) A ticket for the ACE-encoded name I asked for.
(2) A ticket for the UTF-8-encoded name I should have asked for.
(3) KDC_ERR_S_PRINCIPAL_UNKNOWN
(4) something else

> have to define an upper-case version of nameprep for use with realm

Principal names are used to query the kdb, for authorization, and to form 
salt strings.  What stringprep profile to use when needs to be unambiguous 
and consistent; if we have each implementation making its own choice, they 
won't interoperate.  So, some questions need to be answered..

In what cases MUST nameprep be used, if any?
How does an implementation determine this?
Is nameprep used before saslprep or after it?  Or is it used in place of it?

---

From: Jeffrey Altman <[email-masked]>
Date: Sat, 18 Oct 2003 10:56:52 -0400

Jeffrey Hutzelman wrote:

> convention.  Realm names are chosen by administrators, and they don't 
> do it by taking a DNS domain name and applying a stringprep profile.  
> They say "Hm; my domain is cs.cmu.edu, and the documentation says I 
> should use the uppercase form of my domain name, so I'll call my realm 
> CS.CMU.EDU".

Whether the REALM name is upper or lower case is irrelevant to the 
problem at hand.  Having
a recommended standard does not solve the problem as we know that there 
are sites that
violate the convention.  The Kerberos protocol does not require a 
specific case.  Therefore,
we must be able to handle both.

> I think what you're suggesting is that some implementations might want 
> to consider two principal names to be the same if one contains a 
> component that is an ACE encoding of some string, and the other 
> contains a component that is a UTF-8 encoding of the same string.
>

The answer to this is (1).  If the client requests a ticket for 
principal host/[email-masked] it should 
be given a ticket for principal 
host/[email-masked].  The KDC, old, new, 
or otherwise does not have any knowledge of whether the instance is 
supposed to an encoding from some other namespace or not.

> Principal names are used to query the kdb, for authorization, and to 
> form salt strings.  What stringprep profile to use when needs to be 
> unambiguous and consistent; if we have each implementation making its 
> own choice, they won't interoperate.  So, some questions need to be 
> answered..
>

The designation of a string preparation routine is specific to the 
Kerberos protocol.  The only program code which should apply the 
designated string preparation routine is the library which implements 
Kerberos protocol.  Applications MUST NOT apply any string preparation 
routine to Unicode input to the Kerberos library.  To do so risks 
incompatibility with other implementations.  The Kerberos RFC places 
requirements on the implementors of the Kerberos protocol.  It does not 
and should not place requirements on application developers to have 
knowledge of the internal workings of the string processing required by 
the protocol.

Applications should pass an unnormalized Unicode string to the Kerberos 
library in the Unicode encoding (UCS-4, UCS-2, UTF-8, ...) required by 
the library.

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 19 Oct 2003 15:11:31 -0700

> uppercase form of my domain name, so I'll call my realm CS.CMU.EDU".

That's why it should be a recommendation.  Where the convention is
followed consistently one could configure software to alway apply the
optional stringprep that capitalizes realm names.

> that is a UTF-8 encoding of the same string.

I'm suggesting something that can be, and is done today.  I.e., an
abstract principal can have multiple names, aliases if you wish.

> (3) KDC_ERR_S_PRINCIPAL_UNKNOWN

(1), if it exists.  We discussed principal name aliasing at the February
2002 interim meeting as a way to help remove the use of DNS
canonicalization of principal names without forcing users to always use
fully qualified principal names.  IIRC, MS does something like this.

> won't interoperate.  So, some questions need to be answered..

Think of how rfc1510 works now.  If you use mixed case for hst name
components of princ names created as all lower case then the queries
fail - but if you remember to stick to the rfc1510 recommendation then
you'll lower case the hostnames and the queries work.

So, the stringprep profile for lower casing princ name components that
are host/domain names and the stringprep profile for upper casing realm
names, both have to be applied before querying - if one chooses to go
with the recommended convention.

A convention is needed anyways, and always will be because of the
difference in Kerberos and DNS case sensitivity.

> In what cases MUST nameprep be used, if any?

Nameprep (but NOT ToASCII) should be applied to all host/domain names
before using them in any principal name, for any purpose.  Of course,
this would be a recommended convention, and saslprep would still have to
be applied to the result of applying nameprep to the host/domain name.

And note that we need an upper-casing version of nameprep for the realm
naming convention.

> How does an implementation determine this?

Sometimes it cannot.  See the example I gave of private principal naming
conventions - and then there's new standard conventions that may come
along, such as the domain-based princ names we've discussed in the SASL
WG and which I intend to write two I-Ds for (one to define the GSS-API
domain-based name type and generic syntax, one to define the naming
convention for the same for Kerberos V).

Fortunately users can mostly deal with lower- and upper-casing strings
alright (experience with rfc1510 and DNS bears this out, at least for
ASCII).

> Is nameprep used before saslprep or after it?  Or is it used in place of it?

*before*

Technically we can compose a new stringprep for saslprep(nameprep(<name>)).

I'm not arguing for anything that isn't already in rfc1510 and
clarifications - I'm arguing that the existing recommendations for
dealing with the difference in Kerberos V and DNS case sensitivity
should be extended beyond ASCII.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 19 Oct 2003 15:21:54 -0700

> Whether the REALM name is upper or lower case is irrelevant to the 

I disagree.  The case recommendation for realm names is relevant to
interoperability.

> we must be able to handle both.

Historically we have handled the difference in Kerberos V and DNS case
sensitivity by recommending a convention.  We have to keep and extend
the recommended convention for I18N.  And note that we're talking about
a recommendation - not a requirement.

> supposed to an encoding from some other namespace or not.

The KDC may know that one is an alias for the other, but the KDC won't
be canonicalizing the name in the reply, so whether it knows about the
relation between the two is hardly relevant to the client.

> knowledge of the internal workings of the string processing required by 

Where the recommendations are implemented is not as important as making
them be optional (because they are optional now).

And note the example I gave of private naming conventions, as well as
future standardized naming conventions that may place domain names in
non-NT-SRV-HST names or in the second component of principal names.
Such conventions may be application-specific, user-specific, or
standardized - so who applies the recommended stringprep profiles may
have to vary.

Given a) gss_import_name() with GSS_C_NULL_OID as a name type, and,
b) exported GSS names, users can create their naming conventions such
that neither applications nor libraries may know to apply any case
conventions.  In such cases only the users/administrators can apply any
case conventions.

> library in the Unicode encoding (UCS-4, UCS-2, UTF-8, ...) required by 

Unless the application has its own principal naming conventions
involving domain names - in which case it may have to apply nameprep -
or whatever, as per its convention - on its own.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 20 Oct 2003 07:43:08 -0700

> I disagree.  The case recommendation for realm names is relevant to

To clarifiy this statement: the case recommendations of rfc1510/
clarifications are implemented, for the most part, by humans rather than
software - so the case recommendations in rfc1510/clarifications aren't
that relevant to interop, no.

But will users be generally able to manage case in non-ASCII names?

What if users cut-n-paste text that uses characters they're not familiar
with?  (Perhaps users shouldn't do that, but won't they?)

Cheers,

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 20 Oct 2003 11:01:07 -0400

>with?  (Perhaps users shouldn't do that, but won't they?)
If a user is going to cut and paste glyphs they are not familiar with,
then the case of the characters is the least of their worries. 

Some application software provides an option to "uppercase realm names";
most do not.  The reason applications do not do this automatically is
because doing so breaks the ability of users to communicate with existing
realms.  If an application developer decides to extend this functionality
to non-ASCII names they are welcome to do so.  Many systems have libraries
which will perform translation of unicode strings to uppercase or to
lowercase.  This transformation would be performed independent of the
use of a string-prep profile by either the DNS resolver or Kerberos.

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 20 Oct 2003 08:07:06 -0700

> then the case of the characters is the least of their worries. 

That's my gut feeling also, but my guess is it will work often enough
and then will come to be common enough that it will have to work.

I'm thinking of a global organization with sites around the world and
which uses IDNs - will someone in India or Japan know how to change the
case of Latin-1/2 non-ASCII letters?

To do nothing to help users cope with such situations is to discourage
use of IDNs.

> realms.

We agree on the need for any software implementation of these
recommendations to be optional.

>          If an application developer decides to extend this functionality

What do you mean by "independent"?

The transformation should be performed before applying saslprep, that's
for sure.  As to where the transformation should be performed: where
some component or user knows that it should be, given contextual
information - that is, unfortunately, the best we can do AFAICT.

Cheers,

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 20 Oct 2003 11:26:17 -0400

>information - that is, unfortunately, the best we can do AFAICT.
An application is allowed to perform a case transformation on a user input
string when requested by the end user with the knowledge that such as
transformation is lossy and may result in an unknown realm error. 

An application is not allowed to apply any string-prep profiles to the
string.  The string must be delivered to the protocol implementations
in an unnormalized form.

Jeffrey Altman

---

From: Martin Rex <[email-masked]>
Date: Mon, 20 Oct 2003 17:24:52 +0200 (MET DST)

> conventions.  In such cases only the users/administrators can apply any

FYI, a Kerberos5 gssapi mechanism should treat the GSS_C_NULL_OID
nametype in gss_import_name() exactly like GSS_KRB5_NT_PRINCIPAL_NAME
i.e. the Kerberos Principal Name Form (rfc1964 Section 2.1.1).

Every GSS-API mechanism is supposed to use its "native" name format
whenever a portable application supplies GSS_C_NULL_OID as a nametype,
so that names can be entered in the same fashion/format as through
mechanism-specific (adminstrative) UIs.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 20 Oct 2003 08:39:43 -0700

> string.  The string must be delivered to the protocol implementations

This is news to me.  The user input method may well deliver fully
normalized text anyways - or it may not use UTF-8 and the conversion to
UTF-8 may provide normalization as well.

No, I see no reason why the application must be constrained to not apply
stringprep profiles prior to passing text to Kerberos V libraries - as
long as the developer/admin/user understand that doing so may be lossy.
In fact, case transformations are less safe in this regard than mere
normalization.

Yet, as destructive and irreversible as case transformations are, they
are the price we must pay to get Kerberos V and DNS to co-exist.

The Kerberos V libraries must apply saslprep though, even if their text
inputs are already saslprepped.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 20 Oct 2003 08:43:40 -0700

> mechanism-specific (adminstrative) UIs.

I was referring to just that facility of the GSS-API.

The point is that it is possible for users to avoid giving contextual
information to software about what is or isn't a domain name in a
mechanism-specific name (a Kerberos V name, in this case), so it isn't
always possible to apply the case transformation recommendations of
rfc1510/clarifications (and extensions) in software.

Cheers,

Nico
--

---

From: Derek Atkins <[email-masked]>
Date: 20 Oct 2003 11:57:17 -0400

> that relevant to interop, no.

Eh?  What do you mean?  If I try to contact some random host via
a kerberized application, it will automatically convert the requested
fqdn into a host/fqdn@REALM by munging the input fqdn into a REALM.

E.g.:

        rlogin -x foo.example.domain

will attempt to acquire a service ticket for:

        host/[email-masked]

It will do this automatically, with no user input.  How can you
claim that this is "implement by humans"?

-derek

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 20 Oct 2003 09:06:47 -0700

> claim that this is "implement by humans"?

I said "... the case recommendations of ..."

So, does "rlogin -x fOo.eXamPlE.DOmaIn" result in a cache lookup/TGS-REQ
for "host/[email-masked]" or
"host/[email-masked]"?

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Mon, 20 Oct 2003 18:25:50 +0200 (MET DST)

> because doing so breaks the ability of users to communicate with existing

I was surprized a few days ago when I realized that Microsoft's SSPI
does an automatic uppercasing of an explicitly supplied REALM name.

Unfortunately they do it in a very inconsistent fashion,
i.e. when you call AcquireCredentialsHandle() with an explicitly
supplied user+Realm (in an AUTH_IDENTITY structure) on the
initiator side and perform an authentication with a server,
then the authentication will succeed and the Server will
correctly display the users realm in all-uppercase.

However if the initiator does a QueryCredentialsAttributes() on these
initiating credentials, then it will receive the Realm name in
exactly the fashion that it was passed to AcquireCredentialsHandle()
-- OUCH!

-Martin

---

From: Derek Atkins <[email-masked]>
Date: 20 Oct 2003 12:30:36 -0400

> "host/[email-masked]"?

The former.

-derek

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 20 Oct 2003 12:40:45 -0400

> with?  (Perhaps users shouldn't do that, but won't they?)

I really think we need to be talking about realm and principal names 
separately here.

Applications rarely just make up realm names from domain names.  Realm 
names are either provided by the user (via cut-and-paste or manual entry of 
something he knows) or obtained from the Kerberos library based on local 
configuration or cross-realm referral from a KDC (which presumably also has 
local configuration).  The realm names in local configuration were provided 
by some administrator, either by cut-and-paste or by manual entry.

The point is, virually all realm names are obtained either by literal 
copying of something that is already a realm name, or by manual entry of 
something known to the user -- not by deriving them from DNS domain names. 
The only time a realm name should be obtained by derivation from a DNS 
domain name is when a Kerberos administrator is choosing the name of his 
realm.  Our document defines a convention for that case (upcase the name of 
a DNS domain you control), but only for that case.  With regards to 
determining what realm to use in a Kerberos request, we say:

   ...and a
   mapping to a Kerberos realm derived syntactically from the domain
   part of the specified hostname and information from the local
   Kerberos realms database. [1.2]

   Before sending a request to the ticket-granting service, the client
   MUST determine in which realm the application server is believed to
   be registered [3.3.1]

   When establishing a new realm name based on an internet domain
   name it is recommended by convention that the characters be converted
   to upper case. [6.1]

In other words, when creating a realm, you end up deriving the name from 
DNS without any other information.  But an application looking up the realm 
name for a service will have access to local configuration information 
telling it at a minimum what realms exist, and most likely containing a 
mapping from patterns to match against domain names to realm names.

I don't think we need to say any more about realm names than clarifications 
already does.  Does someone disagree?  If so, can we split the discussion 
as it pertains to realms into a separate thread?

Principal names, however, are another story.  While principal names are not 
domain names and should not normally be treated as such, there are many 
cases in which application protocols specify that the principal name for a 
service is to be constructed from the name of the server on which the 
service resides.  We even provide a name type for this, and guidance to the 
effect that

   If the first component of a name identifies a service and there is a
   single component following the service name identifying the instance
   as the host on which the server is running, then the name type SRV-
   HST SHOULD be used. [6.2]

and

   Where the name of the host is not
   case sensitive (for example, with Internet domain names) the name of
   the host MUST be lower case. [6.2.1]

Clearly this is enough guidance for a pre-IDN, clarifications world, in 
which both hostnames and Kerberos principal names are restricted to 
US-ASCII.  But just as clearly, IMHO, it's _not_ enough guidance for an 
IDN+extensions world, in which both names admit richer character sets. 
So...

- What guidance should kerberos-extensions provide to application protocols 
constructing service principal names from Internet domain names?

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 20 Oct 2003 09:43:04 -0700

> > "host/[email-masked]"?

I stand corrected.  Which is good - if hostnames in NT-SRV-HST
principals are lower-cased in widely deployed software then the
recommendation may have to be stronger than "RECOMMENDED."

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 20 Oct 2003 10:07:13 -0700

> determining what realm to use in a Kerberos request, we say:

This is mostly true, but there's at least one case where MIT krb5 upper
cases a realm name - look in krb5_get_host_realm().

Also, users may type in realm names (e.g., .k5login), though often
they'll cut-n-paste them from elsewhere and the ultimate source will be
the administrators, as you point out.

> mapping from patterns to match against domain names to realm names.

Well no, not always - see above.

> as it pertains to realms into a separate thread?

I don't agree.  RFC1510 and clarifications make case transformation
recommendations and both of these need to be updated for extensions I18N
- we have to keep a realm name case recommendation, which is not all
that different from the recommendation for hostnames as princ name
components, so why separate the discussions?

I'm willing to separate the issues of whether either or both of those
recommendations should be stronger than "RECOMMENDED."

> IDN+extensions world, in which both names admit richer character sets. 

That's not really enough guidance in that one may have other host-based
naming conventions and one may not always have a name type hint (again,
see my example of GSS-API names imported with the GSS_C_NULL_OID name
type).

> constructing service principal names from Internet domain names?

The same as in rfc1510/clarifications, extended to the world of Unicode,
and perhaps with stronger rfc2119 terminology (e.g., "MUST").  Plus some
words about contexts where Kerberos V libraries lack the necessary
contextual information to decide whether apply the case transformations
in question (perhaps some heuristics involving the presence of '.' in
princ name components - I've no position on that yet - perhaps text
intended for developers of Kerberos V applications, perhaps text for
users).

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 20 Oct 2003 14:42:16 -0400

> cases a realm name - look in krb5_get_host_realm().

Indeed, krb5_get_host_realm() provides a fallback, based on the convention. 
It is, however, still just a convention -- neither RFC1510 nor 
clarifications suggest that implementors construct realm names from 
hostnames or tell them how to do so.  What they do do is provide guidance 
to administrators choosing realm names.  As this is advice to operators and 
not implementors, it cannot be REQUIRED; in fact, requirements language a 
la RFC2119 doesn't really apply at all.

I agree that we need to be sure that extensions provides enough guidance in 
this area to allow operators to select realm names based on 
internationalized domain names.  I happen to believe that the existing text 
is sufficient, combined with the general rule that realm names are subject 
to saslprep.

We also need to adjust the text which describes the legal realm name 
formats.  Currently, "Domain style realm names MUST look like domain 
names:..." [6.1]; the text prohibits ':' and '/' in such names, but does 
not otherwise restrict the character set.  I think it would be appropriate 
to indicate that such names MUST _be_ valid domain names; that is, they 
must consist of one or more components separated by periods, where each 
component is a valid IDN label.

>> I don't think we need to say any more about realm names than
>> clarifications  already does.  Does someone disagree?  If so, can we
>> split the discussion  as it pertains to realms into a separate thread?
>

Because they are qualitatively different.  The transformation we describe 
for hostnames as principal names components are REQUIRED for implementors 
of Kerberos and Kerberos-using application protocols.  The transformation 
we describe for selecting realm names is advice to realm administrators.

>> Principal names, however, are another story.  While principal names are
>> not  domain names and should not normally be treated as such, there are
>> many  cases in which application protocols specify that the principal
>> name for a  service is to be constructed from the name of the server on
>> which the  service resides.  We even provide a name type for this, and
>> guidance to the  effect that
>>

All using GSS_C_NULL_OID means is that it is the application, not the 
GSSAPI implementation, which is acting as the "Kerberos application" and 
taking responsibility for constructing principal names correctly.  This 
makes it exactly the same as a non-GSSAPI application.  The guidance is to 
those who construct principal names from hostnames; normally this is the 
application or a Kerberos library function explicitly intended to serve 
that purpose (e.g. krb5_sname_to_principal()).

If people define alternate service naming conventions, it is up to them to 
specify whether or how hostnames should be converted.  I would hope that 
section 6.2.1 would be used as a model.  Do you think this is not enough 
for protocol designers to be able to do the right thing?  Do we need to 
provide more advice?

>> - What guidance should kerberos-extensions provide to application
>> protocols  constructing service principal names from Internet domain
>> names?
>
> and perhaps with stronger rfc2119 terminology (e.g., "MUST").

Well, it's already a MUST for 6.2.1-style names, and IMHO the requirements 
levels for other naming conventions should be left to the people defining 
them.  But my real question was regarding what exactly "extended to the 
world of Unicode" should mean.  I would like to see the working group come 
to some agreement as to what the text of 6.2.1 should say in 
kerberos-extensions.

> Plus some

The Kerberos protocol implementation should _never_ apply additional 
transformations to the principal names provided by an application, beyond 
the saslprep required by the specification.  Kerberos libraries today do 
not arbitrarily downcase the second component in two-component names whose 
first component is "host", nor do that do so to names of type NT-SRV-HST. 
The downcasing happens when an application explicitly calls a library 
routine to construct a service principal name from a hostname, and I 
believe this should continue to be the case.

Thus, our guidance is for applications constructing principal names, and to 
library routines which assist in that process, and to developers of 
alternate principal-naming conventions and those applications that use them.

So again, a few questions for the group.  FWIW, I'm trying to

- What changes need to be made to the text describing what are legal realm 
names, in order to allow for domain-style realm names derived from 
internationalized domain names?

- Given an answer to the above, what guidance is needed to realm 
administrators in selecting realm-style domain names?  Is the current 
language (pick a domain name you own and upcase it) sufficient?  Remember 
that this guidance is to humans, and humans do not come with nameprep 
implementations.

- Do we need to provide guidance to Kerberos and application implementors 
on the construction of realm names from server host names?  Some existing 
libraries do this as a last resort; should we encourage or discourage such 
behaviour?  Should we describe how to do it?

- Is it the opinion of the group that additional transformations beyond 
saslprep, such as downcasing hostnames, should be applied only by 
applications constructing principal names (and by library routines 
explicitly intended to assist in that process, like 
krb5_sname_to_principal) and never by the Kerberos protocol implementation? 
If so, do we need language which makes this clear?  If not, who should 
apply such transformations and under what circumstances?

- What should section 6.2.1 (describing service principal names derived 
from hostnames) say on the subject of constructing principal names form 
internationalized hostnames?  Should it require the application of nameprep?

-- Jeff