Subject: Re: [pcp] pcp auth requirements

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 10 Jun 2013 15:37:46 +0000

The other requirement that was updated as part of the discussion during the PCP interim meeting is REQ-14, would like to know if there any comments for this req.
5<http://tools.ietf.org/html/draft-reddy-pcp-auth-req-03#section-5>.  Other recommendations
      REQ-14: There SHOULD be support for a means to provide integrity
      protection without user authentication, i.e., integrity protection
      for PCP messages exchanged between a PCP server and anonymous PCP
      clients.  For example, a client visiting foreign networks such as
      a hotel, hot spot etc where the client may gain access to the
      network but does not know the credentials to authenticate with the
      PCP server.

      a.  An SA MUST be made available to the client and server, which
          will be used for integrity protection of PCP messages.  The
          negotiation of SA should be secure such that the SA is only
          known to the anonymous client and PCP server.

      b.  A PCP client MUST be able to validate that it is communicating
          with the designated PCP server and not an attacker posing as a
          PCP server.

--Tiru.

From: Alper Yegin [mailto:[email-masked]]
Sent: Thursday, May 30, 2013 11:40 AM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]; [email-masked]
Subject: Re: [pcp] pcp auth requirements

This text makes sense.

On May 29, 2013, at 4:09 PM, Tirumaleswar Reddy (tireddy) wrote:

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

          1.  The server can continue to use the same SA to protect
              messages pertaining to that mapping, even if the SA is
              technically expired.

              -  Such server notifications will not change state in the
                 PCP client.

              -  The notification could be a trigger for the client to
                 re-authenticate.  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 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]> [mailto:[email-masked]]
Sent: Wednesday, May 29, 2013 4:57 AM
To: [email-masked]<mailto:[email-masked]>; Tirumaleswar Reddy (tireddy)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [pcp] pcp auth requirements

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]<mailto:[email-masked]>
Subject: Re: [pcp] pcp auth requirements

Tiru,

I agree.

Alper

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

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]<mailto:[email-masked]>
Cc: Tirumaleswar Reddy (tireddy); [email-masked]<mailto:[email-masked]>
Subject: Re: [pcp] pcp auth requirements

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

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

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]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [pcp] pcp auth requirements

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

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

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]<mailto:[email-masked]>; [email-masked]<mailto:[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,

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

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

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]

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

      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: <[email-masked]>
Date: Mon, 10 Jun 2013 23:06:35 +0000

Hi Tiru,

I don’t understand REQ-14.   How an SA can be securely negotiated without authentication?

Yoshihiro Ohba

From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Sent: Tuesday, June 11, 2013 12:38 AM
To: Alper Yegin
Cc: ohba yoshihiro(大場 義洋 ○ＲＤＣ□ＮＳＬ); [email-masked]
Subject: RE: [pcp] pcp auth requirements

--Tiru.

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

This text makes sense.

OLD :

REQ-4-

NEW :

REQ-4-

--Tiru.

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,

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: "Prashanth Patil (praspati)" <[email-masked]>
Date: Wed, 12 Jun 2013 15:26:02 +0000

Hi Yoshihiro,
This was discussed in the PCP interim meeting. The requirement was that an anonymous client in a network be able to communicate with the PCP server for services without needing to authenticate, but with message integrity.
For mutual trust b/w the client and server, some of the things discussed were on the lines of doing DTLS with well known certificates and deriving a key as a consequence for message integrity, client obtains a key over secure DHCP or suchlike.

-Prashanth

On 11/06/13 4:36 AM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Tiru,

Yoshihiro Ohba

From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Sent: Tuesday, June 11, 2013 12:38 AM
To: Alper Yegin
Cc: ohba yoshihiro(大場義洋○ＲＤＣ□ＮＳＬ); [email-masked]<mailto:[email-masked]>
Subject: RE: [pcp] pcp auth requirements

--Tiru.

This text makes sense.

OLD :

REQ-4-

NEW :

REQ-4-

--Tiru.

Yoshihiro Ohba

Tiru,

I agree.

Alper

Hi Alper,

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

--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: Ted Lemon <[email-masked]>
Date: Wed, 12 Jun 2013 15:41:53 +0000

> For mutual trust b/w the client and server, some of the things discussed were on the lines of doing DTLS with well known certificates and deriving a key as a consequence for message integrity, clie…

"secure DHCP"?

There is no confidentiality-providing security mechanism for DHCP, so I think you need to explain what "or suchlike" is.   :)

If you just mean to validate the public key using secure DHCP, bear in mind that you've just pushed the key provisioning problem from PCP to DHCP, and that there is no widely-implemented key provisioning solution for DHCP either.

---

From: Alper Yegin <[email-masked]>
Date: Thu, 13 Jun 2013 09:14:15 +0300

I think what this requirement says is, "should support server-side only authentication".
"Must support mutual auth, and should support server-side only auth."

(yeah, DHCP is not able to solve its own security problems, how is it going to help others).

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Thu, 13 Jun 2013 12:43:40 +0000

Hi Ted,

On 12/06/13 9:11 PM, "Ted Lemon" <[email-masked]> wrote:

>> For mutual trust b/w the client and server, some of the things
>>discussed were on the lines of doing DTLS with well known certificates
>>and deriving a key as a consequence for message integrity, client
>>obtains a key over secure DHCP or suchlike.
>
>"secure DHCP"?
>
>There is no confidentiality-providing security mechanism for DHCP, so I
>think you need to explain what "or suchlike" is.   :)
>
>If you just mean to validate the public key using secure DHCP, bear in
>mind that you've just pushed the key provisioning problem from PCP to
>DHCP, and that there is no widely-implemented key provisioning solution
>for DHCP either.
>
Agreed. This wasn¹t a recommendation, it was something that was discussed
in the interim meeting.

-Prashanth

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Thu, 13 Jun 2013 12:46:50 +0000

Hi Alper,

>"Must support mutual auth, and should support server-side only auth."

Yes. An anonymous client should be able to verify a PCP server using
server-side-only auth and as a consequence obtain an SA which will be used
for PCP message integrity.

-Prashanth