Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 27 Sep 2004 22:31:13 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: -01 version of Chargeable User Identity Date: Mon, 27 Sep 2004 15:30:18 -0700 Message-ID: Thread-Topic: -01 version of Chargeable User Identity Thread-Index: AcSk4ZFf0N3T1Kc6SgKPpJxrjRRMOg== From: "Adrangi, Farid" To: Cc: , 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. =20 - 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. =20 BR, Farid -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 26 Sep 2004 17:37:47 +0000 Date: Sun, 26 Sep 2004 10:27:53 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: IETF 61 submission deadlines (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 23 Sep 2004 23:06:31 +0000 Message-Id: <200409232257.i8NMvEv20643@internaut.com> To: "'radiusext@ops.ietf.org'" , jari.arkko@piuha.net Cc: David Mariblanca (EE/EEM) Subject: Re: alternatives for carrying eap lower layer information Content-Type: text/plain; charset=iso-8859-1 Date: Thu, 23 Sep 2004 15:57:14 -0700 From: Bernard Aboba 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 23 Sep 2004 19:33:41 +0000 Message-ID: <415324AB.2020103@piuha.net> Date: Thu, 23 Sep 2004 22:31:55 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: "'radiusext@ops.ietf.org'" Cc: "David Mariblanca (EE/EEM)" Subject: alternatives for carrying eap lower layer information Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Sep 2004 21:00:39 +0000 Message-ID: <414FE090.7020708@piuha.net> Date: Tue, 21 Sep 2004 11:04:32 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Ignacio Goyret Cc: "'radiusext@ops.ietf.org'" Subject: Re: NAIbis spec revision 03 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 '&' in html. Right? Oops. XML bug in my source :-) That too is now corrected. --Jari -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Sep 2004 19:47:47 +0000 Date: Tue, 21 Sep 2004 12:38:40 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Back online Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Sep 2004 21:50:53 +0000 Message-Id: <200409202150.OAA02066@grigri.eng.ascend.com> Date: Mon, 20 Sep 2004 14:48:48 -0700 To: jari.arkko@piuha.net From: Ignacio Goyret Subject: Re: NAIbis spec revision 03 Cc: "'radiusext@ops.ietf.org'" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 '&' 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 radiusext-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Sep 2004 21:32:39 +0000 Message-Id: <200409202123.i8KLNk607179@internaut.com> To: radiusext@ops.ietf.org Subject: Request: User of [Issue] in Subject Line Content-Type: text/plain; charset=iso-8859-1 Date: Mon, 20 Sep 2004 14:23:46 -0700 From: Bernard Aboba 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Sep 2004 21:17:38 +0000 Message-Id: <200409202108.i8KL8HR06022@internaut.com> To: radiusext@ops.ietf.org Subject: Issue 14: Review of Chargeable User Identity Content-Type: text/plain; charset=iso-8859-1 Date: Mon, 20 Sep 2004 14:08:17 -0700 From: Bernard Aboba For details, see: http://www.drizzle.com/~aboba/RADEXT/#Issue%2014 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Sep 2004 21:17:22 +0000 Message-Id: <200409202108.i8KL8P206057@internaut.com> To: radiusext@ops.ietf.org Subject: Issue 14: Review of Chargeable User Identity Content-Type: text/plain; charset=iso-8859-1 Date: Mon, 20 Sep 2004 14:08:25 -0700 From: Bernard Aboba For details, see: http://www.drizzle.com/~aboba/RADEXT/#Issue%2014 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Sep 2004 13:27:51 +0000 Message-ID: <414EDA88.FC90EF3F@alcatel.be> Date: Mon, 20 Sep 2004 15:26:32 +0200 From: Nagi Reddy Jonnala Reply-To: Nagi_Reddy.Jonnala@alcatel.be Organization: Alcatel Telecom MIME-Version: 1.0 To: jari.arkko@piuha.net CC: "'radiusext@ops.ietf.org'" Subject: Re: NAIbis spec revision 03 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Sep 2004 05:47:46 +0000 Message-ID: <414E6C05.2080200@piuha.net> Date: Mon, 20 Sep 2004 08:35:01 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: "'radiusext@ops.ietf.org'" Subject: NAIbis spec revision 03 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 13 Sep 2004 11:54:16 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: New draft submission - Chargeable User Identity Date: Mon, 13 Sep 2004 14:50:38 +0300 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D0892B9@esebe056.ntc.nokia.com> Thread-Topic: New draft submission - Chargeable User Identity Thread-Index: AcSZdXpN+XmVCVXxRZuq9Pl5VLk6fAAEi8xw From: To: , , Cc: , , , , 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: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org]On Behalf Of ext David Mariblanca > (ML/EEM) > Sent: 13 September, 2004 12:16 > To: 'Adrangi, Farid'; Bernard Aboba > Cc: Nelson, David; Avi Lior; jouni.korhonen@teliasonera.com; > radiusext@ops.ietf.org; sami.ala-luukko@teliasonera.com > Subject: RE: New draft submission - Chargeable User Identity >=20 >=20 >=20 > Hi Farid and others, > for these purposes, in 3GPP it's used the Subscription-Id AVP=20 > from the Diameter Credit Control application. It is a grouped=20 > AVP with these values: >=20 > END_USER_E164 0 =20 > The identifier is in international E.164 format (e.g. MSISDN),=20 > according to the ITU-T E.164 numbering plan as defined in [E164]=20 > and [CE164].=20 > =20 > END_USER_IMSI 1 =20 > The identifier is in international IMSI format,=20 > according to the=20 > ITU-T E.212 numbering plan as defined in [E121] and [CE121]. =20 > =20 > END_USER_SIP_URI 2 =20 > The identifier is in the form of a SIP URI as defined in [SIP]. =20 > =20 > END_USER_NAI 3 =20 > The identifier is in the form of a Network Access Identifier as=20 > defined in [NAI]. =20 > =20 > END_USER_PRIVATE 4 =20 > The Identifier is a credit-control server private identifier.=20 >=20 > If an attribute for a similar purpose is to be created for=20 > RADIUS, shouldn't it be a mapping from this one ? >=20 > BR, > David. >=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Adrangi, Farid > Sent: viernes, 10 de septiembre de 2004 19:02 > To: Bernard Aboba > Cc: Nelson, David; Avi Lior; jouni.korhonen@teliasonera.com; > radiusext@ops.ietf.org; sami.ala-luukko@teliasonera.com > Subject: RE: New draft submission - Chargeable User Identity >=20 >=20 > 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=20 > a standard > attribute from IETF. Several GSMA vendors have already=20 > implemented and > tested the VSA for EAP-SIM trial - and they are ready to=20 > replace it with > the IETF standard attribute for the deployment. So, getting the > standard attribute from IETF sometime this year would be=20 > great! BTW, as > you already know, GSAM has sent an LS on this to IETF. =20 >=20 > I also copied Sami Ala-luukko on this thread as well. >=20 > BR, > Farid >=20 >=20 > > -----Original Message----- > > From: Bernard Aboba [mailto:aboba@internaut.com]=20 > > Sent: Friday, September 10, 2004 9:43 AM > > To: Adrangi, Farid > > Cc: Nelson, David; Avi Lior; jouni.korhonen@teliasonera.com;=20 > > radiusext@ops.ietf.org > > Subject: Re: New draft submission - Chargeable User Identity > >=20 > >=20 > > BTW, I noticed that the GSMA roaming spec includes VSAs for=20 > chargeable > > userID as well as location. Is the GSMA prepared to adopt an IETF > > standard attribute spec for chargeable userID instead,=20 > assuming it is > > completed within their time frame? What is that time frame? > >=20 > >=20 > > On Fri, 10 Sep 2004, Adrangi, Farid wrote: > >=20 > > > Hi, > > > I would like to submit 00 version of a draft to RADEXT WG. =20 > > Here is the > > > url to the draft: > > > > > >=20 > > 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 > > > > >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 13 Sep 2004 09:16:49 +0000 Message-ID: <1AB3D30B989BF141BBD5C70057B2EF7C092E5A18@eestqnt105.es.eu.ericsson.se> From: "David Mariblanca (ML/EEM)" To: "'Adrangi, Farid'" , Bernard Aboba Cc: "Nelson, David" , Avi Lior , jouni.korhonen@teliasonera.com, radiusext@ops.ietf.org, sami.ala-luukko@teliasonera.com Subject: RE: New draft submission - Chargeable User Identity Date: Mon, 13 Sep 2004 11:15:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Adrangi, Farid Sent: viernes, 10 de septiembre de 2004 19:02 To: Bernard Aboba Cc: Nelson, David; Avi Lior; jouni.korhonen@teliasonera.com; radiusext@ops.ietf.org; sami.ala-luukko@teliasonera.com 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:aboba@internaut.com] > Sent: Friday, September 10, 2004 9:43 AM > To: Adrangi, Farid > Cc: Nelson, David; Avi Lior; jouni.korhonen@teliasonera.com; > radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 10 Sep 2004 17:03:31 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: New draft submission - Chargeable User Identity Date: Fri, 10 Sep 2004 10:02:22 -0700 Message-ID: Thread-Topic: New draft submission - Chargeable User Identity Thread-Index: AcSXVliGskfyqFB0RxaZeYSIpiVfTQAABD1A From: "Adrangi, Farid" To: "Bernard Aboba" Cc: "Nelson, David" , "Avi Lior" , , , 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. =20 I also copied Sami Ala-luukko on this thread as well. BR, Farid > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com]=20 > Sent: Friday, September 10, 2004 9:43 AM > To: Adrangi, Farid > Cc: Nelson, David; Avi Lior; jouni.korhonen@teliasonera.com;=20 > radiusext@ops.ietf.org > Subject: Re: New draft submission - Chargeable User Identity >=20 >=20 > 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? >=20 >=20 > On Fri, 10 Sep 2004, Adrangi, Farid wrote: >=20 > > Hi, > > I would like to submit 00 version of a draft to RADEXT WG. =20 > Here is the > > url to the draft: > > > >=20 > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 10 Sep 2004 16:51:49 +0000 Date: Fri, 10 Sep 2004 09:43:06 -0700 (PDT) From: Bernard Aboba To: "Adrangi, Farid" cc: "Nelson, David" , Avi Lior , jouni.korhonen@teliasonera.com, radiusext@ops.ietf.org Subject: Re: New draft submission - Chargeable User Identity Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 08 Sep 2004 19:48:43 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Planning for IETF 61 Date: Wed, 8 Sep 2004 15:47:45 -0400 Message-ID: Thread-Topic: Planning for IETF 61 Thread-Index: AcSV3LKONls7Ux9YTEuEoqRgHIMG7A== From: "Nelson, David" To: 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! =A0 Dave =A0 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 05 Sep 2004 07:42:02 +0000 Message-ID: <413AC2D2.5070503@piuha.net> Date: Sun, 05 Sep 2004 10:40:02 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: "Beck01, Wolfgang" Cc: radiusext@ops.ietf.org, Miguel.An.Garcia@nokia.com Subject: Re: AW: review of draft-sterman Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 03 Sep 2004 19:29:06 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RADEXT WG Minutes for IETF60 Thursday session Date: Fri, 3 Sep 2004 15:28:40 -0400 Message-ID: Thread-Topic: RADEXT WG Minutes for IETF60 Thursday session Thread-Index: AcSR7DZAvgPlW+edSTS9k5irSddY2Q== From: "Nelson, David" To: 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? =20 - No, more along the lines of documentation fixes. - Need to be clear moving forward about attributes being=20 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,=20 we would prefer start/stop. - Q: Are resources released on a stop message? =20 - 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. =20 - 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. =20 - 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. =20 - 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=20 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=20 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...=20 - 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? =20 - 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? =20 - 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? =20 - A: Nope, no plan, and that's the path we are still following. - Diameter compatibility section necessary in drafts. =20 - 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. =20 - 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? =20 - Group hum: some sort of capability negotiation is needed?=20 - 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?=20 - A: Response "iffy" either way. =20 - 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?=20 - 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. =20 - A: Consequences need to be publicized as well. - Q: This really is a wired vulnerability, not a wireless = vulnerability. =09 - A: sniffing on wired networks is harder. - Q: Wired sniffing is mandatory for this attack to happen; no wired, no attack at all. =20 - 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. =20 - 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? =20 - 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? =20 - A: See upcoming slide, also use salt. - Q: Why do I need to ever know the precursor? I have the final=20 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? =20 - 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. =A0 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 03 Sep 2004 19:27:22 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RADEXT WG Minutes for IETF60 Monday session Date: Fri, 3 Sep 2004 15:26:09 -0400 Message-ID: Thread-Topic: RADEXT WG Minutes for IETF60 Monday session Thread-Index: AcSR69xue5w1rktlQhqCacMOAMbW4g== From: "Nelson, David" To: IETF 60 RADIUS Extensions (RADEXT) WG=20 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. =20 - Needed to do IPv6=20 - 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=20 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=09 David Nelson - Extended Management attributes - Existing two attributes are service types for CLI - Need other attributes for SNMP, HTTP, etc. - Also need security levels=20 - 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=20 - Enterasys is working in this area using vendor-specific attributes - Idea is that this might be more generally useful and if=20 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 !! =20 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=20 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,=20 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 =20 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=20 =09 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=20 - 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 =09 Avi for Hannes - prepaid - Extensions for event based charging - Service is not access service - How does RADIUS specify service and actions? =09 Volunteers requested for=20 Issues doc =09 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Sep 2004 17:40:52 +0000 Message-ID: <7D410981F5D6214FA120DD2CF6E75462010CC4EB@zfrac103-int2.europe.nortel.com> From: "Lothar Reith" To: "'Nelson, David'" , "'radiusext@ops.ietf.org'" Subject: AW: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt Date: Thu, 2 Sep 2004 19:39:55 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C49113.DBEB2B48" 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.pd= f=20 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.=20 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: =20 http://www.ietf.org/internet-drafts/draft-pale-email-01.txt.=20 Best Regards, Lothar -----Urspr=FCngliche Nachricht----- Von: Nelson, David [mailto:dnelson@enterasys.com]=20 Gesendet: Donnerstag, 2. September 2004 17:58 An: Reith, Lothar [HAHN:NGD:EXCH]; radiusext@ops.ietf.org 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). =20 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. =20 DBN: Cryptographic entropy is also discussed in most cryptography = texts, e.g. B. Schneier: Applied Cryptography, 2nd Ed., 233-237, 1996. =20 ------_=_NextPart_001_01C49113.DBEB2B48 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable AW: I-D = ACTION:draft-funk-radiusext-shared-secret-amp-01.txt

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/Chokhan= i-KBA%20Metrics.pdf

http://www.ifp.uiuc.edu/~paradasa/talks/IMCrypto_ECE45= 9Talk.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-0= 1.txt.



Best Regards, Lothar











-----Urspr=FCngliche Nachricht-----
Von: Nelson, David [mailto:dnelson@enterasys.com] =
Gesendet: Donnerstag, 2. September 2004 17:58
An: Reith, Lothar [HAHN:NGD:EXCH]; = radiusext@ops.ietf.org
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-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Sep 2004 16:02:56 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt Date: Thu, 2 Sep 2004 11:57:59 -0400 Message-ID: Thread-Topic: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt Thread-Index: AcSQxQAulFxAmO8wRpuyL0JoRNNrBAAQJ5uN From: "Nelson, David" To: "Lothar Reith" , 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). =20 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. =20 DBN: Cryptographic entropy is also discussed in most cryptography texts, = e.g. B. Schneier: Applied Cryptography, 2nd Ed., 233-237, 1996. =20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Sep 2004 13:02:46 +0000 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FD8D@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: jari.arkko@piuha.net, radiusext@ops.ietf.org, Miguel.An.Garcia@nokia.com Subject: AW: review of draft-sterman Date: Thu, 2 Sep 2004 15:02:19 +0200 MIME-Version: 1.0 Content-Type: text/plain 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Sep 2004 12:59:02 +0000 Message-ID: <413718C0.3060101@piuha.net> Date: Thu, 02 Sep 2004 15:57:36 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Miguel Garcia Cc: radiusext@ops.ietf.org, "Beck01, Wolfgang" Subject: Re: review of draft-sterman Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Sep 2004 11:54:08 +0000 Message-ID: <41370988.5070907@piuha.net> Date: Thu, 02 Sep 2004 14:52:40 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: "'radiusext@ops.ietf.org'" , "Beck01, Wolfgang" , Miguel Garcia Subject: review of draft-sterman Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Sep 2004 08:29:49 +0000 Message-ID: <7D410981F5D6214FA120DD2CF6E75462010CC160@zfrac103-int2.europe.nortel.com> From: "Lothar Reith" To: "Lothar Reith" , "'Paul Funk'" , "'Clint Chaplin'" , "'radiusext@ops.ietf.org'" Subject: AW: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt Date: Thu, 2 Sep 2004 10:24:44 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C490C6.4CE482E8" 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. =20 Apologies and regards...Lothar -----Urspr=FCngliche Nachricht----- Von: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = Im Auftrag von Reith, Lothar [HAHN:NGD:EXCH] Gesendet: Donnerstag, 2. September 2004 10:08 An: 'Paul Funk'; 'Clint Chaplin'; 'radiusext@ops.ietf.org' Betreff: AW: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt Paul,=20 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=20 -----Urspr=FCngliche Nachricht-----=20 Von: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org ] Im Auftrag von Paul Funk=20 Gesendet: Donnerstag, 2. September 2004 03:14=20 An: Clint Chaplin; radiusext@ops.ietf.org=20 Betreff: Re: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt=20 Clint,=20 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=20 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=20 At 05:25 PM 9/1/2004 -0700, Clint Chaplin wrote:=20 >I guess part of my problem is that the term "entropy" is being used=20 >here in two different incompatible but related senses, sort of like=20 >"pounds force" and "pounds mass". Entropy in the cryptographic sense=20 >is the measure of the possible values an item may take on, and is=20 >measured in bits. Entropy in the thermodynamic sense is the measure = of=20 >the disorder in a system.=20 >=20 >Talking about "effective entropy" is a little bit like talking about=20 >"effective pounds mass" under acceleration, which makes my teeth itch. = >=20 >Clint (JOATMON) Chaplin=20 >Wireless Security Advisor=20 >Wireless Standards Lead=20 >=20 > >>> Bernard Aboba 8/31/04 21:34:35 >>>=20 >Forwarded from Clint Chaplin...=20 >=20 >---------- Forwarded message ----------=20 >Date: Tue, 31 Aug 2004 19:47:20 -0700=20 >From: Clint Chaplin =20 >To: aboba@internaut.com, radiusext@ops.ietf.org=20 >Subject: Re: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt=20 >=20 >Bernard: due to a snafu here at Symbol, the radiusext email list is=20 >silently rejecting my posts to it; however, I can still receive the=20 >emails from it. Could you please forward this to the list for me?=20 >Thanks!=20 >=20 >I still disagree with the use of the term "entropy" within this I-D. = As=20 >a simplistic way of looking at this, let's say that the input to this=20 >algorithm can only take on two distinct values, and also the salt can=20 >only take on two distinct values (these values may be expressed using=20 >many bits, but that won't change the argument). Since the salt and = the=20 >input can only have two distinct values, the entropy of each is only = 1,=20 >and the two combined can only take on four distinct values, and thus=20 >have an entropy of 2. Putting these four distinct valuse through the=20 >amplification process will still only yield an output with four=20 >distinct values (although these output values may also be expressed=20 >using many bits). No matter how many times the algorithm is applied,=20 >the output will still only have a max of four distinct values, and a=20 >max entropy of 2. Hashing never adds true entropy, and if a collision = >occurs, can reduce entropy.=20 >=20 >Yes, the term "effective entropy" can be used, but that just confuses=20 >the issue, I feel. Plus, there are still places in the draft where=20 >"effective entropy" should be used for consistancy sake, and it is = not.=20 >=20 >For instance, in the abstract, the phrase "A dictionary attack against = >the resulting shared secret will be infeasible due to its high=20 >entropy." should state "A dictionary attack against the resulting=20 >shared secret will be infeasible due to its high effective entropy."=20 >=20 >In the introduction, the phrase "A dictionary attack against the=20 >resulting shared secret will be infeasible due to its high entropy."=20 >should be "A dictionary attack against the resulting shared secret = will=20 >be infeasible due to its high effective entropy."=20 >=20 >And so on.=20 >=20 >Clint (JOATMON) Chaplin=20 >Wireless Security Advisor=20 >Wireless Standards Lead=20 >=20 > >>> 8/27/04 12:42:15 >>>=20 >A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories.=20 >=20 >=20 > Title : RADIUS Shared Secret Security Amplification = > Author(s) : P. Funk=20 > Filename : = draft-funk-radiusext-shared-secret-amp-01.txt=20 > Pages : 10=20 > Date : 2004-8-27=20 >=20 >This draft describes how a mechanism defined in [PKCS-5] can be used=20 > to amplify the security of a RADIUS shared secret; namely, that a=20 > precursor secret is hashed many times to produce an amplified=20 >shared=20 > secret for use in RADIUS.=20 >=20 >A URL for this Internet-Draft is:=20 >http://www.ietf.org/internet-drafts/draft-funk-radiusext-shared-secret-= =20 >amp-01.txt=20 >=20 >=20 >To remove yourself from the I-D Announcement list, send a message to=20 >i-d-announce-request@ietf.org with the word unsubscribe in the body of = >the message. You can also visit=20 >https://www1.ietf.org/mailman/listinfo/I-D-announce =20 >=20 >to change your subscription settings.=20 >=20 >=20 >Internet-Drafts are also available by anonymous FTP. Login with the=20 >username "anonymous" and a password of your e-mail address. After=20 >logging in, type "cd internet-drafts" and then=20 > "get draft-funk-radiusext-shared-secret-amp-01.txt".=20 >=20 >A list of Internet-Drafts directories can be found in=20 >http://www.ietf.org/shadow.html or=20 >ftp://ftp.ietf.org/ietf/1shadow-sites.txt =20 >=20 >=20 >Internet-Drafts can also be obtained by e-mail.=20 >=20 >Send a message to:=20 > mailserv@ietf.org.=20 >In the body type:=20 > "FILE=20 >/internet-drafts/draft-funk-radiusext-shared-secret-amp-01.txt".=20 >=20 >NOTE: The mail server at ietf.org can return the document in=20 > MIME-encoded form by using the "mpack" utility. To use this=20 > feature, insert the command "ENCODING mime" before the "FILE" = > command. To decode the response(s), you will need "munpack" = or=20 > a MIME-compliant mail reader. Different MIME-compliant mail=20 >readers=20 > exhibit different behavior, especially when dealing with=20 > "multipart" MIME messages (i.e. documents which have been = split=20 > up into multiple messages), so check your local documentation = >on=20 > how to manipulate these messages.=20 >=20 >=20 >Below is the data which will enable a MIME compliant mail reader=20 >implementation to automatically retrieve the ASCII version of the=20 >Internet-Draft.=20 >=20 >=20 >_______________________________________________________________________= =20 >_=20 >This email has been scanned for computer viruses.=20 >=20 >_______________________________________________________________________= =20 >_=20 >This email has been scanned for computer viruses.=20 >=20 >--=20 >to unsubscribe send a message to radiusext-request@ops.ietf.org with=20 >the word 'unsubscribe' in a single line as the message text body.=20 >archive: >=20 >=20 >_______________________________________________________________________= =20 >_=20 >This email has been scanned for computer viruses.=20 >=20 >--=20 >to unsubscribe send a message to radiusext-request@ops.ietf.org with=20 >the word 'unsubscribe' in a single line as the message text body.=20 >archive: >=20 Paul Funk=20 Funk Software, Inc.=20 617 497-6339=20 paul@funk.com=20 --=20 to unsubscribe send a message to radiusext-request@ops.ietf.org with = the word 'unsubscribe' in a single line as the message text body. archive: >=20 ------_=_NextPart_001_01C490C6.4CE482E8 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Nachricht
Reading my own mail again, I guess I replaced the word entropy = one time=20 too often. I also now amended the definition to make it more clear what = I=20 mean.
 
Apologies and regards...Lothar
-----Urspr=FCngliche Nachricht-----
Von:=20 owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = Im=20 Auftrag von Reith, Lothar [HAHN:NGD:EXCH]
Gesendet: = Donnerstag,=20 2. September 2004 10:08
An: 'Paul Funk'; 'Clint Chaplin';=20 'radiusext@ops.ietf.org'
Betreff: AW: I-D=20 = ACTION:draft-funk-radiusext-shared-secret-amp-01.txt

Paul,

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


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

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

Note that it leaves the word entropy in  it's=20 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=FCngliche Nachricht----- =
Von:=20 owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.= ietf.org]=20 Im Auftrag von Paul Funk
Gesendet: = Donnerstag, 2.=20 September 2004 03:14
An: Clint Chaplin;=20 radiusext@ops.ietf.org
Betreff: Re: I-D=20 ACTION:draft-funk-radiusext-shared-secret-amp-01.txt


Clint,

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

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

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

Paul

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

Paul Funk
Funk Software, = Inc.=20
617 497-6339
paul@funk.com=20


--
to unsubscribe send a = message to=20 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a = single line as=20 the message text body.

archive: <http://psg.com/lists/radiusext/>=20

------_=_NextPart_001_01C490C6.4CE482E8-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Sep 2004 08:13:43 +0000 Message-ID: <7D410981F5D6214FA120DD2CF6E75462010CC142@zfrac103-int2.europe.nortel.com> From: "Lothar Reith" To: "'Paul Funk'" , "'Clint Chaplin'" , "'radiusext@ops.ietf.org'" Subject: AW: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt Date: Thu, 2 Sep 2004 10:08:28 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C490C4.07756882" 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=FCngliche Nachricht----- Von: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = Im Auftrag von Paul Funk Gesendet: Donnerstag, 2. September 2004 03:14 An: Clint Chaplin; radiusext@ops.ietf.org 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=20 >here in two different incompatible but related senses, sort of like=20 >"pounds force" and "pounds mass". Entropy in the cryptographic sense=20 >is the measure of the possible values an item may take on, and is=20 >measured in bits. Entropy in the thermodynamic sense is the measure = of=20 >the disorder in a system. > >Talking about "effective entropy" is a little bit like talking about=20 >"effective pounds mass" under acceleration, which makes my teeth itch. > >Clint (JOATMON) Chaplin >Wireless Security Advisor >Wireless Standards Lead > > >>> Bernard Aboba 8/31/04 21:34:35 >>> >Forwarded from Clint Chaplin... > >---------- Forwarded message ---------- >Date: Tue, 31 Aug 2004 19:47:20 -0700 >From: Clint Chaplin >To: aboba@internaut.com, radiusext@ops.ietf.org >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=20 >silently rejecting my posts to it; however, I can still receive the=20 >emails from it. Could you please forward this to the list for me?=20 >Thanks! > >I still disagree with the use of the term "entropy" within this I-D. = As=20 >a simplistic way of looking at this, let's say that the input to this=20 >algorithm can only take on two distinct values, and also the salt can=20 >only take on two distinct values (these values may be expressed using=20 >many bits, but that won't change the argument). Since the salt and = the=20 >input can only have two distinct values, the entropy of each is only = 1,=20 >and the two combined can only take on four distinct values, and thus=20 >have an entropy of 2. Putting these four distinct valuse through the=20 >amplification process will still only yield an output with four=20 >distinct values (although these output values may also be expressed=20 >using many bits). No matter how many times the algorithm is applied,=20 >the output will still only have a max of four distinct values, and a=20 >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=20 >the issue, I feel. Plus, there are still places in the draft where=20 >"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=20 >entropy." should state "A dictionary attack against the resulting=20 >shared secret will be infeasible due to its high effective entropy." > >In the introduction, the phrase "A dictionary attack against the=20 >resulting shared secret will be infeasible due to its high entropy."=20 >should be "A dictionary attack against the resulting shared secret = will=20 >be infeasible due to its high effective entropy." > >And so on. > >Clint (JOATMON) Chaplin >Wireless Security Advisor >Wireless Standards Lead > > >>> 8/27/04 12:42:15 >>> >A New Internet-Draft is available from the on-line Internet-Drafts=20 >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=20 >shared > secret for use in RADIUS. > >A URL for this Internet-Draft is:=20 >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=20 >i-d-announce-request@ietf.org with the word unsubscribe in the body of = >the message. You can also visit=20 >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=20 >username "anonymous" and a password of your e-mail address. After=20 >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=20 >http://www.ietf.org/shadow.html or=20 >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE=20 >/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=20 >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=20 >implementation to automatically retrieve the ASCII version of the=20 >Internet-Draft. > > >_______________________________________________________________________= >_ >This email has been scanned for computer viruses. > >_______________________________________________________________________= >_ >This email has been scanned for computer viruses. > >-- >to unsubscribe send a message to radiusext-request@ops.ietf.org with=20 >the word 'unsubscribe' in a single line as the message text body. >archive: > >_______________________________________________________________________= >_ >This email has been scanned for computer viruses. > >-- >to unsubscribe send a message to radiusext-request@ops.ietf.org with=20 >the word 'unsubscribe' in a single line as the message text body. >archive: Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com -- to unsubscribe send a message to radiusext-request@ops.ietf.org with = the word 'unsubscribe' in a single line as the message text body. archive: ------_=_NextPart_001_01C490C4.07756882 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable 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 "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=FCngliche Nachricht-----
Von: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.= ietf.org] Im Auftrag von Paul Funk
Gesendet: Donnerstag, 2. September 2004 03:14
An: Clint Chaplin; radiusext@ops.ietf.org
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 = <aboba@internaut.com> 8/31/04 21:34:35 >>>
>Forwarded from Clint Chaplin...
>
>---------- Forwarded message ----------
>Date: Tue, 31 Aug 2004 19:47:20 -0700
>From: Clint Chaplin = <cchaplin@symbol.com>
>To: aboba@internaut.com, = radiusext@ops.ietf.org
>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
>
> >>> <Internet-Drafts@ietf.org> = 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-radiuse= xt-shared-secret-
>amp-01.txt
>
>
>To remove yourself from the I-D Announcement = list, send a message to
>i-d-announce-request@ietf.org 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:
>         = mailserv@ietf.org.
>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 = radiusext-request@ops.ietf.org 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 = radiusext-request@ops.ietf.org 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
paul@funk.com


--
to unsubscribe send a message to = radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single = line as the message text body.

archive: <http://psg.com/lists/radiusext/>

------_=_NextPart_001_01C490C4.07756882-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Sep 2004 02:46:14 +0000 From: "Joseph Salowey" To: "'Paul Funk'" , "'Clint Chaplin'" , Subject: RE: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt Date: Wed, 1 Sep 2004 19:45:33 -0700 Message-ID: <000601c49096$ec202400$f57e8640@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit owner-radiusext@ops.ietf.org 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 8/31/04 21:34:35 >>> >> Forwarded from Clint Chaplin... >> >> ---------- Forwarded message ---------- >> Date: Tue, 31 Aug 2004 19:47:20 -0700 >> From: Clint Chaplin >> To: aboba@internaut.com, radiusext@ops.ietf.org >> 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 >> >>>>> 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 >> i-d-announce-request@ietf.org 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: >> mailserv@ietf.org. >> 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 radiusext-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: >> >> _____________________________________________________________ >> __________ _ This email has been scanned for computer viruses. >> >> -- >> to unsubscribe send a message to radiusext-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: > > Paul Funk > Funk Software, Inc. > 617 497-6339 > paul@funk.com -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Sep 2004 01:14:46 +0000 Message-Id: <5.2.0.9.2.20040901204445.049f4e60@mail.funk.com> Date: Wed, 01 Sep 2004 21:14:26 -0400 To: "Clint Chaplin" , From: Paul Funk Subject: Re: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 8/31/04 21:34:35 >>> >Forwarded from Clint Chaplin... > >---------- Forwarded message ---------- >Date: Tue, 31 Aug 2004 19:47:20 -0700 >From: Clint Chaplin >To: aboba@internaut.com, radiusext@ops.ietf.org >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 > > >>> 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 >i-d-announce-request@ietf.org 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: > mailserv@ietf.org. >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 radiusext-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > >________________________________________________________________________ >This email has been scanned for computer viruses. > >-- >to unsubscribe send a message to radiusext-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Sep 2004 00:26:22 +0000 Message-Id: Date: Wed, 01 Sep 2004 17:25:06 -0700 From: "Clint Chaplin" To: Subject: Re: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 8/31/04 21:34:35 >>> Forwarded from Clint Chaplin... ---------- Forwarded message ---------- Date: Tue, 31 Aug 2004 19:47:20 -0700 From: Clint Chaplin To: aboba@internaut.com, radiusext@ops.ietf.org 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 >>> 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 i-d-announce-request@ietf.org 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: mailserv@ietf.org. 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: ________________________________________________________________________ This email has been scanned for computer viruses. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 01 Sep 2004 04:41:59 +0000 Date: Tue, 31 Aug 2004 21:34:35 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Re: I-D ACTION:draft-funk-radiusext-shared-secret-amp-01.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Forwarded from Clint Chaplin... ---------- Forwarded message ---------- Date: Tue, 31 Aug 2004 19:47:20 -0700 From: Clint Chaplin To: aboba@internaut.com, radiusext@ops.ietf.org 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 >>> 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 i-d-announce-request@ietf.org 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: mailserv@ietf.org. 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: