Subject: RE: [Pana] Issue 58 and issue 74: proposed text (take 4)

From: [email-masked]
Date: Wed, 5 May 2004 09:32:19 +0300

Ok, great. For this to be repeatable, I think 
that the AAA-Key-new should become the as the 
'AAA-Key' for the remaining time of the session. 
Thus, take this sentence away: "Due to the 
reliance on the AAA-Key, this optimization 
only works when PaC has performed an EAP-based 
authentication on the anchor PAA". The new AAA-Key 
is not as strong as the original one, but on the 
other hand PANA session lifetime has not changed 
either (the key lifetime is not reseted).

   "The value of N depends on the integrity protection algorithm in
   use, i.e., N=160 for HMAC-SHA1. AAA-Key is the EAP-based
   key that was made available to anchor PAA and PaC as a result of
   the earlier EAP authentication. DiameterIdentity is the identifier of
   the current PAA. Session-ID is the identifier of the PaC's PANA session 
   with the anchor PAA."

- Dan

> -----Original Message-----
> From: ext Alper Yegin [mailto:[email-masked]]
> Sent: 05 May, 2004 04:50
> To: Forsberg Dan (Nokia-NRC/Helsinki); [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Pana] Issue 58 and issue 74: proposed text (take 4)
> 
> 
> Updated the text based on the latest comments.....
> 
> [1] Add to 4.1.1:
> 
>    o Nonce AVP: contains a randomly chosen value.
> 
> 
> [2] New text for section 4.9:
> 
> 4.9 Mobility Handling
> 
>    A mobile PaC's AAA performance can be enhanced by deploying a 
>    context-transfer-based mechanism, where some session 
> attributes are 
>    transferred from a previous PAA to the current one in 
> order to avoid 
>    performing a full EAP authentication (reactive approach). 
> Additional 
>    mechanisms that are based on the proactive AAA state 
> establishment at
> 
>    one or more candidate PAAs may be developed in the future 
>    [I-D.irtf-aaaarch-handoff]. The details of a 
> context-transfer-based 
>    mechanism is provided in this section.
> 
>    Upon changing its point of attachment, a PaC that wants to quickly
> resume 
>    its ongoing PANA session without running EAP MAY send the unexpired
>    PANA session identifier in its PANA-Start-Answer message. 
> Along with
> the
>    Session-Id AVP, MAC and Nonce AVPs MUST be included in 
> this message. 
>    Nonce AVP carries a randomly chosen value (PaC_Nonce), and MAC AVP
>    is computed by using the PANA_MAC_Key shared between the PaC and a
>    previous (anchor) PAA that has an unexpired PANA session with the
> PaC.
>    This action signals PaC's desire to perform the mobility
> optimization. In 
>    the absence of Session-Id AVP in this message, PANA 
> session takes its
> 
>    usual course (i.e., EAP-based authentication is performed).
> 
>    If PAA receives a session identifier in the PANA-Start-Answer
>    message, and it is configured to enable this optimization, it
>    SHOULD retrieve the PANA session attributes from the anchor PAA.
>    Current PAA determines the identity of the anchor PAA by looking at
> the
>    DiameterIdentity part of the PANA session identifier. The 
> MAC AVP can
>    only be verified by the anchor PAA, therefore a copy of the PANA
> messsage
>    SHOULD be provided to the anchor PAA. The mechanism 
> required to send
> a 
>    copy of the PANA-Start-Answer message from current PAA to 
> the anchor
> PAA, 
>    and retrieve the session attributes is outside the scope of this 
>    protocol. Seamoby Context Transfer Protocol [I-D.ietf-seamoby-ctp]
> might 
>    be useful for this purpose.
> 
>    When the anchor or current PAA is not configured to enable this 
>    optimization, the current PAA can not retrieve the PANA session 
>    attributes, or the PANA session has already expired (i.e., session 
>    lifetime is zero), the PAA MUST send the PANA-Auth-Request message
> with 
>    the new session identifier and let the PANA exchange take 
> its usual 
>    course. This action will engage EAP-based authentication 
> and create a
>    fresh PANA session from scratch.
> 
>    In case the current PAA can retrieve the on-going PANA session
> attributes
>    from the anchor PAA, the PANA session continues with a PANA-Bind
>    exchange. 
> 
>    As part of the context transfer, an intermediate AAA-Key 
> material is 
>    provided by the anchor PAA to the current PAA.  
> 
> 
>    AAA-Key-int = The first N bits of 
>                  HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID)
>                            
> 
>    In case there are two AAA-Keys generated from a NAP-ISP
> authentication,
>    the AAA-Key-int computation is:
> 
> 
>    AAA-Key-int = The first N bits of 
>                  HMAC-SHA1(AAA-Key1, AAA-Key2, DiameterIdentity | 
>                            Session-ID)
> 
>    
>    The value of N depends on the integrity protection algorithm in
>    use, i.e., N=160 for HMAC-SHA1. AAA-Key is the EAP-based
>    key that was made available to anchor PAA and PaC as a result of
>    the earlier EAP authentication. Due to the reliance on the AAA-Key,
> this 
>    optimization only works when PaC has performed an EAP-based 
>    authentication on the anchor PAA. DiameterIdentity is the 
> identifier
> of
>    the current PAA. Session-ID is the identifier of the PaC's PANA
> session 
>    with the anchor PAA. 
> 
>    Finally, current PAA and PaC compute the new AAA-Key by using the
> nonce 
>    values. PAA_Nonce is the randomly chosen value that MUST be carried
> in a 
>    Nonce AVP in the PANA-Bind-Request message.
> 
> 
>    AAA-Key-new = The first N bits of
>                  HMAC-SHA1(AAA-Key-int, PaC_nonce, PAA_nonce)
> 
> 
>    New PANA_MAC_Key is computed based on the algorithm described in
> Section 
>    4.1.5, by using the new AAA-Key and the new Session-ID assigned by
> the 
>    current PAA. The MAC AVP contained in the PANA-Bind-Request and 
>    PANA-Bind-Answer messages MUST be generated and verified 
> by using the
> new
>    PANA_MAC_Key. Session-ID AVP MUST include a new session identifier 
>    assigned by the current PAA. A new PANA session is created upon 
>    successful completion of this exchange. 
> 
>    Note that correct operation of this optimization relies on many
> factors,
>    including applicability of authorization state from one network 
>    attachment to another. [I-D.ietf-eap-keying] identifies this
> operation as 
>    "fast handoff" and provides deployment considerations. 
> Operators are 
>    recommended to take those guidelines into account when using this 
>    optimization in their networks. 
> 
>    
> [4] Change section 9.3.7 from:
> 
> 9.3.7 PANA-Bind-Request (PBR)
> 
>    PANA-Bind-Request (PBR) is sent by the PAA to the PaC.
> 
>          PANA-Bind-Request ::= < PANA-Header: 4, REQ >
>                        < Session-Id >
>                        < Device-Id >
>                        { EAP-Payload }
>                        { Result-Code }
>                        [ Session-Lifetime ]
>                        [ Protection-Capability ]
>                        [ Key-Id ]
>                     *  [ EP-Device-Id ]
>                     *  [ AVP ]
>                    0*1 < MAC >
> 
> to:
> 
> 9.3.7 PANA-Bind-Request (PBR)
> 
>    PANA-Bind-Request (PBR) is sent by the PAA to the PaC.
> 
>          PANA-Bind-Request ::= < PANA-Header: 4, REQ >
>                        < Session-Id >
>                        < Device-Id >
>                        [ EAP-Payload ]                    
>                        { Result-Code }
>                        [ Session-Lifetime ]
>                        [ Protection-Capability ]
>                        [ Key-Id ]
>                        [ Nonce]
>                     *  [ EP-Device-Id ]
>                     *  [ AVP ]
>                    0*1 < MAC >
> 
> 
> [5] Change 9.3.4:
> 
> Change:
> 
> 9.3.4 PANA-Start-Answer (PSA)
> 
>    PANA-Start-Answer (PSA) is sent by the PaC to the PAA in 
> response to
>    a PANA-Start-Request message.  The PANA_start message transmission
>    sequence number field is copied to the received sequence number
>    field.  The transmission sequence number is set to initial random
>    value.
> 
>          PANA-Start-Answer ::= < PANA-Header: 2 [SEP] >
>                        [ Cookie ]
>                        [ EAP-Payload ]
>                        [ ISP-Information ]
>                     *  [ AVP ]
> 
> 
> To:
> 
> 9.3.4 PANA-Start-Answer (PSA)
> 
>    PANA-Start-Answer (PSA) is sent by the PaC to the PAA in 
> response to
>    a PANA-Start-Request message.  The PANA_start message transmission
>    sequence number field is copied to the received sequence number
>    field.  The transmission sequence number is set to initial random
>    value.
> 
>          PANA-Start-Answer ::= < PANA-Header: 2 [SEP] >
>                        [ Session-Id ] 
>                        [ Cookie ]
>                        [ Nonce ]
>                        [ EAP-Payload ]
>                        [ ISP-Information ]
>                     *  [ AVP ]
>                    0*1 <MAC>                    
> 
> 
> [6] Update the AVP occurrence table from:
> 
>                           +-----------------------------------------+
>                           |        Message                          |
>                           |          Type                           |
>                           +-----+-----+-----+-----+-----+-----+-----+
>       Attribute Name      | PSR | PSA | PAR | PAN | PBR | PBA | PDI |
>       --------------------+-----+-----+-----+-----+-----+-----+-----+
>       EAP-Payload         | 0-1 | 0-1 |  1  |  1  |  1  |  0  |  0  |
>       Session-Id          |  0  |  0  |  1  |  1  |  1  |  1  | 0-1 |
>       MAC                 |  0  |  0  | 0-1 | 0-1 | 0-1 | 0-1 |  0  |
> 
> 
> 
> 
> 
> 
> 
> 
> To:
> 
>                           +-----------------------------------------+
>                           |        Message                          |
>                           |          Type                           |
>                           +-----+-----+-----+-----+-----+-----+-----+
>       Attribute Name      | PSR | PSA | PAR | PAN | PBR | PBA | PDI |
>       --------------------+-----+-----+-----+-----+-----+-----+-----+
>       EAP-Payload         | 0-1 | 0-1 |  1  |  1  | 0-1 |  0  |  0  |
>       Session-Id          |  0  | 0-1 |  1  |  1  |  1  |  1  | 0-1 |
>       MAC                 |  0  | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 |  0  |
>       Nonce               |  0  | 0-1 |  0  |  0  | 0-1 |  0  |  0  |
> 
> 
> 
> And add a line:
> 
>                           +-------------------------------+
>                           |      Message                  |
>                           |       Type                    |
>                           +------+------+-----+-----+-----+
>       Attribute Name      | PRAR | PRAA | PTR | PTA | PER |
>       --------------------+------+------+-----+-----+-----+
>       Nonce               |  0   |  0   |  0  |  0  |  0  |
>      
> 
> 
> 
> [7] Add 9.4.18:
> 
> 9.4.18 Nonce AVP
> 
>    The Nonce AVP (Code 1041) is of type OctetString. The data contains
>    a randomly generated value in opaque format. The data 
> length MUST be 
>    between 8 and 256 bytes inclusive.
> 
> 
> 
> [8] Add to references:
> 
> [I-D.irtf-aaaarch-handoff] draft-irtf-aaaarch-handoff-04.txt
> 
> 
> [9] Add to Security Considerations section:
> 
> i) Mobility optimization
> 
> The mobility optimization described in Section 4.9 involves an anchor
> PAA 
> providing a AAA-Key to the current PAA of the PaC. There are security
> risks 
> stemming from potential compromise of PAAs. Compromise of the current
> PAA 
> does not yield compromise of the anchor PAA, as AAA-Key cannot be
> computed 
> from a compromised AAA-Key-new. But a compromised anchor PAA 
> along with
> the 
> intercepted nonce values leads to the compromise of AAA-Key-new.
> Operators 
> should be aware of the potential risk of using this optimization. An
> operator can reduce the risk exposure by forcing the PaC to 
> perform an 
> EAP-based authentication immediately after the optimized PANA 
> execution.
> 
> 
> 

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

---

From: Alper Yegin <[email-masked]>
Date: Wed, 05 May 2004 12:01:53 -0700

The "anchor" PAA model was a leftover from the time we were using EMSK.
Now that we are not using this key, I think we can convert the scheme to
"chaining" as Dan suggests. 

The text is updated accordingly. Let's make sure we are not missing
something.

Alper

[1] Add to 4.1.1:

4.9 Mobility Handling

   A mobile PaC's AAA performance can be enhanced by deploying a 
   context-transfer-based mechanism, where some session attributes are 
   transferred from the previous PAA to the current one in order to
avoid 
   performing a full EAP authentication (reactive approach). Additional 
   mechanisms that are based on the proactive AAA state establishment at

   one or more candidate PAAs may be developed in the future 
   [I-D.irtf-aaaarch-handoff]. The details of a context-transfer-based 
   mechanism is provided in this section.

   Upon changing its point of attachment, a PaC that wants to quickly
resume 
   its ongoing PANA session without running EAP MAY send its unexpired
   PANA session identifier in its PANA-Start-Answer message. Along with
the
   Session-Id AVP, MAC and Nonce AVPs MUST be included in this message. 
   Nonce AVP carries a randomly chosen value (PaC_Nonce), and MAC AVP
   is computed by using the PANA_MAC_Key shared between the PaC and its
   previous PAA that has an unexpired PANA session with the PaC.
   This action signals PaC's desire to perform the mobility
optimization. In 
   the absence of Session-Id AVP in this message, PANA session takes its

   If PAA receives a session identifier in the PANA-Start-Answer
   message, and it is configured to enable this optimization, it
   SHOULD retrieve the PANA session attributes from the previous PAA.
   Current PAA determines the identity of the previous PAA by looking at
the
   DiameterIdentity part of the PANA session identifier. The MAC AVP can
   only be verified by the previous PAA, therefore a copy of the PANA 
   message SHOULD be provided to the previous PAA. The mechanism
required to 
   send a copy of the PANA-Start-Answer message from current PAA to the 
   previous PAA, and retrieve the session attributes is outside the
scope of 
   PANA protocol. Seamoby Context Transfer Protocol
[I-D.ietf-seamoby-ctp] 
   might be useful for this purpose.

   When the previous or current PAA is not configured to enable this 
   optimization, the current PAA can not retrieve the PANA session 
   attributes, or the PANA session has already expired (i.e., session 
   lifetime is zero), the PAA MUST send the PANA-Auth-Request message
with 
   a new session identifier and let the PANA exchange take its usual 
   course. This action will engage EAP-based authentication and create a
   fresh PANA session from scratch.

   In case the current PAA can retrieve the on-going PANA session
attributes
   from the previous PAA, the PANA session continues with a PANA-Bind
   exchange. 

   As part of the context transfer, an intermediate AAA-Key material is 
   provided by the previous PAA to the current PAA.  

   The value of N depends on the integrity protection algorithm in
   use, i.e., N=160 for HMAC-SHA1. DiameterIdentity is the identifier of
   the current PAA. Session-ID is the identifier of the PaC's PANA
session 
   with the previous PAA. 

   The current PAA and PaC compute the new AAA-Key by using the nonce 
   values and the AAA-Key-int. PAA_Nonce is the randomly chosen value
that 
   MUST be carried in a Nonce AVP in the PANA-Bind-Request message.

   PANA-Bind-Answer messages MUST be generated and verified by using the

   "fast handoff" and provides deployment considerations. Operators are 

to:

[5] Change 9.3.4:

Change:

   PANA-Start-Answer (PSA) is sent by the PaC to the PAA in response to
   a PANA-Start-Request message.  The PANA_start message transmission
   sequence number field is copied to the received sequence number
   field.  The transmission sequence number is set to initial random
   value.

To:

   PANA-Start-Answer (PSA) is sent by the PaC to the PAA in response to
   a PANA-Start-Request message.  The PANA_start message transmission
   sequence number field is copied to the received sequence number
   field.  The transmission sequence number is set to initial random
   value.

To:

And add a line:

[7] Add 9.4.18:

9.4.18 Nonce AVP

   The Nonce AVP (Code 1041) is of type OctetString. The data contains
   a randomly generated value in opaque format. The data length MUST be 
   between 8 and 256 bytes inclusive.

[8] Add to references:

i) Mobility optimization

The mobility optimization described in Section 4.9 involves the previous
PAA 
providing a AAA-Key to the current PAA of the PaC. There are security
risks 
stemming from potential compromise of PAAs. Compromise of the current
PAA 
does not yield compromise of the previous PAA, as AAA-Key cannot be
computed 
from a compromised AAA-Key-new. But a compromised previous PAA along
with 
the intercepted nonce values leads to the compromise of AAA-Key-new. 
Operators should be aware of the potential risk of using this
optimization. 
An operator can reduce the risk exposure by forcing the PaC to perform
an 
EAP-based authentication immediately after the optimized PANA execution.

---

From: Alper Yegin <[email-masked]>
Date: Wed, 05 May 2004 12:01:53 -0700

Alper

[1] Add to 4.1.1:

4.9 Mobility Handling

to:

[5] Change 9.3.4:

Change:

To:

To:

And add a line:

[7] Add 9.4.18:

9.4.18 Nonce AVP

[8] Add to references:

i) Mobility optimization

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 05 May 2004 12:41:47 -0700

> "chaining" as Dan suggests. 

OK.  Please see further comments below.

>                  HMAC-SHA1(AAA-Key1, AAA-Key2, DiameterIdentity | 

I noticed that three parameters are given to the HMAC-SHA1 function.
There should be two parameters instead.  There would be two
ways to fix this.

Algorithm 1:

     AAA-Key-int = The first N bits of 
                   HMAC-SHA1(AAA-Key1, AAA-Key2 | DiameterIdentity | 
                             Session-ID)

Algorithm 2:

     AAA-Key-int = The first N bits of 
                   HMAC-SHA1(AAA-Key', DiameterIdentity | Session-ID)

     where AAA-Key' is a combined key of AAA-Key1 and AAA-Key2.
     (Issue: How to combine the keys?)

Which is good, or any other algorithm?

Note that the same fix should be applied to the current PANA_MAC_Key
computation described in 4.1.5.

>                  HMAC-SHA1(AAA-Key-int, PaC_nonce, PAA_nonce)

Again there are three parameters.  

This should be:

     AAA-Key-new = The first N bits of
                   HMAC-SHA1(AAA-Key-int, PaC_nonce | PAA_nonce)

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 05 May 2004 12:41:47 -0700

Algorithm 1:

Algorithm 2:

This should be:

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Wed, 05 May 2004 18:24:03 -0700

> Which is good, or any other algorithm?

I think we can do this:

      AAA-Key-int = The first N bits of
                    HMAC-SHA1(AAA-Key1 | AAA-Key2, DiameterIdentity |
                              Session-ID)

Alper

> >                           |        Message
|
> >                           |          Type
|
> >                           |        Message
|
> >                           |          Type
|
execution.

---

From: Alper Yegin <[email-masked]>
Date: Wed, 05 May 2004 18:24:03 -0700

I think we can do this:

Alper

|
|
|
|
execution.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 06 May 2004 05:06:26 -0700

>                     HMAC-SHA1(AAA-Key1 | AAA-Key2, DiameterIdentity |

This should be OK.  I will reflect your take 5 with this key
computation algorithm to the manuscript under editing (and fix
PANA_MAC_Key computation algorithm in the same way).

Yoshihiro ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 06 May 2004 05:06:26 -0700

Yoshihiro ohba