Subject: IDNA encoding for Kerberos host names

From: [email-masked] (Sam Hartman)
Date: Mon, 6 Oct 2003 21:57:42 -0400 (EDT)

It's my recollection that we have a working group consensus that we
will not use the IDNA encoding for domain components of Kerberos
principal names.  I'm fairly certain we explicitly discussed this
point at some time in the past but seems like an obvious wrong
direction for several reasons.

First, it seems inappropriate to apply that encoding to non-domain
components of principals.  It's not what we are doing for extensions,
and it is non-interoperable with any implementation that supports
internationalized characters.

Second, the IESG character set policy says that we need to support
UTF8 as an encoding.  Presumably the DNS people didn't have to do that
because they cannot.  But it seems silly to support both UTF8 and IDNA

Finally, I don't see any benefit we gain from IDNA.

I just wanted to confirm this is not the direction we are heading in.

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 07 Oct 2003 00:40:55 -0400

IDNA was one of the alternatives to the use of string-prep profiles we 
considered
quite a long time ago.  At the time of the evaluation there were several 
possible
IDN solutions of which IDNA was still in the early stages of development.

The basic reason for not using one of the IDN solutions is that the 
problem space
for Kerberos and DNS are quite different.  The best fit for us was the 
direct use
of Unicode with a reasonable normalization set encoded in UTF-8.  The 
only place
that IDNA should be found is within a resolver library. 

I have heard that there is some discussion that some vendors might be 
considering
using IDNA encoding for hostnames in service principals as a means of 
providing internationalization which the confines of IA5Strings.  While 
this is certainly a conceivable approach I believe it is wrong.  Not 
only does it not solve the general problem of internationalizing 
principals, realms, passwords, salts, and error text; but it seriously 
increases the already existing interoperability problem between 
RFC1510/Clarifications based Kerberos implementations.  At least with 
the current implementations we are able to make a fairly good 
statistical guess based upon the characters used in the string as to 
whether or not the string is US-ASCII, an 8-bit ISO Latin character set, 
an 8-bit IBM/Microsoft Code Page, or UTF-8.  At the very least it would 
be possible for implementors to encode knowledge of the OS locale into 
the KDC configuration and use it to provide a significant degree of 
interoperability between Clarifications and Extensions via the use of 
character-set translation between the "just send 8-bit" abuse of General 
String and the UTF-8 used in the Extensions version of KerberosString.  
Since there is no means of detecting the difference between IDNA and 
US-ASCII it would be impossible for old and new clients to be able to 
interoperate.

Vendors should wait for extensions or assist us in getting the work 
completed.

Jeffrey Altman

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 07 Oct 2003 07:41:35 +0200

> internationalized characters.

There is no reason to apply the IDNA encoding to non-domain components
of principals.  The IDNA document is clear on what to apply the
encoding to; domain names only.

A host principal would be 'host/xn--rksmrgs-5wao1o.josefsson.org.

> because they cannot.  But it seems silly to support both UTF8 and IDNA

I don't understand this reason.  Yes, you need to support UTF-8, but
until you do, and until you make service principals an "IDN-aware
domain-name field" (in the terminology of IDNA), you follow the IDNA
rules and put ASCII encoded representations in domain name fields.

Not following the IDNA rules when you deal with IDNs essentially
create a new IDN solution.

> Finally, I don't see any benefit we gain from IDNA.

We gain internationalized domain names that work in a backwards
compatible and interoperable way.  What other solution for IDNs in
Kerberos do you propose?

Kerberos Extensions may chose to make service principals IDN aware
domain-name fields, but that doesn't change matters for a pure 1510bis
implementation; I believe they should be using IDNA encoded hostnames
because the protocol is ASCII only (IA5String) and doesn't say
anything as far as IDN is concerned.

Thanks,
Simon

---

From: Matt Crawford <[email-masked]>
Date: Tue, 07 Oct 2003 08:18:09 -0500

I think the most important factor is how the kerberos implementation 
will interact with resolvers and nameservers of various vintages, and 
how well it will match user expectations.  When a DNS name is encoded 
one way in Kerberos and another way in all other contexts, there's 
bound to be a failure.

But the really sticky part is going to be the de facto link between 
realms and DNS domains.  That may be enough to sway the choice away 
from IDNA completely, for all parts of the principal name.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 07 Oct 2003 09:50:08 -0400

> encoding to; domain names only.

Yes, it is indeed clear.  The encoding applies only to domain names placed 
in non-IDN-aware domain name slots.  Kerberos principal names are _not_ 
domain name slots.  They are not used to store domain names, they are not 
looked up as domain names, and most importantly, they are not and cannot be 
compared as domain names.  RFC3490 specifies rules which must be followed 
when comparing domain names, and these rules do not and cannot apply to 
Kerberos principal names, which are compared as case-sensitive strings (in 
the case of kerberos-extensions, after string preparation as described in 
saslprep).  RFC3490 is also quite clear on what constitutes a domain name 
slot:

   A "domain name slot" is defined in this document to be a protocol
   element or a function argument or a return value (and so on)
   explicitly designated for carrying a domain name.
   ... General text that just happens to contain a domain
   name is not a domain name slot

Kerberos principal names are _not_ explicitly designated for carrying 
domain names; thus, they are not domain slots.

> A host principal would be 'host/xn--rksmrgs-5wao1o.josefsson.org.

No, certainly not.  This will create a serious future interoperability 
problem, because Kerberos principal names are _not_ domain name slots, and 
in a kerberos-extensions KDC (or in one of today's KDC's using just-send-8 
or unnormalized UTF-8) that host principal will _not_ compare equal to the 
host principal derived from the same domain name without the extra layer of 
encoding (in extensions, you'd be sending the UTF-8 encoding of the IDNA 
encoding of a unicode string; in other words, a double-encoded string). 
This means you will be sad.

Of course, you are welcome to name your hosts whatever you want.

> rules and put ASCII encoded representations in domain name fields.

Principal names are not domain name slots.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 07 Oct 2003 16:38:17 +0200

Jeffrey Hutzelman <[email-masked]> writes:

> Yes, it is indeed clear.  The encoding applies only to domain names
> placed in non-IDN-aware domain name slots.  Kerberos principal names
> are _not_ domain name slots.  They are not used to store domain names,
> they are not looked up as domain names, and most importantly, they are
> not and cannot be compared as domain names.

What about principal names of the NT-SRV-HST type?  They hold a
service identifier and a Internet hostname.  It is widely used.
Clarifications say that if a principal is on the form SERVICE/HOST,
that name type SHOULD be used.  Some applications synthesize these
principals names, from domain-name fields taken from other sources.
For these principal names, it seems reasonable to consider the second
element a domain name field.

I agree with what you are saying, for principals in general, though.

Thanks,
Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 7 Oct 2003 08:49:11 -0700

IDNA cannot be used interoperably with RFC1510, that, I think we've
established and should be obvious given the existing "just send 8" and
"just send UTF-8" deployed implementations.

I believe IDNA should not apply to extensions either, though for
different reasons:

 - There's no "domain name slots" in Kerberos (the closest any part of
   Kerberos comes to being a "domain name slot" is the realm name - but
   see below).

 - Traditionally the Kerberos namespace has been less restrictive than
   DNS', in part because DNS is not and has not been the only name
   service used in conjunction with Kerberos.

   We should not change this, especially for Kerberos principal name
   components.

    - Further, using IDNA "just for components known to be host or
      domain names" still goes against this tradition and binds Kerberos
      to DNS.

 - Kerberos has always been case-sensitive, DNS is case-insentive - a
   fundamental divergence that should not be papered over with IDNA as
   it changes the semantics of Kerberos for existing deployments of
   RFC1510 Kerberos.

   We should not introduce gratouitous incompatibilities in Kerberos
   extensions.

 - Given that it is possible to use DNS as a name service for users
   (i.e., Hesiod), and even if few organizations do so, should IDNA
   apply to all non-domain name uses of principal name components if it
   applies to the domain name uses of the same?

   Clearly, no as that really would impose unreasonable, gratouitous
   incompatibilities on existing deployments (see above).

 - UTF-8 is just cleaner.

 - There are probably other reasons, which escape me at the moment.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 7 Oct 2003 08:53:23 -0700

> one way in Kerberos and another way in all other contexts, there's 

Ah, but IDNA does not apply to all protocols.  It applies to all
"IDN-unaware domain name slots" where "domain name slot" is defined in a
very narrow and DNS-specific manner.

But you point out an interesting issue: IDNA ACE encodings are supposed
to be usable now, if un-friendly, in various contexts.  What happens
when IDNA ACE encodings "leak" from contexts where they belong to
contexts where they do not?

> from IDNA completely, for all parts of the principal name.

"away?"

I've seen the point argued the other way...

But see my other post today, specifically the point about fundamental
namespace diferences between Kerberos and DNS.

Cheers,

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 07 Oct 2003 13:39:43 -0400

>I agree with what you are saying, for principals in general, though.
When you first look at IDNA it seems reasonable to use for service 
hostnames, except that the entity that performs the DNS lookup on the 
service hostname and the specifies the name to use in the Kerberos 
service ticket request is an application which sits above both.  If you 
wanted IDNA encoding to be used it would be necessary not for Kerberos 
to know about IDNA; but for the application developer for the specified 
protocol to know to use IDNA. 

It is impractical for the specifications of all Kerberos aware 
application protocols to be updated specifically to specify the use of 
IDNA encodings when transparent use of UTF-8 will be available real soon 
now.

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 7 Oct 2003 12:40:44 -0700

> What about principal names of the NT-SRV-HST type?  They hold a

Kerberos principal name types are hints; they do not partition the
namespace.

> element a domain name field.

Where one uses a hostname/domain name in Kerberos principals depends on
various conventions.  The service/hostname convention does not apply to
all two-component names.  Some implementations use hostnames in
one-component principal names and any user of Kerberos is free to
establish their own conventions (see a recent thread in the SASL WG list
about "domain-based" names).

In fact, it is conceivable that an application may not know which, if
any component of a given principal contains a hostname or domain name.

Consider GSS-API name importation with GSS_C_NULL_OID as the name type
and name-based authorization.  This allows users to setup their own
principal naming conventions.  One example of a deployed application
that in fact allows users to do so is Secure NFS as implemented in
Solaris (2.6 & 7 w/ SEAM, 8 and 9), where the client principal name for
any given user is their ccache's default principal and where
authorization is based on mapping exported GSS-API mechanism names (MNs)
to Unix usernames (and their associated group membership[s).

Thus if someone wanted to use principal names like

<application>/<"production"|"dev"|"test"|"marketing"|...>/<hostname>

they could (and they can).  And would users be forced to manually invoke
IDNA transformations to construct such names?  Should they be?  (I don't
think they should be.)

So, not only is there no such thing as a "domain name slot" in Kerberos
V (even realm names) but there is no such thing as a complete set of
principal naming conventions set in stone knowledge of which could be
hardcoded by applications, which may well mean that using IDNA in
Kerberos V [extensions] would mean exposing IDNA to users who should not
have to know about IDNA.

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 07 Oct 2003 16:06:12 -0400

Another thing to consider about IDNA names and Kerberos is that they
don't actually buy you any interoperability.

No one is using them today.  We all seem to be in agreement that we
are moving to full UTF8 for extensions.

If you want internationalization for pre-extensions Kerberos, why
would you pick some new way of encoding names that is only appropriate
for host-based principals?  Why wouldn't you choose to be
interoperable with Microsoft or one of the other just-send-8
implementations?  Yes, you're working outside the spec.  But you're
going to be working outside the spec until extensions comes out.

But if you implement one of the existing just-send-8 strategies, at
least you manage to interoperate with existing implementations.  You
also end up with a well-understood migration path.

--Sam

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 08 Oct 2003 18:01:34 +0200

I agree with your conclusion that the best thing is to use transparent
UTF-8, still I'd like to offer some counter-arguments that IDNA
advocates might use.  I won't be pushing this issue further.

Jeffrey Altman <[email-masked]> writes:

> service ticket request is an application which sits above both.  If
> you wanted IDNA encoding to be used it would be necessary not for
> Kerberos to know about IDNA; but for the application developer for the
> specified protocol to know to use IDNA.

I don't follow.  One point of IDNA is that old protocols need not be
modified, rather implementations will place the ASCII encoding in the
old protocols.  It appears that I can use internationalized domain
names in, e.g., Kerberos telnet today, based on the IDNA solution.

IDNA is used in SMTP, HTTP, DNS, and other protocols, to provide
internationalized domain names.  No changes to those protocols were
required.

> IDNA encodings

I'm not sure I see why any changes are required, even if the principal
name issue in Kerberos seem tricky because there isn't a proper domain
name field.

For a command line telnet application, some glue code can be built
around it to ASCII encode the host name parameter to the tool.

For a Kerberos administration tool that create host keys, some glue
code be built around it to ASCII encode the host name parameter to the
tool.

Those two steps appear to be all that is required to make IDN work
with old Kerberos telnet implementations, without violating the
Kerberos protocol by sending raw UTF-8.

> transparent use of UTF-8 will be available real soon now.

Transparent use of UTF-8 is not a IDN solution; a real IDN solution
have to deal with normalization issues.  It should use the ToUnicode
part of the IDNA specification.

Furthermore, if you want to use transparent UTF-8, in several
protocols, changes will be required since they currently use ASCII (or
non-UTF-8 compatible fields, such as GeneralString) for host names.
As you admit, the Kerberos protocol doesn't support UTF-8 today, and
supporting it requires a revised document.

Thanks,
Simon

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 08 Oct 2003 12:16:53 -0400

>around it to ASCII encode the host name parameter to the tool.

If you are going to IDNA enable an old telnet application by having a 
wrapper application which performs the Unicode to IDNA transformation, 
then you have no choice but to use IDNA transformed names in your 
service principal names.  Doing so at that level will require that the 
host administrator support multiple service principal names for the same 
service: the IDNA encoding as well as the UTF-8 encoding. This is 
exactly the reason why the translation from Unicode to IDNA must be 
performed transparently with the resolver library and not at or above 
the application layer.

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 8 Oct 2003 09:34:09 -0700

> performed transparently with the resolver library and not at or above 

Well, technically, if you change the application (as opposed to wrapping
around it) you can make sure that ACE names are only used with APIs
that meet the "IDN-unaware domain name slot."

But I agree with your position.  It's unfortunate that IDNA places such
an emphasis on implementation at the application level - fortunately it
does not rule out implementation at the resolver level.

As I understand it the emphasis on implementation of IDNA at the
application level relates to implementors of multi-platform applications
such as web browsers who could not ensure that the resolver on all of
their target platforms would be IDN-aware.

Cheers,

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 08 Oct 2003 12:49:57 -0400

>their target platforms would be IDN-aware.

Technically, all applications are multi-platform.  The issue here really 
is not one
one of application implementation but application protocols.  So I have 
an IDNA-aware
web browser which uses a KRB5 GSSAPI implementation for authentication, 
what name is
the browser expected to provide to GSSAPI for the service?  The 
application cannot
trust that it can use UTF8 with GSSAPI, so it will pass in an 
IDNA-encoded name. (?)
It seems like the Kerberos administrators are going to be stuck with 
multiple names
for the same service no matter what.

This does not make me happy.

- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 8 Oct 2003 09:54:45 -0700

> Technically, all applications are multi-platform.  The issue here really 

I was referring to portable applications - surely you won't argue that
all apps are portable to more than one platform :)

> trust that it can use UTF8 with GSSAPI, so it will pass in an 

My point is that if one is to implement IDNA at the application, then
one must also go through tht process of labelling APIs' parameters/
struct fields/whatever as "domain name slots" or "not domain name
slots," + IDN-awareness.

I think the amount of work needed to do so is extensive, but it can be
avoided by just implementing IDNA at the lowest possible layer (i.e., at
the resolver).

I think we agree that "leakage of IDNA ACE names" to contexts where the
such are not to be used will cause problems.  And we agree that Kerberos
V [rfc1510 *and* extensions] is or will be one such context where IDNA
does not apply and where use of ACE names will cause trouble.

> for the same service no matter what.

Not if IDNA ACE name leakage is avoided - see above.  Again, the easiest
way to prevent such leakage is to implement IDNA at the resolver.

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 08 Oct 2003 13:13:21 -0400

>all apps are portable to more than one platform :)
No, I won't argue that all application implementations are portable.

>way to prevent such leakage is to implement IDNA at the resolver.
Absolutely, the resolver is where this should go.  

Jeff

---

From: Martin Rex <[email-masked]>
Date: Wed, 8 Oct 2003 19:37:36 +0200 (MET DST)

Hi Jeff,

Would it be possible that you send your email to ietf-krb
without S/MIME signatures?

Thanks,
-Martin

Jeffrey Altman wrote:
> 
> This is a cryptographically signed message in MIME format.
> 
> 
> --------------ms020909090909030309060407
> Content-Type: application/x-pkcs7-signature; name="smime.p7s"
> Content-Disposition: attachment; filename="smime.p7s"
> Content-Description: S/MIME Cryptographic Signature
> Content-Transfer-Encoding: base64
> 
> MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC
> AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV
> BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx
> HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl
> bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf
> MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h
> bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA
> sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL
> sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A
> aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy
> DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5
> f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB
> FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA
> DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r
> 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6
> jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw
> gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
> VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo
> MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5
> MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx
> IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF
> AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH
> jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd
> Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0
> zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr
> ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe
> +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E
> AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2
> l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S
> 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB
> AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT
> BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3
> dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv
> bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB
> FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy
> NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV
> BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT
> ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN
> BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq
> bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC
> 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww
> KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI
> MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15
> 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s
> ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY
> yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu
> IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD
> ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw
> MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw
> HAYJKoZIhvcNAQkFMQ8XDTAzMTAwODE2NDk1N1owIwYJKoZIhvcNAQkEMRYEFEO3wJQNxiEV
> mQpr3Kfx7xae5kUZMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
> AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3
> EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV
> BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT
> ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK
> MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl
> cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
> FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg
> MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAjTbMirsOZKAilZfeqmboe60nYM6g
> 6qq7IIJp3s2+GniJmRwbR9QzkxJdlUZ40ocSNfu5Hwhy+z1dSr4TCNd/JdvDL/OUBYD7o+79
> jso4td4HkTgN8gklKbc9ei/A1kJnqiViSmIEDDxhGMQVaQMPnjWOs45IHY2UFmk5Q9rZAUAs
> V4DzcJuFs7t33fEKuSWzgoVhlGUwnGhOMSPGOP7byYs26gZHTyeGBp6DYUADt5dV2UArQZg+
> K5ny4GxOuUZEMbIgkZaIqnZOs04kZtA8swJ84V9I/EIfkaamHeD5YK54CrfXcmYSATfypRI1
> HSFfSizo7WW/zZI6k3pV4GNHyQAAAAAAAA==
> --------------ms020909090909030309060407--
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 08 Oct 2003 13:52:59 -0400

> internationalized domain names.  No changes to those protocols were

Those protocols contain protocol elements which are designated for carrying 
domain names; those names, in turn, are used to name hosts or services on 
the internet which may be looked up in the DNS.  The names are not 
specially encoded, embedded in other strings, subject to cyptographic 
hashes or signatures, or used to derive encryption keys.

Principal names in Kerberos are _not_ designated for carrying domain names; 
they are multi-part strings, and it is not possible to tell which parts, if 
any, contain domain names.  Further, even if it were possible to tell, it 
wouldn't help you, because principal names _are_ specially encoded, subject 
to cryptographic hashes and signatures, and used to derive encryption keys. 
They are also looked up in a database which cannot know that a principal 
name is equivalent to the same name with some of its parts replaced by IDNA 
encodings.

> code be built around it to ASCII encode the host name parameter to the

Go ahead and do that.  When you start actually using a real unicode-capable 
kerberos-extensions-compliant KDC, you will have two choices:

1) Continue to use the funny wrappers that encode the names.  If you do 
this, you have effectively decided that the ASCII-encoded version _is_ the 
host's name, and the unencoded version is just a convenience alias that 
will be transformed algorithmically by the tools.  Note that this 
transformation probably can't be done by the DNS resolver library, because 
it is essential that the construction of Kerberos service principal names 
not be based on lookups in insecure DNS.

2) Stop using the tool, and find that you can no longer obtain service 
tickets for those hosts, because the principal name you're asking for is 
not the one in the KDB.

What you _cannot_ do is expect the KDC to magically decide that some 
components of the principal name you asked for need to be ACE-encoded 
before looking up the principal name in the KDB.  You cannot expect this 
because there is no way for the KDC to know when to do this, or which 
components to convert.  Converting all components all the time is not an 
acceptable solution, because it changes the semantics of Kerberos principal 
name comparison, which are case-sensitive and which do not arbitrarily 
consider apparently-related principal names to be equal.  You can get away 
with this sort of behavior in the DNS and in applications that manipulate 
domain names (and indeed, RFC3490 requires it), because those applications 
know when they are manipulating domain names, and will expect domain-name 
semantics.

> part of the IDNA specification.

Incorrect.  ToUnicode is not normalization, it is a whole sequence of 
operations, beginning with decoding a Unicode encoding other than UTF-8, 
and ending with a normalization step using parameters which are not 
appropriate for Kerberos (IDN nameprep is _highly_ inappropriate for 
Kerberos.  It requires case-folding, which is inconsistent with Kerberos 
principal name comparison semantics, and it also prohibits certain 
characters which are extremely common in Kerberos principal names, like 
'.').

It is the concensus of the Kerberos working group that the next version of 
the Kerberos protocol will use UTF-8 encoding for realm names, principal 
name components, passwords, salt strings, and error text.  This decision 
was made in view of IETF policy regarding internationalized character sets 
and character set encodings (particularly, the mandate that protocols be 
able to support the UTF-8 encoding), and of the fact that these strings are 
subject to cryptographic hashes and signatures and are used to derive 
encryption keys, making it difficult to obtain useful results from 
character-set conversion or re-encoding, and thus desirable to limit the 
number of possible encodings.

It is also the concensus of the Kerberos working group that consistent 
normalization rules will be used for all realm names, principal name 
components, passwords, and salt strings.  This is necessary for protocol 
simplicitly, because these elements are often derived from one another, and 
because lacking this rule it would be difficult to tell which normalization 
rules to apply to which strings -- for example, which rules apply to which 
components in a given principal name.  The rules we have chosen are those 
described in draft-ietf-sasl-saslprep-03.txt, which are the result of joint 
work between the Kerberos and SASL working groups.

> non-UTF-8 compatible fields, such as GeneralString) for host names.

It is easy to encode an ASCII hostname in UTF-8.  So easy, in fact, that 
the operation is the identity mapping.  It is only slightly harder to 
encode an internationalized host name, since the latter may be IDNA-encoded 
and thus require decoding before it can be re-encoded using a different 
encoding.  Please remember - IDNA is _an encoding of the Unicode character 
set_, just like UTF-8, thought somewhat more bizarre due to the limitations 
of the available symbol set.

Constructing a Kerberos principal name from either of these requires only 
one additional step, which is to fold the domain name to lower case.  This 
is a requirement of the Kerberos protocol when constructing host-based 
principal names from hostnames which are themselves case-insensitive; it is 
intended to insure the use of a consistent principal name, because Kerberos 
principal names are case-sensitive.

---

From: Martin Rex <[email-masked]>
Date: Wed, 8 Oct 2003 20:14:17 +0200 (MET DST)

Sorry guys, I did an author reply but failed to notice
that this was trapped by an explicit Reply-To: ietf-krb-wg

Is there a convention on addressing Emails to the mailing list?
My plain old "Elm" MUA puts ietf-krb-wg into the CC-field upon
a group reply and I always leave the Reply-To: to myself.

---

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

On Wed, Oct 08, 2003 at 06:01:34PM +0200, Simon Josefsson wrote:
> have to deal with normalization issues.

Noone is arguing for the use of unnormalize Unicode (in any encoding).
We have already stated what stringprep profile Kerberos V extensions
will use, and that takes care of the normalization issu.

Or did you mean that "use of UTF-8 on the wire is not an IDN solution?"
If so, please provide authoritative references.

>                                          It should use the ToUnicode

As Jeff points out, IDNA's ToAscii/ToUnicode transformations do more
than just normalize.

> supporting it requires a revised document.

Correct - that's one of the primary goals of Kerberos V extensions: to
produce a new Kerberos V [minor version] specification that is properly
internationalized (plus other improvements, e.g., extensibility).

Cheers,

Nico
--