Subject: RE: [Mip4] dynamic keys

From: "Jeremy A. Greene" <[email-masked]>
Date: Tue, 10 Feb 2004 21:44:05 -0500

Username/pw can be tied to their existing ones (like existing aaa pw or
through MS domain etc.). And username/pws tend to be easier to remember
and update. And a md5 key is not the easiest thing to remember or type
in. Anyway, it seems that it's a more traditional approach that people
have already dealt with in one way or another. This seems like another
thing to deal with.

Jeremy

-----Original Message-----
From: Henrik Levkowetz [mailto:[email-masked]] 
Sent: Tuesday, February 10, 2004 7:34 PM
To: Jeremy A. Greene
Cc: [email-masked]; [email-masked]
Subject: Re: [Mip4] dynamic keys

Hi Jeremy,

Tuesday 10 February 2004, Jeremy A. Greene wrote:
> So, it doesn't make the initial deployment any easier (if there's one
> HA), just ongoing use more secure. Each MN needs to be manually
> configured in some manually intensive secure manner and/or use a
> proprietary mechanism.
> 
> I guess I was looking more for a standardized server-side-only (aaa)
> configuration solution. More like the web, using server-side cert and
> client-side username/pw (over ssl).

But this is the same difference.  If you can distribute username/passwd
individually to users, you have your initial deployment shared secret,
no?

	Henrik

-- 
Mip4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip4

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 11 Feb 2004 11:06:12 +0100

Tuesday 10 February 2004, Jeremy A. Greene wrote:
> Username/pw can be tied to their existing ones (like existing aaa pw
> or through MS domain etc.).  And username/pws tend to be easier to
> remember and update. And a md5 key is not the easiest thing to
> remember or type in. Anyway, it seems that it's a more traditional
> approach that people have already dealt with in one way or another.
> This seems like another thing to deal with.

I see no reason why a one-time username/password (or a pre-existing one,
if it is deemed strong enough), cannot be run through a hash function to
give you your initial AAAH-MN key.  As long as the hash function is the
same at both ends, the entropy of the username/password used as input is
sufficient, and the method of distributing the username/password is
deemed secure enough for the application in hand, you're home free.
There's no reason to bother a user with entering a string of hex digits,
for instance. 

	Henrik