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

On Mar 26, 2013, at 4:07 PM, <yoshihiro.ohba@toshiba.co.jp> 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.

> 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.  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.

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.

-d

> Regards,
> Yoshihiro Ohba
> 
> -----Original Message-----
> From: Dan Wing [mailto:dwing@cisco.com] 
> Sent: Wednesday, March 27, 2013 1:02 AM
> To: ohba yoshihiro
> Cc: pcp@ietf.org
> Subject: Re: [pcp] Posted auth req slide that was edited during meeting
> 
> 
> On Mar 25, 2013, at 6:55 PM, yoshihiro.ohba@toshiba.co.jp 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: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of 
>> yoshihiro.ohba@toshiba.co.jp
>> Sent: Friday, March 22, 2013 1:42 AM
>> To: pcp@ietf.org
>> 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: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of 
>> yoshihiro.ohba@toshiba.co.jp
>> Sent: Monday, March 18, 2013 11:12 PM
>> To: hartmans@painless-security.com
>> Cc: pcp@ietf.org
>> Subject: Re: [pcp] Posted auth req slide that was edited during 
>> meeting
>> 
>> Sam,
>> 
>> -----Original Message-----
>> From: Sam Hartman [mailto:hartmans@painless-security.com]
>> Sent: Monday, March 18, 2013 11:00 PM
>> To: ohba yoshihiro
>> Cc: alper.yegin@yegin.org; pcp@ietf.org
>> Subject: Re: [pcp] Posted auth req slide that was edited during 
>> meeting
>> 
>>>>>>> <yoshihiro.ohba@toshiba.co.jp> 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
>> pcp@ietf.org
>> https://www.ietf.org/mailman/listinfo/pcp
>> 
>> _______________________________________________
>> pcp mailing list
>> pcp@ietf.org
>> https://www.ietf.org/mailman/listinfo/pcp
>> 
>> _______________________________________________
>> pcp mailing list
>> pcp@ietf.org
>> https://www.ietf.org/mailman/listinfo/pcp
> 
> 