Subject: Kerberos WG: draft-brezak-spnego-http-00.txt

From: "Tim Bass" <[email-masked]>
Date: Tue, 25 Sep 2001 09:45:51 -0400

FYI: Submitted Sept 24,  J. Brezak,  Microsoft:

http://www.ietf.org/internet-drafts/draft-brezak-spnego-http-00.txt

Comments by WG  appreciated.

Finest Regards, Tim

www.silkroad.com

---

From: "Paul B. Hill" <[email-masked]>
Date: Tue, 25 Sep 2001 17:20:40 -0400

This group is embarassing itself. I'm one of the people that repeatedly
asked Microsoft to write the draft so that others could create interoperable
implementations if they so desired. John Brezak has already said that he is
working on removing the non-conformant characters.

Can we please move on to the important comments? Does the informational
draft provide sufficient information for other developers to create an
interoperable client or server?

<http://www.ietf.org/internet-drafts/draft-brezak-spnego-http-00.txt>

Paul

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Tue, 25 Sep 2001 14:45:27 -0700 (PDT)

> This group is embarassing itself. I'm one of the people that
> repeatedly asked Microsoft to write the draft so that others could
> create interoperable implementations if they so desired. John Brezak
> has already said that he is working on removing the non-conformant
> characters.

Actually the petulant comments about character set were on the main IETF
list, not this one.

 - RL "Bob"

---

From: Martin Rex <[email-masked]>
Date: Wed, 26 Sep 2001 11:54:01 +0200 (METDST)

Hi Paul,

> working on removing the non-conformant characters.

Not sure what you're referring to, I haven't seen much comments yet.

We should appreciate when Microsoft publishes its proprietary
developments to allow others to come up with interoperable implementations.

> <http://www.ietf.org/internet-drafts/draft-brezak-spnego-http-00.txt>

OK, important things first:

I'm confused by the description of WWW-Authenticate Response Header
and the Authorization Request Header.  Something is wrong/incomplete.

Why is the field in the WWW-Authenticate Response Header called
"challenge"?  There is no such thing as a challenge in GSS-API/SPNEGO.

Quoting from the document:
----  
  4.1 The WWW-Authenticate Response Header 
      
     If the server receives a request for an access-protected object, and 
     an acceptable Authorization header is not sent, the server responds 
     with a "401 Unauthorized" status code, and a WWW-Authenticate header 
     as per the framework described in [4]. The negotiate scheme will 
     operate as follows: 

          challenge       = "Negotiate" auth-data 
          auth-data       = 1#( [gssapi-data] ) 
           
     The meanings of the values of the directives used above are as 
     follows: 
      
     gssapi-data 
          If the gss_accept_security_context return a token for the 
          client, this directive contains is the base64 encoding of an 
          InitialContextToken as defined in [6]. 
----

In GSS-API, the security context establishment begins with a call
to gss_init_sec_context() which produces the "InitialContextToken",
which is then sent to the Acceptor and passed to gss_accept_sec_context().

In the initial 401 Unauthorized server reply there can *never* be a gssapi
context-level token, and as long an the server is the security context
acceptor, it can *NEVER* be an InitialContextToken / NegTokenInit,
only a NegTokenTarg.

The InitialContextToken can only be present in the Authorize Request Header.
Acutally, since this document uses SPNEGO, the Authorize Request Header
will contain a NegTokenInit.

Next, the 200 Response after receipt of an acceptable Authorization request
could contain a WWW-Authenticate response with a gssapi context token
(SPNEGO NegTokenTarg).  There are several constraints whether this
token is returned and what it contains.

Since this document should describe an existing implementation for
interoperability purposes, those constaints should really be revealed!

- The Kerberos gssapi mechanism (rfc1964) supports 1-way security
  context establishment whenever the initiator does not request
  mutual authentication.  AFAIK, W2K Kerberos supports this as well.
  What does MSIE do?  What should other HTTP-clients do?

- SPNEGO (rfc2478) section 3.2.2. describes under which circumstances
  a NegTokenTarg must be returned by the acceptor.  There are references
  to implementation design choices as well.  Yup, SPNEGO is not a
  trivial protocol ...

Now since this spec is using SPNEGO, what happens if the acceptor does
not implement the mechanism of the initial context token?  SPNEGO would
happily chose the next common mechanism and require an additional
round trip.  I'm not clear whether this is actually supported...

Hypothesis:  Microsoft ships IAKERB with independent mech OIDs and
someone with MSIE containing such an IAKERB connects to a third-party
web-server implementing the HTTP-authentication described in this
document.  When MSIE sends along an IAKERB initial context token,
but the server only has access to a regular rfc-1964 Kerberos mechanism,
then SPNEGO will choose rfc-1964 and cause a second round-trip.

How do you (and how does this protocol) expect to handle this case?

-Martin

---

From: "Paul B. Hill" <[email-masked]>
Date: Wed, 26 Sep 2001 11:39:23 -0400

Hi,

Last night I caused some confusion on the list by posting to the wrong list.
I should have posted to the [email-masked] list, where comments have been
posted in response to draft-brezak-spnego-http-00.txt. To date, all of the
comments on that list have been related to the fact that the current version
of the draft contains some characters that are not 7-bit ASCII. John Brezak
replied saying that he would correct the problem, but the complaints have
continued.

My appolgies to the group, and thank you to those (several) that pointed out
my cross posting error.

Paul

-----Original Message-----
From: Martin Rex [mailto:[email-masked]]
Sent: Wednesday, September 26, 2001 5:54 AM
To: Paul B. Hill
Cc: [email-masked]
Subject: Re: Kerberos WG: draft-brezak-spnego-http-00.txt

Hi Paul,

...
--------------------