Subject: -01 version of Chargeable User Identity
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Mon, 27 Sep 2004 15:30:18 -0700

Hi all,
The version -01 should appear on ID repository soon.  In the mean time,
you can access the draft here :
http://mng.ctgisp.com/IETF/RADIUSEXT/draft-adrangi-radius-chargeable-use
r-id-01.txt.

The -01 update addresses the two issues (issue 13 and 14) submitted
against the draft by David and Bernard respectively - please see
http://www.drizzle.com/~aboba/RADEXT/#Issue%2014 for the detailed
descriptions of the issues.

Bernard,

Regarding two of your comments,

- Made a clarification on encoded format for CUI string.  But, we
weren't sure if you were also questioning the proposed
XX:YYYYYYYYYY format rather than just NAI or other encoding supported by
Username.   

- Diameter translation /CoA message comment, are you suggesting to
prohibit the user of the attribute in COA/Disconnect message?  Please
note that the CUI is for identifying the user session than username.  

BR,
Farid

--
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, 26 Sep 2004 17:37:47 +0000
Date: Sun, 26 Sep 2004 10:27:53 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: IETF 61 submission deadlines (fwd)

Date: Fri, 24 Sep 2004 10:04:11 -0400
From: ietf-secretariat at ietf.org
To: ietf-announce at ietf.org
Subject: Internet-Draft Submission Cutoff Dates for the 61st IETF Meeting
    in Washington, DC, USA

There are two (2) Internet-Draft cutoff dates for the 61st IETF Meeting
in Washington, DC, USA:

October 18: Cutoff Date for Initial (i.e., -00) Internet-Draft Submissions

All initial Internet-Drafts (-00) must be submitted by Monday, October 18
at 9:00 AM ET. As always, all initial submissions (-00) with a filename
beginning with "draft-ietf" must be approved by the appropriate WG Chair
before they can be processed or announced. WG Chair approval must be
received by Monday,October 11 at 9:00 AM ET.

October 25: Cutoff Date for Revised (i.e., -01 and higher) Internet-Draft
Submissions

All revised Internet-Drafts (-01 and higher) must be submitted by Monday,
October 25 at 9:00 AM ET.

Initial and revised Internet-Drafts received after their respective cutoff
dates will not be made available in the Internet-Drafts directory or
announced, and will have to be resubmitted. Please do not wait until the
last minute to submit. The Secretariat will begin accepting Internet-Draft
submissions starting Monday, November 08 at 9:00 AM ET, but may not post
or announce them until Monday, November 15.

Thank you for your understanding and cooperation. If you have any
questions or concerns, then please send a message to internet-drafts at
ietf.org.

The IETF Secretariat

FYI: The Internet-Draft cutoff dates as well as other significant dates
for the 61st IETF Meeting can be found at:
http://www.ietf.org/meetings/cutoff_dates_61.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, 23 Sep 2004 23:06:31 +0000
To: "[email-masked]'" <[email-masked]>, [email-masked]
Cc: David Mariblanca (EE/EEM) <[email-masked]>
Subject: Re: alternatives for carrying eap lower layer information
Date: Thu, 23 Sep 2004 15:57:14 -0700
From: Bernard Aboba <[email-masked]>

There are multiple problems being discussed here: 

a. Ability to differentiate tunneled EAP methods (PEAP, EAP-IKEv2, etc.) from non-tunneled EAP methods. 

b. Ability to differentiate EAP lower layers from one another (EAP-IKEv2).

In terms of problem a), the EAP peer and server know what EAP method is being negotiated (and whether it is tunneled), but the NAS is presumed to be a pass-through.  Therefore, I am not clear how the NAS would obtain information on the EAP method to put into an attribute, unless it gets this from the RADIUS server.  

In terms of problem b), it seems that the problem arises in part from the allocation of a single NAS-Port-Type (Virtual) to all tunnels.  In contrast, in RFC 2868 the combination of Tunnel-Type and Tunnel-Medium-Type attributes enables description of virtually any tunnel type over any medium.  I'd suggest that this approach is more sound than trying to allocate a NAS-Port-Type value for every conceivable combination. 

--
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, 23 Sep 2004 19:33:41 +0000
Date: Thu, 23 Sep 2004 22:31:55 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "[email-masked]'" <[email-masked]>
Cc: "David Mariblanca (EE/EEM)" <[email-masked]>
Subject: alternatives for carrying eap lower layer information

Hello folks,

In San Diego we discussed draft-mariblanca-aaa-eap-lla-01.txt. This
draft is used in conjunction with EAP authentication, and provides a
new attribute that tells the AAA server the name of the protocol that
carried the EAP protocol. For instance, 802.1X, IKEv2, or PEAP.

While I sensed that people in the room saw the need for carrying
this information (useful for policy and in some cases also security
purposes), there was a big discussion on whether existing
attributes are sufficient, whether just a new value would
be needed in an existing attribute, or whether a completely
new attribute is needed.

This e-mail attempts to summarize the possible alternatives
and their pros and cons. Comments on this are appreciated.
Did we miss any alternative? Which alternative do people
prefer?

Best Regards,

Jari and David

----

Introduction
------------

The alternatives are:

- Existing values in the NAS-Port-Type attribute

- New values in the NAS-Port-Type attribute

- New values in the Service-Type attribute

- New attribute specifically for expressing the lower
   layer for EAP

The aspects that we would like to consider are:

- Ability to differentiate between carrying EAP over, say, 802.1X or
   IKEv2 without requiring knowledge of what NAS-Identifiers are what
   type of devices.

- Ability to differentiate between carryig an EAP method on its own or
   embedded within another EAP exchange, such as in PEAP.

- Code (or dictionary) impact. For instance, it may be that a new
   value in an existing attribute is easier to support than a new
   attribute. Note that a code change is always required on the NAS
   side, to make the NAS send the new information. However, it may not
   be needed on the server side.

- Administrative ease of update, e.g., IETF Consensus for new
   attributes or new Service-Type values. Designated Expert for new
   values in other attributes.

- Extensibility. How well does the approach support potential
   new uses of EAP?

- Conservative allocation of new code points, such as enumerated
   values, assuming EAP usage becomes more popular in the future.

- Support of both RADIUS and Diameter.

Next we will look in more detail at each of the alternatives
and their properties:

1. Existing values in the NAS-Port-Type attribute
-------------------------------------------------

This value could be used to distinguish IKEv2 and 802.1X as follows:

   NAS-Port-Type = (5) Virtual => IKEv2
   NAS-Port-Type = (19) Wireless - IEEE 802.11 => 802.1X

It does not seem possible to differentiate between plain and tunneled
EAP methods. Similarly, it does not seem possible to differentiate
between IKEv2 and some other protocol that establishes a virtual
tunnel and uses EAP. Extensibility is limited to certain types
of EAP usage.

2. New values in the NAS-Port-Type attribute
--------------------------------------------

A variation of the above alternative: new NAS-Port-Type values could
be defined to make it clearer what virtual protocol is used:
Virtual-IKEv2, Virtual-Somethingelse, etc. New link layer types
or PANA could also be supported. For instance,

   NAS-Port-Type = (19) Wireless - IEEE 802.11 => 802.1X
   NAS-Port-Type = (TBD) Virtual-IKEv2 => IKEv2
   NAS-Port-Type = (TBD) PANA => PANA

The new values can be allocated through Designated Expert. No new RFC
is required. Code/dictionary impact is minimal.

However, this would still not be able to differentiate plain and
tunneled EAP methods. Extensibility is better than in the previous
approach, but still limited to port types where exactly one EAP
encapsulation is used.

Finally, we're not quite sure if the port type are intended for an
extensive listing of what kind of virtual operation is going on; RFC
2865 says "This Attribute indicates the type of the physical port of
the NAS which is authenticating the user."

3. New values in Service-Type attribute
---------------------------------------

A new value could be used to distinguish between "Framed" (most
current network access methods) and, say, "IKEv2".  However, if 802.11
uses the "Framed" value, it seems odd to introduce a different value
for "PANA", so differentation between PANA and 802.1X seems hard.
Similarly, differentiating between plain and tunneled EAP methods is
not possible. Finally, the proliferation of new Service-Type values
does not seem desirable, so future protocols that use EAP (other than
IKEv2) might not fit into this model.

IETF Consensus and a new RFC would be required for this.

Code impact is likely bigger than in the other alternatives, because
of the role of the Service-Type. It is likely that a dictionary
extension is insufficient.

4. New attribute EAP-lower-layer
--------------------------------

In this alternative, a new attribute would indicate the protocol used
for carrying EAP. This would be orthogonal to the service or port type
attributes, although only some combinations would make sense.

It would be possible to differentiate between different network access
protocols employing EAP (PPP/802.1X/PANA), between different virtual
protocols (IKEv2/whatever), and also between tunneled and non-tunneled
EAP usage.

IETF Consensus and a new RFC would be required for this.

Code/dictionary impact would be small, although bigger than in
allocating just a new value in NAS-Port-Type.

A code change would be needed in all NASes, however, and not just the
virtual ones supporting IKEv2. Alternatively, the omission of the new
attribute would be taken to mean something. For instance, lack of the
lower layer attribute could be taken to mean "unknown" or something
based on the current port type or framed protocol attributes.

--
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, 21 Sep 2004 21:00:39 +0000
Date: Tue, 21 Sep 2004 11:04:32 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Ignacio Goyret <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: NAIbis spec revision 03

Ignacio Goyret wrote:
> Jari,
> A detail:
> 
>      c =/ %x60-7a      ; 'a'-'z'  allowed
>           ^^^^           ^^^
> 
> 0x60 = '`' (on a US keyboard, it is the key to the left of the '1'
> 0x61 = 'a'

Yes. THanks for catching this. It has now been corrected.

> This also looks odd:
>      c =/ %x26         ; '&et;'   allowed
>                            ^^^
> In USASCII, 0x26 = '&' or '&amp;' in html. Right?

Oops. XML bug in my source :-)

That too is now corrected.

--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: Tue, 21 Sep 2004 19:47:47 +0000
Date: Tue, 21 Sep 2004 12:38:40 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Back online

Just a message to say that my mail server is back online now.  My ADSL
link went down and so I had to move the server to another link (it's now
on a cable Internet link).  If you had sent any mail to me in the last two
weeks and didn't get a response, please resend.

--
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, 20 Sep 2004 21:50:53 +0000
Date: Mon, 20 Sep 2004 14:48:48 -0700
To: [email-masked]
From: Ignacio Goyret <[email-masked]>
Subject: Re: NAIbis spec revision 03
Cc: "[email-masked]'" <[email-masked]>

Jari,
A detail:

     c =/ %x60-7a      ; 'a'-'z'  allowed
          ^^^^           ^^^

0x60 = '`' (on a US keyboard, it is the key to the left of the '1'
0x61 = 'a'
...

This also looks odd:
     c =/ %x26         ; '&et;'   allowed
                           ^^^
In USASCII, 0x26 = '&' or '&amp;' in html. Right?

At 08:35 9/20/2004 +0300, Jari Arkko wrote:
>
>Hi,
>
>Working group last call completed on this document some
>time ago. I have now put a modified draft revision and diffs
>at
>
>   http://www.arkko.com/publications/nai/naibis.txt
>   http://www.arkko.com/publications/nai/naibisdiff.html
>
>The modifications include a few editorial improvements
>on the ABNF that Pasi suggested, a couple of other
>editorial things, and the removal of a claim that
>the bis version '!' puts stricter requirements on the
>parts preceding the '!' sign than in RFC 2486.
>
>I think the conclusion from the IKEv2 discussion is
>that there's a couple of promising alternatives for
>transporting i18n or privacy enhanced NAIs over IKEv2.
>But it seems that we should not do them in the NAIbis
>spec. (But I volunteer to draft a spec for that in
>some other context.)
>
>If I missed anything, scream now. I will submit this
>to the I-D directories in a couple of days.
>
>--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/>
> 

--
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, 20 Sep 2004 21:32:39 +0000
To: [email-masked]
Subject: Request: User of [Issue] in Subject Line
Date: Mon, 20 Sep 2004 14:23:46 -0700
From: Bernard Aboba <[email-masked]>

We currently have completed RADEXT WG last call on two documents, SIP Digest Authentication and RFC 2486bis.  In order to track the status of comments, we would appreciate it if reviewers would utilize the Issue format specified on the RADEXT WG Issues list: 

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

This includes using [Issue #] in the subject of the message, to identify the Issue that is being responded to.  If you are submitting a new Issue, please use [Issue ] so that we can easily identify a new issue. 

Thanks in Advance, 

The Chairs

--
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, 20 Sep 2004 21:17:38 +0000
To: [email-masked]
Subject: Issue 14: Review of Chargeable User Identity
Date: Mon, 20 Sep 2004 14:08:17 -0700
From: Bernard Aboba <[email-masked]>

For details, see: 
http://www.drizzle.com/~aboba/RADEXT/#Issue%2014

--
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, 20 Sep 2004 21:17:22 +0000
To: [email-masked]
Subject: Issue 14: Review of Chargeable User Identity
Date: Mon, 20 Sep 2004 14:08:25 -0700
From: Bernard Aboba <[email-masked]>

For details, see: 
http://www.drizzle.com/~aboba/RADEXT/#Issue%2014

--
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, 20 Sep 2004 13:27:51 +0000
Date: Mon, 20 Sep 2004 15:26:32 +0200
From: Nagi Reddy Jonnala <[email-masked]>
Reply-To: [email-masked]
Organization: Alcatel Telecom
To: [email-masked]
CC: "[email-masked]'" <[email-masked]>
Subject: Re: NAIbis spec revision 03

Jari,

See the snips from formal syntax (Infact they are there in the oiginal
RFC as well).

char        =/ "\" x
x           =  %x00-7F ; all 128 ASCII characters, no exception

I suppose that you would want to allow the user name like
"myusername\x0\x1". I'm curious to know  in which cases do we make use
of these combo characters.

Doesn't it look consistent if you make the syntax of x to take all 256
includes ASCII and the remaining UTF-8 characters ( i.e., x = %x00-FF)

regards
Nagi.

Jari Arkko wrote:

> Hi,
>
> Working group last call completed on this document some
> time ago. I have now put a modified draft revision and diffs
> at
>
>    http://www.arkko.com/publications/nai/naibis.txt
>    http://www.arkko.com/publications/nai/naibisdiff.html
>
> The modifications include a few editorial improvements
> on the ABNF that Pasi suggested, a couple of other
> editorial things, and the removal of a claim that
> the bis version '!' puts stricter requirements on the
> parts preceding the '!' sign than in RFC 2486.
>
> I think the conclusion from the IKEv2 discussion is
> that there's a couple of promising alternatives for
> transporting i18n or privacy enhanced NAIs over IKEv2.
> But it seems that we should not do them in the NAIbis
> spec. (But I volunteer to draft a spec for that in
> some other context.)
>
> If I missed anything, scream now. I will submit this
> to the I-D directories in a couple of days.
>
> --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/>

--
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, 20 Sep 2004 05:47:46 +0000
Date: Mon, 20 Sep 2004 08:35:01 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "[email-masked]'" <[email-masked]>
Subject: NAIbis spec revision 03

Hi,

Working group last call completed on this document some
time ago. I have now put a modified draft revision and diffs
at

   http://www.arkko.com/publications/nai/naibis.txt
   http://www.arkko.com/publications/nai/naibisdiff.html

The modifications include a few editorial improvements
on the ABNF that Pasi suggested, a couple of other
editorial things, and the removal of a claim that
the bis version '!' puts stricter requirements on the
parts preceding the '!' sign than in RFC 2486.

I think the conclusion from the IKEv2 discussion is
that there's a couple of promising alternatives for
transporting i18n or privacy enhanced NAIs over IKEv2.
But it seems that we should not do them in the NAIbis
spec. (But I volunteer to draft a spec for that in
some other context.)

If I missed anything, scream now. I will submit this
to the I-D directories in a couple of days.

--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, 13 Sep 2004 11:54:16 +0000
content-class: urn:content-classes:message
Subject: RE: New draft submission - Chargeable User Identity
Date: Mon, 13 Sep 2004 14:50:38 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi all,

Just to follow-on to David. This is what is defined in the Diameter CCA,
and is used by 3GPP for charging.  If there are additional values that
would be useful to add, it would be consistent with the Diameter
CC application to add more.

If we could align the proposed draft with the Diameter CC app, that
would be great.

thanks,
John

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext David Mariblanca
> (ML/EEM)
> Sent: 13 September, 2004 12:16
> To: 'Adrangi, Farid'; Bernard Aboba
> Cc: Nelson, David; Avi Lior; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: New draft submission - Chargeable User Identity
> 
> 
> 
> Hi Farid and others,
> for these purposes, in 3GPP it's used the Subscription-Id AVP 
> from the Diameter Credit Control application. It is a grouped 
> AVP with these values:
> 
>    END_USER_E164                   0  
>      The identifier is in international E.164 format (e.g. MSISDN), 
>      according to the ITU-T E.164 numbering plan as defined in [E164] 
>      and [CE164]. 
>                 
>    END_USER_IMSI                   1  
>        The identifier is in international IMSI format, 
> according to the 
>      ITU-T E.212 numbering plan as defined in [E121] and [CE121].  
>              
>    END_USER_SIP_URI                2  
>      The identifier is in the form of a SIP URI as defined in [SIP].  
>                          
>    END_USER_NAI                    3  
>      The identifier is in the form of a Network Access Identifier as 
>      defined in [NAI].  
>              
>    END_USER_PRIVATE                4   
>      The Identifier is a credit-control server private identifier. 
> 
> If an attribute for a similar purpose is to be created for 
> RADIUS, shouldn't it be a mapping from this one ?
> 
> BR,
> David.
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Adrangi, Farid
> Sent: viernes, 10 de septiembre de 2004 19:02
> To: Bernard Aboba
> Cc: Nelson, David; Avi Lior; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: New draft submission - Chargeable User Identity
> 
> 
> Yes, that is the intent.  The VSA uses the same string format as
> described in the IETF draft, and it is temporary until we get 
> a standard
> attribute from IETF.  Several GSMA vendors have already 
> implemented and
> tested the VSA for EAP-SIM trial - and they are ready to 
> replace it with
> the IETF standard attribute for the deployment.  So, getting the
> standard attribute from IETF sometime this year would be 
> great!  BTW, as
> you already know, GSAM has sent an LS on this to IETF.  
> 
> I also copied Sami Ala-luukko on this thread as well.
> 
> BR,
> Farid
> 
> 
> > -----Original Message-----
> > From: Bernard Aboba [mailto:[email-masked]] 
> > Sent: Friday, September 10, 2004 9:43 AM
> > To: Adrangi, Farid
> > Cc: Nelson, David; Avi Lior; [email-masked]; 
> > [email-masked]
> > Subject: Re: New draft submission - Chargeable User Identity
> > 
> > 
> > BTW, I noticed that the GSMA roaming spec includes VSAs for 
> chargeable
> > userID as well as location.  Is the GSMA prepared to adopt an IETF
> > standard attribute spec for chargeable userID instead, 
> assuming it is
> > completed within their time frame?  What is that time frame?
> > 
> > 
> > On Fri, 10 Sep 2004, Adrangi, Farid wrote:
> > 
> > > Hi,
> > > I would like to submit 00 version of a draft to RADEXT WG.  
> > Here is the
> > > url to the draft:
> > >
> > > 
> > http://mng.ctgisp.com/IETF/RADIUSEXT/draft-adrangi-radius-char
> geable-user-id-00.txt
> >
> > I also attached a copy to this mail.
> >
> > BR,
> > Farid
> >
> >
> 
> --
> 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: Mon, 13 Sep 2004 09:16:49 +0000
From: "David Mariblanca (ML/EEM)" <[email-masked]>
To: "'Adrangi, Farid'" <[email-masked]>, Bernard Aboba <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: RE: New draft submission - Chargeable User Identity
Date: Mon, 13 Sep 2004 11:15:41 +0200

Hi Farid and others,
for these purposes, in 3GPP it's used the Subscription-Id AVP from the Diameter Credit Control application. It is a grouped AVP with these values:

   END_USER_E164                   0  
     The identifier is in international E.164 format (e.g. MSISDN), 
     according to the ITU-T E.164 numbering plan as defined in [E164] 
     and [CE164]. 
                
   END_USER_IMSI                   1  
       The identifier is in international IMSI format, according to the 
     ITU-T E.212 numbering plan as defined in [E121] and [CE121].  
             
   END_USER_SIP_URI                2  
     The identifier is in the form of a SIP URI as defined in [SIP].  
                         
   END_USER_NAI                    3  
     The identifier is in the form of a Network Access Identifier as 
     defined in [NAI].  
             
   END_USER_PRIVATE                4   
     The Identifier is a credit-control server private identifier. 

If an attribute for a similar purpose is to be created for RADIUS, shouldn't it be a mapping from this one ?

BR,
David.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Adrangi, Farid
Sent: viernes, 10 de septiembre de 2004 19:02
To: Bernard Aboba
Cc: Nelson, David; Avi Lior; [email-masked];
[email-masked]; [email-masked]
Subject: RE: New draft submission - Chargeable User Identity

Yes, that is the intent.  The VSA uses the same string format as
described in the IETF draft, and it is temporary until we get a standard
attribute from IETF.  Several GSMA vendors have already implemented and
tested the VSA for EAP-SIM trial - and they are ready to replace it with
the IETF standard attribute for the deployment.  So, getting the
standard attribute from IETF sometime this year would be great!  BTW, as
you already know, GSAM has sent an LS on this to IETF.  

I also copied Sami Ala-luukko on this thread as well.

BR,
Farid

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Friday, September 10, 2004 9:43 AM
> To: Adrangi, Farid
> Cc: Nelson, David; Avi Lior; [email-masked]; 
> [email-masked]
> Subject: Re: New draft submission - Chargeable User Identity
> 
> 
> BTW, I noticed that the GSMA roaming spec includes VSAs for chargeable
> userID as well as location.  Is the GSMA prepared to adopt an IETF
> standard attribute spec for chargeable userID instead, assuming it is
> completed within their time frame?  What is that time frame?
> 
> 
> On Fri, 10 Sep 2004, Adrangi, Farid wrote:
> 
> > Hi,
> > I would like to submit 00 version of a draft to RADEXT WG.  
> Here is the
> > url to the draft:
> >
> > 
> http://mng.ctgisp.com/IETF/RADIUSEXT/draft-adrangi-radius-char
geable-user-id-00.txt
>
> I also attached a copy to this mail.
>
> BR,
> Farid
>
>

--
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, 10 Sep 2004 17:03:31 +0000
Content-class: urn:content-classes:message
Subject: RE: New draft submission - Chargeable User Identity
Date: Fri, 10 Sep 2004 10:02:22 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: "Nelson, David" <[email-masked]>, "Avi Lior" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Yes, that is the intent.  The VSA uses the same string format as
described in the IETF draft, and it is temporary until we get a standard
attribute from IETF.  Several GSMA vendors have already implemented and
tested the VSA for EAP-SIM trial - and they are ready to replace it with
the IETF standard attribute for the deployment.  So, getting the
standard attribute from IETF sometime this year would be great!  BTW, as
you already know, GSAM has sent an LS on this to IETF.  

I also copied Sami Ala-luukko on this thread as well.

BR,
Farid

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Friday, September 10, 2004 9:43 AM
> To: Adrangi, Farid
> Cc: Nelson, David; Avi Lior; [email-masked]; 
> [email-masked]
> Subject: Re: New draft submission - Chargeable User Identity
> 
> 
> BTW, I noticed that the GSMA roaming spec includes VSAs for chargeable
> userID as well as location.  Is the GSMA prepared to adopt an IETF
> standard attribute spec for chargeable userID instead, assuming it is
> completed within their time frame?  What is that time frame?
> 
> 
> On Fri, 10 Sep 2004, Adrangi, Farid wrote:
> 
> > Hi,
> > I would like to submit 00 version of a draft to RADEXT WG.  
> Here is the
> > url to the draft:
> >
> > 
> http://mng.ctgisp.com/IETF/RADIUSEXT/draft-adrangi-radius-char
geable-user-id-00.txt
>
> I also attached a copy to this mail.
>
> BR,
> Farid
>
>

--
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, 10 Sep 2004 16:51:49 +0000
Date: Fri, 10 Sep 2004 09:43:06 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>
cc: "Nelson, David" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked], [email-masked]
Subject: Re: New draft submission - Chargeable User Identity

BTW, I noticed that the GSMA roaming spec includes VSAs for chargeable
userID as well as location.  Is the GSMA prepared to adopt an IETF
standard attribute spec for chargeable userID instead, assuming it is
completed within their time frame?  What is that time frame?

On Fri, 10 Sep 2004, Adrangi, Farid wrote:

> Hi,
> I would like to submit 00 version of a draft to RADEXT WG.  Here is the
> url to the draft:
>
> http://mng.ctgisp.com/IETF/RADIUSEXT/draft-adrangi-radius-chargeable-user-id-00.txt
>
> I also attached a copy to this mail.
>
> BR,
> Farid
>
>

--
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, 08 Sep 2004 19:48:43 +0000
Content-class: urn:content-classes:message
Subject: Planning for IETF 61
Date: Wed, 8 Sep 2004 15:47:45 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Colleagues,

Bernard and I are currently planning the RADEXT session(s) for IETF 61 in November.  In order to determine whether we should request one meeting slot or two meeting slots, it would be extremely helpful to have advance notice of (a) any potential submissions and (b) any pending technical discussions.

If you are planning to (or might possibly) submit an Internet-Draft (or revision) or technical presentation for consideration by RADEXT at IETF 61, *PLEASE* reply with a general notice of your intent, with a very brief description.  Please do it *NOW*.  :-)  We'd rather not have to scurry for a second slot at the last minute, as last minute submissions continue to arrive.

Thanks!
 
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: Sun, 05 Sep 2004 07:42:02 +0000
Date: Sun, 05 Sep 2004 10:40:02 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Beck01, Wolfgang" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: AW: review of draft-sterman

Beck01, Wolfgang wrote:

>>Somehow the above arguments feel a bit out of place here. Just
>>state that Digest is widely used in SIP, and leave it at that :-)
> 
> Some people wanted a motivational section. Some people complained
> about that section. I will shorten it.

Fair enough.

>>>   PKI solutions only cover authentication, not authorization (EAP could
>>>   change this, but its use with SIP is not standardized).  TLS / Basic
>>>   authentication works only with the limited number of SIP devices that
>>>   implement TLS.  Basic authentication has been deprecated for SIP in
>>>   [RFC3261].
>>>
>>>   Current RADIUS-based AAA infrastructures have been built and debugged
>>>   over years.  Deficiencies of RADIUS have been mitigated with
>>>   proprietary (ie costly) extensions.  Operators are therefore
>>>   reluctant to replace their RADIUS infrastructure in order to enable a
>>>   single new authentication mechanism.
>>>
>>
>>Same as above. And I'm not sure all deficiences have been
>>mitigated.
> 
> 'Deficiencies of RADIUS ..' --> 'Some deficiencies of RADIUS'

Ok.

>>>   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
>>>   will be assigned by IANA, if this specification becomes a working
>>>   group or IESG document.
>>
>>Here's an idea: I'd prefer the attributes in this and the Diameter
>>draft to be constructed with the following rules:
>>
>>(1) Don't invent too many of them. Maybe Dig-Alg, Dig-Auts, Dig-QoP,
>>    and Dig-Authp could all use the same attribute? They all have
>>    the same syntax in HTTP (param=value).
> 
> Well, I did this for nonce and nextnonce, response and rspauth.
> Some reviewers found this ugly:
> 
> Miguel Garcia:
> "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?"
> 
> Bernard Aboba:
> "Also, saving attribute space is not a design goal of this document.
> Diameter compatibility *is* a design goal."
> 
> And a guy named Jari Arkko wrote on Mo 09.08.2004 :-)
> "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)."

I can see that I possibly contradicted myself as far
as number of attributes goes :-( Anyway, my main priority is
that the SIP and Diameter versions work with automatic
translation (item 2) and that you and Miguel agree on
the attributes that should be used (item 3). I don't think
the number of attributes is a limiting factor in terms of
available space; you should design the attributes so that
people like the resulting set. My original thought in the
review was that it would be cleaner if the attributes that
looked the same syntactically were transported in the same attribute.
But I understand the argument that the parameters have different
functions, and I guess this is what other people are saying
makes the parameter merging look ugly. I'm OK with that approach
too.

>>(2) If both RADIUS and Diameter are going to define the attributes,
>>    IMHO it would make sense to allocate them from the RADIUS space
>>    so a conversion box would not have to map attributes.
>>
> 
> not easy.

Can you elaborate why this would not be easy?

>>    Alternative idea: use some of the extended RADIUS attribute
>>    format ideas and allocate the numbers from the Diameter space.
>>
> 
> This would introduce a new dependency on other drafts.

Yeah, I just included the suggestion for completeness'
sake. I'd prefer the RADIUS space allocation.

>>(3) Use exactly the set of attributes for the pure digest function
>>    (I did not check if this is already the case).
> 
> 
>    +-----+           +-----+           +-----+
> 
> 
>>The choice between the server and client generated
>>nonces: is there some guidance on how the client knows
>>which one to do? if it believes it may have a user that
>>does Digest AKA then it should do use the server generated
>>scheme? But how would it know this in a roaming case?
> 
> If you are expecting AKA users, you have to use server
> generated nonces.

I guess my question was how do you know you are expecting
AKA users. Is there a fallback in case we were NOT expecting
them but one showed up because our roaming partner started
supporting AKA yesterday?

What does DIAMETER SIP do in this case? Always assume the additional
roundtrip?

>>What abbreviations need to be expanded in the abstract (or possibly
>>also in the title)? The used acrynyms are: RADIUS, SIP, HTTP, CHAP.
> 
> RfC 2866 (RADIUS Accounting) uses the abbreviation
> RfC 2617 (HTTP Digest) uses the abbreviation, too.
> CHAP has already been eliminated from the abstract.
> Proposal:
> "Several protocols use HTTP digest authentication.  This document specifies
> an extension to RADIUS that allows a RADIUS client in a server, upon
> reception of a request, retrieve and compute Digest authentication
> information from a RADIUS server.  Additionally, a scenario describing
> the authentication of a user emiting a request is provided."

Ok.

--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: Fri, 03 Sep 2004 19:29:06 +0000
Content-class: urn:content-classes:message
Subject: RADEXT WG Minutes for IETF60 Thursday session
Date: Fri, 3 Sep 2004 15:28:40 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

IETF 60
RADIUS Extensions (RADEXT) WG
Minutes of the Thursday August 5, 2004 Session

Agenda bash - no changes.

Radius issues and fixes presentation: Dave Nelson
RFC2865
	- No explicit attribute tagging for optional vs. mandatory in RFC2865
	- Apparent text conflict among sections of RFC2865 on "mandatory" behavior
	- Need to change or clarify existing implementations/standards?  
	- No, more along the lines of documentation fixes.
	- Need to be clear moving forward about attributes being 
	mandatory vs. optional.
	- Draft output will be informational

Request ID supplementation/augmentation
	- Issue is that the Request ID is only 8-bits
	- Is existing advice (e.g. RFC) adequate?
	- How many implementations of this?  Three hands.
	- Allocate as many IDs to ports as needed; no problem

What's an SSA?
	- SDO-Specific-Attribute vs. VSA
	- SSA has more formal syntax than VSA
	- Why is this an issue?  Isn't an issue yet.
      - Proposed to assist SDOs in doing RADIUS standards work outside of 	IETF.

3576/NASREQ  Session change dynamically; how do you notify accounting?
	- start/stop vs. interim messages
	- interim messages often ignored.
	- start/stop releases all resources.
	- possible solution: attribute in Authorize-Only Access-Accept
	- Q: We currently use final stop message for billing information, 
	we would prefer start/stop.
	- Q: Are resources released on a stop message?  
	- A: Yes, we release IP addresses on a stop.
	- Q: Not in 3GPP; you send a session continue attribute instead.

RADIUS Authorize only messages
	- RFC 3576 COA messages
	- Must semantics be complete?
	- People are no using Authorize-Only messages to authorize Service 	Instance or for prepaid quotas.  
	- Problem is that may have to include >all< previous information
	in Authorize-Only message.
	- Q: Has this affected anybody in room?
	- A: We have assumed that subset only is OK, and we've worked
	with partners to implement that.  
	- A: It's not explicitly part of standard to do that.
	- Need further discussion on the RADEXT list.

Data Model issues: Bernard Aboba
	- RADIUS dictionary is not defined in any RFCs
	- Client doesn't need to have dictionary; always has to change.
	(Results of research through various RFCs for data types)
	- RFCs only have 4 fundamental data types
	- Q: Framed-IPv6-Prefix design worked OK.  
	- A: Yes, but should have been a string.
	- Q: still need to parse.  Yes
	- Q: Server doesn't need to parse string: passed to back end 
	authenticator
	- Q: several obscure types never actually used: time stamps, etc.

LAN Attribute Extensions: Farid Adrangi
	- draft-adrangi-radius-attribute-extension-01.txt
	- Attributes useful for wireless roaming, but could still be 
	useful for other uses.
	- User Identity Alias Attribute
	- Q: Don't know which is correct, especially if multiple ones;
	not that it's opaque.
	- User name is used for routing purposes, User Alias is designed
	to be unique.
	- Q: Why all the alias types, when there is only one use for this 	attribute?
	- A: For flexibility, feedback from GSM operators... 
	- Q: This defeats anonynimity.
	- Generic RADIUS Application Capability Attribute
	- Enable home RADIUS server to discover capabilities of client
	- IP Address Type Options Attribute
	- Routable vs. non-routable
	- Other attributes
	- Went long on presentation; hold further discussion on the RADEXT 	list
	- Most important is User-Name.
	- Q: Monday presentation had application stuff; is there overlap?  
	- A: No
	- Need further discussion on the RADEXT list.

RADIUS Data Model Issues: Jari Arkko
	- Not all attributes created equal
	- That's cool; different spaces for different purposes
	- Hard to transfer attributes between spaces
	- Can't move from Diameter to RADIUS
	- Q: Would it be valuable to survey current VSA usage?  
	- A: Um, no; too many.
	- Q: Mandatory vs. Optional: applicable to these new types?
	- A: Would have to be optional
	- Q: Is there actually a plan on how we're going to keep parts in 	sync?  
	- A: Nope, no plan, and that's the path we are still following.
	-  Diameter compatibility section necessary in drafts.  
	- Diameter Vs. RADIUS; wish we weren't still discussing RADIUS at all.
	- Vendors don't pay attention to what the IETF does.
	- Jari and Farid have presented three options moving forward
	- Farid is orthogonal to Jari's
	- Q: May not be able to keep both spaces in sync.
	- Q: Interoperability may be between WGs as well as on the wire.  
	- Naming an attribute may be sufficient; don't need to define them
	- Q: What are the various options we need to decide between?
	- Q: Difference between two groups of options.

	- Bernard: Ask group if problems are important?  
	- Group hum: some sort of capability negotiation is needed? 
	- A: Yes
	- Group hum: easier way to share capabilities between Diameter and
      RADIUS?
 	- A: Not as strong, but rough consensus
	- Group hum: need to extend attribute type space?  More type numbers? 
	- A: Response "iffy" either way.  
	- Comment: We'll run out anyway.
	- Q: SSAs may become VSAs
	- Group hum: need for easier movement between VSA attribute space
	and and IETF attribute space?  Alignment of data models?
	- A: Yes

Three additional presentations first, then discussions

RADIUS vulnerability in Wireless: Randy Chou
	- Point is to point out practicality of attacks
	- How many have read actual draft?  About 1/3 to 1/2.
	- Use one example of problem: 802.11i encryption keys depend on
	RADIUS shared secret.
	- Wired sniffing is riskier; wired infrastructure can sense
	promiscuous adapters
	- Shared secret can be easily known; not kept confidential.
	- Loss of shared secret is equivalent to loss of certificate
	- Q: RADIUS Shared secret isn't equivalent to certificate: certificate
	is designed to be shared in a wider area.
	- Q: Does document have anything about RADIUS over IPSec? 
	- A: No.  Some issues covered in 3579.
	- Q: What is the perception of RADIUS Shared Secret?  Is root password 	perceived as similar to RADIUS secret.
	- Q: RADIUS been around a long time; any reports on existing or past 	attacks on RADIUS servers?  Wouldn't be necessarily publicized.
	- Q: This is a RADIUS problem, not a wireless problem.  Taking to the 	press that it's a wireless problem was irresponsible.  
	- A: Consequences need to be publicized as well.
	- Q: This really is a wired vulnerability, not a wireless 	vulnerability.  	
	- A: sniffing on wired networks is harder.
	- Q: Wired sniffing is mandatory for this attack to happen; no wired,
	no attack at all.  
	- A: Agreed
	- Q: Can there be Wireless RADIUS servers?
	- A: Yes.
	- Q: If RADIUS secret is compromised, the user passwords are 	compromised.  Why go for the wireless keys?  Can store wireless 	traffic, and in future when radius secret broken, can decrypt captured 	traffic

RADIUS Shared Secret Security Amplification: Paul Funk
	- Is RADIUS encryption/validation good enough?
	- Dictionary attack.
	- Attacker must have layer 2 traffic visibility
	- Q: Finely hashed becomes the secret. Small final key space allows a 	brute force that's faster than dictionary/hash attack.  
	- A: 96-bit key space can't be brute-forced.
	- Q: If a utility is used, why not also have the utility throw in a
	random number?  
	- A: Want to be able to regenerate final answer easily from remembered 	information.
	- Q: Base64 may be incompatible with some RADIUS product input 	limitations.
	- Q: Why not use RSA instead?
	- A: Trying to increase work needed
	- Q: Why not just pre-calculate dictionary?  
	- A: See upcoming slide, also use salt.
	- Q: Why do I need to ever know the precursor?  I have the final 
	output...
	- A: Many people just want to use the pre-cursor, because they
	>can< remember it.

Transmit keys by RADIUS using AES key wrapping: Glen Zorn
	- Make more secure, and satisfy customer requirements.
	- Q: Recommend use only one shared secret, rather than two.
	- A: two makes more sense, especially for multiple entities.
	- Q: Any discussion with NIST?  FIPS approval?  
	- A: NIST has problem with MD5 in RADIUS header, but as long as it
	isn't relied upon, then OK.
	- Q:  NIST has no formal statement on this.

 

--
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, 03 Sep 2004 19:27:22 +0000
Content-class: urn:content-classes:message
Subject: RADEXT WG Minutes for IETF60 Monday session
Date: Fri, 3 Sep 2004 15:26:09 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

IETF 60
RADIUS Extensions (RADEXT) WG 
Monday August 2, 2004 Session Minutes

The agenda is listed at:
http://www.drizzle.com/~aboba/RADEXT/ietf60_radext_agenda.ppt

Agenda bashing - no changes.

Liason requests - from other SDOs: 802.11, 802.1, GSMA SLAN
 WFA 3GPP2 3GPP  (See http://www.drizzle.com/~aboba/RADEXT/liasons/ )

Liason Plan - In the short term, we will address SDO requests in a
timely way.
In the long term, the IETF wishes to focus on protocol changes and
extensions with widespread appeal.  Other SDOs should be prepared to
work on extensions particular to their own requirements.  RADEXT WG
should assist SDOs in doing their own work (ala SNMP).

WG milestones -  See web page
http://www.ietf.org/html.charters/radext-charter.html

WG last call is currently being held on drafts:
2486bis (NAI), draft-arkko-roamops-rfc2486bis-02.txt
RADIUS Extension for Digest Authentication, draft-sterman-aaa-sip-03.txt

Presentations -

Bert Wijnen - RADIUS MIB Changes for IPv6
	- Should go fast with MIB doctor participation
- Could augment existing documents, but could deprecate old modules so
that implementations would be more straightforward.  
	- Needed to do IPv6 
	- Create 5 new objects
       - Propose WG augment existing modules - agreement from floor
       - MIBs needing be to be recycled are RFC 2618-21
    - WG prefers to modify existing MIBs rather than create new 
    docs

Mutaza Chiba - MIB for RFC3576, Dynamic RADIUS
       - Create a MIB similar to existing  RADIUS MIBs
       - Need two MIBS, one for client one for server
       - Currently only for IPv6
- Question of who is interested in this work - got no response	

David Nelson - Extended Management attributes
	- Existing two attributes are service types for CLI
	- Need other attributes for SNMP, HTTP, etc.
 	- Also need security levels 
	- Need attributes to specify roles or privilege levels
	- See draft-nelson-radius-management-authorization-00.txt
	- SNMP usage in conjunction with service type of "Framed-
Management"
       - Bert W. points out that SNMPv1 and v2c are now historical
	- Suggestion that community based SNMP not be supported 
       - Enterasys is working in this area using vendor-specific
attributes
	- Idea is that this might be more generally useful and if 
	others are interested it could be standardized
	- Two hands indicating interest from the audience
	- Send comments and suggestions to the RADEXT list

Wolfgang Beck - SIP authentication  - draft-sterman-aaa-sip-03.txt
	- RADIUS server generates nonces
       - Required for AKS
       - Draft version 03 emulates an access-challenge sequence
       - Proposal - use Access-Challenge RADIUS packet type
       - Draft in last call - please send comments to list soon !!
       
Jari Arkko - RFC2486bis
	- Status - rewrote to fix errors in draft version 00
	- Clarified the ! syntax
	- Added privacy discussion
	- Changed the examples
	- Discussion on list about feature interaction between 
	User-Name rewrite and the ! syntax
	- could note this in some guideline document
      - or could require a reverse ! conversion for Access-Accept
processing
	- Jari won't talk about it in this draft
	- Question from Paul Funk about why not just convert to what is
required for other apps when needed
       - Jari points out a problem with sending NAI to DNS if the two
are 	not the same
       - Question is whether NAI and email (DNS) will internationalize
the 	same way
      - Internationalization will take time
	- This might be a problem in time?  Probably will not need to
mail 	using NAI address, (so not a problem) but not completely clear.
       - Draft in last call - please send comments to list soon !! :)

Jari Arkko for David Mariblanca - Lower Layer EAP Issues
	- Provides information about the lower layer that EAP runs over
	- AAA server with EAP services both AP and VPN gateway
	- Desire to understand the EAP transport protocol, via an
attribute
	- Is it related to NAS port type
	- What is the port type
       - Could it be handled by sub-type of port type
       - Idea is to tell server what is going on in the access  point, 
       what are the attributes  that are important
       - Focuses on EAP carrier between the user and client - not the
port,
        although not clear what the difference is
       - Topic will be brought up more on the RADEXT list
       
Paul Congdon - LAN Attributes for 802.1
	- Collected stuff from various groups
	- Other attributes will be discussed Thursday
       - Possible overlap and alignment with LAN tunnel attributes
	- How should the attributes be bundled?
	- Attempt is to bundle to solve IEEE 802 issues
	- Will anyone implement this in RADIUS servers (is it
interesting)?
	- Implementer comments?

Avi Lior - RADIUS Redirection
       - Sometimes an operator would like to be able to control a user
session
	- Limit what user can do (e.g. "walled garden")
	- Notifying the user (e.g. with  SMS)
	- Notification scheme not covered in the draft
	- Draft includes NAS-Filter-Rule attribute
	- Feature to redirect HTTP traffic to support Web Authentication
	- Discussion of difference between RADIUS and Diameter
	- Question: why not do redirection inside a filter, because
ordering 	is important
	- Answer: wanted to be compatible with Diameter
	- Talk about this issue some more on the RADEXT list

Bandwidth 
	
On the bandwidth draft, there was some discussion around what can we
actually specify, or do we simply have to punt the problem and identify
a filter-id that must be pre-configured?   That is really how the
filter-ID scheme came up in the first place. No-one could agree on a
standard set of controls, so to wash your hands of the problem, they
simply send down an identifier.  This isn't really driving us towards
good interoperable implementations.

	- Allow an end-user organization to specify bandwidth
       - Advertisement of bandwidth capabilities is optional
	- Selection of allowed bandwidth by AAA server
	- Followed by confirmation message
	- Re-authentication with either push or pull model
	- Issue: single attribute or separate attributes for four
parameters?
	- Issue: include burst size, profile ID or algorithm ID?
	- Issue: what hardware will be able to support this?
	- Devices may have rich QoS capabilities
	- Can use vendor specific attributes, but then how to
standardize.
  	- Is there a standard way to specify QoS?

Avi for ? - prepaid
	- Presented prepaid model, i.e. carrying prepaid service /
credit 	info over RADIUS
	- Multi-services - differentiate between flow types
	- Service may be different IP-flows 
	- Access service is default or initial service
	- 3GPP2 uses it as the "main" service instance
	- Quota - complicated buckets to manage variety of applications
	- Next steps - traffic to date vs. delta
	
Avi for Hannes - prepaid
	- Extensions for event based charging
	- Service is not access service
	- How does RADIUS specify service and actions?
	
Volunteers requested for 
	Issues doc

--
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, 02 Sep 2004 17:40:52 +0000
From: "Lothar Reith" <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: AW: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt
Date: Thu, 2 Sep 2004 19:39:55 +0200 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C49113.DBEB2B48
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

David,

thanks for these references  (shame on me for using the term cryptography
without having read the cryptography bible of Bruce Schneier).

However, I meanwhile found some references that also use the term
guessability in a way which I consider consistent to my proposal of
replacing the term "effective entropy" by "guessability", including:

http://csrc.nist.gov/kba/Presentations/Day%202/Chokhani-KBA%20Metrics.pdf 

http://www.ifp.uiuc.edu/~paradasa/talks/IMCrypto_ECE459Talk.pdf

and taken from: www.cnri.dit.ie/Downloads/guesswork_and_entropy.ps
"In all these cases entropy is being used to measure `guessability'. There
are many possible criteria for specifying `guessability'. The one we
consider here is the expected number of guesses required to get the correct
answer. There are various strategies which can be used for guessing.
Commonly know are brute force attacks where all symbols are guessed in no
particular order, and dictionary attacks where symbols which are deemed more
probable are guessed first. Well known software such as Crack [8] uses a
dictionary attack. 

The guessing strategy we consider is the optimal one, where symbols are
guessed in decreasing order of probability. "

Also, there is an Internet Draft mentioning  guessability in the context of
email adresses:  

http://www.ietf.org/internet-drafts/draft-pale-email-01.txt. 

Best Regards, Lothar

-----Ursprüngliche Nachricht-----
Von: Nelson, David [mailto:[email-masked]] 
Gesendet: Donnerstag, 2. September 2004 17:58
An: Reith, Lothar [HAHN:NGD:EXCH]; [email-masked]
Betreff: RE: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt

Note that it leaves the word entropy in one of it's cryptographic meaning
(by the way I did not know of the cryptographic definition, only of the
physical definition in the first place).
 
DBN:  For those interested, the cryptographic definition of entropy is
derived from Information Theory, specifically two papers by Shannon:
C.E.Shannon: A mathematical theory of communications. Bell Systems Journal,
27:379-423, 623-656, 1948 and C.E. Shannon: Communications theory of secrecy
systems. Bell Systems Journal, 28:656-715, 1949.
 
DBN: Cryptographic entropy is also discussed in most cryptography texts,
e.g. B. Schneier: Applied Cryptography, 2nd Ed., 233-237, 1996.

------_=_NextPart_001_01C49113.DBEB2B48
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2656.31">
<TITLE>AW: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>David,</FONT>
</P>
<BR>

<P><FONT SIZE=2>thanks for these references&nbsp; (shame on me for using the term cryptography without having read the cryptography bible of Bruce Schneier).</FONT></P>

<P><FONT SIZE=2>However, I meanwhile found some references that also use the term guessability in a way which I consider consistent to my proposal of replacing the term &quot;effective entropy&quot; by &quot;guessability&quot;, including:</FONT></P>

<P><FONT SIZE=2><A HREF="http://csrc.nist.gov/kba/Presentations/Day%202/Chokhani-KBA%20Metrics.pdf" TARGET="_blank">http://csrc.nist.gov/kba/Presentations/Day%202/Chokhani-KBA%20Metrics.pdf</A> </FONT>
</P>

<P><FONT SIZE=2><A HREF="http://www.ifp.uiuc.edu/~paradasa/talks/IMCrypto_ECE459Talk.pdf" TARGET="_blank">http://www.ifp.uiuc.edu/~paradasa/talks/IMCrypto_ECE459Talk.pdf</A></FONT>
</P>

<P><FONT SIZE=2>and taken from: www.cnri.dit.ie/Downloads/guesswork_and_entropy.ps</FONT>
<BR><FONT SIZE=2>&quot;In all these cases entropy is being used to measure `guessability'. There are many possible criteria for specifying `guessability'. The one we consider here is the expected number of guesses required to get the correct answer. There are various strategies which can be used for guessing. Commonly know are brute force attacks where all symbols are guessed in no particular order, and dictionary attacks where symbols which are deemed more probable are guessed first. Well known software such as Crack [8] uses a dictionary attack. </FONT></P>

<P><FONT SIZE=2>The guessing strategy we consider is the optimal one, where symbols are guessed in decreasing order of probability. &quot;</FONT>
</P>

<P><FONT SIZE=2>Also, there is an Internet Draft mentioning&nbsp; guessability in the context of email adresses:&nbsp; </FONT>
</P>

<P><FONT SIZE=2><A HREF="http://www.ietf.org/internet-drafts/draft-pale-email-01.txt" TARGET="_blank">http://www.ietf.org/internet-drafts/draft-pale-email-01.txt</A>. </FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=2>Best Regards, Lothar</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>-----Ursprüngliche Nachricht-----</FONT>
<BR><FONT SIZE=2>Von: Nelson, David [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>
<BR><FONT SIZE=2>Gesendet: Donnerstag, 2. September 2004 17:58</FONT>
<BR><FONT SIZE=2>An: Reith, Lothar [HAHN:NGD:EXCH]; [email-masked]</FONT>
<BR><FONT SIZE=2>Betreff: RE: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt</FONT>
</P>
<BR>

<P><FONT SIZE=2>Note that it leaves the word entropy in one of it's cryptographic meaning (by the way I did not know of the cryptographic definition, only of the physical definition in the first place).</FONT></P>

<P><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>DBN:&nbsp; For those interested, the cryptographic definition of entropy is derived from Information Theory, specifically two papers by Shannon:&nbsp; C.E.Shannon: A mathematical theory of communications. Bell Systems Journal, 27:379-423, 623-656, 1948 and C.E. Shannon: Communications theory of secrecy systems. Bell Systems Journal, 28:656-715, 1949.</FONT></P>

<P><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>DBN: Cryptographic entropy is also discussed in most cryptography texts, e.g. B. Schneier: Applied Cryptography, 2nd Ed., 233-237, 1996.</FONT></P>

<P><FONT SIZE=2>&nbsp;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C49113.DBEB2B48--

--
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, 02 Sep 2004 16:02:56 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt
Date: Thu, 2 Sep 2004 11:57:59 -0400
From: "Nelson, David" <[email-masked]>
To: "Lothar Reith" <[email-masked]>, <[email-masked]>

Note that it leaves the word entropy in one of it's cryptographic meaning (by the way I did not know of the cryptographic definition, only of the physical definition in the first place).
 
DBN:  For those interested, the cryptographic definition of entropy is derived from Information Theory, specifically two papers by Shannon:  C.E.Shannon: A mathematical theory of communications. Bell Systems Journal, 27:379-423, 623-656, 1948 and C.E. Shannon: Communications theory of secrecy systems. Bell Systems Journal, 28:656-715, 1949.
 
DBN: Cryptographic entropy is also discussed in most cryptography texts, e.g. B. Schneier: Applied Cryptography, 2nd Ed., 233-237, 1996.

--
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, 02 Sep 2004 13:02:46 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: AW: review of draft-sterman
Date: Thu, 2 Sep 2004 15:02:19 +0200 

Hi Jari,

>>    Due to the weaknesses of Digest authentication (see Section 6),
>
> Section 6 does not talk about the weaknesses of Digest authentication
> (original RFC reference might give you some security considerations;
> I'm not sure if there's any other document that would talk the
> issue).
Section 6 of draft-sterman references section 4 of RfC 2617. Ok,
too many levels of indirections here.

>    Due to the weaknesses of Digest authentication (see Section 6),
>    PKI-based authentication and encryption mechanisms have been
>    introduced into SIP: TLS [RFC2246] and S/MIME [RFC2633].  However,
>
> Digest, TLS, and S/MIME are not necessarily in direct
> competition with each other, as they provide slightly different
> services. For instance, TLS is hbh, and Digest gives you
> freshness which S/MIME does not. Plus all three protect
> different parts of the SIP message.
> 
> Suggestion: soften the above statement a bit.
HTTP Digest used to be the only security mechanism for SIP.
TLS and S/MIME cover the holes that HTTP digest left open.

>>    SIP service providers whishing to authenticate their clients have the
>>    following options: they can
>>    o  build a PKI and wait for interopable S/MIME capable SIP
>>       implementations,
>>    o  build a PKI and wait for SIP implementations supporting TLS with
>>       client-side certificates,
>>    o  replace their existing RADIUS infrastructure with DIAMETER
>>       [RFC3588], when DIAMETER supports HTTP Digest authentication,
>>    o  use TLS for server authentication and plaintext passwords (Basic)
>>       for client authentication, which can be done with standard RADIUS,
>>    o  upgrade their existing RADIUS servers with the functionality
>>       described in this document
>> 
>>    PKI solutions only cover authentication, not authorization (EAP could
>>    change this, but its use with SIP is not standardized).  TLS / Basic
>>    authentication works only with the limited number of SIP devices that
>>    implement TLS.  Basic authentication has been deprecated for SIP in
>>    [RFC3261].
>
> Somehow the above arguments feel a bit out of place here. Just
> state that Digest is widely used in SIP, and leave it at that :-)
Some people wanted a motivational section. Some people complained
about that section. I will shorten it.

>>    PKI solutions only cover authentication, not authorization (EAP could
>>    change this, but its use with SIP is not standardized).  TLS / Basic
>>    authentication works only with the limited number of SIP devices that
>>    implement TLS.  Basic authentication has been deprecated for SIP in
>>    [RFC3261].
>> 
>>    Current RADIUS-based AAA infrastructures have been built and debugged
>>    over years.  Deficiencies of RADIUS have been mitigated with
>>    proprietary (ie costly) extensions.  Operators are therefore
>>    reluctant to replace their RADIUS infrastructure in order to enable a
>>    single new authentication mechanism.
>>
> Same as above. And I'm not sure all deficiences have been
> mitigated.
'Deficiencies of RADIUS ..' --> 'Some deficiencies of RADIUS'

>>    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
>>    will be assigned by IANA, if this specification becomes a working
>>    group or IESG document.
>
> Here's an idea: I'd prefer the attributes in this and the Diameter
> draft to be constructed with the following rules:
>
> (1) Don't invent too many of them. Maybe Dig-Alg, Dig-Auts, Dig-QoP,
>     and Dig-Authp could all use the same attribute? They all have
>     the same syntax in HTTP (param=value).
Well, I did this for nonce and nextnonce, response and rspauth.
Some reviewers found this ugly:

Miguel Garcia:
"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?"

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

And a guy named Jari Arkko wrote on Mo 09.08.2004 :-)
"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)."

> (2) If both RADIUS and Diameter are going to define the attributes,
>     IMHO it would make sense to allocate them from the RADIUS space
>     so a conversion box would not have to map attributes.
>
not easy.

>     Alternative idea: use some of the extended RADIUS attribute
>     format ideas and allocate the numbers from the Diameter space.
>
This would introduce a new dependency on other drafts.

> (3) Use exactly the set of attributes for the pure digest function
>     (I did not check if this is already the case).

   +-----+           +-----+           +-----+

> The choice between the server and client generated
> nonces: is there some guidance on how the client knows
> which one to do? if it believes it may have a user that
> does Digest AKA then it should do use the server generated
> scheme? But how would it know this in a roaming case?
If you are expecting AKA users, you have to use server
generated nonces.

> What abbreviations need to be expanded in the abstract (or possibly
> also in the title)? The used acrynyms are: RADIUS, SIP, HTTP, CHAP.
RfC 2866 (RADIUS Accounting) uses the abbreviation
RfC 2617 (HTTP Digest) uses the abbreviation, too.
CHAP has already been eliminated from the abstract.
Proposal:
"Several protocols use HTTP digest authentication.  This document specifies
an extension to RADIUS that allows a RADIUS client in a server, upon
reception of a request, retrieve and compute Digest authentication
information from a RADIUS server.  Additionally, a scenario describing
the authentication of a user emiting a request is provided."

Thanks for your review,

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, 02 Sep 2004 12:59:02 +0000
Date: Thu, 02 Sep 2004 15:57:36 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Miguel Garcia <[email-masked]>
Cc: [email-masked], "Beck01, Wolfgang" <[email-masked]>
Subject: Re: review of draft-sterman

Miguel Garcia wrote:

> Sure, these directives have the same syntax, but obviously share 
> different semantics. Further more, we just transport the value of the 
> directive, not the "param=value" pair. Consequently, I don't think all 
> these AVPs can all use the same attribute. How can we distinguish what 
> is being transported?

By looking at what's in front of the '=', which you need
to do for Dig-authp anyway?

But I see your point. I need to think about this before
I become convinced, however :-)

> I have a question: in Diameter SIP app, all these AVPs are part of 
> parenet grouped AVP. I believe RADIUS does not offer the concept of 
> grouped AVPs. Does it represent a problem if we define a Diameter SIP 
> app grouped AVP that contains RADIUS AVPs. as it is the proposal?

I think it would imply that you'd not use grouped AVP, just
a set of AVPs. Your ABNF would be longer, but otherwise there
are no practical consequences, I think.

>>      Alternative idea: use some of the extended RADIUS attribute
>>      format ideas and allocate the numbers from the Diameter space.
>>
> 
> For the time being, I am leaning towards the RADIUS address space.

Me too.

--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: Thu, 02 Sep 2004 11:54:08 +0000
Date: Thu, 02 Sep 2004 14:52:40 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "[email-masked]'" <[email-masked]>, "Beck01, Wolfgang" <[email-masked]>, Miguel Garcia <[email-masked]>
Subject: review of draft-sterman

Hi Wolfgang, (cc Miguel)

I know I'm late, but here are a few comments on draft-sterman:

Technical:

>    Due to the weaknesses of Digest authentication (see Section 6),

Section 6 does not talk about the weaknesses of Digest authentication
(original RFC reference might give you some security considerations;
I'm not sure if there's any other document that would talk the
issue).

>    Due to the weaknesses of Digest authentication (see Section 6),
>    PKI-based authentication and encryption mechanisms have been
>    introduced into SIP: TLS [RFC2246] and S/MIME [RFC2633].  However,

Digest, TLS, and S/MIME are not necessarily in direct
competition with each other, as they provide slightly different
services. For instance, TLS is hbh, and Digest gives you
freshness which S/MIME does not. Plus all three protect
different parts of the SIP message.

Suggestion: soften the above statement a bit.

>    SIP service providers whishing to authenticate their clients have the
>    following options: they can
>    o  build a PKI and wait for interopable S/MIME capable SIP
>       implementations,
>    o  build a PKI and wait for SIP implementations supporting TLS with
>       client-side certificates,
>    o  replace their existing RADIUS infrastructure with DIAMETER
>       [RFC3588], when DIAMETER supports HTTP Digest authentication,
>    o  use TLS for server authentication and plaintext passwords (Basic)
>       for client authentication, which can be done with standard RADIUS,
>    o  upgrade their existing RADIUS servers with the functionality
>       described in this document
> 
>    PKI solutions only cover authentication, not authorization (EAP could
>    change this, but its use with SIP is not standardized).  TLS / Basic
>    authentication works only with the limited number of SIP devices that
>    implement TLS.  Basic authentication has been deprecated for SIP in
>    [RFC3261].

Somehow the above arguments feel a bit out of place here. Just
state that Digest is widely used in SIP, and leave it at that :-)

>    PKI solutions only cover authentication, not authorization (EAP could
>    change this, but its use with SIP is not standardized).  TLS / Basic
>    authentication works only with the limited number of SIP devices that
>    implement TLS.  Basic authentication has been deprecated for SIP in
>    [RFC3261].
> 
>    Current RADIUS-based AAA infrastructures have been built and debugged
>    over years.  Deficiencies of RADIUS have been mitigated with
>    proprietary (ie costly) extensions.  Operators are therefore
>    reluctant to replace their RADIUS infrastructure in order to enable a
>    single new authentication mechanism.

Same as above. And I'm not sure all deficiences have been
mitigated.

>    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
>    will be assigned by IANA, if this specification becomes a working
>    group or IESG document.

Here's an idea: I'd prefer the attributes in this and the Diameter
draft to be constructed with the following rules:

(1) Don't invent too many of them. Maybe Dig-Alg, Dig-Auts, Dig-QoP,
     and Dig-Authp could all use the same attribute? They all have
     the same syntax in HTTP (param=value).

(2) If both RADIUS and Diameter are going to define the attributes,
     IMHO it would make sense to allocate them from the RADIUS space
     so a conversion box would not have to map attributes.

     Alternative idea: use some of the extended RADIUS attribute
     format ideas and allocate the numbers from the Diameter space.

(3) Use exactly the set of attributes for the pure digest function
     (I did not check if this is already the case).

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

The choice between the server and client generated
nonces: is there some guidance on how the client knows
which one to do? if it believes it may have a user that
does Digest AKA then it should do use the server generated
scheme? But how would it know this in a roaming case?

Other ideas?

Editorial:

>    Basic and Digest authentication schemes are widely used in protocols
>    such as SIP  and HTTP .  RADIUS  is a protocol for back end

s/HTTP ./HTTP./

>    support HTTP digest authentication only.  Its interopability with a
>    back-end authentication protocol such as RADIUS is needed.

s/interopability/interoperability/

>    o  build a PKI and wait for interopable S/MIME capable SIP
>       implementations,

s/interopable/interoperable/

>    SIP service providers whishing to authenticate their clients have the
>    following options: they can

s/whishing/wishing/

>    Basic and Digest authentication schemes are widely used in protocols
>    such as SIP  and HTTP .  RADIUS  is a protocol for back end
> 
> Sterman, et al.        Expires November 30, 2004                [Page 1]
> 
> Internet-Draft    RADIUS Extension for Digest Authentication   June 2004
> 
> 
>    authentication.  RADIUS supports Basic authentication natively, as
>    well as several other authentication schemes, such as CHAP, but does
>    not support Digest authentication scheme.  This document describes an
>    extension to RADIUS for Digest authentication and provides a scenario
>    of Digest user authentication.

What abbreviations need to be expanded in the abstract (or possibly
also in the title)? The used acrynyms are: RADIUS, SIP, HTTP, CHAP.

--
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, 02 Sep 2004 08:29:49 +0000
From: "Lothar Reith" <[email-masked]>
To: "Lothar Reith" <[email-masked]>, "'Paul Funk'" <[email-masked]>, "'Clint Chaplin'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: AW: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt
Date: Thu, 2 Sep 2004 10:24:44 +0200 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C490C6.4CE482E8
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Reading my own mail again, I guess I replaced the word entropy one time too
often. I also now amended the definition to make it more clear what I mean.
 
Apologies and regards...Lothar

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im
Auftrag von Reith, Lothar [HAHN:NGD:EXCH]
Gesendet: Donnerstag, 2. September 2004 10:08
An: 'Paul Funk'; 'Clint Chaplin'; [email-masked]'
Betreff: AW: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt

Paul, 

from what I understand you really seem to be talking about a concept which
one could perhaps refer to as "guessability".

When applying this proposed term to one of your definitions, (replacing some
but not all occurances of "entropy" with "guessability") it reads like this:

The  cryptographic entropy  of a collection (of passwords) is only
indirectly related to the difficulty of attack, which can only be defined as
the probability of success against  a  number of tries. For example, a
population  of users in which "swordfish" is used 50% of the time, but a
billion other passwords are equiprobable the other 50% of the time, has
entropy of about 15 bits, but a "guessability" of 50% (if the attacker knows
that the term swordfish is  most popular for use as password  and therefore
tries it first- this is an abstraction of the concept of dictionary attack).

Note that it leaves the word entropy in  it's cryptographic meaning (by the
way I did not know of the cryptographic definition, only of the physical
definition in the first place).

Best Regards, Lothar 

-----Ursprüngliche Nachricht----- 
Von: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] Im Auftrag von Paul Funk 
Gesendet: Donnerstag, 2. September 2004 03:14 
An: Clint Chaplin; [email-masked] 
Betreff: Re: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt 

Clint, 

I don't disagree. I'll even add to your point by saying that it makes no
sense to talk about the entropy of a single password. Entropy applies to
populations; the entropy of a single item is 0. So you can't properly say
that the password "swordfish" has entropy of 20 bits. You could say that
within the collection of passwords actually used, "swordfish" is used one in
a million times, and therefore has probability of 2 ^ -20. But the
collection itself may have very low entropy; for example, if the only other
password ever used is "tuna", and it gets used 999,999 out of a million
times. So the probability of a password is not directly related to the
difficulty of attack -- in the case just described, you only have to try 2
passwords.

In addition, the entropy of a collection is only indirectly related to the
difficulty of attack, which can only be defined as the probability spectrum
of success against number of tries. For example, a population in which
"swordfish" is used 50% of the time, but a billion other passwords are
equiprobable the other 50% of the time, has entropy of about 15 bits, but an
attack will succeed in one try 50% of the time.

So talking about entropy in this context necessarily involves 
a kind of shorthand. I'm not entirely sure how to talk about it with clarity
and mathematical precision at the same time. The dodge that I took was to
define "effective entropy", and I really should use that term consistently,
as you point out. If you have a suggestion for how to use comprehensible
language to discuss these matters, let me know.

Paul 

At 05:25 PM 9/1/2004 -0700, Clint Chaplin wrote: 
>I guess part of my problem is that the term "entropy" is being used 
>here in two different incompatible but related senses, sort of like 
>"pounds force" and "pounds mass".  Entropy in the cryptographic sense 
>is the measure of the possible values an item may take on, and is 
>measured in bits.  Entropy in the thermodynamic sense is the measure of 
>the disorder in a system. 
> 
>Talking about "effective entropy" is a little bit like talking about 
>"effective pounds mass" under acceleration, which makes my teeth itch. 
> 
>Clint (JOATMON) Chaplin 
>Wireless Security Advisor 
>Wireless Standards Lead 
> 
> >>> Bernard Aboba <[email-masked]> 8/31/04 21:34:35 >>> 
>Forwarded from Clint Chaplin... 
> 
>---------- Forwarded message ---------- 
>Date: Tue, 31 Aug 2004 19:47:20 -0700 
>From: Clint Chaplin <[email-masked]> 
>To: [email-masked], [email-masked] 
>Subject: Re: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt 
> 
>Bernard: due to a snafu here at Symbol, the radiusext email list is 
>silently rejecting my posts to it; however, I can still receive the 
>emails from it.  Could you please forward this to the list for me? 
>Thanks! 
> 
>I still disagree with the use of the term "entropy" within this I-D. As 
>a simplistic way of looking at this, let's say that the input to this 
>algorithm can only take on two distinct values, and also the salt can 
>only take on two distinct values (these values may be expressed using 
>many bits, but that won't change the argument).  Since the salt and the 
>input can only have two distinct values, the entropy of each is only 1, 
>and the two combined can only take on four distinct values, and thus 
>have an entropy of 2.  Putting these four distinct valuse through the 
>amplification process will still only yield an output with four 
>distinct values (although these output values may also be expressed 
>using many bits).  No matter how many times the algorithm is applied, 
>the output will still only have a max of four distinct values, and a 
>max entropy of 2.  Hashing never adds true entropy, and if a collision 
>occurs, can reduce entropy. 
> 
>Yes, the term "effective entropy" can be used, but that just confuses 
>the issue, I feel.  Plus, there are still places in the draft where 
>"effective entropy" should be used for consistancy sake, and it is not. 
> 
>For instance, in the abstract, the phrase "A dictionary attack against 
>the resulting shared secret will be infeasible due to its high 
>entropy." should state "A dictionary attack against the resulting 
>shared secret will be infeasible due to its high effective entropy." 
> 
>In the introduction, the phrase "A dictionary attack against the 
>resulting shared secret will be infeasible due to its high entropy." 
>should be "A dictionary attack against the resulting shared secret will 
>be infeasible due to its high effective entropy." 
> 
>And so on. 
> 
>Clint (JOATMON) Chaplin 
>Wireless Security Advisor 
>Wireless Standards Lead 
> 
> >>> <[email-masked]> 8/27/04 12:42:15 >>> 
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories. 
> 
> 
>         Title           : RADIUS Shared Secret Security Amplification 
>         Author(s)       : P. Funk 
>         Filename        : draft-funk-radiusext-shared-secret-amp-01.txt 
>         Pages           : 10 
>         Date            : 2004-8-27 
> 
>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 URL for this Internet-Draft is: 
>http://www.ietf.org/internet-drafts/draft-funk-radiusext-shared-secret-
<http://www.ietf.org/internet-drafts/draft-funk-radiusext-shared-secret->  
>amp-01.txt 
> 
> 
>To remove yourself from the I-D Announcement list, send a message to 
>[email-masked] with the word unsubscribe in the body of 
>the message. You can also visit 
>https://www1.ietf.org/mailman/listinfo/I-D-announce
<https://www1.ietf.org/mailman/listinfo/I-D-announce>  
> 
>to change your subscription settings. 
> 
> 
>Internet-Drafts are also available by anonymous FTP. Login with the 
>username "anonymous" and a password of your e-mail address. After 
>logging in, type "cd internet-drafts" and then 
>         "get draft-funk-radiusext-shared-secret-amp-01.txt". 
> 
>A list of Internet-Drafts directories can be found in 
>http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>  or 
>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>  
> 
> 
>Internet-Drafts can also be obtained by e-mail. 
> 
>Send a message to: 
>         [email-masked]. 
>In the body type: 
>         "FILE 
>/internet-drafts/draft-funk-radiusext-shared-secret-amp-01.txt". 
> 
>NOTE:   The mail server at ietf.org can return the document in 
>         MIME-encoded form by using the "mpack" utility.  To use this 
>         feature, insert the command "ENCODING mime" before the "FILE" 
>         command.  To decode the response(s), you will need "munpack" or 
>         a MIME-compliant mail reader.  Different MIME-compliant mail 
>readers 
>         exhibit different behavior, especially when dealing with 
>         "multipart" MIME messages (i.e. documents which have been split 
>         up into multiple messages), so check your local documentation 
>on 
>         how to manipulate these messages. 
> 
> 
>Below is the data which will enable a MIME compliant mail reader 
>implementation to automatically retrieve the ASCII version of the 
>Internet-Draft. 
> 
> 
>_______________________________________________________________________ 
>_ 
>This email has been scanned for computer viruses. 
> 
>_______________________________________________________________________ 
>_ 
>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/ <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/ <http://psg.com/lists/radiusext/>
> 

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/ <http://psg.com/lists/radiusext/>
> 

------_=_NextPart_001_01C490C6.4CE482E8
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<TITLE>Nachricht</TITLE>

<META content="MSHTML 6.00.2800.1400" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=593211808-02092004><FONT face=Arial color=#0000ff 
size=2>Reading my own mail again, I guess I replaced the word entropy one time 
too often. I also now amended the definition to make it more clear what I 
mean.</FONT></SPAN></DIV>
<DIV><SPAN class=593211808-02092004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=593211808-02092004><FONT face=Arial color=#0000ff 
size=2>Apologies and regards...Lothar</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=OutlookMessageHeader lang=de dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Ursprüngliche Nachricht-----<BR><B>Von:</B> 
  [email-masked] [mailto:[email-masked]] <B>Im 
  Auftrag von </B>Reith, Lothar [HAHN:NGD:EXCH]<BR><B>Gesendet:</B> Donnerstag, 
  2. September 2004 10:08<BR><B>An:</B> 'Paul Funk'; 'Clint Chaplin'; 
  [email-masked]'<BR><B>Betreff:</B> AW: I-D 
  ACTION:draft-funk-radiusext-shared-secret-amp-01.txt<BR><BR></FONT></DIV>
  <P><FONT size=2>Paul,</FONT> </P>
  <P><FONT size=2>from what I understand you really seem to be talking about a 
  concept which one could perhaps refer to as "guessability".</FONT></P><BR>
  <P><FONT size=2>When applying this proposed term to one of your definitions, 
  (replacing some but not all occurances of "entropy" with "guessability") it 
  reads like this:</FONT></P>
  <P><FONT size=2>The<SPAN class=593211808-02092004><FONT face=Arial 
  color=#0000ff>&nbsp; cryptographic entropy&nbsp;</FONT></SPAN> of a collection 
  (of passwords) is only indirectly related to the difficulty of attack, which 
  can only be defined as the probability of success against&nbsp;<SPAN 
  class=593211808-02092004><FONT face=Arial color=#0000ff>&nbsp;a 
  &nbsp;</FONT></SPAN>number of tries. For example, a population&nbsp;<SPAN 
  class=593211808-02092004><FONT face=Arial color=#0000ff>&nbsp;of 
  users&nbsp;</FONT></SPAN>in which "swordfish" is used 50% of the time, but a 
  billion other passwords are equiprobable the other 50% of the time, has 
  entropy of about 15 bits, but a "guessability" of 50% (if the attacker knows 
  that the term swordfish is&nbsp;<SPAN class=593211808-02092004><FONT 
  face=Arial color=#0000ff>&nbsp;most&nbsp;</FONT></SPAN>popular for use as 
  password<SPAN class=593211808-02092004><FONT face=Arial color=#0000ff>&nbsp; 
  and therefore tries it first- this is&nbsp;an abstraction of the concept of 
  dictionary attack</FONT></SPAN>).</FONT></P>
  <P><FONT size=2>Note that it leaves the word entropy in&nbsp; it's 
  cryptographic meaning (by the way I did not know of the cryptographic 
  definition, only of the physical definition in the first place).</FONT></P>
  <P><FONT size=2>Best Regards, Lothar</FONT> </P><BR><BR>
  <P><FONT size=2>-----Ursprüngliche Nachricht-----</FONT> <BR><FONT size=2>Von: 
  [email-masked] [<A 
  href="mailto:[email-masked]">mailto:[email-masked]</A>] 
  Im Auftrag von Paul Funk</FONT> <BR><FONT size=2>Gesendet: Donnerstag, 2. 
  September 2004 03:14</FONT> <BR><FONT size=2>An: Clint Chaplin; 
  [email-masked]</FONT> <BR><FONT size=2>Betreff: Re: I-D 
  ACTION:draft-funk-radiusext-shared-secret-amp-01.txt</FONT> </P><BR>
  <P><FONT size=2>Clint,</FONT> </P>
  <P><FONT size=2>I don't disagree. I'll even add to your point by saying that 
  it makes no sense to talk about the entropy of a single password. Entropy 
  applies to populations; the entropy of a single item is 0. So you can't 
  properly say that the password "swordfish" has entropy of 20 bits. You could 
  say that within the collection of passwords actually used, "swordfish" is used 
  one in a million times, and therefore has probability of 2 ^ -20. But the 
  collection itself may have very low entropy; for example, if the only other 
  password ever used is "tuna", and it gets used 999,999 out of a million times. 
  So the probability of a password is not directly related to the difficulty of 
  attack -- in the case just described, you only have to try 2 
  passwords.</FONT></P>
  <P><FONT size=2>In addition, the entropy of a collection is only indirectly 
  related to the difficulty of attack, which can only be defined as the 
  probability spectrum of success against number of tries. For example, a 
  population in which "swordfish" is used 50% of the time, but a billion other 
  passwords are equiprobable the other 50% of the time, has entropy of about 15 
  bits, but an attack will succeed in one try 50% of the time.</FONT></P>
  <P><FONT size=2>So talking about entropy in this context necessarily 
  involves</FONT> <BR><FONT size=2>a kind of shorthand. I'm not entirely sure 
  how to talk about it with clarity and mathematical precision at the same time. 
  The dodge that I took was to define "effective entropy", and I really should 
  use that term consistently, as you point out. If you have a suggestion for how 
  to use comprehensible language to discuss these matters, let me 
  know.</FONT></P>
  <P><FONT size=2>Paul</FONT> </P>
  <P><FONT size=2>At 05:25 PM 9/1/2004 -0700, Clint Chaplin wrote:</FONT> 
  <BR><FONT size=2>&gt;I guess part of my problem is that the term "entropy" is 
  being used </FONT><BR><FONT size=2>&gt;here in two different incompatible but 
  related senses, sort of like </FONT><BR><FONT size=2>&gt;"pounds force" and 
  "pounds mass".&nbsp; Entropy in the cryptographic sense </FONT><BR><FONT 
  size=2>&gt;is the measure of the possible values an item may take on, and is 
  </FONT><BR><FONT size=2>&gt;measured in bits.&nbsp; Entropy in the 
  thermodynamic sense is the measure of </FONT><BR><FONT size=2>&gt;the disorder 
  in a system.</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;Talking 
  about "effective entropy" is a little bit like talking about </FONT><BR><FONT 
  size=2>&gt;"effective pounds mass" under acceleration, which makes my teeth 
  itch.</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;Clint (JOATMON) 
  Chaplin</FONT> <BR><FONT size=2>&gt;Wireless Security Advisor</FONT> <BR><FONT 
  size=2>&gt;Wireless Standards Lead</FONT> <BR><FONT size=2>&gt;</FONT> 
  <BR><FONT size=2>&gt; &gt;&gt;&gt; Bernard Aboba &lt;[email-masked]&gt; 
  8/31/04 21:34:35 &gt;&gt;&gt;</FONT> <BR><FONT size=2>&gt;Forwarded from Clint 
  Chaplin...</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;---------- 
  Forwarded message ----------</FONT> <BR><FONT size=2>&gt;Date: Tue, 31 Aug 
  2004 19:47:20 -0700</FONT> <BR><FONT size=2>&gt;From: Clint Chaplin 
  &lt;[email-masked]&gt;</FONT> <BR><FONT size=2>&gt;To: 
  [email-masked], [email-masked]</FONT> <BR><FONT 
  size=2>&gt;Subject: Re: I-D 
  ACTION:draft-funk-radiusext-shared-secret-amp-01.txt</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT size=2>&gt;Bernard: due to a snafu here at 
  Symbol, the radiusext email list is </FONT><BR><FONT size=2>&gt;silently 
  rejecting my posts to it; however, I can still receive the </FONT><BR><FONT 
  size=2>&gt;emails from it.&nbsp; Could you please forward this to the list for 
  me? </FONT><BR><FONT size=2>&gt;Thanks!</FONT> <BR><FONT size=2>&gt;</FONT> 
  <BR><FONT size=2>&gt;I still disagree with the use of the term "entropy" 
  within this I-D. As </FONT><BR><FONT size=2>&gt;a simplistic way of looking at 
  this, let's say that the input to this </FONT><BR><FONT size=2>&gt;algorithm 
  can only take on two distinct values, and also the salt can </FONT><BR><FONT 
  size=2>&gt;only take on two distinct values (these values may be expressed 
  using </FONT><BR><FONT size=2>&gt;many bits, but that won't change the 
  argument).&nbsp; Since the salt and the </FONT><BR><FONT size=2>&gt;input can 
  only have two distinct values, the entropy of each is only 1, </FONT><BR><FONT 
  size=2>&gt;and the two combined can only take on four distinct values, and 
  thus </FONT><BR><FONT size=2>&gt;have an entropy of 2.&nbsp; Putting these 
  four distinct valuse through the </FONT><BR><FONT size=2>&gt;amplification 
  process will still only yield an output with four </FONT><BR><FONT 
  size=2>&gt;distinct values (although these output values may also be expressed 
  </FONT><BR><FONT size=2>&gt;using many bits).&nbsp; No matter how many times 
  the algorithm is applied, </FONT><BR><FONT size=2>&gt;the output will still 
  only have a max of four distinct values, and a </FONT><BR><FONT size=2>&gt;max 
  entropy of 2.&nbsp; Hashing never adds true entropy, and if a collision 
  </FONT><BR><FONT size=2>&gt;occurs, can reduce entropy.</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT size=2>&gt;Yes, the term "effective entropy" can 
  be used, but that just confuses </FONT><BR><FONT size=2>&gt;the issue, I 
  feel.&nbsp; Plus, there are still places in the draft where </FONT><BR><FONT 
  size=2>&gt;"effective entropy" should be used for consistancy sake, and it is 
  not.</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;For instance, in 
  the abstract, the phrase "A dictionary attack against </FONT><BR><FONT 
  size=2>&gt;the resulting shared secret will be infeasible due to its high 
  </FONT><BR><FONT size=2>&gt;entropy." should state "A dictionary attack 
  against the resulting </FONT><BR><FONT size=2>&gt;shared secret will be 
  infeasible due to its high effective entropy."</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT size=2>&gt;In the introduction, the phrase "A 
  dictionary attack against the </FONT><BR><FONT size=2>&gt;resulting shared 
  secret will be infeasible due to its high entropy." </FONT><BR><FONT 
  size=2>&gt;should be "A dictionary attack against the resulting shared secret 
  will </FONT><BR><FONT size=2>&gt;be infeasible due to its high effective 
  entropy."</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;And so 
  on.</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;Clint (JOATMON) 
  Chaplin</FONT> <BR><FONT size=2>&gt;Wireless Security Advisor</FONT> <BR><FONT 
  size=2>&gt;Wireless Standards Lead</FONT> <BR><FONT size=2>&gt;</FONT> 
  <BR><FONT size=2>&gt; &gt;&gt;&gt; &lt;[email-masked]&gt; 8/27/04 
  12:42:15 &gt;&gt;&gt;</FONT> <BR><FONT size=2>&gt;A New Internet-Draft is 
  available from the on-line Internet-Drafts </FONT><BR><FONT 
  size=2>&gt;directories.</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Title&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : RADIUS 
  Shared Secret Security Amplification</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : P. Funk</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 
  draft-funk-radiusext-shared-secret-amp-01.txt</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Pages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 10</FONT> 
  <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 
  2004-8-27</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;This draft 
  describes how a mechanism defined in [PKCS-5] can be used</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp; to amplify the security of a RADIUS shared 
  secret; namely, that a</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; 
  precursor secret is hashed many times to produce an amplified </FONT><BR><FONT 
  size=2>&gt;shared</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp; secret for 
  use in RADIUS.</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;A URL 
  for this Internet-Draft is: </FONT><BR><FONT size=2>&gt;<A 
  href="http://www.ietf.org/internet-drafts/draft-funk-radiusext-shared-secret-" 
  target=_blank>http://www.ietf.org/internet-drafts/draft-funk-radiusext-shared-secret-</A></FONT> 
  <BR><FONT size=2>&gt;amp-01.txt</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT size=2>&gt;To remove yourself from the I-D 
  Announcement list, send a message to </FONT><BR><FONT 
  size=2>&gt;[email-masked] with the word unsubscribe in the body 
  of </FONT><BR><FONT size=2>&gt;the message. You can also visit 
  </FONT><BR><FONT size=2>&gt;<A 
  href="https://www1.ietf.org/mailman/listinfo/I-D-announce" 
  target=_blank>https://www1.ietf.org/mailman/listinfo/I-D-announce</A></FONT> 
  <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;to change your subscription 
  settings.</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;</FONT> 
  <BR><FONT size=2>&gt;Internet-Drafts are also available by anonymous FTP. 
  Login with the </FONT><BR><FONT size=2>&gt;username "anonymous" and a password 
  of your e-mail address. After </FONT><BR><FONT size=2>&gt;logging in, type "cd 
  internet-drafts" and then</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "get 
  draft-funk-radiusext-shared-secret-amp-01.txt".</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT size=2>&gt;A list of Internet-Drafts directories 
  can be found in </FONT><BR><FONT size=2>&gt;<A 
  href="http://www.ietf.org/shadow.html" 
  target=_blank>http://www.ietf.org/shadow.html</A> or </FONT><BR><FONT 
  size=2>&gt;<A href="ftp://ftp.ietf.org/ietf/1shadow-sites.txt" 
  target=_blank>ftp://ftp.ietf.org/ietf/1shadow-sites.txt</A></FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt;Internet-Drafts can also be obtained by e-mail.</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT size=2>&gt;Send a message to:</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  [email-masked].</FONT> <BR><FONT size=2>&gt;In the body type:</FONT> 
  <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "FILE 
  </FONT><BR><FONT 
  size=2>&gt;/internet-drafts/draft-funk-radiusext-shared-secret-amp-01.txt".</FONT> 
  <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt;NOTE:&nbsp;&nbsp; The mail 
  server at ietf.org can return the document in</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIME-encoded form 
  by using the "mpack" utility.&nbsp; To use this</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; feature, insert 
  the command "ENCODING mime" before the "FILE"</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; command.&nbsp; To 
  decode the response(s), you will need "munpack" or</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a MIME-compliant 
  mail reader.&nbsp; Different MIME-compliant mail </FONT><BR><FONT 
  size=2>&gt;readers</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; exhibit different 
  behavior, especially when dealing with</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "multipart" MIME 
  messages (i.e. documents which have been split</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; up into multiple 
  messages), so check your local documentation </FONT><BR><FONT 
  size=2>&gt;on</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; how to manipulate 
  these messages.</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT size=2>&gt;Below is the data which will enable a 
  MIME compliant mail reader </FONT><BR><FONT size=2>&gt;implementation to 
  automatically retrieve the ASCII version of the </FONT><BR><FONT 
  size=2>&gt;Internet-Draft.</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt;_______________________________________________________________________</FONT> 
  <BR><FONT size=2>&gt;_</FONT> <BR><FONT size=2>&gt;This email has been scanned 
  for computer viruses.</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt;_______________________________________________________________________</FONT> 
  <BR><FONT size=2>&gt;_</FONT> <BR><FONT size=2>&gt;This email has been scanned 
  for computer viruses.</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt;--</FONT> <BR><FONT size=2>&gt;to unsubscribe send a message to 
  [email-masked] with </FONT><BR><FONT size=2>&gt;the word 
  'unsubscribe' in a single line as the message text body.</FONT> <BR><FONT 
  size=2>&gt;archive: &lt;<A href="http://psg.com/lists/radiusext/" 
  target=_blank>http://psg.com/lists/radiusext/</A>&gt;</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt;_______________________________________________________________________</FONT> 
  <BR><FONT size=2>&gt;_</FONT> <BR><FONT size=2>&gt;This email has been scanned 
  for computer viruses.</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt;--</FONT> <BR><FONT size=2>&gt;to unsubscribe send a message to 
  [email-masked] with </FONT><BR><FONT size=2>&gt;the word 
  'unsubscribe' in a single line as the message text body.</FONT> <BR><FONT 
  size=2>&gt;archive: &lt;<A href="http://psg.com/lists/radiusext/" 
  target=_blank>http://psg.com/lists/radiusext/</A>&gt;</FONT> </P>
  <P><FONT size=2>Paul Funk</FONT> <BR><FONT size=2>Funk Software, Inc.</FONT> 
  <BR><FONT size=2>617 497-6339</FONT> <BR><FONT size=2>[email-masked]</FONT> 
  </P><BR>
  <P><FONT size=2>--</FONT> <BR><FONT size=2>to unsubscribe send a message to 
  [email-masked] with the word 'unsubscribe' in a single line as 
  the message text body.</FONT></P>
  <P><FONT size=2>archive: &lt;<A href="http://psg.com/lists/radiusext/" 
  target=_blank>http://psg.com/lists/radiusext/</A>&gt;</FONT> 
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C490C6.4CE482E8--

--
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, 02 Sep 2004 08:13:43 +0000
From: "Lothar Reith" <[email-masked]>
To: "'Paul Funk'" <[email-masked]>, "'Clint Chaplin'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: AW: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt
Date: Thu, 2 Sep 2004 10:08:28 +0200 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C490C4.07756882
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Paul,

from what I understand you really seem to be talking about a concept which
one could perhaps refer to as "guessability".

When applying this proposed term to one of your definitions, (replacing some
but not all occurances of "entropy" with "guessability") it reads like this:

The "guessability" of a collection (of passwords) is only indirectly related
to the difficulty of attack, which can only be defined as the probability
spectrum of success against number of tries. For example, a population in
which "swordfish" is used 50% of the time, but a billion other passwords are
equiprobable the other 50% of the time, has entropy of about 15 bits, but a
"guessability" of 50% (if the attacker knows that the term swordfish is
relatively popular for use as password).

Note that it leaves the word entropy in one of it's cryptographic meaning
(by the way I did not know of the cryptographic definition, only of the
physical definition in the first place).

Best Regards, Lothar

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im
Auftrag von Paul Funk
Gesendet: Donnerstag, 2. September 2004 03:14
An: Clint Chaplin; [email-masked]
Betreff: Re: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt

Clint,

I don't disagree. I'll even add to your point by saying that it makes no
sense to talk about the entropy of a single password. Entropy applies to
populations; the entropy of a single item is 0. So you can't properly say
that the password "swordfish" has entropy of 20 bits. You could say that
within the collection of passwords actually used, "swordfish" is used one in
a million times, and therefore has probability of 2 ^ -20. But the
collection itself may have very low entropy; for example, if the only other
password ever used is "tuna", and it gets used 999,999 out of a million
times. So the probability of a password is not directly related to the
difficulty of attack -- in the case just described, you only have to try 2
passwords.

In addition, the entropy of a collection is only indirectly related to the
difficulty of attack, which can only be defined as the probability spectrum
of success against number of tries. For example, a population in which
"swordfish" is used 50% of the time, but a billion other passwords are
equiprobable the other 50% of the time, has entropy of about 15 bits, but an
attack will succeed in one try 50% of the time.

So talking about entropy in this context necessarily involves
a kind of shorthand. I'm not entirely sure how to talk about it with clarity
and mathematical precision at the same time. The dodge that I took was to
define "effective entropy", and I really should use that term consistently,
as you point out. If you have a suggestion for how to use comprehensible
language to discuss these matters, let me know.

Paul

At 05:25 PM 9/1/2004 -0700, Clint Chaplin wrote:
>I guess part of my problem is that the term "entropy" is being used 
>here in two different incompatible but related senses, sort of like 
>"pounds force" and "pounds mass".  Entropy in the cryptographic sense 
>is the measure of the possible values an item may take on, and is 
>measured in bits.  Entropy in the thermodynamic sense is the measure of 
>the disorder in a system.
>
>Talking about "effective entropy" is a little bit like talking about 
>"effective pounds mass" under acceleration, which makes my teeth itch.
>
>Clint (JOATMON) Chaplin
>Wireless Security Advisor
>Wireless Standards Lead
>
> >>> Bernard Aboba <[email-masked]> 8/31/04 21:34:35 >>>
>Forwarded from Clint Chaplin...
>
>---------- Forwarded message ----------
>Date: Tue, 31 Aug 2004 19:47:20 -0700
>From: Clint Chaplin <[email-masked]>
>To: [email-masked], [email-masked]
>Subject: Re: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt
>
>Bernard: due to a snafu here at Symbol, the radiusext email list is 
>silently rejecting my posts to it; however, I can still receive the 
>emails from it.  Could you please forward this to the list for me? 
>Thanks!
>
>I still disagree with the use of the term "entropy" within this I-D. As 
>a simplistic way of looking at this, let's say that the input to this 
>algorithm can only take on two distinct values, and also the salt can 
>only take on two distinct values (these values may be expressed using 
>many bits, but that won't change the argument).  Since the salt and the 
>input can only have two distinct values, the entropy of each is only 1, 
>and the two combined can only take on four distinct values, and thus 
>have an entropy of 2.  Putting these four distinct valuse through the 
>amplification process will still only yield an output with four 
>distinct values (although these output values may also be expressed 
>using many bits).  No matter how many times the algorithm is applied, 
>the output will still only have a max of four distinct values, and a 
>max entropy of 2.  Hashing never adds true entropy, and if a collision 
>occurs, can reduce entropy.
>
>Yes, the term "effective entropy" can be used, but that just confuses 
>the issue, I feel.  Plus, there are still places in the draft where 
>"effective entropy" should be used for consistancy sake, and it is not.
>
>For instance, in the abstract, the phrase "A dictionary attack against 
>the resulting shared secret will be infeasible due to its high 
>entropy." should state "A dictionary attack against the resulting 
>shared secret will be infeasible due to its high effective entropy."
>
>In the introduction, the phrase "A dictionary attack against the 
>resulting shared secret will be infeasible due to its high entropy." 
>should be "A dictionary attack against the resulting shared secret will 
>be infeasible due to its high effective entropy."
>
>And so on.
>
>Clint (JOATMON) Chaplin
>Wireless Security Advisor
>Wireless Standards Lead
>
> >>> <[email-masked]> 8/27/04 12:42:15 >>>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : RADIUS Shared Secret Security Amplification
>         Author(s)       : P. Funk
>         Filename        : draft-funk-radiusext-shared-secret-amp-01.txt
>         Pages           : 10
>         Date            : 2004-8-27
>
>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 URL for this Internet-Draft is: 
>http://www.ietf.org/internet-drafts/draft-funk-radiusext-shared-secret-
>amp-01.txt
>
>
>To remove yourself from the I-D Announcement list, send a message to 
>[email-masked] with the word unsubscribe in the body of 
>the message. You can also visit 
>https://www1.ietf.org/mailman/listinfo/I-D-announce
>
>to change your subscription settings.
>
>
>Internet-Drafts are also available by anonymous FTP. Login with the 
>username "anonymous" and a password of your e-mail address. After 
>logging in, type "cd internet-drafts" and then
>         "get draft-funk-radiusext-shared-secret-amp-01.txt".
>
>A list of Internet-Drafts directories can be found in 
>http://www.ietf.org/shadow.html or 
>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [email-masked].
>In the body type:
>         "FILE 
>/internet-drafts/draft-funk-radiusext-shared-secret-amp-01.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail 
>readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation 
>on
>         how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader 
>implementation to automatically retrieve the ASCII version of the 
>Internet-Draft.
>
>
>_______________________________________________________________________
>_
>This email has been scanned for computer viruses.
>
>_______________________________________________________________________
>_
>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/>
>
>_______________________________________________________________________
>_
>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/>

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/>

------_=_NextPart_001_01C490C4.07756882
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2656.31">
<TITLE>AW: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Paul,</FONT>
</P>

<P><FONT SIZE=2>from what I understand you really seem to be talking about a concept which one could perhaps refer to as &quot;guessability&quot;.</FONT></P>
<BR>

<P><FONT SIZE=2>When applying this proposed term to one of your definitions, (replacing some but not all occurances of &quot;entropy&quot; with &quot;guessability&quot;) it reads like this:</FONT></P>

<P><FONT SIZE=2>The &quot;guessability&quot; of a collection (of passwords) is only indirectly related to the difficulty of attack, which can only be defined as the probability spectrum of success against number of tries. For example, a population in which &quot;swordfish&quot; is used 50% of the time, but a billion other passwords are equiprobable the other 50% of the time, has entropy of about 15 bits, but a &quot;guessability&quot; of 50% (if the attacker knows that the term swordfish is relatively popular for use as password).</FONT></P>

<P><FONT SIZE=2>Note that it leaves the word entropy in one of it's cryptographic meaning (by the way I did not know of the cryptographic definition, only of the physical definition in the first place).</FONT></P>

<P><FONT SIZE=2>Best Regards, Lothar</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=2>-----Ursprüngliche Nachricht-----</FONT>
<BR><FONT SIZE=2>Von: [email-masked] [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>] Im Auftrag von Paul Funk</FONT>
<BR><FONT SIZE=2>Gesendet: Donnerstag, 2. September 2004 03:14</FONT>
<BR><FONT SIZE=2>An: Clint Chaplin; [email-masked]</FONT>
<BR><FONT SIZE=2>Betreff: Re: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt</FONT>
</P>
<BR>

<P><FONT SIZE=2>Clint,</FONT>
</P>

<P><FONT SIZE=2>I don't disagree. I'll even add to your point by saying that it makes no sense to talk about the entropy of a single password. Entropy applies to populations; the entropy of a single item is 0. So you can't properly say that the password &quot;swordfish&quot; has entropy of 20 bits. You could say that within the collection of passwords actually used, &quot;swordfish&quot; is used one in a million times, and therefore has probability of 2 ^ -20. But the collection itself may have very low entropy; for example, if the only other password ever used is &quot;tuna&quot;, and it gets used 999,999 out of a million times. So the probability of a password is not directly related to the difficulty of attack -- in the case just described, you only have to try 2 passwords.</FONT></P>

<P><FONT SIZE=2>In addition, the entropy of a collection is only indirectly related to the difficulty of attack, which can only be defined as the probability spectrum of success against number of tries. For example, a population in which &quot;swordfish&quot; is used 50% of the time, but a billion other passwords are equiprobable the other 50% of the time, has entropy of about 15 bits, but an attack will succeed in one try 50% of the time.</FONT></P>

<P><FONT SIZE=2>So talking about entropy in this context necessarily involves</FONT>
<BR><FONT SIZE=2>a kind of shorthand. I'm not entirely sure how to talk about it with clarity and mathematical precision at the same time. The dodge that I took was to define &quot;effective entropy&quot;, and I really should use that term consistently, as you point out. If you have a suggestion for how to use comprehensible language to discuss these matters, let me know.</FONT></P>

<P><FONT SIZE=2>Paul</FONT>
</P>

<P><FONT SIZE=2>At 05:25 PM 9/1/2004 -0700, Clint Chaplin wrote:</FONT>
<BR><FONT SIZE=2>&gt;I guess part of my problem is that the term &quot;entropy&quot; is being used </FONT>
<BR><FONT SIZE=2>&gt;here in two different incompatible but related senses, sort of like </FONT>
<BR><FONT SIZE=2>&gt;&quot;pounds force&quot; and &quot;pounds mass&quot;.&nbsp; Entropy in the cryptographic sense </FONT>
<BR><FONT SIZE=2>&gt;is the measure of the possible values an item may take on, and is </FONT>
<BR><FONT SIZE=2>&gt;measured in bits.&nbsp; Entropy in the thermodynamic sense is the measure of </FONT>
<BR><FONT SIZE=2>&gt;the disorder in a system.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Talking about &quot;effective entropy&quot; is a little bit like talking about </FONT>
<BR><FONT SIZE=2>&gt;&quot;effective pounds mass&quot; under acceleration, which makes my teeth itch.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Clint (JOATMON) Chaplin</FONT>
<BR><FONT SIZE=2>&gt;Wireless Security Advisor</FONT>
<BR><FONT SIZE=2>&gt;Wireless Standards Lead</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt;&gt; Bernard Aboba &lt;[email-masked]&gt; 8/31/04 21:34:35 &gt;&gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt;Forwarded from Clint Chaplin...</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;---------- Forwarded message ----------</FONT>
<BR><FONT SIZE=2>&gt;Date: Tue, 31 Aug 2004 19:47:20 -0700</FONT>
<BR><FONT SIZE=2>&gt;From: Clint Chaplin &lt;[email-masked]&gt;</FONT>
<BR><FONT SIZE=2>&gt;To: [email-masked], [email-masked]</FONT>
<BR><FONT SIZE=2>&gt;Subject: Re: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Bernard: due to a snafu here at Symbol, the radiusext email list is </FONT>
<BR><FONT SIZE=2>&gt;silently rejecting my posts to it; however, I can still receive the </FONT>
<BR><FONT SIZE=2>&gt;emails from it.&nbsp; Could you please forward this to the list for me? </FONT>
<BR><FONT SIZE=2>&gt;Thanks!</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;I still disagree with the use of the term &quot;entropy&quot; within this I-D. As </FONT>
<BR><FONT SIZE=2>&gt;a simplistic way of looking at this, let's say that the input to this </FONT>
<BR><FONT SIZE=2>&gt;algorithm can only take on two distinct values, and also the salt can </FONT>
<BR><FONT SIZE=2>&gt;only take on two distinct values (these values may be expressed using </FONT>
<BR><FONT SIZE=2>&gt;many bits, but that won't change the argument).&nbsp; Since the salt and the </FONT>
<BR><FONT SIZE=2>&gt;input can only have two distinct values, the entropy of each is only 1, </FONT>
<BR><FONT SIZE=2>&gt;and the two combined can only take on four distinct values, and thus </FONT>
<BR><FONT SIZE=2>&gt;have an entropy of 2.&nbsp; Putting these four distinct valuse through the </FONT>
<BR><FONT SIZE=2>&gt;amplification process will still only yield an output with four </FONT>
<BR><FONT SIZE=2>&gt;distinct values (although these output values may also be expressed </FONT>
<BR><FONT SIZE=2>&gt;using many bits).&nbsp; No matter how many times the algorithm is applied, </FONT>
<BR><FONT SIZE=2>&gt;the output will still only have a max of four distinct values, and a </FONT>
<BR><FONT SIZE=2>&gt;max entropy of 2.&nbsp; Hashing never adds true entropy, and if a collision </FONT>
<BR><FONT SIZE=2>&gt;occurs, can reduce entropy.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Yes, the term &quot;effective entropy&quot; can be used, but that just confuses </FONT>
<BR><FONT SIZE=2>&gt;the issue, I feel.&nbsp; Plus, there are still places in the draft where </FONT>
<BR><FONT SIZE=2>&gt;&quot;effective entropy&quot; should be used for consistancy sake, and it is not.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;For instance, in the abstract, the phrase &quot;A dictionary attack against </FONT>
<BR><FONT SIZE=2>&gt;the resulting shared secret will be infeasible due to its high </FONT>
<BR><FONT SIZE=2>&gt;entropy.&quot; should state &quot;A dictionary attack against the resulting </FONT>
<BR><FONT SIZE=2>&gt;shared secret will be infeasible due to its high effective entropy.&quot;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;In the introduction, the phrase &quot;A dictionary attack against the </FONT>
<BR><FONT SIZE=2>&gt;resulting shared secret will be infeasible due to its high entropy.&quot; </FONT>
<BR><FONT SIZE=2>&gt;should be &quot;A dictionary attack against the resulting shared secret will </FONT>
<BR><FONT SIZE=2>&gt;be infeasible due to its high effective entropy.&quot;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;And so on.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Clint (JOATMON) Chaplin</FONT>
<BR><FONT SIZE=2>&gt;Wireless Security Advisor</FONT>
<BR><FONT SIZE=2>&gt;Wireless Standards Lead</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt;&gt; &lt;[email-masked]&gt; 8/27/04 12:42:15 &gt;&gt;&gt;</FONT>
<BR><FONT SIZE=2>&gt;A New Internet-Draft is available from the on-line Internet-Drafts </FONT>
<BR><FONT SIZE=2>&gt;directories.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Title&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : RADIUS Shared Secret Security Amplification</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : P. Funk</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : draft-funk-radiusext-shared-secret-amp-01.txt</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Pages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 10</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 2004-8-27</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;This draft describes how a mechanism defined in [PKCS-5] can be used</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; to amplify the security of a RADIUS shared secret; namely, that a</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; precursor secret is hashed many times to produce an amplified </FONT>
<BR><FONT SIZE=2>&gt;shared</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; secret for use in RADIUS.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;A URL for this Internet-Draft is: </FONT>
<BR><FONT SIZE=2>&gt;<A HREF="http://www.ietf.org/internet-drafts/draft-funk-radiusext-shared-secret-" TARGET="_blank">http://www.ietf.org/internet-drafts/draft-funk-radiusext-shared-secret-</A></FONT>
<BR><FONT SIZE=2>&gt;amp-01.txt</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;To remove yourself from the I-D Announcement list, send a message to </FONT>
<BR><FONT SIZE=2>&gt;[email-masked] with the word unsubscribe in the body of </FONT>
<BR><FONT SIZE=2>&gt;the message. You can also visit </FONT>
<BR><FONT SIZE=2>&gt;<A HREF="https://www1.ietf.org/mailman/listinfo/I-D-announce" TARGET="_blank">https://www1.ietf.org/mailman/listinfo/I-D-announce</A></FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;to change your subscription settings.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Internet-Drafts are also available by anonymous FTP. Login with the </FONT>
<BR><FONT SIZE=2>&gt;username &quot;anonymous&quot; and a password of your e-mail address. After </FONT>
<BR><FONT SIZE=2>&gt;logging in, type &quot;cd internet-drafts&quot; and then</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;get draft-funk-radiusext-shared-secret-amp-01.txt&quot;.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;A list of Internet-Drafts directories can be found in </FONT>
<BR><FONT SIZE=2>&gt;<A HREF="http://www.ietf.org/shadow.html" TARGET="_blank">http://www.ietf.org/shadow.html</A> or </FONT>
<BR><FONT SIZE=2>&gt;<A HREF="ftp://ftp.ietf.org/ietf/1shadow-sites.txt" TARGET="_blank">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</A></FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Internet-Drafts can also be obtained by e-mail.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Send a message to:</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [email-masked].</FONT>
<BR><FONT SIZE=2>&gt;In the body type:</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;FILE </FONT>
<BR><FONT SIZE=2>&gt;/internet-drafts/draft-funk-radiusext-shared-secret-amp-01.txt&quot;.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;NOTE:&nbsp;&nbsp; The mail server at ietf.org can return the document in</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIME-encoded form by using the &quot;mpack&quot; utility.&nbsp; To use this</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; feature, insert the command &quot;ENCODING mime&quot; before the &quot;FILE&quot;</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; command.&nbsp; To decode the response(s), you will need &quot;munpack&quot; or</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a MIME-compliant mail reader.&nbsp; Different MIME-compliant mail </FONT>
<BR><FONT SIZE=2>&gt;readers</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; exhibit different behavior, especially when dealing with</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;multipart&quot; MIME messages (i.e. documents which have been split</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; up into multiple messages), so check your local documentation </FONT>
<BR><FONT SIZE=2>&gt;on</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; how to manipulate these messages.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Below is the data which will enable a MIME compliant mail reader </FONT>
<BR><FONT SIZE=2>&gt;implementation to automatically retrieve the ASCII version of the </FONT>
<BR><FONT SIZE=2>&gt;Internet-Draft.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;_______________________________________________________________________</FONT>
<BR><FONT SIZE=2>&gt;_</FONT>
<BR><FONT SIZE=2>&gt;This email has been scanned for computer viruses.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;_______________________________________________________________________</FONT>
<BR><FONT SIZE=2>&gt;_</FONT>
<BR><FONT SIZE=2>&gt;This email has been scanned for computer viruses.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;--</FONT>
<BR><FONT SIZE=2>&gt;to unsubscribe send a message to [email-masked] with </FONT>
<BR><FONT SIZE=2>&gt;the word 'unsubscribe' in a single line as the message text body.</FONT>
<BR><FONT SIZE=2>&gt;archive: &lt;<A HREF="http://psg.com/lists/radiusext/" TARGET="_blank">http://psg.com/lists/radiusext/</A>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;_______________________________________________________________________</FONT>
<BR><FONT SIZE=2>&gt;_</FONT>
<BR><FONT SIZE=2>&gt;This email has been scanned for computer viruses.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;--</FONT>
<BR><FONT SIZE=2>&gt;to unsubscribe send a message to [email-masked] with </FONT>
<BR><FONT SIZE=2>&gt;the word 'unsubscribe' in a single line as the message text body.</FONT>
<BR><FONT SIZE=2>&gt;archive: &lt;<A HREF="http://psg.com/lists/radiusext/" TARGET="_blank">http://psg.com/lists/radiusext/</A>&gt;</FONT>
</P>

<P><FONT SIZE=2>Paul Funk</FONT>
<BR><FONT SIZE=2>Funk Software, Inc.</FONT>
<BR><FONT SIZE=2>617 497-6339</FONT>
<BR><FONT SIZE=2>[email-masked]</FONT>
</P>
<BR>

<P><FONT SIZE=2>--</FONT>
<BR><FONT SIZE=2>to unsubscribe send a message to [email-masked] with the word 'unsubscribe' in a single line as the message text body.</FONT></P>

<P><FONT SIZE=2>archive: &lt;<A HREF="http://psg.com/lists/radiusext/" TARGET="_blank">http://psg.com/lists/radiusext/</A>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C490C4.07756882--

--
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, 02 Sep 2004 02:46:14 +0000
From: "Joseph Salowey" <[email-masked]>
To: "'Paul Funk'" <[email-masked]>, "'Clint Chaplin'" <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt
Date: Wed, 1 Sep 2004 19:45:33 -0700

[email-masked] wrote:
> Clint,
> 
> I don't disagree. I'll even add to your point by saying that
> it makes no sense to talk about the entropy of a single
> password. Entropy applies to populations; the entropy of a
> single item is 0. So you can't properly say that the password
> "swordfish" has entropy of 20 bits. You could say that within
> the collection of passwords actually used, "swordfish" is
> used one in a million times, and therefore has probability of
> 2 ^ -20. But the collection itself may have very low entropy;
> for example, if the only other password ever used is "tuna",
> and it gets used 999,999 out of a million times. So the
> probability of a password is not directly related to the
> difficulty of attack -- in the case just described, you only have to
> try 2 passwords. 
> 
> In addition, the entropy of a collection is only indirectly
> related to the difficulty of attack, which can only be
> defined as the probability spectrum of success against number
> of tries. For example, a population in which "swordfish" is
> used 50% of the time, but a billion other passwords are
> equiprobable the other 50% of the time, has entropy of about
> 15 bits, but an attack will succeed in one try 50% of the time.
> 
> So talking about entropy in this context necessarily involves
> a kind of shorthand. I'm not entirely sure how to talk about
> it with clarity and mathematical precision at the same time.
> The dodge that I took was to define "effective entropy", and
> I really should use that term consistently, as you point out.
> If you have a suggestion for how to use comprehensible
> language to discuss these matters, let me know.
>

[Joe] It might be better to talk in terms of computational cost.  

> Paul
> 
> At 05:25 PM 9/1/2004 -0700, Clint Chaplin wrote:
>> I guess part of my problem is that the term "entropy" is being used
>> here in two different incompatible but related senses, sort of like
>> "pounds force" and "pounds mass".  Entropy in the cryptographic sense
>> is the measure of the possible values an item may take on, and is
>> measured in bits.  Entropy in the thermodynamic sense is the measure
>> of the disorder in a system. 
>> 
>> Talking about "effective entropy" is a little bit like talking about
>> "effective pounds mass" under acceleration, which makes my teeth
>> itch. 
>> 
>> Clint (JOATMON) Chaplin
>> Wireless Security Advisor
>> Wireless Standards Lead
>> 
>>>>> Bernard Aboba <[email-masked]> 8/31/04 21:34:35 >>>
>> Forwarded from Clint Chaplin...
>> 
>> ---------- Forwarded message ----------
>> Date: Tue, 31 Aug 2004 19:47:20 -0700
>> From: Clint Chaplin <[email-masked]>
>> To: [email-masked], [email-masked]
>> Subject: Re: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt
>> 
>> Bernard: due to a snafu here at Symbol, the radiusext email list is
>> silently rejecting my posts to it; however, I can still receive the
>> emails from it.  Could you please forward this to the list for me?
>> Thanks! 
>> 
>> I still disagree with the use of the term "entropy" within this I-D.
>> As a simplistic way of looking at this, let's say that the input to
>> this algorithm can only take on two distinct values, and also the
>> salt can only take on two distinct values (these values may be
>> expressed using many bits, but that won't change the argument). 
>> Since the salt and the input can only have two distinct values, the
>> entropy of each is only 1, and the two combined can only take on
>> four distinct values, and thus have an entropy of 2.  Putting these
>> four distinct valuse through the amplification process will still
>> only yield an output with four distinct values (although these
>> output values may also be expressed using many bits).  No matter how
>> many times the algorithm is applied, the output will still only have
>> a max of four distinct values, and a max entropy of 2.  Hashing
>> never adds true entropy, and if a collision occurs, can reduce
>> entropy.  
>> 
>> Yes, the term "effective entropy" can be used, but that just confuses
>> the issue, I feel.  Plus, there are still places in the draft where
>> "effective entropy" should be used for consistancy sake, and it is
>> not. 
>> 
>> For instance, in the abstract, the phrase "A dictionary attack
>> against the resulting shared secret will be infeasible due to its
>> high entropy." should state "A dictionary attack against the
>> resulting shared secret will be infeasible due to its high effective
>> entropy." 
>> 
>> In the introduction, the phrase "A dictionary attack against the
>> resulting shared secret will be infeasible due to its high entropy."
>> should be "A dictionary attack against the resulting shared secret
>> will be infeasible due to its high effective entropy."
>> 
>> And so on.
>> 
>> Clint (JOATMON) Chaplin
>> Wireless Security Advisor
>> Wireless Standards Lead
>> 
>>>>> <[email-masked]> 8/27/04 12:42:15 >>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. 
>> 
>> 
>>         Title           : RADIUS Shared Secret Security Amplification
>>         Author(s)       : P. Funk
>>         Filename        :
> draft-funk-radiusext-shared-secret-amp-01.txt
>>         Pages           : 10
>>         Date            : 2004-8-27
>> 
>> 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 URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-funk-radiusext-shar
>> ed-secret- amp-01.txt 
>> 
>> 
>> To remove yourself from the I-D Announcement list, send a message to
>> [email-masked] with the word unsubscribe in the body
>> of the message. You can also visit
>> https://www1.ietf.org/mailman/listinfo/I-D-announce
>> 
>> to change your subscription settings.
>> 
>> 
>> Internet-Drafts are also available by anonymous FTP. Login with the
>> username "anonymous" and a password of your e-mail address. After
>> logging in, type "cd internet-drafts" and then
>>         "get draft-funk-radiusext-shared-secret-amp-01.txt".
>> 
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> 
>> 
>> Internet-Drafts can also be obtained by e-mail.
>> 
>> Send a message to:
>>         [email-masked].
>> In the body type:
>>         "FILE
>> /internet-drafts/draft-funk-radiusext-shared-secret-amp-01.txt".
>> 
>> NOTE:   The mail server at ietf.org can return the document in
>>         MIME-encoded form by using the "mpack" utility.  To use this
>>         feature, insert the command "ENCODING mime" before the "FILE"
>>         command.  To decode the response(s), you will need "munpack"
>>         or a MIME-compliant mail reader.  Different MIME-compliant
>>         mail readers exhibit different behavior, especially when
>>         dealing with "multipart" MIME messages (i.e. documents which
>>         have been split up into multiple messages), so check your
>>         local documentation on how to manipulate these messages.
>> 
>> 
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft. 
>> 
>> 
>> _____________________________________________________________
>> __________ _ This email has been scanned for computer viruses.
>> 
>> _____________________________________________________________
>> __________ _ 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/>
>> 
>> _____________________________________________________________
>> __________ _ 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/>
> 
> 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, 02 Sep 2004 01:14:46 +0000
Date: Wed, 01 Sep 2004 21:14:26 -0400
To: "Clint Chaplin" <[email-masked]>,<[email-masked]>
From: Paul Funk <[email-masked]>
Subject: Re: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt

Clint,

I don't disagree. I'll even add to your point by saying that it makes
no sense to talk about the entropy of a single password. Entropy
applies to populations; the entropy of a single item is 0. So you
can't properly say that the password "swordfish" has entropy of
20 bits. You could say that within the collection of passwords
actually used, "swordfish" is used one in a million times, and
therefore has probability of 2 ^ -20. But the collection itself may
have very low entropy; for example, if the only other password
ever used is "tuna", and it gets used 999,999 out of a million
times. So the probability of a password is not directly related
to the difficulty of attack -- in the case just described, you only
have to try 2 passwords.

In addition, the entropy of a collection is only indirectly related
to the difficulty of attack, which can only be defined as the
probability spectrum of success against number of tries. For
example, a population in which "swordfish" is used 50% of the
time, but a billion other passwords are equiprobable the other
50% of the time, has entropy of about 15 bits, but an attack
will succeed in one try 50% of the time.

So talking about entropy in this context necessarily involves
a kind of shorthand. I'm not entirely sure how to talk about it
with clarity and mathematical precision at the same time. The
dodge that I took was to define "effective entropy", and I really
should use that term consistently, as you point out. If you have
a suggestion for how to use comprehensible language to discuss
these matters, let me know.

Paul

At 05:25 PM 9/1/2004 -0700, Clint Chaplin wrote:
>I guess part of my problem is that the term "entropy" is being used here
>in two different incompatible but related senses, sort of like "pounds
>force" and "pounds mass".  Entropy in the cryptographic sense is the
>measure of the possible values an item may take on, and is measured in
>bits.  Entropy in the thermodynamic sense is the measure of the disorder
>in a system.
>
>Talking about "effective entropy" is a little bit like talking about
>"effective pounds mass" under acceleration, which makes my teeth itch.
>
>Clint (JOATMON) Chaplin
>Wireless Security Advisor
>Wireless Standards Lead
>
> >>> Bernard Aboba <[email-masked]> 8/31/04 21:34:35 >>>
>Forwarded from Clint Chaplin...
>
>---------- Forwarded message ----------
>Date: Tue, 31 Aug 2004 19:47:20 -0700
>From: Clint Chaplin <[email-masked]>
>To: [email-masked], [email-masked]
>Subject: Re: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt
>
>Bernard: due to a snafu here at Symbol, the radiusext email list is
>silently rejecting my posts to it; however, I can still receive the
>emails from it.  Could you please forward this to the list for me?
>Thanks!
>
>I still disagree with the use of the term "entropy" within this I-D.
>As a simplistic way of looking at this, let's say that the input to this
>algorithm can only take on two distinct values, and also the salt can
>only take on two distinct values (these values may be expressed using
>many bits, but that won't change the argument).  Since the salt and the
>input can only have two distinct values, the entropy of each is only 1,
>and the two combined can only take on four distinct values, and thus
>have an entropy of 2.  Putting these four distinct valuse through the
>amplification process will still only yield an output with four distinct
>values (although these output values may also be expressed using many
>bits).  No matter how many times the algorithm is applied, the output
>will still only have a max of four distinct values, and a max entropy of
>2.  Hashing never adds true entropy, and if a collision occurs, can
>reduce entropy.
>
>Yes, the term "effective entropy" can be used, but that just confuses
>the issue, I feel.  Plus, there are still places in the draft where
>"effective entropy" should be used for consistancy sake, and it is not.
>
>For instance, in the abstract, the phrase "A dictionary attack against
>the resulting shared secret will be infeasible due to its high entropy."
>should state "A dictionary attack against the resulting shared secret
>will be infeasible due to its high effective entropy."
>
>In the introduction, the phrase "A dictionary attack against the
>resulting shared secret will be infeasible due to its high entropy."
>should be "A dictionary attack against the resulting shared secret will
>be infeasible due to its high effective entropy."
>
>And so on.
>
>Clint (JOATMON) Chaplin
>Wireless Security Advisor
>Wireless Standards Lead
>
> >>> <[email-masked]> 8/27/04 12:42:15 >>>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>
>         Title           : RADIUS Shared Secret Security Amplification
>         Author(s)       : P. Funk
>         Filename        : draft-funk-radiusext-shared-secret-amp-01.txt
>         Pages           : 10
>         Date            : 2004-8-27
>
>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 URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-funk-radiusext-shared-secret-amp-01.txt
>
>
>To remove yourself from the I-D Announcement list, send a message to
>[email-masked] with the word unsubscribe in the body of
>the message.
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>
>to change your subscription settings.
>
>
>Internet-Drafts are also available by anonymous FTP. Login with the
>username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-funk-radiusext-shared-secret-amp-01.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [email-masked].
>In the body type:
>         "FILE
>/internet-drafts/draft-funk-radiusext-shared-secret-amp-01.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail
>readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation
>on
>         how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>
>________________________________________________________________________
>This email has been scanned for computer viruses.
>
>________________________________________________________________________
>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/>
>
>________________________________________________________________________
>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/>

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, 02 Sep 2004 00:26:22 +0000
Date: Wed, 01 Sep 2004 17:25:06 -0700
From: "Clint Chaplin" <[email-masked]>
To: <[email-masked]>
Subject: Re: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt

I guess part of my problem is that the term "entropy" is being used here
in two different incompatible but related senses, sort of like "pounds
force" and "pounds mass".  Entropy in the cryptographic sense is the
measure of the possible values an item may take on, and is measured in
bits.  Entropy in the thermodynamic sense is the measure of the disorder
in a system.

Talking about "effective entropy" is a little bit like talking about
"effective pounds mass" under acceleration, which makes my teeth itch.

Clint (JOATMON) Chaplin
Wireless Security Advisor
Wireless Standards Lead

>>> Bernard Aboba <[email-masked]> 8/31/04 21:34:35 >>>
Forwarded from Clint Chaplin...

---------- Forwarded message ----------
Date: Tue, 31 Aug 2004 19:47:20 -0700
From: Clint Chaplin <[email-masked]>
To: [email-masked], [email-masked] 
Subject: Re: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt

Bernard: due to a snafu here at Symbol, the radiusext email list is
silently rejecting my posts to it; however, I can still receive the
emails from it.  Could you please forward this to the list for me? 
Thanks!

I still disagree with the use of the term "entropy" within this I-D. 
As a simplistic way of looking at this, let's say that the input to this
algorithm can only take on two distinct values, and also the salt can
only take on two distinct values (these values may be expressed using
many bits, but that won't change the argument).  Since the salt and the
input can only have two distinct values, the entropy of each is only 1,
and the two combined can only take on four distinct values, and thus
have an entropy of 2.  Putting these four distinct valuse through the
amplification process will still only yield an output with four distinct
values (although these output values may also be expressed using many
bits).  No matter how many times the algorithm is applied, the output
will still only have a max of four distinct values, and a max entropy of
2.  Hashing never adds true entropy, and if a collision occurs, can
reduce entropy.

Yes, the term "effective entropy" can be used, but that just confuses
the issue, I feel.  Plus, there are still places in the draft where
"effective entropy" should be used for consistancy sake, and it is not.

For instance, in the abstract, the phrase "A dictionary attack against
the resulting shared secret will be infeasible due to its high entropy."
should state "A dictionary attack against the resulting shared secret
will be infeasible due to its high effective entropy."

In the introduction, the phrase "A dictionary attack against the
resulting shared secret will be infeasible due to its high entropy."
should be "A dictionary attack against the resulting shared secret will
be infeasible due to its high effective entropy."

And so on.

Clint (JOATMON) Chaplin
Wireless Security Advisor
Wireless Standards Lead

>>> <[email-masked]> 8/27/04 12:42:15 >>>
A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: RADIUS Shared Secret Security Amplification
	Author(s)	: P. Funk
	Filename	: draft-funk-radiusext-shared-secret-amp-01.txt
	Pages		: 10
	Date		: 2004-8-27

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 URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-funk-radiusext-shared-secret-amp-01.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce

to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-funk-radiusext-shared-secret-amp-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt 

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE
/internet-drafts/draft-funk-radiusext-shared-secret-amp-01.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation
on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

________________________________________________________________________
This email has been scanned for computer viruses.

________________________________________________________________________
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/>

________________________________________________________________________
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, 01 Sep 2004 04:41:59 +0000
Date: Tue, 31 Aug 2004 21:34:35 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt

Forwarded from Clint Chaplin...

---------- Forwarded message ----------
Date: Tue, 31 Aug 2004 19:47:20 -0700
From: Clint Chaplin <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt

Bernard: due to a snafu here at Symbol, the radiusext email list is silently rejecting my posts to it; however, I can still receive the emails from it.  Could you please forward this to the list for me?  Thanks!

I still disagree with the use of the term "entropy" within this I-D.  As a simplistic way of looking at this, let's say that the input to this algorithm can only take on two distinct values, and also the salt can only take on two distinct values (these values may be expressed using many bits, but that won't change the argument).  Since the salt and the input can only have two distinct values, the entropy of each is only 1, and the two combined can only take on four distinct values, and thus have an entropy of 2.  Putting these four distinct valuse through the amplification process will still only yield an output with four distinct values (although these output values may also be expressed using many bits).  No matter how many times the algorithm is applied, the output will still only have a max of four distinct values, and a max entropy of 2.  Hashing never adds true entropy, and if a collision occurs, can reduce entropy.

Yes, the term "effective entropy" can be used, but that just confuses the issue, I feel.  Plus, there are still places in the draft where "effective entropy" should be used for consistancy sake, and it is not.

For instance, in the abstract, the phrase "A dictionary attack against the resulting shared secret will be infeasible due to its high entropy." should state "A dictionary attack against the resulting shared secret will be infeasible due to its high effective entropy."

In the introduction, the phrase "A dictionary attack against the resulting shared secret will be infeasible due to its high entropy." should be "A dictionary attack against the resulting shared secret will be infeasible due to its high effective entropy."

And so on.

Clint (JOATMON) Chaplin
Wireless Security Advisor
Wireless Standards Lead

>>> <[email-masked]> 8/27/04 12:42:15 >>>
A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: RADIUS Shared Secret Security Amplification
	Author(s)	: P. Funk
	Filename	: draft-funk-radiusext-shared-secret-amp-01.txt
	Pages		: 10
	Date		: 2004-8-27

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 URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-funk-radiusext-shared-secret-amp-01.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-funk-radiusext-shared-secret-amp-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-funk-radiusext-shared-secret-amp-01.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

________________________________________________________________________
This email has been scanned for computer viruses.

________________________________________________________________________
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/>