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