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

[<[e-mail]>]

Sam,

We are discussing the posted auth req slide, and sorry I have no intention to deviate from that.

Regarding your question: " Would you care to explain why you think people set up security association expiration so we can evaluate whether this particular use opens up any attacks with regard to the design goals of security association expiration?", the design goal is to bind the SA with the authorization lifetime.  In this discussion, authorization lifetime is in terms of using keys to protect PCP messages (and not necessarily in terms of the PCP states).

If we use the SA after expiration, it can end up with a situation where a user who is not allowed to create or modify a PCP state after the SA expiration can do it using the expired SA, which is undesirable from security perspective.

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.

Yoshihiro Ohba


-----Original Message-----
From: Sam Hartman [mailto:[e-mail]] 
Sent: Monday, March 18, 2013 9:14 PM
To: ohba yoshihiro
Cc: [e-mail]; [e-mail]
Subject: Re: [pcp] Posted auth req slide that was edited during meeting

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

    > Sam, It is quite obvious from the definition EAP re-authentication
    > 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.  ^^^^^^^^^ "


I'm sorry, but that doesn't answer my question at all.  You're quoting definitions at me.  I was hoping you'd be willing to engage in a discussion of what security properties PCP needs and what attacks are enabled by various decisions we make here.
Would you be willing to do that?

--Sam