Subject: Re: [Pana] NEW: [issue73] DI on DSL

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 16 Apr 2004 13:41:13 -0700

On Fri, Mar 19, 2004 at 09:03:55AM +0200, [email-masked] wrote:
> From Alper..
> 
> New submission from Dan Forsberg <[email-masked]>:
> 
> What type of DI will be used on DSL networks? A lower-layer per-packet
> identifier (source address) might not be available in all deployments. In
> that case, a different type of identifier, such as "physical interface on the 
> PAA" might be used. That interface might be a virtual circuit dedicated to a 
> PaC.

In the case where physical interface of the PAA is used for
identifying the PaC, the PAA always knows it and thus the physical
interface information does not need to be carried by PANA.  Regarding
virtual circuit information, it might depend on whether an attacker
can sit on the path between PaC and PAA in the DSL access network and
spoof the virtual circuit id.

Yoshihiro Ohba

> 
> ----------
> category: Technical
> document: draft-ietf-pana-pana-xx.txt
> messages: 244
> nosy: dforsber
> priority: Should Fix
> status: Pending
> title: DI on DSL
> __________________________________________________
> PANA Issues <[email-masked]>
> <http://danforsberg.info:8080/pana-issues/issue73>
> __________________________________________________

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 16 Apr 2004 13:41:13 -0700

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Mon, 19 Apr 2004 11:59:20 -0700

> > identifier (source address) might not be available in all
deployments.
> In
> > that case, a different type of identifier, such as "physical
interface
> on the
> > PAA" might be used. That interface might be a virtual circuit
dedicated
> to a
> interface information does not need to be carried by PANA. 

So, carrying device ID in PANA signaling becomes optional. PAA wouldn't
send a device ID in the PBR, and PaC won't respond with one either in
cases where a device ID is not carried on the IP packets. 

I think the assumption is, upon receipt of PANA packets from the
lower-layer, PAA and PaC modules should be provided with some local
auxiliary data (possibly an implementation/technology specific interface
identifier). I think we also assume that these are point-to-point
interfaces. So, anything coming from interfaceX is always coming from
the node connected to that interface.

> Regarding

With respect to MitM attacks, I think virtual and physical circuits are
not any different. 

Alper

---

From: Alper Yegin <[email-masked]>
Date: Mon, 19 Apr 2004 11:59:20 -0700

deployments.
interface
dedicated

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 19 Apr 2004 12:50:10 -0700

On Mon, Apr 19, 2004 at 11:59:20AM -0700, Alper Yegin wrote:
> So, carrying device ID in PANA signaling becomes optional. 

I think the device ID in PANA signaling is already an optional
feature, but if there is still "SHOULD" or "MUST" wording on carring
device id in PBR/PBA in the specification, it should be changed to
"MAY".

> PAA wouldn't

Yes, and I think this is a valid an assumption for the following
reason.  If the PAA itself is not able to know which physical
interface on which a packet is received, the interface information
should be explicitly carried in higher-layer (i.e., PANA) packets, but
it would be much more difficult for the PaC to know or specify which
the PAA's physical interface it is connected.

> With respect to MitM attacks, I think virtual and physical circuits are

I think so, too.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 19 Apr 2004 12:50:10 -0700

I think so, too.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Thu, 22 Apr 2004 17:04:23 -0700

Proposed updates for handling this issue....

[1] In section 4.1.7: 

Change from: 

   o  When a device identifier of the communication peer is bound to the
      PANA session, it matches the device identifier carried in MAC and/
      or IP header(s).

To:

   o  When a device identifier of the communication peer is bound to the
      PANA session, it matches the device identifier carried in MAC and/
      or IP header(s), or other auxiliary indetifier provided by the 
      lower-layers (e.g., circuit ID).

[2] In section 4.3:

Change from:

   When an EAP method that is capable of deriving keys is used during
   the authentication phase and the keys are successfully derived the
   PANA-Bind-Request and PANA-Bind-Answer messages and all subsequent
   PANA messages MUST contain a MAC AVP.  The PANA-Bind-Request and the
   PANA-Bind-Answer message exchange is also used for binding device
   identifiers of the PaC and the PAA to the PANA SA. To achieve this,
   the PANA-Bind-Request and the PANA-Bind-Answer SHOULD contain a
   device identifier of the PAA and the PaC, respectively, in a
   Device-Id AVP.  The PaC MUST use the same type of device identifier
   as contained in the PANA-Bind-Request message.  

To:

   When an EAP method that is capable of deriving keys is used during
   the authentication phase and the keys are successfully derived the
   PANA-Bind-Request and PANA-Bind-Answer messages and all subsequent
   PANA messages MUST contain a MAC AVP.  The PANA-Bind-Request and the
   PANA-Bind-Answer message exchange is also used for binding device
   identifiers of the PaC and the PAA to the PANA SA when the
identifiers
   are either IP or MAC addresses. To achieve this, the
PANA-Bind-Request 
   and the PANA-Bind-Answer SHOULD contain a device identifier of the 
   PAA and the PaC, respectively, in a Device-Id AVP.  The PaC MUST 
   use the same type of device identifier as contained in the 
   PANA-Bind-Request message.  

[3] Section 4.7 Device ID Choice:

Change from:

   A PaC SHOULD configure an IP address before PANA if it can. It might
   either have a pre-configured IP address, or have to obtain one via
   dynamic methods such as DHCP or stateless address autoconfiguration.
   Dynamic methods may or may not succeed depending on the local
   security policy.  In networks where clients have to be authorized
   before they are allowed to obtain an IP address, EPs will detect the
   associated activity and PANA protocol will be engaged before the
   clients can configure a valid IP address.

   Either an IP address or a link-layer address SHOULD be used as device
   ID at any time. It is assumed that PAA knows the security mechanisms
   being provided or required on the access network (e.g., based on
   physical security, link-layer ciphers enabled before or after PANA,
   or IPsec). When IPsec-based mechanism [I-D.ietf-pana-ipsec] is the
   choice of access control, PAA SHOULD provide its IP address as device
   ID, and expect the PaC to provide its IP address in return.  In all
   other cases, link-layer addresses can be provided from both sides.

To:

   The device identifiers used in the context of PANA can be an IP
address,
   a MAC address, or an identifier that is not carried on data packets
   but has local significance in identifying a connected host (e.g., 
   circuit ID). The last type of identifiers are commonly used in 
   physically secured point-to-point links where MAC addresses are not
   available. 

   It is assumed that PAA knows the link type and the security
mechanisms 
   being provided or required on the access network (e.g., based on
physical 
   security, link-layer ciphers enabled before or after PANA, or IPsec)
   Based on that information, the PAA can decide what type of device ID
   will be used when running PANA with the client. When IPsec-based 
   mechanism [I-D.ietf-pana-ipsec] is the choice of access control, PAA 
   SHOULD provide an IP address as device ID, and expect the PaC to
provide 
   its IP address in return. In case IPsec is not used, MAC addresses
are 
   used as device IDs when available. If non-IPsec access control is
enabled, 
   and a MAC address is not available, device ID exchange does not occur

   within PANA. Instead, peers rely on lower-layers to provide 
   locally-significant identifiers along with received PANA packets. 

[4] Section 4.9:

Change from:

   In case the new PAA retrieves the on-going PANA session attributes
   from the previous PAA, the PANA session continues with a PANA-Reauth
   exchange.  The MAC AVP contained in the PANA-Reauth messages MUST be
   generated and verified by using the retrieved PANA SA attributes.
   This exchange MUST also include Session-Id AVP that contains the
   newly assigned session identifier, and Device-Id AVP. A new PANA
   session is created upon successful completion of this exchange. This
   session inherits only the session lifetime, protection capability,
   and AAA-Key attributes from the previous session. Other attributes
   are generated based on the PANA exchanges on the new link. While
   AAA-Key stays the same, a new PANA_MAC_Key is computed using the new
   parameters. Subsequent MAC-AVPs are processed using this new PANA SA.

To:

   In case the new PAA retrieves the on-going PANA session attributes
   from the previous PAA, the PANA session continues with a PANA-Reauth
   exchange.  The MAC AVP contained in the PANA-Reauth messages MUST be
   generated and verified by using the retrieved PANA SA attributes.
   This exchange MUST also include Session-Id AVP that contains the
   newly assigned session identifier, and MAY include Device-Id AVP. 
   A new PANA session is created upon successful completion of this
exchange. 
   This session inherits only the session lifetime, protection
capability,
   and AAA-Key attributes from the previous session. Other attributes
   are generated based on the PANA exchanges on the new link. While
   AAA-Key stays the same, a new PANA_MAC_Key is computed using the new
   parameters. Subsequent MAC-AVPs are processed using this new PANA SA.

[5] Updated 9.3.7:

9.3.7 PANA-Bind-Request (PBR)

   PANA-Bind-Request (PBR) is sent by the PAA to the PaC.

         PANA-Bind-Request ::= < PANA-Header: 4, REQ >
                       < Session-Id >
                       { EAP-Payload }
                       { Result-Code }
                       [ Device-Id ]
                       [ Session-Lifetime ]
                       [ Protection-Capability ]
                       [ Key-Id ]
                    *  [ EP-Device-Id ]
                    *  [ AVP ]
                   0*1 < MAC >

[6] Updated 9.3.8:

9.3.8 PANA-Bind-Answer (PBA)

   PANA-Bind-Answer (PBA) is sent by the PaC to the PAA in response to a
   PANA-Result-Request message.

         PANA-Bind-Answer ::= < PANA-Header: 4 >
                       < Session-Id >
                       [ Device-Id ]
                       [ Key-Id ]
                    *  [ AVP ]
                   0*1 < MAC >

[7] Updated 9.3.9:

9.3.9 PANA-Reauth-Request (PRAR)

   PANA-Reauth-Request (PRAR) is either sent by the PaC or the PAA.

         PANA-Reauth-Request ::= < PANA-Header: 5, REQ >
                       < Session-Id >
                       [ Device-Id ]
                    *  [ AVP ]
                   0*1 < MAC >

[8] Updated 9.3.10:

9.3.10 PANA-Reauth-Answer (PRAA)

   PANA-Reauth-Answer (PRAA) is sent in response to a
   PANA-Reauth-Request.

         PANA-Reauth-Answer ::= < PANA-Header: 5 >
                       < Session-Id >
                       [ Device-Id ]
                    *  [ AVP ]
                   0*1 < MAC >

[9] Updated tables from 9.5:

                          +-----------------------------------------+
                          |        Message                          |
                          |          Type                           |
                          +-----+-----+-----+-----+-----+-----+-----+
      Attribute Name      | PSR | PSA | PAR | PAN | PBR | PBA | PDI |
      --------------------+-----+-----+-----+-----+-----+-----+-----+
      Result-Code         |  0  |  0  |  0  |  0  |  1  |  0  |  0  |
      Session-Id          |  0  |  0  |  1  |  1  |  1  |  1  | 0-1 |
      Termination-Cause   |  0  |  0  |  0  |  0  |  0  |  0  |  0  |
      EAP-Payload         | 0-1 | 0-1 |  1  |  1  |  1  |  0  |  0  |
      MAC                 |  0  |  0  | 0-1 | 0-1 | 0-1 | 0-1 |  0  |
      Device-Id           |  0  |  0  |  0  |  0  | 0-1 | 0-1 |  0  |
      Cookie              | 0-1 | 0-1 |  0  |  0  |  0  |  0  |  0  |
      Protection-Cap.     |  0  |  0  |  0  |  0  | 0-1 |  0  |  0  |
      Session-Lifetime    |  0  |  0  |  0  |  0  | 0-1 |  0  |  0  |
      Failed-AVP          |  0  |  0  |  0  |  0  |  0  |  0  |  0  |
      ISP-Information     |  0+ | 0-1 | 0-1 |  0  |  0  |  0  |  0  |
      NAP-Information     | 0-1 |  0  | 0-1 |  0  |  0  |  0  |  0  |
      EP-Device-Id        |  0  |  0  |  0  |  0  |  0+ |  0  |  0  |
      Key-Id              |  0  |  0  |  0  |  0  | 0-1 | 0-1 |  0  |
      --------------------+-----+-----+-----+-----+-----+-----+-----+

                          +-------------------------------+
                          |      Message                  |
                          |       Type                    |
                          +------+------+-----+-----+-----+
      Attribute Name      | PRAR | PRAA | PTR | PTA | PER |
      --------------------+------+------+-----+-----+-----+
      Result-Code         |  0   |  0   |  0  |  0  |  1  |
      Session-Id          |  1   |  1   |  1  |  1  |  1  |
      Termination-Cause   |  0   |  0   |  1  |  0  |  0  |
      EAP-Payload         | 0-1  | 0-1  |  0  |  0  |  0  |
      MAC                 | 0-1  | 0-1  | 0-1 | 0-1 | 0-1 |
      Device-Id           | 0-1  | 0-1  |  0  |  0  |  0  |
      Cookie              |  0   |  0   |  0  |  0  |  0  |
      Protection-Cap.     |  0   |  0   |  0  |  0  |  0  |
      Session-Lifetime    |  0   |  0   |  0  |  0  |  0  |
      Failed-AVP          |  0   |  0   |  0  |  0  |  1  |
      ISP-Information     |  0   |  0   |  0  |  0  |  0  |
      NAP-Information     |  0   |  0   |  0  |  0  |  0  |
      EP-Device-Id        |  0   |  0   |  0  |  0  |  0  |
      Key-Id              |  0   |  0   |  0  |  0  |  0  |
      --------------------+------+------+-----+-----+-----+

---

From: Alper Yegin <[email-masked]>
Date: Thu, 22 Apr 2004 17:04:23 -0700

[1] In section 4.1.7: 

Change from: 

To:

[2] In section 4.3:

Change from:

To:

Change from:

To:

[4] Section 4.9:

Change from:

To:

[5] Updated 9.3.7:

[6] Updated 9.3.8:

[7] Updated 9.3.9:

[8] Updated 9.3.10:

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 22 Apr 2004 19:34:45 -0700

I have just one comment.

>    exchange.  The MAC AVP contained in the PANA-Reauth messages MUST be

I guess the resolution of issue 74 will replace PANA-Reauth exchange 
with PANA-Bind exchange.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 22 Apr 2004 19:34:45 -0700

I have just one comment.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 23 Apr 2004 12:49:32 -0700

Yoshi,

You are right.

Since you are editing the draft, let me say: Resolution to different
issues are sometimes impacting the same section in the draft. When
merging updates are not straight forward, please ask for help. For
example, I can give you the final section 4.9, once we agree on the
individual changes.

Alper

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: Thursday, April 22, 2004 7:35 PM
> To: Alper Yegin
> Cc: [email-masked]
> Subject: Re: [Pana] NEW: [issue73] DI on DSL
> 
> I have just one comment.
>

---

From: Alper Yegin <[email-masked]>
Date: Fri, 23 Apr 2004 12:49:32 -0700

Yoshi,

You are right.

Alper