Subject: [abfab] Interactions between EAP and GSS EAP state machines

From: Sam Hartman <[email-masked]>
Date: Thu, 07 Jul 2011 13:47:29 -0400

Hi.

I've always been a bit confused about RFC 3748 and protected result
indications and how that all works in practice.

I'm wondering how GSS-EAP should know when authentication has succeeded
or failed.

If I'm understanding RFC 3748 you end up sending an eap success or
failure packet even if the method supports protected result indication.
Is my understanding correct?

First, how should we handle cases where the protected result disagrees
with the failure/success message?

Secondly, we should wait for the failure/success message before deciding
whether the context is established or not?

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Jul 2011 13:46:03 -0500

> Is my understanding correct?

Looking at RFC2716 (EAP-TLS), yes, that exactly so.  I don't know how
representative EAP-TLS is, but there we have protected _failure_
notifications only, followed by an unprotected echo of it, well, IIUC.
 I don't see a protected success message...

> with the failure/success message?

If we get a shared key out of the method then GSS-EAP should probably
use it to construct its own protected success and failure messages
(which should be sent in addition to, and in parallel with the EAP
messages).

If not then GSS-EAP should use EAP as it is, with all the same exact
issues as EAP.

> whether the context is established or not?

Yes.  But the security context could be PROT_READY before that.

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Thu, 7 Jul 2011 18:48:48 +0000

> (which should be sent in addition to, and in parallel with the EAP

AFAIK we only get a shared key on success. We do send unprotected error messages at present.

I need to check the code to see if we send protected error messages in the post-EAP exchange. If we don't we probably should, this isn't too hard as that exchange is already protected anyway. Perhaps it just works :-)

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Jul 2011 14:10:04 -0500

> AFAIK we only get a shared key on success. We do send unprotected error messages at present.

It seems that with EAP-TLS you get a shared key (between the peer and
server) before success or failure is determined.  I guess that's
because success/failure hinges on authorization decisions made after
the TLS handshake succeeds.  OTOH, if the TLS handshake fails, it
fails.  This probably all depends heavily on which method we're
talking about, which is why I said "if" we get a shared key...

> I need to check the code to see if we send protected error messages in the post-EAP exchange. If we don't we probably should, this isn't too hard as that exchange is already protected anyway. Perha…

:)

Nico
--

---

From: Josh Howlett <[email-masked]>
Date: Fri, 8 Jul 2011 07:23:23 +0000

>with the failure/success message?

It was my understanding that the protected response is authoritative, and
the unprotected response is ignored. Alan?

>whether the context is established or not?

Hmm, isn't the context establishment ultimately dependent on receipt of
the MSK? The protected response is within the tunnel, the MSK is outside
the tunnel.

Josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG

---

From: Sam Hartman <[email-masked]>
Date: Fri, 08 Jul 2011 09:51:05 -0400

>>>>> "Josh" == Josh Howlett <[email-masked]> writes:

    >> with the failure/success message?

    Josh> It was my understanding that the protected response is authoritative, and
    Josh> the unprotected response is ignored. Alan?

    >> whether the context is established or not?

    Josh> Hmm, isn't the context establishment ultimately dependent on receipt of
    Josh> the MSK? The protected response is within the tunnel, the MSK is outside
    Josh> the tunnel.

What is this tunnel of which you speak?  At this layer, both passthrough
authenticators and tunnel methods are somewhat invisible to us.  That's
absolutely true on the initiator. On the acceptor, it's more complex; we
want to write guidance that works with a full or passthrough
authenticator.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 08 Jul 2011 16:54:28 +0200

> the unprotected response is ignored. Alan?

  They should match, and the unprotected response needs to be sent for
the EAP state machine to finish.  But that should be it.

  Alan DeKok.

---

From: Josh Howlett <[email-masked]>
Date: Tue, 12 Jul 2011 09:15:10 +0000

>What is this tunnel of which you speak?

The method; I was assuming a tunnelled method.

>At this layer, both passthrough

Isn't it sufficient for the acceptor to conclude success if the method
exposes the keying material and parameters per section 2 of RFC5247?
That's true for both full and passthrough authenticators.

Josh.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 12 Jul 2011 08:33:34 -0400

>>>>> "Josh" == Josh Howlett <[email-masked]> writes:

    Josh> Isn't it sufficient for the acceptor to conclude success if the method
    Josh> exposes the keying material and parameters per section 2 of RFC5247?
    Josh> That's true for both full and passthrough authenticators.

It needs to happen in consistent timing with the initiator.  I think
Alan is right hear: the state machine is far simpler if you wait for the
actual success message.  Note that since the RADIUS server is going to
wait for that before sending you access accept, you don't have much of a
choice.

--Sam

---

From: Josh Howlett <[email-masked]>
Date: Tue, 12 Jul 2011 15:22:17 +0000

>wait for that before sending you access accept, you don't have much of a

Perhaps we're talking cross-purposes here; which success message are we
talk about here? I was assuming the EAP Success message.

Josh.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 12 Jul 2011 21:32:09 -0400

>>>>> "Josh" == Josh Howlett <[email-masked]> writes:

    Josh> Perhaps we're talking cross-purposes here; which success message are we
    Josh> talk about here? I was assuming the EAP Success message.

I am too.  My point is that you have to wait for the EAP success message
even though it's a half round trip or more beyond where you'd ideally
terminate things in a fully protected result method with a fully
optimized state machine.  However, you have to build in too much method
knowledge to do anything else and you have to have non-standard AAA
behavior.

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Jul 2011 20:35:32 -0500

> knowledge to do anything else and you have to have non-standard AAA

Right.  That half-round-trip is a price to pay for using EAP/AAA.  And
it's another reason to want fast re-auth.

Nico
--