Re: [Sterman Issue 7] Message Authenticator: Options

Jari Arkko <jari.arkko@piuha.net> Mon, 22 November 2004 21:44 UTC

Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 22 Nov 2004 21:46:08 +0000
Message-ID: <41A25DA5.3040507@piuha.net>
Date: Mon, 22 Nov 2004 23:44:05 +0200
From: Jari Arkko <jari.arkko@piuha.net>
Reply-To: jari.arkko@piuha.net
Organization: None
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316
MIME-Version: 1.0
To: Avi Lior <avi@bridgewatersystems.com>
Cc: radiusext@ops.ietf.org
Subject: Re: [Sterman Issue 7] Message Authenticator: Options
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit

Hi Avi,

I may be missing some background here. [Ok, I confess I have
not read all the e-mails in my Inbox :-) ]

Why is this problem specific to RADIUS Digest draft? I realize
that it will have to reference the use of Message-Authenticator.
But so do other RADIUS specs. If the use of MD5 is an issue,
it would seem to be simpler that the IETF would just do it once
and for all in all of RADIUS. Alternatively, start mandating
IPsec.

Also, should RADIUS Digest go through unmodified,
standard RADIUS proxies? If so, how would they be aware of
a new AVP that they need to process?

Finally, if MD5 is bad, wouldn't that be a problem for
most Digest usage, RADIUS or not, given that the only
algorithms supported now are MD5 and AKA? I guess I'm
asking what makes the Message-Authenticator usage of
MD5 different from other RADIUS usage of MD5 or Digest
usage of MD5, both of which have to be relied upon anyway?
Or is the issue that the MD5 usage in Message-Authenticator
is particularly vulnerable?

--Jari

Avi Lior wrote:
> Hi folks,
> We would like to get closure on the issue of the use of Message
> Authenticator for draft-sterman-aaa-sip-04.
> 
> Everyone seems to agree that we need to use some sort of RADIUS Message
> Authenticator.
> 
> There was a discussion on the strength of HMAC-MD5.  Some suggested that we
> should stregthen the RADIUS Message-Authenticator to HMAC-SHA1.
> 
> -HMAC-MD5 is not busted (yet).
> -draft-sterman-aaa-sip-04 carries HTTP digest which are based on MD5.
> -draft-sterman-aaa-sip-04 seems to be addressing legacy deployements.
> Recommending that greenfield implementation use Diameter.
> -There is a push to get draft-sterman-aaa-sip-04 out quickly.
> -keywrap proposes a new message authenticator Message-Authentication-Code
> which supports either HMAC-MD5 or MHAC-SHA1 methods.
> 
> Options:
> ========
> 1) Allow draft-sterman-aaa-sip to use Message-Authenticator(80). And when
> keywrap is ready we can state in keywrap that RADIUS implmentation should
> upgrade to Message-Authentication-Code.
> 
> 2) Require draft-sterman-aaa-sip to use Message-Authentication-Code.
> 
> 
> Questions:
> ==========
> 
> -Will IESG accept a new RFC based on HMAC-MD5?
> If not then we don't really have a choice.
> 
> -Will keywrap be ready in time?
> This is important but the authors feel that it is ready to go.  However,
> note that Keywrap allows Message-Authentication-Code to be HMAC-MD5 isn't
> this a problem?
> 
> Your comments and opinion would be appreciated.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>