Subject: [abfab] EAP Applicability: server-initiated re-authentication

From: Sam Hartman <[email-masked]>
Date: Fri, 19 Oct 2012 09:41:29 -0400

Second issue relates to EAP requirements surrounding server-initiated
re-authentication.  We've had one claim that EAP lower layers MUST
support re-authentication initiated by the server.

If that's true, we have kind of a big problem with GSS-EAP.

As best I can tell though that's not true.  RFC 3748 doesn't really talk
about server-initiated re-authentication.  The RADIUS EAP support
doesn't seem to support it, and the COA informational RFC explicitly
says it cannot be used for re-authentication.  The Diameter EAP
application says that if the lower layer supports EAP re-authentication
then the Diameter NAS MUST support re-authentication as well.
I have looked up citations for the above in a PCP discussion and am
happy to dig that all up if  they would help anyone here.

As best I can tell, the motivation for re-authentication is an
interesting different between network access and application
authentication. In network access, there is a significant disruption  if
your connection drops and you have to re-authenticate before you can
send your next packet.
It's strongly desirable to re-authenticate before your lifetime expires.
(This doesn't speak to server-initiated re-auth, I realize)

Some applications work like that.
However there are a lot of applications where the server can close the
connection and when the client wants to  do the next thing, it will
re-authenticate at that time.
For example with SMTP, it's not going to be a big deal if the next time
I want to send mail it takes a bit longer because my server has closed a
connection to force me to reauthenticate.

My recommendation is that the applicability statement  should discuss
the issue of re-authentication. We should recommend that applications
that will be disrupted  by  authentication expiration have a mechanism
to re-authenticate while the existing authentication is still live.

I think we need to say very little about server-initiated
re-authentication. I think we should say that applications MAY support
server-initiated re-authentication. If they do, then the server can send
authentication packets at any time.

---

From: Alper Yegin <[email-masked]>
Date: Fri, 19 Oct 2012 16:56:27 +0300

Hi Sam,

Please also share this discussion with EAP WG and EMU WG mailing lists. That's where the EAP expertise is and they should chime in, given that you are proposing to modify EAP applicability statement.

Alper

On Oct 19, 2012, at 4:41 PM, Sam Hartman wrote:

> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Sam Hartman <[email-masked]>
Date: Fri, 19 Oct 2012 10:08:35 -0400

>>>>> "Alper" == Alper Yegin <[email-masked]> writes:

    Alper> Hi Sam, Please also share this discussion with EAP WG and EMU
    Alper> WG mailing lists. That's where the EAP expertise is and they
    Alper> should chime in, given that you are proposing to modify EAP
    Alper> applicability statement.

The eap applicability statement  update is a charter item of
ABFAB. We've agreed it will be last called in EMU.
Since it's a work item of abfab, it should be discussed on that list.
You're certainly free to let people know that the discussion if taking
place, although we've done that several times before.

---

From: Alper Yegin <[email-masked]>
Date: Mon, 22 Oct 2012 13:06:40 +0300

> place, although we've done that several times before.

Sam,

The type of changes you are talking about are well beyond the "applicability statement changes" that ABFAB is chartered to make.
Now you are discussing how EAP can be executed in a client-driven style (as opposed to network driven), how server-initiated EAP re-authentication may not be supported, how authorization parameters (especially the session lifetime) is not set by the AAA server. 

We need EAP and AAA expertise to get involved in the discussion. Not only when ABFAB WG thinks it is done, but especially from the get go.
This, IMHO, is re-engineering EAP and associated AAA procedures.

Alper

---

From: Sam Hartman <[email-masked]>
Date: Mon, 22 Oct 2012 08:50:56 -0400

>> ABFAB. We've agreed it will be last called in EMU.  Since it's a
    >> work item of abfab, it should be discussed on that list.  You're
    >> certainly free to let people know that the discussion if taking

    Alper> Sam,

    Alper> The type of changes you are talking about are well beyond the
    Alper> "applicability statement changes" that ABFAB is chartered to
    Alper> make.  

First,  I definitely encourage you to involve anyone in any IETF WG
discussion you believe will help form a better consensus.
So, absolutely, encourage people who you believe should join the
discussion to do so.

I am a bit confused by your message, because I'm not discussing changing
EAP, only discussing how some issues that seem relatively likely to come
up will influence applying EAP authentication to application
authentication.
My intent is to document existing, potentially hard to understand
aspects of EAP so that  people can better apply EAP to their
applications.

Thanks,

--Sam

---

From: Alper Yegin <[email-masked]>
Date: Tue, 23 Oct 2012 11:08:09 +0300

> So, absolutely, encourage people who you believe should join the

Good. Please remember to keep these groups updated as you progress the discussion.

I captured the issues you are raising as below:

>  how EAP can be executed in a client-driven style (as opposed to network driven), how server-initiated EAP re-authentication may not be supported, how authorization parameters (especially the session lifetime) is not set by the AAA server. 

These have potential impact on the EAP layer, and EAP lower-layer (both the EAP peer to EAP Authenticator leg, and the EAP Authenticator to EAP Authentication Server leg [a.k.a, the AAA protocol]). We need to fully understand the implications. These are not mere "applicability" issues. 

The ABFAB applicability update in my understanding is nothing more than removing the somewhat artificial constraints in RFC 3748 that was blocking the use of EAP for anything other than network access authentication. The types of issues you are discussing now are well beyond that.

Alper

> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 24 Oct 2012 16:14:53 +0900

RFC 5247 discusses EAP re-authentication in several sections.

Here is one part:

"
    Where TSKs are derived from or are wrapped by exported EAP keying
    material, compromise of that exported EAP keying material implies
    compromise of TSKs.  Therefore, if EAP keying material is considered
    stale, not only SHOULD EAP re-authentication be initiated, but also
    replacement of child keys, including TSKs.
"

Since EAP keying material can be considered stale by either peer or 
authenticator, it makes sense to support both peer-initiated and 
authenticator-initiated re-authentication.  If an application protocol 
has a design restriction that prevents from suppporting 
authenticator-initiated re-authentication, then it is better to let each 
application specification have some text in their Security 
Considerations section to assess potential impact on the application due 
to lack of the functionality.

Having said that I don't agree with having text like "applications MAY support server-initiated re-authentication" in EAP applicability statement.  What we sould have in EAP applicability statement is that the key management framework described in RFC 5247 is applicable to both network access and application usage of EAP.

Regards,
Yoshihiro Ohba

---

From: Sam Hartman <[email-masked]>
Date: Wed, 24 Oct 2012 06:35:38 -0400

>>>>> "Yoshihiro" == Yoshihiro Ohba <[email-masked]> writes:

    Yoshihiro> RFC 5247 discusses EAP re-authentication in several
    Yoshihiro> sections.  Here is one part:

    Yoshihiro> " Where TSKs are derived from or are wrapped by exported
    Yoshihiro> EAP keying material, compromise of that exported EAP
    Yoshihiro> keying material implies compromise of TSKs.  Therefore,
    Yoshihiro> if EAP keying material is considered stale, not only
    Yoshihiro> SHOULD EAP re-authentication be initiated, but also
    Yoshihiro> replacement of child keys, including TSKs.  "

    Yoshihiro> Since EAP keying material can be considered stale by
    Yoshihiro> either peer or authenticator, it makes sense to support
    Yoshihiro> both peer-initiated and authenticator-initiated
    Yoshihiro> re-authentication.  If an application protocol has a
    Yoshihiro> design restriction that prevents from suppporting
    Yoshihiro> authenticator-initiated re-authentication, then it is
    Yoshihiro> better to let each application specification have some
    Yoshihiro> text in their Security Considerations section to assess
    Yoshihiro> potential impact on the application due to lack of the
    Yoshihiro> functionality.

A few points.

First, I agree with you that stale keying is an important thing to
consider when integrating EAP into an application.
So, I think we should make sure applications have the advice they need
with regard to this topic.

I also agree with you that the keying framework applies.

However, we disagree about  the need to discuss application-specific
issues.
Here are some things to consider:

1) If your application uses TLS for confidentiality and integrity, say
because it uses EAP with the eap-aes128 SASL mechanism, then compromise
of the MSK does not affect traffic keys for your application. If  the
MSK was compromised at time of generation--say because a long-term
password was compromised--then your entire authentication is
compromised.
If on the other hand the MSK is compromised after authentication, no
harm appears to be done in this case.

2) The EAP keying framework is written in the context of network
access. In that context, shutting down a session in response to needing
to re-key is a disruptive event. However, for something like SMTP, it
seems entirely reasonable to just take down the session, which the
server can do at an appropriate sequence point. If the client still
wants to talk it will reconnect. There are actually a number of
applications that work this way.

3) As you point out, if an application doesn't have a way to respond to
key compromise, there are likely to be security considerations.
One thing applicability statements often do is point out security issues
people should consider when applying a technology.

Especially where application use differs from network access use, we
should document that sort of thing. 

Various aspects of the "detailed security analysis" provided by RFC 5247
are different, or the common assumptions are different for applications
rather than network access.
This is why you can't just change the one sentence in section 1.3 of RFC
3748  and be done.

In conclusion, thanks for pointing out the really interesting issue of
key compromise. We'll want to handle that.

---

From: Alper Yegin <[email-masked]>
Date: Wed, 24 Oct 2012 14:11:37 +0300

Sam,

I recommend starting from identifying what aspects of "applications" are different from "network access", and how such differences play into EAP.

Below you are talking about one such difference. 

(In that, in my understanding, you are OK with server initiated re-auth for network access, but you think this is not needed for applications. 
What is the root cause of this difference? )

There may be other differences. 

Alper

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 29 Oct 2012 03:12:45 +0000

For the purposes of whether "server initiated re-authentication" is required, I think it is up to the lower layer to determine what this means.  As has been pointed out for network access you usually want to re-authenticate using a mechanism that does not disrupt the session.  For an application, this may not be an important consideration.  It may be feasible to just terminate the session and start a new one with a fresh authentication.  An application needs to determine how it will handle the following cases:

1)  refresh in keying material is required - (key overuse, PN/nonce exhaustion,etc)
2)  handling key/session compromise

I do not think it will be too hard to provide text for this in the applicability considerations and security considerations if that is what the group wants to do.  

Cheers,

Joe