Re: [Mip4] dynamic keys

[Pete McCann <mccap at lucent.com>]

I think it's also important that the MN-AAA secret be generated
according to sound random number principles ala RFC 1750.  If a plain
text password is used, it may be vulnerable to offline dictionary
attacks because all the other input parameters to the HMACs are
potentially public knowledge.

Note that making the MN-AAA out of a one-way function from a plain
text password is not good enough, because it just adds one additional
step to the dictionary attack.

-Pete



Tom Hiller writes:

 > Jeremy,
 > 
 > I'd like to clarify a few things:
 > 
 > 1) The MN-AAA shared secret is used more than once
 > 2) It is periodically refreshed
 > 3) It is configured per mobile and is not shared by other mobiles
 > 4) aaa-keys does not say how the key is periodically refreshed.
 > 
 > I've acted as the editor, addressing security review comments and other=20
 > comments from IETF and 3GPP2 folks.   Summary: (1) The MN-AAA secret had=20
 > to be refreshed periodically.  That was added to the text.  (2) The term=20
 > "security association" was overloaded; "mobility security association",=20
 > etc., were added to the text.  There was an IANA assignment that did not=20
 > match earlier text in the draft, and other editorial nits.  Those were=20
 > fixed.
 > 
 > 
 > 	- Tom
 > 
 > PS In an earlier email, I provided a link to an MN-AAA shared secret=20
 > provisioning 3GPP2 specification that uses https.  A problem with=20
 > provisioning in cdma2000 is that the mobile may not have an IP address=20
 > at the time the provisioning server wishes to refresh the shared secret=20
 > or other data, the phone may have just been purchased, etc., so there=20
 > are radio network specific scenarios to be specified.
 > 

Jeremy A. Greene wrote:

> I was referring to the offline attacks. Where does it say in the mip-ke=
y=20
> or diameter-aaa drafts that username/pw would only be used once?
>=20
> =20
>=20
>  From section 5 of the mip-key draft:
>=20
> =20
>=20
> 1. Using the Key Generation Nonce from the extension, the mobile
>=20
>        node calculates
>=20
> =20
>=20
>           key =3D HMAC-MD5 (AAA-key, {Key Generation Nonce || home
>=20
>           address})
>=20
> ...
>=20
> The secret key used within the HMAC-MD5 computation is indicated by
>=20
>    the AAA Security Association indexed by the AAA SPI, which has been
>=20
>    previously configured as the basis for the AAA Security Association
>=20
>    between the mobile node and the AAA server creating the key material.
>=20
> =20
>=20
> If I understand what you=92re suggesting, the aaa-key above would be=20
> generated from a username/password on the MN (and HA, somehow). But the=
=20
> text above seems to imply it will be used every time the aaah sends a=20
> new nonce to create new =91session=92 keys.
>=20
> =20
>=20
> And I still think there=92s a practical issue of using passwords to cre=
ate=20
> a hash on the MN since the HA won=92t be able to verify it without the=20
> password clear-text to run through the same hash.
>=20
> =20
>=20
> Sorry if I=92m being slow on this, but everything with security is way =
too=20
> confusing!
>=20
> =20
>=20
> Jeremy
>=20
> =20
>=20
> -----Original Message-----
> From: Henrik Levkowetz [mailto:henrik@levkowetz.com]
> Sent: Wednesday, February 11, 2004 2:56 PM
> To: Jeremy A. Greene
> Cc: mip4@ietf.org; aaa-wg@merit.edu
> Subject: Re: [Mip4] dynamic keys
>=20
> =20
>=20
> Jeremy,
>=20
> =20
>=20
> Wednesday 11 February 2004, Jeremy A. Greene wrote:
>=20
>>  But, more importantly, there's a concern in the 802.11, wpa area that
>=20
>>  touches on this:
>=20
>>  http://wifinetnews.com/archives/002452.html
>=20
> =20
>=20
> No, there's no real similarity here.  The concern in this article is
>=20
> that it uses a broken procedure to generate a temporary session key,
>=20
> resulting in eavesdropping being possible, and goes on to discusses
>=20
> offline attacks on the passphrase.  Offline attacks on an authenticatin=
g
>=20
> password/username combination is not that relevant in a bootstrap
>=20
> scenario where you only use a specific username/password combination
>=20
> once, and any repeated use will be blocked.
>=20
> =20
>=20
>       Henrik
>=20


-- 
Mip4 mailing list
Mip4@ietf.org
https://www.ietf.org/mailman/listinfo/mip4


-- 
Mip4 mailing list
Mip4@ietf.org
https://www.ietf.org/mailman/listinfo/mip4