Subject: Re: IDNA encoding for Kerberos host names

From: Ienup Sung <[email-masked]>
Date: Thu, 09 Oct 2003 14:51:53 -0700 (PDT)

I do believe I understand your point and explanations.

The things that I'm most concern about is how to make the Kerberos inter-
operable with IDNA applications particularly on domain style host and domain
name components in the principal and realm names.

Obviously, people are seeing and will see host/domain names with IDN (could be
in ACE, Japanese Shift_JIS, ISO-8859-15, UTF-8, and so on) in grand scale and
those IDN names will be given to the Kerberos space and vice versa for
realms and principal names.

With an assumption that you're agreeing on the above paragraph, my concern is
on the interface (i.e., interaction point) between the IDNA space and
the Kerberos space.

Yes, the extension will need more than what Nameprep can provide.
What I'm saying is the answer might not be the SASLprep alone.

Obviously for me, if the SASLprep will be adapted as the Stringprep profile for
entire PrincipalName and Realm, then, there will be incompatibilities due
to the fact that IDN names are going to be non-equivalent between
the IDNA space and the Kerberos space and for that, there should be some
clear descriptions on the incompatibilities that I mentioned and also
on the ways to deal with such incompatibilities instead of
leaving things to people's wildest, own, ideas/interpretations/gueses.
Or, the WG could define its own profile and/or use existing profiles with
certain pre- and post- operations defined correctly so that
the maximum compatiblity can be acheived with and among protocols already
exist and also being developed, once again, on the domain style host and
domain names.

I believe for successful deployment of the extension onto non-ASCII portion of
world that is gearing toward to the IDNA, providing some level of compatibility
and also written considerations on the IDNA should benefit the extension
greatly in my opinion. If you already agree on this, please forgive me writing
on this and also forget about this paragraph.

With regards,

Ienup

] Date: Thu, 09 Oct 2003 16:09:50 -0400
] From: Jeffrey Altman <[email-masked]>
] Subject: Re: IDNA encoding for Kerberos host names
] To: Ienup Sung <[email-masked]>
] Cc: [email-masked]
] MIME-version: 1.0
] Content-transfer-encoding: 7bit
] X-Accept-Language: en-us, en
] X-No-Spam-Score: Local
] X-Scanned-By: MIMEDefang 2.35
] 
] These differences are necessary because the use of strings in Kerberos 
] are case sensitive
] and strings in DNS are case insensitive.   Kerberos strings also allow 
] the use of ' ' and
] '.' which are not permitted in DNS.  There are also differences in the 
] use of C0 controls.
] 
] These distinctions have absolutely nothing to due with 
] internationalization.  It is just
] as true in an ASCII-only world as an internationalized world that DNS 
] strings and
] Kerberos strings cannot be arbitrarily mapped from one to the other. 
] 
] It is for exactly this reason that there are restrictions on the types 
] of REALM and host
] names which can be used within Kerberos if DNS TXT and DNS SRV records 
] are to be used
] to for distributing Kerberos REALM configuration information.
] 
] Jeffrey Altman
] 
] 
] 
] Ienup Sung wrote:
] 
] >Sure. One of the examples below.
] >
] >The SASLprep does not use B.2 or B.3 of the Stringprep. The B.2 and the B.3
] >are case folding mappings, the former to be used with Normalization and
] >the latter to be used with no normalization. And yet the SASLprep does
] >Normalization KC (a.k.a. into NFKC).
] >
] >In the IDNA/Nameprep, the Normalization with NFKC and the Case Folding B.2
] >go together as intended, i.e., in the IDNA/Nameprep, the following will be
] >done for a character 'a':
] >
] >	b = NormalizeWithKC(Fold(a));
] >	c = NormalizeWithKC(Fold(b));
] >	if c is not the same as b, add a mapping for "a to c".
] >
] >where such 'a' characters exist and are from some Greek characters and many
] >symbols that contain Latin characters (of the Unicode).
] >
] >The SASLprep's sans-Fold() wouldn't be yielding the same mapping table.
] >
] >Hence the domain style names between the IDNA applications and the Kerberos
] >principal names/realms loose compatibility/interchangeability/transitivity.
] >
] >With regards,
] >
] >Ienup
] >
] >
] >] Date: Thu, 09 Oct 2003 15:35:55 -0400
] >] From: Sam Hartman <[email-masked]>
] >] Subject: Re: IDNA encoding for Kerberos host names
] >] To: Ienup Sung <[email-masked]>
] >] Cc: [email-masked]
] >] MIME-version: 1.0
] >] 
] >] >>>>> "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: Sam Hartman <[email-masked]>
Date: Thu, 09 Oct 2003 18:34:13 -0400

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

    Ienup> Obviously, people are seeing and will see host/domain names
    Ienup> with IDN (could be in ACE, Japanese Shift_JIS, ISO-8859-15,
    Ienup> UTF-8, and so on) in grand scale and those IDN names will
    Ienup> be given to the Kerberos space and vice versa for realms
    Ienup> and principal names.

I believe I disagree with this paragraph.

Both kerberos and DNS will see domain names.  Kerberos should never
see ACE encoded domains.

The Kerberos name should never be given to DNS and the DNS name should
never be given to Kerberos.  Instead, the same user input domain--call
this string the raw domain-- should be given to both Kerberos and DNS.
Kerberos converts the string to Unicode, runs saslprep and encodes as
utf8.  DNS splits the string into labels, converts the string to
Unicode, runs nameprep, and encodes the string.