Subject: Re: KRB-WG IETF-55 meeting minutes - for review by attendies

From: Sam Hartman <[email-masked]>
Date: Thu, 21 Nov 2002 10:39:01 -0500

>>>>> "Douglas" == Douglas E Engert <[email-masked]> writes:

    Douglas> Sam Hartman is bringing up concerns about authorization
    Douglas> data SHOULD versus MUSTs. There is consensus that
    Douglas> "encapsulating authorization data" MUST be rejected if
    Douglas> not understood.

No, I thought the consensus was all authzdata must be rejected if not understood and that  people must implement encapsulating elements.
    Douglas> Issue #3: Sam would like to force some principals to only
    Douglas> have random keys. There's a concern from the crowd that
    Douglas> the KDC is currently a free source of entropy. Leif
    Douglas> thinks that a fix to this draft may change the
    Douglas> LDAP-schema draft.

He actually said that it might help sync ldap change password extended
operations with set-change password.

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 21 Nov 2002 08:43:31 -0600

[Draft 1.0 of minutes for review by the attendees. Please send comments  
on the minutes, i.e. if the minutes do not reflect what was said at the meeting
of if important points from the meeting where not reported. But fell free to
send other comments to the list, but change the subject in the reply.]

The Kerberos  WG (krb-wg)  meet at 55th IETF, 11/19/02

[13:00] Doug Engert opened the meeting with a review of the agenda. There
where about 60 people attending.

Larry Greenfield <[email-masked]> volunteered to take note. [These 
minutes are substantial his notes. Thanks Larry.]

[13:10] Cliff Neuman, Kerberos Clarifications

Today is the last day of the WG last call for Kerberos clarifications,
draft-ietf-krb-wg-kerberos-clarifications-02.txt. There were many
comments; http://www.kerberos.isi.edu/people/bcn/krb-revisions/ have
the latest issues and the editor's classification of them.

Sam Hartman is bringing up concerns about authorization data SHOULD
versus MUSTs. There is consensus that "encapsulating authorization
data" MUST be rejected if not understood.

It's decided that there has to be another WG last call once
a new draft reflecting issues has been issued.

[13:18] Ken Raeburn, Encryption and Checksum Specifications for Kerberos 5
draft-ietf-krb-wg-crypto-02.txt
draft-raeburn-krb-rijndael-krb-02.txt

Ken and others believe that clarifications, encryption, and the AES documents
will all have to move simultaneously.

There needs to be another encryption draft because of DES
specification problems. The latest version of the AES document dropped
twofish and 192-bit AES.

One issue is whether there needs to be a new function in the crypto
profile for generating random data to feed into algorithms for
combining keys.

[13:25] Matt Hur, PKINIT
draft-ietf-cat-kerberos-pk-init-16.txt

There have been very few changes in the past few revisions. The goal
is to last call this document shortly after clarifications.

Tom Yu brings up that RFC 2253 transformation from cert to principal
isn't unique. Kurt Zelinga, Tom Yu, Leif Johansson, Bob Morgan, Larry
Greenfield, Jeff Altman, participate in a discussion. General
consensus that the certificate to principal mapping is a site policy
issue but some guidance might be helpful. There was some amount of
confusion when PKTAPP was brought up, since then services (and not
just KDCs) will be making the mapping.

Agreement to discuss the mapping problem on the list and there will be
another version of the draft.

[13:46] Sam Hartman, Kerberos set/change password
draft-ietf-cat-kerberos-set-passwd-06.txt

Issue #1: This specification implicitly changes the Kerberos protocol
by making restrictions on what addresses are passed to krb_mk_priv().

Issue #2: The draft currently specifies UTF-8; it would be nice to
have something that works now and continues to work after extensions
makes Kerberos Unicode friendly. This brings up non-unicode
characters, stringprep, and where to normalize.

Sam recommends sending unnormalized UTF-8 to the server with a
recommendation to confine to US-ASCII if you want to interoperate now.

Issue #3: Sam would like to force some principals to only have random
keys. There's a concern from the crowd that the KDC is currently a
free source of entropy. Leif thinks that a fix to this draft may
change the LDAP-schema draft.

The chair sees consensus that set/change password should be withdrawn
from the IESG, fixed, and resubmitted.

[14:00] End of first session, 15 minute break.

[14:15] Cliff Neuman, Kerberos Extensions
<no current draft>

Cliff summarizes where extensions came from and what the goals
are. Jeff Altman contributes that the i18n extensions mostly revolve
around normalization. Many of the things listed for extensions (client
canonicalization, updating MUSTs versus SHOULDs) have actually been
done or partially done in clarifications.

Tom Yu brings up the edata outstanding issues, including authenticated
cleartext and typed data inside of edata. Sam Hartman relays that
previous consensus in Feb was that the typed data wasn't the general
solution. Sam also brings up problems with name space constraints that
are mentioned in clarifications and should be addressed in extensions
(cross-realm cache poisoning).

Cliff talks about what will be enabled by extensions and emphasized
backwards compatibility. Matt Hur queries if this will still be
Kerberos v5 or if the protocol number should change. An impassioned
discussion follows where many people say "who cares what the protocol
number is".

[14:42] Glen Zorn, IAKERB
draft-ietf-cat-iakerb-08.txt

Glen talks about the current state of the draft (in the hands of the
IESG) and, upon querying by the chair, says that he's not familiar
with Martin Rex's objections. Glen thought Symbol might have done an
implementation of IAKERB, but the crowd disagrees.

Jeff Hutzelman relays some of Martin Rex's concerns, like "SPNEGO in
this protocol has no value" and "under specified for a GSS mechanism"
so "no two implementations will interoperate". The document editor,
Jonathan Trostle, thought that he had addressed Martin's comments.

The chair notes that the WG is still waiting on Jeff Schiller's comments.

There is consensus that IAKERB is seriously flawed if it can't deal
with multiple round trips and various preauth mechanisms. Glen Zorn
dissents.

The WG discusses moving the document to experimental instead of
standards-track. The chair asks if the WG should withdraw this
document; the room is split 50-50 with no consensus. The chair notes
that those in favor for withdrawal, are mostly core developers, those
in favor of not withdrawal are vendors who might still find it useful.

[14:50] Derek Atkins, Krb5-EAP

Derek presents an alternative to IAKERB and believes he will have a
draft out in mid-December. His approach uses EAP to tunnel "random"
Kerberos messages.

[14:55] Ken Hornstein, initial authentication
draft-ietf-krb-wg-hw-auth-02.txt
draft-ietf-krb-wg-kerberos-sam-01.txt

Ken discusses protecting the initial authentication using the local
host key and how it interacts with hardware preauth. One problem with
kerbeors-sam-01 is that it is insecure when used with RC4.

[15:00] Donna Skibbie, Kerberos LDAP schema
draft-skibbie-krb-kdc-ldap-schema-01.txt

There is general interest that this is good work; a fairly large group
has indicated specific interest. Leif asks why the information model
was removed from the base Kerberos spec (clarifications). Ken Raeburn
replies that it was overly MIT specific, and there's general consensus
that a general information model would be a good thing.

Donna asks people to contact her if you want to be added to the
Kerberos-ldap-schema-list.

[15:08] done, 8 minutes overtime.

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: "Tim Bass" <[email-masked]>
Date: Thu, 21 Nov 2002 12:26:23 -0500

With regard to:

"Jeff Hutzelman relays some of Martin Rex's concerns, like "SPNEGO in
this protocol has no value" and "under specified for a GSS mechanism"
so "no two implementations will interoperate". 

-----------

FWIW:

A "large organization" expected MS to publish a fully interoperable
specification for SPNEGO (when they met with MS and requested MS
to do so) and to fully particate in the IETF WG to insure that the 
SPNEGO (and similar MS Kerberos implementations) would be 'worked'
in the WG as an open standard.

We have not been as encouraged as we would have liked by the
(apparent) 'lack of interest' by MS to evolve SPNEGO as requested
by the WG.  It was not our understanding that SPNEGO would be
"informational only" and "documents only a specific implementation"
as has been stated.  We will circle back on this with the folks who 
met with MS last year and relay the concerns of the WG, if required
to move this forward.

The "large organizations" goals were to insure that MS implementation 
of KV5 over HTTP is fully compliant with open standards and specified
so that interoperability can be insured.  

We greatly appreciate the consensus comments of the WG on the SPNEGO
draft.

Finest Regards, Tim
www.silkroad.com

---

From: Sam Hartman <[email-masked]>
Date: Fri, 22 Nov 2002 20:55:09 -0500

>>>>> "Tim" == Tim Bass <[email-masked]> writes:

    Tim> With regard to:

    Tim> "Jeff Hutzelman relays some of Martin Rex's concerns, like
    Tim> "SPNEGO in this protocol has no value" and "under specified
    Tim> for a GSS mechanism" so "no two implementations will
    Tim> interoperate".

    Tim> -----------

Jeff was talking about the iakerb draft: draft-ietf-cat-iakerb-08,
which describes  one way of using Kerberos to get initial tickets for
dialup connections.

So far as  I know, iakerb has nothing to do with HTTP, which seems to
be the thrust of your message.

    Tim> FWIW:

    Tim> A "large organization" expected MS to publish a fully
    Tim> interoperable specification for SPNEGO (when they met with MS
    Tim> and requested MS to do so) and to fully particate in the IETF
    Tim> WG to insure that the SPNEGO (and similar MS Kerberos
    Tim> implementations) would be 'worked' in the WG as an open
    Tim> standard.

SPNEGO  (RFC 2743) is a standards-track document for specifying how a
client and server can agree on which GSSAPI mechanism to use.  That
document was a work product of the Common Authentication Technologies
working group of the IETF.  While the finalization of SPNEGO predated
my involvement in the IETF, I believe that Microsoft was involved in
that process.

Having discussed SPNEGO with John and other Microsoft employees I've
gotten the impression that Microsoft believes they have implemented
something that complies with the IETF proposed standard for SPNEGO;
obviously you should confirm with Microsoft rather than taking my word
on what they have done if it becomes important.  I am aware of three
non-Microsoft efforts to implement SPNEGO, including my effort to
implement SPNEGO for MIT Kerberos; all three of these efforts have a
goal of interoperability testing with Microsoft.  If we run into
interoperability problems we'll naturally discuss our concerns with
Microsoft and bring any problems we find in the specification to the
attention of the IETF.

    Tim> We have not been as encouraged as we would have liked by the
    Tim> (apparent) 'lack of interest' by MS to evolve SPNEGO as
    Tim> requested by the WG.  It was not our understanding that
    Tim> SPNEGO would be "informational only" and "documents only a
    Tim> specific implementation" as has been stated.  We will circle
    Tim> back on this with the folks who met with MS last year and
    Tim> relay the concerns of the WG, if required to move this

I can only assume these comments refer to draft-brezak-spnego-http,
not to the SPNEGO specification itself, as I'm not aware of anyone
wanting to evolve SPNEGO and it is not "just for information."  If I
misread your message, then please clarify what you are concerned
about.  Otherwise, here are my thoughts on SPNEGO and HTTP.

It's important to realize that the IETF is a consensus-based
organization.  Even if Microsoft wants to standardize their approach
to SPNEGO over HTTP, they cannot do so unless the IETF community as a
whole is interested in the work.

It would be nice to consider various approaches for using GSSAPI in
conjunction with HTTP, including Microsoft's approach and two
approaches based on SASL and to standardize a solution.  But despite
these three proposals being written up, there seems to be insufficient
effort expended to cause the proposals to move anywhere.  I think this
problem could benefit significantly from someone organizing the
interested parties--including server and browser vendors as well as
security experts from the IETF--and providing focus on the issue.
This organizational effort doesn't have to come from Microsoft or any
of the current players; a large organization who wanted an
interoperable solution to the problem and who was willing to dedicate
time to participating in the IETF process and organizing all the
appropriate parties could go a long way.  Of course vendors like
Microsoft would need to participate and eventually implement a
solution, but it is not surprising that vendors are reluctant to
commit effort to standardization if there is not clear interest both
in the customer and standards community.

---

From: "Tim Bass" <[email-masked]>
Date: Fri, 22 Nov 2002 23:25:42 -0500

Sam,

My apologies for the confusion.  I had surgery on my eye muscles
recently and have not been reading things as carefully as I should
during the recovery - and can't seem to get away from the computer
screen, so much work to do!

You are exactly right, I was confusing comments on SPNEGO (RFC 2743)
with draft-brezak-spnego-http.

I concur with your comments that the core issues are not the
draft per se, and evolve around how/if to move forward GSSAPI/HTTP 
in an interoperable way that works with the server, browser and security

parties.

You concluded:  

"a large organization who wanted an interoperable solution to the 
problem and who was willing to dedicate time to participating in 
the IETF process and organizing all the appropriate parties could 
go a long way."

I think it is possible that "one particular large organization"
could be willing to dedicate time to the IETF process and help 
organize all the appropriate parties" (to paraphrase your words).

We would need to provide a bit more details to the senior leadership
of 'the paraticular large organization' i.e. 

Question:

In your estimate, how much resource (time) would 'the large
organization' 
needs to dedicate to IETF?  Do you see this effort under the Kerberos
WG?

Should we take this offline?

-Tim

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Friday, November 22, 2002 8:55 PM
To: [email-masked]
Cc: 'Kerberos WG'
Subject: spnego, http 

    Tim> With regard to:

    Tim> -----------

Jeff was talking about the iakerb draft: draft-ietf-cat-iakerb-08, which
describes  one way of using Kerberos to get initial tickets for dialup
connections.

So far as  I know, iakerb has nothing to do with HTTP, which seems to be
the thrust of your message.

    Tim> FWIW:

SPNEGO  (RFC 2743) is a standards-track document for specifying how a
client and server can agree on which GSSAPI mechanism to use.  That
document was a work product of the Common Authentication Technologies
working group of the IETF.  While the finalization of SPNEGO predated my
involvement in the IETF, I believe that Microsoft was involved in that
process.

I can only assume these comments refer to draft-brezak-spnego-http, not
to the SPNEGO specification itself, as I'm not aware of anyone wanting
to evolve SPNEGO and it is not "just for information."  If I misread
your message, then please clarify what you are concerned about.
Otherwise, here are my thoughts on SPNEGO and HTTP.

It's important to realize that the IETF is a consensus-based
organization.  Even if Microsoft wants to standardize their approach to
SPNEGO over HTTP, they cannot do so unless the IETF community as a whole
is interested in the work.

It would be nice to consider various approaches for using GSSAPI in
conjunction with HTTP, including Microsoft's approach and two approaches
based on SASL and to standardize a solution.  But despite these three
proposals being written up, there seems to be insufficient effort
expended to cause the proposals to move anywhere.  I think this problem
could benefit significantly from someone organizing the interested
parties--including server and browser vendors as well as security
experts from the IETF--and providing focus on the issue. This
organizational effort doesn't have to come from Microsoft or any of the
current players; a large organization who wanted an interoperable
solution to the problem and who was willing to dedicate time to
participating in the IETF process and organizing all the appropriate
parties could go a long way.  Of course vendors like Microsoft would
need to participate and eventually implement a solution, but it is not
surprising that vendors are reluctant to commit effort to
standardization if there is not clear interest both in the customer and
standards community.

---

From: Leif Johansson <[email-masked]>
Date: Sun, 24 Nov 2002 02:52:42 +0100

>>>>>>"Douglas" == Douglas E Engert <[email-masked]> writes:

<snip>

> operations with set-change password.

Correct. There was also discussions about aligning krb password policy
with ldap password policy schema as part of the schema work...

	Cheers Leif

---

From: Martin Rex <[email-masked]>
Date: Thu, 28 Nov 2002 19:35:13 +0100 (MET)

> so "no two implementations will interoperate". 

My criticism has probably been misunderstood in some aspects.

Requiring SPNEGO for IAKERB would be about as bad as requiring
it for supporting additional Kerberos enctypes -- i.e. an
incredible amount of unnecessary protocol bloat.

In addition, in the GSS-API world very few vendors actually
participate the IETF process or perform interop testing

I've seen several different SPKM/rfc-2025 implementations
from vendors that asked us for interoperability certification
with our application, but apparently no two vendors have 
performed interop testing with any other implementations,
because from the output of my test tools I can see that
no two of them will fully operate (by which I mean not just
on-the-wire but also full API-level interoperability --
which means for the customers that they will have to use
homogeneous installations, they cannot mix SPKM implementations
from different vendors for use in our distributed application.

With Kerberos it should today be possible to use heterogeneous
environments with implementations from different vendors
(like MIT Kerberos and Microsoft W2K Kerberos) with only minor
hazzles.  I'll try my best to fight against Kerberos change proposals
that will terminate/break this status quo.  :)

> met with MS last year and relay the concerns of the WG, if required

As it has already been pointed out on this list, SPNEGO is already
a proposed standard and has been around for quite some time now.

However, SPNEGO has a very specific place in the GSS-API architecture
and several requirements and constraints of which the two Microsoft
proposals IAKERB and Kerberos-authentication over HTTP are 
completely ignorant (KV5 over HTTP is extremely awful in ignoring
the SPNEGO constraints and requirements).

> so that interoperability can be insured.  

Fixing the client side that is easy -- completely drop SPNEGO.
Fortunately SPNEGO is utterly useless for the client anyway.

Fixing the server side that is near impossible -- the installed base of
broken MSIEs that send SPNEGO will be hard to overcome.

KV5 over HTTP *with* SPNEGO way beyond fixing.  SPNEGO just doesn't fly
in this particular environment (it's a real mystery to me how an SPNEGO
implementor could have misunderstood this part of the SPNEGO spec,
so I assume that the implementor of KV5 over HTTP never read the
SPNEGO spec and never talked to the SPNEGO implementor at Microsoft...).

-Martin