Subject: [Pana] Section 4 (Issues 220, 221, 222, 223, 224, 225, 226, 227)

From: "Alper Yegin" <[email-masked]>
Date: Mon, 6 Feb 2006 17:22:56 +0200

Revised Section 4 based on AD review is below. "CHANGE" marks where a
change was made, "REMARK" signifies a note for the ML readers. Both must be
omitted in the final text.

4.  Protocol Details

   The following sections explain in detail the various phases of a PANA
   session.

4.1  Transport Layer

   PANA uses UDP as its transport layer protocol.  The UDP port number
   is To Be Assigned by IANA.  All messages except for PANA-PAA-Discover
   are always unicast.  The PANA-PAA-Discover message MAY be unicast
   when the PaC knows the IP address of the PAA.

4.2  Payload Encoding

CHANGE: Editorial addition at the very end of the paragraph.

   The payload of any PANA message consists of zero or more AVPs
   (Attribute Value Pairs).  The subsequent sections refer to these
   AVPs, therefore the list of AVPs are provided with a brief
   description before more extensive descriptions are included later in
   the document (see Section 8).

CHANGE: Issue 220 handled below by giving reference to RFC4086. Same must be
done in Section 8.1.

   o  Cookie AVP: contains a random value that is generated by the PAA
      according to [RFC4086] and used for making PAA discovery robust
      against blind resource consumption DoS attacks.

   o  Protection-Capability AVP: contains the type of per-packet
      protection (link-layer vs. network-layer) when a cryptographic
      mechanism should be enabled after PANA authentication.

   o  Device-Id AVP: contains a device identifier (link-layer address or
      an IP address) of the PaC or an EP.

   o  EAP AVP: contains an EAP PDU.

CHANGE: Replaced "MAC" with "AUTH" per issue 221. Editor: I've only changed
this one instance. Please make sure to carry this change across the
document.

   o  AUTH AVP: contains a Message Authentication Code that integrity
      protects the PANA message.

   o  Termination-Cause AVP: contains the reason of session termination.

   o  Result-Code AVP: contains information about the protocol execution
      results.

   o  Session-Id AVP: contains the PANA session identifier value.

   o  Session-Lifetime AVP: contains the duration of authorized access.

   o  Failed-AVP: contains an offending AVP that caused a failure.

   o  Provider-Identifier AVP: contains the identifier of a NAP or an
      ISP.

   o  Provider-Name AVP: contains a name of a NAP or an ISP.

   o  NAP-Information AVP, ISP-Information AVP: contains the identifier
      of a NAP and an ISP, respectively.

   o  Key-Id AVP: contains a AAA-Key identifier.

   o  PPAC AVP: Post-PANA-Address-Configuration AVP.  Used to indicate
      the available/chosen IP address configuration methods that can be
      used by the PaC after successful PANA authentication.

CHANGE: Included the reference to RFC 4086.

   o  Nonce AVP: contains a randomly chosen value [RFC4086] that is used in
      cryptographic key computations.

   o  Notification AVP: contains a displayable message.

4.3  Discovery and Handshake Phase

CHANGE: Paragraph updated for issue 222.

   When the PaC knows the IP address of the PAA, it can send a unicast
   PANA-PAA-Discover message and initiate the PANA exchange. In other
   cases, the PaC MUST rely on dynamic discovery methods, such
   as multicast-based and a traffic-driven discovery.

CHANGE: Add the following subtitle (no subsection numbering).

   Multicast-based Discovery:

   The PaCs and PAAs MUST implement multicast-based discovery where the
   PaC sends a PANA-PAA-Discover message to a well-known
   administratively scoped multicast address (To Be Assigned by IANA)
   and UDP port (To Be Assigned by IANA).

   The network administrator MUST configure the multicast scope such
   that the discovery messages can reach only the designated PAA(s).  In
   case the PAA(s) is on the same link as the PaC, the administratively
   scoped multicast messages MUST not be forwarded by the routers.
   Details of scope configuration are discussed in [RFC2365].

   The PAA(s) that receive the discovery message MUST respond with a
   unicast PANA-Start-Request message sent to the soliciting PaC.

CHANGE: Add the following subtitle (no subsection numbering).

   Traffic-driven Discovery:

   Alternatively, the PaC MAY also choose to start sending data packets
   before getting authenticated.  The EP in an access network that
   implements PANA SHOULD drop such unauthorized packets upon receipt.
   Additionally, the EP MAY also take this traffic as an indication of
   unauthorized PaC and notify the PAA.  The EP-to-PAA notification
   SHOULD be sent via [I-D.ietf-pana-snmp].  In response, the PAA SHOULD
   send an unsolicited PANA-Start-Request message to the PaC.  This is
   called traffic-driven PAA discovery (an alternative to the PaC
   explicitly soliciting for a PAA).  Deployment of this alternate
   scheme is optional.

CHANGE: Add the following subtitle (no subsection numbering).

   Other Alternatives:

   The EP-to-PAA notification MAY also be generated in response to
   receiving a link-up event notification on the EP [I-D.ietf-dna-link-
   information].

   Alternative PAA discovery schemes may be designed (e.g., DHCP-based)
   but they are outside the scope of this specification.

CHANGE: Moved the "unicast discovery" paragraph that used to be here to top.

   When the PaC receives a PANA-Start-Request message from a PAA, it
   responds with a PANA-Start-Answer message if it wishes to enter the
   authentication and authorization phase.

   There can be multiple PAAs in the access network and the PaC may
   receive multiple PANA-Start-Request messages from those PAAs.  The
   authentication and authorization result does not depend on which PAA
   is chosen by the PaC.  By default the PaC MAY choose the PAA that
   sent the first PANA-Start-Request message.

CHANGE: Following paragraph revised for handling issue 222 (DoS prevention).

   A PANA-Start-Request message MAY carry a Cookie AVP that contains a
   random value generated by the PAA.  The random value is referred to
   as a cookie.  The cookie is used for preventing the PAA from resource
   consumption DoS attacks by blind attackers which bombard the PAA with
   PANA-PAA-Discover messages.  By relying on a cookie mechanism the PAA
   can avoid per-PaC state creation until after the PaC can produce the
   same cookie in its PANA-Start-Answer message.  In order to do that,
   the cookie MUST be computed in such a way that it does not require
   any per-session state maintenance on the PAA in order to verify the
   cookie returned in the PANA-Start-Answer message.  The PAA discovery
   that takes advantage of cookies is called "stateless PAA discovery".
   The exact algorithms and syntax used by the PAA to generate cookies
   does not affect interoperability and hence is not specified here.  
   Additionally, the PAA MAY limit the rate it processes incoming 
   PANA-PAA-Discover messages.

CHANGE: Cookie example that used to be here is now removed per issue 223.

   When the PaC sends a PANA-Start-Answer message in response to a PANA-
   Start-Request containing a Cookie AVP, the answer MUST contain a
   Cookie AVP with the cookie value copied from the request.

CHANGE: Clarification modification on the next paragraph for issue 223.

   When the PAA receives the PANA-Start-Answer message from the PaC, it
   verifies the cookie.  The cookie is considered as valid if the
   received cookie matches the send cookie. If the match is verified, 
   the protocol enters the authentication and authorization
   phase.  Otherwise, the PAA MUST silently discard the received message.

   The initial EAP Request message MAY be optionally carried by the
   PANA-Start-Request (as opposed to by a later PANA-Auth-Request)
   message in order to reduce the number of round-trips.  This
   optimization SHOULD NOT be used if the PAA discovery is desired to be
   stateless since transmission of an EAP Request message creates a
   state at EAP layer.  See [I-D.ietf-eap-statemachine] for more
   information on the EAP state machine and the allocation of state
   information in the respective protocol steps.

REMARK: AD comment on the complexity was captured in issue 224. Despite the
added complexity, recommendation is to keep the stateless discovery feature.
That feature becomes more important with PAAs deployed multiple-hops away
from the PaCs. For that, no change was made to the text. 

   A Protection-Capability AVP and a Post-PANA-Address-Configuration
   (PPAC) AVP MAY be included in the PANA-Start-Request in order to
   indicate required and available capabilities for the network access.
   These AVPs MAY be used by the PaC for assessing the capability match
   even before the authentication takes place.  Since these AVPs are
   provided during the insecure discovery and handshake phase, there are
   certain security risks involved in using the provided information.
   See Section 11 for further discussion on this.

   If the initial EAP Request message is carried in the PANA-Start-
   Request message, an EAP Response message MUST be carried in the PANA-
   Start-Answer message returned to the PAA.

   The PANA-Start-Request/Answer exchange is needed before entering the
   authentication and authorization phase even when the PaC is pre-
   configured with the IP address of the PAA and the PANA-PAA-Discover
   message is unicast.

   A Nonce AVP MUST be included in the first PANA-Auth-Request and PANA-
   Auth-Answer messages in the authentication and authorization phase
   when stateless PAA discovery is used, and in PANA-Start-Request and
   PANA-Start-Answer messages in this phase otherwise.

CHANGE: Following paragraph is revised for handling issue 225. An explicit
flag is defined in the PANA message header to indicate stateless discovery,
as opposed to using the "cookie" as a hint. Please see the far end of the
message for changes in appropriate sections for the introduction of this new
flag.

   A PANA-Start-Request message in stateless PAA discovery MUST NOT be
   retransmitted as this voids the statelessness on the PAA.  Instead,
   the PaC MUST retransmit the PANA-PAA-Discover message until it
   receives a PANA-Start-Request message, and retransmit the PANA-Start-
   Answer message until it receives a PANA-Auth-Request message.  The
   PaC can determine whether the PAA is using stateless PAA discovery by
   looking at the L-flag in the PANA header. The PANA-Start-Request message 
   MUST be retransmitted instead of the PANA-Start-Answer message when 
   stateful PAA discovery is used (L-flag is not set).

   It is possible that both the PAA and the PaC initiate the discovery
   and handshake procedure at the same time, i.e., the PAA sends a PANA-
   Start-Request message while the PaC sends a PANA-PAA-Discover
   message.  To resolve the race condition, the PAA SHOULD silently
   discard the PANA-PAA-Discover message received from the PaC after it
   has sent a PANA-Start-Request message with creating a state (i.e., 
   L-flag is not set) for the PaC.  In this case the
   PAA will retransmit the PANA-Start-Request message based on a timer,
   if the PaC doesn't respond in time (the message was lost for
   example).  If the PAA had sent a PANA-Start-Request message without
   creating a state for the PaC (i.e., L-flag is set), then it SHOULD answer
   to the PANA-PAA-Discover message.

   Figure 2 shows an example sequence for the discovery and handshake
   phase when a PANA-PAA-Discover message is sent by the PaC.  Figure 3
   shows an example sequence for the discovery and handshake phase with
   traffic-driven PAA discovery.

      PaC      PAA         Message(sequence number)[AVPs]
      ------------------------------------------------------
         ----->            PANA-PAA-Discover(0)
         <-----            PANA-Start-Request(x)[Cookie]
         ----->            PANA-Start-Answer(x)[Cookie]
                           (continued to the authentication and
                            authorization phase)

   Figure 2: Example sequence for the discovery and handshake phase when
                   PANA-PAA-Discover is sent by the PaC

      PaC   EP      PAA    Message(sequence number)[AVPs]
      ------------------------------------------------------
       ---->o              (Data packet arrival or L2 trigger)
             ------>       PAA-to-EP protocol, or another mechanism
       <------------       PANA-Start-Request(x)[Cookie]
       ------------>       PANA-Start-Answer(x)[Cookie]
                           (continued to the authentication and
                            authorization phase)

   Figure 3: Example sequence for the discovery and handshake phase with
                       traffic-driven PAA discovery

4.4  Authentication and Authorization Phase

   The main task of the authentication and authorization phase is to
   carry EAP messages between the PaC and the PAA.  EAP Request and
   Response messages are carried in PANA-Auth-Request messages.  PANA-
   Auth-Answer messages are simply used to acknowledge receipt of the
   requests.  As an optimization, a PANA-Auth-Answer message MAY include
   the EAP Response message.  This optimization MAY not be used when it
   takes time to generate the EAP Response message (due to, e.g.,
   intervention of human input), in which case returning an EAP-Auth-
   Answer message without piggybacking an EAP Response message can avoid
   unnecessary retransmission of the PANA-Auth-Request message.  Another
   optimization allows optionally carrying the first EAP Request/
   Response message in PANA-Start-Request/Answer message as described in
   Section 4.3.

   When stateless PAA discovery was performed in the discovery and
   handshake phase, a Nonce AVP MUST be included in the first PANA-Auth-
   Request and PANA-Auth-Answer messages.

   PANA allows execution of two separate authentication methods, one
   with NAP and one with ISP under the same PANA session.  This optional
   feature may be offered by the PAA and accepted by the PaC.  When
   performed separately, the result of the first EAP authentication is
   signaled via PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer
   message exchange which delineates the first method execution from the
   next.  See Section 4.8 for a detailed discussion on separate NAP and
   ISP authentication.

   The result of PANA authentication is carried in a PANA-Bind-Request
   message sent from the PAA to the PaC.  This message carries the final
   EAP authentication result (whether it is the second EAP
   authentication result of NAP and ISP separate authentication, or the
   sole EAP authentication result) and the result of PANA
   authentication.  The PANA-Bind-Request message MUST be acknowledged
   with a PANA-Bind-Answer (PBA) message.  Figure 4 shows an example
   sequence in the authentication and authorization phase (no separate
   authentication).

   PaC      PAA  Message(sequence number)[AVPs]
   --------------------------------------------------------------------
                 (continued from the discovery and handshake phase)
      <-----     PANA-Auth-Request(x+1)
                    [Session-Id, Nonce, EAP{Request}]
      ----->     PANA-Auth-Answer(x+1) // No piggybacking EAP Response
                    [Session-Id, Nonce]
      ----->     PANA-Auth-Request(y)
                    [Session-Id, EAP{Response}]
      <-----     PANA-Auth-Answer(y)
                    [Session-Id]
      <-----     PANA-Auth-Request(x+2)
                    [Session-Id, EAP{Request}]
      ----->     PANA-Auth-Answer(x+2) // Piggybacking EAP Response
                    [Session-Id, EAP{Response}]
      <-----     PANA-Bind-Request(x+3)
                    [Session-Id, Result-Code, EAP{Success}, Device-Id,
                     Key-Id, Lifetime, Protection-Cap., PPAC, MAC]
      ----->     PANA-Bind-Answer(x+3)
                    [Session-Id, Device-Id, Key-Id, PPAC, MAC]

    Figure 4: Example sequence for the authentication and authorization
                                   phase

   When an EAP method that is capable of deriving keys is used during
   the authentication and authorization phase and the keys are
   successfully derived, the PANA message that carries the EAP Success
   message (i.e., a PANA-FirstAuth-End-Request or a PANA-Bind-Request
   message) and any subsequent message MUST contain a MAC AVP.

CHANGE: The following 2 paragraphs are the break-down of one large
paragraph.

   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.  Otherwise, if a
   Protection-Capability AVP is not 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.  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.  

   The PANA-Bind-Request message with
   a PANA_SUCCESS result code MUST also contain a Protection-Capability
   AVP if link-layer or network-layer ciphering is enabled after the
   authentication and authorization phase.  The PANA-Bind-Request
   message MAY also contain a Protection-Capability AVP to indicate if
   link-layer or network-layer ciphering should be enabled after the
   authentication and authorization phase.  No link-layer or network-
   layer specific information is included in the Protection-Capability
   AVP.  It is assumed that the PAA is aware of the security
   capabilities of the access network.  The PANA protocol does not
   specify how the PANA SA and the Protection-Capability AVP will be
   used to provide per-packet protection for data traffic.  When the PaC
   does not support the protection capability indicated in the
   Protection-Capability AVP, the PaC MUST send a PANA-Error-Request
   message with a PANA_PROTECTION_CAPABILITY_UNSUPPORTED result code and
   terminate the PANA session.

   Additionally, the PANA-Bind-Request message with a PANA_SUCCESS
   result code MUST include a Post-PANA-Address-Configuration (PPAC)
   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.  In
   this case, 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.  When there is no match, the PaC MUST send a
   PANA-Error-Request message with a PANA_PPAC_CAPABILITY_UNSUPPORTED
   result code and terminate the PANA session.

CHANGE: Revised the following paragraph for issue 226.

   EAP authentication can fail at a pass-through authenticator without
   sending an EAP Failure message [I-D.ietf-eap-statemachine].  When
   this occurs, the PAA SHOULD send a PANA-Error-Request message to the
   PaC with using PANA_UNABLE_TO_COMPLY result code.  The PaC MUST NOT
   change its state unless the error message is secured by PANA or
   lower-layer.  In any case, a more appropriate way is to rely on a
   timeout on the PaC.

   There is a case where EAP authentication succeeds with producing an
   EAP Success message but network access authorization fails due to,
   e.g., authorization rejected by a AAA or authorization locally
   rejected by the PAA.  When this occurs, the PAA MUST send a PANA-
   Bind-Request with a result code PANA_AUTHORIZATION_REJECTED.  If a
   AAA-Key is established between the PaC and the PAA by the time when
   the EAP Success message is generated by the EAP server (this is the
   case when the EAP method provides protected success indication), the
   PANA-Bind-Request and PANA-Bind-Answer messages MUST be protected
   with a MAC AVP and carry a Key-Id AVP.  The AAA-Key and the PANA
   session MUST be deleted immediately after the PANA-Bind message
   exchange.

4.5  Access Phase

   Once the authentication and authorization phase or the re-
   authentication phase successfully completes, the PaC gains access to
   the network and can send and receive IP data traffic through the
   EP(s) and the PANA session enters the access phase.  In this phase,
   PANA-Ping-Request and PANA-Ping-Answer messages can be used for
   testing the liveness of the PANA session on the PANA peer.  Both the
   PaC and the PAA are allowed to send a PANA-Ping-Request message to
   the communicating peer whenever they need to make sure the
   availability of the session on the peer and expect the peer to return
   a PANA-Ping-Answer message.  Both PANA-Ping-Request and PANA-Ping-
   Answer messages MUST be protected with a MAC AVP when a PANA SA is
   available.

CHANGE: Following paragraph is revised to handle issue 227. Also, see issue
tracker #227 for changes on Section 5.2.

   Implementations MUST limit the rate of performing this test.  The PaC
   and the PAA can handle rate limitation on their own, they do not have
   to perform any coordination with each other.  There is no negotiation
   of timers for this purpose. Additionally, an implementation MAY 
   rate-limit processing the incoming PANA-Ping-Requests.

   Figure 5 and Figure 6 show liveness tests as they are initiated by
   the PaC and the PAA respectively.

   PaC      PAA     Message(sequence number)[AVPs]
   ------------------------------------------------------
      ----->        PANA-Ping-Request(q)[Session-Id, MAC]
      <-----        PANA-Ping-Answer(q)[Session-Id, MAC]

        Figure 5: Example sequence for PaC-initiated liveness test

   PaC      PAA     Message(sequence number)[AVPs]
   ------------------------------------------------------
      <-----        PANA-Ping-Request(p)[Session-Id, MAC]
      ----->        PANA-Ping-Answer(p)[Session-Id, MAC]

        Figure 6: Example sequence for PAA-initiated liveness test

4.6  Re-authentication Phase

   The PANA session in the access phase can enter the re-authentication
   phase to extend the current session lifetime by re-executing EAP.
   Once the re-authentication phase successfully completes, the session
   re-enters the access phase.  Otherwise, the session is deleted.

   When the PaC wants to initiate re-authentication, it sends a PANA-
   Reauth-Request message to the PAA.  This message MUST contain a
   Session-Id AVP which is used for identifying the PANA session on the
   PAA.  If the PAA already has an established PANA session for the PaC
   with the matching session identifier, it MUST first respond with a
   PANA-Reauth-Answer message, followed by a PANA-Auth-Request that
   starts a new EAP authentication.  If the PAA cannot identify the
   session, it MAY respond with a PANA-Error-Request message with a
   result code PANA_UNKNOWN_SESSION_ID.  Transmission of this error
   request is made optional in case this behavior is leveraged for a DoS
   attack on the PAA.

   The PaC may receive a PANA-Auth-Request before receiving the answer
   to its outstanding PANA-Reauth-Request.  This condition can arise due
   to packet re-ordering or a race condition between the PaC and PAA
   when they both attempt to engage in re-authentication.  The PaC MUST
   keep discarding the received PANA-Auth-Requests until it receives the
   answer to its request.

   When the PAA initiates re-authentication, it sends a PANA-Auth-
   Request message containing the session identifier for the PaC to
   enter the re-authentication phase.  The PAA SHOULD initiate EAP re-
   authentication before the current session lifetime expires.

   Re-authentication of an on-going PANA session MUST maintain the
   existing sequence numbers.

CHANGE: Added the clarification and a forward reference for S-flag in the
following paragraph.

   For any re-authentication, if there is an established PANA SA, PANA-
   Auth-Request and PANA-Auth-Answer messages MUST be protected by
   adding a MAC AVP to each message.  Any subsequent EAP authentication
   MUST be performed with the same ISP and NAP that was selected during
   the discovery and handshake phase.  The value of the S-flag ("separate
   authentication" flag, see Section 6.2) of the
   PANA messages exchanged in the re-authentication phase MUST be
   inherited from the previous authentication and authorization phase or
   re-authentication phase.

   PaC      PAA  Message(sequence number)[AVPs]
   ------------------------------------------------------
      ----->     PANA-Reauth-Request(q)
                    [Session-Id, MAC]
      <-----     PANA-Reauth-Answer(q)
                    [Session-Id, MAC]
      <-----     PANA-Auth-Request(p)
                    [Session-Id, EAP{Request}, MAC]
      ----->     PANA-Auth-Answer(p)   // No piggybacking EAP Response
                    [Session-Id, MAC]
      ----->     PANA-Auth-Request(q+1)
                    [Session-Id, EAP{Response}, MAC]
      <-----     PANA-Auth-Answer(q+1) // No piggybacking EAP Response
                    [Session-Id, MAC]
      <-----     PANA-Auth-Request(p+1)
                    [Session-Id, EAP{Request}, MAC]
      ----->     PANA-Auth-Answer(p+1) // Piggybacking EAP Response
                    [Session-Id, EAP{Response}, MAC]
      <-----     PANA-Bind-Request(p+2)
                    [Session-Id, Result-Code, EAP{Success},
                     Device-Id, Key-Id,
                     Lifetime, Protection-Cap., PPAC, MAC]
      ----->     PANA-Bind-Answer(p+2)
                    [Session-Id, Device-Id, Key-Id, PPAC, MAC]

   Figure 7: Example sequence for the re-authentication phase initiated
                                  by PaC

4.7  Termination Phase

   A procedure for explicitly terminating a PANA session can be
   initiated either from the PaC (i.e., disconnect indication) or from
   the PAA (i.e., session revocation).  The PANA-Termination-Request and
   PANA-Termination-Answer message exchanges are used for disconnect
   indication and session revocation procedures.

   The reason for termination is indicated in the Termination-Cause AVP.
   When there is an established PANA SA between the PaC and the PAA, all
   messages exchanged during the termination phase MUST be protected
   with a MAC AVP.  When the sender of the PANA-Termination-Request
   message receives a valid acknowledgment, all states maintained for
   the PANA session MUST be deleted immediately.

   PaC      PAA     Message(sequence number)[AVPs]
   ------------------------------------------------------
      ----->        PANA-Termination-Request(q)[Session-Id, MAC]
      <-----        PANA-Termination-Answer(q)[Session-Id, MAC]

   Figure 8: Example sequence for the termination phase triggered by PaC

4.8  Separate NAP and ISP Authentication

   PANA allows running at most two EAP sessions in sequence in the
   authentication and authorization phase to support separate NAP and
   ISP authentication as described in this section.  A typical network
   access authentication includes execution of one EAP method with the
   ISP.  This separation allows the PaC to perform an additional
   authentication method for receiving differentiated services from the
   NAP.

   Currently, running multiple EAP sessions in sequence in the
   authentication and authorization phase is designed only for separate
   NAP and ISP authentication.  It is not for running arbitrary number
   of EAP sessions in sequence, or giving the PaC another chance to try
   another EAP authentication method within an integrated NAP and ISP
   authentication when an EAP authentication method fails.

   Within separate NAP and ISP authentication, the NAP authentication
   and the ISP authentication are considered completely independent.
   Presence or success of one should not effect the other.  Making a
   network access authorization decision based on the success or failure
   of each authentication is a network policy issue.

4.8.1  Negotiating Separate NAP and ISP Authentication

   When the PaC and PAA negotiates in the discovery and handshake phase
   to perform separate NAP and ISP authentication, the PaC and the PAA
   operate in the following way in addition to the behavior defined in
   Section 4.3

   In the discovery and handshake phase, the PAA MAY advertise
   availability of separate NAP and ISP authentication ([I-D.ietf-pana-
   framework]) by setting the S-flag on the PANA header of the PANA-
   Start-Request message.

   If the S-flag of the received PANA-Start-Request message is set, the
   PaC can indicate its desire to perform separate NAP and ISP
   authentication by setting the S-flag in the PANA-Start-Answer
   message.  If the S-flag of the received PANA-Start-Request message is
   not set, the PaC MUST NOT set the S-flag in the PANA-Start-Answer
   message sent back to the PAA.

   If the S-flag in the PANA-Start-Answer message is not set, only one
   authentication is performed (ISP-only) and the processing occurs as
   described in Section 4.3.

   When the S-flag is set in a PANA-Start-Request message, the initial
   EAP Request message MUST NOT be carried in the PANA-Start-Request
   message.  (If the initial EAP Request message were contained in the
   PANA-Start-Request message during the S-flag negotiation, the PaC
   cannot tell whether the EAP Request message is for NAP authentication
   or ISP authentication.)

4.8.2  Execution of Separate NAP and ISP Authentication

   When the PaC and PAA have negotiated in the discovery and handshake
   phase to perform separate NAP and ISP authentication, the PaC and the
   PAA operate in the following way in addition to the behavior defined
   in Section 4.4

   o  The S-flag of PANA-Auth-Request and PANA-Auth-Answer messages MUST
      be set.

   o  An EAP Success/Failure message is carried in a PANA-FirstAuth-End-
      Request (PFER) message as well as a PANA-Bind-Request (PBR)
      message.  The PANA-FirstAuth-End-Request message MUST be used at
      the end of the first EAP authentication and the PANA-Bind-Request
      MUST be used for the second EAP authentication.  The PANA-
      FirstAuth-End-Request messages MUST be acknowledged with a PANA-
      FirstAuth-End-Answer (PFEA) message.

   o  If the first EAP authentication has failed, the PAA can choose not
      to perform the second EAP authentication by clearing the S-flag of
      the PANA-FirstAuth-End-Request message.  In this case, the S-flag
      of the PANA-FirstAuth-End-Answer message sent by the PaC MUST be
      cleared.  If the S-flag of the PANA-FirstAuth-End-Request message
      is set when the first EAP authentication has failed, the PaC can
      choose not to perform the second EAP authentication by clearing
      the S-flag of the PANA-FirstAuth-End-Answer message.  If the first
      EAP authentication failed and the S-flag is not set in the PANA-
      FirstAuth-End-Answer message as a result of those operations, the
      PANA session MUST be immediately deleted.  Otherwise, the second
      EAP authentication MUST be performed.

   o  The PAA determines the execution order of NAP authentication and
      ISP authentication.  In this case, the PAA can indicate which
      authentication (NAP authentication or ISP authentication) is
      currently occurring by using N-flag in the PANA message header.
      When NAP authentication is being performed, the N-flag MUST be
      set.  When ISP authentication is being performed, the N-flag MUST
      NOT be set.  The N-flag MUST NOT be set when S-flag is not set.

   When the PaC and PAA have negotiated in the discovery and handshake
   phase to perform separate NAP and ISP authentication, and the lower-
   layer is insecure, the two EAP authentication methods used in the
   separate authentication MUST be capable of deriving keys (AAA-Key).

4.8.3  AAA-Key Calculation

   When the PaC and PAA have negotiated in the discovery and handshake
   phase to perform separate NAP and ISP authentication, if the lower-
   layer is insecure, the two EAP authentication methods used in the
   separate authentication MUST be capable of deriving keys.  In this
   case, if the first EAP authentication is successful, the PANA-
   FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages as well
   as PANA-Auth-Request and PANA-Auth-Answer messages in the second EAP
   authentication MUST be protected with the key derived from the AAA-
   Key for the first EAP authentication.  The PANA-Bind-Request and
   PANA-Bind-Answer messages and all subsequent PANA messages exchanged
   in the access phase, re-authentication phase and termination phase
   MUST be protected either with the AAA-Key for the first EAP
   authentication if the first EAP authentication succeeds and the
   second EAP authentication fails, or with the AAA-Key for the second
   EAP authentication if the first EAP authentication fails and the
   second EAP authentication succeeds, or with the compound AAA-Key
   derived from the two AAA-Keys, one for the first EAP authentication
   and the other from the second EAP authentication, if both the first
   and second EAP authentication succeed.  See Section 5.3 for how to
   derive the AAA-Key.

REMARK: The following are the changes required for the addition of the
L-flag.

CHANGE: Revised Flags section in Section 6.2:

  Flags

      The Flags field is two octets.  The following bits are assigned:

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R S N L r r r r r r r r r r r r|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      R (Request)

         If set, the message is a request.  If cleared, the message is
         an answer.

      S (Separate)

         When the S-flag is set in a PANA-Start-Request message it
         indicates that PAA is willing to offer separate NAP and ISP
         authentication.  When the S-flag is set in a PANA-Start-Answer
         message it indicates that the PaC accepts on performing
         separate NAP and ISP authentication.  The PaC may also respond
         with the S-flag not set which implies the PaC has chosen to
         authenticate with the ISP only.  When the S-flag is set in a
         PANA-Auth-Request/Answer, PANA-FirstAuth-End-Request/Answer and
         PANA-Bind-Request/Answer messages it indicates that separate
         NAP and ISP authentication is being performed in the
         authentication and authorization phase.  For other cases,
         S-flag MUST NOT be set.

      N (NAP authentication)

         When the N-flag is set in a PANA-Auth-Request, a PANA-
         FirstAuth-End-Request or a PANA-Bind-Request message, it
         indicates that the current EAP authentication is for NAP
         authentication.  When the N-flag is unset in a PANA-Auth-
         Request, a PANA-FirstAuth-End-Request or a PANA-Bind-Request
         message, it indicates that the current EAP authentication is
         for ISP authentication.  The PaC MUST copy the value of the
         flag in its answer from the last received request of the PAA.
         The value of the flag on an answer MUST be copied from the
         request.  The N-flag MUST NOT be set when S-flag is not set.

      L (stateLess discovery)

         When the L-flag is set in a PANA-Start-Request message it
         indicates that the PAA is performing stateless discovery. 
         Cookie AVP MUST be included in both the PANA-Start-Request and
         the PANA-Start-Answer messages when performing stateless
         discovery.

      r(eserved)

         These flag bits are reserved for future use, and MUST be set to
         zero, and ignored by the receiver.

CHANGE: In Section 7, add the new bit in the ABNF as:

l-bit		= ", SLS"
               ; If present, the 'L' bit in the Message
               ; Flags is set, indicating PAA is performing
               ; stateless discovery

CHANGE: In Section 7.2, change the ABNF as:

   PANA-Start-Request ::= < PANA-Header: 2, REQ [,SEP] [,SLS] >
                       [ Nonce ]
                       [ Cookie ]
                       [ EAP-Payload ]
                       [ NAP-Information ]
                    *  [ ISP-Information ]
                       [ Protection-Capability]
                       [ PPAC ]
                       [ Notification ]
                    *  [ AVP ]

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 06 Feb 2006 17:10:26 -0500

The proposed text looks good.  Especially I like the idea of defining
L-bit for stateless discovery.  I also agree with removing the example
cookie computation algorithm from the PANA spec.

Yoshihiro Ohba