Subject: Re: Principal name type tagging, or lack thereof (Re: I18N answers needed now for KITTEN work)

From: Sam Hartman <[email-masked]>
Date: Wed, 01 Aug 2007 15:28:50 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> Add to this the potential for ambiguity in two-component
    Nicolas> principal name conventions, some of which are host-based
    Nicolas> names (whose second component is a domainname slot), some
    Nicolas> of which are not (these tend not to have any domainname
    Nicolas> slots)...

    Nicolas> ... add the lessons we've learned from IDNA (see the
    Nicolas> presentation on IDNAbis at last week's SAAG meeting), in
    Nicolas> particular the implication that we must loosen some of
    Nicolas> the constraints from IDNA...

I follow you up to here.

    Nicolas> ... and I think we need to seriously consider labelling
    Nicolas> all Kerberos V principal name components, and realm
    Nicolas> names, as domainname slots.

But here I completely lose you.  I don't understand what you're trying
to accomplish, why this is the right layer to accomplish it, etc.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 1 Aug 2007 14:58:32 -0500

> to accomplish, why this is the right layer to accomplish it, etc.

Let me re-phrase:  I'm proposing that we consider using "A-labels" (ACE)
in all places where today we have KerberosString.

The reason is that because we lack accurate or any principal name type
tagging we have to accept some ambiguity somewhere: either in principal
name form (NT-HST-SRV vs. something else that has not components with
domainname contents) or in ASCII vs. ACE.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 02 Aug 2007 01:53:30 +0200

Nicolas Williams <[email-masked]> writes:

> On Tue, Jul 31, 2007 at 10:29:36AM +0200, Simon Josefsson wrote:
>> Nicolas Williams <[email-masked]> writes:
>> 
>> I agree that specifying the type, or at least knowing the type of a
>> string, is the first step towards any usable I18N solution.
>
> But we can't add type information everywhere (we can have correct ASN.1
> type tags on the wire, but that's not the issue!).

If the i18n capability is negotiated between the two sides (and this
appears to be the assumption), we can add type information.  I'm not
suggesting this is a good idea, but it is one out of very few
possibilities.

>> > We lose little from doing so, and gain much (e.g., Unicode version
>> > agnosticism).
>> 
>> If we use ACE encoded IDN's ("IDN-unaware domain name slot"), I believe
>> we are stuck with some particular version of Unicode.  If we use UTF-8,
>> the above holds.
>
> I recommend that you listen to the recording of the IDNAbis presentation
> at SAAG last week.

I have listened to it.

>> I strongly believe that Punycode-encoded strings should be avoided in
>> I18N solutions outside of the DNS-space.  In Kerberos we control the
>> client and servers, and can have them negotiate this.
>
> You might reconsider if you saw that presentation.

I didn't find much in the way of argumentation, mostly an assertion that
"do use ACE encoding in your protocols (but there are exceptions)".

>> > But more importantly, choosing to treat most every instance of
>> > GeneralString in RFC4120 as a domainname slot will probably make
>> > Kerberos V I18N simpler to implement.
>> 
>> Yes.  The only alternative is to specify exactly which strings are
>> domain name slots and which are not.  That may be tricky and ugly.
>
> My point is that we can't avoid ambiguity.  We'll have to accept some
> amount of ambiguity somewhere, and I think I'd rather accept ACE vs.
> valid non-ACE ASCII.

There are potentially more than one ambiguity here.  Are you referring
to the one where we have domainname matching 'xn--.*' without being
meant to be a ACE encoded non-ASCII domainname?  I think that ambiguity
have little practical impact.  Still, if we negotiate all string types
to be UTF-8 fields, it seems this ambiguity goes away.  Alternatively,
part of the i18n negotiation could be a flag to tell whether the ASCII
string is meant to be interpreted as ASCII or ACE.

/Simon

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 01 Aug 2007 20:14:04 -0400

> suggesting this is a good idea, but it is one out of very few

I think that Nico's point is that we don't have tagging in all of
the application facing interfaces such as configuration files,
command line input, etc. in order to know what the user/admin is
expecting.  As a result, we must simply accept ACE-encoding as
the encoding of printable Kerberos Strings.

A Kerberos service principal can and often is used as a client
principal.  So there really isn't any distinction that can be
made based upon the principal type or the usage.

There are too many places where a principal name comes without tagging.
Unless we are willing to redesign all of the APIs and not permit
backward compatibility, we may not have a choice but to treat
KerberosString as ACE-encoded.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 02 Aug 2007 02:45:46 +0200

> KerberosString as ACE-encoded.

Oh, I see, thanks for explaining.

Although I still disagree: For unknown domainname slots, Kerberos
implementation could invoke ToUnicode on the string, and use that before
sending it over the wire in the Kerberos protocol.

This approach will avoid the use of ACE over the wire in a protocol that
can support UTF-8, which I believe is a good idea.  I don't see any
disadvantage in doing things this way; I don't see how you could avoid
the call to ToUnicode/ToASCII in any solution.

I would admit that the decision to use either

 1) Invoke ToASCII on domainname slots and send the ACE encoded
 domainname over the wire in the Kerberos protocol, or

 2) Invoke ToUnicode on domainname slots and send the UTF-8 encoded
 domainname over the wire in the Kerberos protocol

is a subjective decision.  My preference is for 2) though, unless
someone can better explain why that costs associated with that are
larger than 1).  (Or if there is a flaw in the categorization above.)

/Simon

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 01 Aug 2007 20:57:46 -0400

> larger than 1).  (Or if there is a flaw in the categorization above.)
But then what do you do about authenticating to a service on a host when
the only thing you know about the host is the ACE-encoding of its DNS
name?    The problem is that the source of the string may be the output
of another protocol exchange such that you only have ACE. 

I can't describe an actual scenario at the moment but I do remember
thinking about this years ago in some of the discussions surrounding
internationalized e-mail messages.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 02 Aug 2007 09:32:23 +0200

> of another protocol exchange such that you only have ACE. 

Run ToUnicode on all input string?

If the input is a UTF-8 I18n string, the it is processed according to
the IDNA rules, which is necessary for input directly from the user.
For example, 'räksmörgås' remains as-is, and 'josefßon' is translated
into 'josefsson' (that is how IDNA works today).

Any ACE encoded strings are decoded into UTF-8.  For example,
'rksmrgs-5wao1o' is decoded into 'räksmörgås'

The resulting UTF-8 string is sent over the wire.

> internationalized e-mail messages.

I think it is a realistic scenario.  It helps to consider that the
following should work:

telnet räksmörgås.josefsson.org
telnet rksmrgs-5wao1o.josefsson.org

If you want to consider GSS-API interactions, consider:

ssh räksmörgås.josefsson.org
ssh rksmrgs-5wao1o.josefsson.org

Web browsers with i18n support typically accept both input formats, and
translate them into the Unicode format on the screen.  That appears to
be give the best user experience.

I don't think you can get away with either running ToASCII or ToUnicode
in the Kerberos library in practice, unfortunately, since in practice
applications can't be bothered to do this processing on their own.  And
further, since Kerberos will reference a particular version of IDNA, it
has to make sure that the strings are processed according to those IDNA
rules and not some other rules.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Aug 2007 10:48:32 -0500

> suggesting this is a good idea, but it is one out of very few

We can't add type information to exported GSS name tokens, or at least
not easily.  Similarly for .k5login.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Aug 2007 10:52:18 -0500

> There are potentially more than one ambiguity here.  Are you referring

I've pointed out two.

> have little practical impact.  Still, if we negotiate all string types

Right.

The other ambiguity is two-component principal names (and three, once we
get domain-based names) -- is the second component a domainname slot?
Depends on the type of the principal name.  But you may not have that
information.  So you say "if the first component is one from the GSS
service name registry then the second must be a domainname slot, else,
not."  But that's not realistically enough -- it complicates things for
customers who don't register their service names.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Aug 2007 10:59:47 -0500

> the call to ToUnicode/ToASCII in any solution.

Sure, that works, as long as all entities in the protocol use octet-wise
comparison except: administration points (they have to apply policies
w.r.t. new principal and realm names) and clients (they need to be aware
of the code points in the UTF8Strings in order to be able to display
them properly.  And what of servers?  As long as they do nothing
terribly interesting with the strings, no problem.  Else you run into
the Unicode version problem described in the IDNAbis presentation.

It's the Unicode version problem that motivates me proposing ACE here:
Unicode versions will matter only where entities have to call
toUnicode() and then do something with that Unicode.

> larger than 1).  (Or if there is a flaw in the categorization above.)

The first order issue is determining what is a domainname slot, and that
is hard because of the ambiguities described.

If we punt on that then we have to decide whether to apply toASCII() or
toUnicode() to all KerberosString protocol elements.

Nico
--

---

From: Chaskiel M Grundman <[email-masked]>
Date: Thu, 02 Aug 2007 12:23:53 -0400

--On Thursday, August 02, 2007 10:59:47 AM -0500 Nicolas Williams 
<[email-masked]> wrote:

> Else you run into

How does this save you from the unicode version problem? The user could 
hand you a utf-8 string instead of a punycode string. if your unicode 
version is different than the user's, you might end up having to reject the 
string. How is this different from a system that uses utf8 everywhere?

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Aug 2007 11:25:13 -0500

> Run ToUnicode on all input string?

If we'd do that we might as well run toASCII() on all of them as well.

I think your point is that toASCII() is a lot more restrictive of its
Unicode inputs than toUnicode() is of its input, thus we should prefer
toUnicode(), and since we're going to be negotiating newness vs.
oldness, we get no real benefit from choosing toASCII() instead of
toUnicode().  Is that right?

[...]
> applications can't be bothered to do this processing on their own.

I don't understand this inference.  I think it's quite reasonable to
expect updated krb5 implementations to apply toASCII() and/or
toUnicode() as we specify it.

>                                                                     And

Well, I would be happy to live with the restrictions of IDNAbis.  As for
the ones in IDNA2003, we have already chosen to live with similar
restrictions in SASLprep.  If IDNAbis is adopted and we adopt it
(directly or indirectly) and drop SASLprep then we'll be doing Kerberos
users a big favor.

Nico
--

---

From: Chaskiel M Grundman <[email-masked]>
Date: Thu, 02 Aug 2007 12:36:12 -0400

> toUnicode() as we specify it.

I believe the point that Simon is making is that, because applications may 
use either A-labels or U-labels in names passed to kerberos/gss functions 
rather than being consistent about it (you have asserted this yourself), 
then no matter what we decide here, the library implementations are going 
to have to invoke either ToAscii or ToUnicode on those names in order to 
get something consistent.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Aug 2007 11:43:14 -0500

> rather than being consistent about it (you have asserted this yourself), 

I hadn't so asserted (I think Jeff did), though I agree.

> get something consistent.

I agree with this too, but it is the opposite of what Simon wrote.

Or perhaps Simon meant that we can't use just one of ToASCII() or
ToUnicode() in the krb5 libraries, that in some cases the libraries will
have to use _both_?

---

From: Chaskiel M Grundman <[email-masked]>
Date: Thu, 02 Aug 2007 12:57:25 -0400

> I agree with this too, but it is the opposite of what Simon wrote.

you are right. I somehow read "with" as "without".

---

From: Sam Hartman <[email-masked]>
Date: Thu, 02 Aug 2007 13:15:20 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Wed, Aug 01, 2007 at 03:28:50PM -0400, Sam Hartman
    >>  But here I completely lose you.  I don't understand what
    >> you're trying to accomplish, why this is the right layer to
    >> accomplish it, etc.

    Nicolas> Let me re-phrase: I'm proposing that we consider using
    Nicolas> "A-labels" (ACE) in all places where today we have
    Nicolas> KerberosString.

OK, that seems really bad for a number of reasons:

*  doing so would basically forbid . (U+0x2e) in principal names; this is a bug in how you said what you want to do.

* This would be incompatible with what every deployed implementation is doing for usernames and passwords today.  I don't see why any implementer would want to go along with this.

* The constraints on IDNA are very likely not appropriate constraints
  for Kerberos usernames.  In particular, take a look at the
  descriptions of DNS constraints in RFC 4690 and the IDNAbis effort
  and note that few of them apply to principal names.

I think your proposal is motivated by the belief that we must identify
domain name slots over the wire.  I.E. I must be able to look at a
principal and determine if something in it is a hostname.  I don't
think that's actually true.  I do think we should use the output of
toascii when adding a hostname to a principal.  Similiraly, I think
there are certain things in the Kerberos protocol that do happen to be
domain name slots.  However I see no requirement that anyone other
than the party constructing a principal be able to tell whether
something is a hostname.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Aug 2007 12:30:33 -0500

On Thu, Aug 02, 2007 at 01:15:20PM -0400, Sam Hartman wrote:
> *  doing so would basically forbid . (U+0x2e) in principal names; this
> is a bug in how you said what you want to do.

If it's a bug in how I stated what I wanted then you can workaround it.

You can represent '.' in ACE-encoded strings: ASCII periods appear
unencoded as separators of ACE-encoded sub-strings.  And that just how
ACE-encoded domainnames would be displayed when the Unicode form cannot
be (e.g., because the user wants to see ACE).

> * This would be incompatible with what every deployed implementation
> is doing for usernames and passwords today.  I don't see why any
> implementer would want to go along with this.

I don't think so.

For one, I said nothing about passwords.

But more importantly I also didn't say that I don't want to negotiate
old vs. new behaviour, so whether we use toASCII() or toUnicode() output
on the wire in the I18Ned krb5 should not impact interop with legacy
deployments of RFC1510/4120.

Quite the contrary, I still want I18N negotiation.

>   and note that few of them apply to principal names.

I'll admit that I've not read the IDNAbis proposal in detail.  The
impression that I got from the presentation at SAAG is that the
constraints of IDNAbis will be much looser than SASLprep's (e.g., the
example given during the talk about zero-width joiner).

> domain name slots over the wire.  I.E. I must be able to look at a

That's part of it, and if that were all I'd stop at wanting every
KerberosString in the protocol to be a domainname slot and the output of
either toASCII() or toUnicode(), without any preference on my part, or
perhaps I'd prefer toUnicode() output.  Note: the same bug appears here
as you mentioned above; work around it please :)

---

From: Sam Hartman <[email-masked]>
Date: Thu, 02 Aug 2007 13:52:54 -0400

>> * This would be incompatible with what every deployed
    >> implementation is doing for usernames and passwords today.  I
    >> don't see why any implementer would want to go along with this.

    Nicolas> I don't think so.

    Nicolas> For one, I said nothing about passwords.

    Nicolas> But more importantly I also didn't say that I don't want
    Nicolas> to negotiate old vs. new behaviour, so whether we use

The issue is that the FAST proposal is much easier for both Microsoft
and MIT to implement than what you propose here.  Microsoft basically
just has to normalize and for example deployments of MIT that are
using Unicode just have to normalize.

What you propose involves everyone taking the hit for basically no
gain.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Aug 2007 13:01:37 -0500

> What you propose involves everyone taking the hit for basically no

Neither do the earlier proposals necessarily align us with IDNA or
IDNAbis, and we must do that for at least domainname slots in the
protocol.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Aug 2007 13:06:16 -0500

> IDNAbis, and we must do that for at least domainname slots in the

I suppose the easy way out is to say that what is a domainname slot
depends on the applications' context.  And we can even pass the buk in
the case of the GSS mechanism.  This is what the resolver does in the
IDNA world, after all.  I suspect that will turn out to be a
dissatisfier, but it's no less acceptable than the resolver leaving IDNA
to the application, I suppose.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 02 Aug 2007 21:18:32 +0200

> customers who don't register their service names.

Right.  So you are proposing to treat all the principal strings as
domainname slots?  That would be incorrect for some situations, like
admin/kadmin principals, but I do not see any harm caused by this.  So I
think it is a good idea.

This is orthogonal to which encoding is used on the wire, though.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 02 Aug 2007 21:30:05 +0200

> toUnicode() and then do something with that Unicode.

How are you avoiding the Unicode version problem?  There is no way to
avoid that problem as far as I see, except possibly to send whatever the
user types to the server, and let the server figure out things.  But so
far nobody has proposed that, it seems the proposals are to send ToASCII
output or ToUnicode output.

New versions of Unicode/IDNA may introduce new code points (this is done
in IDNAbis, by going from Unicode 3.2 to Unicode 5.0), and may modify
the output for some input strings (IDNAbis ToUnicode allegedly believes
that ß should remain ß, the currently deployed IDNA ToUnicode translates
ß into 'ss').

You can't predict the changes made by future IDNA releases.

> is hard because of the ambiguities described.

Right, although the idea of just treating all KerberosStrings as
(idn-aware) domainname slots is one approach.

> toUnicode() to all KerberosString protocol elements.

I think we always will need to decide if and whether to use
ToSACII/ToUnicode.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Aug 2007 14:32:49 -0500

> domainname slots?  That would be incorrect for some situations, like

It would be incorrect if too constraining...

> admin/kadmin principals, but I do not see any harm caused by this.  So I

...I suspect it would not be so constraining as to cause harm, so we
agree.

> This is orthogonal to which encoding is used on the wire, though.

Mostly, I think.

I think though that Sam prefers kicking the domainname slot can to the
apps.  It's useful if you're just providing a krb5 library, and it will
do, I think (though I have to think through various scenarios).  But
krb5 libraries are as difficult to update ahead of apps as DNS
resolvers.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Aug 2007 14:35:59 -0500

> output or ToUnicode output.

IDNAbis purports to get us Unicode version agnosticism: the only places
where Unicode versions matter in IDNAbis are the clients and
administrative interfaces.

> (idn-aware) domainname slots is one approach.

The only other approaches are: heuristics, or kicking the can to the
apps.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 02 Aug 2007 21:41:19 +0200

> If we'd do that we might as well run toASCII() on all of them as well.

ToUnicode runs ToASCII internally, but I'm not sure that's your point?

My reason for running ToUnicode is that I always want UTF-8 encoding of
non-ASCII domainnames on the wire.  If we don't use ToUnicode, we'll
have a mix of UTF-8 and ACE and ASCII over the wire.

> Unicode inputs than toUnicode() is of its input

That is incorrect.  Both functions accept and reject exactly the same
strings.  The difference is that ToUnicode outputs Unicode code points
whereas ToASCII outputs ASCII code points.

> thus we should prefer toUnicode(), and since we're going to be
> negotiating newness vs.  oldness, we get no real benefit from choosing
> toASCII() instead of toUnicode().  Is that right?

My point is that I prefer UTF-8 over the wire.  I don't want ACE
encoding, since I don't see what that gains us.  Using ToUnicode is the
aim to achieve that goal.

> toUnicode() as we specify it.

Yes, my point was that things would be simpler (implementation wise) if
updated krb5 implementation didn't have to run ToASCII/ToUnicode.  But
that would result in a non-working solution, hence the conclusions is
that updated implementations need to invoke ToASCII/ToUnicode.

> (directly or indirectly) and drop SASLprep then we'll be doing Kerberos

That would be a nice, but I think it is unrealistic to wait that long.
We should, and can, solve the i18n problem in Kerberos before IDNAbis
comes out.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 02 Aug 2007 21:44:37 +0200

Chaskiel M Grundman <[email-masked]> writes:

> I believe the point that Simon is making is that, because applications
> may use either A-labels or U-labels in names passed to kerberos/gss
> functions rather than being consistent about it (you have asserted
> this yourself), then no matter what we decide here, the library
> implementations are going to have to invoke either ToAscii or
> ToUnicode on those names in order to get something consistent.

Exactly!

My preference in that (subjective) choice would be ToUnicode.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 02 Aug 2007 21:46:18 +0200

> you are right. I somehow read "with" as "without".

Upon re-reading that, it was a typo.  I meant 'without'.  Sorry for the
confusion.

/Simon

---

From: Sam Hartman <[email-masked]>
Date: Thu, 02 Aug 2007 17:50:01 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Thu, Aug 02, 2007 at 01:01:37PM -0500, Nicolas
    Nicolas> Williams wrote:
    >> On Thu, Aug 02, 2007 at 01:52:54PM -0400, Sam Hartman wrote: >
    >> The issue is that the FAST proposal is much easier for both
    >> Microsoft > and MIT to implement than what you propose here.
    >> Microsoft basically > just has to normalize and for example
    >> deployments of MIT that are > using Unicode just have to
    >> normalize.
    >> > 
    >> > What you propose involves everyone taking the hit for
    >> basically no > gain.
    >> 
    >> Neither do the earlier proposals necessarily align us with IDNA
    >> or IDNAbis, and we must do that for at least domainname slots
    >> in the protocol.

    Nicolas> I suppose the easy way out is to say that what is a
    Nicolas> domainname slot depends on the applications' context.
    Nicolas> And we can even pass the buk in the case of the GSS
    Nicolas> mechanism.  

Exactly.

The hostname in name types that have a hostname is a domain name slot
as far as sname_to_principal and gss_import_name are concerned.
But ultimately the application needs to know what is a domain name.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Aug 2007 16:57:46 -0500

> But ultimately the application needs to know what is a domain name.

I must say I'm not entirely happy about this, and I'm not sure that it
really simplifies anything for implementors unless we also pass the buck
to the GSS apps (even though there name type information is generally
available for GSS_Import_name()).

If we decide to pass the buck to GSS apps then that will be something
that has to be decided in the KITTEN WG, not just the KRB WG.  If we
don't pass the buck to GSS apps then why pass it to krb5 apps?  After
all, krb5 implementors are usually GSS-API implementors also, and once
we decide that the GSS mechs deal with calling toASCII() and/or
toUnicode() then the rest of the krb5 implementation can as well.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 02 Aug 2007 19:05:13 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> I must say I'm not entirely happy about this, and I'm not
    Nicolas> sure that it really simplifies anything for implementors
    Nicolas> unless we also pass the buck to the GSS apps (even though
    Nicolas> there name type information is generally available for
    Nicolas> GSS_Import_name()).

We're saying the client needs to deal, not the KDC.  Making it a
application problem allows us to simplify things and use one strategy
for usernames and another strategy for hostnames.  That is what makes
it simpler.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Aug 2007 18:13:17 -0500

> We're saying the client needs to deal, not the KDC.  Making it a

No aregument there -- the only thing related to the KDC that needs to
know about IDNA is the administrative interfaces (e.g., kadmind).

---

From: Martin Rex <[email-masked]>
Date: Fri, 3 Aug 2007 17:44:39 +0200 (MEST)

> toUnicode() then the rest of the krb5 implementation can as well.

GSS-API has a concept of a "canonicalized" name.  An application
that uses hostbased service names may still know that there is
a hostname involved, but only as long as the name is represented
as a hostbased service name.

Once the hostbased service name is visualized or used as a printable
canonical name (e.g. a Kerberos principal name), then the knowledge
about which part of the name may represent domain name slots becomes
invisible to the app.

And then there are gssapi mechanisms (SPKM-like) that do not use/provide
gssapi hostbased service at all.

We have always been recommending to all of our kerberos-using customers
to configure all names as kerberos principal names, and avoid the
use of hostbased service names (our application never asserts
a target name from the network addrress), because of the potential
confusion and security vulnerability that comes with an implementation
of hostbased service names as suggested by rfc-2743 and as implemented
by MIT Kerberos 5 (performing hostname canonicalization through
insecure DNS lookups).

-Martin

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 6 Aug 2007 11:16:55 -0400 (EDT)

On Thu, 2 Aug 2007, Sam Hartman wrote:

If we do this...

> I do think we should use the output of
> toascii when adding a hostname to a principal.

... then I think I agree with this...

> However I see no requirement that anyone other

However, I would be interested in hearing what Kerberos protocol elements
are domain name slots, as opposed to places that we sometimes put domain
names and sometimes don't and can't always tell the difference.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 6 Aug 2007 10:26:53 -0500

> names and sometimes don't and can't always tell the difference.

Sam's point is that applications know that, therefore we wouldn't call
out any specific Kerberos V protocol elements as domainname slots, but
application protocols that use Kerberos V would use label some of their
uses of some Kerberos V protocol elements as domainname slots.

I.e., extend the treatment of resolvers (apps have to apply IDNA, not
resolvers) to Kerberos V.

It can work.  I'm not sure it helps Kerberos V implementors because the
Kerberos V GSS-API mechanism is an application from this p.o.v., so krb5
implementors (who nearly always also implement the mech, as well as
several krb5 and/or gss apps) will have to implement or depend on an
implementation of IDNA unless...

...unless we push IDNA to GSS apps too -- but that is not what we
discussed at the KITTEN meeting.

This is one protocol where we could apply IDNA to all name strings in
the protocol, and therefore in the krb5 equivalent of the resolver (the
krb5 libraries).  For applications this might not be as great a
simplification as I'd like to think: apps already have to be IDNA-aware
anyways and that requirement won't go away.  It wouldn't be much of a
simplification for krb5 lib implementors either (though it wouldn't
complicate things either -- see above).  But it would be a protocol
simplification (I18N for all name-like fields in the protocol in one
shot).

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 6 Aug 2007 11:33:58 -0400 (EDT)

> toUnicode() then the rest of the krb5 implementation can as well.

Unlike Kerberos, the GSS-API has enough typing information in its
application-facing interfaces for the GSS implementation to do the right
thing.  The host and domain names in GSS_C_NT_HOSTBASED_SERVICE and
GSS_C_NT_DOMAINBASED_SERVICE names are clearly domain name slots, and
those parts of the names should be encoded appropriately by the mechanism.
Yes; that means that existing RFC4120 implementations won't work with IDN
names, but what did you expect?  On the other hand, one the mechanism is
updated, they _will_ work with unmodifed applications, at least to the
extent permitted by the Latin1-using interfaces defined in RFC2744.

Names with the other types defined in RFC2743 clearly are not domain name
slots.  And as for GSS_KRB5_NT_PRINCIPAL_NAME, GSS applications that use
it effectively _are_ Kerberos applications, to the extent that they
knowingly construct mechanism-specifiic Kerberos principal names -- such
names must be constructed correctly, either by the application or by the
user, as appropriate.

So I think it is quite reasonable for an RFC4120 implementation,
as a Kerberos application, to deal with this issue -- even if the GSS-API
does _not_ make it the problem of the GSS-API application.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 6 Aug 2007 11:36:48 -0400 (EDT)

On Mon, 6 Aug 2007, Nicolas Williams wrote:

> Sam's point is that applications know that

I think Sam was suggesting that there are protocol elements which are
_clearly_ domain name slots; presumably those are other than principal
name components.  I want to know what they are.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 6 Aug 2007 10:40:31 -0500

On Mon, Aug 06, 2007 at 11:33:58AM -0400, Jeffrey Hutzelman wrote:
> thing.

Most of the time :)

>         The host and domain names in GSS_C_NT_HOSTBASED_SERVICE and

This may be an argument for pushing IDNA to the GSS apps too.  I don't
like it, but I don't have to like it :/

> does _not_ make it the problem of the GSS-API application.

Did you mean RFC4121?

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 6 Aug 2007 10:41:14 -0500

> name components.  I want to know what they are.

Realm names, transited field...

---

From: Sam Hartman <[email-masked]>
Date: Mon, 06 Aug 2007 13:17:00 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> On Mon, 6 Aug 2007, Nicolas Williams wrote:
    >> > > I do think we should use the output of > > toascii when
    >> adding a hostname to a principal.
    >> >
    >> > > However I see no requirement that anyone other > > than the
    >> party constructing a principal be able to tell whether > >
    >> something is a hostname.
    >> >
    >> > However, I would be interested in hearing what Kerberos
    >> protocol elements > are domain name slots, as opposed to places
    >> that we sometimes put domain > names and sometimes don't and
    >> can't always tell the difference.
    >> 

    Jeffrey> I think Sam was suggesting that there are protocol
    Jeffrey> elements which are _clearly_ domain name slots;
    Jeffrey> presumably those are other than principal name
    Jeffrey> components.  I want to know what they are.

There are classes of principal name (certain name types) where certain
principal components are domain name slots.

There are inputs in certain krb5 APIs that clearly are domain name
slots.

We could decide that domain based realms are domain name slots,
although I think we decided that they were not and that we didn't want
ACE for realm names.

---

From: Martin Rex <[email-masked]>
Date: Tue, 7 Aug 2007 15:09:23 +0200 (MEST)

> names must be constructed correctly, either by the application or by the

There seems to be significant confusion about GSS_KRB5_NT_PRINCIPAL_NAME.
Few, if any, applications will "compose" GSS_KRB5_NT_PRINCIPAL_NAMEs.
Applications are strongly recommneded to consider the printable
names opaque blobs that are NOT to be parsed or composed in any
fashion.

Normally, these names are supplied by human users or admins, or they
are the result of visualizing the owner of a credential or the
peer of a security context via "gss_display_name()".

If an application (which often doesn't know or care which particular
gssapi mechanism is used) does not supply a nametype when calling
gss_import_name() for a Kerberos 5 gssapi mechanism, then the supplied
printable name will be interpreted as the mechanism-default native
nametype, which for Kerberos 5 is GSS_KRB5_NT_PRINCIPAL_NAME.

The reason for this is that there are NO generic nametypes that will
work for a significant fraction of gssapi mechanisms, and requiring
users to supply nametype oids when entering names would create
a significant usability problem.  So we (in CAT) chose to specify
that the mechanism native nametype should be implied whenever
a printable name with a NULL nametype OID is passed to gss_import_name().

This should be the same nametype/format/semantics as for the
administrative user management interfaces of the gssapi mechanism.

-Martin

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 7 Aug 2007 11:02:00 -0400 (EDT)

> There seems to be significant confusion about GSS_KRB5_NT_PRINCIPAL_NAME.

Maybe, but not on my part.

> peer of a security context via "gss_display_name()".

A name supplied by a human user or admin was not constructed by the
application; it was constructed by the human, who then bears the
responsibility of making sure that it is the right name.  If we choose to
adopt the rule that domain names are processed as per IDNA when used to
construct Kerberos principal names, then the "right name" is the result of
such processing.

A printable name produced by GSS_Display_name has syntax which is "a local
matter" (RFC2743 2.4.4); it is not suitable as input to GSS_Import_name.

> nametype

True.

> which for Kerberos 5 is GSS_KRB5_NT_PRINCIPAL_NAME.

Says you.  I find nothing in RFC1964 which says this.

But none of this matters.  The important thing here is that the Kerberos
GSS-API mechanism can assume that suppliers of Kerberos principal names
are responsible for using the correct principal name, which in turn means
that Kerberos can require applications -- even the Kerberos GSS-API
mechanism -- to supply correct principal names.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 7 Aug 2007 10:25:17 -0500

> mechanism -- to supply correct principal names.

Emphasis throughout on 'can'.

Assuming that IDNAbis' constraints on Unicode strings that can be used
are sufficiently loose for our purposes we could also conclude that
Kerberos can be responsible for calling toASCII() and toUnicode().

I think the rationale for leaving IDNA to DNS apps is not necessarily
applicable with the same force to Kerberos.

So let's settle that: just how far should we follow the IDNA model of
leaving it to the applications to deal with domainname slots?

---

From: Sam Hartman <[email-masked]>
Date: Tue, 07 Aug 2007 12:04:16 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Tue, Aug 07, 2007 at 11:02:00AM -0400, Jeffrey
    Nicolas> Hutzelman wrote:
    >> But none of this matters.  The important thing here is that the
    >> Kerberos GSS-API mechanism can assume that suppliers of
    >> Kerberos principal names are responsible for using the correct
    >> principal name, which in turn means that Kerberos can require
    >> applications -- even the Kerberos GSS-API mechanism -- to
    >> supply correct principal names.

    Nicolas> Emphasis throughout on 'can'.

    Nicolas> Assuming that IDNAbis' constraints on Unicode strings
    Nicolas> that can be used are sufficiently loose for our purposes
    Nicolas> we could also conclude that Kerberos can be responsible
    Nicolas> for calling toASCII() and toUnicode().

    Nicolas> I think the rationale for leaving IDNA to DNS apps is not
    Nicolas> necessarily applicable with the same force to Kerberos.

    Nicolas> So let's settle that: just how far should we follow the
    Nicolas> IDNA model of leaving it to the applications to deal with
    Nicolas> domainname slots?

I can't parse this message at all.

In particular, in the model I'm proposing, Kerberos ends up calling
toascii most of the time, although it does it in gss_import_name and
krb5_sname_to_principal.

You seem to be proposing something different, but I can't tell what,
or even why you'd want something different in an ideal world.

--Sam

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 07 Aug 2007 12:42:03 -0400

> toascii most of the time, although it does it in gss_import_name and

Those aren't part of Kerberos. :-)

---

From: Martin Rex <[email-masked]>
Date: Tue, 7 Aug 2007 20:57:20 +0200 (MEST)

> construct Kerberos principal names, then the "right name" is the result of

It may be not as easy.  The "native UIs" for your preferred gssapi
mechanism may be "feature enhanced", so that the user or admin does
not know what transformations to apply "manually" in order to come
up with a representation suitable for use with GSS-API calls.

Example: Microsoft Kerberos.  The UIs of the Active Directory
use the lower-case DNS name throughout when visualizing
account names.  At the SSPI-level, however, the majority of calls
uses the upper-case Kerberos REALM name.  And the supportive
SSPI-calls are either seriously broken (like TranslateName) or
missing in order to convert from the names as visualized at
Microsoft's UIs into the protocol-level representation as used
by the native Kerberos protocol.  That is a serious usability issue.

> matter" (RFC2743 2.4.4);

According to rfc2743 2.4.4 the syntax of the printable form is a local
matter--for mechanism that standardize name formats, such as Kerberos 5,
it is a mechanism-specific, not implementation specific matter.

>
> it is not suitable as input to GSS_Import_name.

The inference that the output of gss_display_name is _not_ suitable
as input to gss_import_name() is entirely unjustified.
RFC-2743 certainly does NOT say this.

The reason why gss_display_name() provides a nametype OID output
parameter is precisely that it can be fed back into gss_import_name()
without creating an ambiguity about the syntax of the name.

What you can not rely on, however, is that the re-importing of a
displayed MN will again result in an MN--in general, you have
to use gss_canonicalize_name() in order to be sure that an
imported printable name is transformed into an MN.

> Says you.  I find nothing in RFC1964 which says this.

Not me -- rfc 2743 2.4.5 requires this.

> mechanism -- to supply correct principal names.

Nope, I violently disagree.  A GSS-API based application that supplies
a GSS_KRB5_NT_PRINCIPAL_NAME must be assumed to _NOT_ know about
the internal syntax of the name.

The meta-knowledge that part of a name reprents a hostname or a
service name only applies to hostbased service names (and domain based
service names).  And the installed base of gssapi applications is
probably entirely unaware of IDNA.  Although I've heard people talking
about IDNA-aware code, I have personally never seen nor written
such code myself.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 7 Aug 2007 14:39:52 -0500

> about IDNA-aware code, I have personally never seen nor written

This was true in general for all applications and resolvers prior to the
advent of IDNA (duh, of course).  IDNA puts the responsibility for
implementing IDNA on the applications.

We could do the same for domainnames in GSS-API API elements and
Kerberos V protocol elements.  I think that's what Sam wants.  I think
it's workable.  I think we're in a position where might be able to do
better because we don't have ubiquitous, unupgradeable implementations
of key components of the GSS/Kerberos/apps stack.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 13 Aug 2007 16:21:07 -0400

In the interests of attempting to build a consensus I'd like to state
my agreement with Jeff Hutzelman's interpretation of GSS-API rather
than Martin's in this matter.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Mon, 13 Aug 2007 16:23:11 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Tue, Aug 07, 2007 at 08:57:20PM +0200, Martin Rex
    Nicolas> wrote:
    >> service name only applies to hostbased service names (and
    >> domain based service names).  And the installed base of gssapi
    >> applications is probably entirely unaware of IDNA.  Although
    >> I've heard people talking about IDNA-aware code, I have
    >> personally never seen nor written such code myself.

    Nicolas> This was true in general for all applications and
    Nicolas> resolvers prior to the advent of IDNA (duh, of course).
    Nicolas> IDNA puts the responsibility for implementing IDNA on the
    Nicolas> applications.

    Nicolas> We could do the same for domainnames in GSS-API API
    Nicolas> elements and Kerberos V protocol elements.  I think
    Nicolas> that's what Sam wants.  

I am not at all sure that putting this responsibility on the applications is what I've described.

I certainly think there are cases wher what I've described involves
making things be application responsibility.

--Sam