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