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

From: Dave Thaler <[email-masked]>
Date: Thu, 14 Mar 2013 19:19:55 +0000

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.

-Dave

---

From: Alper Yegin <[email-masked]>
Date: Fri, 15 Mar 2013 05:18:44 +0200

> basis on which to start the discussion on the list.   Feel free to point out problems

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 15 Mar 2013 17:09:26 +0100

Dear all:

I have been trying to understand the requirement 4) but I have failed (probably my problem).

Let me share my view about this.

A security association (SA) is the result of the establishment of some sort of shared security context between two (or more) network entities to perform secure communications. We have IPsec SA, IKE SA, TLS SA, etc... These entities share a security context which imply to share fresh cryptographic material.

So, to me, the statement "Server can use expired SA for a given mapping to protect any unsolicited unicast message it sends regarding that mapping " seems wrong under a security standpoint (maybe it is not intention of the sentence or I do not understand it)

A expired SA means it is not a fresh SA and therefore not valid. Using it creates a security issue.

Apart from this, I was wondering... what is the expiration time of a "expired" SA? Or, in other words, when the "expired" SA is really expired? Is the lifetime set to infinite? If it isn't, how is the extended lifetime SA set? 

This is really confusing to me. As also said in the meeting, then we are not talking about an expired SA.

I believe I also heard in the audio that there were real examples where an expired SA is used. I would like to know some of them. AFAIK, IPsec SA, IKE SA, etc... do not proceed like this way. Is there any standard secure protocol that allows this and it is considered secure?

An example about the usage of certificates was also given. A certificate is a credential. So I do not know how this example applies.

I would really appreciate any clarification.

Best regards.

> basis on which to start the discussion on the list.   Feel free to point out problems

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Sam Hartman <[email-masked]>
Date: Sat, 16 Mar 2013 14:29:36 -0400

>>>>> "Alper" == Alper Yegin <[email-masked]> 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?

---

From: <[email-masked]>
Date: Sat, 16 Mar 2013 19:52:37 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Sunday, March 17, 2013 3:30 AM
To: Alper Yegin
Cc: [email-masked]
Subject: Re: [pcp] Posted auth req slide that was edited during meeting

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
[email-masked]
https://www.ietf.org/mailman/listinfo/pcp

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Mar 2013 08:14:29 -0400

>>>>>   <[email-masked]> 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

---

From: <[email-masked]>
Date: Mon, 18 Mar 2013 13:36:46 +0000

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:[email-masked]] 
Sent: Monday, March 18, 2013 9:14 PM
To: ohba yoshihiro
Cc: [email-masked]; [email-masked]
Subject: Re: [pcp] Posted auth req slide that was edited during meeting

    > a server with whom the EAP peer shares valid unexpired EAP keying

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

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Mar 2013 09:59:36 -0400

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

So, the sorts of attacks we'd want to prevent are people changing state
after credentials have changed or authorizations have changed?

--Sam

---

From: <[email-masked]>
Date: Mon, 18 Mar 2013 14:12:07 +0000

Sam,

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

    > 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

---

From: <[email-masked]>
Date: Thu, 21 Mar 2013 16:41:58 +0000

Can we take silence as agreement about re-auth to happen before the SA expires?

Yoshihiro Ohba

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, March 18, 2013 11:12 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [pcp] Posted auth req slide that was edited during meeting

Sam,

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

[YO] Yes.

Yoshihiro Ohba

--Sam

---

From: <[email-masked]>
Date: Tue, 26 Mar 2013 01:55:08 +0000

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

Best Regards,
Yoshihiro Ohba

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, March 22, 2013 1:42 AM
To: [email-masked]
Subject: Re: [pcp] Posted auth req slide that was edited during meeting

Yoshihiro Ohba

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, March 18, 2013 11:12 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [pcp] Posted auth req slide that was edited during meeting

Sam,

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

[YO] Yes.

Yoshihiro Ohba

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Mar 2013 22:21:22 -0400

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

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.

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.

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.

--Sam

---

From: <[email-masked]>
Date: Tue, 26 Mar 2013 03:22:22 +0000

Sam,

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

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

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

---

From: Sam Hartman <[email-masked]>
Date: Tue, 26 Mar 2013 08:58:06 -0400

I'm sorry, but I think it's totally reasonable to mandate in a spec and
enforce in servers that PCP clients cannot send messages using expired
SAs.

At this point I think we've explained our positions fairly clearly and
are not likely to change each others' minds.

I continue not to envy the chairs' challenge in calling consensus.

---

From: Dan Wing <[email-masked]>
Date: Tue, 26 Mar 2013 09:02:18 -0700

>      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

---

From: <[email-masked]>
Date: Tue, 26 Mar 2013 23:07:44 +0000

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.

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.

Regards,
Yoshihiro Ohba

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: Wednesday, March 27, 2013 1:02 AM
To: ohba yoshihiro
Cc: [email-masked]
Subject: Re: [pcp] Posted auth req slide that was edited during meeting

-d

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

---

From: Dan Wing <[email-masked]>
Date: Tue, 26 Mar 2013 16:42:27 -0700

> 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 ex…

Ok.  But your proposed wording of the requirement does not allow such an operation.

> 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 authe…

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

---

From: Dave Thaler <[email-masked]>
Date: Wed, 27 Mar 2013 01:09:24 +0000

> Sent: Tuesday, March 26, 2013 5:58 AM
> To: [email-masked]
> Cc: [email-masked]
> I'm sorry, but I think it's totally reasonable to mandate in a spec and enforce
> in servers that PCP clients cannot send messages using expired SAs.
[...]

(With no hats on) I agree with the above.   It's totally reasonable to mandate
such a thing, if that's what the WG decides to do.

-Dave

---

From: <[email-masked]>
Date: Wed, 27 Mar 2013 03:12:41 +0000

I agree to enforce in servers that clients cannot send messages using expired SAs to avoid security issues.

For the same reason, we should also enforce in clients that servers cannot send messages using expired SAs.

Yoshihiro Ohba

-----Original Message-----
From: Dave Thaler [mailto:[email-masked]] 
Sent: Wednesday, March 27, 2013 10:09 AM
To: Sam Hartman; ohba yoshihiro
Cc: [email-masked]
Subject: RE: [pcp] Posted auth req slide that was edited during meeting

> I'm sorry, but I think it's totally reasonable to mandate in a spec 
> and enforce in servers that PCP clients cannot send messages using expired SAs.
[...]

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Wed, 27 Mar 2013 03:18:48 +0000

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, March 26, 2013 8:13 PM
> To: Dave Thaler; [email-masked]
> Cc: [email-masked]

No, the same reason doesn't apply.   The reason to enforce in servers is
to prevent modification of server state.

Enforcing in clients wouldn't mitigate any state change attack I understand.
The message from a server using an expired SA would just have the effect
of (for example) being a hint to the client that it needs to refresh its state in the
server, and could trigger the client to do reauth as it needs to send a MAP or
PEER or whatever.   So I think the effects are quite different.

Is there some attack you have in mind that doing enforcement in the client
would mitigate?

-Dave

---

From: <[email-masked]>
Date: Wed, 27 Mar 2013 03:32:23 +0000

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: Wednesday, March 27, 2013 8:42 AM
To: ohba yoshihiro
Cc: [email-masked]
Subject: Re: [pcp] Posted auth req slide that was edited during meeting

[YO] This is a different requirement option (say option 5).  What I meant is I am fine with either requirement, i.e., either server-initiated re-auth before expiration of SA (modified option 1) or server-initiated auth after expiration of SA (option 5).

> 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 authe…

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.  
[YO] Sure.  What I wanted to mention is that the exact timing of SA expiration may be different between the client and server unless strict time synchronization is maintained between them.

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.
[YO] This is what I don't understand.  If a previous expired SA can be accepted by the client, when the client can consider the SA is invalid?

[YO] I agree on creating a list of pros/cons, including options 1 to 4, modified option 1 (server-initiated re-auth before expiration of SA) and option 5 (server-initiated auth after expiration of SA).

Regards,
Yoshihiro Ohba

-d

>>> re-authentication in RFC 5247 about re-authentication timing.  I see 
>>> absolutely no reason to change the definition.
>>

---

From: <[email-masked]>
Date: Wed, 27 Mar 2013 03:54:40 +0000

-----Original Message-----
From: Dave Thaler [mailto:[email-masked]] 
Sent: Wednesday, March 27, 2013 12:19 PM
To: ohba yoshihiro; [email-masked]
Cc: [email-masked]
Subject: RE: [pcp] Posted auth req slide that was edited during meeting

Enforcing in clients wouldn't mitigate any state change attack I understand.
The message from a server using an expired SA would just have the effect of (for example) being a hint to the client that it needs to refresh its state in the server, and could trigger the client to do reauth as it needs to send a MAP or
PEER or whatever.   So I think the effects are quite different.

Is there some attack you have in mind that doing enforcement in the client would mitigate?

[YO] Since it is only "a hint" (since the client has no state for the "expired" SA), there can be  a false re-authentication trigger DoS attack.  If the client has to keep the expired SA, I consider it is not actually expired as I mentioned in Orlando meeting. I feel that we do not have a common understanding about "expired SA" in this debate.

Yoshihiro Ohba

-Dave

> > and enforce in servers that PCP clients cannot send messages using 
> > expired
> SAs.
> [...]
>