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

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 27 Jan 2009 14:53:57 -0500

Let me forward my response to Lionel as the response stored in the ML
archive is empty...

Yoshihiro Ohba

----- Forwarded message from Yoshihiro Ohba <[email-masked]> -----

From: Yoshihiro Ohba <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Pana] Review of draft-ietf-pana-preauth-04.txt
User-Agent: Mutt/1.5.18 (2008-05-17)
X-UIDL: aH^"!X>*"!JY0!!m&K!!

Hi Lionel,

Thank you very much for your review.  Please see my comments below.

On Tue, Jan 20, 2009 at 08:17:17PM +0100, [email-masked] wrote:
> 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."

I agree.

> 
> 
> 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.

We can delete the sentence "The proposed method operates across
multiple AAA domains."

> 
> 
> 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?

That is because even after a PANA SA is established with the CPAA, the
PaC may hold the SA without moving to the access network of the CPAA,
and the CPAA with the established PANA SA still needs to be
distinguished from the SPAA.

> 
> 
>    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

Please see my comment below.

> 
> 
> 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.

I am afraid if we described non-normative text for out-of-scope
things, then people may say delete it.

> 
>    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.

Alper had a comment to delete "The PCI message MUST be unicast."

> 
>    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...

Yes.

> 
>    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.

I agree.

> [LM] it could be also useful to say that the rest of the PANA exchange if for establishing the pre-PANA SA.

I agree.

> [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.

I agree.  Basically this issue is the same as the one Alper and Rafa
raised.  We are trying to address the issue by replacing
pre-authorization SA and post-authorization SA with pre-authorization
state and post-authorization state, respectively.

> 
>    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.

We can certainly add a new section on 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

OK.

> 
>    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.

This issue was also raised by Alper and Rafa, and revised text has
been proposed in response to Alper's email.

Thank you,

Yoshihiro Ohba

----- End forwarded message -----
_______________________________________________
Pana mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pana
_______________________________________________
Pana mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pana