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

[<[e-mail]>]

Sam,

-----Original Message-----
From: Sam Hartman [mailto:[e-mail]] 
Sent: Tuesday, March 26, 2013 11:21 AM
To: ohba yoshihiro
Cc: [e-mail]
Subject: Re: [pcp] Posted auth req slide that was edited during meeting

>>>>>   <[e-mail]> writes:

    > Can we take silence as agreement about re-auth to happen before
    > the SA expires?  Yoshihiro Ohba
I'm sorry; I missed this message somehow (my fault) and noticed it because you replied to it.

[YO] No problem.

When we were last conversing, we agreed that the attacks we were trying to prevent were a PCP client modifying mapping state after the SA has expired.

However,  I don't see how those attacks are  possible with either option
3 or 4.

Option 3 provides protected signaling of a re-auth request.
At worst, option 3 is no more secure than option 2.

Option 4  provides  protected signaling about potential server updates in an expired SA. However, the attacks we agreed are the ones of concern cannot happen with option 4 , because the client cannot change PCP state using an expired SA in that case.

[YO] If an SA is bidirectional, it is not possible to use the SA such that only one end of the SA can use it.  The following cases are logically possible:

- Both the client and server can use the expired SA.  This is an unacceptable option since client can modify the existing mapping.  This eliminates options 3 and 4.

- Neither the client or server can use the expired SA.  This eliminates options 3 and 4 as well.

If an SA is bidirectional this is not the case, but bidirectional SA for PCP will add more complexity with little benefit and is not a viable option.


My preference list of options is 4, 3, 2, 1, your modified option 1.
The reason I dislike your modified option is that it's not clear when a client or server should offer re-authentication in that case, so I believe that your proposal will lead to less interoperability than option 1.
[YO] Options 3 and 4 can be logically eliminated for the reasons I explained above.  Option 2 (unprotected notice from server about need for re-auth) is vulnerable to false re-auth trigger attack that I mentioned last year (http://www.ietf.org/mail-archive/web/pcp/current/msg02668.html for example).  Option 1 and modified option 1 are not different in that both do not prohibit the client to initiate re-aut, and I don't see any interoperability issue for allowing both entities to initiate re-auth especially when using PANA.  Can you elaborate?

Prior to the meeting, I believe that we had ruled out option 1 and 4 and had a consensus on the list that was ambiguous between option 2 and 3.
At the meeting Stuart asked to re-open option 4.
My assumption is that Stuart probably also considers option 4 most preferred.

[YO] My understanding is the option 4 is the "starting point".  Since I found a problem with option 4, I argue here.

Regards,
Yoshihiro Ohba

--Sam