Re: [pcp] Posted auth req slide that was edited during meeting

[<[e-mail]>]

-----Original Message-----
From: Dan Wing [mailto:[e-mail]] 
Sent: Wednesday, March 27, 2013 8:42 AM
To: ohba yoshihiro
Cc: [e-mail]
Subject: Re: [pcp] Posted auth req slide that was edited during meeting


On Mar 26, 2013, at 4:07 PM, <[e-mail]> wrote:

> Another way is to let the SA expire, and if the server needs to send a message later on, then it can initiate authentication (and this is not a re-authentication by definition because the SA has expired).  I am fine with this way either.

Ok.  But your proposed wording of the requirement does not allow such an operation.

[YO] This is a different requirement option (say option 5).  What I meant is I am fine with either requirement, i.e., either server-initiated re-auth before expiration of SA (modified option 1) or server-initiated auth after expiration of SA (option 5).


> For those who are interested in security details:
> 
> Depending on the timing of the server-initiated authentication, the client might still have an unexpired SA.  Such a client may enter the authentication while keeping the current SA until the authentication succeeds so that it can switch back to the current SA in case the authentication fails, which provides robustness against false authentication trigger DoS attacks (at the cost of maintaining multiple authentication sessions temporarily).  PANA supports this robust operation.

I don't understand the "depending on the timing" statement.  If the server thinks the SA has expired, it has expired and the server won't accept messages with that old SA.  
[YO] Sure.  What I wanted to mention is that the exact timing of SA expiration may be different between the client and server unless strict time synchronization is maintained between them.

If you're worried of an attacker sending bogus messages to the client, claiming to the client that its SA has expired, yes, those need to either be protected (using a previous expired SA, as Sam and Stuart have suggested) or need to be treated as 'advisory', which is what I guess PANA does.
[YO] This is what I don't understand.  If a previous expired SA can be accepted by the client, when the client can consider the SA is invalid?


Perhaps a list of pros/cons of the approaches in http://www.ietf.org/mail-archive/web/pcp/current/msg02785.html could be generated, to help the working group make a decision on this point.

[YO] I agree on creating a list of pros/cons, including options 1 to 4, modified option 1 (server-initiated re-auth before expiration of SA) and option 5 (server-initiated auth after expiration of SA).

Regards,
Yoshihiro Ohba

-d


> Regards,
> Yoshihiro Ohba
> 
> -----Original Message-----
> From: Dan Wing [mailto:[e-mail]]
> Sent: Wednesday, March 27, 2013 1:02 AM
> To: ohba yoshihiro
> Cc: [e-mail]
> Subject: Re: [pcp] Posted auth req slide that was edited during 
> meeting
> 
> 
> On Mar 25, 2013, at 6:55 PM, [e-mail] wrote:
> 
>> Here is my suggested change on REQ-5 of draft-reddy-pcp-auth-req-01.
>> 
>> (Current)
>> 
>>  REQ-5:  PCP allows a server to send multiple responses.  If the
>>     server wants to send an unsolicited message, but the previous
>>     security association has expired, the server MUST be able to
>>     trigger re-authentication with the client.
>> "
>> 
>> (New)
>> 
>> "
>>  REQ-5:  PCP allows a server to send multiple responses.  If the
>>     server wants to send an unsolicited message, but the previous
>>     security association is going to expire, the server MUST be able to
>>     trigger re-authentication with the client prior to expiration of the security association.
>> "
> 
> The PCP server does not know, a priori, if it will want or need to send a message later.  So the only way to comply with that requirement would be for the PCP server to prevent a security association from expiring at all.  Is there some other way to comply with that requirement?
> 
> -d
> 
> 
>> 
>> Best Regards,
>> Yoshihiro Ohba
>> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of 
>> [e-mail]
>> Sent: Friday, March 22, 2013 1:42 AM
>> To: [e-mail]
>> Subject: Re: [pcp] Posted auth req slide that was edited during 
>> meeting
>> 
>> Can we take silence as agreement about re-auth to happen before the SA expires?
>> 
>> Yoshihiro Ohba
>> 
>> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of 
>> [e-mail]
>> Sent: Monday, March 18, 2013 11:12 PM
>> To: [e-mail]
>> Cc: [e-mail]
>> Subject: Re: [pcp] Posted auth req slide that was edited during 
>> meeting
>> 
>> Sam,
>> 
>> -----Original Message-----
>> From: Sam Hartman [mailto:[e-mail]]
>> Sent: Monday, March 18, 2013 11:00 PM
>> To: ohba yoshihiro
>> Cc: [e-mail]; [e-mail]
>> Subject: Re: [pcp] Posted auth req slide that was edited during 
>> meeting
>> 
>>>>>>> <[e-mail]> writes:
>> 
>> 
>>> In any case, we should follow the definition of EAP 
>>> re-authentication in RFC 5247 about re-authentication timing.  I see 
>>> absolutely no reason to change the definition.
>> 
>> OK. So you're saying that the goal of the security association expiration is to make sure that a client cannot change the PCP state in a manner that requires authentication outside a time window defined by the AAA infrastructure/PCP server?
>> 
>> [YO] Yes.
>> 
>> So, the sorts of attacks we'd want to prevent are people changing state after credentials have changed or authorizations have changed?
>> 
>> [YO] Yes, unless the credentials or authorizations are changed via a valid re-authentication, that is the whole purpose of re-authentication.
>> 
>> Yoshihiro Ohba
>> 
>> --Sam
>> 
>> _______________________________________________
>> pcp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pcp
>> 
>> _______________________________________________
>> pcp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pcp
>> 
>> _______________________________________________
>> pcp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pcp
> 
>