Subject: Re: [pcp] pcp auth requirements

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 18 May 2013 17:23:34 +0000

Hi Alper,

Please see inline [TR]

From: Alper Yegin [mailto:[email-masked]]
Sent: Tuesday, April 30, 2013 12:53 PM
To: [email-masked]
Subject: [pcp] pcp auth requirements

      c.  If a server wants to send an unsolicited message, but the

          previous security association has expired

          1.  The server can continue to use the same SA to protect

              messages pertaining to that mapping, even if the SA is

              technically expired.

"Expired" means "do not use (even if its still hanging around)".

We not only do not need to use expired SAs, but also using something expired in any sense is plain wrong -- unless someone wants to redefine what "expired" means.

[TR]

For example if we consider MSCHAPv2, there is configuration option where server accepts the challenge-response from the client even if the password is expired and allows it be changed.

Please clarify if you have some attack in mind that would cause problems using expired SA.

[/TR]

              -  Such server notifications will not change state in the

                 PCP client.

              -  The notification could be a trigger for the client to

                 re-authenticate.

Here the document is getting into some solution description.

And as for such a solution:

Instead of sending a notification that is protected with an expired SA to mean "re-authenticate", why not send an explicit message that says "re-authenticate"?

[TR]

The client has trusted the PCP server sometime back using mutual authentication, so it can assume the integrity protected PCP response using expired SA is coming from the same PCP server and not from some attacker posing as PCP server.

[/TR]

What is gained by appearing to use an expired SA (but in fact not really using it! because the payload of the notification is not consumed by the receiver).

                 For example, if the server indicates

                 that external IP address/port has changed, the PCP

                 client can then re-authenticate with the server to

                 confirm if the external IP address/port for the mapping

                 has indeed changed.

          2.  The server can optionally trigger re-authentication with

              the client.

Yes, that's the solution. If the server has something to send to the client, and there's no live SA, then the server first needs to trigger re-auth, setup a fresh SA, then send whatever it wants to send to the client.

[TR]

We have updated this requirement in the new draft, please have a look.

Best Regards,

--Tiru.

[/TR]

Alper

---

From: Alper Yegin <[email-masked]>
Date: Mon, 20 May 2013 10:53:29 +0300

Hi Tiru,

Please see below.

 
[TR]

Alper> In that case the password is "expired for login purpose" (i.e., the user cannot login using the password), but it's still "unexpired for password change purpose" (and in fact the previous password is expired even for that purpose). 

Alper> SAs are given finite lifetimes for one of many reasons. It can be for limiting the use of keys because they cannot stand infinite amount of use in the face of crypto-attacks, it can be for limiting the access to the service (because the service provider allows finite access to the subscriber), it can be for periodically challenging the client to ensure the client device is not compromised, etc. etc. 

Alper> These are all deployment considerations. At the protocol design level, we won't know why the SA lifetime is set to the value it is set to. Using the SA beyond its lifetime is going to violate one of the deployment considerations, and we won't even know which. And we won't know how to remedy it. This is complicated.

Alper> It's even more complicated. How long would each party hold on to the expired SAs? What happens if the receiver has "rightfully" yanked the SA after it expired?

Alper> I don't see the utility of using expired SAs either. If the server wants to tell the client to re-auth, it should just do that. No point in using expired SAs to do that.

[/TR]

Alper> Just to make sure… I'm saying the document shall not get into the solution space.

 
[TR] 

Alper>  The client knows the IP address of the PCP server, right? So, the first line of defense is to check if the IP address of the PCP server is the expected one.
Alper>  Let's say the attacker is using the legit PCP server IP address, and it worked its way thru ingress filtering.
Alper> The worst that happens is (when not using expired SAs), the client is triggered to enter the re-auth phase.
Alper> If the attacker is not able to receive the responses, then the first message exchange will hang  because the attacker cannot receive and respond. Client will timeout and that's it.
Alper> If the attacker is able to receive responses as well (somehow it's MitM), then the re-auth works all the way, until the "authentication" fails. 
Alper> No serious harm is done. 

Alper> In either case, this is a minor threat that simply gets the PCP client into single re-auth when it in fact didn't have to. 

Alper> Using expired SA prevents that, but the complexity and unknown side effects are not worth it. 

 

[TR]

Alper> I see "The server MUST be able to optionally trigger re-authentication with the client."
Alper> Then using expired SA could be to about "using the expired SA to protect the trigger message".

Alper

Best Regards,
--Tiru.
 
[/TR]

---

From: <[email-masked]>
Date: Tue, 21 May 2013 07:14:18 +0000

Tiru,

In my analysis, Req-4-d-1 is basically introducing a three-state SA model for PCP: State 0:  unavailable (or non-existent), State 1: partially available only for triggering re-auth, and State 2: fully available. MSCHAPv2 password change function is designed based on this model.

I am not going to get into details about the three-state SA model, but even the three-state SA model will require re-auth trigger to be integrity protected.

Having said that, I think the following requirement is sufficient for Req-4-d: “The server MUST be able to send an integrity protected re-authentication trigger to the client.”

Regards,
Yoshihiro Ohba

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Sunday, May 19, 2013 2:24 AM
To: Alper Yegin; [email-masked]
Subject: Re: [pcp] pcp auth requirements

Hi Alper,

Please see inline [TR]

From: Alper Yegin [mailto:[email-masked]]
Sent: Tuesday, April 30, 2013 12:53 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [pcp] pcp auth requirements

              technically expired.

[TR]

[/TR]

                 PCP client.

                 re-authenticate.

[TR]

[/TR]

                 has indeed changed.

              the client.

[TR]

Best Regards,

--Tiru.

[/TR]

Alper

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 21 May 2013 14:58:50 +0000

The suggestion from Alper is to use expired SA only to trigger re-authentication and this unsolicited message should not convey any other information in this message or trigger re-authentication from the PCP server without using expired SA.

we have three options now :

      d.  If the server wants to send an unsolicited message, but the
          previous security association for the mapping
          identified in the original PCP request has expired then

Option 1:

1.  The server MUST be able to trigger re-authentication with the client. The unsolicited message for re-authentication can be integrity protected using the expired SA.

Option 2:

1.  The server MUST be able to trigger re-authentication with the client. The unsolicited message for re-authentication is not integrity protected using the expired SA.

Option 3:

The existing proposal in the draft for REQ-4-d-1.

would like to hear comments from others on this requirement.

--Tiru.
From: Alper Yegin [mailto:[email-masked]]
Sent: Monday, May 20, 2013 1:23 PM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]
Subject: Re: [pcp] pcp auth requirements

Hi Tiru,

Please see below.

[TR]

[/TR]

Alper> Just to make sure... I'm saying the document shall not get into the solution space.

[TR]

[TR]

Alper

Best Regards,
--Tiru.

[/TR]

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 May 2013 15:29:35 +0000

On May 21, 2013, at 10:58 AM, "Tirumaleswar Reddy (tireddy)" <[email-masked]<mailto:[email-masked]>> wrote:
would like to hear comments from others on this requirement.
<ad hat off>

Suppose we say that reauthentication can be triggered using an expired security association.   Here's how it would go:

1. Server sends signed reauthentication request, using expired SA.
2. Client gets signed request and either:
a. remembers the expired SA and validates the message with it
b. does not remember the expired SA, and can't validate the message

If b is possible, then there is no point in signing the message, because an attacker can always send a message signed with an unknown SA.   So in order to get any benefit from signing a message with an expired SA, you have to require that the client retain all expired SAs, and reject any message that's signed with an unknown SA, or not signed at all.   But I don't think you can do that, because now there is no way to recover from a loss of state—once either the server or the client forgets an SA, there is no way for the server to initiate communication with the client.

If that scenario is possible, I don't see any benefit to using expired SAs—I can't think of a situation where signing the message with the expired SA can be assumed to add any security at all.   That being the case, I think you should just never use expired SAs.

Of course, I am not completely up to speed here, so some of the assumptions I have made may be wrong.   But if not, I think you should just drop this expired SA idea.

---

From: Subir Das <[email-masked]>
Date: Tue, 21 May 2013 16:33:06 -0400

I agree. We should not use an expired SA.

-Subir

On Tue, May 21, 2013 at 11:29 AM, Ted Lemon <[email-masked]> wrote:

>  On May 21, 2013, at 10:58 AM, "Tirumaleswar Reddy (tireddy)" <
> [email-masked]> wrote:
>
>  Suppose we say that reauthentication can be triggered using an expired
> security association.   Here's how it would go:
>
>  If b is possible, then there is no point in signing the message, because
> an attacker can always send a message signed with an unknown SA.   So in
> order to get any benefit from signing a message with an expired SA, you
> have to require that the client retain all expired SAs, and reject any
> message that's signed with an unknown SA, or not signed at all.   But I
> don't think you can do that, because now there is no way to recover from a
> loss of state—once either the server or the client forgets an SA, there is
> no way for the server to initiate communication with the client.
>
>  If that scenario is possible, I don't see any benefit to using expired
> SAs—I can't think of a situation where signing the message with the expired
> SA can be assumed to add any security at all.   That being the case, I
> think you should just never use expired SAs.
>
>  Of course, I am not completely up to speed here, so some of the
> assumptions I have made may be wrong.   But if not, I think you should just
> drop this expired SA idea.
>
>
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp
>
>

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 21 May 2013 20:54:41 -0700

I am not sure i understand all the details, but the root requirement seems
to be that it must be possible to seamlessly maintain a PCP service in the face
of SA's expiring. Obviously that does not mean that you need to trust expired
SAs, but it seems to require that you have a scheme to renew SA or swap SAs
seamlessly, right ?

Also, one related question: If the SA is based on Certificates, are there any
epectations on how PCP should deal with expired certificates ?

I just ran into the issue that the certificates on my TivoHD expired in february.
Of course there are no further SW updates and the certificates where 5-years old.
In result, the SSL connections between the Tivo and my PCs failed and i had to
hack around the PC side to permit getting the SSL connections to work again.
And of course there is non non-SSL option to talk to the Rivo at all.

Since that experience i start seeing certificates in embedded devices as the
superior SW technology for planned obsolescence. So much easier to plan
than trying to find the right shabby HW components.

Of course i assume/hope that PCP would start to be used in embedded devices in 
the home so i fear this is an issue that could hit PCP unless the requirements
are set right.

Cheers
    Toerless

On Tue, May 21, 2013 at 04:33:06PM -0400, Subir Das wrote:
> > loss of state?once either the server or the client forgets an SA, there is
> > SAs?I can't think of a situation where signing the message with the expired

---

From: Alper Yegin <[email-masked]>
Date: Wed, 22 May 2013 10:22:27 +0300

> Having said that, I think the following requirement is sufficient for Req-4-d: “The server MUST be able to send an integrity protected re-authentication trigger to the client.”

If there is no SA available, then the server can send an un-protected re-auth trigger. We should allow that.
This is equivalent to what happens at the very beginning before the very first authentication between the client and the server.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Wed, 22 May 2013 10:29:43 +0300

This is a long-term credential management issue, dealing with how the credentials are installed on the end-points, and how they are maintained.
It's in-scope for architecture and product designs, but falls outside the scope of PCP design.
PCP would assume there exists long-term credentials and take it from there.

---

From: <[email-masked]>
Date: Wed, 22 May 2013 08:16:44 +0000

Hi Alper,

I agree that we should allow unprotected authentication trigger from the server, but we should distinguish authentication after expiration of SA from “re-authentication”.

Yoshihiro Ohba

From: Alper Yegin [mailto:[email-masked]]
Sent: Wednesday, May 22, 2013 4:22 PM
To: ohba yoshihiro
Cc: [email-masked]; [email-masked]
Subject: Re: [pcp] pcp auth requirements

On May 21, 2013, at 10:14 AM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Tiru,

Alper

Regards,
Yoshihiro Ohba

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Sunday, May 19, 2013 2:24 AM
To: Alper Yegin; [email-masked]<mailto:[email-masked]>
Subject: Re: [pcp] pcp auth requirements

Hi Alper,

Please see inline [TR]

              technically expired.

[TR]

[/TR]

                 PCP client.

                 re-authenticate.

[TR]

[/TR]

                 has indeed changed.

              the client.

[TR]

Best Regards,

--Tiru.

[/TR]

Alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 23 May 2013 00:16:04 +0300

Hi Yoshi,

Here are the three states:

0. Before PCP client and PCP server has initiated PCP session.

1. There is a PCP session and a live SA.

2. There is a PCP session, but no live SA (i.e., the last used SA is already expired).

If we execute auth in state 0, we call it "(initial) authentication".
Auth executed in state 1 is called "re-authenticaiton".
I'd call auth executed in state 2 a "re-authentication" as well, unless we want to give it a more specific name.

Alper

---

From: <[email-masked]>
Date: Wed, 22 May 2013 22:39:43 +0000

Hi Alper,

When we talk about re-authentication, we should not care about whether there is a PCP session or not.

Please see the following definition 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.
“

According to the above definition, if authentication is conducted over a live SA, it is re-authentication, otherwise it is not re-authentication.

Yoshihiro Ohba

From: Alper Yegin [mailto:[email-masked]]
Sent: Thursday, May 23, 2013 6:16 AM
To: ohba yoshihiro
Cc: [email-masked]; [email-masked]
Subject: Re: [pcp] pcp auth requirements

Hi Yoshi,

Alper

On May 22, 2013, at 11:16 AM, <[email-masked]<mailto:[email-masked]>> wrote:

Hi Alper,

Yoshihiro Ohba

From: Alper Yegin [mailto:[email-masked]]
Sent: Wednesday, May 22, 2013 4:22 PM
To: ohba yoshihiro
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [pcp] pcp auth requirements

Tiru,

Alper

Regards,
Yoshihiro Ohba

Hi Alper,

Please see inline [TR]

              technically expired.

[TR]

[/TR]

                 PCP client.

                 re-authenticate.

[TR]

[/TR]

                 has indeed changed.

              the client.

[TR]

Best Regards,

--Tiru.

[/TR]

Alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 23 May 2013 09:47:29 +0300

Yoshi,

You are right. In terms of EAP and RFC 5247, only the second case qualifies for "EAP re-authentication".

On the other hand, first and third case are not the same. 
And I'd conceptually think of the third case as a some sort of "re-authentication" (apparently not an "EAP re-authentication" per RFC 5247).

Anyways, at least I'd like people to be aware of these three different cases -- even if we cannot find a proper name to all of them.

Alper

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 23 May 2013 13:24:27 +0200

Hi Alper:

Under my point of view, even though there are three cases, case 0 and 2 imply an EAP authentication meanwhile case 1 implies an EAP re-authentication. In other words, regardless you have case 0 or 2, you have to create a SA so you need an EAP authentication (no living SA exists in either case). On the contrary, you have an SA in case 1 that you need to refresh (EAP re-authentication)

So I am not sure if we really need to distinguish case 0 and 2 under EAP's standpoint (or named them in a different way).

Best regards.

>> We have updated this requirement in the new draft, please have a look.

-------------------------------------------------------
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: Alper Yegin <[email-masked]>
Date: Thu, 23 May 2013 22:12:11 +0300

Hi Rafa,

From EAP perpective, 0 and 2 are the same.
From EAP lower-layer perspective, they are not the same. Because, there's already some pre-established state in 2, but not in 0.

Alper

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 28 May 2013 11:01:38 +0000

Hi Alper,

[1] when the PCP server triggers re-authentication and SA is valid, if the PCP client does not respond then possibly after N number of re-tries PCP server may want to give up and close the explicit mappings associated with the user. This would handle the scenario where PCP client would have crashed or terminated or connection lost for some reason or the user has logged off and some other user got the same IP address as the previous user.

[2] Even in case 3, we may want similar behavior as [1]. For Case 3, there could be a scenarios - where PCP server would want to inform the PCP client that external IP address/port has changed, but the SA is expired. In this case PCP server would have to trigger re-auth. If re-auth is successful then send the mapping update or if there is no response from the client then proceed with deleting the explicit mappings after N number of tries.

Case 3 could be an optimization to trigger re-authentication only when there is interesting update to be sent from the client or server and not to trigger re-authentication before SA expires .

--Tiru.
From: Alper Yegin [mailto:[email-masked]]
Sent: Thursday, May 23, 2013 12:17 PM
To: [email-masked]
Cc: Tirumaleswar Reddy (tireddy); [email-masked]
Subject: Re: [pcp] pcp auth requirements

Yoshi,

Alper

On May 23, 2013, at 1:39 AM, <[email-masked]<mailto:[email-masked]>> wrote:

Hi Alper,

"
"

Yoshihiro Ohba

Hi Yoshi,

Alper

Hi Alper,

I agree that we should allow unprotected authentication trigger from the server, but we should distinguish authentication after expiration of SA from "re-authentication".

Yoshihiro Ohba

Tiru,

Having said that, I think the following requirement is sufficient for Req-4-d: "The server MUST be able to send an integrity protected re-authentication trigger to the client."

Alper

Regards,
Yoshihiro Ohba

Hi Alper,

Please see inline [TR]

              technically expired.

[TR]

[/TR]

                 PCP client.

                 re-authenticate.

[TR]

[/TR]

                 has indeed changed.

              the client.

[TR]

Best Regards,

--Tiru.

[/TR]

Alper

---

From: Alper Yegin <[email-masked]>
Date: Tue, 28 May 2013 19:02:42 +0300

Tiru,

I agree.

Alper

On May 28, 2013, at 2:01 PM, Tirumaleswar Reddy (tireddy) wrote:

> [2] Even in case 3, we may want similar behavior as [1]. For Case 3, there could be a scenarios – where PCP server would want to inform the PCP client that external IP address/port has changed, but the SA is expired. In this case PCP server would have to trigger re-auth. If re-auth is successful then send the mapping update or if there is no response from the client then proceed with deleting the explicit mappings after N number of tries.
>

---

From: <[email-masked]>
Date: Tue, 28 May 2013 23:27:25 +0000

OK.  Then I suggest forming a requirement without using the term “re-authentication”, something like:

The server MUST be able to send authentication trigger to the client when there is a mapping.  The authentication trigger MUST be integrity protected if there is a SA.

Yoshihiro Ohba

From: Alper Yegin [mailto:[email-masked]]
Sent: Wednesday, May 29, 2013 1:03 AM
To: Tirumaleswar Reddy
Cc: ohba yoshihiro; [email-masked]
Subject: Re: [pcp] pcp auth requirements

Tiru,

I agree.

Alper

Hi Alper,

--Tiru.
From: Alper Yegin [mailto:[email-masked]]
Sent: Thursday, May 23, 2013 12:17 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Tirumaleswar Reddy (tireddy); [email-masked]<mailto:[email-masked]>
Subject: Re: [pcp] pcp auth requirements

Yoshi,

Alper

Hi Alper,

Yoshihiro Ohba

Hi Yoshi,

Alper

Hi Alper,

Yoshihiro Ohba

Tiru,

Alper

Regards,
Yoshihiro Ohba

Hi Alper,

Please see inline [TR]

              technically expired.

[TR]

[/TR]

                 PCP client.

                 re-authenticate.

[TR]

[/TR]

                 has indeed changed.

              the client.

[TR]

Best Regards,

--Tiru.

[/TR]

Alper

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 29 May 2013 13:09:45 +0000

Thanks Yoshi for the text :

OLD :

REQ-4-

      d.  If the server wants to send an unsolicited message, but the
          previous security association for the mapping
          identified in the original PCP request has expired

                 re-authenticate.  For example, if the server indicates

          2.  The server MUST be able to optionally trigger re-
              authentication with the client.

NEW :

REQ-4-

      d. The server MUST be able to trigger authentication with the client. The unsolicited message for authentication trigger MUST be integrity protected if there is valid unexpired SA.

--Tiru.
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, May 29, 2013 4:57 AM
To: [email-masked]; Tirumaleswar Reddy (tireddy)
Cc: [email-masked]
Subject: Re: [pcp] pcp auth requirements

OK.  Then I suggest forming a requirement without using the term "re-authentication", something like:

Yoshihiro Ohba

Tiru,

I agree.

Alper

Hi Alper,

--Tiru.

Yoshi,

Alper

Hi Alper,

Yoshihiro Ohba

Hi Yoshi,

Alper

Hi Alper,

Yoshihiro Ohba

Tiru,

Alper

Regards,
Yoshihiro Ohba

Hi Alper,

Please see inline [TR]

              technically expired.

[TR]

[/TR]

                 PCP client.

                 re-authenticate.

[TR]

[/TR]

                 has indeed changed.

              the client.

[TR]

Best Regards,

--Tiru.

[/TR]

Alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 30 May 2013 09:09:39 +0300

This text makes sense.