Subject: Re: IDNA encoding for Kerberos host names

From: Ienup Sung <[email-masked]>
Date: Thu, 09 Oct 2003 10:27:57 -0700 (PDT)

Actually I did a comparison between the SASLprep and the Nameprep
(a Stringprep profile used in the IDNA as you know) a few days ago and
found those two are not compatible.

Thus, for that particular issue, I think either use of the two profiles,
i.e., the Nameprep for the domai name style host/domain name component of
principals and realm and the SASLprep for user and presumably other
components, or, somehow come up with one profile that will be compatible with
both the SASLprep and the Nameprep would be quite desirable and necessary.
(I presume the latter is in the work but it seems Samuel's email only
mentioned the SASLprep...) Otherwise, names wouldn't match exactly in some
cases. 

And, thanks for your emails. I believe the summary Samuel provided are what
I've also gotten from other members of the WG. I would like to point out
that I'm not interested in insisting on the ACE at the principals/realms.
I'm more interested in the compatibility and I think the extension should
describe about how to deal with it as clearly as possile. And, I'm also
hoping that the WG is also interested in having a clause/section
or two at the extension describing the compatibilty issue with the IDNA to
simply provide better compatibility and reduce/minimize any future issues,
problems, or both (which could be similar issues/problems that people have
seen on the RFC1510 GeneralString used on the PrincipalName and Realm).

With that assumptions in my mind, I'm writing a very brief memo listing 
the sub-issues that I think the WG might consider discussing for the
compatibility issue that I rather vaguely raised as an issue yesterday.

With regards,

Ienup

] Date: Thu, 09 Oct 2003 11:29:00 -0500
] From: "Douglas E. Engert" <[email-masked]>
] Subject: Re: IDNA encoding for Kerberos host names
] To: Sam Hartman <[email-masked]>
] Cc: Ienup Sung <[email-masked]>, [email-masked]
] MIME-version: 1.0
] Content-transfer-encoding: 7bit
] X-Accept-Language: en
] 
] 
] 
] Sam Hartman wrote:
] > 
] > >>>>> "Ienup" == Ienup Sung <[email-masked]> writes:
] > 
] >     Ienup> Hello everyone, I quite recently joined the working group
] >     Ienup> and I'm concerning about the IDNA RFCs and the upcoming(?)
] >     Ienup> extensions to the Kerberos, esp., on the compatibility.
] > 
] >     Ienup> I'm still reading the email archives and it will take some
] >     Ienup> more time for me to finish reading and at leat have some
] >     Ienup> background idea on what has been discussed and also what
] >     Ienup> are the general agreements on the issues but if it has not
] >     Ienup> been completed (it looks that way), I would like to propose
] >     Ienup> to work on IDNA compatibility issues, e.g., IDNA's ACE
] >     Ienup> names and principals/realms, proper Stringpreps.
] > 
] > Hi.  To avoid opening a can of worms I'll try and summarize things
] > that we seemed to have already decided for you.  You can attempt to
] > reopen some of these discussions but you will need a strong reason for
] > doing so and will probably face significant opposition.  My summary of
] > what decisions have been made is not authoritative; the working group
] > chair judges consensus.  Hopefully Doug will chime in if he thinks
] > I've gotten something wrong.
] 
] No, you have it right, The statements below are a good summary of the
] consensus.  
] 
] 
] > 
] > We've decided that we will use the saslprep stringprep profile.  That
] > profile can be found in draft-ietf-sasl-saslprep.  This is not the
] > same as the nameprep profile.  Examples of why this is necessary
] > include the fact that Kerberos principals are case sensitive and that
] > Kerberos principals can contain the ascii dot character, which is
] > excluded by nameprep.  Remember domain names are split up intolabels;
] > Kerberos principals are not.
] > 
] > We've decided that Kerberos clarifications will only officially
] > support US ASCII.  Several implementations support other character
] > sets in proprietary manners.  For example Microsoft just sends UTF8.
] > If I had to do internationalization with Kerberos today, I'd send UTF8
] > using the saslprep profile.  The IETF will not standardize this
] > solution.
] > 
] > We've decided that Kerberos extensions will send UTF8 using the
] > saslprep profile for strings that are queries or stored in databases
] > and will send unnormalized UTF8 for error messages and other text
] > strings intended for display.
] > 
] > We are in the middle of a discussion that seems to be reaffirming the
] > consensus that we will not use IDNA's encoding anywhere in the
] > Kerberos protocol.  Several of us seemed to believe that we had
] > already made this decision a while back, but reaffirming the consensus
] > seemed easier than finding the appropriate minutes.  You can look at
] > the archives for the last week to see the reasoning why we believe
] > this is the right decision.  This issue is probably still technically
] > open, but you'd need to come up with responses to the points already
] > raised that were sufficient to convince people you were right.
] > 
] > Hope this helps you.
] 
] -- 
] 
]  Douglas E. Engert  <[email-masked]>
]  Argonne National Laboratory
]  9700 South Cass Avenue
]  Argonne, Illinois  60439 
]  (630) 252-5444

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 9 Oct 2003 10:45:45 -0700

> found those two are not compatible.

Unfortunately they have to be.  That's because RFC1510's "stringprep
profile" is incompatible with pre-IDN DNS' "stringprep profile."

 - RFC1510 Kerberos V allows pretty much all ASCII characters and is
   case-sensitive.  (Technically RFC1510 allows any characters that can
   be used with GeneralString, but for various reasons it turns out that
   only ASCII can be used interoperably with RFC1510.)

 - DNS allows only ASCII LDH and is case insensitive.

There's no way to make RFC1510's "stringprep profile" compatible with
pre-IDN DNS's, obviously.  But there also isn't any way to make extended
Kerberos V's stringprep profile compatible with IDNA's - not without
breaking compatibility with RFC1510 deployments.

> both the SASLprep and the Nameprep would be quite desirable and necessary.

But it isn't always possible to know that a given component of a
principal name is a host/domain name, so it isn't always possible to
apply IDNA's nameprep instead of the SASL/Kerberos stringprp profiles.

I gave an example this week involving GSS-API applications and
user-provided names imported with GSS_C_NULL_OID as the name type.
Other examples are possible, no doubt, perhaps involving the SASL GSS-*
mechanisms (at least one implementation of which imports GSS-API names
with GSS_C_NULL_OID).

This is a result of: not having "domain name slots" in Kerberos V +
additional API layers that make it difficult or impossible to set some
"domain name slot" conventions.

> seen on the RFC1510 GeneralString used on the PrincipalName and Realm).

Yes, we'll definitely have to have such text.

> compatibility issue that I rather vaguely raised as an issue yesterday.

Excellent.  Thanks,

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 09 Oct 2003 13:57:21 -0400

>found those two are not compatible.
They are not compatible because they are used for different purposes.  
If we believed there was a requirement that there be a one to one 
mapping between names represented in KerberosStrings and those 
represented in DNS we would have produced a different stringprep 
profile.  However, as far as we can tell this is not the case.  The DNS 
database and the Kerberos database are completely independent.  Names 
stored in the DNS database are not used for queries to the Kerberos 
database.  Nor are names stored in the Kerberos database used for 
queries to the DNS database. Instead there is a user input string which 
is used to query DNS and to query Kerberos.  This user input string is 
separately canonicalized differently prior to each query.  The 
requirement of the canonicalization is that the resulting string is 
unique in the appropriate namespace.  Hence, there user application 
whether internally or via the Resolver and Kerberos libraries will 
produce two separate query strings from the user input string.  One for 
use in querying DNS and the other for querying Kerberos.

>mentioned the SASLprep...) Otherwise, names wouldn't match exactly in some
As described above we do not believe there is a requirement for there to 
be a single
canonicalization for both DNS and Kerberos. 

>seen on the RFC1510 GeneralString used on the PrincipalName and Realm)
>  
>
Please feel free to submit to the working group a list of use scenarios 
you would like to
see addressed in the upcoming Extensions work.  We will endeavor to 
address them either
within RFC1510-ter or within an Informational Draft on 
internationalization issues
related to migrating to RFC1510-ter.

Jeffrey Altman

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 09 Oct 2003 21:33:53 +0200

Jeffrey Altman <[email-masked]> writes:

> profile.  However, as far as we can tell this is not the case.  The
> DNS database and the Kerberos database are completely independent.
> Names stored in the DNS database are not used for queries to the
> Kerberos database.  Nor are names stored in the Kerberos database used
> for queries to the DNS database. Instead there is a user input string
> which is used to query DNS and to query Kerberos.  This user input
> string is separately canonicalized differently prior to each query.
> The requirement of the canonicalization is that the resulting string
> is unique in the appropriate namespace.  Hence, there user application
> produce two separate query strings from the user input string.  One
> for use in querying DNS and the other for querying Kerberos.

What if the application receive a hostname via some protocol? That
protocol could be IDN-unaware, then the hostname may be in Nameprep'ed
ACE form.  The application could be a CGI application running on a
host with one Kerberos host key per virtual HTTP host, and would need
to find the right host key to use depending on the query.  Perhaps
decoding the ACE string using ToUnicode, and then performing SASLprep
on the string, leads to different results than performing SASLprep on
the original, pre-Nameprep:ed, string.

Thanks,
Simon

---

From: Sam Hartman <[email-masked]>
Date: Thu, 09 Oct 2003 15:35:55 -0400

>>>>> "Ienup" == Ienup Sung <[email-masked]> writes:

    Ienup> Actually I did a comparison between the SASLprep and the
    Ienup> Nameprep (a Stringprep profile used in the IDNA as you
    Ienup> know) a few days ago and found those two are not
    Ienup> compatible.

Can you describe some real-world problems we would run into with
saslprep that we don't already have with case sensitive domain
components in principals?

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 09 Oct 2003 15:55:46 -0400

The point is that this is simply not a safe transformation to make. 
An ACE-string is not case-sensitive and does not permit '.'.  Even if
you were to convert this string back to Unicode it would not be possible
to ensure that the string could match an entry in the Kerberos database.
The Kerberos namespace and the DNS namespace are disjoint. 

As pointed out yesterday, application level protocols should not be
passing around strings in ACE form.  If they do they are guaranteed
to have problems when attempting to interoperate with namespaces other
than DNS.  Application which pass hostname identifiers utilizing ACE
form are restricting themselves to name lookups in DNS. 

I feel very strongly about my opinion that ACE form must be restricted
to DNS query and storage strings.  It is not appropriate for an application
to use ACE form as a means of long term internal representation. 

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 9 Oct 2003 13:44:53 -0700

> to ensure that the string could match an entry in the Kerberos database.

I'm not sure I agree.  As long as the IDNA nameprep is a subset of the
SASL/Kebreros stringprep it should be possible to apply ToUnicode to all
the labels of an input domain name, join the labels with '.' then apply
the SASL/Kerberos stringprep - the result should match a Kebreros
principal name created by applying the SASL/Kerberos stringprep to an
otherwise unnormalized Unicode string that, split by '.' (and all
characters that map to it) looks just like the presentation form of the
IDN in question.

And if not, perhaps we can change the SASL/Kerberos profile to make it
so.

What a mouthful.

> form are restricting themselves to name lookups in DNS. 

I think what we can say is that applications that can receive ACE names
(e.g., from user input) should convert ACE names to whatever internal
form they would use otherwise (preferably Unicode) as early as possible.

> to use ACE form as a means of long term internal representation. 

IIUC it is also intended that users that otherwise cannot input IDNs be
able to input their ACE forms.  This can only work in a limited fashion,
but it can work better if the application can convert immediately from
ACE form to internal form (again, preferably Unicode).

Cheers,

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 09 Oct 2003 17:28:44 -0400

>And if not, perhaps we can change the SASL/Kerberos profile to make it
You are forgetting about case-folding necessary for IDN.  The two profiles
are not compatible.

>form they would use otherwise (preferably Unicode) as early as possible.
Applications which receive ACE names as user input really should not exist.
If an application is Unicode aware, then it should be accepting input as
UCS-2 or UTF-8. 

If the application is not Unicode aware, then the ACE input is going to
look no different to the application than standard ASCII.  In which case
the string that you call an ACE encoding is really just an ASCII string
and MUST be treated as such.  It is not possible for an application without
additional input to decide if "[email-masked]" is
a valid principal name or not.  Currently 
"xn--krksmrgs-5wao1o.josefsson.org"
is a perfectly valid REALM name.  So is "XN--KRKSMRGS-5WAO1O.JOSEFSSON.ORG"
and "xn--KrKsMrgs-5wAo1O.JoseFSSon.ORG" and any other combination of case
utilization. 

A service running on a host can have multiple service principal names.
We already do this now for clusters.  Microsoft takes this to an extreme
with all of the different aliases they have for their systems.  If
applications are going to accept hostname input in ACE form, then there
must be multiple service principals generated for the service.  One
utilizing the Unicode form and one utilizing the ACE form.  In both cases
the service principals will be stored in the Kerberos database as
SASLprep'd strings. 

I must stress.  This is not a Kerberos protocol issue.  This is a Kerberos
usage issue.  If there is a need to support multiple service
principal names (aliases) for a given service, it is up to the 
implementation
specific Kerberos administration tools to make it easy for the Kerberos
administrator to manage these principals as a common service entity.

>ACE form to internal form (again, preferably Unicode).
I would assume that the platforms on which people are concerned with 
utilizing
ACE forms directly by end users are those which do not support Unicode 
at all.
Whether this is an older OS release that does not support Unicode input 
to the
DNS resolver API or an application compiled to use 8-bit locale specific 
input
instead of Unicode, it really does not matter.  In either case, it is not
going to be possible for the application to translate from ACE to Unicode.

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 9 Oct 2003 15:00:44 -0700

> You are forgetting about case-folding necessary for IDN.  The two profiles

Well, yes, but people have to deal with this today - we mostly make do
by using a single case consistently, and where folks do the only thing
to add to my description is to fold the case of the ToUnicode output
(DNS is case-insensitive, but case preserving).

I think we could make helpful recommendations in this regard, much as
clarifications recommends that realm names be all uppercase.  But wait!
RFC1510 already recommends (lower case "must" - rfc1510 precedes rfc2119
- which may or may not be stronger than RFC2119 "RECOMMENDED") folding
hostnames to lower case for NT-SRV-HST principals.

> Applications which receive ACE names as user input really should not exist.

I agree, but IDNA doesn't.

> If an application is Unicode aware, then it should be accepting input as

Or whatever non-Unicode locale is being used for input, understanding
that this may limit what IDNs may be input.

> and "xn--KrKsMrgs-5wAo1O.JoseFSSon.ORG" and any other combination of case

But IDNA does allow applications to display ACE forms when IDN forms
cannot be displayed (e.g., because the locale's charset does not allow
a given IDN to be displayed correctly, or because of missing fonts,
say), and IDNA does allow applications to input ACE forms.  And IDNA
does not say that ACE forms MUST be tagged as such - IDNA uses soft
words in this respect in section 6.1.  I think it is within IDNA to
determine ACE-ness by simple inspection of a label (or, rather, by
applying ToUnicode and comparing to the orifinal), though that does mean
reserving that portion of the namespace that starts with ACE prefixes
for ACE names (not that I agree that this should be so).

> the service principals will be stored in the Kerberos database as

Perhaps extensions should recommend this.

> ACE forms directly by end users are those which do not support Unicode 

I would not assume this.

Font issues, users' choice of locales, etc.. can lead to a user choosing
to use ACE forms even on platforms that support Unicode.

Cheers,

Nico
--