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

From: [email-masked]
Date: Tue, 4 May 2004 09:54:55 +0300

Two security related comments below.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> Alper Yegin
> Sent: 03 May, 2004 21:39
> To: 'Julien Bournelle'
> Cc: 'Yoshihiro Ohba'; [email-masked]
> Subject: RE: [Pana] Issue 58 and issue 74: proposed text (take 3)
> 
> 
> Hi Julien,
> 
> > >    outside the scope of this protocol. Seamoby Context Transfer
> Protocol
> > >
> > >    [I-D.ietf-seamoby-ctp] might be useful for this purpose.
> > 
> > As the PaC does not give its previous Device-Identifier, the anchor
> PAA
> > won't be able to retrieve the PANA context.
> 
> The PANA session identifier is sufficient to retrieve all the 
> parameters
> associated with the session. The CT protocol should carry the 
> session id
> to the anchor PAA. Note that this is the session between the 
> PaC and the
> anchor PAA.

How about adding the MAC AVP as well. Kind of authenticating the session. It makes the system just a bit more resistant to DoS attacks and the anchor PAA behavior more clear. The new PAA may add the Session-Id and the MAC into the CT protocol and the anchor PAA can then verify this request if it is valid or not. If the request is valid, then the session is moved/terminated/etc., but if it is not valid the session is unchanged AND the legitimitate PaC will keep it's session. Another plus is that at this point the DoS attack has been detected and not after the PANA-Bind message exchange.
 
> 
> > 
> > >
> > >    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.
> > >
> > >    A new AAA-Key is provided by the anchor PAA to the current PAA.
> The
> > >    anchor PAA and PaC perform the following computation for
> generating
> > > the
> > >    new AAA-Key:
> > >
> > >    AAA-Key-new = The first N bits of
> > >                  HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID)
> > 
> > if an attacker is able to get this AAA-Key, (s)he will be able to
> > compute this new key.
> 
> That's true. We address this issue in the 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 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.

To make the system a bit stronger I would suggest that PaC and the new-PAA would exchange nonces and include the nonces into the key generation process. 

First the anchor PAA and PaC compute the AAA-Key-new as it is described above (I assume that the anchor PAA then transmits the AAA-Key-new to the new PAA). Then with this AAA-Key-new PaC and new-PAA can exchange PANA-Bind messages and include fresh nonces (from both of them). Then 2nd key generation could take place

AAA-Key-Independent-new = The first N bits of
                          HMAC-SHA1 ( AAA-Key-new, Session-ID | PaC-Nonce | PAA-Nonce )

Then 2nd PANA-Bind message exchange would use this AAA-Key-Independent-new in the MAC calculation. The result would then be that with the AAA-Key (old) the AAA-Key-Indepenent-new can not be calculated.

- Dan

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

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

---

From: Julien Bournelle <[email-masked]>
Date: Tue, 4 May 2004 10:20:43 +0200

Hi all,

> How about adding the MAC AVP as well. Kind of authenticating the session. It makes the system just a bit more resistant to DoS attacks and the anchor PAA behavior more clear. The new PAA may add th…

the CT protocol already provides such a feature. In CTP, the MN triggers
the transfer by sending a CTAR message to the new access router. This message contains a keyed
hash which is computed with a key that the MN and the old Access Router
should share.

> Then 2nd PANA-Bind message exchange would use this AAA-Key-Independent-new in the MAC calculation. The result would then be that with the AAA-Key (old) the AAA-Key-Indepenent-new can not be calcula…

it sounds good

---

From: Julien Bournelle <[email-masked]>
Date: Tue, 4 May 2004 10:20:43 +0200

Hi all,

it sounds good

---

From: Alper Yegin <[email-masked]>
Date: Tue, 04 May 2004 18:50:13 -0700

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.

---

From: Alper Yegin <[email-masked]>
Date: Tue, 04 May 2004 18:50:13 -0700

[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