Subject: [Pana] issue 52: revised text

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 29 Mar 2004 09:03:29 -0800

This is revised text for issue 52, reflecting Alper's comments.

Summary on changes
------------------

o When separate NAP and ISP authentications are performed and two
AAA-Keys are derived, one from NAP authentication and the other from
ISP authentication, the PANA-MAC-Key is computed based on the two
AAA-Keys (i.e., compound key)

o New PANA messages PANA-FirstAuth-End-Request and
PANA-FirstAuth-End-Answer messages are introduced.  The new messages
are used at the end of the first EAP authentication (instead of
PANA-Bind-Request/Answer) when the PaC and PAA negotiated to perform
separate NAP and ISP authentications.

o The PaC and PAA can choose not to perform the second EAP
authentication when they negotiated to perform separate NAP and ISP
authentications, but the first EAP authentication has failed.  S-flag
is reused for this purpose.

o A new N-flag is introduced to indicate whether NAP or ISP
authentication is performed in NAP and ISP separate authentications.

Changes
-------

- In order to support compound MAC key when separate NAP and ISP
authentications are performed, change the first paragraph in
section 4.1.5:

   "A PANA SA is created as an attribute of a PANA session when EAP
   authentication succeeds with a creation of a AAA-Key.  A PANA SA is
   not created when the PANA authentication fails or no AAA-Key is
   produced by any EAP authentication method. In the case where two EAP
   authentications are performed in a sequence in a single PANA
   authentication, it is possible that two AAA-Keys are derived. If this
   happens, the PANA SA MUST be bound to the AAA-Key derived from the
   first EAP authentication.  When a new AAA-Key is derived as a result
   of EAP-based re-authentication, any key derived from the old AAA-Key
   MUST be updated to a new one that is derived from the new AAA-Key.
   In order to distinguish the new AAA-Key from old ones, one Key-Id AVP
   MUST be carried in PANA-Bind-Request and PANA-Bind-Answer message at
   the end of the authentication phase which resulted in deriving a new
   AAA-Key.  The Key-Id AVP is of type Unsigned32 and MUST contain a
   value that uniquely identifies the AAA-Key within the PANA session.
   The PANA-Bind-Answer message sent in response to a PANA-Bind-Request
   with a Key-Id AVP MUST contain a Key-Id AVP with the same AAA-Key
   identifier carried in the request. PANA-Bind-Request and
   PANA-Bind-Answer messages with a Key-Id AVP MUST also carry a MAC AVP
   whose value is computed by using the new AAA-Key.  Although the
   specification does not mandate a particular method for calculation of
   Key-Id AVP value, a simple method is to use monotonically increasing
   numbers."

to:

   "A PANA SA is created as an attribute of a PANA session when EAP
   authentication succeeds with a creation of a AAA-Key.  A PANA SA is
   not created when the PANA authentication fails or no AAA-Key is
   produced by any EAP authentication method. In the case where two
   EAP authentications are performed in sequence in a single PANA
   authentication phase, it is possible that two AAA-Keys are
   derived. If this happens, the PANA SA MUST be generated from both
   AAA-Keys.  When a new AAA-Key is derived as a result of EAP-based
   re-authentication, any key derived from the old AAA-Key MUST be
   updated to a new one that is derived from the new AAA-Key.  In
   order to distinguish the new AAA-Key from old ones, one Key-Id AVP
   MUST be carried in PANA-Bind-Request and PANA-Bind-Answer messages
   or PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer
   messages at the end of the EAP authentication which resulted in
   deriving a new AAA-Key.  The Key-Id AVP is of type Unsigned32 and
   MUST contain a value that uniquely identifies the AAA-Key within
   the PANA session.  The PANA-Bind-Answer message (or the
   PANA-FirstAuth-End-Answer message) sent in response to a
   PANA-Bind-Request message (or a PANA-FirstAuth-End-Request message)
   with a Key-Id AVP MUST contain a Key-Id AVP with the same AAA-Key
   identifier carried in the request.  PANA-Bind-Request,
   PANA-Bind-Answer, PANA-FirstAuth-End-Request and
   PANA-FirstAuth-End-Answer messages with a Key-Id AVP MUST also
   carry a MAC AVP whose value is computed by using the new
   PANA-MAC-Key derived from the new AAA-Key (or the new pair of
   AAA-Keys when the PANA_MAC_KEY is derived from two AAA-Keys).
   Although the specification does not mandate a particular method for
   calculation of Key-Id AVP value, a simple method is to use
   monotonically increasing numbers."

- In order to support compound MAC key when separate NAP and ISP
authentications are performed, change the following paragraphs in
section 4.1.5.

"
   The PANA_MAC_Key is used to integrity protect PANA messages and
   derived from the AAA-Key in the following way:

      PANA_MAC_KEY = The first N bits of
                     HMAC_SHA1(AAA-Key, ISN_pac | ISN_paa | Session-ID)

   where the value of N depends on the integrity protection algorithm in
   use, i.e., N=160 for HMAC-SHA1.

   The length of AAA-Key MUST be N bits or longer.  See Section 4.1.6
   for the detailed usage of the PANA_MAC_Key.
"

to:

   The PANA_MAC_Key is used to integrity protect PANA messages.  When
   the PANA_MAC_Key is derived from a single AAA-Key, it is computed
   in the following way:

      PANA_MAC_KEY = The first N bits of
                     HMAC_SHA1(AAA-Key, ISN_pac | ISN_paa | Session-ID)

   where the value of N depends on the integrity protection algorithm
   in use, i.e., N=160 for HMAC-SHA1.

   When the PANA_MAC_Key is derived from two AAA-Keys, it is computed
   in the following way:

      PANA_MAC_KEY = The first N bits of
                     HMAC_SHA1(AAA-Key1, AAA-Key2, 
                               ISN_pac | ISN_paa | Session-ID)

   where AAA-Key1 and AAA-Key2 are AAA-Keys for the first and second
   EAP authentication in a single PANA authentication phase,
   respectively.

   The length of AAA-Key, AAA-Key1 and AAA-Key2 MUST be N bits or
   longer.  See Section 4.1.6 and Section 4.3 for the detailed usage
   of the PANA_MAC_Key.
"

- In order to clarify that ISP-Information AVP can be included in PSA
message even if PAA does not contain any ISP-Information AVP in PSR
message, add the following paragraph in section 4.2:

  "The PaC can still choose an ISP and contain an ISP-Information AVP
  for the chosen ISP in a PANA-Start-Answer message even when there is
  no ISP-Information AVP contained in the PANA-Start-Request message."

- In order to clarify that PSR message does not contain EAP Request
while negotiating on performing separate authentication for NAP and
ISP, change the following paragraphs in section 4.2 from:

"
   When a Cookie-AVP is carried in a PANA-Start-Request message, the
   initial EAP Request MUST NOT be carried in the PANA-Start-Request
   message in order for the PAA to be stateless.

   When a Cookie-AVP is not carried in a PANA-Start-Request message, the
   PAA does not need to be stateless.  In this case, the initial EAP
   Request message MAY be carried in the PANA-Start-Request message.

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

to:

"
   When a Cookie-AVP is carried in a PANA-Start-Request message, the
   initial EAP Request MUST NOT be carried in the PANA-Start-Request
   message in order for the PAA to be stateless.

   Initial EAP Request 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.

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

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

Rewrite Section 4.3 as follows:

4.3 Authentication Phase

   The main task in authentication phase is to carry EAP messages
   between PaC and PAA.  EAP Request messages are carried in PANA-
   Auth-Request messages and optionally carried in PANA-Start-Request
   messages.  EAP Response messages are carried in PANA-Auth-Answer
   messages and optionally carried in PANA-Start-Answer messages.
   When an EAP Success/Failure message is sent from a PAA, the message
   is carried in a PANA-Bind-Request (PBR) or
   PANA-FirstAuth-End-Request (PFER) message.  The
   PANA-FirstAuth-End-Reques message MUST be used at the end of the
   first EAP when the PaC and PAA have negotiated during the discovery
   and initial handshake phase to perform separate NAP and ISP
   authentications in a single PANA authentication phase.  Otherwise,
   the PANA-Bind-Request message MUST be used.  The PANA-Bind-Request
   and PANA-FirstAuth-End-Request messages MUST be acknowledged with a
   PANA-Bind-Answer (PBA) and a PANA-FirstAuth-End-Answer (PFEA)
   messages, respectively.

   When the PaC and PAA have negotiated during the discovery and
   initial handshake phase to perform separate NAP and ISP
   authentications, the S-flag of PANA-Auth-Request and
   PANA-Auth-Answer messages MUST be set.  Otherwise, the S-flag MUST
   NOT be set.

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

   When separate NAP and ISP authentications are performed, 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.

   Currently, use of multiple EAP methods in PANA is designed only for
   NAP-ISP authentication separation.  It is not for arbitrary EAP
   method sequencing, or giving the PaC another chance when an
   authentication method fails.  The NAP and ISP authentication are
   considered completely independent.  Presence or success of one
   should not effect the other.  Making an authentication decision
   based on the success or failure of each authentication is a network
   policy issue.  

   When an EAP method that is capable of deriving keys is used during
   the authentication phase and the keys are successfully derived, the
   PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer and/or
   PANA-Bind-Request and PANA-Bind-Answer messages, and all subsequent
   PANA messages MUST contain a MAC AVP.  When separate NAP and ISP
   authentications are performed and the lower-layer is insecure, the
   two EAP methods 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 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
   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 authentications succeed (see section
   4.1.5 how the compound key is derived).

   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.  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.  No link
   layer or network layer specific information is included in the
   Protection-Capability AVP.  When the information is preconfigured
   on the PaC and the PAA this AVP can be omitted.  It is assumed that
   at least 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.

   PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted
   based on the retransmission rule described in Appendix A.

Add the following example in section 4.6:

"
   Another PANA message sequence is illustrated in Figure X.  The
   example assumes the following scenario:

   o  PaC multicasts PANA-PAA-Discover message

   o  The ISNs used by the PAA and the PaC are x and y, respectively.
      
   o  PAA offers NAP and ISP separate authentication, as well as a
      choice of ISP from "ISP1" and "ISP2".

   o  PaC accepts the offer from PAA, with choosing "ISP1" as the ISP.

   o  An EAP sequence for NAP authentication and an EAP sequence for
      ISP authentication is performed in this order in authentication phase.

   o  An EAP authentication method with a single round trip is used in
      each of EAP sequence.

   o  The EAP authentication methods derive keys.  Once the two EAP
      authenticatioins are successful, the PANA_MAC_KEY is derived
      from the two AAA-Keys.

   o  After PANA SA is established, all messages are integrity and
      replay protected with the MAC AVP.

   o  Re-authentication and termination phase are not shown.

      PaC      PAA  Message(tseq,rseq)[AVPs]
      -----------------------------------------------------
      // Discovery and initial handshake phase
         ----->     PANA-PAA-Discover (0,0)
         <-----     PANA-Start-Request (x,0)            // S-flag set
                    [Cookie, ISP-Information("ISP1"),   
                     ISP-Information("ISP2"),           
                     NAP-Information("MyNAP")]
         ----->     PANA-Start-Request-Answer (y,x)     // S-flag set
                    [Cookie, ISP-Information("ISP1")]   // PaC chooses "ISP1"
                                                    
      // Authentication phase
         <-----     PANA-Auth-Request(x+1,y)[EAP]       // NAP authentication
                                                        // S- and N-flags set
         ----->     PANA-Auth-Answer(y+1,x+1)[EAP]      // S- and N-flags set
         <-----     PANA-Auth-Request(x+2,y+1)[EAP]     // S- and N-flags set
         ----->     PANA-Auth-Answer(y+2,x+2)[EAP]      // S- and N-flags set
         <-----     PANA-FirstAuth-End-Request(x+3,y+2) // S- and N-flags set
                      [EAP{Success}, Key-Id, MAC] 
         ----->     PANA-FirstAuth-End-Answer(y+3,x+3)  // S- and N-flags set
                      [Key-Id, MAC]                     
         <-----     PANA-Auth-Request(x+3,y+4)[EAP, MAC]// ISP authentication
                                                        // S-flag set
         ----->     PANA-Auth-Answer(y+4,x+4)[EAP, MAC] // S-flag set
         <-----     PANA-Auth-Request(x+4,y+5)[EAP, MAC]// S-flag set
         ----->     PANA-Auth-Answer(y+5,x+5)[EAP, MAC] // S-flag set
         <-----     PANA-Bind-Request(x+5,y+6)          // S-flag set
                      [EAP{Success}, Device-Id, Key-Id, 
                       Lifetime, Protection-Cap., MAC]
         ----->     PANA-Bind-Answer(y+6,x+5)           // S-flag set
                      [Device-Id, Key-Id, Protection-Cap., MAC]

        Figure X: A Message Sequence for NAP and ISP Separate Authentication
"

Add N-flag in the header as follows:

"      0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |R r r r S N r r|
      +-+-+-+-+-+-+-+-+
"
 
Change the following paragraph in section 9.1:

"
      S(eparate)

         When the S-flag is set in a PANA-Start-Request message it
         indicates that PAA is willing to offer separate EAP
         authentication for NAP and ISP.  When the S-flag is set in a
         PANA-Start-Answer message it indicates that PaC accepts on
         performing separate EAP authentication for NAP and ISP.
"

to:

"     S(eparate)

         When the S-flag is set in a PANA-Start-Request message it
         indicates that PAA is willing to offer separate EAP
         authentications for NAP and ISP.  When the S-flag is set in a
         PANA-Start-Answer message it indicates that PaC accepts on
         performing separate EAP authentications for NAP and ISP.
         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
         authentications are being performed in the authentication
         phase.

      N(AP authentication)

        When the N-flag is set in a PANA-Auth-Request message, it
        indicates that PAA is performing NAP authentication.  When the
        N-flag is unset in a PANA-Auth-Request message, it indicates
        that PAA is performing ISP authentication.  The N-flag MUST
        NOT be set when S-flag is not set.
"

- Change Figure 9 as follows:

"
                 Message          Direction: PaC---PAA
                 -------------------------------------
                 PANA-PAA-Discover           -------->

                 PANA-Start-Request          <--------
                 PANA-Start-Answer           -------->

                 PANA-Auth-Request           <--------
                 PANA-Auth-Answer            -------->

                 PANA-FirstAuth-End-Request  <--------
                 PANA-FirstAuth-End-Answer   -------->

                 PANA-Bind-Request           <--------
                 PANA-Bind-Answer            -------->

                 PANA-Reauth-Request         <------->
                 PANA-Reauth-Answer          <------->

                 PANA-Termination-Request    <------->
                 PANA-Termination-Answer     <------->

                 PANA-Error                  <------->
"

Remove NAP-Information and ISP-Information AVPs from the ABNF for PAR
message as follows:

"        PANA-Auth-Request ::= < PANA-Header: 3, REQ >
                       < Session-Id >
                       < EAP-Payload >
                    *  [ AVP ]
                   0*1 < MAC >
"

Add the following two sections:

"9.3.X PANA-FirstAuth-End-Request (PFER)

   PANA-FirstAuth-End-Request (PFER) is sent by the PAA to the PaC.

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

9.3.Y  PANA-FirstAuth-End-Answer (PFEA)

   PANA-FirstAuth-End-Answer (PFEA) is sent by the PaC to the PAA in
   response to a PANA-FirstAuth-End-Request message.

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

- Change the AVP occurrence table as follows:

"
                          +-----------------------------------------+
                          |        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  |  1+ |  1+ | 0-1 |
      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  |  0  |  0  |  0  |  0  |
      NAP-Information     | 0-1 |  0  |  0  |  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 | PFER | PFEA |
      --------------------+------+------+-----+-----+-----+------+------+
      Result-Code         |  0   |  0   |  0  |  0  |  1  |  1   |  0   |
      Session-Id          |  1   |  1   |  1  |  1  |  1  |  1   |  1   |
      Termination-Cause   |  0   |  0   |  1  |  0  |  0  |  0   |  0   |
      EAP-Payload         | 0-1  | 0-1  |  0  |  0  |  0  |  1   |  0   |
      MAC                 | 0-1  | 0-1  | 0-1 | 0-1 | 0-1 | 0-1  | 0-1  |
      Device-Id           |  1+  |  1+  |  0  |  0  |  0  |  0   |  0   |
      Cookie              |  0   |  0   |  0  |  0  |  0  |  0   |  0   |
      Protection-Cap.     |  0   |  0   |  0  |  0  |  0  |  0   |  0   |
      Session-Lifetime    |  0   |  0   |  0  |  0  |  0  |  0   |  0   |
      Failed-AVP          |  0   |  0   |  0  |  0  |  1  |  0   |  0   |
      ISP-Information     |  0   |  0   |  0  |  0  |  0  |  0   |  0   |
      NAP-Information     |  0   |  0   |  0  |  0  |  0  |  0   |  0   |
      EP-Device-Id        |  0   |  0   |  0  |  0  |  0  |  0   |  0   |
      Key-Id              |  0   |  0   |  0  |  0  |  0  | 0-1  | 0-1  |
      --------------------+------+------+-----+-----+-----+------+------+
"

Regards,

Yoshihiro Ohba

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