Subject: [Pana] pana-pana: issue168 proposed resolution

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 23 Jun 2005 14:35:01 -0400

[1] In section 4.3, change:

"
   The PANA-Bind-Request and the PANA-Bind-Answer message exchange is
   also used for binding device identifiers of the PaC and EP(s)to the
   PANA SA.  To achieve this, the PANA-Bind-Request message MUST contain
   the device identifier in a Device-Id AVP for each EP if a Protection-
   Capability AVP is included in the message.  Otherwise, the message
   SHOULD contain the device identifier in a Device-Id AVP for each EP
   when a link-layer or IP address is used as the device identifier of
   the PaC.
"

to:

"
   The PANA-Bind-Request and the PANA-Bind-Answer message exchange is
   also used for binding device identifiers of the PaC and EP(s) to
   the PANA SA.  To achieve this, if a Protection-Capability AVP is
   included in the PANA-Bind-Request message, the message MUST contain
   the device identifier in a Device-Id AVP for each EP when a
   link-layer or IP address is used as the device identifier of the 
   PaC.  Otherwise, if a Protection-Capability AVP is not included in
   the PANA-Bind-Request message, the message SHOULD contain the
   device identifier in a Device-Id AVP for each EP when a link-layer
   or IP address is used as the device identifier of the PaC.
"

[2] Add the following section 

"
5.X PaC-EP-Master-Key

As described in section 4.3, use of a cryptographic filtering
mechanism is indicated by inclusion of a Protection-Capability AVP in
the PANA-Bind-Request message in the authentication and authorization
phase.  In this case, a PaC-EP-Master-Key is derived from the
AAA-Key for each EP and used by a secure association protocol for
bootstrapping link-layer or IPsec ciphering betweeen the PaC and EP.
The PaC-EP-Master-Key derivation algorithm is defined as follows.

PaC-EP-Master-Key = HMAC-SHA-1 (AAA-Key, "PaC-EP master key" |
                                Session ID | Key-ID | EP-Device-Id)

EP-Device-Id is either the Data field of the Device-Id AVP for the
corresponding EP or null when the EP has a locally significant
identifier such as PPP interface id.  In the latter case, the
algorithm is equivalent to:

PaC-EP-Master-Key = HMAC-SHA-1 (AAA-Key, "PaC-EP master key" |
                                Session ID | Key-ID).

In the latter case, the PAA and EP MUST be co-located.
"

[3]  In section 10.5, change:

"
   When link-layer or network-layer ciphering [I-D.ietf-pana-ipsec] is
   enabled as a result of successful PANA authentication, a separate
   PaC-EP master key is generated based on the AAA-Key, session
   identifier, key identifier, and EP device identifier.
"

to:

"
   When link-layer or network-layer ciphering [I-D.ietf-pana-ipsec] is
   enabled as a result of successful PANA authentication, a
   PaC-EP-Master-Key is generated for each EP from the AAA-Key,
   session identifier, key identifier, and the EP device identifier.
   The PaC-EP-Master-Key derivation algorithm defined in section 5.X
   ensures cryptographic independency among different
   PaC-EP-Master-Keys.
"

Comments are appreciated,

Yoshihiro Ohba

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Alper Yegin <[email-masked]>
Date: Fri, 24 Jun 2005 11:14:40 -0700

Yoshi,

>    the device identifier in a Device-Id AVP for each EP << when a
>    PaC>>.  Otherwise, if a Protection-Capability AVP is not included
in
>    or IP address is used as the device identifier of the PaC.

When Protection-Capability AVP is included, there must be a device ID.
For that, the text between << >> above are not necessary imo.

Also, I think the second SHOULD can be a MUST. 

> algorithm is equivalent to:

I don't understand why we need to support NULL EP DI. PPP does not have
authentication support.

> Comments are appreciated,

Thanks.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 24 Jun 2005 14:02:26 -0400

> For that, the text between << >> above are not necessary imo.

This depends on whether we support bootstrapping PPP ciphers or not.
I think we can support it.  Please see my further comment on this
below.

> Also, I think the second SHOULD can be a MUST. 

OK.

> I don't understand why we need to support NULL EP DI. PPP does not have

I am not sure what do you mean by "PPP does not have authentication
support", but let me explain more.

PPP does not have a secure association protocol, but in the case of
PPP, the PaC-EP-Master-Key with NULL EP DI can be a cipher key itself,
e.g., a 56-bit key for DES encryption (RFC 2419) and a 168-bit key for
3DES (RFC 2420).  So I think it is possible to bootstrap PPP security
from PANA.  However, since PPP does not have a secure association
protocol, available ciphering mechanisms may be limited.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 24 Jun 2005 14:02:41 -0700

> protocol, available ciphering mechanisms may be limited.

PANA usage is for access control, which requires data origin
authentication in crypto-based deployments. Privacy (encryption) of data
traffic is just a by-product. As far as I know, PPP does not have
support for authentication. Hence, I don't think PPP is worth creating a
special case for it (NULL EP DI). Because, we cannot make a "secure
network" out of it even with that modification.

Alper

> > >    enabled as a result of successful PANA authentication, a
separate

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 24 Jun 2005 15:24:29 -0400

Now I see what you mean, I agree.

Yoshihiro Ohba