Subject: [Pana] Issue245: PANA and KDF

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 22 Feb 2006 11:20:36 -0500

http://danforsberg.info:8080/pana-issues/issue245

Here is proposaed text based on the suggested approach:

Note: The changes are from the latest snapshot 
(http://www.panasec.org/docs/editing/draft-ietf-pana-pana-11d.txt)

[1] Add the following bullet in Section 4.2:

o Algorithm AVP: contains a pseudo-random function and an integrity
                 algorithm.

[2] Change Figure 4 as follows:

   PaC      PAA  Message(sequence number)[AVPs]a
   --------------------------------------------------------------------
                 (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, Algorithm, 
                     Lifetime, Protection-Cap., PPAC, AUTH]
      ----->     PANA-Bind-Answer(x+3)
                    [Session-Id, Device-Id, Key-Id, PPAC, AUTH]

   Figure 4: Example sequence for the authentication and authorization
   phase

[3] In Section 4.4,

change:

"
   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 an AUTH AVP.
"

to:

"
   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) MUST contain an Algorithm AVP, a Key-Id AVP and an AUTH
   AVP, and any subsequent message MUST contain an AUTH AVP.
"

change:

"
   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 an AUTH AVP and carry a Key-Id AVP.  The AAA-Key and the PANA
   session MUST be deleted immediately after the PANA-Bind 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 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 an AUTH AVP and carry an Algorithm AVP and a Key-Id
   AVP.  The AAA-Key and the PANA session MUST be deleted immediately
   after the PANA-Bind message exchange.
"

[4] Change Figure 7 as follows:

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

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

[5] In Section 5.3, 

Add the following PANA SA attributes:

   * Pseudo-random function

   * Integrity algorithm

[6] In Section 5.3, 

change:

"
   PANA_AUTH_KEY = The first N bits of
                  HMAC_SHA1(AAA-Key, PaC_nonce | PAA_nonce | 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 the AAA-Key MUST be N
   bits or longer.  See Section 5.4 for the detailed usage of the
   PANA_AUTH_KEY.
"

to:

"
   PANA_AUTH_KEY = prf+(AAA-Key, PaC_nonce | PAA_nonce | Session-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 a PANA-Bind-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.
"

[7] In Section 5.4,

change:

"
   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_PRF(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_PRF
   represents the pseudo random function corresponding to the hash
   algorithm specified in the AUTH AVP.  The PaC and PAA MUST use the
   same algorithm to calculate an AUTH AVP they originate and receive.
   The algorithm is determined by the PAA when a PANA-Bind-Request with
   an AUTH AVP is sent.  When the PaC does not support the hash
   algorithm specified in the PANA-Bind-Request message, it MUST
   silently discard the message.  The PAA MUST NOT change the hash
   algorithm throughout the continuation of the PANA session.
"

to:

"
   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 a PANA-Bind-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
   PANA-Bind-Request message, it MUST silently discard the message.
"

[8] In Section 5.6,

change:

"
   PaC-EP-Master-Key = The first 64 octets of
                       HMAC-SHA1+(AAA-Key, "PaC-EP master key" |
                                  Session ID | Key-ID | EP-Device-Id)

   HMAC-SHA1+ is an instance of prf+ function defined in IKEv2
   [RFC4306], where the instance uses HMAC-SHA1 as the prf (pseudo-
   random function).
"

to:

"
   PaC-EP-Master-Key = The first 64 octets of
                       prf+(AAA-Key, "PaC-EP master key" |
                            Session ID | Key-ID | EP-Device-Id)

   The prf+ function is defined in IKEv2 [RFC4306].  The pseudo-random
   function used for the prf+ function is specified in the Algorithm
   AVP carried in a PANA-Bind-Request message.
"

[9] In Section 7.8, 

change:

"
   PANA-Bind-Request ::= < PANA-Header: 5, REQ [,SEP] [,NAP] >
                       < Session-Id >
                       { Result-Code }
                       [ PPAC ]
                       [ EAP-Payload ]
                       [ Session-Lifetime ]
                       [ Protection-Capability ]
                       [ Key-Id ]
                    *  [ Device-Id ]
                       [ Notification ]
                    *  [ AVP ]
"

to:

"
   PANA-Bind-Request ::= < PANA-Header: 5, REQ [,SEP] [,NAP] >
                       < Session-Id >
                       { Result-Code }
                       [ PPAC ]
                       [ EAP-Payload ]
                       [ Session-Lifetime ]
                       [ Protection-Capability ]
                       [ Key-Id ]
                       [ Algorithm ]
                    *  [ Device-Id ]
                       [ Notification ]
                    *  [ AVP ]
"

[10] In Section 7.16, 

change:

"
   PANA-FirstAuth-End-Request ::= < PANA-Header: 9, REQ [,SEP] [,NAP] >
                       < Session-Id >
                       { Result-Code }
                       [ EAP-Payload ]
                       [ Key-Id ]
                       [ Notification ]
                    *  [ AVP ]
                   0*1 < AUTH >
"

to:

"
   PANA-FirstAuth-End-Request ::= < PANA-Header: 9, REQ [,SEP] [,NAP] >
                       < Session-Id >
                       { Result-Code }
                       [ EAP-Payload ]
                       [ Key-Id ]
                       [ Algorithm ]
                       [ Notification ]
                    *  [ AVP ]
                   0*1 < AUTH >
"

[11] Add the following rows in Figures 10 and 11:

                         +---------------------------------------------+
                         |                  Message                    |
                         |                   Type                      |
                         +---+---+---+---+---+----+----+---+---+---+---+
   Attribute Name        |PDI|PSR|PSA|PAR|PAN|PRAR|PRAA|PBR|PBA|PPR|PPA|
   ----------------------+---+---+---+---+---+----+----+---+---+---+---+
   Algorithm             | 0 | 0 | 0 | 0 | 0 | 0  | 0  |0-1| 0 | 0 | 0 |

                         +---------------------------------+
                         |              Message            |
                         |               Type              |
                         +---+---+---+---+----+----+---+---+
   Attribute Name        |PTR|PTA|PER|PEA|PFER|PFEA|PUR|PUA|
   ----------------------+---+---+---+---+----+----+---+---+
   Algorithm             | 0 | 0 | 0 | 0 | 0-1| 0  | 0 | 0 |

[12] Change Section 8.7

from:

"
8.7.  AUTH AVP

   The AUTH (Authentication) AVP is used to integrity protect PANA
   messages.  The first octet of the this AVP (AVP Code 7) data contains
   the hash algorithm type.  Rest of the AVP data payload contains the
   Message Authentication Code encoded in network byte order.  The 8-bit
   Algorithm name space is managed by IANA [ianaweb].  The AVP length
   varies depending on the used algorithm.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Algorithm   |          Message Authentication Code...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Algorithm

      1         HMAC-SHA1 (20 bytes)

   Message Authentication Code

      The Message Authentication Code is encoded in network byte order.
"

to:

"
8.7.  Authentication (AUTH) AVP

   The AUTH AVP (AVP Code 7) 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.
"

[13] Insert the following section:

"
8.X. Algorithm AVP

   The Algorithm AVP (AVP Code X) is used for conveying the pseudo-
   random function to derive PANA_AUTH_KEY and PaC-EP-Master-Key as
   well as the integrity algorithm to compute an AUTH AVP.  The AVP
   data is of type Unsigned32.

   The first 16-bit of the AVP data contains an IKEv2 Transform ID of
   Transform Type 2 [RFC4306] corresponding to the key derivation
   function.

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

   All PANA implementations MUST support PRF_HMAC_SHA1 (2) [RFC2104]
   for the key derivation algorithm and AUTH_HMAC_SHA1_160 (7)
   [ianaweb] corresponding to the integrity algorithm.
"

Note: Originally, the Algorithm field in AUTH AVP had its own value
space.  The value space for the Algorithm is now reusing the IKEv2
Transform ID.  This is to avoid reinventing the wheel.

[14] Reshuffle AVP code values in Section 8 due to insertion of the
Algorithm AVP.

[15] Delete the following section:

"
10.5.1.  Algorithm Values of AUTH AVP

   As defined in Section 8.7, the Algorithm field of an AUTH AVP (AVP
   Code 7) defines the value of 1 (one) for HMAC-SHA1.

   All remaining values are available for assignment via IETF Consensus
   [IANA].
"

[16] Change Figure 12 as follows:

   PaC      PAA  Message(sequence number)[AVPs]
   -----------------------------------------------------
   // Discovery and handshake phase
      ----->     PANA-PAA-Discover(0)
      <-----     PANA-Start-Request(x)     // S-flag set.
                    [Cookie,
                     ISP-Information("ISP1"),
                     ISP-Information("ISP2"),
                     NAP-Information("MyNAP")]
      ----->     PANA-Start-Answer(x)      // S-flag set.
                    [Cookie,               // PaC chooses "ISP1".
                     ISP-Information("ISP1")]

   // Authentication and authorization phase
      <-----     PANA-Auth-Request(x+1)    // NAP authentication.
                    [Session-Id, Nonce,    // (S,N)-flags set
                     EAP{Request}]         // for all messages during
                                           // NAP authentication.
      ----->     PANA-Auth-Answer(x+1)[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)[Session-Id, EAP{Response}]
      <-----     PANA-FirstAuth-End-Request(x+3)
                    [Session-Id, EAP{Success}, Key-Id, 
                     PRF, Integrity-Algorithm, AUTH]
      ----->     PANA-FirstAuth-End-Answer(x+3)
                    [Session-Id, Key-Id, AUTH]
      <-----     PANA-Auth-Request(x+4)     // ISP authentication.
                    [Session-Id, EAP{Request}, AUTH]  // Only S-flag set
                                            // for all messages during
                                            // ISP authentication.
      ----->     PANA-Auth-Answer(x+4)[Session-Id, AUTH]
      ----->     PANA-Auth-Request(y+1)[Session-Id, EAP{Response}, AUTH]
      <-----     PANA-Auth-Answer(y+1)[Session-Id, AUTH]
      <-----     PANA-Auth-Request(x+5)[Session-Id, EAP{Request}, AUTH]
      ----->     PANA-Auth-Answer(x+5)[Session-Id, EAP{Response}, AUTH]
      <-----     PANA-Bind-Request(x+6)
                    [Session-Id, Result-Code, EAP{Success}, Device-Id,
                     Key-Id, Algorithm, 
                     Lifetime, Protection-Cap., PPAC, AUTH]
      ----->     PANA-Bind-Answer(x+6)[Session-Id, Device-Id, Key-Id,
                     PPAC, AUTH]

   Figure 12: A Complete Message Sequence for Separate NAP and ISP

Comments are appreciated.

Regards,
Yoshihiro Ohba

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

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 23 Feb 2006 19:33:34 -0500

Hi Yoshi

I have a comment regarding this paragraph.

"

Only Algorithm AVP is included at the end of PANA authentication
(PBR,PBA). Would not it be possible to include that AVP in a previous
exchanges as a HINT
(maybe in PSR)?

-- 
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645    e-mail: [email-masked]
------------------------------------------------------

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 23 Feb 2006 19:46:43 -0500

I agree with you on adding optional Algorithm TLV in PSR.

Yoshihiro Ohba

---

From: Sasikanth Bharadwaj <[email-masked]>
Date: Tue, 28 Feb 2006 15:06:54 +0530

Hi Yoshi

>    PANA-Bind-Request message, it MUST silently discard the message.

Discarding the message will cause the session to be terminated by the PAA
after retransmissions. I feel some negotiation should be allowed regarding
this algorithm because in case a PaC supports only the mandated algorithm
and the PAA asks for a stronger or better one, the session would fail, so
there actually is no point in mandating an algorithm unless the PaC can
negotiate. It would be better if this negotiation happens in the handshake
phase itself, so the algorithm AVP should be made mandatory in the PSR/PSA
exchange rather than optional.
>    PaC      PAA  Message(sequence number)[AVPs]
Also, in separate authentication, it would be better to state whether a PAA
can use separate algorithms for NAP and ISP authentications because that
inturn would give rise to several combinations, when one is supported by the
PaC and the other isn't. If the algorithm is to be kept the same for both, I
think there's no need to carry the AVP in both PFER and PBR messages.

Regards

Sasikanth

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 28 Feb 2006 13:27:58 -0500

Hi Sasikanth,

> exchange rather than optional.

The purpose of carrying the algorithm is just to avoid hard-coded key
derivation and integrity algorithms, not to allow negotiation.

We discussed this in the past for integrity algorithm for MAC (now
AUTH) AVP.  We are just applying the same rule for KDF as well.

> think there's no need to carry the AVP in both PFER and PBR messages.

Good point.  There is no need to use different algorithms for NAP and
ISP authentications.  When the Algorithm AVP is carried in PFER, then
the AVP can be omitted in PBR.  We can add some text on these.

Yoshihiro Ohba