headers
Sam Hartman | 1 Aug 2007 21:28
Picon
Favicon

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

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams <at> sun.com> 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
Permalink | Reply | 27 comments |
headers
Nicolas Williams | 1 Aug 2007 21:58
Picon

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

On Wed, Aug 01, 2007 at 03:28:50PM -0400, Sam Hartman wrote:
> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams <at> sun.com> 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.

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.
(Continue reading)

Permalink | Reply | 26 comments |
headers
Simon Josefsson | 2 Aug 2007 01:53
Favicon
Gravatar

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

Nicolas Williams <Nicolas.Williams <at> sun.com> writes:

> On Tue, Jul 31, 2007 at 10:29:36AM +0200, Simon Josefsson wrote:
>> Nicolas Williams <Nicolas.Williams <at> sun.com> 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
(Continue reading)

Permalink | Reply | 19 comments |
headers
Jeffrey Altman | 2 Aug 2007 02:14
Favicon
Gravatar

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

Simon Josefsson wrote:
> 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.

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.
Attachment (smime.p7s): application/x-pkcs7-signature, 3355 bytes
Permalink | Reply | 14 comments |
headers
Simon Josefsson | 2 Aug 2007 02:45
Favicon
Gravatar

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

Jeffrey Altman <jaltman <at> secure-endpoints.com> writes:

> Simon Josefsson wrote:
>> 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.
>
> 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.

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
(Continue reading)

Permalink | Reply | 13 comments |
headers
Jeffrey Altman | 2 Aug 2007 02:57
Favicon
Gravatar

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

Simon Josefsson wrote:
> 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
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.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Simon Josefsson | 2 Aug 2007 09:32
Favicon
Gravatar

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

Jeffrey Altman <jaltman <at> secure-endpoints.com> writes:

> Simon Josefsson wrote:
>> 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
> 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
(Continue reading)

Permalink | Reply | 7 comments |
headers
Nicolas Williams | 2 Aug 2007 17:48
Picon

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

On Thu, Aug 02, 2007 at 01:53:30AM +0200, Simon Josefsson wrote:
> Nicolas Williams <Nicolas.Williams <at> sun.com> writes:
> > On Tue, Jul 31, 2007 at 10:29:36AM +0200, Simon Josefsson wrote:
> >> Nicolas Williams <Nicolas.Williams <at> sun.com> 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 can't add type information to exported GSS name tokens, or at least
not easily.  Similarly for .k5login.
Permalink | Reply | 0 comments |
headers
Nicolas Williams | 2 Aug 2007 17:52
Picon

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

On Thu, Aug 02, 2007 at 01:53:30AM +0200, Simon Josefsson wrote:
> Nicolas Williams <Nicolas.Williams <at> sun.com> writes:
> >> 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

I've pointed out two.

> 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

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.
Permalink | Reply | 2 comments |
headers
Nicolas Williams | 2 Aug 2007 17:59
Picon

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

On Thu, Aug 02, 2007 at 02:45:46AM +0200, Simon Josefsson wrote:
> 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.

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.

> 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
(Continue reading)

Permalink | Reply | 3 comments |

Gmane