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

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

On the other hand, mandating reauth may be a bit strong requirement since neither the client nor the server may want  to continue to talk after the lifetime of the SA.

Having said that, I prefer a revised version of option 1) as follows:

If reauth happens, it MUST happen before SA expires.

Regards,
Yoshihiro Ohba

-----Original Message-----
From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Sam Hartman
Sent: Sunday, March 17, 2013 3:30 AM
To: Alper Yegin
Cc: pcp@ietf.org
Subject: Re: [pcp] Posted auth req slide that was edited during meeting

>>>>> "Alper" == Alper Yegin <alper.yegin@yegin.org> writes:

    Alper> Yeah, let me do that.

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

    Alper> This is obviously a bad idea. 

Alper, it's not obvious to me why using a security association for status updates regarding an existing mapping is bad after it's expired for new mappings.

I agree that we'll need to analyze the security of whatever we do and document any attacks that result.

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?
_______________________________________________
pcp mailing list
pcp@ietf.org
https://www.ietf.org/mailman/listinfo/pcp