Subject: RADEXT Issue Tracking
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Date: Sat, 28 Aug 2004 10:03:43 -0700 (PDT)

We have currently encountered some difficulties in getting issues tracking
software (e.g. Roundup) hosted for the RADEXT WG.  Until we get those
issues resolved, we are doing manual issues tracking using the RADEXT WG
web page:

http://www.drizzle.com/~aboba/RADEXT/

In order to assist the chairs in maintaining the Issues list, we would
like to request that WG participants clearly indicate Issues by including
the string "Issue: " in the subject line of an issue.  We would also
appreciate if issues were posted in the format described on the RADEXT WG
web page above.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 27 Aug 2004 13:41:50 +0000
Date: Fri, 27 Aug 2004 15:39:57 +0200
From: Nagi Reddy Jonnala <[email-masked]>
Reply-To: [email-masked]
Organization: Alcatel Telecom
To: Barney Wolff <[email-masked]>
CC: Joseph Salowey <[email-masked]>, "'Bernard Aboba'" <[email-masked]>, "'Avi Lior'" <[email-masked]>, "'Beck01, Wolfgang'" <[email-masked]>, [email-masked]
Subject: Re: Issue with SIP - Need for Message-Authenticator

RIPv2 seem to be interested in HMAC-SHA1 and is described in the draft below.
The introduction section mentions that some governments insist on the use of
HMAC-SHA1 cryptographic mechanism. May be it is worth getting the author
opinions/comments about it.

http://www.ietf.org/internet-drafts/draft-rja-ripv2-auth-00.txt

regards
Nagi.

Barney Wolff wrote:

> On Thu, Aug 26, 2004 at 10:00:55AM -0700, Joseph Salowey wrote:
> > >
> > > Note that Message-Authenticator is based on HMAC-MD5.  Recent
> > > research has demonstrated collisions in MD5 (though not in
> > > HMAC-MD5), so that it may make sense to define a new
> > > attribute that uses a more highly regarded algorithm, such as
> > > HMAC-SHA1.
> >
> > [Joe] See
> > http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-01.txt, this
> > defines an attribute that can SHA for message authentication.
>
> As I read the chatter on the crypto list, it's premature to assume that
> SHA-1 will survive better than MD5, although it probably will.  Arguments
> have been made that HMAC-MD5 will not fall to MD5 attacks.  I'd suggest
> waiting at least a couple of weeks for the smoke to clear before acting.
>
> We do know that the RADIUS Authenticator has long been considered inferior
> to HMAC-MD5, and the recent issues may seal its fate.  It's therefore
> prudent to consider how to react when, or before, the authenticator is
> broken.  Certainly boxes that have sufficient cpu and codespace can use
> IPsec, as has already been suggested.  What, if anything, to do for/with
> boxes that cannot run IPsec is an open question.
>
> --
> Barney Wolff         http://www.databus.com/bwresume.pdf
> I'm available by contract or FT, in the NYC metro area or via the 'Net.
>
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 27 Aug 2004 13:41:39 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked], [email-masked]
Subject: AW: Comments on draft-sterman-aaa-sip-03
Date: Fri, 27 Aug 2004 15:40:35 +0200

Pete McCann wrote:

> Document should start with an overview of the assumed architecture, as
> shown in e.g. Figure 1 of Section 1.3.  However, the text of Section
> 1.3 dives into a particular scenario and a broader overview is
> necessary first.  (I think Miguel made this comment earlier)
> Section 1.2 (although I think this text should be deleted):
When I started working on the draft, people asked for a motivational
section.

I'll do an overview section which includes the 2 scenario sections

     1.3   Overview . . . . . . . . . . . . . . . . . . . . . . . . .  4
       1.3.1   Scenario 1, RADIUS client chooses nonces . . . . . . .  5
       1.3.2   Scenario 2, RADIUS server chooses nonces . . . . . . .  6

Section 1.3 will be the '1.5 Approach' section of -03 without the last
paragraph.

>   However, in
>   some cases the RADIUS server is better off with pre-computed hashes.
>   Section 1.4 describes an mechanism that enables this style of
>   authentication.
> This paragraph mentions "precomputed hashes" but then the issue is never
> revisited.  Is it true that precomputed hashes can be used with arbitrary
> message contents, or is some other coordination required between the
> home RADIUS server and the client?
Proposal:
"1.3.2  Scenario 2, RADIUS server chooses nonces

   In most cases, the operation outlined in Section 1.3.1 is sufficient.
   It reduces the load on the RADIUS server to a minimum.  However, when
   using AKA [RFC3310] the nonce is partially derived from a precomputed
   authentication vector.  These authentication vectors are often stored
   centrally.

   Figure 3 depicts an scenario, where the RADIUS server chooses nonces."

> Section 2:
> Reformat list of attributes into a table, and use values like "TBD-DIG-RES"
> in the table.  Create an IANA considerations section which requests allocations.
There is a IANA consideration section at the end of the document. I didn't want
to use DIG-RES etc. in the sub sections of 2. before explaining that they are
attribute names.

Proposal:
"2.  New RADIUS attributes

   DIG-RES, DIG-REALM, DIG-NONCE, DIG-METHOD, DIG-URI, DIG-QOP, DIG-ALG,
   DIG-BODY, DIG-CNONCE, DIG-NC, DIG-USER, DIG-OPAQUE, DIG-AUTHP,
   DIG-AUTS, DIG-DOMAIN and DIG-STALE are placeholders for values that
   are taken from the RADIUS attribute type number space (see Section 
   <IANA considerations>)."

> Don't use text like "if this specification becomes a working group or IESG
> document..."
> [..]
> Get rid of " Early implementations have used the experimental type
> 206."
Ok.

The following is confusing:

> 3.1  RADIUS Client Behaviour
> 
>    A RADIUS client without an encrypted or otherwise secured connection
>    to its RADIUS server only accepts unsecured connections from its
>    HTTP-style clients (or else the clients would have a false sense of
>    security).
> 
> It is not quite clear what is meant by "encrypted or otherwise
> secured", because there are several different security mechanisms
> available in RADIUS, including the hop-by-hop message authenticator
> and the shared-key method of obfuscating individual attributes.  I
"encrypted" ~ eg. IPSEC or proprietary tunnel technology
"otherwise secured" ~ eg. RADIUS client and server are in a closed MPLS
VPN.

> assume this would not be adequate to provide the protection you are
> looking for.  Also, what counts as an "unsecured connection" from an
> HTTP-style client?  Do you mean one that doesn't use either TLS or
> IPSec?
Yes. I'll insert a reference to the security considerations section,
which has this paragraph:
  "HTTP-style clients can use TLS with server side certificates together
   with HTTP-Digest authentication.  IPSec can be used in a similar way.
   TLS or IPSec secure the connection while Digest Authentication
   authenticates the user.  If a RADIUS client accepts such connections,
   it MUST have a secure connection to the RADIUS server."

> Maybe this paragraph is adequately covered by the security
> considerations (or should be) and could be deleted.
I disagree. If a SIP client wants the signalling to be secure,
it uses sips: URLs. All SIP proxies along the way must use TLS
connections to forward requests with sips: URLs. I don't think
the SIP proxies (=RADIUS clients) should expose parts of the SIP
message by using a unencrypted RADIUS messages in this case.

As this is part of the client behaviour, I put it into that section.

Thank you very much for your help,

Wolfgang

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 26 Aug 2004 23:38:43 +0000
Date: Thu, 26 Aug 2004 18:37:16 -0500
From: Pete McCann <[email-masked]>
To: [email-masked]
Subject: Comments on draft-sterman-aaa-sip-03

Hi, 

Attached are some review comments on draft-sterman-aaa-sip-03.

-Pete

Document should start with an overview of the assumed architecture, as
shown in e.g. Figure 1 of Section 1.3.  However, the text of Section
1.3 dives into a particular scenario and a broader overview is
necessary first.  (I think Miguel made this comment earlier)

Section 1.2 (although I think this text should be deleted):

Change:
   lacking support, too: even two years 
To:
   lacking support, too; even two years 

Change:
   SIP service providers whishing 
To:
   SIP service providers wishing

Section 1.5:

Change:
  Section 1.4 describes an mechanism 
To:
  Section 1.4 describes a mechanism 

   However, in
   some cases the RADIUS server is better off with pre-computed hashes.
   Section 1.4 describes an mechanism that enables this style of
   authentication.
This paragraph mentions "precomputed hashes" but then the issue is never
revisited.  Is it true that precomputed hashes can be used with arbitrary
message contents, or is some other coordination required between the
home RADIUS server and the client?

Section 2:
Reformat list of attributes into a table, and use values like "TBD-DIG-RES"
in the table.  Create an IANA considerations section which requests allocations.
Don't use text like "if this specification becomes a working group or IESG
document..."

Get rid of " Early implementations have used the experimental type
206."

The following is confusing:

3.1  RADIUS Client Behaviour

   A RADIUS client without an encrypted or otherwise secured connection
   to its RADIUS server only accepts unsecured connections from its
   HTTP-style clients (or else the clients would have a false sense of
   security).

It is not quite clear what is meant by "encrypted or otherwise
secured", because there are several different security mechanisms
available in RADIUS, including the hop-by-hop message authenticator
and the shared-key method of obfuscating individual attributes.  I
assume this would not be adequate to provide the protection you are
looking for.  Also, what counts as an "unsecured connection" from an
HTTP-style client?  Do you mean one that doesn't use either TLS or
IPSec?  Maybe this paragraph is adequately covered by the security
considerations (or should be) and could be deleted.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 26 Aug 2004 19:20:54 +0000
Date: Thu, 26 Aug 2004 12:18:35 -0700
From: Murtaza Chiba <[email-masked]>
To: Barney Wolff <[email-masked]>
CC: Joseph Salowey <[email-masked]>, "'Bernard Aboba'" <[email-masked]>, "'Avi Lior'" <[email-masked]>, "'Beck01, Wolfgang'" <[email-masked]>, [email-masked]
Subject: Re: Issue with SIP - Need for Message-Authenticator

 From what I understand, having an easy way to generate collisions does 
not mean that it will be easy to create valid RADIUS packets that result 
in the collision hash.  Also, its not been proved that cryptanalysis 
will help reverse engineer the cleartext from the hash.

Murtaza

Barney Wolff wrote:
> On Thu, Aug 26, 2004 at 10:00:55AM -0700, Joseph Salowey wrote:
> 
>>>Note that Message-Authenticator is based on HMAC-MD5.  Recent
>>>research has demonstrated collisions in MD5 (though not in
>>>HMAC-MD5), so that it may make sense to define a new
>>>attribute that uses a more highly regarded algorithm, such as
>>>HMAC-SHA1. 
>>
>>[Joe] See
>>http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-01.txt, this
>>defines an attribute that can SHA for message authentication.  
> 
> 
> As I read the chatter on the crypto list, it's premature to assume that
> SHA-1 will survive better than MD5, although it probably will.  Arguments
> have been made that HMAC-MD5 will not fall to MD5 attacks.  I'd suggest
> waiting at least a couple of weeks for the smoke to clear before acting.
> 
> We do know that the RADIUS Authenticator has long been considered inferior
> to HMAC-MD5, and the recent issues may seal its fate.  It's therefore
> prudent to consider how to react when, or before, the authenticator is
> broken.  Certainly boxes that have sufficient cpu and codespace can use
> IPsec, as has already been suggested.  What, if anything, to do for/with
> boxes that cannot run IPsec is an open question.
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 26 Aug 2004 18:59:11 +0000
Date: Thu, 26 Aug 2004 14:56:36 -0400
From: Barney Wolff <[email-masked]>
To: Joseph Salowey <[email-masked]>
Cc: "'Bernard Aboba'" <[email-masked]>, "'Avi Lior'" <[email-masked]>, "'Beck01, Wolfgang'" <[email-masked]>, [email-masked]
Subject: Re: Issue with SIP - Need for Message-Authenticator

On Thu, Aug 26, 2004 at 10:00:55AM -0700, Joseph Salowey wrote:
> > 
> > Note that Message-Authenticator is based on HMAC-MD5.  Recent
> > research has demonstrated collisions in MD5 (though not in
> > HMAC-MD5), so that it may make sense to define a new
> > attribute that uses a more highly regarded algorithm, such as
> > HMAC-SHA1. 
> 
> [Joe] See
> http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-01.txt, this
> defines an attribute that can SHA for message authentication.  

As I read the chatter on the crypto list, it's premature to assume that
SHA-1 will survive better than MD5, although it probably will.  Arguments
have been made that HMAC-MD5 will not fall to MD5 attacks.  I'd suggest
waiting at least a couple of weeks for the smoke to clear before acting.

We do know that the RADIUS Authenticator has long been considered inferior
to HMAC-MD5, and the recent issues may seal its fate.  It's therefore
prudent to consider how to react when, or before, the authenticator is
broken.  Certainly boxes that have sufficient cpu and codespace can use
IPsec, as has already been suggested.  What, if anything, to do for/with
boxes that cannot run IPsec is an open question.

-- 
Barney Wolff         http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 26 Aug 2004 18:42:20 +0000
content-class: urn:content-classes:message
Subject: RE: Issue with SIP - Need for Message-Authenticator
Date: Thu, 26 Aug 2004 11:41:37 -0700
From: "Randy Chou" <[email-masked]>
To: "Joseph Salowey" <[email-masked]>, "Bernard Aboba" <[email-masked]>, "Avi Lior" <[email-masked]>
Cc: "Beck01, Wolfgang" <[email-masked]>, <[email-masked]>, "Randy Chou" <[email-masked]>

If you're referring to the recent collisions found in MD5 and SHA-0,
here are a few points:

- Many believe that it's just a matter of time before a collision is
found in SHA-1.
- nothing indicates that the collisions affect HMAC-MD5.
- The more important (weakest link) in Radius is actually the response
authenticator which uses plain MD5.  If the method used in finding the
collision (diff analysis) can somehow speed up the cracking of the
RADIUS shared secret, it doesn't make any difference how the message
authenticator is arrived at.
- On the other hand, if someone has figured out how to crack this, it's
unlikely that the attack will be released to the public anytime soon due
to disclosure requirements :).

Any of these hashes coupled with a static shared key is an accident
waiting to happen.  The real fix IMO would be to derive encryption and
authentication keys through  assymetric encryption (use IKE/IPSEC, TLS,
...).  There's no point in patching it with HMAC-SHA1, might as well
leave it as is for compatibility.  The gain is minimal.

Regards,
=20
--
Randy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Joseph Salowey
Sent: Thursday, August 26, 2004 10:01 AM
To: 'Bernard Aboba'; 'Avi Lior'
Cc: 'Beck01, Wolfgang'; [email-masked]
Subject: RE: Issue with SIP - Need for Message-Authenticator

[email-masked] wrote:
> Thanks for pointing this out Avi.  Here is what it says in Section=20
> 5.19 of RFC 2869:
>=20
>    An Access-Request that contains either a User-Password or
>    CHAP-Password or ARAP-Password or one or more EAP-Message
>    attributes MUST NOT contain more than one type of those four=20
> attributes.  If it
>    does not contain any of those four attributes, it SHOULD contain a
>    Message-Authenticator.  If any packet type contains an EAP-Message
>    attribute it MUST also contain a Message-Authenticator.
>=20
> Note that Message-Authenticator is based on HMAC-MD5.  Recent research

> has demonstrated collisions in MD5 (though not in HMAC-MD5), so that=20
> it may make sense to define a new attribute that uses a more highly=20
> regarded algorithm, such as HMAC-SHA1.

[Joe] See
http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-01.txt,
this defines an attribute that can SHA for message authentication. =20

>=20
> On Thu, 26 Aug 2004, Avi Lior wrote:
>=20
>> Wolfgang,
>>=20
>> In the SIP doc I think you need to use Message-Authenticator(80) in=20
>> the access request.
>>=20
>> The problem is this:  without using a field such as CHAP-Password or=20
>> Password, the RADIUS server has no way to validate that the=20
>> Access-Request is arriving from a valid NAS.
>>=20
>> Message-Authenticator(80) is used to provide integrity protection for

>> the entire Access-Request packet and can be used by the RADIUS Server

>> to validate that the packet was received from a known Client (since=20
>> the Message-Authenticator uses a shared secret shared by the
>> Client-Server.)
>>=20

>>=20
>>=20
>> --
>> to unsubscribe send a message to
> [email-masked] with
>> the word 'unsubscribe' in a single line as the message text body.
>> archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 26 Aug 2004 17:02:11 +0000
From: "Joseph Salowey" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, "'Avi Lior'" <[email-masked]>
Cc: "'Beck01, Wolfgang'" <[email-masked]>, <[email-masked]>
Subject: RE: Issue with SIP - Need for Message-Authenticator
Date: Thu, 26 Aug 2004 10:00:55 -0700

[email-masked] wrote:
> Thanks for pointing this out Avi.  Here is what it says in
> Section 5.19 of RFC 2869:
> 
>    An Access-Request that contains either a User-Password or
>    CHAP-Password or ARAP-Password or one or more EAP-Message
>    attributes MUST NOT contain more than one type of those four
> attributes.  If it
>    does not contain any of those four attributes, it SHOULD contain a
>    Message-Authenticator.  If any packet type contains an EAP-Message
>    attribute it MUST also contain a Message-Authenticator.
> 
> Note that Message-Authenticator is based on HMAC-MD5.  Recent
> research has demonstrated collisions in MD5 (though not in
> HMAC-MD5), so that it may make sense to define a new
> attribute that uses a more highly regarded algorithm, such as
> HMAC-SHA1. 

[Joe] See
http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-01.txt, this
defines an attribute that can SHA for message authentication.  

> 
> On Thu, 26 Aug 2004, Avi Lior wrote:
> 
>> Wolfgang,
>> 
>> In the SIP doc I think you need to use Message-Authenticator(80) in
>> the access request. 
>> 
>> The problem is this:  without using a field such as CHAP-Password or
>> Password, the RADIUS server has no way to validate that the
>> Access-Request is arriving from a valid NAS.
>> 
>> Message-Authenticator(80) is used to provide integrity protection for
>> the entire Access-Request packet and can be used by the RADIUS Server
>> to validate that the packet was received from a known Client (since
>> the Message-Authenticator uses a shared secret shared by the
>> Client-Server.) 
>> 

>> 
>> 
>> --
>> to unsubscribe send a message to
> [email-masked] with
>> the word 'unsubscribe' in a single line as the message text body.
>> archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 26 Aug 2004 14:14:57 +0000
Content-class: urn:content-classes:message
Subject: RE: REMINDER: RADEXT WG last call on RFC 2486bis
Date: Thu, 26 Aug 2004 10:13:26 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Last reminder -- this WGLC completes today.

> This is a reminder of RADEXT WG Last Call in progress on "The Network
> Access Identifier" specification, RFC 2486bis, prior to sending the
draft
> on to the IESG for consideration as an IETF Proposed Standard
(recycled).
> The draft is available for inspection at:
>=20
>
http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-02.tx
t
>=20
> RADEXT WG Last Call will complete on August 26, 2004.  Please send
> comments to the RADEXT WG mailing list ([email-masked]), using
the
> issue format described at
http://www.drizzle.com/~aboba/AAA/issues.html.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 26 Aug 2004 14:14:42 +0000
Content-class: urn:content-classes:message
Subject: RE: REMINDER: RADEXT WG last call on RADIUS Extension for Digest Authentication
Date: Thu, 26 Aug 2004 10:12:37 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Last reminder -- this WGLC completes today.

> This is a reminder of the ongoing RADEXT WG Last Call on the "RADIUS
> Extension
> for Digest Authentication" specification, prior to sending the draft
on to
> the IESG for consideration as an IETF Proposed Standard. The
> draft is available for inspection at:
>=20
> http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-03.txt
>=20
> RADEXT WG Last Call will complete on August 26, 2004.  Please send
> comments to the RADEXT WG mailing list ([email-masked]), using
the
> issue format described at
http://www.drizzle.com/~aboba/AAA/issues.html.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 26 Aug 2004 13:10:44 +0000
Date: Thu, 26 Aug 2004 06:00:49 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Avi Lior <[email-masked]>
cc: "Beck01, Wolfgang" <[email-masked]>, [email-masked]
Subject: Re: Issue with SIP - Need for Message-Authenticator

Thanks for pointing this out Avi.  Here is what it says in Section 5.19 of
RFC 2869:

   An Access-Request that contains either a User-Password or
   CHAP-Password or ARAP-Password or one or more EAP-Message attributes
   MUST NOT contain more than one type of those four attributes.  If it
   does not contain any of those four attributes, it SHOULD contain a
   Message-Authenticator.  If any packet type contains an EAP-Message
   attribute it MUST also contain a Message-Authenticator.

Note that Message-Authenticator is based on HMAC-MD5.  Recent research has
demonstrated collisions in MD5 (though not in HMAC-MD5), so that it may
make sense to define a new attribute that uses a more highly regarded
algorithm, such as HMAC-SHA1.

On Thu, 26 Aug 2004, Avi Lior wrote:

> Wolfgang,
>
> In the SIP doc I think you need to use Message-Authenticator(80) in the
> access request.
>
> The problem is this:  without using a field such as CHAP-Password or
> Password, the RADIUS server has no way to validate that the Access-Request
> is arriving from a valid NAS.
>
> Message-Authenticator(80) is used to provide integrity protection for the
> entire Access-Request packet and can be used by the RADIUS Server to
> validate that the packet was received from a known Client (since the
> Message-Authenticator uses a shared secret shared by the Client-Server.)
>
>
>
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 26 Aug 2004 09:08:23 +0000
From: Avi Lior <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>, [email-masked]
Subject: Issue with SIP - Need for Message-Authenticator
Date: Thu, 26 Aug 2004 05:07:07 -0400

Wolfgang,

In the SIP doc I think you need to use Message-Authenticator(80) in the
access request.

The problem is this:  without using a field such as CHAP-Password or
Password, the RADIUS server has no way to validate that the Access-Request
is arriving from a valid NAS.

Message-Authenticator(80) is used to provide integrity protection for the
entire Access-Request packet and can be used by the RADIUS Server to
validate that the packet was received from a known Client (since the
Message-Authenticator uses a shared secret shared by the Client-Server.)

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 25 Aug 2004 16:12:53 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Subject: open issue: rspauth generation not possible if RADIUS server choo ses nonces and qop=auth-int
Date: Wed, 25 Aug 2004 18:12:13 +0200

rspauth generation not possible if RADIUS server chooses nonces
and qop=auth-int
Submitter name: Wolfgang Beck
Submitter email address: [email-masked]
Date first submitted: 25.8.2004
Reference: 
Document: RADIUS Extension for Digest Authentication
Comment type: T
Priority: 1
Section: 3.1, 3.2
Rationale/Explanation of issue:
Jun Wang wrote:
> As the RADIUS server does not know about the response body the
> RADIUS client is going to send, it can't generate A2.
> 
> In 3GPP2, we do need to perform auth-int because we need to protect the 
> response that is sent from the network to the MS. I hope in this draft you 
> could allow solution 3 or at least you will not preclude solution 3 so that 
> we can have 3GPP2 VSA to do it.
> 
> Thanks,
> Jun
> 
> Beck01, Wolfgang wrote:
>> Hello Jun,
>> 
>> thank you for your review. Rahul Joshi told me about this problem
>> some weeks ago and I think there are three possible solutions: 1)
>> don't use authentication-info with auth-int 2) send all possible
>> response body-digests to the RADIUS server 3) your suggestion.
>> 
>> I am not sure about the security implications of 3). Replay
>> attacks might be possible. Solution 2) is a bit bloated as it
>> would double the work on client and server.
>> 
>> In the San Diego meeting, I proposed using solution 1) and
>> did not hear any objections.
>> 
>>
>> Jun Wang wrote
>>>
>>> By reviewing sterman draft (RADIUS Extension for Digest Authentication, 
>>> draft-sterman-aaa-sip-03.txt), I have questions on how the RADIUS sever can 
>>> calculate the Digest-Response that can be used by RADIUS client to 
>>> construct Auth-info header (mentioned in section 3.2 in sterman draft). 
>>> According to 3.2.3 of RFC 2617, if I understand correctly, the response 
>>> digest is calculated as for the request-digest except that A2 is slightly 
>>> different. But regardless, to calculate Digest-Response, the RADIUS server 
>>> needs to know H(entity-body), here entity-body, I think, is the body 
>>> contained in 200OK response. But RADIUS server doesn't know it. It seems to 
>>> me that the right thing is to pass some derived key to RADIUS client so 
>>> that the RADIUS client can calculate Auth-info.
>>> 
>>> 
Requested change:

[Jun Wang]
>>> [..] It seems to me that the right thing is to pass some
>>> derived key to RADIUS client so that the RADIUS client can
>>> calculate Auth-info.

[Wolfgang Beck]
When using qop=auth-int, the response-auth value is 

response-auth  = <"> < KD ( H(A1),     unq(nonce-value)
                                          ":" nc-value
                                          ":" unq(cnonce-value)
                                          ":" unq(qop-value)
                                          ":" H(A2)
                                  ) <">

with algorithm = MD5, A1 and A2 are:

A1       = unq(username-value) ":" unq(realm-value) ":" passwd
A2       = ":" digest-uri-value ":" H(entity-body)

Sending H(A1) in an Access-Accept message would be risky as A1
has no random components. Replay attacks are possible.

with algorithm = MD5-sess, A1 and A2 are:

A1       = H( unq(username-value) ":" unq(realm-value)
                     ":" passwd )
                     ":" unq(nonce-value) ":" unq(cnonce-value)
A2       = ":" digest-uri-value ":" H(entity-body)

here, A1 has some randomness. A possible solution might be:
1. Add a new attribute to carry H(A1), Digest-HA1
2. Use Digest-HA1 if server chooses nonces, qop=auth-int and
algorithm=MD5-sess
3. Use a Digest-Response-Auth attribute (new, see issue 4, 5) 
if server chooses nonces and qop != auth-int.
4. On reception of Digest-HA1, the RADIUS client constructs
rspauth, using the nonce received in a previous Access-Challenge

I don't know if this is really secure.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 25 Aug 2004 16:11:25 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Subject: open issue:draft-sterman, use of Access-Challenge
Date: Wed, 25 Aug 2004 18:09:57 +0200

Use of Access-Challenge
Submitter name: Wolfgang Beck
Submitter email address: [email-masked]
Date first submitted: 25.8.2004
Reference: 
Document: RADIUS Extension for Digest Authentication
Comment type: T
Priority: 2
Section: 1.4, 3.1, 3.2
Rationale/Explanation of issue:
draft-sterman-aaa-sip-03 uses Access-Accept messages with a Digest-Nonce,
but without a Digest-Response parameter. This is a in fact a challenge
message and should use RADIUS Access-Challenge.

Requested change:
1.4 Scenario 2, RADIUS server chooses nonces

   Figure 2 depicts an alternative scenario, where the RADIUS server
   generates nonces.  It shows a generic case where entities A and B
   communicate in the front-end using protocols such as HTTP/SIP, while
   entities B and C communicate in the back-end using RADIUS.

                     HTTP/SIP           RADIUS
   
            +-----+    (1)    +-----+           +-----+
            |     |==========>|     |    (2)    |     |
            |     |           |     |---------->|     |
            |     |           |     |    (3)    |     |
            |     |    (4)    |     |<----------|     |
            |     |<==========|     |           |     | 
            |     |    (5)    |     |           |     |
            |     |==========>|     |           |     |
            |  A  |           |  B  |    (6)    |  C  |
            |     |           |     |---------->|     |
            |     |           |     |    (7)    |     |
            |     |           |     |<----------|     |
            |     |    (8)    |     |           |     |
            |     |<==========|     |           |     |
            +-----+           +-----+           +-----+

            ====> HTTP/SIP
            ----> RADIUS

                 Figure 2: RADIUS server chooses nonces

   The roles played by the entities in this scenario are as follows:

   A: HTTP client / SIP UA

   B:  {HTTP  server / HTTP proxy server / SIP proxy server / SIP UAS}
   acting also as a RADIUS NAS

   C: RADIUS server

   The relevant order of messages sent in this scenario is as follows:

   A sends B an HTTP/SIP request without authorization header (step 1).
   B sends an Access-Request message with the newly defined
   Digest-Method and Digest-URI attributes but without a Digest-Nonce
   attribute to the RADIUS server, C (step 2).  C chooses a nonce and
   responds with an Access-Challenge (step 3).  This Access-Challenge
   contains Digest attributes, from which B takes values to construct a
   HTTP/SIP "(Proxy) Authorization required" response.  The remaining 
   steps are identical with scenario 1 (Section 1.3): B sends this
   response to A (step 4).  A resends its request with its credentials
   (step 5).  B sends an Access-Request to C (step 6).  C checks the
   credentials and replies with Access-Accept or Access-Reject (step 7).
   Dependent on the C's result, B processes A's request or rejects it

3.1  RADIUS Client Behaviour

   [..]
   The RADIUS client has three ways to obtain nonces: it generates them
   locally, it has received one in a Digest-Nonce attribute of a
   previously received Access-Accept message, or it asks the RADIUS
   server for one.  To do the latter, it sends an Access-Request
   containing a Digest-Method and a Digest-URI attribute but without a
   Digest-Nonce attribute.  The RADIUS server chooses a nonce and
   responds with an Access-Challenge containing a Digest-Nonce
   attribute.  If the RADIUS server responds with an Access-Reject, the
   RADIUS client MAY generate a nonce locally.  If the RADIUS client
   does not generate nonces locally, the authentication has failed.  The
   RADIUS server can send Digest-QoP, Digest-Algorithm, Digest-Realm,
   Digest-Domain and Digest-Opaque attributes in the Access-Accept
   carrying the nonce.  If these attributes are present, the client MUST
   use them.

3.2  RADIUS Server Behaviour

   If the RADIUS server receives an Access-Request message with a
   Digest-Method and a Digest-URI attribute but without a Digest-Nonce
   attribute, it chooses a nonce.  It puts the nonce into a Digest-Nonce
   attribute and sends it in an Access-Challenge message to the RADIUS
   client.  The RADIUS server MUST add Digest-Algorithm, Digest-Realm,
   SHOULD add Digest-QoP and MAY add Digest-Domain, Digest-Opaque
   attributes to the Access-Challenge message.  If the server cannot
   choose a nonce, it replies with an Access-Reject message.
    [..]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 23 Aug 2004 19:47:05 +0000
Content-class: urn:content-classes:message
Subject: Notes from the Monday session??
Date: Mon, 23 Aug 2004 15:44:54 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Would the minute takers for the Monday RADEXT WG session at IETF 60 =
please forward those notes to me?  Thanks!  I think these were =
previously sent to Bernard, but he's on vacation and I need to get the =
minutes submitted prior to September 5.  I have the notes from the =
Thursday session.

Regards,
=A0
Dave
=A0

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 22 Aug 2004 17:17:35 +0000
Content-class: urn:content-classes:message
Subject: RE: Moving forward on billable identities
Date: Sun, 22 Aug 2004 10:16:16 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Yes, we will move this attribute (known as User Identity Alias in
http://www.ietf.org/internet-drafts/draft-adrangi-radius-attributes-exte
nsion-01.txt) to a separate ID.  =20
BR,
Farid

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Saturday, August 21, 2004 2:34 PM
> To: [email-masked]
> Subject: Moving forward on billable identities
>=20
>=20
> At IETF 60, there was a desire expressed to move forward on a document
> relating to the billable identities issue.
>=20
> Here is what needs to be done:
>=20
> a. Submit an Internet-Draft covering this subject exclusively.
> b. Request comments/reviews from the RADEXT WG mailing list.
> c. Assuming the reaction is favorable, request adoption as a WG
>    work item.
>=20
> Note that there has already been considerable RADEXT WG=20
> discussion on this
> topic, much of which has centered around the need for this=20
> attribute and
> potential backward compatibility issues.
>=20
> Therefore I'd suggest that the document make a convincing=20
> case for why a
> new attribute is needed, and describe how backward=20
> compatibility can be
> handled.
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 21 Aug 2004 21:40:21 +0000
Date: Sat, 21 Aug 2004 14:33:58 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Moving forward on billable identities

At IETF 60, there was a desire expressed to move forward on a document
relating to the billable identities issue.

Here is what needs to be done:

a. Submit an Internet-Draft covering this subject exclusively.
b. Request comments/reviews from the RADEXT WG mailing list.
c. Assuming the reaction is favorable, request adoption as a WG
   work item.

Note that there has already been considerable RADEXT WG discussion on this
topic, much of which has centered around the need for this attribute and
potential backward compatibility issues.

Therefore I'd suggest that the document make a convincing case for why a
new attribute is needed, and describe how backward compatibility can be
handled.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 18 Aug 2004 22:12:05 +0000
Date: Wed, 18 Aug 2004 15:05:53 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: WG Web page

I've put up a preliminary version of the RADEXT WG Web page at:
http://www.drizzle.com/~aboba/RADEXT/

Comments welcome.

A request.  At IETF 60 we mentioned that we would like to move to
automated issue tracking.  If there are folks in the WG who have
experience with these tools (Roundup, RT, Bugzilla, etc.), please send
email to the chairs.  We are also looking for help with hosting the issue
tracking system.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 18 Aug 2004 06:46:59 +0000
Date: Tue, 17 Aug 2004 23:40:47 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: REMINDER: RADEXT WG last call on RADIUS Extension for Digest Authentication

This is a reminder of the ongoing RADEXT WG Last Call on the "RADIUS Extension
for Digest Authentication" specification, prior to sending the draft on to
the IESG for consideration as an IETF Proposed Standard. The
draft is available for inspection at:

http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-03.txt

RADEXT WG Last Call will complete on August 26, 2004.  Please send
comments to the RADEXT WG mailing list ([email-masked]), using the
issue format described at http://www.drizzle.com/~aboba/AAA/issues.html.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 18 Aug 2004 06:46:35 +0000
Date: Tue, 17 Aug 2004 23:40:07 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: REMINDER: RADEXT WG last call on RFC 2486bis

This is a reminder of RADEXT WG Last Call in progress on "The Network
Access Identifier" specification, RFC 2486bis, prior to sending the draft
on to the IESG for consideration as an IETF Proposed Standard (recycled).
The draft is available for inspection at:

http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-02.txt

RADEXT WG Last Call will complete on August 26, 2004.  Please send
comments to the RADEXT WG mailing list ([email-masked]), using the
issue format described at http://www.drizzle.com/~aboba/AAA/issues.html.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 17 Aug 2004 11:44:52 +0000
Date: Tue, 17 Aug 2004 14:43:54 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: [email-masked]
Cc: [email-masked]
Subject: Re: Comments for 2486bis WGLC

Pasi,

Thanks for your suggestions. I agree with them.

--Jari

> Some minor comments about draft-arkko-roamops-rfc2486bis-02:
> 
> - In Section 2.1, on the line
> 
>    c           =/ %x2b    ; '*'              allowed
> 
>   the '*' in the comment should be '+'
> 
> - In Section 2.1, the line
> 
>    c           =/ %x5e-7e ; '^' - '          allowed
> 
>   would probably be easier to understand if written out:
> 
>    c           =/ %x5e    ; '^'              allowed
>    c           =/ %x5f    ; '_'              allowed
>    c           =/ %x60-7a ; 'a'-'z'          allowed
>    c           =/ %x7b    ; '{'              allowed
>    c           =/ %x7c    ; '|'              allowed
>    c           =/ %x7d    ; '}'              allowed
>    c           =/ %x7e    ; '~'              allowed
> 
> - In Appendix A, fourth bullet: it seems there are no 
>   stricter requirements on the part preceding the '!' 
>   sign _unless_ it's explicitly known that this realm 
>   supports this syntax. 
> 
>   So it's not a backwards-compatibility problem: something 
>   like "[email-masked]" continues to be a valid NAI 
>   (even though "foo" is not a valid realm) unless it's 
>   known that example.com uses the stricter syntax
>   from section 2.7.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 17 Aug 2004 11:26:45 +0000
content-class: urn:content-classes:message
Subject: Comments for 2486bis WGLC
Date: Tue, 17 Aug 2004 14:25:22 +0300
From: <[email-masked]>
To: <[email-masked]>

Hi,

Some minor comments about draft-arkko-roamops-rfc2486bis-02:

- In Section 2.1, on the line

   c           =3D/ %x2b    ; '*'              allowed

  the '*' in the comment should be '+'

- In Section 2.1, the line

   c           =3D/ %x5e-7e ; '^' - '          allowed

  would probably be easier to understand if written out:

   c           =3D/ %x5e    ; '^'              allowed
   c           =3D/ %x5f    ; '_'              allowed
   c           =3D/ %x60-7a ; 'a'-'z'          allowed
   c           =3D/ %x7b    ; '{'              allowed
   c           =3D/ %x7c    ; '|'              allowed
   c           =3D/ %x7d    ; '}'              allowed
   c           =3D/ %x7e    ; '~'              allowed

- In Appendix A, fourth bullet: it seems there are no=20
  stricter requirements on the part preceding the '!'=20
  sign _unless_ it's explicitly known that this realm=20
  supports this syntax.=20

  So it's not a backwards-compatibility problem: something=20
  like "[email-masked]" continues to be a valid NAI=20
  (even though "foo" is not a valid realm) unless it's=20
  known that example.com uses the stricter syntax
  from section 2.7.

Best regards,
Pasi

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 17 Aug 2004 04:17:17 +0000
Date: Tue, 17 Aug 2004 07:16:03 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "[email-masked]'" <[email-masked]>
Cc: Charlie Kaufman <[email-masked]>
Subject: Re: [Ipsec] IKEv2 identifier issue with EAP

Copying the RADEXT list on my question to the IPsec WG
and Charlie Kaufman's response:

Charlie Kaufman wrote:
> I agree that this is likely to become a problem, that any of your
> 'possible solutions' could be used to fix it (except that I don't
> believe the first two 'define the problem away' were serious proposals),
> and that the community SHOULD agree on one standard approach to maximize
> interoperability.
> 
> My favorite would be:
>     o  Go against the SHOULD NOT when the given NAI requires this.
> 
> ...because this also addresses the identity type hint that you say might
> be coming. But others have argued heatedly that it is important to
> minimize the number of messages in an IKE exchange, and this would
> result in an eight message exchange while some of the other proposals
> work in six.
> 
> I'm really glad it's not my job anymore to herd the cats towards one
> approach or the other.
> 
> 	--Charlie
> 
> p.s. If you are going to define a new ID type, it would need to be added
> to the IANA registry for IKEv2. The procedure for this is "expert
> review". It could probably be defined in some EAP RFC and ratified by
> some expert chosen by the security ADs, but I don't know.
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Jari Arkko
> Sent: Monday, August 16, 2004 4:17 AM
> To: IPsec WG
> Cc: Bernard Aboba
> Subject: [Ipsec] IKEv2 identifier issue with EAP
> 
> 
> First some background: In traditional EAP usage, the client's identifier
> has been determined through the EAP Identity Request/Response exchange.
> The identifier is typically a Network Access Identifier (NAI). Basically
> an identifier similar to an e-mail address, used to identify the user
> and to find the right home network in case of a roaming user.
> 
> IKEv2-14 says the following:
> 
>     Note that since IKE passes an indication of initiator identity in
>     message 3 of the protocol, EAP based prompts for Identity SHOULD NOT
>     be used.
> 
> it also defines one of the identity type as follows:
> 
>     ID_RFC822_ADDR                      3
> 
>       A fully-qualified RFC822 email address string, An example of
>       a ID_RFC822_ADDR is, "[email-masked]".  The string MUST
>       not contain any terminators.
> 
> In the RADEXT and EAP WGs, we have recently discussed some
> problems that this causes. Here are the issues:
> 
> 1. A revision of the NAI specification, RFC 2486bis, intends
>     to extend the existing user@domain format in
>     draft-arkko-roamops-rfc2486bis-02.txt, partially based on
>     existing practise. This spec is currently in WGLC in the
>     RADEXT WG.
> 
>     One of the extensions is to allow the client's identity
>     to be hidden from the access server / IKEv2 gateway,
>     if the used EAP method supports end-to-end encrypted
>     tranmission of the identity. Syntactically, this
>     happens through specifying an empty username, "@domain"
>     but keeping the domain pawrt in order to make the AAA
>     routing possible.
> 
>     The issue with IKEv2 is strictly speaking, this
>     string would be illegal in RFC 822. Hence an IKEv2
>     implementation can not be relied upon to accept such
>     "privacy" user names.
> 
> 2. Another extension from this draft is internationalized
>     NAIs. The domain parts are IDNs, i.e., converted to ASCII
>     via a specific mapping, but the username part is UTF-8.
>     Again, this is strictly speaking not conformant to RFC 822,
>     so sending an internationalized username via IKEv2 might
>     not be possible. For instance, someone might be assigned
>     a username for WLAN access, but the usage of this username
>     for IKEv2 purposes might not be possible if it contains
>     international characters.
> 
>     Some of the possible solutions to avoid this problem
>     include
> 
>     o  Decide that support of privacy & international usernames
>        is not necessary in IKEv2.
> 
>     o  Remove the privacy and international username (not domain)
>        parts from RFC 2486bis.
> 
>     o  Change the international username part so that instead of
>        UTF-8, it uses a IDN-like ASCII mapping which can represent
>        non-ASCII characters but it looks like ASCII to the carrier.
>        Either remove the privacy feature or just say it can not
>        be used in all carrier protocols.
> 
>     o  Define a new IKEv2 ID type to carry the new types NAIs.
>        (If so, would this type be defined in the NAIbis, IKEv2
>        or some other draft?)
> 
>     o  Rely on IKEv2 implementations to not check the contents
>        of the identifier for RFC 822 compliance.
> 
>     o  Go against the SHOULD NOT when the given NAI requires this.
> 
> 3. Ongoing work (and some existing practise) provides some
>     information through the EAP identity request. More specifically,
>     the client can get a hint of what type of identifier it should
>     offer. See draft-adrangi-eap-network-discovery-03.txt.
> 
>     This functionality does not appear to be present when running
>     EAP over IKEv2. (I have not heard of any customer who wanted
>     this functionality in this context, but I'd like to avoid
>     special cases where possible.)

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 16 Aug 2004 06:59:26 +0000
From: Tschofenig Hannes <[email-masked]>
To: "'Yoshihiro Ohba'" <[email-masked]>, [email-masked]
Subject: RE: IKEv2 issue in RFC2486bis
Date: Mon, 16 Aug 2004 08:57:40 +0200

hi yoshi, 

i am very much in favour of your proposal for adding new IKEv2 ID type. 

i have sent the ikev2 folks a mail about this issue many months ago. no
reply. 
i hope it will be different now. 

ciao
hannes

ps: i also dislike the mentioned paragraph from section 3.16. 

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Sunday, August 29, 2004 7:12 PM
> To: [email-masked]
> Subject: IKEv2 issue in RFC2486bis
> 
> Hi,
> 
> I had a discussion with Jari, Bernard and Pasi on an IKEv2 
> issue of RFC2486bis and the following is the summary of the 
> discussion (please correct if I am wrong):
> 
> Section 3.16 of draft-ietf-ipsec-ikev2-14.txt says:
> 
> "
>    Note that since IKE passes an indication of initiator identity in
>    message 3 of the protocol, EAP based prompts for Identity 
> SHOULD NOT
>    be used.
> "
> 
> This means that an RFC2486bis NAI may be carried in an IKEv2 
> Identity Payload when EAP is used in IKEv2.  In this case, 
> there is an issue of which ID Type of IKEv2 Identification 
> Payload is appropriate to carry the RFC2486bis NAI.
> 
> One possibility is using ID_RFC822_ADDR, but RFC822 address 
> is not compatible with RFC2486bis NAI at least in that (i) 
> RFC822 address does NOT allow the characters preceding "@" 
> (i.e., local-part) to be null and (ii) RFC822 address does 
> NOT allow ASCII control characters to appear in local-part 
> without being quoted as quoted-string (thus a
> UTF-8 encoded username with containing ASCII control 
> characters is not compatible with local-part of RFC822 address.)
> 
> Since IKEv2 specification does not prohibit an implementation 
> to perform strict check against RFC 822 format and returns an 
> error Notification with "INVALID_SYNTAX" when the strict 
> check fails, I think using ID_RFC822_ADDR for RFC2486bis NAI 
> has an interoperability problem.  Using ID_KEY_ID is not 
> appropriate to carry RFC2486bis either, since it is used for 
> carrying certain proprietary types of identification.
> 
> To solve the problem, I would suggest defining a new IKEv2 
> Identification Payload Type to carry RFC2486bis NAI.
> 
> Also, draft-ietf-ipsec-ikev2-iana-02.txt says:
> 
> "
> 7.1 Amending formula for IKEv2 Identification Payload ID Types
> 
>    IKEv2 Identification Payload ID Types may be allocated by
>    Specification Required.
> "
> 
> So I think RFC2486bis could be the Specification where the 
> new IKEv2 ID Type is defined.
> 
> This was not discussed, but when a given RFC2486bis NAI also 
> conforms to RFC822 address, I think such an NAI can also be 
> carried as ID_RFC822_ADDR ID type.
> 
> Best regards,
> 
> Yoshihiro Ohba
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 15 Aug 2004 20:50:56 +0000
Date: Sun, 15 Aug 2004 23:49:47 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>
Cc: Yoshihiro Ohba <[email-masked]>, [email-masked]
Subject: Re: IKEv2 issue in RFC2486bis

Bernard Aboba wrote:
>>Question: Would this be part of the NAIbis RFC, or a
>>separate RFC?
> 
> 
> It should be fixed in the IKEv2 I-D that is now under evaluation.

The IKEv2 people will be glad when they hear about this.

>>My interpretation is that this allows any type of text
>>(even non-ASCII), except ASCII control characters. There's
>>also a special treatment for " and \. So it seems that we
>>can carry an internationalized username here, or even a
>>privacy NAI (but the latter would not make sense with
>>current Digest algorithms).
> 
> 
> OK.  So is the SIP "username" a subset or superset of the NAI user-name
> grammar?

Taking a new look at the RFCs, there's really three
answers:

(1) If you allow for escape (\x), then both syntaxes can
     represent exactly the same username strings. Technically, this
     means that you can take any HTTP Digest username value
     and put into a legal NAI, but you may have to add/remove
     some escape characters.

(2) If you do not allow for escape or don't do the related
     conversion, then there are some strings that are legal
     in a HTTP Digest username value, but illegal in a NAI.
     Example: <nancy>@example.net

(3) NAI spec requires that the domain name part actually
     be a domain name. RFC 2617 did not require that for the
     username part. So conceivably you could use [email-masked]
     in SIP, but that would be invalid as a NAI. Also, a
     AAA node trying to use the domain name part in some
     manner might get into trouble.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 15 Aug 2004 15:21:40 +0000
Date: Sun, 15 Aug 2004 08:15:31 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: Yoshihiro Ohba <[email-masked]>, [email-masked]
Subject: Re: IKEv2 issue in RFC2486bis

> Question: Would this be part of the NAIbis RFC, or a
> separate RFC?

It should be fixed in the IKEv2 I-D that is now under evaluation.

> My interpretation is that this allows any type of text
> (even non-ASCII), except ASCII control characters. There's
> also a special treatment for " and \. So it seems that we
> can carry an internationalized username here, or even a
> privacy NAI (but the latter would not make sense with
> current Digest algorithms).

OK.  So is the SIP "username" a subset or superset of the NAI user-name
grammar?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 15 Aug 2004 08:21:28 +0000
Date: Sun, 15 Aug 2004 11:20:12 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>
Cc: Yoshihiro Ohba <[email-masked]>, [email-masked]
Subject: Re: IKEv2 issue in RFC2486bis

Bernard Aboba wrote:
>>o  Define the new IKEv2 ID type as Yoshihiro suggests
>>   below.
> 
> 
> I'd support this alternative.  IKEv2 is already incompatible with RFC
> 2486, so this would need to be done anyway.

Question: Would this be part of the NAIbis RFC, or a
separate RFC?

>>Finally, does anyone have a full list of places where the
>>NAI can appear? Either because the protocol specs say that
>>a particular field is a NAI, or because people take a
>>particular application identifier and put it into a place
>>which traditionally carries a NAI (such as RADIUS User-Name).
>>I think we are talking about PPP, EAP, RADIUS, Diameter,
>>SIP and Mobile IPv4, but is this all? What do these specifications
>>say about non-RFC822 compliant names?
> 
> 
> In PPP, EAP, RADIUS and Diameter the structure of the NAI is not
> constrained, so I don't think there is an issue.
> 
> In RFC 2794, it defines the NAI field as "A string in the NAI format
> defined in [1]." So I don't think there is an issue there either.

Ok. Thanks for the info.

> I didn't know that SIP utilized the NAI.  Where is this usage defined?

It is not defined directly as a NAI. It falls into the class of
fields that get copied into a place that traditionally carries
a NAI. When using HTTP digest with SIP, a system implementing
either the RADIUS or Diameter SIP application will put the
"username" field from the Digest headers into the AAA User-Name
AVP.

Here's the syntax of the "username" field from RFC 2616-2617:

        username         = "username" "=" username-value
        username-value   = quoted-string
        quoted-string  = ( <"> *(qdtext | quoted-pair ) <"> )
        qdtext         = <any TEXT except <">>
        quoted-pair    = "\" CHAR
        TEXT           = <any OCTET except CTLs,
                         but including LWS>
        CTL            = <any US-ASCII control character
                         (octets 0 - 31) and DEL (127)>
        CR             = <US-ASCII CR, carriage return (13)>
        LF             = <US-ASCII LF, linefeed (10)>
        SP             = <US-ASCII SP, space (32)>
        HT             = <US-ASCII HT, horizontal-tab (9)>
        CRLF           = CR LF
        LWS            = [CRLF] 1*( SP | HT )

My interpretation is that this allows any type of text
(even non-ASCII), except ASCII control characters. There's
also a special treatment for " and \. So it seems that we
can carry an internationalized username here, or even a
privacy NAI (but the latter would not make sense with
current Digest algorithms).

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 14 Aug 2004 13:27:38 +0000
Date: Sat, 14 Aug 2004 06:21:53 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: Yoshihiro Ohba <[email-masked]>, [email-masked]
Subject: Re: IKEv2 issue in RFC2486bis

> o  Define the new IKEv2 ID type as Yoshihiro suggests
>    below.

I'd support this alternative.  IKEv2 is already incompatible with RFC
2486, so this would need to be done anyway.

> Finally, does anyone have a full list of places where the
> NAI can appear? Either because the protocol specs say that
> a particular field is a NAI, or because people take a
> particular application identifier and put it into a place
> which traditionally carries a NAI (such as RADIUS User-Name).
> I think we are talking about PPP, EAP, RADIUS, Diameter,
> SIP and Mobile IPv4, but is this all? What do these specifications
> say about non-RFC822 compliant names?

In PPP, EAP, RADIUS and Diameter the structure of the NAI is not
constrained, so I don't think there is an issue.

In RFC 2794, it defines the NAI field as "A string in the NAI format
defined in [1]." So I don't think there is an issue there either.

I didn't know that SIP utilized the NAI.  Where is this usage defined?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 14 Aug 2004 10:54:44 +0000
Date: Sat, 14 Aug 2004 13:53:37 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Yoshihiro Ohba <[email-masked]>
Cc: [email-masked]
Subject: Re: IKEv2 issue in RFC2486bis

Oh, and I forgot one more possibility, see below:

>>From the 10.000 ft point of view, I see the following
> possibilities:
> 
> o  Decide that support of privacy & international usernames
>    is not necessary in IKEv2.
> 
> o  Remove the privacy and international username (not domain)
>    parts from RFC 2486bis.
> 
> o  Change the international username part so that instead of
>    UTF-8, it uses a IDN-like ASCII mapping which can represent
>    non-ASCII characters but it looks like ASCII to the carrier.
>    Either remove the privacy feature or just say it can not
>    be used in all carrier protocols.
> 
> o  Define the new IKEv2 ID type as Yoshihiro suggests
>    below.

o  Rely on IKEv2 implementations to not check the contents
    of the identifier for RFC 822 compliance.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 14 Aug 2004 07:48:04 +0000
Date: Sat, 14 Aug 2004 10:46:50 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Yoshihiro Ohba <[email-masked]>
Cc: [email-masked]
Subject: Re: IKEv2 issue in RFC2486bis

Thanks for bringing this issue up, Yoshihiro. I think
this problem is serious and we need to decide
what to do about it.

>From the 10.000 ft point of view, I see the following
possibilities:

o  Decide that support of privacy & international usernames
   is not necessary in IKEv2.

o  Remove the privacy and international username (not domain)
   parts from RFC 2486bis.

o  Change the international username part so that instead of
   UTF-8, it uses a IDN-like ASCII mapping which can represent
   non-ASCII characters but it looks like ASCII to the carrier.
   Either remove the privacy feature or just say it can not
   be used in all carrier protocols.

o  Define the new IKEv2 ID type as Yoshihiro suggests
   below.

Finally, does anyone have a full list of places where the
NAI can appear? Either because the protocol specs say that
a particular field is a NAI, or because people take a
particular application identifier and put it into a place
which traditionally carries a NAI (such as RADIUS User-Name).
I think we are talking about PPP, EAP, RADIUS, Diameter,
SIP and Mobile IPv4, but is this all? What do these specifications
say about non-RFC822 compliant names?

--Jari

Yoshihiro Ohba wrote:
> Hi,
> 
> I had a discussion with Jari, Bernard and Pasi on an IKEv2 issue of
> RFC2486bis and the following is the summary of the discussion 
> (please correct if I am wrong):
> 
> Section 3.16 of draft-ietf-ipsec-ikev2-14.txt says:
> 
> "
>    Note that since IKE passes an indication of initiator identity in
>    message 3 of the protocol, EAP based prompts for Identity SHOULD NOT
>    be used.
> "
> 
> This means that an RFC2486bis NAI may be carried in an IKEv2 Identity
> Payload when EAP is used in IKEv2.  In this case, there is an issue of
> which ID Type of IKEv2 Identification Payload is appropriate to carry
> the RFC2486bis NAI.
> 
> One possibility is using ID_RFC822_ADDR, but RFC822 address is not
> compatible with RFC2486bis NAI at least in that (i) RFC822 address
> does NOT allow the characters preceding "@" (i.e., local-part) to be
> null and (ii) RFC822 address does NOT allow ASCII control characters
> to appear in local-part without being quoted as quoted-string (thus a
> UTF-8 encoded username with containing ASCII control characters is not
> compatible with local-part of RFC822 address.)
> 
> Since IKEv2 specification does not prohibit an implementation to
> perform strict check against RFC 822 format and returns an error
> Notification with "INVALID_SYNTAX" when the strict check fails, I
> think using ID_RFC822_ADDR for RFC2486bis NAI has an interoperability
> problem.  Using ID_KEY_ID is not appropriate to carry RFC2486bis
> either, since it is used for carrying certain proprietary types of
> identification.
> 
> To solve the problem, I would suggest defining a new IKEv2
> Identification Payload Type to carry RFC2486bis NAI.
> 
> Also, draft-ietf-ipsec-ikev2-iana-02.txt says:
> 
> "
> 7.1 Amending formula for IKEv2 Identification Payload ID Types
> 
>    IKEv2 Identification Payload ID Types may be allocated by
>    Specification Required.
> "
> 
> So I think RFC2486bis could be the Specification where the new IKEv2
> ID Type is defined.
> 
> This was not discussed, but when a given RFC2486bis NAI also conforms
> to RFC822 address, I think such an NAI can also be carried as
> ID_RFC822_ADDR ID type.
> 
> Best regards,
> 
> Yoshihiro Ohba
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 13 Aug 2004 22:56:17 +0000
Date: Sun, 29 Aug 2004 13:12:26 -0400
From: Yoshihiro Ohba <[email-masked]>
Subject: IKEv2 issue in RFC2486bis
To: [email-masked]

Hi,

I had a discussion with Jari, Bernard and Pasi on an IKEv2 issue of
RFC2486bis and the following is the summary of the discussion 
(please correct if I am wrong):

Section 3.16 of draft-ietf-ipsec-ikev2-14.txt says:

"
   Note that since IKE passes an indication of initiator identity in
   message 3 of the protocol, EAP based prompts for Identity SHOULD NOT
   be used.
"

This means that an RFC2486bis NAI may be carried in an IKEv2 Identity
Payload when EAP is used in IKEv2.  In this case, there is an issue of
which ID Type of IKEv2 Identification Payload is appropriate to carry
the RFC2486bis NAI.

One possibility is using ID_RFC822_ADDR, but RFC822 address is not
compatible with RFC2486bis NAI at least in that (i) RFC822 address
does NOT allow the characters preceding "@" (i.e., local-part) to be
null and (ii) RFC822 address does NOT allow ASCII control characters
to appear in local-part without being quoted as quoted-string (thus a
UTF-8 encoded username with containing ASCII control characters is not
compatible with local-part of RFC822 address.)

Since IKEv2 specification does not prohibit an implementation to
perform strict check against RFC 822 format and returns an error
Notification with "INVALID_SYNTAX" when the strict check fails, I
think using ID_RFC822_ADDR for RFC2486bis NAI has an interoperability
problem.  Using ID_KEY_ID is not appropriate to carry RFC2486bis
either, since it is used for carrying certain proprietary types of
identification.

To solve the problem, I would suggest defining a new IKEv2
Identification Payload Type to carry RFC2486bis NAI.

Also, draft-ietf-ipsec-ikev2-iana-02.txt says:

"
7.1 Amending formula for IKEv2 Identification Payload ID Types

   IKEv2 Identification Payload ID Types may be allocated by
   Specification Required.
"

So I think RFC2486bis could be the Specification where the new IKEv2
ID Type is defined.

This was not discussed, but when a given RFC2486bis NAI also conforms
to RFC822 address, I think such an NAI can also be carried as
ID_RFC822_ADDR ID type.

Best regards,

Yoshihiro Ohba

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 09 Aug 2004 13:50:59 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: AW: [AAA-WG]: AW: Comments to draft-sterman-aaa-sip-03 and draft- ietf-aaa-sip-a pp-03
Date: Mon, 9 Aug 2004 15:50:31 +0200 

Bernard,

>> After converting the draft to flat attributes, I tried to save attribute
>> space. It is a scarce resource in RADIUS.
>
> Point of process.  In the RADEXT WG, issues are not resolved by assertion.
> They are resolved by WG discussion.
Just take my response to Miguel as a contribution to the WG discussion.

> Also, saving attribute space is not a design goal of this document.
> Diameter compatibility *is* a design goal.
If we can do both, why shouldn't we? If not, I've no problem adding attributes
to the draft.

Wolfgang

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 09 Aug 2004 13:47:16 +0000
Date: Mon, 09 Aug 2004 16:46:32 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>
Cc: "Beck01, Wolfgang" <[email-masked]>, [email-masked], Miguel Garcia <[email-masked]>
Subject: Re: [AAA-WG]: AW: Comments to draft-sterman-aaa-sip-03 and draft-ietf-aaa-sip-a pp-03

Wolfgang Beck wrote:

> After converting the draft to flat attributes, I tried to save attribute
> space. It is a scarce resource in RADIUS.

Bernard Aboba wrote:

> Also, saving attribute space is not a design goal of this document.
> Diameter compatibility *is* a design goal.

In general, I'd rather have a larger number of attributes
in a draft than cause problems for translation. Of course
we can build special cases for attributes, but I'd rather
have NASREQ-style completely automatic mapping (attribute =>
AVP from RADIUS space) or at least simple table driven
mapping (attribute => AVP from Diameter space with same
type).

Note: if RADIUS attribute space really runs out, we can
create more, through an IETF "vendor" attribute, for
instance.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 09 Aug 2004 12:55:44 +0000
Date: Mon, 9 Aug 2004 05:50:30 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>
cc: [email-masked]
Subject: Re: [AAA-WG]: AW: Comments to draft-sterman-aaa-sip-03 and draft-ietf-aaa-sip-a pp-03

> After converting the draft to flat attributes, I tried to save attribute
> space. It is a scarce resource in RADIUS.

Point of process.  In the RADEXT WG, issues are not resolved by assertion.
They are resolved by WG discussion.

Also, saving attribute space is not a design goal of this document.
Diameter compatibility *is* a design goal.

Issue 4 will remain open until the Diameter compatibility implications are
discussed and understood.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 09 Aug 2004 07:28:00 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: AW: Comments to draft-sterman-aaa-sip-03 and draft-ietf-aaa-sip-a pp-03
Date: Mon, 9 Aug 2004 09:27:04 +0200 

Miguel,

> 1) Abstract: The abstract looks more like an introduction to me, 
> providing a motivation for this work. I think the abstract should just 
> indicate what this document provides, rather than a historical 
> description of the capabilities of RADIUS, SIP and HTTP. I would suggest 
> a text around this lines:
> 
> "This document specifies an extension to RADIUS that allows a RADIUS 
> client in a SIP/HTTP server, upon reception of a SIP/HTTP request, 
> retrieve and compute Digest authentication information from a RADIUS 
> server. Additionally, a scenario describing  the authentication of a 
> user emiting a SIP/HTTP request is provided."
Thank you for this proposal.

> 3) draft-sterman defines a Digest-Body attribute. But actually, the 
> attribute will not contain a body, but the hash of a body. I would 
> suggest to rename this attribute to Digest-Entity-Body-Hash. It happens 
> that this is the name of the same AVP in Diamter SIP app.
Digest-Body-Digest looked a bit strange to me and Digest-Entity-Body-Hash
a bit long. But I've no problem changing it.

> 4) I noticed that draft-sterman does not specified a Digest-Nextnonce 
> attribute, but we have a Digest-Nextnonce AVP in Diameter SIP app. It 
> seems that draft-sterman reuses Digest-Nonce to transport a nextnonce. 
> While the mechanism probably works, I would suggest to define a new 
> Digest-Nextnonce attribute in draft-sterman, since the semantics of 
> Nonce and Nextnonce are completely different, so they are sent in 
> different parameters in the Digest header. Is this acceptable?
> 
> 5) Similar to #4 above, I noticed that draft-sterman defines a 
> Digest-Response that presumably is used to map it to both "response" and 
> "rspauth" in Digest. As in #4, the semantics of both Digest parameters 
> are different, so the attributes should be. In Diameter SIP app. we 
> define Digest-Response and Digest-Response-Auth AVPs. I would suggest 
> that draft-sterman splits Digest-Response similarly. Is this acceptable?
After converting the draft to flat attributes, I tried to save attribute
space. It is a scarce resource in RADIUS.

> 6) Question of documentation. I noticed that all the attribute 
> descriptions in draft-sterman include a figure containing the position 
> of Type, Length and String. I wonder if it is needed to repeat the 
> figure in all the attribute descriptions or whether you can indicate in 
> a general paragraph the commonality shared by all the attributes (among 
> others, the structure represented in those figures).
OK.

> 7) Section 2.1 in draft-sterman. The definition of Type says:
>      Type
>           DIG-RES for Digest-Response.  Early implementations have used
>           the experimental type 206.
> 
>     I would suggest to remove the last sentence. It is not relevant for 
> this document the value an early implementation has used or not. What is 
> important is the value assigned by IANA.
OK.

> 8) Section 2.16, Digest-Stale. I notice that draft-sterman and Diameter 
> SIP app are not synchronized with the possible values of this attribute.
> 
> Draft-sterman indicates that if Digest-Stale is present, its value will 
> always be set to "1". This will be mapped to the stale="true" parameter 
> in Digest. I understan that if Digest-Stale is not present, then the 
> RADIUS client should assume that stale="false" or simple not present in 
> Digest
> [..]
> My proposal is that draft-sterman aligns with Diameter SIP app and the 
> value of the Digest-Stale AVP includes a quoted string that is straight 
> forward mapped to the stale parameter in Digest. Is this acceptable?
Yes.

> In general, I found that this section 4 has to be rewritten once we 
> agree on the proposals in this e-mail. It would become easier to map 
> both documents now.
There will be some more changes as I will use Access-Challenge in the next
version of the draft.  

> 11) Section 5:
> 
> I would expect that this section starts with the following sentence:
>
> "This document serves as IANA registration request for ..."
> 
> Particularly, I would remove the dependency on becoming a working group 
> (item) or IESG document.
OK.

> 12) Examples in Section 7:
> 
> This one was a shock to me. It violates all the rules of writing RFCs. 
> For instance, it does not use the IP address space suggested for 
> examples, it does not use the example.com domain name.
> 
> The SIP examples luck a few mandatory headers (e.g., Max-Forwards), 
> contains the name of commertial products, contains undocumented 
> extensions to SDP, misses recommendations of populating several SIP 
> headers and SDP lines...
> 
> If you want to continue in this path, I may suggest that an expert 
> reviewer assigned by the transport AD should inspect this examples.
> 
> I have a better suggestion: at the end of the day, this draft is about 
> Digest and RADIUS. So why don't you focus on Digest and RADIUS in the 
> examples? create some sort of abstract SIP/HTTP request, and just write 
> down the Digest headers, but not the whole SIP message.
To be honest, I took the examples without much review from the -00 version
which was based on RfC 2543. 

Thank you for this detailed review,

Wolfgang

--
Wolfgang Beck
T-Systems
Internet Netzplattformen
+49 6151 937 2863
Am Kavalleriesand 3
64295 Darmstadt 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 06 Aug 2004 10:54:07 +0000
Date: Fri, 6 Aug 2004 03:49:05 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Presentations from IETF60

Are available at:
http://www.drizzle.com/~aboba/IETF60/radext/

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 05 Aug 2004 07:43:50 +0000
Date: Thu, 05 Aug 2004 03:43:26 -0400
To: [email-masked],[email-masked]
From: Paul Funk <[email-masked]>
Subject: Re: shared secret vulnerability 
Cc: [email-masked],Joshua Wright <[email-masked]>

Randy,

See my last email. (I responded before I saw this one.)

I will clarify the actual vs. effective entropy issue in the next
draft. Also, I'll put some text in about the precomputed
dictionary attack, which isn't in the current draft.

Paul

Randy Chou wrote:
Yes, you're right.  I also missed that the first time I read Paul's
draft.  Entropy would only be increased if the possible number of
outputs increased.  Since the salt is fixed (and known anyways based on
PKCS#5), the number of possible outputs only depends on the precursor
secret itself.  The representation of the output increased so that would
make it harder to brute force.  But that's not to say that someone would
not be able to find a faster way to reach the result besides the brute
force method.  It just seems very very difficult.

So Paul, the following comment may need to be revised depending on
interpretation:

 > Differently stated, 20
    bits of effective entropy are added to a secret when hashed one
    million times; thus, a secret with 40 bits of entropy provides 60
    bits of effective entropy after amplification

Regards,

--
Randy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Clint Chaplin
Sent: Wednesday, August 04, 2004 2:00 PM
To: [email-masked]; [email-masked]
Subject: Re: shared secret vulnerability

My impression is that hashing doesn't add any more entropy than was
already present in the input.  Yes, hashing adds time to the
calculation, but the output itself isn't any more entropic than the
input was.  Am I incorrect?

Clint (JOATMON) Chaplin
 >>> Joshua Wright <[email-masked]> 08/04/04 13:54 PM >>>
Paul Funk wrote:
  > The idea is that you take an ordinary secret, hash it many times,  >
and get a resulting "amplified" shared secret that multiplies the  >
difficulty of attack by the number of times it has been hashed. The  >
draft suggests 0x100000 (~ one million) iterations, adding 2 ^ 20  >
bits of effective entropy to the secret.

While I believe this algorithm is effective at adding entropy to a
password such as the RADIUS secret, it does not resolve the issue of a
widespread shared secret distributed throughout an organization. Without

a mechanism in place to regularly change the secret, the use of shared
secrets in this fashion is reminiscent of WEP pre-shared keys. As most
people are painfully aware, shared secret do not stay secretive.

That being said, I like Paul's idea for effectively adding entropy to
the shared secret that will prolong a brute-force attack.  However, I do

not believe that this is effective at resolving weak authentication
between the RADIUS authentication server and NAS.

-Joshua Wright
[email-masked] or
[email-masked]

-- 
-Joshua Wright
[email-masked]
http://home.jwu.edu/jwright/

pgpkey: http://home.jwu.edu/jwright/pgpkey.htm
fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 05 Aug 2004 07:35:21 +0000
Date: Thu, 05 Aug 2004 03:34:56 -0400
To: [email-masked],[email-masked]
From: Paul Funk <[email-masked]>
Subject: Re: shared secret vulnerability 
Cc: Joshua Wright <[email-masked]>

--=====================_231727500==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Clint,

Yes, the entropy isn't really increased. In the amplification draft,
I often used the term "effective entropy", since it is really that the
added difficulty in attacking the hashed secret makes it
equivalent in entropy to a stronger secret for the purpose of
dictionary attack.

There is a "precomputed" type of dictionary attack in which
a dictionary is computed in advance and stored on, say,
CD-ROM. The CD-ROM items are then used to attack a
signature. Thus, if the attacker first created a CD-ROM of all
amplified shared secrets based on likely precursor secrets,
the attack from such a CD-ROM against a signature with
an amplified secret would be no harder than an attack against
a signature based on a precursor secret. This illustrates your
point about conservation of entropy. However, to create such
a CD-ROM would take a very, very long time and you'd need
lots of CD-ROMs.

Paul

Clint Chapin wrote:
My impression is that hashing doesn't add any more entropy than was already 
present in the input.  Yes, hashing adds time to the calculation, but the 
output itself isn't any more entropic than the input was.  Am I incorrect?

Clint (JOATMON) Chaplin
 >>> Joshua Wright <[email-masked]> 08/04/04 13:54 PM >>>
Paul Funk wrote:
  > The idea is that you take an ordinary secret, hash it many times,
  > and get a resulting "amplified" shared secret that multiplies the
  > difficulty of attack by the number of times it has been hashed. The
  > draft suggests 0x100000 (~ one million) iterations, adding 2 ^ 20
  > bits of effective entropy to the secret.

While I believe this algorithm is effective at adding entropy to a
password such as the RADIUS secret, it does not resolve the issue of a
widespread shared secret distributed throughout an organization. Without
a mechanism in place to regularly change the secret, the use of shared
secrets in this fashion is reminiscent of WEP pre-shared keys. As most
people are painfully aware, shared secret do not stay secretive.

That being said, I like Paul's idea for effectively adding entropy to
the shared secret that will prolong a brute-force attack.  However, I do
not believe that this is effective at resolving weak authentication
between the RADIUS authentication server and NAS.

-Joshua Wright
[email-masked] or
[email-masked]

-- 
-Joshua Wright
[email-masked]
http://home.jwu.edu/jwright/

pgpkey: http://home.jwu.edu/jwright/pgpkey.htm
fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

--=====================_231727500==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
Clint,<br><br>
Yes, the entropy isn't really increased. In the amplification draft,
<br>
I often used the term &quot;effective entropy&quot;, since it is really
that the <br>
added difficulty in attacking the hashed secret makes it <br>
equivalent in entropy to a stronger secret for the purpose of <br>
dictionary attack.<br><br>
There is a &quot;precomputed&quot; type of dictionary attack in which
<br>
a dictionary is computed in advance and stored on, say, <br>
CD-ROM. The CD-ROM items are then used to attack a <br>
signature. Thus, if the attacker first created a CD-ROM of all <br>
amplified shared secrets based on likely precursor secrets, <br>
the attack from such a CD-ROM against a signature with <br>
an amplified secret would be no harder than an attack against <br>
a signature based on a precursor secret. This illustrates your <br>
point about conservation of entropy. However, to create such <br>
a CD-ROM would take a very, very long time and you'd need <br>
lots of CD-ROMs.<br><br>
Paul<br><br>
Clint Chapin wrote:<br>
My impression is that hashing doesn't add any more entropy than was
already present in the input.&nbsp; Yes, hashing adds time to the
calculation, but the output itself isn't any more entropic than the input
was.&nbsp; Am I incorrect?<br><br>
Clint (JOATMON) Chaplin<br>
&gt;&gt;&gt; Joshua Wright &lt;[email-masked]&gt; 08/04/04 13:54 PM
&gt;&gt;&gt;<br>
Paul Funk wrote:<br>
&nbsp;&gt; The idea is that you take an ordinary secret, hash it many
times,<br>
&nbsp;&gt; and get a resulting &quot;amplified&quot; shared secret that
multiplies the<br>
&nbsp;&gt; difficulty of attack by the number of times it has been
hashed. The<br>
&nbsp;&gt; draft suggests 0x100000 (~ one million) iterations, adding 2 ^
20<br>
&nbsp;&gt; bits of effective entropy to the secret.<br><br>
While I believe this algorithm is effective at adding entropy to a <br>
password such as the RADIUS secret, it does not resolve the issue of a
<br>
widespread shared secret distributed throughout an organization. Without
<br>
a mechanism in place to regularly change the secret, the use of shared
<br>
secrets in this fashion is reminiscent of WEP pre-shared keys. As most
<br>
people are painfully aware, shared secret do not stay 
secretive.<br><br>
That being said, I like Paul's idea for effectively adding entropy to
<br>
the shared secret that will prolong a brute-force attack.&nbsp; However,
I do <br>
not believe that this is effective at resolving weak authentication 
<br>
between the RADIUS authentication server and NAS.<br><br>
-Joshua Wright<br>
[email-masked] or<br>
[email-masked]<br><br>
-- <br>
-Joshua Wright<br>
[email-masked]<br>
<a href="http://home.jwu.edu/jwright/" eudora="autourl">http://home.jwu.edu/jwright/</a><br><br>
pgpkey:
<a href="http://home.jwu.edu/jwright/pgpkey.htm" eudora="autourl">http://home.jwu.edu/jwright/pgpkey.htm</a><br>
fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73<br><br>
<br><br>
<x-sigsep><p></x-sigsep>
Paul Funk<br>
Funk Software, Inc.<br>
617 497-6339<br>
[email-masked]<br>
</body>
</html>

--=====================_231727500==.ALT--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 05 Aug 2004 07:28:36 +0000
From: "Randy Chou" <[email-masked]>
To: <[email-masked]>, "Paul Funk" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Bernard Aboba" <[email-masked]>
Subject: Re: shared secret vulnerability 
Date: Thu, 5 Aug 2004 00:32:58 -0700

Comments inline before I go to sleep...[rc]...

Regards,

--
Randy

----- Original Message ----- 
From: Paul Funk
To: [email-masked] ; [email-masked]
Cc: [email-masked] ; [email-masked] ; Bernard Aboba
Sent: Thursday, August 05, 2004 12:04 AM
Subject: Re: shared secret vulnerability

Randy,

See inline. (My comments marked [pf] ).

Paul

--- from Randy Chou ---

Thanks Paul for your draft and discussing with me on Monday.  We can go into
further detail during Thursday's meeting, but here are some comments to
think about:

- The draft-funk-radiusext-shared-secret-amp-00.txt doc provides a practical
way for people to still remember short passwords while providing good
entropy.  It would be good IMO to categorize the environments this provides
adequate security and the environments that it doesn't.

[pf] I agree. I think intra-domain vs. inter-domain might be a way to slice
this.
Also, the ability to segregate administrative traffic from user traffic is
important.

[rc] I like that.  Especially now that there are Radius services on the
internet being provided for 802.1x.  Scary eh?

- As I pointed in a previous email, this still wouldn't protect cases where
the shared secret is somehow exposed.  Perhaps we can document this better
in the radius_vuln_00.txt draft as comments so far have been focusing on
short shared secrets which was only one aspect of what was documented.
Consumers have been educated for many years to understand that exposure to
the private key (assuming RSA) of a certificate is the only way to decrypt
packets through sniffing during TLS handshakes.  So certs are protected very
carefully and access to it is very limited. However, in a wifi environment
w/ 802.1x, exposure of a previous Radius shared secret can also allow an
attacker to decrypt wireless packets. So from an encryption point of view,
losing the current or any previously used Radius shared secret can be as
fatal as losing the server cert.  I don't think many consumers understand
that correlation and many would be shocked if they knew.  The more
security-conscious consumers use a combination of DH w/ RSA or ephemeral RSA
so even losing the server cert doesn't allow for data decryption.  The fact
that data decryption is still achievable only through the loss of the Radius
shared key makes Radius look very bad IMO.

[pf] I agree that people should understand the implications of their
security choices. But since they are entering shared secrets into
security servers, you'd think people would understand that it must
be important to the security of their operations.

[rc] Note that the shared secrets also go into generic NAS devices that
normally don't provide security features.

[pf] Yes, DH will provide perfect forward secrecy, though I'm not sure
how many people attempt to configure that vs. use whatever the default
cipher suite happens to be.

[pf] Whether you are protecting a private key or a shared secret, you need
to secure the equipment that uses it. I'm not sure that a shared secret
on a server is any less secure than a private key. Also, you have to
worry about your backup tapes!

[rc] Agreed, and this isn't just a Radius problem (SNMP, telnet,...etc).  I
think a shared secret versus cert difference is that the shared secret also
resides on many NAS devices which makes it much more difficult to protect.

- Would like to understand why you think IPSEC is so hard to use.  They're
available in most generic OSes where Radius servers are run and on many NAS
devices.  As to ease of deployment, I think this needs to be compared to
having to rotate RADIUS shared keys routinely on potentially hundreds of NAS
devices without duplicate usage, and making sure previous keys are never
exposed.

[pf] If it's not hard to use, why isn't it used more? Maintaining a PKI is
administratively challenging. Yes, OSes have built in support, but NASes
may run on platforms where IPsec is not readily available. I doubt also that
diligent shared secret rotation is all that common.

[rc]  IPSEC is deployed widely for end-users.  My theory as to why it's not
commonly used for Radius (there are some that do use it) is because of lack
of understanding (amongst consumers) of the seriousness of the problem and
because it's only a recommendation in the RFC as opposed to an absolute
requirement.  Hence the draft we wrote.

- Would like to hear security analysis of other uses of Radius besides
802.1x/wireless if anyone else has something to share.

Regards,

--
Randy

----- Original Message ----- 
From: "Paul Funk" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
"Bernard Aboba" <[email-masked]>
Sent: Monday, August 02, 2004 10:11 AM
Subject: shared secret vulnerability

> To further the discussion of shared secret vulnerability brought
> up in radius_vuln_00.txt, here is a proposal for using PKCS-5
> to create shared secrets with enhanced resistance to dictionary
> attack.
>
> The idea is that you take an ordinary secret, hash it many times,
> and get a resulting "amplified" shared secret that multiplies the
> difficulty of attack by the number of times it has been hashed. The
> draft suggests 0x100000 (~ one million) iterations, adding 2 ^ 20
> bits of effective entropy to the secret.
>
> The draft can be found at:
>
http://www.funk.com/documents/draft-funk-radiusext-shared-secret-amp-00.txt
>
> A demo of shared secret amplification can be found at:
> http://www.funk.com/passwordamplifier
>
> Here is the abstract:
>
>     This draft describes how a mechanism defined in [PKCS-5] can be used
>     to amplify the security of a RADIUS shared secret; namely, that a
>     precursor secret is hashed many times to produce an amplified shared
>     secret for use in RADIUS.
>
>     A dictionary attack against the resulting shared secret will be
>     infeasible due to its high entropy. A dictionary attack against the
>     precursor secret will require the attacker to apply the same hashing
>     process to each candidate precursor secret to derive a candidate
>     RADIUS shared secret, prior to applying it to the RADIUS packet.
>
>     This approach allows administrators to use the same types of secrets
>     that they are comfortable with as precursor secrets. The algorithm
>     to generate the amplified shared secret is deterministic, so the
>     precursor shared secret is all that needs to be remembered.
>
>     Unlike approaches that require changes to RADIUS servers and
>     clients, the amplification approach is compatible with all current
>     equipment. It is simply a means to generate a shared secret, which
>     then may be configured in the NAS or RADIUS server just as any
>     shared secret would be. For example, a simple utility can accept the
>     precursor secret, amplify it, and present it to the administrator,
>     who may copy and paste it into the configuration application of a
>     RADIUS server or NAS.
>
> Paul
>
>
> Paul Funk
> Funk Software, Inc.
> 617 497-6339
> [email-masked]
>
>

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 05 Aug 2004 07:21:14 +0000
Date: Thu, 05 Aug 2004 03:17:02 -0400
To: [email-masked],Joshua Wright <[email-masked]>
From: Paul Funk <[email-masked]>
Subject: Re: shared secret vulnerability 

Joshua,

Yes, widespread use of the same secret makes it less likely
to stay secret.

One of things the amplification draft discusses is use of a salt
to allow it to be easier to use different shared secrets on different
devices. The salt is set by the administrator and defines the
minimum entropy of all shared secrets derived from it. Each
technician can then make up different precursor secrets for
different devices; these can be much weaker, since the salt
entropy is added to the entropy of the precursor.

Note that the salt as used here is has a different purpose than
as defined in PKCS-5. It is not random data generated for each
use of a secret and displayed as clear text. It itself is kept
secret. In fact, it's best if the salt is a closely held secret of
the administrator, and baked into a utility that technicians can
use when they amplify the precursor secrets.

Paul

Joshua Wright wrote:
Paul Funk wrote:
 > The idea is that you take an ordinary secret, hash it many times,
 > and get a resulting "amplified" shared secret that multiplies the
 > difficulty of attack by the number of times it has been hashed. The
 > draft suggests 0x100000 (~ one million) iterations, adding 2 ^ 20
 > bits of effective entropy to the secret.

While I believe this algorithm is effective at adding entropy to a password 
such as the RADIUS secret, it does not resolve the issue of a widespread 
shared secret distributed throughout an organization. Without a mechanism 
in place to regularly change the secret, the use of shared secrets in this 
fashion is reminiscent of WEP pre-shared keys. As most people are painfully 
aware, shared secret do not stay secretive.

That being said, I like Paul's idea for effectively adding entropy to the 
shared secret that will prolong a brute-force attack. However, I do not 
believe that this is effective at resolving weak authentication between the 
RADIUS authentication server and NAS.

-Joshua Wright
[email-masked] or
[email-masked]

--
-Joshua Wright
[email-masked]
http://home.jwu.edu/jwright/

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 05 Aug 2004 07:05:23 +0000
Date: Thu, 05 Aug 2004 03:04:35 -0400
To: <[email-masked]>,<[email-masked]>
From: Paul Funk <[email-masked]>
Subject: Re: shared secret vulnerability 
Cc: <[email-masked]>,<[email-masked]>, "Bernard Aboba" <[email-masked]>

--=====================_229906781==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Randy,

See inline. (My comments marked [pf] ).

Paul

--- from Randy Chou ---

Thanks Paul for your draft and discussing with me on Monday.  We can go into
further detail during Thursday's meeting, but here are some comments to
think about:

- The draft-funk-radiusext-shared-secret-amp-00.txt doc provides a practical
way for people to still remember short passwords while providing good
entropy.  It would be good IMO to categorize the environments this provides
adequate security and the environments that it doesn't.

[pf] I agree. I think intra-domain vs. inter-domain might be a way to slice 
this.
Also, the ability to segregate administrative traffic from user traffic is
important.

- As I pointed in a previous email, this still wouldn't protect cases where
the shared secret is somehow exposed.  Perhaps we can document this better
in the radius_vuln_00.txt draft as comments so far have been focusing on
short shared secrets which was only one aspect of what was documented.
Consumers have been educated for many years to understand that exposure to
the private key (assuming RSA) of a certificate is the only way to decrypt
packets through sniffing during TLS handshakes.  So certs are protected very
carefully and access to it is very limited. However, in a wifi environment
w/ 802.1x, exposure of a previous Radius shared secret can also allow an
attacker to decrypt wireless packets. So from an encryption point of view,
losing the current or any previously used Radius shared secret can be as
fatal as losing the server cert.  I don't think many consumers understand
that correlation and many would be shocked if they knew.  The more
security-conscious consumers use a combination of DH w/ RSA or ephemeral RSA
so even losing the server cert doesn't allow for data decryption.  The fact
that data decryption is still achievable only through the loss of the Radius
shared key makes Radius look very bad IMO.

[pf] I agree that people should understand the implications of their
security choices. But since they are entering shared secrets into
security servers, you'd think people would understand that it must
be important to the security of their operations.

[pf] Yes, DH will provide perfect forward secrecy, though I'm not sure
how many people attempt to configure that vs. use whatever the default
cipher suite happens to be.

[pf] Whether you are protecting a private key or a shared secret, you need
to secure the equipment that uses it. I'm not sure that a shared secret
on a server is any less secure than a private key. Also, you have to
worry about your backup tapes!

- Would like to understand why you think IPSEC is so hard to use.  They're
available in most generic OSes where Radius servers are run and on many NAS
devices.  As to ease of deployment, I think this needs to be compared to
having to rotate RADIUS shared keys routinely on potentially hundreds of NAS
devices without duplicate usage, and making sure previous keys are never
exposed.

[pf] If it's not hard to use, why isn't it used more? Maintaining a PKI is
administratively challenging. Yes, OSes have built in support, but NASes
may run on platforms where IPsec is not readily available. I doubt also that
diligent shared secret rotation is all that common.

- Would like to hear security analysis of other uses of Radius besides
802.1x/wireless if anyone else has something to share.

Regards,

--
Randy

----- Original Message -----
From: "Paul Funk" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
"Bernard Aboba" <[email-masked]>
Sent: Monday, August 02, 2004 10:11 AM
Subject: shared secret vulnerability

 > To further the discussion of shared secret vulnerability brought
 > up in radius_vuln_00.txt, here is a proposal for using PKCS-5
 > to create shared secrets with enhanced resistance to dictionary
 > attack.
 >
 > The idea is that you take an ordinary secret, hash it many times,
 > and get a resulting "amplified" shared secret that multiplies the
 > difficulty of attack by the number of times it has been hashed. The
 > draft suggests 0x100000 (~ one million) iterations, adding 2 ^ 20
 > bits of effective entropy to the secret.
 >
 > The draft can be found at:
 >
http://www.funk.com/documents/draft-funk-radiusext-shared-secret-amp-00.txt
 >
 > A demo of shared secret amplification can be found at:
 > http://www.funk.com/passwordamplifier
 >
 > Here is the abstract:
 >
 >     This draft describes how a mechanism defined in [PKCS-5] can be used
 >     to amplify the security of a RADIUS shared secret; namely, that a
 >     precursor secret is hashed many times to produce an amplified shared
 >     secret for use in RADIUS.
 >
 >     A dictionary attack against the resulting shared secret will be
 >     infeasible due to its high entropy. A dictionary attack against the
 >     precursor secret will require the attacker to apply the same hashing
 >     process to each candidate precursor secret to derive a candidate
 >     RADIUS shared secret, prior to applying it to the RADIUS packet.
 >
 >     This approach allows administrators to use the same types of secrets
 >     that they are comfortable with as precursor secrets. The algorithm
 >     to generate the amplified shared secret is deterministic, so the
 >     precursor shared secret is all that needs to be remembered.
 >
 >     Unlike approaches that require changes to RADIUS servers and
 >     clients, the amplification approach is compatible with all current
 >     equipment. It is simply a means to generate a shared secret, which
 >     then may be configured in the NAS or RADIUS server just as any
 >     shared secret would be. For example, a simple utility can accept the
 >     precursor secret, amplify it, and present it to the administrator,
 >     who may copy and paste it into the configuration application of a
 >     RADIUS server or NAS.
 >
 > Paul
 >
 >
 > Paul Funk
 > Funk Software, Inc.
 > 617 497-6339
 > [email-masked]
 >
 >

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

--=====================_229906781==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
Randy,<br><br>
See inline. (My comments marked [pf] ).<br><br>
Paul<br><br>
--- from Randy Chou ---<br><br>
Thanks Paul for your draft and discussing with me on Monday.&nbsp; We can
go into<br>
further detail during Thursday's meeting, but here are some comments
to<br>
think about:<br><br>
- The draft-funk-radiusext-shared-secret-amp-00.txt doc provides a
practical<br>
way for people to still remember short passwords while providing
good<br>
entropy.&nbsp; It would be good IMO to categorize the environments this
provides<br>
adequate security and the environments that it doesn't.<br><br>
[pf] I agree. I think intra-domain vs. inter-domain might be a way to
slice this. <br>
Also, the ability to segregate administrative traffic from user traffic
is <br>
important.<br><br>
- As I pointed in a previous email, this still wouldn't protect cases
where<br>
the shared secret is somehow exposed.&nbsp; Perhaps we can document this
better<br>
in the radius_vuln_00.txt draft as comments so far have been focusing
on<br>
short shared secrets which was only one aspect of what was
documented.<br>
Consumers have been educated for many years to understand that exposure
to<br>
the private key (assuming RSA) of a certificate is the only way to
decrypt<br>
packets through sniffing during TLS handshakes.&nbsp; So certs are
protected very<br>
carefully and access to it is very limited. However, in a wifi
environment<br>
w/ 802.1x, exposure of a previous Radius shared secret can also allow
an<br>
attacker to decrypt wireless packets. So from an encryption point of
view,<br>
losing the current or any previously used Radius shared secret can be
as<br>
fatal as losing the server cert.&nbsp; I don't think many consumers
understand<br>
that correlation and many would be shocked if they knew.&nbsp; The
more<br>
security-conscious consumers use a combination of DH w/ RSA or ephemeral
RSA<br>
so even losing the server cert doesn't allow for data decryption.&nbsp;
The fact<br>
that data decryption is still achievable only through the loss of the
Radius<br>
shared key makes Radius look very bad IMO.<br><br>
[pf] I agree that people should understand the implications of their
<br>
security choices. But since they are entering shared secrets into <br>
security servers, you'd think people would understand that it must <br>
be important to the security of their operations.<br><br>
[pf] Yes, DH will provide perfect forward secrecy, though I'm not sure
<br>
how many people attempt to configure that vs. use whatever the default
<br>
cipher suite happens to be. <br><br>
[pf] Whether you are protecting a private key or a shared secret, you
need <br>
to secure the equipment that uses it. I'm not sure that a shared secret
<br>
on a server is any less secure than a private key. Also, you have to
<br>
worry about your backup tapes!<br><br>
- Would like to understand why you think IPSEC is so hard to use.&nbsp;
They're<br>
available in most generic OSes where Radius servers are run and on many
NAS<br>
devices.&nbsp; As to ease of deployment, I think this needs to be
compared to<br>
having to rotate RADIUS shared keys routinely on potentially hundreds of
NAS<br>
devices without duplicate usage, and making sure previous keys are
never<br>
exposed.<br><br>
[pf] If it's not hard to use, why isn't it used more? Maintaining a PKI
is <br>
administratively challenging. Yes, OSes have built in support, but NASes
<br>
may run on platforms where IPsec is not readily available. I doubt also
that <br>
diligent shared secret rotation is all that common. <br><br>
- Would like to hear security analysis of other uses of Radius
besides<br>
802.1x/wireless if anyone else has something to share.<br><br>
Regards,<br><br>
--<br>
Randy<br><br>
<br>
----- Original Message ----- <br>
From: &quot;Paul Funk&quot; &lt;[email-masked]&gt;<br>
To: &lt;[email-masked]&gt;<br>
Cc: &lt;[email-masked]&gt;; &lt;[email-masked]&gt;;
&lt;[email-masked]&gt;;<br>
&quot;Bernard Aboba&quot; &lt;[email-masked]&gt;<br>
Sent: Monday, August 02, 2004 10:11 AM<br>
Subject: shared secret vulnerability<br><br>
<br>
&gt; To further the discussion of shared secret vulnerability
brought<br>
&gt; up in radius_vuln_00.txt, here is a proposal for using PKCS-5<br>
&gt; to create shared secrets with enhanced resistance to 
dictionary<br>
&gt; attack.<br>
&gt;<br>
&gt; The idea is that you take an ordinary secret, hash it many
times,<br>
&gt; and get a resulting &quot;amplified&quot; shared secret that
multiplies the<br>
&gt; difficulty of attack by the number of times it has been hashed.
The<br>
&gt; draft suggests 0x100000 (~ one million) iterations, adding 2 ^
20<br>
&gt; bits of effective entropy to the secret.<br>
&gt;<br>
&gt; The draft can be found at:<br>
&gt;<br>
<a href="http://www.funk.com/documents/draft-funk-radiusext-shared-secret-amp-00.txt" eudora="autourl">http://www.funk.com/documents/draft-funk-radiusext-shared-secret-amp-00.txt</a><br>
&gt;<br>
&gt; A demo of shared secret amplification can be found at:<br>
&gt;
<a href="http://www.funk.com/passwordamplifier" eudora="autourl">http://www.funk.com/passwordamplifier</a><br>
&gt;<br>
&gt; Here is the abstract:<br>
&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; This draft describes how a mechanism defined
in [PKCS-5] can be used<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; to amplify the security of a RADIUS shared
secret; namely, that a<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; precursor secret is hashed many times to
produce an amplified shared<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; secret for use in RADIUS.<br>
&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; A dictionary attack against the resulting
shared secret will be<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; infeasible due to its high entropy. A
dictionary attack against the<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; precursor secret will require the attacker
to apply the same hashing<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; process to each candidate precursor secret
to derive a candidate<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; RADIUS shared secret, prior to applying it
to the RADIUS packet.<br>
&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; This approach allows administrators to use
the same types of secrets<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; that they are comfortable with as precursor
secrets. The algorithm<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; to generate the amplified shared secret is
deterministic, so the<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; precursor shared secret is all that needs to
be remembered.<br>
&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; Unlike approaches that require changes to
RADIUS servers and<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; clients, the amplification approach is
compatible with all current<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; equipment. It is simply a means to generate
a shared secret, which<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; then may be configured in the NAS or RADIUS
server just as any<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; shared secret would be. For example, a
simple utility can accept the<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; precursor secret, amplify it, and present it
to the administrator,<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; who may copy and paste it into the
configuration application of a<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; RADIUS server or NAS.<br>
&gt;<br>
&gt; Paul<br>
&gt;<br>
&gt;<br>
&gt; Paul Funk<br>
&gt; Funk Software, Inc.<br>
&gt; 617 497-6339<br>
&gt; [email-masked]<br>
&gt;<br>
&gt;<br><br>
<br>
<x-sigsep><p></x-sigsep>
Paul Funk<br>
Funk Software, Inc.<br>
617 497-6339<br>
[email-masked]<br>
</body>
</html>

--=====================_229906781==.ALT--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 04 Aug 2004 23:28:26 +0000
Date: Wed, 04 Aug 2004 19:28:01 -0400
To: [email-masked]
From: David Mitton <[email-masked]>
Subject: Re: shared secret vulnerability

At 8/4/2004 04:50 PM, Joshua Wright wrote:
>While I believe this algorithm is effective at adding entropy to a 
>password such as the RADIUS secret, it does not resolve the issue of a 
>widespread shared secret distributed throughout an organization. Without a 
>mechanism in place to regularly change the secret, the use of shared 
>secrets in this fashion is reminiscent of WEP pre-shared keys. As most 
>people are painfully aware, shared secret do not stay secretive.

While I agree with the sentiment, I'd like to attempt to point out another 
possible implementation issue.

Unlike WEP, there is nothing in RADIUS that requires the shared secrets to 
be the same for all partners.  In many (most?) implementations, the secret 
can be unique for each source IP address.  Essentially any pair of RADIUS 
client/servers can have unique secrets.

Dave. 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 04 Aug 2004 22:36:16 +0000
content-class: urn:content-classes:message
Subject: RE: shared secret vulnerability
Date: Wed, 4 Aug 2004 15:35:05 -0700
From: "Randy Chou" <[email-masked]>
To: "Clint Chaplin" <[email-masked]>, <[email-masked]>, <[email-masked]>

Yes, you're right.  I also missed that the first time I read Paul's
draft.  Entropy would only be increased if the possible number of
outputs increased.  Since the salt is fixed (and known anyways based on
PKCS#5), the number of possible outputs only depends on the precursor
secret itself.  The representation of the output increased so that would
make it harder to brute force.  But that's not to say that someone would
not be able to find a faster way to reach the result besides the brute
force method.  It just seems very very difficult.

So Paul, the following comment may need to be revised depending on
interpretation:

> Differently stated, 20=20
   bits of effective entropy are added to a secret when hashed one=20
   million times; thus, a secret with 40 bits of entropy provides 60=20
   bits of effective entropy after amplification

Regards,

--
Randy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Clint Chaplin
Sent: Wednesday, August 04, 2004 2:00 PM
To: [email-masked]; [email-masked]
Subject: Re: shared secret vulnerability

My impression is that hashing doesn't add any more entropy than was
already present in the input.  Yes, hashing adds time to the
calculation, but the output itself isn't any more entropic than the
input was.  Am I incorrect?

Clint (JOATMON) Chaplin
>>> Joshua Wright <[email-masked]> 08/04/04 13:54 PM >>>
Paul Funk wrote:
 > The idea is that you take an ordinary secret, hash it many times,  >
and get a resulting "amplified" shared secret that multiplies the  >
difficulty of attack by the number of times it has been hashed. The  >
draft suggests 0x100000 (~ one million) iterations, adding 2 ^ 20  >
bits of effective entropy to the secret.

While I believe this algorithm is effective at adding entropy to a=20
password such as the RADIUS secret, it does not resolve the issue of a=20
widespread shared secret distributed throughout an organization. Without

a mechanism in place to regularly change the secret, the use of shared=20
secrets in this fashion is reminiscent of WEP pre-shared keys. As most=20
people are painfully aware, shared secret do not stay secretive.

That being said, I like Paul's idea for effectively adding entropy to=20
the shared secret that will prolong a brute-force attack.  However, I do

not believe that this is effective at resolving weak authentication=20
between the RADIUS authentication server and NAS.

-Joshua Wright
[email-masked] or
[email-masked]

--=20
-Joshua Wright
[email-masked]
http://home.jwu.edu/jwright/

pgpkey: http://home.jwu.edu/jwright/pgpkey.htm
fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

________________________________________________________________________
This email has been scanned for computer viruses.

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 04 Aug 2004 21:00:30 +0000
Date: Wed, 04 Aug 2004 13:59:35 -0700
From: "Clint Chaplin" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: shared secret vulnerability

My impression is that hashing doesn't add any more entropy than was =
already present in the input.  Yes, hashing adds time to the calculation, =
but the output itself isn't any more entropic than the input was.  Am I =
incorrect?

Clint (JOATMON) Chaplin
>>> Joshua Wright <[email-masked]> 08/04/04 13:54 PM >>>
Paul Funk wrote:
 > The idea is that you take an ordinary secret, hash it many times,
 > and get a resulting "amplified" shared secret that multiplies the
 > difficulty of attack by the number of times it has been hashed. The
 > draft suggests 0x100000 (~ one million) iterations, adding 2 ^ 20
 > bits of effective entropy to the secret.

While I believe this algorithm is effective at adding entropy to a=20
password such as the RADIUS secret, it does not resolve the issue of a=20
widespread shared secret distributed throughout an organization. Without=20=

a mechanism in place to regularly change the secret, the use of shared=20
secrets in this fashion is reminiscent of WEP pre-shared keys. As most=20
people are painfully aware, shared secret do not stay secretive.

That being said, I like Paul's idea for effectively adding entropy to=20
the shared secret that will prolong a brute-force attack.  However, I =
do=20
not believe that this is effective at resolving weak authentication=20
between the RADIUS authentication server and NAS.

-Joshua Wright
[email-masked] or
[email-masked]

--=20
-Joshua Wright
[email-masked]
http://home.jwu.edu/jwright/

pgpkey: http://home.jwu.edu/jwright/pgpkey.htm
fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

________________________________________________________________________
This email has been scanned for computer viruses.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 04 Aug 2004 20:51:43 +0000
Date: Wed, 04 Aug 2004 16:50:34 -0400
From: Joshua Wright <[email-masked]>
To: [email-masked]
Subject: Re: shared secret vulnerability

Paul Funk wrote:
 > The idea is that you take an ordinary secret, hash it many times,
 > and get a resulting "amplified" shared secret that multiplies the
 > difficulty of attack by the number of times it has been hashed. The
 > draft suggests 0x100000 (~ one million) iterations, adding 2 ^ 20
 > bits of effective entropy to the secret.

While I believe this algorithm is effective at adding entropy to a 
password such as the RADIUS secret, it does not resolve the issue of a 
widespread shared secret distributed throughout an organization. Without 
a mechanism in place to regularly change the secret, the use of shared 
secrets in this fashion is reminiscent of WEP pre-shared keys. As most 
people are painfully aware, shared secret do not stay secretive.

That being said, I like Paul's idea for effectively adding entropy to 
the shared secret that will prolong a brute-force attack.  However, I do 
not believe that this is effective at resolving weak authentication 
between the RADIUS authentication server and NAS.

-Joshua Wright
[email-masked] or
[email-masked]

-- 
-Joshua Wright
[email-masked]
http://home.jwu.edu/jwright/

pgpkey: http://home.jwu.edu/jwright/pgpkey.htm
fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 04 Aug 2004 07:09:47 +0000
From: "Randy Chou" <[email-masked]>
To: <[email-masked]>, "Paul Funk" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Bernard Aboba" <[email-masked]>, "Randy Chou" <[email-masked]>
Subject: Re: shared secret vulnerability
Date: Wed, 4 Aug 2004 00:13:25 -0700

Thanks Paul for your draft and discussing with me on Monday.  We can go into
further detail during Thursday's meeting, but here are some comments to
think about:

- The draft-funk-radiusext-shared-secret-amp-00.txt doc provides a practical
way for people to still remember short passwords while providing good
entropy.  It would be good IMO to categorize the environments this provides
adequate security and the environments that it doesn't.

- As I pointed in a previous email, this still wouldn't protect cases where
the shared secret is somehow exposed.  Perhaps we can document this better
in the radius_vuln_00.txt draft as comments so far have been focusing on
short shared secrets which was only one aspect of what was documented.
Consumers have been educated for many years to understand that exposure to
the private key (assuming RSA) of a certificate is the only way to decrypt
packets through sniffing during TLS handshakes.  So certs are protected very
carefully and access to it is very limited. However, in a wifi environment
w/ 802.1x, exposure of a previous Radius shared secret can also allow an
attacker to decrypt wireless packets. So from an encryption point of view,
losing the current or any previously used Radius shared secret can be as
fatal as losing the server cert.  I don't think many consumers understand
that correlation and many would be shocked if they knew.  The more
security-conscious consumers use a combination of DH w/ RSA or ephemeral RSA
so even losing the server cert doesn't allow for data decryption.  The fact
that data decryption is still achievable only through the loss of the Radius
shared key makes Radius look very bad IMO.

- Would like to understand why you think IPSEC is so hard to use.  They're
available in most generic OSes where Radius servers are run and on many NAS
devices.  As to ease of deployment, I think this needs to be compared to
having to rotate RADIUS shared keys routinely on potentially hundreds of NAS
devices without duplicate usage, and making sure previous keys are never
exposed.

- Would like to hear security analysis of other uses of Radius besides
802.1x/wireless if anyone else has something to share.

Regards,

--
Randy

----- Original Message ----- 
From: "Paul Funk" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
"Bernard Aboba" <[email-masked]>
Sent: Monday, August 02, 2004 10:11 AM
Subject: shared secret vulnerability

> To further the discussion of shared secret vulnerability brought
> up in radius_vuln_00.txt, here is a proposal for using PKCS-5
> to create shared secrets with enhanced resistance to dictionary
> attack.
>
> The idea is that you take an ordinary secret, hash it many times,
> and get a resulting "amplified" shared secret that multiplies the
> difficulty of attack by the number of times it has been hashed. The
> draft suggests 0x100000 (~ one million) iterations, adding 2 ^ 20
> bits of effective entropy to the secret.
>
> The draft can be found at:
>
http://www.funk.com/documents/draft-funk-radiusext-shared-secret-amp-00.txt
>
> A demo of shared secret amplification can be found at:
> http://www.funk.com/passwordamplifier
>
> Here is the abstract:
>
>     This draft describes how a mechanism defined in [PKCS-5] can be used
>     to amplify the security of a RADIUS shared secret; namely, that a
>     precursor secret is hashed many times to produce an amplified shared
>     secret for use in RADIUS.
>
>     A dictionary attack against the resulting shared secret will be
>     infeasible due to its high entropy. A dictionary attack against the
>     precursor secret will require the attacker to apply the same hashing
>     process to each candidate precursor secret to derive a candidate
>     RADIUS shared secret, prior to applying it to the RADIUS packet.
>
>     This approach allows administrators to use the same types of secrets
>     that they are comfortable with as precursor secrets. The algorithm
>     to generate the amplified shared secret is deterministic, so the
>     precursor shared secret is all that needs to be remembered.
>
>     Unlike approaches that require changes to RADIUS servers and
>     clients, the amplification approach is compatible with all current
>     equipment. It is simply a means to generate a shared secret, which
>     then may be configured in the NAS or RADIUS server just as any
>     shared secret would be. For example, a simple utility can accept the
>     precursor secret, amplify it, and present it to the administrator,
>     who may copy and paste it into the configuration application of a
>     RADIUS server or NAS.
>
> Paul
>
>
> Paul Funk
> Funk Software, Inc.
> 617 497-6339
> [email-masked]
>
>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 02 Aug 2004 17:14:48 +0000
Date: Mon, 02 Aug 2004 13:11:10 -0400
To: [email-masked]
From: Paul Funk <[email-masked]>
Subject: shared secret vulnerability
Cc: [email-masked],[email-masked],[email-masked], Bernard Aboba <[email-masked]>

To further the discussion of shared secret vulnerability brought
up in radius_vuln_00.txt, here is a proposal for using PKCS-5
to create shared secrets with enhanced resistance to dictionary
attack.

The idea is that you take an ordinary secret, hash it many times,
and get a resulting "amplified" shared secret that multiplies the
difficulty of attack by the number of times it has been hashed. The
draft suggests 0x100000 (~ one million) iterations, adding 2 ^ 20
bits of effective entropy to the secret.

The draft can be found at:
http://www.funk.com/documents/draft-funk-radiusext-shared-secret-amp-00.txt

A demo of shared secret amplification can be found at:
http://www.funk.com/passwordamplifier

Here is the abstract:

    This draft describes how a mechanism defined in [PKCS-5] can be used
    to amplify the security of a RADIUS shared secret; namely, that a
    precursor secret is hashed many times to produce an amplified shared
    secret for use in RADIUS.

    A dictionary attack against the resulting shared secret will be
    infeasible due to its high entropy. A dictionary attack against the
    precursor secret will require the attacker to apply the same hashing
    process to each candidate precursor secret to derive a candidate
    RADIUS shared secret, prior to applying it to the RADIUS packet.

    This approach allows administrators to use the same types of secrets
    that they are comfortable with as precursor secrets. The algorithm
    to generate the amplified shared secret is deterministic, so the
    precursor shared secret is all that needs to be remembered.

    Unlike approaches that require changes to RADIUS servers and
    clients, the amplification approach is compatible with all current
    equipment. It is simply a means to generate a shared secret, which
    then may be configured in the NAS or RADIUS server just as any
    shared secret would be. For example, a simple utility can accept the
    precursor secret, amplify it, and present it to the administrator,
    who may copy and paste it into the configuration application of a
    RADIUS server or NAS.

Paul

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 02 Aug 2004 15:58:47 +0000
Date: Mon, 2 Aug 2004 08:54:06 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: REMINDER:  Slides needed!

If you are presenting at the RADEXT WG meeting today, please send your
slides to myself and David NOW.  The meeting is tightly scheduled and so
we will have all the slides preloaded on the laptop, ready to go.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>