Subject: statless servers, pushing exported (proto)context to clients

From: Martin Rex <[email-masked]>
Date: Wed, 25 Jul 2007 22:32:45 +0200 (MEST)

Based on the discussion during the Kitten WG session at IETF 69 today
here's another thought about potential problems.

(Wasn't NTLM authentication with rfc-4559 mentioned as an example?)

I see a problem with challenge-response style gssapi mechanisms such
as NTLM to support export of incomplete security contexts because
of the challenge.  Will a receiver of an exported security context
have to accept whatever challenge is in the exported context token?

How does it protect against replay? (a copy of the captured
session could be replayed against every allowed receiver of 
the exported security context token.) 

In the existing implementation, Microsoft's NTLM authentication
protocol appears to have a (local) replay cache for challenges,
because it limits the lifetime of the proto-security-context
to two minutes (IIRC, this is actually visible from
the lifetime output parameter of SSPI's AcceptSecurityContext).

-Martin

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

---

From: Leif Johansson <[email-masked]>
Date: Wed, 25 Jul 2007 22:43:34 +0200

> the exported security context token.) 
Off the top of my head a replay cache seems problematic
since I believe it will be roughly equivalent to maintaining
server-side state.

It would be better to bind the exported state to the
channel over which it will be sent because this is the
intended usecase but I haven't thought this through
enough.

    Cheers Leif

---

From: Nico <[email-masked]>
Date: Wed, 25 Jul 2007 15:50:13 -0500

> since I believe it will be roughly equivalent to maintaining

If there's a cluster involved then you have this problem no matter what.
If not then there is no problem.

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Wed, 25 Jul 2007 22:55:33 +0200

> If not then there is no problem.
What about binding to the client (assuming that is possible)?

---

From: Nico <[email-masked]>
Date: Wed, 25 Jul 2007 16:00:50 -0500

I should add that clustering replay caches can be done, but high
performance clustered replay caches are non-trivial to design and
implement.

This only comes up here because the context of Leif's HTTP+GSS I-D
involves the possibility of Kerberos, concentrators and clusters.  But
the same issue comes up in other contexts.

There is, however, a very neat solution: don't replay cache!  Which we
can get away with if we use a service name distinct from ones used in
the past and if the "cookie" sent to the client is sent in a wrap token.

Nico
--

---

From: Nico <[email-masked]>
Date: Wed, 25 Jul 2007 16:06:43 -0500

We can always just add another round-trip if needed to avoid the need to
have a replay cache.  Again, we need a separate service name so we know
we can safely turn the replay cache off.