Subject: Please review: http gss authentication mech

From: Leif Johansson <[email-masked]>
Date: Thu, 09 Nov 2006 20:23:46 +0100

At the informal bar-bof yesterday in San Diego it was decided that I should
send my drafts describing a new http gss authentication mechanism to
this list.

Note that these drafts are not intended for inclusion in the kitten
charter at
this or any future time. They are only presented to this list for review
by gss
experts.

By way of background this draft (and the related draft describing channel
bindings for http+tls) describes a successor (but not update) to  the 
negotiate
http auth mech which hopes to solve some of the drawbacks of this
mechanism.
The orginal motivation for this work was requirements from the calcify
wg who
expressed the need for a better authentication mechanism (than plain
passwords)
for applications using http as a transport but not using a browser as a
client.

Please note that this is a 00 version and new versions with
modifications based
on discussions from yesterday are forthcoming.

http://www.ietf.org/internet-drafts/draft-johansson-http-gss-00.txt
http://www.ietf.org/internet-drafts/draft-johansson-http-tls-cb-00.txt

       Cheers Leif

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Michael B Allen <[email-masked]>
Date: Thu, 9 Nov 2006 15:21:42 -0500

I don't speak for kitten and I'm not familiar with the TLS channel binding
thing but the only flaw in the Negotiate method that really that really
jumps out is the conflict between stateful GSSAPI and stateless HTTP. How
does your method address this issue?

For example consider a client that pipelines 10 requests. The server
response to the first and the client submits another token. How will
you distinguish secondary or teriary tokens from one another?

What happends if the 5th request in a pipeline fails GSS?

What happends if the 5th request in a pipeline sends connection: close?

These are the sort of things that cause problems with mechanisms that
require more than one exchange (e.g. I suspect this is a source of
mysterious NTLM failures reported occasionally).

Mike

On Thu, 09 Nov 2006 20:23:46 +0100

-- 
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/

---

From: Leif Johansson <[email-masked]>
Date: Thu, 09 Nov 2006 22:20:25 +0100

> does your method address this issue?
If I understand your question correctly the gss draft aims to solve this
problem by having the
server send state back to the client (state which is also used to do
fast reauth) with the challenge.
There are several ways to implement this, including short-cuts if you
use kerberos and proposed
extensions to allow exporting unfinished contexts from gssapi.

    Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Fri, 10 Nov 2006 00:09:18 +0100

Tim Alsop wrote:
> Leif,
>
> Have you considered using SASL over HTTP with GSS-API, as described in :
>
> http://tools.ietf.org/wg/sasl/draft-nystrom-http-sasl-12.txt 
>
> I was under the impression that the above draft was the preferred method
> to improve on the HTTP negotiate approach.
>
>
>   
I am under the impression that the proposed SASL mechanism doesn't
support channel
bindings, partially because channel bindings have been a notoriously
difficult problem to get
right in SASL space. Personally I din't see the value of adding the
extra layer of glue.

    Cheers Leif

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Thu, 9 Nov 2006 15:26:00 -0800 (PST)

More significantly, draft-nystrom-http-sasl-12.txt only works when 
persistent connections are used, which is a showstopper.  Hence the 
text in http-gss:

    session.  Instead opaque identifiers in the GSS challenge option
    field are optionally used together with channel bindings to provide a
    way to share a security context over several HTTP connections.

  - RL "Bob"

> support channel bindings, partially because channel bindings have been a 
> notoriously difficult problem to get right in SASL space. Personally I 
> din't see the value of adding the extra layer of glue.
>
>    Cheers Leif
>
>

---

From: "Tim Alsop" <[email-masked]>
Date: Thu, 9 Nov 2006 22:16:02 -0000

Leif,

Thanks,
Tim

-----Original Message-----
From: Leif Johansson [mailto:[email-masked]] 
Sent: 09 November 2006 19:24
To: Kitten
Cc: Lisa Dusseault
Subject: Please review: http gss authentication mech

At the informal bar-bof yesterday in San Diego it was decided that I
should
send my drafts describing a new http gss authentication mechanism to
this list.

By way of background this draft (and the related draft describing
channel

       Cheers Leif

---

From: "Tim Alsop" <[email-masked]>
Date: Fri, 10 Nov 2006 16:19:42 -0000

Leif,

support channel
difficult problem to get
extra layer of glue.

My understanding is that, if SASL is using GSS/Kerberos to protect HTTP
communications, then GSS channel bindings can be used, so SASL does not
need to have direct support for channel bindings. This is an advantage
of using a multi-layered architecture.

Cheers,
Tim

---

From: "Tim Alsop" <[email-masked]>
Date: Fri, 10 Nov 2006 16:23:27 -0000

Bob,

Since the draft for SASL-HTTP is not yet an RFC, is there any reason why
changes cannot be proposed to allow it to support non-persistent
connections ?

It just seems strange to me that this draft has undergone a lot of work
by many people, and because of some functionality that is missing from
it (e.g. support for non-persistent connections) it is being suggested
that a new draft should be progressed instead. Is this the way that
standards are normally progressed ?

Regards,
Tim 

-----Original Message-----
From: RL 'Bob' Morgan [mailto:[email-masked]] 
Sent: 09 November 2006 23:26
To: Leif Johansson
Cc: Tim Alsop; Kitten; Lisa Dusseault
Subject: Re: Please review: http gss authentication mech

    session.  Instead opaque identifiers in the GSS challenge option
    field are optionally used together with channel bindings to provide
a
    way to share a security context over several HTTP connections.

  - RL "Bob"

---

From: Lisa Dusseault <[email-masked]>
Date: Sun, 12 Nov 2006 11:07:03 -0800

I've done an early (not for nits) review of this draft.

Major architectural concern: I am not enough of a GSS expert to know  
if this mechanism offers enough information in each roundtrip for a  
server to be able to reconstruct who the request is from and where  
they are in the authentication process.  The spec only mentions  
passing GSS tokens resulting from various API calls, and not how  
these tokens can be used to recover state, or what other state the  
server must store to put all this together, and how long the server  
must store that.  For HTTP server farms and non-persistent connection  
scenarios, it's important to explain this stuff somewhere.

Major standardization concern: This work is based on an Informational  
RFC, yet it's marked as intended for Standard Track.  I am dubious  
about a variance for a downref for RFC4559, for various reasons we  
can discuss if it's not obvious or others disagree.

Other work todo on this spec, besides the todos already mentioned in  
the spec:
	- Add a swimlane diagram showing client requests and server  
responses and what GSS stuff goes in each.
	- Much more discussion and spec text necessary on the "client  
initiates authentication feature".  Although I would like to see this  
feature become a standard, it's not actually tied to GSS, and I think  
this feature From [email-masked] Sun Nov 12 14:49:09 2006
From: Lisa Dusseault <[email-masked]>
Date: Sun, 12 Nov 2006 11:07:03 -0800
To: Leif Johansson <[email-masked]>
Cc: Kitten <[email-masked]>
Subject: Re: Please review: http gss authentication mech

I've done an early (not for nits) review of this draft.

Major architectural concern: I am not enough of a GSS expert to know  
if this mechanism offers enough information in each roundtrip for a  
server to be able to reconstruct who the request is from and where  
they are in the authentication process.  The spec only mentions  
passing GSS tokens resulting from various API calls, and not how  
these tokens can be used to recover state, or what other state the  
server must store to put all this together, and how long the server  
must store that.  For HTTP server farms and non-persistent connection  
scenarios, it's important to explain this stuff somewhere.

Major standardization concern: This work is based on an Informational  
RFC, yet it's marked as intended for Standard Track.  I am dubious  
about a variance for a downref for RFC4559, for various reasons we  
can discuss if it's not obvious or others disagree.

Other work todo on this spec, besides the todos already mentioned in  
the spec:
	- Add a swimlane diagram showing client requests and server  
responses and what GSS stuff goes in each.
	- Much more discussion and spec text necessary on the "client  
initiates authentication feature".  Although I would like to see this  
feature become a standard, it's not actually tied to GSS, and I think  
this feature could not easily go to Proposed Standard unless it met  
with solid approval from HTTP implementors. There are many details  
still unspecified (some questions at bottom of this email, not  
guaranteed to be a complete list of issues).
	- I'd personally prefer MUST-language that does not say that the  
client or server "MUST call gss_foo_bar".   Instead, the requirements  
could be that the client or server MUST use the token that would  
result from a call to gss_foo_bar.  This may be an un-GSS way of  
doing things :)
	- Explain the limits on the number of roundtrips (current spec text  
says "This process continues until either an error occurs or the GSS- 
API layer has successfully completed...").

Lisa

Open questions on client initiating HTTP Authentication
	- How does the client know it may send an empty Authorization header  
-- what if it tries this with a server not supporting HTTP-GSS?
	- May the server respond with any WWW-Authenticate value whatsoever  
or only HTTP-GSS?
	- Can the server assume from the empty Authorization header that the  
client supports HTTP-GSS?  What about assuming support other mechanisms?
	- How would a GUI client (browser or rich client) know whether to  
present a "Login" button?  Imagine a client browsing a publicly- 
readable archive in HTML or WebDAV -- with anonymous read requests,  
the may see all kinds of documents.  Yet if the client can  
authenticate and get more permissions, the client might see new stuff  
(e.g. additional documents, links to edit documents, or with WebDAV  
see write permission available on ACL queries and know to enable  
"upload" and "change" UIs in response).
	- What method would the empty Authorization header go on? Any? Only  
GET? MUST the server handle it or can it ignore?

> http://www.ietf.org/internet-drafts/draft-johansson-http-tls-cb-00.txt

14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Note that these drafts are not =
intended for inclusion in the kitten</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">charter =
at</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; ">this or any future time. They are only =
presented to this list for review</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">by =
gss</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">experts.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">By way =
of background this draft (and the related draft describing =
channel</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">bindings for http+tls) describes =
a successor (but not update) to<SPAN class=3D"Apple-converted-space">=A0 =
</SPAN>the<SPAN class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">negotiate</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">http auth =
mech which hopes to solve some of the drawbacks of this</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">mechanism.</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">The orginal =
motivation for this work was requirements from the calcify</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">wg who</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">expressed the =
need for a better authentication mechanism (than plain</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">passwords)</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">for =
applications using http as a transport but not using a browser as =
a</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; ">client.</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Please note that this is a 00 =
version and new versions with</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">modifications =
based</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">on discussions from yesterday =
are forthcoming.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><A =
href=3D"http://www.ietf.org/internet-drafts/draft-johansson-http-gss-00.tx=
t">http://www.ietf.org/internet-drafts/draft-johansson-http-gss-00.txt</A>=
</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; "><A =
href=3D"http://www.ietf.org/internet-drafts/draft-johansson-http-tls-cb-00=
.txt">http://www.ietf.org/internet-drafts/draft-johansson-http-tls-cb-00.t=
xt</A></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><SPAN class=3D"Apple-converted-space">=A0=A0 =A0 =A0 =
</SPAN>Cheers Leif</DIV> </BLOCKQUOTE></DIV><BR></BODY></HTML>=

--Apple-Mail-11-367629644--

---

From: Lisa Dusseault <[email-masked]>
Date: Sun, 12 Nov 2006 11:36:21 -0800

Tim,

Most of the history of why the HTTP-SASL draft died in IETF last call  
in 2004 can be found in the IETF I-D Tracker.  Look for "more detail"  
links under comments from Eric Rescorla, Joe Orton, Roy Fielding and  
myself.   I believe this link will work: https://datatracker.ietf.org/ 
public/pidtracker.cgi?command=view_id&dTag=6611&rfc_flag=0

We followed this up with conversations over lunch in person with  
Alexey Melnikov, Sam and others, also back in 2004, and concluded  
that the group at hand couldn't at that time think up an architecture  
that would tie SASL to HTTP without breaking intermediaries.

HTTP proxies, connections and state interact in a very complicated  
way and there is a great deal of "deployed reality" in addition to  
the specs.  I consider myself an HTTP expert yet I find it very  
difficult to be confident when this kind of thing will really work  
(you can see this from my comments in the I-D tracker from 2004,  
where I caught some issues but missed several even deeper  
architectural issues).  For example, today when a client request with  
an Authorization header resul="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============1763322061==--

---

From: Lisa Dusseault <[email-masked]>
Date: Sun, 12 Nov 2006 11:36:21 -0800

Tim,

HTTP proxies, connections and state interact in a very complicated  
way and there is a great deal of "deployed reality" in addition to  
the specs.  I consider myself an HTTP expert yet I find it very  
difficult to be confident when this kind of thing will really work  
(you can see this from my comments in the I-D tracker from 2004,  
where I caught some issues but missed several even deeper  
architectural issues).  For example, today when a client request with  
an Authorization header results in a 401 Unauthorized response, it  
means game over.  Are there deployed caches or firewalls or client  
libraries that make that assumption and depend on it ( which would be  
untrue for at least one interchange in every use of HTTP-GSS)?  I  
would hope not, but experience with deployed HTTP reality has led me  
to conclude that it's a festering minefield (how's that for mixed  
metaphors) of unwarranted assumptions and implementation-by-imitation.

Lisa

On Nov 9, 2006, at 3:26 PM, RL 'Bob' Morgan wrote:

>> support channel bindings, partially because channel bindings have  
>> been a notoriously difficult problem to get right in SASL space.  
>> Personally I din't see the value of adding the extra layer of glue.
>>
>>    Cheers Leif
>>
>>

ts in a 401 Unauthorized response, it  
means game over.  Are there deployed caches or firewalls or client  
libraries that make that assumption and depend on it ( which would be  
untrue for at least one interchange in every use of HTTP-GSS)?  I  
would hope not, but experience with deployed HTTP reality has led me  
to conclude that it's a festering minefield (how's that for mixed  
metaphors) of unwarranted assumptions and implementation-by-imitation.

Lisa

On Nov 9, 2006, at 3:26 PM, RL 'Bob' Morgan wrote:

>> support channel bindings, partially because channel bindings have  
>> been a notoriously difficult problem to get right in SASL space.  
>> Personally I din't see the value of adding the extra layer of glue.
>>
>>    Cheers Leif
>>
>>

---

From: Leif Johansson <[email-masked]>
Date: Mon, 13 Nov 2006 21:24:42 +0100

Lisa Dusseault wrote:
> passing GSS tokens resulting from various API calls, and not how these
> tokens can be used to recover state, or what other state the server
> must store to put all this together, and how long the server must
> store that.  For HTTP server farms and non-persistent connection
Noted.
> about a variance for a downref for RFC4559, for various reasons we can
> discuss if it's not obvious or others disagree.
>
The intent is only to use RFC4559 as a non-normative reference. The
specification shouldn't contain any
normative references on RFC4559 but I would like to include the
non-normative reference both as help
for implementors and to explain what the historical basis for this
specification is.
> - Add a swimlane diagram showing client requests and server responses
> and what GSS stuff goes in each.
That will certainly increase readability.
> guaranteed to be a complete list of issues).
I have gotten similar feedback from other reviewers too.
> result from a call to gss_foo_bar.  This may be an un-GSS way of doing
> things :)
I was looking for a better way to write this. This sounds like a win and
I don't think it is very un-GSS at all.
> says "This process continues until either an error occurs or the
> GSS-API layer has successfully completed...").
>
That may be more difficult. In practice there are few situations where
more than (say) 5 roundtrips are
ever needed and in many cases 1 or 2 are enough but in general GSS have
few hard limits. The same
question came up during the discussion of GSS-TLS on friday. I don't
have a good answer to this at
this time.
> Lisa
>
> /Open questions on client initiating HTTP Authentication/
> - May the server respond with any WWW-Authenticate value whatsoever or
> only HTTP-GSS?
If I understand these questions correctly I believe they will be
alleviated by following Cyrus Daboos suggestion to
use the attribute=value-pair ABNF which RFC4559 decided not to use for
some reason. I.e "GSS challenge=<> "
instead of "GSS <>".
> present a "Login" button?  Imagine a client browsing a
> publicly-readable archive in HTML or WebDAV -- with anonymous read
> requests, the may see all kinds of documents.  Yet if the client can
How does a client ever know that?
> GET? MUST the server handle it or can it ignore?

Again I wonder if this problem goes away with better ABNF...

       Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Mon, 13 Nov 2006 21:54:04 +0100

<snip>
>
> Some of these need English text.  An ABNF telling me that the
> WWW-Authenticate header can contain "GSS challenge=<>" doesn't
> actually guarantee that the server sending such a header supports GSS
> although I think that is a reasonable inference. :)  I think it's
> really text elsewhere which talks about *empty* headers, and it's not
> clear what the empty Authorization header means.  Does it mean "I want
> to authenticate but I'm not telling you anything about which
> authentication mechanisms I might support"?  Does it mean "I want to
> authenticate and by the way I support GSS"? 
>
The former of course! There is no sense in putting any authentication
mechanism before the others at this point :-)

I'd say you raise a good point - the question of how to do negotiation
of authentication mechanism in HTTP is
perhaps too big a bite for this specification, especially since there
are all the issues involving downgrade attacks
etc. For the purpose of HTTP-GSS possibly all I need is that the client
can initiate authentication when it knows
that the server supports it and wants to do a handle-based fast reauth.

This is all tied in with channel-bindings which imo makes it unlikely
that the client will want to initiate auth in the
general case since the first "please authenticate" challenge from the
server will also serve to establish cb to the
underlying tls if one exists.

          Cheers Leif

---

From: Martin Rex <[email-masked]>
Date: Tue, 14 Nov 2006 01:07:10 +0100 (MET)

RL 'Bob' Morgan wrote:
> persistent connections are used, which is a showstopper.

Microsoft's implementation (rfc4559) also support only persistent
connections.  The request-reply is basically half-duplex until
the security context is established, and after that it becomes
regular HTTP/1.1 connection: keep-alive.  In none of the successive
requests on the persistent channel is it visible that there was
a GSS-API based authentication in the beginning.

Every new communication channel requires a new gss/spnego
authentication handhshake.

A gss-api based authentication is fairly expensive and requires
at least two tokens (under spnego), so a full authentication of
every request would be prohibitively expensive.

On the server-side, binding the lifetime of the gssapi security
context to the socket of the persistent connection is IMHO quite
sensible.

There is a certain problem of such a communication scheme with
reverse proxies, ssl accellerators and load balancers, which may have
difficulties providing persistent connections.
"Request pooling/aggregation" between the (server-side) middle-box
and the backend might be difficult.

> Hence the 

I don't really understand what you mean by that, but it really doesn't
sound right.

Channel bindings are IMHO a broken concept (I know Nico doesn't agree,
because his CCM mechanism desperately needs them).  (Traditional)
channel bindings break many architectures in a horrible fashion because
they link characteristics from entirely seperate communication layers
and fail with the addition of the first middle-box to the communication
path (proxy,app-level gateway,firewall).

A much better approach to "forking" sessions that were authenticated
in rfc4559-style is that the application issues a (cryptgraphically strong)
session re-authentication token which the client needs to re-send with
*every* new request.

The existing rfc4559 with SPNEGO&Kerberos uses a 2-token security
context establishment, so if the application issues a session
re-authentication token which the client adds to every request,
then this scheme works even with servers-side reverse proxies
and load-balancers that pool&aggregate requests over a small
number of connections between the middle-box and the backend.

Traditional Web-Browsers have only limited functionality to replicate
session authentication tokens in successor requests.
 - basic authentication credentials
 - cookies
however only cookies can be set on request of the server.

It would have been a good idea to have the browser replicate
a server-issued (crypgraphically strong) token on a www-authenticate:
header field for every successive request after a gss/spnego handshake,
but it appears the designers of the rfc4559 authentication scheme forgot to
specify this, so right now, the use of non-persistent cookies and
a preference or requirement of an SSL/TLS protected communication channel
is probably the most portable design approach (with the least impact
on the creative features of middle-boxes).  If reverse proxies with
load balacing to the backend are involved, the session re-authentication
token must contain enough plaintext information for the reverse proxy
to find the backend server that created this session for repeated
or new network connections.

-Martin

---

From: Michael B Allen <[email-masked]>
Date: Mon, 13 Nov 2006 22:02:41 -0500

On Tue, 14 Nov 2006 01:07:10 +0100 (MET)

> every request would be prohibitively expensive.

SPNEGO sites currently authenticate every request and I don't recall
people complaining that much (unless perhaps NTLM is getting in the way).

Mike

-- 
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/

---

From: Leif Johansson <[email-masked]>
Date: Tue, 14 Nov 2006 13:36:21 +0100

Martin Rex wrote:

<snip>
> I don't really understand what you mean by that, but it really doesn't
Maybe the next revision will be more clear on this point.
> Channel bindings are IMHO a broken concept (I know Nico doesn't agree,
Nor do I.
> session re-authentication token which the client needs to re-send with
This is essentially what http-gss specifies! I wanted to avoid explicit
dependencies on GSS-API
for the context identifiers, which is why I only mentioned
gss_export_sec_context in an implementation
note at the end. I can think of several ways in which a server-farm
(say) could maintain state in
such a way that a random token would be the preferred way communicate
state over a cryptographic
token.

> number of connections between the middle-box and the backend.
But this doesn't work for all GSS-API mechanisms which is the goal. I'm
not interested in
a solution which only provides support for a single kerberos GSS-API
mechanism.

          Cheers Leif

---

From: Martin Rex <[email-masked]>
Date: Tue, 14 Nov 2006 15:05:49 +0100 (MET)

> people complaining that much (unless perhaps NTLM is getting in the way).

When I checked the headers of the requests with HTTPwatch when
using negotiate between MSIE 6 and IIS, then the authentication
exchange (and www-authenticate headers) were only visible on
the first request of a new connection.

About the performance impact:  there is a lot of code out there
in "productive" environments which is a real performance killer,
especially Apache in reverse-proxy scenarios (doesn't implement
client-side SSL session caching, can not do request aggregation,
fragments request headers like crazy).

-Martin

---

From: Leif Johansson <[email-masked]>
Date: Tue, 14 Nov 2006 15:17:59 +0100

> fragments request headers like crazy).
I have to agree with Martin here - just because its been deployed
doesn't mean it can't
be improved upon.

       Cheers Leif

---

From: Michael B Allen <[email-masked]>
Date: Tue, 14 Nov 2006 12:13:58 -0500

On Tue, 14 Nov 2006 15:05:49 +0100 (MET)

> the first request of a new connection.

That's not what I see with IIS on Windows 2003 SBS. At no time does the
client get a response without the request having a Negotiate token. I
still have the capture if you'd like to see it.

> fragments request headers like crazy).

I'm not advocating authenticating every request. I'm just trying to help
out with the facts of the case which is that in at least my case every
request is authenticated which suggests that "prohibitively expensive"
is misleading. GSSAPI acceptor authentication is not *that* expensive
since there's no network communication involved (provided the acceptor
has loaded it's credential already).

It would be nice to curb redundant authentications but you do realize it
could be tricky on top of HTTP. You're talking about associating state
with a socket when most HTTP server implementations, Servlet containers,
PHP scripts, etc only give you a *session* which is more abstract
and not directly mapped to the client's socket. You would have to get
the local port and put state in a map.

Note that if you have to put state in a map by port you could do that
now with Negotiate auth so it's not clear to me what benifit this new
mechanism would provide wrt redundant authentications.

Mike

-- 
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/

---

From: Martin Rex <[email-masked]>
Date: Tue, 14 Nov 2006 20:47:52 +0100 (MET)

> still have the capture if you'd like to see it.

I just retried -- my logs contain a single negotiate handshake in
the beginning (the html page), and everything else (all seperate
objects embedded in the page) are without, definitely!

In my case, the session was using SSL/TLS (properties says SSLv3 128-bit RC4).

> has loaded it's credential already).

When public key crypto is involved in the authentication, then the
performance impact is significant, similar to SSL full handshake vs.
SSL session resume from the cache.

On my machine, SSL session resume from the cache (entire resume handshake)
is 3 millisec, whereas the full SSL handshake is ~40 milliseconds.  On
slower machines (e.g. Unix RISC machines), the difference that I measure
is even higher.

An order of a magnitude is what *I* consider prohibitive.

> mechanism would provide wrt redundant authentications.

As soon as you have to keep state on the backend, it is fairly easy
to create&use a session token that can be used for session re-authentication.

The server creates and issues that session re-authentication token,
so can make this token useful in many respects.

Look at the SSL session ID issued by an SSL/TLS server.  OpenSSL is
pretty dumb when creating SSL session IDs.  An SSL session ID is
32 Bytes long, so when the server creates a session ID, it might
be a good idea to make the session ID useful:

   - fill >=16 bytes with a cryptographically strong random number
     so that attackers can not guess SSL session IDs

   - use >= 8 bytes for a monotonically increasing integer so
     that (a) there will never be collisions on SSL session IDs
     and  (b) you get near-perfect hash values for 2^n hash lookup tables
              for free

and as a result, the server may become more efficient in SSL session
cache management by not having to perform a hash function and
not having to check the cache for a collision when creating a new
session ID. (This only applies to the server-side cache and session ID,
of course).

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 14 Nov 2006 20:57:45 +0100 (MET)

> has loaded it's credential already).

The other issue that one should not forget: A lot of user authentication
systems have some kind of account lockout functionality, so the
combination of "authenticate every request" with "immediate pipelining
of 10 requests" may have quite negative consequences when there's
something wrong with the credentials (typo in password).  NTLM
is password-based, IAKERB might be, and so may be others.

-Martin

---

From: Michael B Allen <[email-masked]>
Date: Tue, 14 Nov 2006 17:15:02 -0500

On Tue, 14 Nov 2006 20:47:52 +0100 (MET)

> An order of a magnitude is what *I* consider prohibitive.

Ok, well we're not talking about SSL. We're talking about decrypting
a token with a symmetric cipher. The extra round trip HTTP clients go
through to determine that the server wants auth in the first place takes
an order of magnitude longer than decypting a Kerberos ticket.

> to create&use a session token that can be used for session re-authentication.

There's one major problem with using sessions to store authentication
data. You're assuming that the data is valid in all processes sharing the
session. There can be multiple processes on different servers. Clusers
for example may try to serialize sessions which would invalidate things
like Kerberos tickets. Browsers frequently open multiple sockets that
will share a session but not the same httpd worker process.

Stateful authentication over HTTP is tricky buisness. Basically you
have to assume a default posture of failure. Meaning if ANYTHING is
not optimal for state to be valid just return 401 and make the client
reauthenticate. If the token is deserialized on a different node, 401. If
the client doesn't submit a token and there's no session token, 401. If
the session token is old, 401. If you get a pipeline of unauthenticated
requests, 401 every one of them.

Mike

-- 
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/

---

From: Michael B Allen <[email-masked]>
Date: Tue, 14 Nov 2006 17:23:17 -0500

On Tue, 14 Nov 2006 20:57:45 +0100 (MET)

> is password-based, IAKERB might be, and so may be others.

Oh yes, I know about this very well from doing the JCIFS NTLM Servlet
Filter. NTLM requires a stateful exchange which means you MUST use the
session in which case you can trap and dispose of redundant authentication
attempts good or bad.

Of course Kerberos doesn't have this problem.

Mike

-- 
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/

---

From: Martin Rex <[email-masked]>
Date: Wed, 15 Nov 2006 01:12:46 +0100 (MET)

> an order of magnitude longer than decypting a Kerberos ticket.

I'm sorry, I thought we were also talking about how the IETF would use
SPNEGO to negotiate gss-api mechanisms, and that would include mechanisms
using X.509 certificates for authentication.

> will share a session but not the same httpd worker process.

Well, no, I'm not making any assumptions.

Installations where the backend state is so tiny that moving it
around between different backend servers is an option scale nowhere.
A scheme that might get used here to "share" an authentication
within a server farm might be a keyed hash, like HMAC, that covers
a shared secret in the server farm to reauthenticate user sessions.

The server farms that I'm dealing with produce backend state in
the megabyte range, and you don't want to move that around with
every little gif icon on every of your pages among backend servers.

Moving the state might be an issue for high-availability scenarios,
but again, you wouldn't move it around for no reason, and a
re-authentication requirement in case of a move would be OK.

> requests, 401 every one of them.

This is why I'm OK with 2-token Kerberos authentication with rfc4559.  :)

If you do have backend state, but need a server farm to accomodate
the load, then you have two options, either move the state around,
or glue the sessions to the backend servers which are holding the
state.

For _very_ lightweight sessions, the first approach may be OK, 
although it puts a significant burden on the apps in that they have
to completely serialize there state for transfer to other servers.
For heavyweight state sessions, this option simply doesn't exist.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 15 Nov 2006 21:57:33 +0100 (MET)

Open mouth, insert foot...

Michael, you were right in some way about negotiate re-doing authentication
all the time.

> In my case, the session was using SSL/TLS (properties says SSLv3 128-bit RC4).

Well, I did try, but with an IIS that was configured by our local
microsoft experts quite a long time ago and later upgraded (now W2K3 Server).

That particular IIS (to which I don't have adminstrative access)
returns 401 www-authenticate: for both negotiate and ntlm on HTTP:1080,
and my MSIE 6.0 performs negotiate (Kerberos).  As a result I
get back a redirect to the same machine, but https:// (aka port 443)
and trying to get that page results in a 401 www-authenticate for
NTLM only, to which my browser agrees and then all remaining embedded
objects of this servers homepage (50 objects: .js/.css/.jpg/.gif/.wmf/.htc)
are loaded with only one additional 401 -- and that happens at the
beginning of a secondary communication channel (new local port)
according to HTTPwatch.

I just tried to confirm my findings with negotiate/Kerberos instead
of NTLM on a WinXP 64-bit machine that which I can administrate.

Negotiate/Kerberos was fairly easy to activate, but the resulting
HTTPwatch logs were devastating!  It appears that MSIE does blind
pipelining (ouch!) of requests for the embedded object, and IIS forces
reauthentication of every single request with a 401 (ouch ouch!).

It seems that MSIE is not expecting IIS to misbehave in such a stupid
fashion, because MSIE does _not_ send the negotiate token unless the
server asks for it with 401 (which it does, each and every time).

I'm really confused by what I see.
For the NTLM-authentication, the IIS server seems to be holding the state
(and the impersonation token) as long as the network connection persists,
while for negotiate/kerberos, this doesn't work.
MSIE does not seem to expect this.  So when using negotiate/kerberos
with HTTPS, one does not only get the overhead of a full gssapi context
establishment for each and every single object, but also the 401&retry
exchange.  The additional roundtrips hit on the performance, and
the additional gssapi tokens consume network bandwidth.

Here is the result comparing the overhead when retrieving a 216 byte gif:

  NTLM-authenication MSIE6->IIS6:
   request             reply
   GET (315 bytes)     200 (465 bytes)

  Negotiate/Kerberos authentication MSIE6->IIS6:
   GET (315 bytes)     401 (1872 bytes)
   GET (4070 bytes)    200 (715 bytes)

So the performance hit that the server takes by using negotiate/Kerberos
instead of NTLM is: 1 additional network roundtrip, 10x increase in
the total request size, 5x increase in the total reply size,
plus the entire GSS-API processing overhead.

Somehow, this doesn't look like good engineering to me.

At least, rfc4559 doesn't seem to require implementing this in such
an inefficient fashion.

-Martin

---

From: Michael B Allen <[email-masked]>
Date: Wed, 15 Nov 2006 16:46:35 -0500

On Wed, 15 Nov 2006 21:57:33 +0100 (MET)

> while for negotiate/kerberos, this doesn't work.

Interesting. I thought IIS re-auth'd every request for NTLM too but I've
confirmed your findings - IIS does cache NTLM authentications per socket.

All of this is probably deliberate though. Consider the difference
in overhead.

Negotiate/Kerberos:
  Two round trips between the same nodes and a ticket decryption. That's
  not that bad.

NTLM/NTLMSSP or Negotiate/NTLMSSP:
  Three round trips and a DCERPC over SMB named pipe password check
  with the domain controller which is a different node probably on an
  entirely different subnet.

So authenticating every request with NTLM is indeed "prohibitively
expensive" whereas I would say the Negotiate/Kerberos case is not
(people do it all the time).

Also, NTLM doesn't support delegation and doesn't contain authorization
data so storing NTLM state in the HTTP session doesn't have some
of the issues that Kerberos would. Actually the results of an NTLM
authentication is pretty much useless (you don't even have a signing
key if you're doing pass-through style auth like JCIFS) so there's no
point in saving anything at all - you just associate "authenticated=true"
with the socket (or I guess the session) or something that just indicates
the client was already authenticated.

I still think the best performance improvement would be acquired on
the client side. When a client (e.g. Firefox) encounters a server that
requires authentication, it set's a flag associated with that socket
(I think IE uses the hostname/port or IP/port for HTTP POST request
preemption I mentioned yesterday) indicating that subsequent requests
should preemptively include an initial token. If the server responds
200 OK and no WWW-Authenticate header is sent, the client can clear the
said flag and go back to assuming authentication is no required (this
is important for browsing from protected to non-protected content on the
same server). Note that even if mutual is not requested the server will
respond with a WWW-Authenticate token that is largely empty (at least
with Negotiate it does, old-school NTLM is on the rocks).

Mike

-- 
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/

---

From: Martin Rex <[email-masked]>
Date: Thu, 16 Nov 2006 01:15:45 +0100 (MET)

Michael B Allen wrote:
> expensive"

It's true that the NTLM authentication results in significantly
higher overhead on the server side because it involves a round trip
to a domain controller.

> 
>             whereas I would say the Negotiate/Kerberos case is not

I still do not agree to this.  the Kerberos overhead (and the
much larger token size) is not marginal.

> the client was already authenticated.

NTLM and Kerberos both support impersonation, which is necessary for
using the Posix-style Access Control model from the TCB instead of
doing all manually at the application level.  Impersonation is much
more than a simple flag, it might provide adminstrative privileges
to an originally very restricted service account.

NTLM doesn't provide credentials and therefore can not be used to
further authenticate to remote resources, aka. delegation.
(IIRC, delegation is available for machine-local NTLM authentication,
but that isn't a real use case for Web-Servers...).
However, delegation in Kerberos is not enabled by default (and
should never be, for security reasons).  Kerberos delegation is currently
implemented by forwarding the TGT, and the resulting initial context
token isn't exactly small.

I would like it if delegation was the default so that any fellow
developer setting up an IIS on his workstation could harvest TGTs
from every MSIE that connected, e.g. by using Outlook to send
Emails with IMG SRC urls to furnish their sig with a neat picture...

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 16 Nov 2006 15:40:37 -0600

> changes cannot be proposed to allow it to support non-persistent

The GSS-API already has a notion of exported security context.  SASL
does not.

> standards are normally progressed ?

It's who shows up and who does the work.  Attending the conferences
helps because the bandwidth between attendees goes way up as compared to
the rest of the year.  So when we had our various bar BoFs and the DIX
BoF we quickly jettisoned SASL -- noone was there to defend it from this
and other objections (e.g., lack of channel binding support[*]).  The DIX
BoF could have been attended via jabber too.

Now, you can push the HTTP-SASL thing now, and get that going.

[*]  The SASL WG is working on channel binding, but the SASL notion of
     channel binding is subtly different from the GSS-API equivalent,
     different in a way that we don't want in this case.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 16 Nov 2006 15:49:52 -0600

> of using a multi-layered architecture.

Your understanding is wrong.

First of all, there's an API issue -- which, since the IETF does not
standardize a SASL API you might hand wave away.

Second, there's a semantic issue, and this is far more important.
Rather than re-hash this here you might want to look at the SASL WG
mailing list archives and the gs2 I-D (draft-ietf-sasl-gs2) and its
evolution.  Then you'll understand why GSS channel bindings in the SASL
"GSSAPI" mechanism are generally not usable.

Third, we need channel binding to TLS to avoid re-doing the GSS (or
SASL) authentication over and over, and so what's the point of using
SASL if the only SASL mechs that would support channel binding were the
GSS-based ones (using SASL/gs2)?  And if channel binding support is
added to SASL MD5-DIGEST, with the same semantics, can't we also add a
GSS-API mechanism that uses the same credentials as MD5-DIGEST?  And why
isn't HTTP MD5-DIGEST good enough anyways?  And what other SASL
mechanisms did you want to use with this?

Nico
--

---

From: "Tim Alsop" <[email-masked]>
Date: Thu, 16 Nov 2006 22:01:10 -0000

Nico,

Thankyou for explaining the background to SASL-HTTP, and why it has died
... I hadn't seen any mention of it for a few years, but I was under the
impression (wrongly) that there was a rough concensus that SASL-HTTP was
the preferred replacement for the negotiate approach, as used in IE,
Mozilla, IIS, Apache etc. Clearly this is not the case anymore ...

I don't want you to think I have any preferrences, either way - I don't.
If anything, I prefer simpler architectures, as they are less likely to
go wrong and easier to code and debug. So, adding an extra protocol
layer, when it is not absolutely necessary, just makes the solution more
complex than is needed. Taking this into account, it seems that using
HTTP/GSS, instead of HTTP/SASL/GSS is perhaps a better replacement for
the netogitate approach. Obviously, I am over simplifying the
requirements by saying this, and there is a lot more work to be done to
progress the HTTP/GSS approach, and this might also die in the same way
as SASL-HTTP :-)

Thanks again,
Tim

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: 16 November 2006 21:41
To: Tim Alsop
Cc: RL 'Bob' Morgan; Leif Johansson; Kitten; Lisa Dusseault
Subject: Re: Please review: http gss authentication mech

and other objections (e.g., lack of channel binding support[*]).  The
DIX

Nico
--

---

From: "Tim Alsop" <[email-masked]>
Date: Thu, 16 Nov 2006 22:02:52 -0000

Nico,

Thankyou for correcting me, on my assumption related to channel
bindings.

Regards,
Tim 

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: 16 November 2006 21:50
To: Tim Alsop
Cc: Leif Johansson; Kitten; Lisa Dusseault
Subject: Re: Please review: http gss authentication mech

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 17 Nov 2006 09:54:14 -0600

> Mozilla, IIS, Apache etc. Clearly this is not the case anymore ...

It may have been that there was consensus for it in some circles...

When I have discussed HTTP authentication improvements with others SASL
has come up, but usually its problems led to us discarding it.

> I don't want you to think I have any preferrences, either way - I don't.

It's OK to have preferences!

> progress the HTTP/GSS approach, and this might also die in the same way

So, if SASL didn't have the problems we discussed, or if we had the
energy to fix them, and if the non-GSS SASL mechanisms were highly
desirable and we did not have the energy to specify/implement GSS
equivalents, then SASL would be the better solution because it would
have more mechanisms available to it than the GSS-API.

So it's quite reasonable to see HTTP-SASL as potentially better than
HTTP-GSS.  But in the end I think it's hard to conclude anything other
than that there are no SASL non-GSS mechanisms that we really want to
use in the HTTP + TLS channel binding scenario[*].  It's also easy to
conclude that it's less work to specify HTTP-GSS than to deal with the
SASL issues.

[*] Save DIGEST-MD5, and that has an HTTP binding anyways, and it's fast
    enough that maybe we don't ever care, and we can always specify a
    GSS-API mechanism based on it with little effort.

Nico
--

---

From: "Tim Alsop" <[email-masked]>
Date: Fri, 17 Nov 2006 16:08:54 -0000

Nico said>

Tim said> This makes sense. Thank you again for your explanations, to
bring me upto date on what has been happening with the HTTP-SASL draft.

Take care,
Tim

---

From: Martin Rex <[email-masked]>
Date: Fri, 17 Nov 2006 17:25:53 +0100 (MET)

> (people do it all the time).

For traditional Kerberos, the computational overhead on the server
to process an AP_REQ and create an AP_REP is "relatively" small,
because it was designed that way.

Microsoft's Kerberos SSP works a little different.  Impersonation
can be performed in two fashions, either by mapping an external
Kerberos principal name to a local account, or (the default case
when KDC is an Active Directory and the Server is also on a
Windows machine), by inclusion of a PAC in the service ticket.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnkerb/html/MSDN_PAC.asp

Now I'm a little confused under what circumstances the KDC signature
on the PAC will be verified.  Verification will likely require a
network roundtrip to a domain controller.  Absence of verification
would allow any acceptor (knowing its own key--which isn't that
unusual) to create arbitrary (local) access tokens:

Quoting from above document:

  Signatures (PAC_SERVER_CHECKSUM and PAC_PRIVSVR_CHECKSUM)

  The PAC contains two digital signatures: one using the key of the server,
  and one using the key of the KDC. The signatures are present for two
  reasons.  First, the signature with the server's key is present to
  prevent a client from generating their own PAC and sending it to the
  KDC as encrypted authorization data to be included in tickets.
  Second, the signature with the KDC's key is present to prevent
  an untrusted service from forging a ticket to itself with an invalid PAC. 

  [...]

  Security Considerations

  Before the PAC data is used for access control, the PAC_SERVER_CHECKSUM
  signature MUST be checked. This will verify that the provider of the PAC
  data knows the server's secret key.

  Validation of the PAC_PRIVSVR_CHECKSUM is OPTIONAL. It is used to verify
  that the PAC was issued from the KDC and not placed in the ticket by
  someone other than the KDC with access to the service key.

And in addition, because of the current habit of IIS6 to 401 for each
and every request, the total for the homepage of our local microsoft
experts compare like this:

   MSIE6->IIS6  with NTLM
     54 requests (50 objects, 2 sockets with 2x 401 exchanges),
     2 full NTLM authentications,
        requiring additional 2.4 KByte MSIE6->IIS6 and 8 KByte IIS6->MSIE6

   MSIE->IIS with Negotiate/Kerberos:
     100 requests (50 objects, 2 sockets, one 401 exchange for each object)
     50 full Kerberos authentications
	requiring additional 200 KByte MSIE6->IIS6 and 100 KByte IIS6->MSIE6
 
Maybe not yet "prohibitive" but undoubtedly with a significant performance
impact.  In case the KDC's signature on the PAC is verified, then
it will become quite expensive.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 17 Nov 2006 10:41:40 -0600

On Sun, Nov 12, 2006 at 11:07:03AM -0800, Lisa Dusseault wrote:
> they are in the authentication process.

It has enough information in each roundtrip that:

a) it context tokens for one security context will not get mixed up with
another (and failure will result if they do get mixed up as a result of
implementation bugs),

b) when the context is fully established the server will know who the
client is.

This is done at the GSS-API level by tracking _state_ in a security
context, which is an opaque type, both, client and server side.

To avoid server side state the server will "export" (serialize) and
encrypt the security context after processing each context token and
will send back any output context tokens and the encrypted exported
context to the client.  The client will send subsequent context tokens
and the server's encrypted context back to the server.

Rinse, repeat until the security context is fully established, at which
point, since the set of TLS channels with this client [or its proxy] and
this server [or its concentrator] is now bound to that context the
client and server can now rely on TLS to secure their session without
further GSS sec context establishments.  A cookie, or the encrypted
exported fully established security context can then be used as a
cookie-like object to identify all of a client's requests without
actually having to re-authenticate the client.

>                                          The spec only mentions  

See above.  The key is being able to export (serialize) server-side
GSS-API state.  The GSS-API appears to allow this only for fully
established security contexts, but we think it's trivial to allow it for
partially established security contexts as well.

> API layer has successfully completed...").

The limits on round-trips are given by the underlying mechanism.  The
client can't force an infinite number of round-trips for a single
security context unless the underlying GSS mechanism gives it a way to
do that (I don't know of any that do, nor do I expect any future mechs
to do that).

Do the HTTP implementations need to know a priori the min/max # of
round-trips?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 17 Nov 2006 10:56:56 -0600

> I don't think it is very un-GSS at all.

Check out some of the other RFCs and I-Ds that do this (RFC2203,
RFC2222, RFC2228, RFC3645, RFC4462, draft-ietf-sasl-gssapi,
draft-ietf-sasl-gs2).

> have a good answer to this at

There is always a finite maximum number of round-trips.  There's no API
to inquire what that would be for a given GSS mechanism (or for all
available mechanisms), but a) we could provide such an API, b) such data
could be hardcoded as a last resort.

But, why is this needed?

> How does a client ever know that?

It might know from: context, configuration, and/or, much more likely,
from application-level data sent by the server.

In the NFSv4 case, for example, the negotiation is at the application
layer (i.e., in NFSv4, not in RPC or RPCSEC_GSS), and the server may
want different mechanisms to be used for different subsets of its
filesystems.

WebDAV should probably follow that model.

And HTML too should follow it.  Meaning we need an element by which the
server can tell the client that "if the user clicks on this, then
authenticate using HTTP-GSS + channel binding to TLS."

Specification of all such app-layer bits are well beyond the scope of
Leif's I-Ds, and, in some cases (e.g., HTML), well beyond the scope of
the IETF.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 17 Nov 2006 11:02:56 -0600

> mechanism before the others at this point :-)

I'm not sure that we want to allow that, but, whatever.  The client
could always try each mechanism that it has credentials for, one by one
(even in parallel) until one works or all fail.

> of authentication mechanism in HTTP is perhaps too big a bite for this
> specification, especially since there are all the issues involving
> downgrade attacks etc. For the purpose of HTTP-GSS possibly all I need
> is that the client can initiate authentication when it knows that the
> server supports it and wants to do a handle-based fast reauth.

I think we must tackle this.  I think we can avoid the two-layer
negotiation issue without much trouble (but we must avoid it).

> underlying tls if one exists.

Indeed.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 17 Nov 2006 11:07:44 -0600

On Fri, Nov 17, 2006 at 08:51:31AM -0800, Lisa Dusseault wrote:
> On Nov 17, 2006, at 8:41 AM, Nicolas Williams wrote:
> I do not know that the implementations need to know a priori, but I  
> can tell you the implementors will be curious :)

:)

The answer is: there's always a finite max # of RTs, and there's a max
for every mechanism.  Some mechanisms may be subject to future extension
work that changes their max # of RTs, for surely this won't be an issue.

>                                                   Much of what you  
> wrote in response to my questions could be usefully added to a draft,  
> at least for the HTTP-savvy (and perhaps not-so-GSS-savvy) reader's  
> benefit.

OK.  I'll re-read Leif's I-Ds and propose introductory text for the
non-GSS-savvy.

Nico
--

---

From: Michael B Allen <[email-masked]>
Date: Fri, 17 Nov 2006 12:15:25 -0500

I suspect we're starting to bore list memebers so I think this will be
my final comment on the topic.

PAC verification does not require communication with the domain
controller.

If you want to come up with a more efficient way of doing this stuff,
great, go for it. I'm just pointing out that people use IIS's Kerberos
auth right now and don't seem to care too much about the performance
impact. We're not talking about doing this stuff over the Internet. At
my last Megacorp job everyone had Gigabit to their workstations.

Mike

On Fri, 17 Nov 2006 17:25:53 +0100 (MET)
Martin Rex <[email-masked]> wrote:

> network roundtrip to a domain controller. 

-- 
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 17 Nov 2006 15:48:58 -0600

> or new network connections.

Yes, we shan't forget that.  It's crucial for HTTP 1.0 operation.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 17 Nov 2006 16:31:05 -0600

> Maybe the next revision will be more clear on this point.

Basically we want this:

 - Use one GSS-API security context establishment to authenticate the
   initiator<->acceptor AND associate the {initiator, acceptor} pair
   with the set of ALL present and future TLS channels that the same
   client could establish with the same server.

We want that so that between this and fast TLS session resumption
(preferably w/o server-side state -- see RFC4507) we get:

 - really fast session crypto that can be offloaded to existing
   off-the-shelf concentrators

 - proxy traversal (the last client-side proxy being the TLS client)

 - minimal number of authentication exchanges (1 per-session until the
   server expires state or the client logs out[*])

Now, the magic is in identifying that set of TLS channels.

We do this by doing two things:

a) using GSS-API channel binding with the server cert as the channel
   binding data for all those TLS sessions

   and, crucially,

b) having a cookie-like opaque octet string that the client must replay
   over all HTTP w/ TLS sessions to the same server for the same
   session.  This cookie-like object is set by the server and it must be
   confidentiality protected (it's a shared secret).  It references the
   session established as a result of the GSS authentication step.

   and, crucially,

c) relying on TLS cipher suites[**] that use PK for key exchange
   (ephemeral DH key agreement or RSA key transport) + server certs, so
   that the client can always have strong role in key exchange and so
   that the server cert is always strongly bound to the session key
   exchange.

Between (a), (b) and (c) we get the goal described above.

[*]  Hmmm, if we have HTTP-level authentication that establishes
     sessions, shouldn't we have a logout operation as well?  IMO, yes.

[**] Let's never again try to have a single namespace for {key exchange,
     authentication, bulk crypto} algorithm tuples, shall we?

> > Channel bindings are IMHO a broken concept (I know Nico doesn't agree,

I believe there's a fairly large community of IETF participants
(certainly not just Leif and myself) who are interested in channel
binding in general, with various specific purposes.  A topic for another
thread, to be sure, and, IMO, an unnecessary discussion at this point,

> > path (proxy,app-level gateway,firewall).

Martin,

First, the whole point of channel binding *is* to eliminate MITMs.

Second, in this particular case we are doing our utmost to accomodate
middle boxes, specifically proxies and concentrators, and we manage it
because HTTP is not quite like other protocols in that it is
sufficiently aware of proxies, and because the common TLS use scenario
has anonymous clients and servers authenticated by certificates.

You might ask if the second point isn't in conflict with the first.  In
fact, it is not.  That's because in the HTTP w/ proxies world the MITMs
that we would consider attackers are those that would come between the
client's last proxy and the server's concentrator.

We leave the matter of protecting client<->trusted-proxy and
concentrator<->server communications mostly out of scope, dealing only
with the matter of how the client authenticates its proxies so that
MITMs can't pretend to be one of the client's proxies.

So, as you can see, Leif's proposal breaks nothing in the sense that you
described.  The result should be a protocol that has all of these
characteristics:

 - is based on HTTP 1.0 (thus no need for persistent connections)
 - is based on TLS 1.0

 - works with HTTP 1.1 and TLS 1.1, taking advantage of TLS 1.1
   features, specifically fast session re-establishment w/o server-side
   state (RFC4507)

 - supports environments where client proxies want to see app data
 - supports TLS concentrators

 - is pluggable w.r.t. authentication (through the GSS-API)

 - it relies mostly on off-the-shelf technology, requiring changes ONLY
   to clients' last proxies, clients and servers, but not to all other
   proxies and concentrators

 - has fast connection re-establishement

 - is secure in the stated threat model, namely: active and passive
   attackers between the client's last proxy and the server's
   concentrator

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Sat, 18 Nov 2006 16:12:52 +0100

> OK.  I'll re-read Leif's I-Ds and propose introductory text for the
Thanks Nico. That will be appreciated.

    Cheers Leif

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 20 Nov 2006 14:02:55 -0600

> > OK.  I'll re-read Leif's I-Ds and propose introductory text for the

Actually, I think draft-johansson-http-gss-00.txt mostly already has
the necessary text, but it needs to be promoted to higher-level sections
where it will be most visible.  E.g., the second paragraph of section
3.2 says most of what needs to be said, but a more concise version of it
should be in section 3.

The intro should say boldly that the new authentication mechanism does
NOT require use of HTTP/1.1, much less persistent connections.

Section 3, add:

+   HTTP/1.1 persistent connections are not required in spite of the
+   possibility of multi-round-trip GSS-API context token exchanges.
+
+   Instead GSS-API context token exchanges are threaded through the use
+   of an opaque, server-issued token.  This token MAY be an encrypted
+   representation of server-side GSS-API state to support authentication
+   without server state.
+
+   Multiple HTTP with TLS channels are be tied into a single session
+   between the same client and server by using the same mechanism.
+
+   Readers who are not familiar with the GSS-API are referred to
+   RFC2743, particularly section 2.2 (Context-level calls), which
+   describes the functions and high-level protocol used in establishing
+   GSS-API security contexts.

I think we need a very concise description of what we're shooting for.
My suggestion:

    pluggable authentication for HTTP bound to a set of HTTP+TLS
    channels, and with trusted proxy traversal

(is that concise enough?).

Perhaps we could use this in the abstract of draft-johansson-http-tls-cb:

 Abstract
 
    This document specifies a channel concept for HTTP with TLS and a
    representation of that channel which can be used by protocols which
    use channel bindings to delegate session protection to lower layers.
+   Support for trusted proxy traversal is included.
+
+   A related document specifies a pluggable authentication system for
+   HTTP that uses this channel binding construction to bind individual
+   authentication exchanges to the set of current and future HTTP with
+   TLS channels that the same client may establish with the same
+   server.

Section 1 ("Terminology" -- the rfc2119 language) should be made a
sub-section of the Introduction in both I-Ds, or you should tell xml2rfc
to not insert a page break at the end of top-level sections.

The introduction in draft-johansson-http-tls-cb should be updated to
clarify that the channel binding construction described in this I-D can
be used to bind authentication not merely to one channel but to a set of
channels all of which have the same channel binding.

draft-williams-on-channel-binding-00 describes "end-point channel
bindings" which is the type of channel binding that
draft-johansson-http-tls-cb defines for HTTP+TLS.  You may want to
reference draft-williams-on-channel-binding.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 23 Nov 2006 21:44:07 +0100 (MET)

> +   representation of server-side GSS-API state to support authentication

This appears to be going entirely into the wrong direction (IMHO).

GSS-API is designed as an abstraction accross multiple independent
but interoperable gssapi mechanisms, and this approach is making
a large number of flawed assumptions.

The existing specification of "security context export/import" in
GSS-API does *NOT* support this:

  - security context export/import is only available for fully
    established security contexts

  - security context tokens are entirely implementation-defined
    and will, in general, *NOT* be importable on another machine of
    the same kind (same CPU,OS-Release,same gssapi mechanism implementation),
    let alone servers with different architectures (different OS types,
    different CPUs, word-sizes, byte order, and code-pages/locales).

  - security context tokens are NOT standardized and a MIT Kerberos 5
    will probably not interoperate with Microsoft SSP on exported
    security context information.
    
That doesn't mean that it can not be done for extremely constrained
and well-defined scenarios/setups.  But it is not possible to standardize
behaviour here that is generic in any sense of the word (as how generic
is used in GSS-API).

Besides, trying hard to avoid having to keep backend state on the backend
is first of all a pure academic challenge.  It provides no benefit for the
majority of realworld scenarios.  And in order to make it work,
the entire application stack must be able to support the same approach,
and the continous transfer of the (protected) state of the entire
software stack has a severe impact on the communication bandwidth and
on the processing time for each request, as well as severe constraints
on how extremely homogeneous the backend server farm must be.

Persistent connections and keeping application state on the backend
make life so much easier for application design, and the performance
benefit (CPU-time and communication time) are significant (factors
to magnitudes), depending on the complexity of the application
(static vs. dynamic content) and the amount of (accumulated)
state on the backend and the amount of "uncommitted" changes to
persistent storage of the backend.  Consistency checks between
serialized state and state of the persitent storage as well
as timeout-handling (pending changes, optimistic locks, etc.)
are also much more complicated.  And then you have to deal
with "replay" attacks and distinguishing them from cloned
browser windows, and at some point you realize that stateless
backend is a myth except for dumb static fileserver or pocket calulator
type of applications.

I also have the feeling that the problems of TLS channel bindings
are underestimated.  It is more important to ensure that TLS/SSL-terminating
server-side proxies/loadbalancers have sufficient information to
allow route various indepented SSL/TLS communication channels
(with independent SSL session IDs) to the correct backend server
that is holding the state for the associated application-level session.

How many different SSL/TLS sessions get used during the course of
a single application-level session depends on many different factors.

And how about rollover of the SSL Server cert while the server is up
and there are several thousand active application sessions?

Unless an invalid server cert is installed, the application level
sessions should NOT be harmed.  The SSL/TLS session will need to
be re-negotiated (i.e. every SSL handshake will result in a new
full handshake), but the application-level authentication and
session ought to go unharmed by this.  I certainly wouldn't like
TLS channel bindings to interfere.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 27 Nov 2006 11:04:05 -0600

> This appears to be going entirely into the wrong direction (IMHO).

So you've said.

>     established security contexts

That's OK because: a) this does not prevent GSS implementations from
supporting this as an extension, b) we can add that extension to the
KITTEN WG charter, c) without this functionality the TLS server simply
needs to keep more state, d) the draft in question already explains this
(in fact, it mentions exported security contexts only in a non-normative
implementation note).  We want a protocol that does not fundamentally
require the server to keep state; the normative GSS-API reference does
not preclude this.

>   - security context tokens are entirely implementation-defined
      ^
      exported

>     different CPUs, word-sizes, byte order, and code-pages/locales).

That's not an issue here.

>   - security context tokens are NOT standardized and a MIT Kerberos 5
      ^
      exported

>     security context information.

See above.

> behaviour here that is generic in any sense of the word (as how generic

The draft we're talking about does not require this functionality.

Nico
--