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

From: Martin Rex <[email-masked]>
Date: Mon, 30 Jul 2007 21:22:04 +0200 (MEST)

Michael B Allen wrote:
> 
> On Wed, 25 Jul 2007 22:32:45 +0200 (MEST)
> Martin Rex <[email-masked]> wrote:
> 
> > 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).
> 
> I've done a lot of NTLM and I've never seen a problem using an old
> challenge.

What do you mean by that?

> 
> Then again I'm not sure I understand the whole reply cache thing in the
> context of NTLM since the challenge is specific to a TCP connection.

The challenge in a challenge-repsonse protocol like NTLM serves
the purpose to turn a shared-secret authentication into a
non-disclosing authentication, so that a passive observer of the
communication can not re-use what he sees on the network to
impersonate the client.

In order to achieve that, challenges ought to be (globally) unique
and a server ought to make sure that responses that it receives
are matching to outstanding challenges the server has previously
issued and not yet received a response for.

Transfering a partially established security context from a
challenge response authentication where the server has sent
the challenge and is wating for the response is therefore
not easily possible.  *I* would not attempt to go statless
in this situation, as I can not think of an easy way to
solve the replay attack vulnerability.  

Forcing the client to keep track of the (backend) state of a
session seems like an idea with an extemely small an limited
environment.  Personally, I think it is entirey insignificant.

Sending the session state back and forth requires a serious
amount of bandwidth.  Securing and verifying the state on
the server additonal CPU overhead.

Normally, the cheapest storage space is available on the
server, network bandwidth and storage space on the clients
are usually much more expensive.

If the backend state is large several 10 KBytes to several
MBytes of memory, sending the state back and forth with
every request becomes entirely insane.

If the state is lightweight, serializing and storing it on
some mass-storage on the server side (with a lifetime after
which it will get forgotten) is something that servers
have been successfully doing for more than a decade
(with backend state far into the multi-MBytes).

So the only scenario where this could make any sense at all
is a thin server, a fat client, many users and little server-side
storage but NO server-CPU and NO bandwith issues.

I have serious difficulties to think of such a usage scenario.
an MIT Kerberos KDC might be one of those.
But adding a Web Interface to the KDC is likely to become
a source for regular vulerability reports...

-Martin

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

---

From: Michael B Allen <[email-masked]>
Date: Mon, 30 Jul 2007 16:35:04 -0400

On Mon, 30 Jul 2007 21:22:04 +0200 (MEST)

> issued and not yet received a response for.

Hey Martin,

Still ignorant here.

Anyway, the reason I chimed in is because I maintain the JCIFS NTLM
HTTP authentication Filter. The way it works is the first request for
authentication opens a TCP connection and creates an "SmbTransport"
object which has a challenge associated with it. It then proceeds to
authenticate all users by multiplexing NTLMSSP authentications (using the
same challenge) over the same TCP connection. Web applications being what
they are there are idle periods between authentications. After several
years of supporting this solution I have never seen the challege expire
because of any limit in the lifetime of the challege. Second, if an
interloper were to attempt to use a challenge over a new TCP connection
it would not be successful (I believe I tested this once but I don't
recall). So unless you're talking about an attack that also used TCP
connection hijacking I'm not sure I understand the replay attack you
speak of.

Now, if you're talking about NTLM as defined by the OpenGroup without
regard for the TCP constraint then perhaps my observations are of no
help to you as I do not usual concern myself with anything not seen in
the wild (I'm a programmer not a pioneer).

Mike

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