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

From: "John Brezak" <[email-masked]>
Date: Mon, 8 Oct 2001 09:07:33 -0700

Below [JBrezak].

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Monday, October 08, 2001 2:30 AM
To: John Brezak; Paul Leach
Cc: [email-masked]
Subject: Kerberos WG: draft-brezak-spnego-http-00.txt

John Brezak wrote:
> I will be posting an updated I-D that address the HTTP use of SPNEGO 
> based on some of the questions and comments on the list.
> 
> A preview:
> - HTTP/SPNEGO as implemented in Win2000 is limited to those mech-types

> that complete in 1 or 1.5 round trips - such as Kerberos and NTLM. The

> updated draft contains the details.
>
> - The client can preemptively send an Authorization header with a
> Negotiate+gssapi-data when it "knows" that a particular server can
> accept this Authentication mechanism.

1.5 roundtrips?  Is that 1 roundtrip plus a "challenge" from the initial
"HTTP/1.1 401 Unauthorized" reply -- this would explain how the term
"challenge" got the description of the WWW-Authenticate field. As I
explained this wouldn't fly with SPNEGO (rfc2478) since there is no
gssapi token prior to NegTokenInit.

[JBrezak] When using Kerberos it is just a single round trip:

S: 401, WWW-Authenticate: Negotiate
C: Authorization: Negotiate 987AB...	[Client call
InitializeSecurityContext
                                           requesting mutual auth to
start...]
S: 200, WWW-Authenticate: Negotiate  F890A...

But if that was the case, then I would have to wonder how a client could

short-cut further requests by preemtively sending an Authorization
header with the NTLM mechanism, since the initial challenge from the
server is the only way to prevent replay attacks with NTLM...

[JBrezak] The server acts as a universal responder since it can
distinguish between Kerberos, SPNEGO, and NTLM based on OID. However the
client will use SPNEGO with an optimistic blob based on whether the KDC
returned a service ticket for the target server. If the KDC didn't know
about the service, then NTLM is used as the optimistic mechanism.

> 
> Specifc questions about implementation of SPNEGO will not be addressed

> in this Internet-Draft.
 
I already mentioned this as well: there is one detail that you should
definitely document and that is whether your SPNEGO (acceptor) will
accept a plain rfc-1964 context establishment which every sensible
implementation of SPNEGO will support.

[JBrezak] Answered above.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Oct 2001 13:23:22 -0400

> [JBrezak] When using Kerberos it is just a single round trip:

Well, reading the IAKERB draft, it is 1.5 round-trips *at the GSS level*
when using IAKERB. So, how are 3rd, 4th, ..., Nth GSS tokens exchanged?

That is the question. Er, one of them.

[...]

> [JBrezak] Answered above.

How? Not that it matters. If the draft says "SPNEGO" then the acceptor
should be able to accept non-SPNEGO GSS initial tokens for mechs the
acceptor supports. This being an informational draft the question of how
MS' implementation behaves in this respect in quite interesting, but if
it is to be a standards track draft then the question is not probably no
longer relevant to the draft.

Cheers,

Nico
--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.