Subject: kerberos-extensions open issues

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 23 Oct 2003 13:48:55 -0400

I've gone through the minutes from the interm meeting last month, and come 
up with the following list of open issues for kerberos-extensions.  Many of 
these were to be done by the November meeting...

- REMOVE SMTP name type [Cliff Neuman]
- add language tags to request as well as reply [Tom Yu]
- Add nonce to krb-error [Tom Yu]
- Encoding [Tom Yu, Nico Williams]
- Allow KDC to offer extensions support via PA-DATA PA-AS-REQ [Sam Hartman]
- Allow KDC to accept addresses of unknown families [Cliff Neuman]
- KRB-ERROR signing guidelines [Sam Hartman]
- typed-hole namespace assignment [Tom Yu, Nico Williams]
- cross-realm referrals [Todd Stecher/Microsoft]
  how is this different from what clarifications already includes?
- PKINIT US-ASCII text (what is this??) [Jeff Altman]
- Mixed client libraries [Sam Hartman, Jeff Altman]
- U2U negotiation [Tom Yu]
- Namespace restrictions [Sam Hartman]
- Downgrade ext->clar issues [Nico Williams]
- I18N issues [Jeff Altman, Jeff Hutzelman]
- How does extensions-only client probe KDC -- deferred to list
- Update MUST's -- deferred until closer to publication

I believe many of these items only require the designated individual to 
provide some text to Cliff to be included in the document; a couple are 
actually separate internet-drafts.  Ideally, I'd like to see text for each 
of these submitted (to Cliff or to the internet-drafts repository) before 
the meeting.  For those things going into kerberos-extensions which are not 
done, please at least send Cliff a status update so he'll have something to 
tell us during the meeting.  Note that the I-D submission deadline for new 
documents has already passed, so nothing will be _published_ before the 
meeting.

The real purpose of this message, though, relates to those items which 
actually required research and/or discussion.  We need to come up with a 
list of extensions-related topics to place on the agenda, and anything from 
the above list that requires input from the working group is a good 
candidate.  We already have a brief status report from Cliff, followed by a 
discussion of the IDN issues led by Jeff Altman.  What other topics need to 
be added?

-- Jeff

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 23 Oct 2003 18:59:47 -0400

I would like to see a discussion on Cross Realm Referrals and perhaps a 
refresher on the Name Canonicalization issues as they may affect the IDN 
discussion.

- Jeff

Jeffrey Hutzelman wrote:

> I've gone through the minutes from the interm meeting last month, and 
> come up with the following list of open issues for 
> kerberos-extensions.  Many of these were to be done by the November 
> meeting...
>
> I believe many of these items only require the designated individual 
> to provide some text to Cliff to be included in the document; a couple 
> are actually separate internet-drafts.  Ideally, I'd like to see text 
> for each of these submitted (to Cliff or to the internet-drafts 
> repository) before the meeting.  For those things going into 
> kerberos-extensions which are not done, please at least send Cliff a 
> status update so he'll have something to tell us during the meeting.  
> Note that the I-D submission deadline for new documents has already 
> passed, so nothing will be _published_ before the meeting.
>
>
> actually required research and/or discussion.  We need to come up with 
> a list of extensions-related topics to place on the agenda, and 
> anything from the above list that requires input from the working 
> group is a good candidate.  We already have a brief status report from 
> Cliff, followed by a discussion of the IDN issues led by Jeff Altman.  
> What other topics need to be added?
>
> -- Jeff
>

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 23 Oct 2003 15:58:15 -0700

> refresher on the Name Canonicalization issues as they may affect the IDN 

Do we still want to do name canonicalization in the KDC exchanges for
anything other than referrals?

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 23 Oct 2003 19:06:00 -0400

>anything other than referrals?

Well we didn't.  But the IDN issues might be better solved with name 
canonicalization.  The deeper I look at the problem the uglier it gets.  
I hope to post another detailed message sooner rather than later.

- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 23 Oct 2003 16:14:30 -0700

> I hope to post another detailed message sooner rather than later.

The KDC would have to know what conventions are in use for principal
naming that involve the use of domain names and such conventions would
have to be unambiguous, but without relying on the name type hint from
queries.

The two-component principal naming conventions in use today are
ambiguous.  Making them unambiguous is probably not very hard, but the
result won't be very clean.

So far I'm happy with just extending the case folding recommendations of
rfc1510/clarifications - it worked for rfc1510, after all.

There are some wrinkles with that approach too, but I think they're
small and manageable, namely:

 - who applies the case folding recommendations (as I've pointed out, in
   some cases only the user can, namely when non-standard naming
   conventions are used)

 and

 - whether the case folding recommendation is required for realm names;
   this can be addressed like so: not required for ASCII-only realm
   names but required for non-ASCII realm names.

 - have I missed any other wrinkles?

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 24 Oct 2003 19:49:39 +0200 (MET DST)

> refresher on the Name Canonicalization issues as they may affect the IDN 

Name Canonicalization:

The Kerberos protocol and the GSS-API architecture both use
name-based authentication.  Since an application (server) needs to
populate ACLs for access control and authorization that does not
involve established security contexts with all possible initiators,
any name canonicalization MUST be available seperately from
security context establishment, i.e. for the sequence of the
following three gssapi calls:

 gss_import_name()   taking the printable input from an admin
 gss_canonicalize_name()
 gss_export_name()   emitting the canonical name for populating an ACL

The solution to this problem is not sufficiently addressed in
the canonicalization implemented by Microsoft's Kerberos SSP.

Any IETF approach to name canonicalization for Kerberos
must address and solve this issue.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Mon, 27 Oct 2003 16:30:47 -0500

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> The Kerberos protocol and the GSS-API architecture both
    Martin> use name-based authentication.  Since an application
    Martin> (server) needs to populate ACLs for access control and
    Martin> authorization that does not involve established security
    Martin> contexts with all possible initiators, any name
    Martin> canonicalization MUST be available seperately from
    Martin> security context establishment, i.e. for the sequence of
    Martin> the following three gssapi calls:

I disagree with your use of the word must in the previous paragraph.
I will defer a discussion of why I disagree until we have a concrete
proposal on the table that you find objectionable.  It seems like a
bad idea to waste time on a philosophical discussion of what the
requirements are if we end up proposing a specific implementation we
both agree to.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 27 Oct 2003 16:33:22 -0500

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

    Nicolas> On Thu, Oct 23, 2003 at 06:59:47PM -0400, Jeffrey Altman
    Nicolas> wrote:
    >> I would like to see a discussion on Cross Realm Referrals and
    >> perhaps a refresher on the Name Canonicalization issues as they
    >> may affect the IDN discussion.

    Nicolas> Do we still want to do name canonicalization in the KDC
    Nicolas> exchanges for anything other than referrals?

Microsoft presented compelling arguments that client name
canonicalization is required.  They were convinced that KDC-side
aliasing is sufficient for there needs.

---

From: Martin Rex <[email-masked]>
Date: Tue, 28 Oct 2003 12:20:11 +0100 (MET)

> requirements are if we end up proposing a specific implementation we

No *concrete* proposal necessary.
GSS-API is a generic API and an *abstraction*.
The MUST needs to be there, whether you like it or not.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 28 Oct 2003 12:40:36 +0100 (MET)

> aliasing is sufficient for there needs.

What Microsoft is shipping these days looks more and more like DCE
and less and less like Kerberos5.

There's a more than 2-way security context establishment which can
be used to avoid the use of a server-side replay cache -- DCE has that.

They use an authorization extension and when it's present, they ignore
the name based authentication.  -- DCE has that, only that it uses
a seperate ticket instead of stuffing it into the regular TGT.

They have an Directory (called Active Directory) which they use to
transform names.  -- DCE also has a Directory for that purpose,
only that DCE does it correctly and has name lookup seperated
from authentication, which makes it fit with GSS-API architecture.

When you're finished, Kerberos5 will not be Kerberos5 anymore, but
hacked up in the Microsoft fashion to offer all features of DCE.

And it will make MIT Kerberos and other Unix-based Kerberi look bad
in comparison to Microsoft's because it doesn't come with its own
DNS server and Directory...

When I look at some of the stuff that Microsoft is proposing
(e.g. name canonicalization) then I'm convinced this is what D.E. Knuth
meant when he said "Premature optimization is the root of all evil".

-Martin