Subject: I18N answers needed now for KITTEN work

From: Nico <[email-masked]>
Date: Thu, 26 Jul 2007 11:33:24 -0500

Hello KRB WG,

Many of you attended the KITTEN WG meeting at IETF69 or listened to the
audio and/or followed the jabber room yesterday and so already know that
this e-mail was coming and what it would say.

The KITTEN WG has a work item to define "domain-based service names,"
which are similar to "host-based service names."  This is a new name
type for the GSS-API and will have mappings onto GSS mechanism naming,
particularly for the Kerberos V mechanism.

This new name type comes well after IDNA, and given that this name type
involves what might be new domainname slots in GSS mechanisms, the IESG
requested that we properly address the resulting IDN issues.

The relevant I-Ds are:

 - draft-ietf-kitten-gssapi-domain-based-names-03.txt
 - draft-ietf-kitten-krb5-gssapi-domain-based-names-03.txt

At yesterday's KITTEN WG meeting we decided to:

 - treat domain names in domain-based service names as domainname slots
 - treat host names in domain-based service names as domainname slots
 - treat service names in domain-based service names as not d-n slots

This means that the mapping of domain-based service names onto Kerberos
V principal names must do something about non-ASCII labels and IDNA ACE
labels.  We cannot simply say "non-ASCII labels are not supported by the
Kerberos V mechanism."  Saying "neither non-ASCII nor ACE labels are
supported by the Kerberos V mechanism" seems like asking for a lot of
trouble (since no Kerberos V implementation disallows use of ACE in
labels).

This is all further complicated by the fact that declaring the second
component of NT-SRV-HST principal names to be domainname slots may be
insufficient given that in Kerberos V type-tagging of principal names
is, effectively, optional (when NT-UNKNOWN is used then the result would
be ambiguity w.r.t. to other two-component names that are not service
names with a host instance).

In other words, we have run into a Kerberos V I18N issue at the KITTEN
WG that we cannot resolve without KRB WG help.

Please help us figure out what to do about the mapping of domain-based
service names to Kerberos V principal names.  Thank you,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 30 Jul 2007 13:05:05 -0500

There are several places where Kerberos V principal names are used
without reference to principal name types:

 - in the Kerberos V protocol when NT-UNKNOWN is used

 - in the Kerberos V GSS-API mechanism's exported name token

 - in the Kerberos V GSS-API mechanism's GSS_KRB5_NT_PRINCIPAL_NAME name
   type (and all uses of it as inputs to GSS_Import_name())

 - in things like .k5login

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

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

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

We lose little from doing so, and gain much (e.g., Unicode version
agnosticism).

We'll probably want to include Unicode (UTF8String) and/or just-8 (OCTET
STRING) aliases (in Ticket, in EncKDCRepPart*).

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, this would mean accepting an ambiguity with respect to existing
names that look like ACEs but aren't.  Given that we've accepted this
ambiguity in the domainname system I think we might as well do the same
in Kerberos V.

[*]  I don't include Authenticator because I'm unsure as to the purpose
     of having cname/crealm in the Authenticator at all given that
     Ticket doesn't have anything like subjectAltNames.  ISTM that
     showing that the client knows the Ticket's session key is much more
     important than showing that the client knows its name according to
     the Ticket -- in fact, the latter is probably too constraining,
     unless we want to add a notion of subjectAltNames.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Mon, 30 Jul 2007 22:19:14 +0200 (MEST)

>      unless we want to add a notion of subjectAltNames.

I'm not a Kerberos protocol wrangler, so that description pops up
a question in my head (for which I don't know the answer):

  How is the client going to perform mutual authentication if it
  does not verify the server's name on ticket/authenticator?

  If I'm an attacker with control over one service C in the REALM
  and want to get hold of some confidential information that client A
  is going to send to a specific server B.  With Kerberos authentication
  integrated into HTTP clients and HTML integrated into Email, it
  is usually trivial to coerce a user into a TGS_REQ/TGS_REP for
  a service C plus an AP_REQ/AP_REP with that service C.

  How does the client A prevent that attacker replaces the TGS_REP for B
  with the TGS_REP for C (captured from the network during the coerced
  connect to C) and intercepts and processes the clients
  communication with B using the ticket for C (without noticing
  if it doesn't verify the principal name of the server it is talking to.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 30 Jul 2007 15:29:47 -0500

>   does not verify the server's name on ticket/authenticator?

I was referring to the cname/crealm -- different problem.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 30 Jul 2007 16:07:50 -0500

> I was referring to the cname/crealm -- different problem.

Specifically I was referring to the cname/crealm in the Authenticator.

What purpose do these have?  Hard to tell.

Authentication of the client principal to the target occurs when the
target successfully decrypts (i.e., the integrity check succeeds) the
first the Ticket from the AP-REQ (with the target's key) and then the
Authenticator from the same AP-REQ (with the Ticket's session key).
(I'm ignoring replay caching here.)

Authentication of the service principal to the client occurs when the
client successfully decrypts (i.e., the integrity check succeeds) the
AP-REP from the target (with the Ticket's session key or the sub-session
key from the Authenticator).

The Authenticator happens to have a cname and crealm fields, and the
server is supposed to check that they match the corresponding fields of
the Ticket, but this adds little value: what really matters is that the
client prove that it knows the Ticket's session key.

Nico
--

---

From: Chaskiel M Grundman <[email-masked]>
Date: Mon, 30 Jul 2007 18:01:49 -0400

> client prove that it knows the Ticket's session key.

The client doesn't really know what is in the ticket.

The authenticator contains the client's assertion of its identity. The 
ticket contains the kdc's assertion of the clients identity. You really 
want them to match, though I admit that I can't see a specific attack that 
this prevents.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 30 Jul 2007 17:26:57 -0500

> The client doesn't really know what is in the ticket.

Well, it knows what its cname/crealm are, and the KDC shouldn't have put
in anything different in the Ticket.  Thus the inutility of having
cname/crealm in the Authenticator -- it adds no more value than the
integrity check on decryption of the Authenticator does (which is what
really matters, from a crypto protocol p.o.v.).  For example, the
cname/crealm in the Authenticator add no security against Ticket
cut-n-paste attacks on the KDC-REP -- the attacker would have to be sure
to have two Tickets with the same session key inside but different
cname/crealm in order to mount some attack should Authenticator not have
those two fields, but if the attacker can find two Tickets with the same
session keys, for the same sname/srealm, then the attacker either is the
server (in which case why bother attacking the client's KDC exchanges?)
or the attacker compromised Kerberos crypt (same thing).

> want them to match, though I admit that I can't see a specific attack that 

Right, I can't either.

Tom did some research into how we ended up with cname/crealm in the
Authenticator but found nothing conclusive, IIRC.

Thanks,

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 31 Jul 2007 10:29:36 +0200

> is a domainname slot), some of which are not (these tend not to have any

I agree that specifying the type, or at least knowing the type of a
string, is the first step towards any usable I18N solution.

> principal name components, and realm names, as domainname slots.

Right.  The only viable alternative is to specify exactly which fields
are IDN-aware slot or not.  I'm not sure which is simpler, but both
options should be considered.

Btw, terminology in the IDN area is somewhat sloppy.  Are you sure you
meant "domainname slot" and not "IDN-aware domain name slot"?  See RFC
3490.  Some of the rest doesn't make sense with just "domain name slot"
but makes good sense if you mean "IDN-aware domain name slot"... in

> We lose little from doing so, and gain much (e.g., Unicode version

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 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.

> 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.

> ambiguity in the domainname system I think we might as well do the same

My hope is that ACE encoding can be avoided in the Kerberos I18N
solution.

Have people already decided on a ACE-based approach?

I suggest considering an all-UTF8 approach.

/Simon

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 31 Jul 2007 08:16:25 -0400

> My hope is that ACE encoding can be avoided in the Kerberos I18N

The problem is that we can't be sure what the source of a hostname is.
There are going to be many application protocols where only the
punycode-encoded string is known.  One way to handle this would be for
the KDC to support automatic generation of punycode aliases for service
principals.  The administrator would determine which principals contain
host names or domain names and the admin tool would generate the
appropriate aliases.  The KDC would issue a service ticket for the
canonical service principal name and also include the list of equivalent
aliases for client verification.

If we can put the smarts into the KDC, then perhaps we don't need to
worry about the name types as much.

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 31 Jul 2007 13:18:29 -0500

> 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!).

> but makes good sense if you mean "IDN-aware domain name slot"... in

You start by declaring something to be a domainname slot and then you
figure out if you want to shove ACE ot Unicode into it.

> we are stuck with some particular version of Unicode.  If we use UTF-8,

I recommend that you listen to the recording of the IDNAbis presentation
at SAAG last week.

> client and servers, and can have them negotiate this.

You might reconsider if you saw that presentation.

> 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.

> Have people already decided on a ACE-based approach?

We already had consensus to use ACE for domainname slots.  I'm now
proposing that all principal name components be subject to ACE.

> I suggest considering an all-UTF8 approach.

I preferred that too, until I saw Klensing's presentation.

Nico
--