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

On Mar 14, 2013, at 9:19 PM, Dave Thaler wrote:

> I just uploaded the slide started editing during the meeting into the proceedings:
> http://www.ietf.org/proceedings/86/slides/slides-86-pcp-18.pdf
>  
> During the meeting the chairs heard rough consensus to use option 4 as the
> basis on which to start the discussion on the list.   Feel free to point out problems
> with it.

Yeah, let me do that.

Option 4 is based on using "expired" security associations as if they did not expire.

This is obviously a bad idea. There's a reason why they are expired. Using them beyond expiration is plain nullifying the protection aimed by setting finite lifetimes on them. 
(If people are so convinced that using them beyond expiration is a fine idea, then maybe we should set their lifetime to infinity(!)

DoS vulnerability was given as  the justification for using expired SAs. The idea is that, the server would use the expired SA to integrity-protect the message and the client wouldn't  be duped into responding to spoofed messages. 
So, the client is getting DoS attacked by a server engaging it to perform a single authentication? No way.
You could be talking about a server getting DoS attacked when (what appears to be) 1000s of clients engaging it to perform authentication. That gives you DoS. And…. and you have no protection for that! When (what appears to be) fresh clients talk to the server, server&client have no expired/unexpired SAs to integrity protect the authentication messaging.

Once again, I am not aware of any protocols designed to use of expired SAs.
I asked for an example, and example given was human users OKing browser pop-ups when they encounter expired certificates.
People cluelessly OKing whatever the pop-up says is plain trouble. They OK it even when it says the certificate does not match the domain name. You see where this can lead to?
Market overly relaxing security solutions in order to achieve certain amount of practicality at the expense of "proper security" is a different ball game.
It is not something we shall fold back into our protocol design.

Alper

>  
> -Dave
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp