Subject: [Pana] Review of draft-ietf-pana-preauth-04.txt

From: <[email-masked]>
Date: Tue, 20 Jan 2009 20:17:17 +0100

Hi All, 

Here is my review of the draft.
I'm sorry but I haven't read yet the current exchange on this topic on the mailing list.
Therefore, most of my comments are maybe already covered by previous reviews.

BR,

Lionel

***********************************

General comment:

The document is quite in a good shape but some key points should clarify in order to understand the purpose of this document.

***********************************

Abstract

   This document defines an extension to the Protocol for carrying
   Authentication for Network Access (PANA) for proactively establishing
   a PANA SA (Security Association) between a PaC in one access network
   and a PAA in another access network to which the PaC may move.  The
   proposed method operates across multiple administrative domains.

[LM] I would avoid the use of too many acronyms in the abstract.
Proposed change:

   "This document defines an extension to the Protocol for carrying
   Authentication for Network Access (PANA) for proactively establishing
   a PANA sécurity association between a PANA Client in one access network
   and a PANA Authentication Agent in another access network to which the 
   PANA Client may move.  The proposed method operates across multiple
   administrative domains."

1.  Introduction

   The Protocol for carrying Authentication for Network Access (PANA)
   [RFC5191] carries EAP messages between a PaC (PANA Client) and a PAA
   (PANA Authentication Agent) in the access network.  If the PaC is a
   mobile device and is capable of moving one access network to another
   while running its applications, it is critical for the PaC to perform
   a handover seamlessly without degrading the performance of the
   applications during the handover period.  When the handover requires
   the PaC to establish a PANA session with the PAA in the new access
   network, the signaling to establish the PANA session should be
   completed as fast as possible.

   This document defines an extension to the PANA protocol [RFC5191]
   used for proactively executing EAP authentication and establishing a
   PANA SA (Security Association) between a PaC in an access network and
   a PAA in another access network to which the PaC may move.  The
   proposed method operates across multiple AAA domains.  The extension
   to the PANA protocol is designed to realize direct pre-authentication
   defined in [I-D.ietf-hokey-preauth-ps].

[LM] the multiple AAA domains case is not described in the document.

2.  Terminogy

   The following terms are used in this document in addition to the
   terms defined in [RFC5191].

   Serving PAA (SPAA):  A PAA that resides in the serving network and
      provides network access authentication for a particular PaC.  For
      simplicity, this document assumes that there is only one SPAA in
      the serving network while the pre-authentication mechanism
      described in this document is generally applicable to the case
      where there are two or more SPAAs in the serving network.

   Candidate PAA (CPAA):  A PAA that resides in a candidate network to
      which the PaC may move.  A CPAA for a particular PaC may be a SPAA
      for another PaC.

[LM] as you said, SPAA and CPAA are not tight to the notion of network but to the relationship with the PaC.
Why do not simply define SPAA as the current PAA having an PANA SA with the PaC and the CPAA as the new PAA with which an SA needs to be established?

   Pre-authentication:  Pre-authentication refers to EAP pre-
      authentication and defined as the utilization of EAP to pre-
      establish EAP keying material on an authenticator prior to arrival
      of the peer at the access network served by that authenticator
      [I-D.ietf-hokey-preauth-ps].  In this draft, EAP pre-
      authentication is performed between a PaC and a CPAA.

   Pre-authorization:  An authorization for a PaC, made by a CPAA for
      the PaC at the time of pre-authentication.

   Post-authorization:  An authorization for a PaC, made by a CPAA for
      the PaC when the CPAA becomes the SPAA for the PaC.

   Pre-authorization SA:  A PANA SA established between a PaC and its
      CPAA.

[LM] Why do not use Pre-PANA SA in that case? But see my comment below about Pre-/Post-PANA SA

   Post-authorization SA:  A PANA SA established between the PaC and its
      SPAA.

[LM] Why do not use Post-PANA SA in that case? But see my comment below about Pre-/Post-PANA SA

3.  Pre-authentication Procedure

   A PaC that supports pre-authentication may establish a PANA session
   for each CPAA.

   There may be several mechanisms for a PaC and a CPAA to discover each
   other.  However, such mechanisms are out of the scope of this
   document.

[LM] If possible, it would be maybe useful to provide at least one non-normative example for illustration.

   There may be a number of criteria for CPAA selection, the timing to
   start pre-authentication and the timing to make a pre-authorization
   SA a post-authorization SA (and hence the CPAA becomes the SPAA).
   Such criteria can be implementation specific and thus are outside the
   scope of this document.

   Pre-authentication may be initiated by both a PaC and a CPAA.  A new
   'E' (prE-authentication) bit is defined in the PANA header.  When
   pre-authentication is performed, the 'E' (prE-authentication) bit of
   PANA messages are set in order to indicate whether this PANA run is
   for pre-authentication.  Use of pre-authentication is negotiated as
   follows.

   o  When a PaC initiates pre-authentication, it sends a PANA-Client-
      Initiation (PCI) message with the 'E' (prE-authentication) bit
      set.  The PCI message MUST be unicast.  The CPAA responds with a
      PANA-Auth-Request (PAR) message with the 'S' (Start) and 'E' (prE-
      authentication) bits set only if it supports pre-authentication.
      Otherwise, it MUST silently discard the message.

[LM] The PCI message MUST be unicast to the CPAA.

   o  When a CPAA initiates pre-authentication, it sends a PAR message
      with the 'S' (Start) and 'E' (prE-authentication) bits set.  The
      PaC responds with a PANA-Auth-Answer (PAN) message with the 'S'
      (Start) and 'E' (prE-authentication) bits set only if it supports
      pre-authentication.  Otherwise, it MUST silently discard the
      message.

[LM] I assume that the PAR is unicast to the PaC...

   o  Once the PaC and CPAA have agreed on performing pre-authentication
      using the 'S' (Start) and 'E' (prE-authentication) bits, the
      subsequent PANA messages exchanged between them MUST have the 'E'
      (prE-authentication) bit set.

[LM] It could be useful to add here that this procedure can be performed with several CPAAs.
[LM] it could be also useful to say that the rest of the PANA exchange if for establishing the pre-PANA SA.
[LM] Is it assumed that the pre-PANA SA is established as new basic PANA SA? Basically, it would imply that the PaC is handling simultaneous PANA SA binding. and there is no pre- and Post-PANA SA, only multiple PANA SAs with several PAA. Both should be clarified in the procedure description.

   When a CPAA with which the PaC has a pre-authorization SA becomes the
   SPAA due to, e.g., movement of the PaC, the PaC performs an IP
   address update procedure defined in Section 5.6 of [RFC5191] in order
   to update the SPAA with the PaC's new address obtained from the new
   serving network.  PANA-Notification-Request (PNR) and PANA-
   Notification-Answer (PNA) messages with 'P' (Ping) bit set are used
   for this purpose.  The completion of the IP address update procedure
   will change the pre-authorization SA to a post-authorization SA.  In
   this case, the 'E' MUST NOT be set in the PNR and PNA messages and
   subsequent PANA messages.

[Skip]

4.  PANA Extensions

   A new 'E' (prE-authentication) bit is defined in Flags field of PANA
   header as follows.

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R S C A P I E r r r r r r r r r|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   E(PrE-authentication)  When pre-authentication is performed, the 'E'
      (prE-authentication) bit of PANA messages are set in order to
      indicate whether this PANA run is for establishing a pre-
      authorization SA.  The exact usage of this bit is described in
      Section 3.  This bit is to be assigned by IANA.

[LM] Even if everything is described in the section 3, it could also useful to add a specific section describing backward compatibility handling.

5.  Authorization and Accounting Considerations

   A pre-authorization and a post-authorization for the PaC may have
   different authorization policies.  For example, the pre-authorization
   policy may not allow the PaC to sent or receive packets through an

[LM] s/sent/send

   Enforcement Point (EP) that is under control of the CPAA, while both
   the pre-authorization and post-authorization policies may allow
   installing credentials to the EP, where the credentials are used for
   establishing a security association for per-packet cryptographic
   filtering.

   In an access network where accounting is performed, accounting starts
   when the pre-authorization SA becomes the post-authorization SA by
   default.  Depending on the pre-authorization policy, accounting may
   start immediately after the pre-authorization SA is established.

6.  Security Considerations

   Since the mechanism described in this document is designed to work
   across multiple access networks, each EP in the serving network
   SHOULD be configured to allow PANA messages to be forwarded between a
   PaC and a CPAA only if the PaC has a post-authorization SA with the
   SPAA in order to avoid an unauthorized PaC to initiate pre-
   authentication.  Also, each access network that supports pre-
   authentication SHOULD block pre-authentication attempts from networks
   from which a handover is not likely to occur.

[LM] If you have multiple networks between the PaC and the CPAA, how do know that you have to block this request? Maybe this question on blocking requests from external networks shoul be out of scope as well.

   When pre-authentication is initiated by a CPAA, it is possible that
   the PaC simultaneously communicates with multiple CPAAs initiating
   pre-authentication.  In order to avoid possible resource consumption
   attacks on the PaC caused by a blind attacker initiating pre-
   authentication for the PaC by changing source addresses, the PaC
   SHOULD limit the maximum number of CPAAs allowed to communicate.

   The pre-authentication mechanism defined in this document does not
   have an issue on context binding in which link-layer independent
   context carried over pre-authentication signaling is bound to the
   link-layer specific context [I-D.ietf-hokey-preauth-ps], because the
   same EAP transport protocol (i.e., PANA) is used for normal
   authentication and pre-authentication in the candidate network.

[end of my comment]
_______________________________________________
Pana mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pana

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 21 Jan 2009 12:17:12 -0500

---

From: Subir Das <[email-masked]>
Date: Thu, 22 Jan 2009 01:43:35 -0500

by others and sorry for the delay.

regards,
_Subir

1. Introduction

*** moving 'from' one access network ***

proposed method operates across multiple AAA domains.

*** In abstract ‘administrative domains’ but above ‘AAA domains’ are used.

Are they same? The document should use a consistent terminology.

2. Terminogy

*** Not sure I understand the relevance of this in the definition ***

*** Do we need for the Pac again? Alternatively we can possibly say

‘An Authorization made by CPAA for a PaC at the time of pre-authentication”

*** same as above ***

*** the text in the parenthesis is not clear ***

*** Missing ‘bit’ after ‘E’ ***

If there is another CPAA with which the PaC has a pre-authorization

SA and the PaC wants to keep the pre-authorization SA after the

change of SPAA, the PaC also performs an IP address update procedure

defined in Section 5.6 of [RFC5191] in order to update the CPAA with

the PaC's new address.

*** Not clear the purpose of the above operation. Even if PaC performs 
IP address
update, how long does it keep this SA? For example, if PaC moves to 
another CPAA does

it still need to maintain and continue this operation ? ***

PNR and PNA messages with 'P' (Ping) bit set is used for this purpose.

*** typo: should be ‘are’ ***

In this case, the 'E' (prE-authentication)

bit MUST be set in the PNR and PNA messages and subsequent PANA

messages. The IP address update procedure with the CPAA will not

change the pre-authorization SA to a post-authorization SA.

The pre-authorization SA and the corresponding PANA session between

the PaC and a CPAA is deleted by entering the termination phase of

the PANA protocol.

*** What will happen if Pac has multiple such pre-authorization SAs? ***

authorization SA.

*** Typo: should be ‘is’

policy may not allow the PaC to sent or receive packets

*** Typo: should be ‘send’ ***

Security Considerations

authentication.

*** Not sure I understand the above. How a post-authorization with the
SPAA obtained in the first place? ***

Also, each access network that supports pre-

*** Is there any relationship between handover protocol and pre-auth?

How does access network will know that handover is not likely to occur? ***