Subject: [pcp] draft-chen-pcp-authentication-sim-00

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 18 Sep 2014 04:31:39 +0000

In the PCP interim meeting there we discussed the impact of draft-chen-pcp-authentication-sim-00 on PCP authentication draft and it's usage in Mobile networks.

Offline Gang and I had discussed the PCP authentication mechanism proposed in draft-chen-pcp-authentication-sim-00 and that it can be updated so that the client uses the existing ID Indicator option defined in PCP authentication draft to signal B-TID value to the server in the PA-client message. PCP server can use the Key from HTTP authentication as MSK for deriving the Transport key.

This way the new PCP option defined in this draft is not required and the proposed mechanism will align with the PCP authentication work.
Let us know if this works to modify the draft accordingly.

Updated figure:

      PCP Client                         PCP Server                       BSF              HSS

           |  1. PA-Initiation               |                             |                 |
           |-------------------------------->|                             |                 |
           |2. PA-Server(bootstrapping)      |                             |                 |
           |<--------------------------------|                             |                 |
           |                     3.Request(User Identity)                  |  4.Retrieve AV  |
           |-------------------------------------------------------------->|<--------------->|
           |                    5.401 Unauthorized WWW-Authenticate        |
           |                     Digest (RAND, AUTH)                       |
           |<--------------------------------------------------------------|
           |                6.Request Authorization: Digest (RES is used)  |
           |-------------------------------------------------------------->|
           |                                 |                   Server checks the given Digest
           |                                 |                       and drive Ks
           |                    7.200 OK, B-TID, Key lifetime              |
           |<--------------------------------------------------------------|
           |     8. PA-Client                |  9. Authentication Request  |
           |     (ID-Indicator)              |   (B-TID)                   |
           |-------------------------------->|---------------------------->|
           |                                 | 10.Authentication Answer    |
           | 11.AUTHENTICAION-SUCCESSD       | (Ks, Key lifetime)          |
           |<--------------------------------|<----------------------------|

                    Figure4: PCP authentication in GBA

-Tiru

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Thu, 18 Sep 2014 07:56:22 +0000

According to our previous discussion, the ID-indicator is used to provide the an identifier to the PCP client so that the client can use it to choose the correct credentials in the authentication with the PCP server. Therefore, this option should be sent from the server to the client.

I think it is better to define a new option rather than re-using the existing one.

In addition, in the base authentication protocol, it is assumed that EAP will be used to perform authentication. And the discussion in the document is all about how to transport EAP messages. So, if we want to combine the two document into a single one, the assumption will be broken and quite a lot of contents need to be adjusted (I would like to do the adjustment of course if the group decide to do so). For instance, in an authentication solution supporting different authentication protocols other than EAP, when a PCP client and a PCP server initially exchange their PA messages, they need to be able to negotiate the authentication protocols they would like to use, which is not considered in the current document. So, I think it might be a good idea to propose the two document separately. One is the based authentication protocol designed for EAP and one is the extension of base authentication protocol to support other authentication protocols.  Gang Chen has invited me to help him improve his work. So, I suggest the group  to decide the plan of next step first and then go into the discussion of design details.

Comments?

Cheers

Dacheng

From: pcp [mailto:[email-masked]] On Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Thursday, September 18, 2014 12:32 PM
To: [email-masked]
Subject: [pcp] draft-chen-pcp-authentication-sim-00

Updated figure:

           |  1. PA-Initiation               |                             |                 |

-Tiru

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 18 Sep 2014 09:28:57 +0000

Hi Dacheng,

Inline [TR]

From: Zhangdacheng (Dacheng) [mailto:[email-masked]]
Sent: Thursday, September 18, 2014 1:26 PM
To: Tirumaleswar Reddy (tireddy); [email-masked]
Subject: RE: draft-chen-pcp-authentication-sim-00

In addition, in the base authentication protocol, it is assumed that EAP will be used to perform authentication. And the discussion in the document is all about how to transport EAP messages. So, if we want to combine the two document into a single one, the assumption will be broken and quite a lot of contents need to be adjusted (I would like to do the adjustment of course if the group decide to do so).

[TR] I am not proposing that these drafts be combined. But align the work in draft-pcp-authentication-sim with the existing PCP authentication draft.

For instance, in an authentication solution supporting different authentication protocols other than EAP, when a PCP client and a PCP server initially exchange their PA messages, they need to be able to negotiate the authentication protocols they would like to use, which is not considered in the current document. So, I think it might be a good idea to propose the two document separately. One is the based authentication protocol designed for EAP and one is the extension of base authentication protocol to support other authentication protocols.

[TR] After the negotiation of authentication protocol, ID-indicator can also be re-used (we may want try avoiding adding new option for each new out-of-band authentication protocol). In this draft I did not see any negotiation of the authentication protocol, client supports both EAP-SIM, HTTP authentication but it is forced to pick HTTP authentication because PCP server only supports this protocol.

-Tiru

Gang Chen has invited me to help him improve his work. So, I suggest the group  to decide the plan of next step first and then go into the discussion of design details.

Comments?

Cheers

Dacheng

From: pcp [mailto:[email-masked]] On Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Thursday, September 18, 2014 12:32 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [pcp] draft-chen-pcp-authentication-sim-00

Updated figure:

           |  1. PA-Initiation               |                             |                 |

-Tiru

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Thu, 18 Sep 2014 10:44:29 +0000

See my reply inline please. ^_^

Cheers

Dacheng

From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Sent: Thursday, September 18, 2014 5:29 PM
To: Zhangdacheng (Dacheng); [email-masked]
Subject: RE: draft-chen-pcp-authentication-sim-00

Hi Dacheng,

Inline [TR]

From: Zhangdacheng (Dacheng) [mailto:[email-masked]]
Sent: Thursday, September 18, 2014 1:26 PM
To: Tirumaleswar Reddy (tireddy); [email-masked]<mailto:[email-masked]>
Subject: RE: draft-chen-pcp-authentication-sim-00

[TR] I am not proposing that these drafts be combined. But align the work in draft-pcp-authentication-sim with the existing PCP authentication draft.
[Dacheng Zhang:] I see. ^_^

[TR] After the negotiation of authentication protocol, ID-indicator can also be re-used (we may want try avoiding adding new option for each new out-of-band authentication protocol). In this draft I did not see any negotiation of the authentication protocol, client supports both EAP-SIM, HTTP authentication but it is forced to pick HTTP authentication because PCP server only supports this protocol.
[Dacheng Zhang:]
When the authentication protocol is used to transport different authentication protocols, the option could be  re-used for different purposes. I agree with that. @Gang Chen, could you please clarify in your scenario whether a PCP server may need to help the client select proper certificates for authentication? If the answer is no, then we can re-use the ID indicator. If the answer is yes, then we may have to define a new option.

-Tiru

Comments?

Cheers

Dacheng

Updated figure:

           |  1. PA-Initiation               |                             |                 |

-Tiru

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 19 Sep 2014 04:23:25 +0000

Inline [TR2]

From: Zhangdacheng (Dacheng) [mailto:[email-masked]]
Sent: Thursday, September 18, 2014 4:14 PM
To: Tirumaleswar Reddy (tireddy); [email-masked]
Subject: RE: draft-chen-pcp-authentication-sim-00

Cheers

Dacheng

From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Sent: Thursday, September 18, 2014 5:29 PM
To: Zhangdacheng (Dacheng); [email-masked]<mailto:[email-masked]>
Subject: RE: draft-chen-pcp-authentication-sim-00

Hi Dacheng,

Inline [TR]

[TR] In this case, WWW-Authenticate response header will have parameters like realm to help the client pick right credentials. The ID indicator from server can be ignored by the client or if they negotiate to proceed with HTTP authentication then the PCP Server does not even have to send ID indicator option.

-Tiru

Comments?

Cheers

Dacheng

Updated figure:

           |  1. PA-Initiation               |                             |                 |

-Tiru

---

From: GangChen <[email-masked]>
Date: Mon, 22 Sep 2014 18:36:41 +0800

Dacheng,

2014-09-18 18:44 GMT+08:00, Zhangdacheng (Dacheng) <[email-masked]>:

> When the authentication protocol is used to transport different
> authentication protocols, the option could be  re-used for different
> purposes. I agree with that. @Gang Chen, could you please clarify in your
> scenario whether a PCP server may need to help the client select proper
> certificates for authentication? If the answer is no, then we can re-use the
> ID indicator. If the answer is yes, then we may have to define a new
> option.

PCP server doesn't have to tell the client to choose the certificates.
The MSK is stored in the (U)SIM. PCP client could choose the
credentials for authentication.

What PCP server told PCP client is to start HTTP process with BSF.  In
the draft-chen-pcp-authentication-sim-00, the result code
"BOOTSTRAPPING-INITIATION" is proposed. I guess it's also should be
considered.

Best Regards

Gang