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

From: Alper Yegin <[email-masked]>
Date: Wed, 14 Nov 2012 14:12:05 +0200

Furthermore, as we discussed in PCP WG there's another problem.

Sam is proposing to decouple EAP security association management from the application state.
More specifically, even after the EAP session is release/timed out, application may still be in use.
What that means is, if the server has an application message that is pending to be transmitted to the client, and if at that time there's no security association available (see above), then the server needs to initiate re-authentication in order to re-generate a security association and send the app message securely.

In PCP WG meeting Sam claimed he can design a solution to this problem, and committed to sending a straw man solution. 
I just want to make ABFAB people aware of this issue, and indicate that we are looking forward to seeing Sam's solution proposal.

Cheers,

Alper

On Oct 24, 2012, at 10:14 AM, Yoshihiro Ohba wrote:

> 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
> 
> 
> (2012/10/19 22:41), Sam Hartman wrote:
>> 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.
>> _______________________________________________
>> abfab mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/abfab
>> 
> 
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Sam Hartman <[email-masked]>
Date: Wed, 14 Nov 2012 09:07:18 -0500

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

    Alper> Furthermore, as we discussed in PCP WG there's another
    Alper> problem.  Sam is proposing to decouple EAP security
    Alper> association management from the application state.  More
    Alper> specifically, even after the EAP session is release/timed
    Alper> out, application may still be in use.  What that means is, if
    Alper> the server has an application message that is pending to be
    Alper> transmitted to the client, and if at that time there's no
    Alper> security association available (see above), then the server
    Alper> needs to initiate re-authentication in order to re-generate a
    Alper> security association and send the app message securely.

Hmm, that's not how I'd think about this at all.

I'd describe it as follows.  In a peer-to-peer protocol, you sometimes
have messages you'd like to send to peers for which you have no security
state.
In that case you can either:

1) send an insecure message

2) establish security state.

The question of whether you previously had state with a peer seems a
needless complication.

Regardless, I don't think this issue has much to do with the EAP
applicability statement.
Similar issues show up all over the place with SIP, XMPP, etc.

--Sam

---

From: Alan DeKok <[email-masked]>
Date: Wed, 14 Nov 2012 10:07:54 -0500

> What that means is, if the server has an application message that is pending to be transmitted to the client, and if at that time there's no security association available (see above), then the ser…

  This is what's done today for 802.1X authentication.  Both wired &&
wireless.  The solution is to re-establish authentication before sending
another application message.

  The hard part about 802.1X is that the application doesn't know
there's an underlying security association.  All it knows is that the
network went away for a bit, and then came back.

  For PCP, it's reasonable that the application knows the EAP session
has timed out.  It can re-establish it before sending the next message.
 Or, if messages are rare, it can wait and re-establish it later.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 14 Nov 2012 10:44:12 -0500

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan>   For PCP, it's reasonable that the application knows the EAP
    Alan> session has timed out.  It can re-establish it before sending
    Alan> the next message.  Or, if messages are rare, it can wait and
    Alan> re-establish it later.

Well, it's a bit tricky to re-establish the session if the next message
is coming from the server but only the client can start the
authentication.
I think you have two general options:

1) Decide it's OK not to re-establish the session until the client wants
to do so

2) Change things and let the server start an EAP session.

3) Require the client to start an EAP session whenever the old session
goes away.

The details as they apply to PCP are best discussed on that list.

---

From: Alper Yegin <[email-masked]>
Date: Sat, 17 Nov 2012 01:14:19 +0200

> 1) Decide it's OK not to re-establish the session until the client wants

This does not make sense. If we are talking about securing a protocol, that better be a complete security, not a partial security that's uncontrollably on and off. In this case, when the server wants to send a message, if it's lucky it'll find a live security association and send the message securely. If it's unlucky (there is no live SA), then bad luck -- packet is dropped w/o transmission. Because sending an unsecure packet does not make sense, it's at best useless, at worst harmful if we expect the clients to act on them.

> 3) Require the client to start an EAP session whenever the old session

2&3 make sense.

I'd say the protocol shall support the capabilities needed for both 2 and 3. And leave it to the deployment to decide when to use them.

Alper

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 19 Nov 2012 20:42:11 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Alper Yegin
> Sent: Friday, November 16, 2012 3:14 PM
> To: Sam Hartman
> Cc: [email-masked]
> Subject: Re: [abfab] EAP Applicability: server-initiated re-authentication
> 
> 
> > Well, it's a bit tricky to re-establish the session if the next
> > message is coming from the server but only the client can start the
> > authentication.
> > 1) Decide it's OK not to re-establish the session until the client
> > wants to do so
> >
> 
> This does not make sense. If we are talking about securing a protocol,
that
> better be a complete security, not a partial security that's
uncontrollably on
> and off. In this case, when the server wants to send a message, if it's
lucky
> it'll find a live security association and send the message securely. If
it's
> unlucky (there is no live SA), then bad luck -- packet is dropped w/o
> transmission. Because sending an unsecure packet does not make sense, it's
> at best useless, at worst harmful if we expect the clients to act on them.

I find this to be a completely appropriate behavior.  Before I left the
e-mail group at Microsoft I had just come to the realization that I no
longer believe that all email messages needed to have S/MIME signatures
verified prior to showing the message to the recipient.  The validation
process could be deferred until one of a number of different trigger events
occurred.  I changed groups because the Outlook group was not interested in
doing another round of changes in behavior so I never had the long
discussions to get my ideas into the program.

However this represents a similar behavior.  As a client I get a message,
would I care about the content of the message?  If so then I can find out if
the message is real.  If I don't care about the content of the message then
why should I care if it is real or spam?  

The act that the client is expected to do is to ask the server if the
message is real (assuming it cares) before performing operations on the
message.  That seems to be a totally reasonable behavior.

Jim

> I'd say the protocol shall support the capabilities needed for both 2 and
3.
> And leave it to the deployment to decide when to use them.
>

---

From: Alper Yegin <[email-masked]>
Date: Thu, 22 Nov 2012 12:50:44 +0200

> message.  That seems to be a totally reasonable behavior.

Are there real and used examples of this approach you are describing?

I think it's flawed.

Following your email example, I can easily see people losing nerves clicking the "authenticate this message, now!" button when seeing emails like "your cat has died!" and "you are promoted to become VP!" :-)

In terms of software processing, what kind of message would the receiver not care? If it does not care, why the other end is sending that message to it… 
Even for understanding if the receiver cares about the packet, it needs to "consume" the payload. And that payload may already be altered enroute, since the packet is not integrity-protected. That's a security hole.

Alper