Subject: [Pana] PANA WG last call: draft-ietf-pana-ipsec-04.txt

From: Alper Yegin <[email-masked]>
Date: Wed, 20 Oct 2004 16:49:11 -0700

This message announces the PANA WG last call on "PANA Enabling
IPsec-based Access Control" document (draft-ietf-pana-ipsec-04.txt). The
last call will conclude on Nov 3rd, 2004.

Please read and review the document, and register your feedback on the
PANA mailing list (even if it is a simple "I read the document and it is
ready to proceed.").

http://www.ietf.org/internet-drafts/draft-ietf-pana-ipsec-04.txt

Previously discussed and closed issues on this document can be found at:
http://danforsberg.info:8080/pana-issues/

- PANA WG Chairs

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

---

From: Alper Yegin <[email-masked]>
Date: Thu, 21 Oct 2004 10:23:56 -0700

This message announces the PANA WG last call on "Protocol for Carrying
Authentication for Network Access (PANA)" document
(draft-ietf-pana-pana-06.txt). The last call will conclude on Nov 4th,
2004.

Version 06 of the document is submitted to IETF and it is in the process
of publication. Until it is posted on the IETF repository, you can
access this latest revision at the following URL. Make sure to review
**-06**.

http://www.toshiba.com/tari/pana/draft-ietf-pana-pana-06.txt

- PANA WG Chairs

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sun, 26 Sep 2004 17:54:00 -0700

The document seems to be in a good shape and here are a few comments that i had.

1) In section 2.0,
      PANA Session:

          A PANA session begins with the handshake between the PANA Client
          (PaC) and the PANA Authentication Agent (PAA), and terminates as a
          result of an authentication failure, a timeout, or an explicit
          termination message.  A fixed session identifier is maintained
          throughout a session.  A session cannot be shared across multiple
          network interfaces.

     Can we explain the reason why the session cannot be shared across multiple network interfaces ?
      I could not find any other place in the document where this is explained (perhaps missed it).

2) In section 4.1,

      In any case, PANA MUST NOT generate an EAP message on behalf of EAP
      peer or EAP (pass-through) authenticator.

   This looked like a general statement and not specific section to 4.1. It might have been
   good to have a general section on how EAP maps to PANA or at least how PANA uses
   EAP.

3) In section 4.1,

      A Nonce AVP MUST be included in PANA-Start-Request and
      PANA-Start-Answer messages.  The nonces are used to establish a PANA
      SA.

    This is the first place Nonce is used but not defined/explained at to why nonce
     is needed ? I understand that it adds freshness to the key material used for PANA
     SA. But isn't that already taken care when AAA-key is derived.
     It might be good to point out the security property of using the
     Nonce in the PANA_MAC_KEY.

4) Section 4.3 Authorization phase :
        I am confused by the usage of word "Authorization". In the "Authentication phase",
        the PaC is in the process of getting authenticated. Similarly does it mean that the PaC
        is in the process of getting authorized ? So, if i send a PANA_SUCCESS at the end
        of authentication phase, by definition the node is both authenticated and authorized. So,
        i don't know what authorization phase means.

5) section 4.3 : It is not explained as to how the replay attack is prevented. The attacker can
    collect the ping answers and can bombard them. But the use of sequence numbers prevent
    the replay attack. Also, if there was a recent request/response exchange, that implies that
    the other side is alive because of the sequence number being acked. This can be used 
    as an optimization to not send the ping request.

6) In section 5.3, 

    When a request message is received, it is considered valid in terms
    of sequence numbers if and only if its sequence number matches the
    expected value.  This check does not apply to PANA-PAA-Discover, and
    the very first request messages.

   Expand "the very first request messages". 

7) In section 7.3,

     Vendor-Id

      The Vendor-Id field is present if the 'V' bit is set in the AVP
      Flags field.  The optional four-octet Vendor-Id field contains the
      IANA assigned "SMI Network Management Private Enterprise Codes"
      [ianaweb] value, encoded in network byte order.  Any vendor
      wishing to implement a vendor-specific PANA AVP MUST use their own
      Vendor-Id along with their privately managed AVP address space,
      guaranteeing that they will not collide with any other vendor's
      vendor-specific AVP(s), nor with future IETF applications.

I don't know why the privately managed AVP address space cannot overlap with
some other vendor specific AVPs ? Section 10.4.1 does not say anything.

8)  In section 11.1, you can note that the sequence number also can be used as liveness
     check.

Editorial
--------
1) In section 4.1,
    A PANA-Start-Request message MAY carry a Cookie AVP that contains a
   cookie.  The sequence number is set to a randomly picked initial
   sequence number.  The cookie is used for preventing the PAA from
   resource consumption DoS attacks by blind attackers.  

    s/blind attackers/attackers.

2) Section 11.8,

       11.8  Livenes Test

    s/Livenes Test/ Liveness Test

-mohan

---

From: Alper Yegin <[email-masked]>
Date: Fri, 29 Oct 2004 12:46:20 -0700

I have a long list of editorial comments that I'll send to the
editor/authors. Otherwise, I found just one technical issue:

The M (mandatory) bit is underspecified. We need more explanations about
when it is set, what happens when it is set/unset and an AVP is not
recognized, etc. Is it set for all AVPs defined in the base
specification? If so, let's state that.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 31 Oct 2004 11:14:15 -0500

My last call comments on draft-ietf-pana-ipsec-04.txt are available at
http://www.toshiba.com/tari/pana/draft-ietf-pana-ipsec-04_ohba-comments.txt.
Most are editorial comments.  There are three technical comments which
are shown below:

Technical comment 1 (on section 6):

"
           ID_KEY_ID data = (Session-Id | Key-Id)

   The Session-Id and Key-Id are the values contained in the data
   portion of the Session-Id and Key-Id AVP respectively [PANA-PROT].
   They are concatenated to form the content of ID_KEY_ID data. IP
   addresses cannot be used as identifier as the PaC may be re-
   authenticated multiple times and hence may not uniquely identify the
   pre-shared key.
"
$ohba(technical) I don't think the reason for why not using an IP
address of the PaC in ID_KEY_ID is because the PaC may be
*re-authenticated multiple times*.  The actual reason is that the same
PaC or a different PaC may use the same IP address *across a PANA
session*, e.g.,

PaC A acquires IP address X and establishes a PANA session.  After the
PANA session terminates for some reason, the same PaC A or another PaC
B acquires IP address X and establishes a new PANA session.  In this
case, if ID_KEY_ID data were defined as (PaC's IP address | Key-Id),
it would end up with having the same ID_KEY_ID for the two IKE
pre-shared keys derived from two different PANA sessions.

Technical comment 2 (on Appendix A):

"
        When [RFC3456] is used, DHCP is
        run over the IPsec tunnel and the address (IPsec-TIA) is
        assigned to the IPsec tunnel interface.
"

$ohba(technical) I am not sure RFC3456 assumes that IPsec tunnel mode
SA is always implemented as a logical IP interface.  Please check.
(If IPsec tunnel mode SA does not have to be implemented as a logical
IP interface, I think the same source address selection could exist.)

Technical comment 3 (on Appendix A):

"
        The link-local address
        (IPsec-TOA) is assigned to the physical interface. As there is
"

$ohba(technical) Why the IPsec-TOA needs to be a link-local address in
RFC3456?  It could be a non-link-local address, I think.

Best regards,

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 31 Oct 2004 23:08:38 -0500

These are my last call comments on draft-ietf-pana-pana-06.txt.

o Technical comment 1 (section 4.2)

"
   The PANA-Bind-Request and the PANA-Bind-Answer message exchange is
   also used for binding device identifiers of the PaC and EP(s), and
   the IP address of the PAA to the PANA SA.  To achieve this, the
   PANA-Bind-Request SHOULD contain the device identifier(s) of the
   EP(s) in Device-Id AVP(s) when they are either MAC or IP address(es),
   and the IP address of the PAA in an IP-Address AVP.  PANA-Bind-Answer
   SHOULD contain PaC's device identifier in a Device-Id AVP when it is
   already presented with that of EP(s).  The PaC MUST use the same type
   of device identifier as contained in the PANA-Bind-Request message.
"

The two "SHOULD" in the above text are ambiguous.  I think when a
Protection-Capability AVP is included in the PBR, a Device-Id AVP MUST
be included in order to indicate the MAC or IP address of each EP.
Also, when a Protection-Capability AVP is included, I think it is
always true that the device identifier of each EP is either MAC or IP
address.  On the other hand, when the PBR includes a Device-Id AVP, I
think that the PaC MUST include a Device-Id AVP in the PBA.  In this
case, what the PAA should do if the PAA sent a PBR with a
Protection-Capability AVP and one or more Device-Id AVP but the PBA
from the PaC does not contain any Device-Id AVP?  I think the right
behavior for this case is that the PAA sends a PANA-Error-Request
message with a PANA_MISSING_AVP result code and wait for a
PANA-Error-Answer message to terminate the session.

Suggested 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), and
   the IP address of the PAA to the PANA SA.  To achieve this, the
   PANA-Bind-Request message MUST contain the device identifier(s) of
   EP(s) in Device-Id AVP(s) when a Protection-Capability ASP is
   included in the message.  The PANA-Bind-Request message MUST also
   contain the IP address of the PAA in an IP-Address AVP.  The
   PANA-Bind-Answer message MUST contain the PaC's device identifier
   in a Device-Id AVP when it is already presented with that of EP(s)
   in the request with using the same type of device identifier as
   contained in the request.  If the PANA-Bind-Answer message sent
   from the PaC does not contain a Device-Id AVP with the same device
   identifier type contained in the request, the PAA sends a
   PANA-Error-Request message with a PANA_MISSING_AVP result code, and
   wait for a PANA-Error-Answer message to terminate the session.
"

o Technical comment 2 (section 4.2)

"
   The PANA-Bind-Request message MAY also contain a
   Protection-Capability AVP to indicate if link-layer or network-layer
   ciphering should be initiated after PANA.  
"

If the Result-Code AVP included in the PBR does not indicate
PANA_SUCCESS, I think a Protection-Capability AVP does not need to be
included (or SHOULD NOT be included, to avoid unnecessary information
disclosure to unauthorized clients) in the PBR and the corresponding
PBA.

Suggested change:

"
   The PANA-Bind-Request message with a PANA_SUCCESS result code MAY
   also contain a Protection-Capability AVP to indicate if link-layer
   or network-layer ciphering should be initiated after PANA.
"

o Technical comment 3 (section 4.2)

"
   Additionally, PANA-Bind-Request MUST include a
   Post-PANA-Address-Configuration AVP, which helps PAA to inform PaC
   about whether a new IP address MUST be configured and the available
   methods to do so.  PaC MUST include a PPAC AVP in order to indicate
   its choice of method when there is a match between the methods
   offered by the PAA and the methods available on the PaC.
"

If the Result-Code AVP included in the PBR does not indicate
PANA_SUCCESS, I think a PPAC AVP does not need to be included (or
SHOULD NOT be included, to avoid unnecessary information disclosure to
unauthorized clients) in the PBR and the corresponding PBA.  Also
there is some duplicated wording "PaC MUST include a PPAC AVP in order
to indicate" text in the text.

Suggested change:

"
   Additionally, the PANA-Bind-Request message with a PANA_SUCCESS
   result code MUST include a Post-PANA-Address-Configuration AVP,
   which helps the PAA to inform the PaC about whether a new IP
   address MUST be configured and the available methods to do so.  The
   PaC MUST include a PPAC AVP in the PANA-Bind-Answer message in
   order to indicate its choice of method when there is a match
   between the methods offered by the PAA and the methods available on
   the PaC.
"

o Technical comment 4 (section 6.2)

"
   Upon changing its point of attachment, a PaC that wants to quickly
   resume its ongoing PANA session without running EAP MAY send its
   unexpired PANA session identifier in its PANA-Start-Answer message.
   Along with the Session-Id AVP, a MAC AVP MUST be included in this
   message.  The MAC AVP is computed by using the PANA_MAC_KEY shared
   between the PaC and its previous PAA that has an unexpired PANA
   session with the PaC.  This action signals PaC's desire to perform
   the mobility optimization.  In the absence of a Session-Id AVP in
   this message, the PANA session takes its usual course (i.e.,
   EAP-based authentication is performed).
"

Since MAC for the PSR used for mobility handling is calculated by
using a different key other than the PANA_MAC_KEY that is to be
established between the PaC and the current PAA and used for
subsequent PANA messages, I would suggest using a separate AVP
(something like Mobility-Optimization-MAC AVP or Mobility-Token AVP )
for this special MAC carried in PSR rather than overloading the MAC
AVP to be used with different keys, in order to avoid possible
mis-implementation.

Best regards,
Yoshihiro Ohba