Subject: [Pana] Proposed changes for algorithm negotiation

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 6 Jul 2007 19:37:29 -0400

Here is line-by-line proposed changes to support algorithm negotiation:

[1] Change the following paragraph in Section 4.1:

"
   An Algorithm AVP MAY be included in the initial PANA-Auth-Request in
   order to indicate required and available capabilities for the network
   access.  This AVP MAY be used by the PaC for assessing the capability
   match even before the authentication takes place.  Since this AVP is
   provided in the insecure initial request, there are certain security
   risks involved in using the provided information.  See Section 11 for
   further discussion on this.
"

to:

"
   If a PANA SA needs to be established with use of a key-generating
   EAP method, PRF and integrity algorithms to be used for
   PANA_AUTH_KEY derivation (see Section 5.3) and AUTH AVP calculation
   (see Section 5.4) are negotiated as follows.  The PAA sends the
   initial PANA-Auth-Request carrying one or more PRF-Algorithm AVPs
   and one or more Integrity-Algorithm AVPs for the PRF and integrity
   algorithms supported by it, respectively.  The PaC then selects one
   PRF algorithm and one integrity algorithm from these AVPs carried
   in the initial PANA-Auth-Request and responds with the initial
   PANA-Auth-Answer carrying one PRF-Algorithm AVP and one
   Integrity-Algorithm AVP for the selected algorithms.  The
   negotiation is protected after the MSK is available, as described
   in Section 5.4.
"

[2] Change the following paragraph in Section 4.1:

"
   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 last PANA-Auth-Request message with the 'C'
   (Complete) bit set MUST contain a Key-Id AVP and an AUTH AVP, and an
   Algorithm AVP for the first derivation of keys in the session, and
   any subsequent message MUST contain an AUTH AVP.  An Algorithm AVP
   MUST NOT be contained in any PANA-Auth-Request message after the
   first derivation of keys in the session.
"

to:

"
   If a PANA SA needs to be established with use of a key-generating
   EAP method and an MSK is successfully generated, the last
   PANA-Auth-Request message with the 'C' (Complete) bit set MUST
   contain a Key-Id AVP and an AUTH AVP for the first derivation of
   keys in the session, and any subsequent message MUST contain an
   AUTH AVP.  "

(Note: I don't see the need for including *-Algorithm AVPs in the last
PAR/PAN exchange if the algorithm negotiation has been made in the
initial PAR/PAN exchange.)

[3] Change Figure 1 as follows (added algorithm negotiation in the
initial PAR/PAN and removed Algorithm AVP from the last PAR):

  PaC      PAA  Message(sequence number)[AVPs]
  --------------------------------------------------------------------
     ----->     PANA-Client-Initiation(0)
     <-----     PANA-Auth-Request(x)[PRF-Algorithm, Integrity-Algorithm]
                                           // The 'S' (Start) bit set
     ----->     PANA-Auth-Answer(x)[PRF-Algorithm, Integrity-Algorithm]
                                           // The 'S' (Start) bit set
     <-----     PANA-Auth-Request(x+1)[Nonce, EAP-Payload]
     ----->     PANA-Auth-Answer(x+1)[Nonce] // No piggybacking EAP
     ----->     PANA-Auth-Request(y)[EAP-Payload]
     <-----     PANA-Auth-Answer(y)
     <-----     PANA-Auth-Request(x+2)[EAP-Payload]
     ----->     PANA-Auth-Answer(x+2)[EAP-Payload]
                                           // Piggybacking EAP
     <-----     PANA-Auth-Request(x+3)[Result-Code, EAP-Payload,
                                       Key-Id, Session-Lifetime, AUTH]
                                           // The 'C' (Complete) bit set
     ----->     PANA-Auth-Answer(x+3)[Key-Id, AUTH]
                                           // The 'C' (Complete) bit set

[4] Change the following paragraph in Section 4.1:

"
   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 the last
   PANA-Auth-Request with a result code PANA_AUTHORIZATION_REJECTED.  If
   an MSK is available, the last PANA-Auth-Request and PANA-Auth-Answer
   messages with the 'C' (Complete) bit set MUST be protected with an
   AUTH AVP and carry a Key-Id AVP.  The last PANA-Auth-Request message
   MUST also carry an Algorithm AVP if it is for the first derivation of
   keys in the session.  The PANA session MUST be terminated immediately
   after the last PANA-Auth message exchange.
"

to:

"
   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 the last
   PANA-Auth-Request with a result code PANA_AUTHORIZATION_REJECTED.
   If an MSK is available, the last PANA-Auth-Request and
   PANA-Auth-Answer messages with the 'C' (Complete) bit set MUST be
   protected with an AUTH AVP and carry a Key-Id AVP.  The PANA
   session MUST be terminated immediately after the last PANA-Auth
   message exchange.
"

[5] Change Figure 2 as follows (removed Algorithm AVP from the last
PAR):

   PaC      PAA  Message(sequence number)[AVPs]
   ------------------------------------------------------
      ----->     PANA-Notification-Request(q)[AUTH]
                               // The 'A' (re-Authentication) bit set
      <-----     PANA-Notification-Answer(q)[AUTH]
                               // The 'A' (re-Authentication) bit set
      <-----     PANA-Auth-Request(p)[EAP-Payload, Nonce, AUTH]
      ----->     PANA-Auth-Answer(p)[AUTH, Nonce]
      ----->     PANA-Auth-Request(q+1)[EAP-Payload, AUTH]
      <-----     PANA-Auth-Answer(q+1)[AUTH]
      <-----     PANA-Auth-Request(p+1)[EAP-Payload, AUTH]
      ----->     PANA-Auth-Answer(p+1)[EAP-Payload, AUTH]
      <-----     PANA-Auth-Request(p+2)[Result-Code, EAP-Payload,
                                        Key-Id, Session-Lifetime, 
                                        AUTH]
                                        // The 'C' (Complete) bit set
      ----->     PANA-Auth-Answer(p+2)[Key-Id, AUTH]
                                        // The 'C' (Complete) bit set

[6] Change the following text in Section 5.3:

"
   The PANA_AUTH_KEY is derived from the available MSK and it is used to
   integrity protect PANA messages.  The PANA_AUTH_KEY is computed in
   the following way:

    PANA_AUTH_KEY = prf+(MSK, PaC_nonce|PAA_nonce|Session_ID|Key_ID)

   where the prf+ function is defined in IKEv2 [RFC4306].  The
   pseudo-random function to be used for the prf+ function is specified
   in the Algorithm AVP in the last PANA-Auth-Request message.  The
   length of PANA_AUTH_KEY depends on the integrity algorithm in use.
   See Section 5.4 for the detailed usage of the PANA_AUTH_KEY.
   PaC_nonce and PAA_nonce are values of the Nonce AVP carried in the
   first non-initial PANA-Auth-Answer and PANA-Auth-Request messages in
   the authentication and authorization phase or the first
   PANA-Auth-Answer and PANA-Auth-Request messages in the
   re-authentication phase, respectively.  Session_ID is the session
   identifier of the session.  Key_ID is the value of the Key-Id AVP.
"

to:

"
   The PANA_AUTH_KEY is derived from the available MSK and it is used to
   integrity protect PANA messages.  The PANA_AUTH_KEY is computed in
   the following way:

    PANA_AUTH_KEY = prf+(MSK, PaC_nonce|PAA_nonce|Session_ID|Key_ID)

   where the prf+ function is defined in IKEv2 [RFC4306].  The
   pseudo-random function to be used for the prf+ function is
   negotiated in the initial PANA-Auth-Request and PANA-Auth-Answer
   exchange with 'S' bit set using PRF-Algorithm AVP.  The length of
   PANA_AUTH_KEY depends on the integrity algorithm in use.  See
   Section 5.4 for the detailed usage of the PANA_AUTH_KEY.  PaC_nonce
   and PAA_nonce are values of the Nonce AVP carried in the first
   non-initial PANA-Auth-Answer and PANA-Auth-Request messages in the
   authentication and authorization phase or the first
   PANA-Auth-Answer and PANA-Auth-Request messages in the
   re-authentication phase, respectively.  Session_ID is the session
   identifier of the session.  Key_ID is the value of the Key-Id AVP.
"

[7] Change Section 5.4:

"
5.4.  Message Authentication

   A PANA message can contain an AUTH AVP for cryptographically
   protecting the message.

   When an AUTH AVP is included in a PANA message, the value field of
   the AUTH AVP is calculated by using the PANA_AUTH_KEY in the
   following way:

      AUTH AVP value = PANA_AUTH_HASH(PANA_AUTH_KEY, PANA_PDU)

   where PANA_PDU is the PANA message including the PANA header, with
   the AUTH AVP value field first initialized to 0.  PANA_AUTH_HASH
   represents the integrity algorithm specified in the Algorithm AVP in
   the last PANA-Auth-Request message.  The PaC and PAA MUST use the
   same integrity algorithm to calculate an AUTH AVP they originate and
   receive.  The algorithm is determined by the PAA.  When the PaC does
   not support the integrity algorithm specified in the last
   PANA-Auth-Request message, it MUST silently discard the message.
"

to:

"
5.4.  Message Authentication

   A PANA message can contain an AUTH AVP for cryptographically
   protecting the message.

   When an AUTH AVP is included in the last PANA-Auth-Request and
   PANA-Auth-Answer messages with 'C' (Complete) bit set in the
   authentication and authorization phase, the value field of
   the AUTH AVP is calculated by using the PANA_AUTH_KEY in the
   following way:

      AUTH AVP value = PANA_AUTH_HASH(PANA_AUTH_KEY, PANA_PDU,
                                      I_PAR, I_PAN)

   When an AUTH AVP is included in any other PANA message, the value
   field of the AUTH AVP is calculated in the following way:

      AUTH AVP value = PANA_AUTH_HASH(PANA_AUTH_KEY, PANA_PDU)

   In the above AUTH AVP calculation algorithms, PANA_PDU represents
   the PANA message including the PANA header, with the AUTH AVP value
   field first initialized to 0.  I_PAR is the initial
   PANA-Auth-Request message with 'S' (Start) bit set.  I_PAN is the
   initial PANA-Auth-Answer message with 'S' (Start) bit set.
   PANA_AUTH_HASH represents the integrity algorithm negotiated during
   the initial PANA-Auth-Request and PANA-Auth-Answer message
   exchange.
"

[8] Change PAR format in Section 7.2 as follows:

   PANA-Auth-Request ::= < PANA-Header: 2, REQ[,STA][,COM] >
                       [ EAP-Payload ]
                       [ Nonce ]
                    *  [ PRF-Algorithm ]
                    *  [ Integrity-Algorithm ]
                       [ Result-Code ]
                       [ Session-Lifetime ]
                       [ Key-Id ]
                    *  [ AVP ]
                   0*1 < AUTH >

[9] Change PAR format in Section 7.3 as follows:

   PANA-Auth-Answer ::= < PANA-Header: 2 [,STA][,COM] >
                       [ Nonce ]
                       [ EAP-Payload ]
                       [ PRF-Algorithm ]
                       [ Integrity-Algorithm ]
                       [ Key-Id ]
                    *  [ AVP ]
                   0*1 < AUTH >

[10] Change AVP occurrence table as follows:

   The table uses the following symbols:

   0     The AVP MUST NOT be present in the message.

   0-1   Zero or one instance of the AVP MAY be present in the message.
         It is considered an error if there are more than one instance
         of the AVP.

   1     One instance of the AVP MUST be present in the message.

   0+    Zero or more instance of the AVP MAY be present in the message.

                         +---------------------------+
                         |        Message Type       |
                         +---+---+---+---+---+---+---+
   Attribute Name        |PCI|PAR|PAN|PTR|PTA|PNR|PNA|
   ----------------------+---+---+---+---+---+---+---+
   PRF-Algorithm         | 0 |0+ |0-1| 0 | 0 | 0 | 0 |
   Integrity-Algorithm   | 0 |0+ |0-1| 0 | 0 | 0 | 0 |
   AUTH                  | 0 |0-1|0-1|0-1|0-1|0-1|0-1|
   EAP-Payload           | 0 |0-1|0-1| 0 | 0 | 0 | 0 |
   Key-Id                | 0 |0-1|0-1| 0 | 0 | 0 | 0 |
   Nonce                 | 0 |0-1|0-1| 0 | 0 | 0 | 0 |
   Result-Code           | 0 |0-1| 0 | 0 | 0 | 0 | 0 |
   Session-Lifetime      | 0 |0-1| 0 | 0 | 0 | 0 | 0 |
   Termination-Cause     | 0 | 0 | 0 | 1 | 0 | 0 | 0 |
   ----------------------+---+---+---+---+---+---+---+

                      Figure 4: AVP Occurrence Table

[11] Remove Section 8.1 (Algorithm AVP) and add the following sections
instead:

"
8.X.  Integrity-Algorithm AVP

   The PRF-Algorithm AVP (AVP Code X) is used for conveying the the
   integrity algorithm to compute an AUTH AVP.  The AVP data is of
   type Unsigned32.

   The AVP data contains an IKEv2 Transform ID of Transform Type 3
   [RFC4306] for the integrity algorithm.

   All PANA implementations MUST support AUTH_HMAC_SHA1_160 (7)
   [RFC4595].
"

"
8.Y.  PRF-Algorithm AVP

   The PRF-Algorithm AVP (AVP Code Y) is used for conveying the
   pseudo-random function to derive PANA_AUTH_KEY.  The AVP data is of
   type Unsigned32.

   The AVP data contains an IKEv2 Transform ID of Transform Type 2
   [RFC4306].

   All PANA implementations MUST support PRF_HMAC_SHA1 (2) [RFC2104].
"

(Note: Unsigned32 is used here instead of Unsigned16 because RFC3588
does not define Unsigned16 datatype.)

[12] Change Section 8.2:

"
8.2.  AUTH AVP

   The AUTH AVP (AVP Code 2) is used to integrity protect PANA messages.
   The AVP data payload contains the Message Authentication Code encoded
   in network byte order.  The AVP length varies depending on the
   integrity algorithm specified in an Algorithm AVP.  The AVP data is
   of type OctetString.
"

to:

"
8.2.  AUTH AVP

   The AUTH AVP (AVP Code 2) is used to integrity protect PANA
   messages.  The AVP data payload contains the Message Authentication
   Code encoded in network byte order.  The AVP length varies
   depending on the integrity algorithm negotiated in the initial
   PANA-Auth-Request and PANA-Auth-Answer exchange with 'S' bit set
   using Integrity-Algorithm AVP.  The AVP data is of type
   OctetString.
"

[13] Change the following paragraph of Section 10.3.1:

"
   AVP Code 0 is not used.  This document defines the AVP Codes 1-8.
   See Section 8.1 through Section 8.8 for the assignment of the
   namespace in this specification.
"

to:

"
   AVP Code 0 is not used.  This document defines the AVP Codes 1-9.
   See Section 8.1 through Section 8.9 for the assignment of the
   namespace in this specification.
"

[14] Remove the following paragraph from Section 11.2:

"
   In networks where lower-layers are not secured prior to running PANA,
   the capability discovery enabled through inclusion of an Algorithm
   AVP in the initial PANA-Auth-Request message is susceptible to
   spoofing leading to DoS attacks.  Therefore, usage of this AVP during
   the initial message exchange in such insecure networks is NOT
   RECOMMENDED.  The same AVP is delivered with integrity protection via
   the last PANA-Auth-Request message upon successful authentication.
"

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

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 9 Jul 2007 02:47:38 +0300

Yoshi,

>       AUTH AVP value = PANA_AUTH_HASH(PANA_AUTH_KEY, PANA_PDU)

Not sure which one is better: Having single formula in the spec (good for a
simpler spec), or not having to repeat the same AVPs at a later message
(good for reducing payload). I'm slightly leaning towards the former.....

>    initial PANA-Auth-Answer message with 'S' (Start) bit set.

So that people don't mistakenly take the whole IP packet as the PANA
message, let's say "I_PAR is the initial PANA-Auth-Request message (the PANA
header and the following PANA AVPs) with 'S' (Start) bit set."

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 10 Jul 2007 09:20:41 -0400

> (good for reducing payload). I'm slightly leaning towards the former.....

If that is the case, how about having I_PAR/I_PAN in the PANA_AUTH_KEY
derivation algorithm, and keeping the currently defined AUTH AVP
calculation algorithm in pana-pana-17 as it is?  I mean:

PANA_AUTH_KEY = prf+(MSK, I_PAR|I_PAN|PaC_nonce|PAA_nonce|Key_ID)

(SessionID is included in I_PAR and I_PAN.)

Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 10 Jul 2007 23:28:18 +0300

That makes sense to me.

Alper 

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: Tuesday, July 10, 2007 4:21 PM
> To: Alper Yegin
> Cc: 'Yoshihiro Ohba'; 'Mark Townsley'; 'Jari Arkko'; 'Sam Hartman';
> [email-masked]
> Subject: Re: [Pana] RE: Proposed changes for algorithm negotiation
> 
> messages.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 11 Jul 2007 13:29:33 +0300

This would also work for me.

Jari

Alper Yegin kirjoitti:
>>> Not sure which one is better: Having single formula in the spec (good
>>>       
>> for a
>>     
>>> (good for reducing payload). I'm slightly leaning towards the
>>>       
>> former.....
>>
>>> message, let's say "I_PAR is the initial PANA-Auth-Request message (the
>>>       
>> PANA
>>     
>>>>    0-1   Zero or one instance of the AVP MAY be present in the
>>>>         
>> message.
>>     
>>>>    0+    Zero or more instance of the AVP MAY be present in the
>>>>         
>> message.
>>     
>>>>
>>>>    The AVP data payload contains the Message Authentication Code
>>>>         
>> encoded
>>     
>>>>    In networks where lower-layers are not secured prior to running
>>>>         
>> PANA,
>>     
>>>>    spoofing leading to DoS attacks.  Therefore, usage of this AVP
>>>>         
>> during
>>     
>>>>    RECOMMENDED.  The same AVP is delivered with integrity protection
>>>>         
>> via
>>