Re: [pcp] pcp auth requirements

[Alper Yegin <[e-mail]>]

Yoshi,

You are right. In terms of EAP and RFC 5247, only the second case qualifies for "EAP re-authentication".

On the other hand, first and third case are not the same. 
And I'd conceptually think of the third case as a some sort of "re-authentication" (apparently not an "EAP re-authentication" per RFC 5247).

Anyways, at least I'd like people to be aware of these three different cases -- even if we cannot find a proper name to all of them.

Alper



On May 23, 2013, at 1:39 AM, <[e-mail]> wrote:

> Hi Alper,
>  
> When we talk about re-authentication, we should not care about whether there is a PCP session or not.
>  
> Please see the following definition in RFC 5247:
> “
>    EAP Re-Authentication
>       EAP authentication between an EAP peer and a server with whom the
>       EAP peer shares valid unexpired EAP keying material.
> “
>  
> According to the above definition, if authentication is conducted over a live SA, it is re-authentication, otherwise it is not re-authentication.
>  
> Yoshihiro Ohba
>  
>  
> From: Alper Yegin [mailto:[e-mail]] 
> Sent: Thursday, May 23, 2013 6:16 AM
> To: ohba yoshihiro
> Cc: [e-mail]; [e-mail]
> Subject: Re: [pcp] pcp auth requirements
>  
> Hi Yoshi,
>  
> Here are the three states:
>  
> 0. Before PCP client and PCP server has initiated PCP session.
>  
> 1. There is a PCP session and a live SA.
>  
> 2. There is a PCP session, but no live SA (i.e., the last used SA is already expired).
>  
>  
> If we execute auth in state 0, we call it "(initial) authentication".
> Auth executed in state 1 is called "re-authenticaiton".
> I'd call auth executed in state 2 a "re-authentication" as well, unless we want to give it a more specific name.
>  
> Alper
>  
>  
>  
>  
> On May 22, 2013, at 11:16 AM, <[e-mail]> wrote:
> 
> 
> Hi Alper,
>  
> I agree that we should allow unprotected authentication trigger from the server, but we should distinguish authentication after expiration of SA from “re-authentication”.
>  
> Yoshihiro Ohba
>  
> From: Alper Yegin [mailto:[e-mail]] 
> Sent: Wednesday, May 22, 2013 4:22 PM
> To: ohba yoshihiro
> Cc: [e-mail]; [e-mail]
> Subject: Re: [pcp] pcp auth requirements
>  
>  
> On May 21, 2013, at 10:14 AM, <[e-mail]> <[e-mail]> wrote:
> 
> 
> 
> Tiru,
>  
> In my analysis, Req-4-d-1 is basically introducing a three-state SA model for PCP: State 0:  unavailable (or non-existent), State 1: partially available only for triggering re-auth, and State 2: fully available. MSCHAPv2 password change function is designed based on this model.
>  
> I am not going to get into details about the three-state SA model, but even the three-state SA model will require re-auth trigger to be integrity protected.  
>  
> Having said that, I think the following requirement is sufficient for Req-4-d: “The server MUST be able to send an integrity protected re-authentication trigger to the client.”
>  
>  
> If there is no SA available, then the server can send an un-protected re-auth trigger. We should allow that.
> This is equivalent to what happens at the very beginning before the very first authentication between the client and the server.
>  
> Alper
>  
>  
>  
> 
> 
> 
> Regards,
> Yoshihiro Ohba
>  
>  
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Tirumaleswar Reddy (tireddy)
> Sent: Sunday, May 19, 2013 2:24 AM
> To: Alper Yegin; [e-mail]
> Subject: Re: [pcp] pcp auth requirements
>  
> Hi Alper,
>  
> Please see inline [TR]
>  
> From: Alper Yegin [mailto:[e-mail]] 
> Sent: Tuesday, April 30, 2013 12:53 PM
> To: [e-mail]
> Subject: [pcp] pcp auth requirements
>  
> 
> 
>       c.  If a server wants to send an unsolicited message, but the
>           previous security association has expired
>  
>           1.  The server can continue to use the same SA to protect
>               messages pertaining to that mapping, even if the SA is
>               technically expired.
> 
> "Expired" means "do not use (even if its still hanging around)". 
> We not only do not need to use expired SAs, but also using something expired in any sense is plain wrong -- unless someone wants to redefine what "expired" means.
>  
> [TR]
> For example if we consider MSCHAPv2, there is configuration option where server accepts the challenge-response from the client even if the password is expired and allows it be changed. 
>  
> Please clarify if you have some attack in mind that would cause problems using expired SA.
>  
> [/TR]
>  
>               -  Such server notifications will not change state in the
>                  PCP client.
>  
>               -  The notification could be a trigger for the client to
>                  re-authenticate.  
> 
> Here the document is getting into some solution description.
> 
> And as for such a solution:
> 
> Instead of sending a notification that is protected with an expired SA to mean "re-authenticate", why not send an explicit message that says "re-authenticate"?
>  
> [TR] 
> The client has trusted the PCP server sometime back using mutual authentication, so it can assume the integrity protected PCP response using expired SA is coming from the same PCP server and not from some attacker posing as PCP server.
> [/TR]
>  
> What is gained by appearing to use an expired SA (but in fact not really using it! because the payload of the notification is not consumed by the receiver).
> 
> 
>                  For example, if the server indicates
>                  that external IP address/port has changed, the PCP
>                  client can then re-authenticate with the server to
>                  confirm if the external IP address/port for the mapping
>                  has indeed changed.
>  
>           2.  The server can optionally trigger re-authentication with
>               the client.
>  
>  
> Yes, that's the solution. If the server has something to send to the client, and there's no live SA, then the server first needs to trigger re-auth, setup a fresh SA, then send whatever it wants to send to the client.
>  
> [TR]
>  
> We have updated this requirement in the new draft, please have a look.
>  
> Best Regards,
> --Tiru.
>  
> [/TR]
>  
>  
> Alper
>  
>  
>