Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 28 Aug 2004 17:11:15 +0000 Date: Sat, 28 Aug 2004 10:03:43 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: RADEXT Issue Tracking Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII We have currently encountered some difficulties in getting issues tracking software (e.g. Roundup) hosted for the RADEXT WG. Until we get those issues resolved, we are doing manual issues tracking using the RADEXT WG web page: http://www.drizzle.com/~aboba/RADEXT/ In order to assist the chairs in maintaining the Issues list, we would like to request that WG participants clearly indicate Issues by including the string "Issue: " in the subject line of an issue. We would also appreciate if issues were posted in the format described on the RADEXT WG web page above. -- to unsubscribe send a message to 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, 27 Aug 2004 13:41:50 +0000 Message-ID: <412F39AD.D6401DDB@alcatel.be> Date: Fri, 27 Aug 2004 15:39:57 +0200 From: Nagi Reddy Jonnala Reply-To: Nagi_Reddy.Jonnala@alcatel.be Organization: Alcatel Telecom MIME-Version: 1.0 To: Barney Wolff CC: Joseph Salowey , "'Bernard Aboba'" , "'Avi Lior'" , "'Beck01, Wolfgang'" , radiusext@ops.ietf.org Subject: Re: Issue with SIP - Need for Message-Authenticator Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit RIPv2 seem to be interested in HMAC-SHA1 and is described in the draft below. The introduction section mentions that some governments insist on the use of HMAC-SHA1 cryptographic mechanism. May be it is worth getting the author opinions/comments about it. http://www.ietf.org/internet-drafts/draft-rja-ripv2-auth-00.txt regards Nagi. Barney Wolff wrote: > On Thu, Aug 26, 2004 at 10:00:55AM -0700, Joseph Salowey wrote: > > > > > > Note that Message-Authenticator is based on HMAC-MD5. Recent > > > research has demonstrated collisions in MD5 (though not in > > > HMAC-MD5), so that it may make sense to define a new > > > attribute that uses a more highly regarded algorithm, such as > > > HMAC-SHA1. > > > > [Joe] See > > http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-01.txt, this > > defines an attribute that can SHA for message authentication. > > As I read the chatter on the crypto list, it's premature to assume that > SHA-1 will survive better than MD5, although it probably will. Arguments > have been made that HMAC-MD5 will not fall to MD5 attacks. I'd suggest > waiting at least a couple of weeks for the smoke to clear before acting. > > We do know that the RADIUS Authenticator has long been considered inferior > to HMAC-MD5, and the recent issues may seal its fate. It's therefore > prudent to consider how to react when, or before, the authenticator is > broken. Certainly boxes that have sufficient cpu and codespace can use > IPsec, as has already been suggested. What, if anything, to do for/with > boxes that cannot run IPsec is an open question. > > -- > Barney Wolff http://www.databus.com/bwresume.pdf > I'm available by contract or FT, in the NYC metro area or via the 'Net. > > -- > to unsubscribe send a message to 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, 27 Aug 2004 13:41:39 +0000 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FD7D@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: mccap@lucent.com, radiusext@ops.ietf.org Subject: AW: Comments on draft-sterman-aaa-sip-03 Date: Fri, 27 Aug 2004 15:40:35 +0200 MIME-Version: 1.0 Content-Type: text/plain Pete McCann wrote: > Document should start with an overview of the assumed architecture, as > shown in e.g. Figure 1 of Section 1.3. However, the text of Section > 1.3 dives into a particular scenario and a broader overview is > necessary first. (I think Miguel made this comment earlier) > Section 1.2 (although I think this text should be deleted): When I started working on the draft, people asked for a motivational section. I'll do an overview section which includes the 2 scenario sections 1.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3.1 Scenario 1, RADIUS client chooses nonces . . . . . . . 5 1.3.2 Scenario 2, RADIUS server chooses nonces . . . . . . . 6 Section 1.3 will be the '1.5 Approach' section of -03 without the last paragraph. > However, in > some cases the RADIUS server is better off with pre-computed hashes. > Section 1.4 describes an mechanism that enables this style of > authentication. > This paragraph mentions "precomputed hashes" but then the issue is never > revisited. Is it true that precomputed hashes can be used with arbitrary > message contents, or is some other coordination required between the > home RADIUS server and the client? Proposal: "1.3.2 Scenario 2, RADIUS server chooses nonces In most cases, the operation outlined in Section 1.3.1 is sufficient. It reduces the load on the RADIUS server to a minimum. However, when using AKA [RFC3310] the nonce is partially derived from a precomputed authentication vector. These authentication vectors are often stored centrally. Figure 3 depicts an scenario, where the RADIUS server chooses nonces." > Section 2: > Reformat list of attributes into a table, and use values like "TBD-DIG-RES" > in the table. Create an IANA considerations section which requests allocations. There is a IANA consideration section at the end of the document. I didn't want to use DIG-RES etc. in the sub sections of 2. before explaining that they are attribute names. Proposal: "2. New RADIUS attributes DIG-RES, DIG-REALM, DIG-NONCE, DIG-METHOD, DIG-URI, DIG-QOP, DIG-ALG, DIG-BODY, DIG-CNONCE, DIG-NC, DIG-USER, DIG-OPAQUE, DIG-AUTHP, DIG-AUTS, DIG-DOMAIN and DIG-STALE are placeholders for values that are taken from the RADIUS attribute type number space (see Section )." > Don't use text like "if this specification becomes a working group or IESG > document..." > [..] > Get rid of " Early implementations have used the experimental type > 206." Ok. The following is confusing: > 3.1 RADIUS Client Behaviour > > A RADIUS client without an encrypted or otherwise secured connection > to its RADIUS server only accepts unsecured connections from its > HTTP-style clients (or else the clients would have a false sense of > security). > > It is not quite clear what is meant by "encrypted or otherwise > secured", because there are several different security mechanisms > available in RADIUS, including the hop-by-hop message authenticator > and the shared-key method of obfuscating individual attributes. I "encrypted" ~ eg. IPSEC or proprietary tunnel technology "otherwise secured" ~ eg. RADIUS client and server are in a closed MPLS VPN. > assume this would not be adequate to provide the protection you are > looking for. Also, what counts as an "unsecured connection" from an > HTTP-style client? Do you mean one that doesn't use either TLS or > IPSec? Yes. I'll insert a reference to the security considerations section, which has this paragraph: "HTTP-style clients can use TLS with server side certificates together with HTTP-Digest authentication. IPSec can be used in a similar way. TLS or IPSec secure the connection while Digest Authentication authenticates the user. If a RADIUS client accepts such connections, it MUST have a secure connection to the RADIUS server." > Maybe this paragraph is adequately covered by the security > considerations (or should be) and could be deleted. I disagree. If a SIP client wants the signalling to be secure, it uses sips: URLs. All SIP proxies along the way must use TLS connections to forward requests with sips: URLs. I don't think the SIP proxies (=RADIUS clients) should expose parts of the SIP message by using a unencrypted RADIUS messages in this case. As this is part of the client behaviour, I put it into that section. Thank you very much for your help, Wolfgang -- to unsubscribe send a message to 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, 26 Aug 2004 23:38:43 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16686.29740.890368.137984@gargle.gargle.HOWL> Date: Thu, 26 Aug 2004 18:37:16 -0500 From: Pete McCann To: radiusext@ops.ietf.org Subject: Comments on draft-sterman-aaa-sip-03 Hi, Attached are some review comments on draft-sterman-aaa-sip-03. -Pete Document should start with an overview of the assumed architecture, as shown in e.g. Figure 1 of Section 1.3. However, the text of Section 1.3 dives into a particular scenario and a broader overview is necessary first. (I think Miguel made this comment earlier) Section 1.2 (although I think this text should be deleted): Change: lacking support, too: even two years To: lacking support, too; even two years Change: SIP service providers whishing To: SIP service providers wishing Section 1.5: Change: Section 1.4 describes an mechanism To: Section 1.4 describes a mechanism However, in some cases the RADIUS server is better off with pre-computed hashes. Section 1.4 describes an mechanism that enables this style of authentication. This paragraph mentions "precomputed hashes" but then the issue is never revisited. Is it true that precomputed hashes can be used with arbitrary message contents, or is some other coordination required between the home RADIUS server and the client? Section 2: Reformat list of attributes into a table, and use values like "TBD-DIG-RES" in the table. Create an IANA considerations section which requests allocations. Don't use text like "if this specification becomes a working group or IESG document..." Get rid of " Early implementations have used the experimental type 206." The following is confusing: 3.1 RADIUS Client Behaviour A RADIUS client without an encrypted or otherwise secured connection to its RADIUS server only accepts unsecured connections from its HTTP-style clients (or else the clients would have a false sense of security). It is not quite clear what is meant by "encrypted or otherwise secured", because there are several different security mechanisms available in RADIUS, including the hop-by-hop message authenticator and the shared-key method of obfuscating individual attributes. I assume this would not be adequate to provide the protection you are looking for. Also, what counts as an "unsecured connection" from an HTTP-style client? Do you mean one that doesn't use either TLS or IPSec? Maybe this paragraph is adequately covered by the security considerations (or should be) and could be deleted. -- to unsubscribe send a message to 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, 26 Aug 2004 19:20:54 +0000 Message-ID: <412E378B.3020506@cisco.com> Date: Thu, 26 Aug 2004 12:18:35 -0700 From: Murtaza Chiba User-Agent: Mozilla Thunderbird 0.7 (X11/20040615) MIME-Version: 1.0 To: Barney Wolff CC: Joseph Salowey , "'Bernard Aboba'" , "'Avi Lior'" , "'Beck01, Wolfgang'" , radiusext@ops.ietf.org Subject: Re: Issue with SIP - Need for Message-Authenticator Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit From what I understand, having an easy way to generate collisions does not mean that it will be easy to create valid RADIUS packets that result in the collision hash. Also, its not been proved that cryptanalysis will help reverse engineer the cleartext from the hash. Murtaza Barney Wolff wrote: > On Thu, Aug 26, 2004 at 10:00:55AM -0700, Joseph Salowey wrote: > >>>Note that Message-Authenticator is based on HMAC-MD5. Recent >>>research has demonstrated collisions in MD5 (though not in >>>HMAC-MD5), so that it may make sense to define a new >>>attribute that uses a more highly regarded algorithm, such as >>>HMAC-SHA1. >> >>[Joe] See >>http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-01.txt, this >>defines an attribute that can SHA for message authentication. > > > As I read the chatter on the crypto list, it's premature to assume that > SHA-1 will survive better than MD5, although it probably will. Arguments > have been made that HMAC-MD5 will not fall to MD5 attacks. I'd suggest > waiting at least a couple of weeks for the smoke to clear before acting. > > We do know that the RADIUS Authenticator has long been considered inferior > to HMAC-MD5, and the recent issues may seal its fate. It's therefore > prudent to consider how to react when, or before, the authenticator is > broken. Certainly boxes that have sufficient cpu and codespace can use > IPsec, as has already been suggested. What, if anything, to do for/with > boxes that cannot run IPsec is an open question. > -- to unsubscribe send a message to 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, 26 Aug 2004 18:59:11 +0000 Date: Thu, 26 Aug 2004 14:56:36 -0400 From: Barney Wolff To: Joseph Salowey Cc: "'Bernard Aboba'" , "'Avi Lior'" , "'Beck01, Wolfgang'" , radiusext@ops.ietf.org Subject: Re: Issue with SIP - Need for Message-Authenticator Message-ID: <20040826185636.GA47121@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i On Thu, Aug 26, 2004 at 10:00:55AM -0700, Joseph Salowey wrote: > > > > Note that Message-Authenticator is based on HMAC-MD5. Recent > > research has demonstrated collisions in MD5 (though not in > > HMAC-MD5), so that it may make sense to define a new > > attribute that uses a more highly regarded algorithm, such as > > HMAC-SHA1. > > [Joe] See > http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-01.txt, this > defines an attribute that can SHA for message authentication. As I read the chatter on the crypto list, it's premature to assume that SHA-1 will survive better than MD5, although it probably will. Arguments have been made that HMAC-MD5 will not fall to MD5 attacks. I'd suggest waiting at least a couple of weeks for the smoke to clear before acting. We do know that the RADIUS Authenticator has long been considered inferior to HMAC-MD5, and the recent issues may seal its fate. It's therefore prudent to consider how to react when, or before, the authenticator is broken. Certainly boxes that have sufficient cpu and codespace can use IPsec, as has already been suggested. What, if anything, to do for/with boxes that cannot run IPsec is an open question. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. -- to unsubscribe send a message to 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, 26 Aug 2004 18:42:20 +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: Issue with SIP - Need for Message-Authenticator Date: Thu, 26 Aug 2004 11:41:37 -0700 Message-ID: Thread-Topic: Issue with SIP - Need for Message-Authenticator Thread-Index: AcSLjwS4F9lkHi75TDK8lAofvYNDOAACH5QQ From: "Randy Chou" To: "Joseph Salowey" , "Bernard Aboba" , "Avi Lior" Cc: "Beck01, Wolfgang" , , "Randy Chou" If you're referring to the recent collisions found in MD5 and SHA-0, here are a few points: - Many believe that it's just a matter of time before a collision is found in SHA-1. - nothing indicates that the collisions affect HMAC-MD5. - The more important (weakest link) in Radius is actually the response authenticator which uses plain MD5. If the method used in finding the collision (diff analysis) can somehow speed up the cracking of the RADIUS shared secret, it doesn't make any difference how the message authenticator is arrived at. - On the other hand, if someone has figured out how to crack this, it's unlikely that the attack will be released to the public anytime soon due to disclosure requirements :). Any of these hashes coupled with a static shared key is an accident waiting to happen. The real fix IMO would be to derive encryption and authentication keys through assymetric encryption (use IKE/IPSEC, TLS, ...). There's no point in patching it with HMAC-SHA1, might as well leave it as is for compatibility. The gain is minimal. Regards, =20 -- Randy -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Joseph Salowey Sent: Thursday, August 26, 2004 10:01 AM To: 'Bernard Aboba'; 'Avi Lior' Cc: 'Beck01, Wolfgang'; radiusext@ops.ietf.org Subject: RE: Issue with SIP - Need for Message-Authenticator owner-radiusext@ops.ietf.org wrote: > Thanks for pointing this out Avi. Here is what it says in Section=20 > 5.19 of RFC 2869: >=20 > An Access-Request that contains either a User-Password or > CHAP-Password or ARAP-Password or one or more EAP-Message > attributes MUST NOT contain more than one type of those four=20 > attributes. If it > does not contain any of those four attributes, it SHOULD contain a > Message-Authenticator. If any packet type contains an EAP-Message > attribute it MUST also contain a Message-Authenticator. >=20 > Note that Message-Authenticator is based on HMAC-MD5. Recent research > has demonstrated collisions in MD5 (though not in HMAC-MD5), so that=20 > it may make sense to define a new attribute that uses a more highly=20 > regarded algorithm, such as HMAC-SHA1. [Joe] See http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-01.txt, this defines an attribute that can SHA for message authentication. =20 >=20 > On Thu, 26 Aug 2004, Avi Lior wrote: >=20 >> Wolfgang, >>=20 >> In the SIP doc I think you need to use Message-Authenticator(80) in=20 >> the access request. >>=20 >> The problem is this: without using a field such as CHAP-Password or=20 >> Password, the RADIUS server has no way to validate that the=20 >> Access-Request is arriving from a valid NAS. >>=20 >> Message-Authenticator(80) is used to provide integrity protection for >> the entire Access-Request packet and can be used by the RADIUS Server >> to validate that the packet was received from a known Client (since=20 >> the Message-Authenticator uses a shared secret shared by the >> Client-Server.) >>=20 >>=20 >>=20 >> -- >> to unsubscribe send a message to > 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: -- 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, 26 Aug 2004 17:02:11 +0000 From: "Joseph Salowey" To: "'Bernard Aboba'" , "'Avi Lior'" Cc: "'Beck01, Wolfgang'" , Subject: RE: Issue with SIP - Need for Message-Authenticator Date: Thu, 26 Aug 2004 10:00:55 -0700 Message-ID: <00c701c48b8e$41d60b20$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit owner-radiusext@ops.ietf.org wrote: > Thanks for pointing this out Avi. Here is what it says in > Section 5.19 of RFC 2869: > > An Access-Request that contains either a User-Password or > CHAP-Password or ARAP-Password or one or more EAP-Message > attributes MUST NOT contain more than one type of those four > attributes. If it > does not contain any of those four attributes, it SHOULD contain a > Message-Authenticator. If any packet type contains an EAP-Message > attribute it MUST also contain a Message-Authenticator. > > Note that Message-Authenticator is based on HMAC-MD5. Recent > research has demonstrated collisions in MD5 (though not in > HMAC-MD5), so that it may make sense to define a new > attribute that uses a more highly regarded algorithm, such as > HMAC-SHA1. [Joe] See http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-01.txt, this defines an attribute that can SHA for message authentication. > > On Thu, 26 Aug 2004, Avi Lior wrote: > >> Wolfgang, >> >> In the SIP doc I think you need to use Message-Authenticator(80) in >> the access request. >> >> The problem is this: without using a field such as CHAP-Password or >> Password, the RADIUS server has no way to validate that the >> Access-Request is arriving from a valid NAS. >> >> Message-Authenticator(80) is used to provide integrity protection for >> the entire Access-Request packet and can be used by the RADIUS Server >> to validate that the packet was received from a known Client (since >> the Message-Authenticator uses a shared secret shared by the >> Client-Server.) >> >> >> >> -- >> to unsubscribe send a message to > 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: Thu, 26 Aug 2004 14:14:57 +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: REMINDER: RADEXT WG last call on RFC 2486bis Date: Thu, 26 Aug 2004 10:13:26 -0400 Message-ID: Thread-Topic: REMINDER: RADEXT WG last call on RFC 2486bis Thread-Index: AcSE7zZkuONcb+0dQ0+6HfkVA5LSaAGh4w9Q From: "Nelson, David" To: Last reminder -- this WGLC completes today. > This is a reminder of RADEXT WG Last Call in progress on "The Network > Access Identifier" specification, RFC 2486bis, prior to sending the draft > on to the IESG for consideration as an IETF Proposed Standard (recycled). > The draft is available for inspection at: >=20 > http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-02.tx t >=20 > RADEXT WG Last Call will complete on August 26, 2004. Please send > comments to the RADEXT WG mailing list (radiusext@ops.ietf.org), using the > issue format described at http://www.drizzle.com/~aboba/AAA/issues.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, 26 Aug 2004 14:14:42 +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: REMINDER: RADEXT WG last call on RADIUS Extension for Digest Authentication Date: Thu, 26 Aug 2004 10:12:37 -0400 Message-ID: Thread-Topic: REMINDER: RADEXT WG last call on RADIUS Extension for Digest Authentication Thread-Index: AcSE7ze3FlUeqdp+RTq92dQt/fg85wGh0p1g From: "Nelson, David" To: Last reminder -- this WGLC completes today. > This is a reminder of the ongoing RADEXT WG Last Call on the "RADIUS > Extension > for Digest Authentication" specification, prior to sending the draft on to > the IESG for consideration as an IETF Proposed Standard. The > draft is available for inspection at: >=20 > http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-03.txt >=20 > RADEXT WG Last Call will complete on August 26, 2004. Please send > comments to the RADEXT WG mailing list (radiusext@ops.ietf.org), using the > issue format described at http://www.drizzle.com/~aboba/AAA/issues.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, 26 Aug 2004 13:10:44 +0000 Date: Thu, 26 Aug 2004 06:00:49 -0700 (PDT) From: Bernard Aboba To: Avi Lior cc: "Beck01, Wolfgang" , radiusext@ops.ietf.org Subject: Re: Issue with SIP - Need for Message-Authenticator Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Thanks for pointing this out Avi. Here is what it says in Section 5.19 of RFC 2869: An Access-Request that contains either a User-Password or CHAP-Password or ARAP-Password or one or more EAP-Message attributes MUST NOT contain more than one type of those four attributes. If it does not contain any of those four attributes, it SHOULD contain a Message-Authenticator. If any packet type contains an EAP-Message attribute it MUST also contain a Message-Authenticator. Note that Message-Authenticator is based on HMAC-MD5. Recent research has demonstrated collisions in MD5 (though not in HMAC-MD5), so that it may make sense to define a new attribute that uses a more highly regarded algorithm, such as HMAC-SHA1. On Thu, 26 Aug 2004, Avi Lior wrote: > Wolfgang, > > In the SIP doc I think you need to use Message-Authenticator(80) in the > access request. > > The problem is this: without using a field such as CHAP-Password or > Password, the RADIUS server has no way to validate that the Access-Request > is arriving from a valid NAS. > > Message-Authenticator(80) is used to provide integrity protection for the > entire Access-Request packet and can be used by the RADIUS Server to > validate that the packet was received from a known Client (since the > Message-Authenticator uses a shared secret shared by the Client-Server.) > > > > -- > to unsubscribe send a message to 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: Thu, 26 Aug 2004 09:08:23 +0000 Message-ID: From: Avi Lior To: "Beck01, Wolfgang" , radiusext@ops.ietf.org Subject: Issue with SIP - Need for Message-Authenticator Date: Thu, 26 Aug 2004 05:07:07 -0400 MIME-Version: 1.0 Content-Type: text/plain Wolfgang, In the SIP doc I think you need to use Message-Authenticator(80) in the access request. The problem is this: without using a field such as CHAP-Password or Password, the RADIUS server has no way to validate that the Access-Request is arriving from a valid NAS. Message-Authenticator(80) is used to provide integrity protection for the entire Access-Request packet and can be used by the RADIUS Server to validate that the packet was received from a known Client (since the Message-Authenticator uses a shared secret shared by the Client-Server.) -- to unsubscribe send a message to 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, 25 Aug 2004 16:12:53 +0000 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FD79@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: radiusext@ops.ietf.org Subject: open issue: rspauth generation not possible if RADIUS server choo ses nonces and qop=auth-int Date: Wed, 25 Aug 2004 18:12:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" rspauth generation not possible if RADIUS server chooses nonces and qop=auth-int Submitter name: Wolfgang Beck Submitter email address: beckw@t-systems.com Date first submitted: 25.8.2004 Reference: Document: RADIUS Extension for Digest Authentication Comment type: T Priority: 1 Section: 3.1, 3.2 Rationale/Explanation of issue: Jun Wang wrote: > As the RADIUS server does not know about the response body the > RADIUS client is going to send, it can't generate A2. > > In 3GPP2, we do need to perform auth-int because we need to protect the > response that is sent from the network to the MS. I hope in this draft you > could allow solution 3 or at least you will not preclude solution 3 so that > we can have 3GPP2 VSA to do it. > > Thanks, > Jun > > Beck01, Wolfgang wrote: >> Hello Jun, >> >> thank you for your review. Rahul Joshi told me about this problem >> some weeks ago and I think there are three possible solutions: 1) >> don't use authentication-info with auth-int 2) send all possible >> response body-digests to the RADIUS server 3) your suggestion. >> >> I am not sure about the security implications of 3). Replay >> attacks might be possible. Solution 2) is a bit bloated as it >> would double the work on client and server. >> >> In the San Diego meeting, I proposed using solution 1) and >> did not hear any objections. >> >> >> Jun Wang wrote >>> >>> By reviewing sterman draft (RADIUS Extension for Digest Authentication, >>> draft-sterman-aaa-sip-03.txt), I have questions on how the RADIUS sever can >>> calculate the Digest-Response that can be used by RADIUS client to >>> construct Auth-info header (mentioned in section 3.2 in sterman draft). >>> According to 3.2.3 of RFC 2617, if I understand correctly, the response >>> digest is calculated as for the request-digest except that A2 is slightly >>> different. But regardless, to calculate Digest-Response, the RADIUS server >>> needs to know H(entity-body), here entity-body, I think, is the body >>> contained in 200OK response. But RADIUS server doesn't know it. It seems to >>> me that the right thing is to pass some derived key to RADIUS client so >>> that the RADIUS client can calculate Auth-info. >>> >>> Requested change: [Jun Wang] >>> [..] It seems to me that the right thing is to pass some >>> derived key to RADIUS client so that the RADIUS client can >>> calculate Auth-info. [Wolfgang Beck] When using qop=auth-int, the response-auth value is response-auth = <"> < KD ( H(A1), unq(nonce-value) ":" nc-value ":" unq(cnonce-value) ":" unq(qop-value) ":" H(A2) ) <"> with algorithm = MD5, A1 and A2 are: A1 = unq(username-value) ":" unq(realm-value) ":" passwd A2 = ":" digest-uri-value ":" H(entity-body) Sending H(A1) in an Access-Accept message would be risky as A1 has no random components. Replay attacks are possible. with algorithm = MD5-sess, A1 and A2 are: A1 = H( unq(username-value) ":" unq(realm-value) ":" passwd ) ":" unq(nonce-value) ":" unq(cnonce-value) A2 = ":" digest-uri-value ":" H(entity-body) here, A1 has some randomness. A possible solution might be: 1. Add a new attribute to carry H(A1), Digest-HA1 2. Use Digest-HA1 if server chooses nonces, qop=auth-int and algorithm=MD5-sess 3. Use a Digest-Response-Auth attribute (new, see issue 4, 5) if server chooses nonces and qop != auth-int. 4. On reception of Digest-HA1, the RADIUS client constructs rspauth, using the nonce received in a previous Access-Challenge I don't know if this is really secure. -- to unsubscribe send a message to 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, 25 Aug 2004 16:11:25 +0000 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FD78@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: radiusext@ops.ietf.org Subject: open issue:draft-sterman, use of Access-Challenge Date: Wed, 25 Aug 2004 18:09:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Use of Access-Challenge Submitter name: Wolfgang Beck Submitter email address: beckw@t-systems.com Date first submitted: 25.8.2004 Reference: Document: RADIUS Extension for Digest Authentication Comment type: T Priority: 2 Section: 1.4, 3.1, 3.2 Rationale/Explanation of issue: draft-sterman-aaa-sip-03 uses Access-Accept messages with a Digest-Nonce, but without a Digest-Response parameter. This is a in fact a challenge message and should use RADIUS Access-Challenge. Requested change: 1.4 Scenario 2, RADIUS server chooses nonces Figure 2 depicts an alternative scenario, where the RADIUS server generates nonces. It shows a generic case where entities A and B communicate in the front-end using protocols such as HTTP/SIP, while entities B and C communicate in the back-end using RADIUS. HTTP/SIP RADIUS +-----+ (1) +-----+ +-----+ | |==========>| | (2) | | | | | |---------->| | | | | | (3) | | | | (4) | |<----------| | | |<==========| | | | | | (5) | | | | | |==========>| | | | | A | | B | (6) | C | | | | |---------->| | | | | | (7) | | | | | |<----------| | | | (8) | | | | | |<==========| | | | +-----+ +-----+ +-----+ ====> HTTP/SIP ----> RADIUS Figure 2: RADIUS server chooses nonces The roles played by the entities in this scenario are as follows: A: HTTP client / SIP UA B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS} acting also as a RADIUS NAS C: RADIUS server The relevant order of messages sent in this scenario is as follows: A sends B an HTTP/SIP request without authorization header (step 1). B sends an Access-Request message with the newly defined Digest-Method and Digest-URI attributes but without a Digest-Nonce attribute to the RADIUS server, C (step 2). C chooses a nonce and responds with an Access-Challenge (step 3). This Access-Challenge contains Digest attributes, from which B takes values to construct a HTTP/SIP "(Proxy) Authorization required" response. The remaining steps are identical with scenario 1 (Section 1.3): B sends this response to A (step 4). A resends its request with its credentials (step 5). B sends an Access-Request to C (step 6). C checks the credentials and replies with Access-Accept or Access-Reject (step 7). Dependent on the C's result, B processes A's request or rejects it 3.1 RADIUS Client Behaviour [..] The RADIUS client has three ways to obtain nonces: it generates them locally, it has received one in a Digest-Nonce attribute of a previously received Access-Accept message, or it asks the RADIUS server for one. To do the latter, it sends an Access-Request containing a Digest-Method and a Digest-URI attribute but without a Digest-Nonce attribute. The RADIUS server chooses a nonce and responds with an Access-Challenge containing a Digest-Nonce attribute. If the RADIUS server responds with an Access-Reject, the RADIUS client MAY generate a nonce locally. If the RADIUS client does not generate nonces locally, the authentication has failed. The RADIUS server can send Digest-QoP, Digest-Algorithm, Digest-Realm, Digest-Domain and Digest-Opaque attributes in the Access-Accept carrying the nonce. If these attributes are present, the client MUST use them. 3.2 RADIUS Server Behaviour If the RADIUS server receives an Access-Request message with a Digest-Method and a Digest-URI attribute but without a Digest-Nonce attribute, it chooses a nonce. It puts the nonce into a Digest-Nonce attribute and sends it in an Access-Challenge message to the RADIUS client. The RADIUS server MUST add Digest-Algorithm, Digest-Realm, SHOULD add Digest-QoP and MAY add Digest-Domain, Digest-Opaque attributes to the Access-Challenge message. If the server cannot choose a nonce, it replies with an Access-Reject message. [..] -- to unsubscribe send a message to 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, 23 Aug 2004 19:47:05 +0000 Content-class: urn:content-classes:message Subject: Notes from the Monday session?? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Aug 2004 15:44:54 -0400 Message-ID: Thread-Topic: Notes from the Monday session?? Thread-Index: AcSJSazxW2sATWwKRhi+TI9ZwZW49w== From: "Nelson, David" To: Would the minute takers for the Monday RADEXT WG session at IETF 60 = please forward those notes to me? Thanks! I think these were = previously sent to Bernard, but he's on vacation and I need to get the = minutes submitted prior to September 5. I have the notes from the = Thursday session. Regards, =A0 Dave =A0 -- to unsubscribe send a message to 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, 22 Aug 2004 17:17:35 +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: Moving forward on billable identities Date: Sun, 22 Aug 2004 10:16:16 -0700 Message-ID: Thread-Topic: Moving forward on billable identities Thread-Index: AcSHx3j24kJ5eZ4bRQ+ro8ySRMP4MgAocw5w From: "Adrangi, Farid" To: "Bernard Aboba" , Yes, we will move this attribute (known as User Identity Alias in http://www.ietf.org/internet-drafts/draft-adrangi-radius-attributes-exte nsion-01.txt) to a separate ID. =20 BR, Farid > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Saturday, August 21, 2004 2:34 PM > To: radiusext@ops.ietf.org > Subject: Moving forward on billable identities >=20 >=20 > At IETF 60, there was a desire expressed to move forward on a document > relating to the billable identities issue. >=20 > Here is what needs to be done: >=20 > a. Submit an Internet-Draft covering this subject exclusively. > b. Request comments/reviews from the RADEXT WG mailing list. > c. Assuming the reaction is favorable, request adoption as a WG > work item. >=20 > Note that there has already been considerable RADEXT WG=20 > discussion on this > topic, much of which has centered around the need for this=20 > attribute and > potential backward compatibility issues. >=20 > Therefore I'd suggest that the document make a convincing=20 > case for why a > new attribute is needed, and describe how backward=20 > compatibility can be > handled. >=20 > -- > to unsubscribe send a message to 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: Sat, 21 Aug 2004 21:40:21 +0000 Date: Sat, 21 Aug 2004 14:33:58 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Moving forward on billable identities Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII At IETF 60, there was a desire expressed to move forward on a document relating to the billable identities issue. Here is what needs to be done: a. Submit an Internet-Draft covering this subject exclusively. b. Request comments/reviews from the RADEXT WG mailing list. c. Assuming the reaction is favorable, request adoption as a WG work item. Note that there has already been considerable RADEXT WG discussion on this topic, much of which has centered around the need for this attribute and potential backward compatibility issues. Therefore I'd suggest that the document make a convincing case for why a new attribute is needed, and describe how backward compatibility can be handled. -- to unsubscribe send a message to 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, 18 Aug 2004 22:12:05 +0000 Date: Wed, 18 Aug 2004 15:05:53 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: WG Web page Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I've put up a preliminary version of the RADEXT WG Web page at: http://www.drizzle.com/~aboba/RADEXT/ Comments welcome. A request. At IETF 60 we mentioned that we would like to move to automated issue tracking. If there are folks in the WG who have experience with these tools (Roundup, RT, Bugzilla, etc.), please send email to the chairs. We are also looking for help with hosting the issue tracking system. -- to unsubscribe send a message to 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, 18 Aug 2004 06:46:59 +0000 Date: Tue, 17 Aug 2004 23:40:47 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: REMINDER: RADEXT WG last call on RADIUS Extension for Digest Authentication Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is a reminder of the ongoing RADEXT WG Last Call on the "RADIUS Extension for Digest Authentication" specification, prior to sending the draft on to the IESG for consideration as an IETF Proposed Standard. The draft is available for inspection at: http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-03.txt RADEXT WG Last Call will complete on August 26, 2004. Please send comments to the RADEXT WG mailing list (radiusext@ops.ietf.org), using the issue format described at http://www.drizzle.com/~aboba/AAA/issues.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: Wed, 18 Aug 2004 06:46:35 +0000 Date: Tue, 17 Aug 2004 23:40:07 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: REMINDER: RADEXT WG last call on RFC 2486bis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is a reminder of RADEXT WG Last Call in progress on "The Network Access Identifier" specification, RFC 2486bis, prior to sending the draft on to the IESG for consideration as an IETF Proposed Standard (recycled). The draft is available for inspection at: http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-02.txt RADEXT WG Last Call will complete on August 26, 2004. Please send comments to the RADEXT WG mailing list (radiusext@ops.ietf.org), using the issue format described at http://www.drizzle.com/~aboba/AAA/issues.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: Tue, 17 Aug 2004 11:44:52 +0000 Message-ID: <4121EF7A.6050903@piuha.net> Date: Tue, 17 Aug 2004 14:43:54 +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: Pasi.Eronen@nokia.com Cc: radiusext@ops.ietf.org Subject: Re: Comments for 2486bis WGLC Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pasi, Thanks for your suggestions. I agree with them. --Jari > Some minor comments about draft-arkko-roamops-rfc2486bis-02: > > - In Section 2.1, on the line > > c =/ %x2b ; '*' allowed > > the '*' in the comment should be '+' > > - In Section 2.1, the line > > c =/ %x5e-7e ; '^' - ' allowed > > would probably be easier to understand if written out: > > c =/ %x5e ; '^' allowed > c =/ %x5f ; '_' allowed > c =/ %x60-7a ; 'a'-'z' allowed > c =/ %x7b ; '{' allowed > c =/ %x7c ; '|' allowed > c =/ %x7d ; '}' allowed > c =/ %x7e ; '~' allowed > > - In Appendix A, fourth bullet: it seems there are no > stricter requirements on the part preceding the '!' > sign _unless_ it's explicitly known that this realm > supports this syntax. > > So it's not a backwards-compatibility problem: something > like "foo!bar@example.com" continues to be a valid NAI > (even though "foo" is not a valid realm) unless it's > known that example.com uses the stricter syntax > from section 2.7. -- to unsubscribe send a message to 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, 17 Aug 2004 11:26:45 +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: Comments for 2486bis WGLC Date: Tue, 17 Aug 2004 14:25:22 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A60227C16F@esebe023.ntc.nokia.com> Thread-Topic: Comments for 2486bis WGLC Thread-Index: AcSETOInd1sFQDx1RxygWXEc1z06/g== From: To: Hi, Some minor comments about draft-arkko-roamops-rfc2486bis-02: - In Section 2.1, on the line c =3D/ %x2b ; '*' allowed the '*' in the comment should be '+' - In Section 2.1, the line c =3D/ %x5e-7e ; '^' - ' allowed would probably be easier to understand if written out: c =3D/ %x5e ; '^' allowed c =3D/ %x5f ; '_' allowed c =3D/ %x60-7a ; 'a'-'z' allowed c =3D/ %x7b ; '{' allowed c =3D/ %x7c ; '|' allowed c =3D/ %x7d ; '}' allowed c =3D/ %x7e ; '~' allowed - In Appendix A, fourth bullet: it seems there are no=20 stricter requirements on the part preceding the '!'=20 sign _unless_ it's explicitly known that this realm=20 supports this syntax.=20 So it's not a backwards-compatibility problem: something=20 like "foo!bar@example.com" continues to be a valid NAI=20 (even though "foo" is not a valid realm) unless it's=20 known that example.com uses the stricter syntax from section 2.7. Best regards, Pasi -- to unsubscribe send a message to 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, 17 Aug 2004 04:17:17 +0000 Message-ID: <41218683.80508@piuha.net> Date: Tue, 17 Aug 2004 07:16:03 +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: Charlie Kaufman Subject: Re: [Ipsec] IKEv2 identifier issue with EAP Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Copying the RADEXT list on my question to the IPsec WG and Charlie Kaufman's response: Charlie Kaufman wrote: > I agree that this is likely to become a problem, that any of your > 'possible solutions' could be used to fix it (except that I don't > believe the first two 'define the problem away' were serious proposals), > and that the community SHOULD agree on one standard approach to maximize > interoperability. > > My favorite would be: > o Go against the SHOULD NOT when the given NAI requires this. > > ...because this also addresses the identity type hint that you say might > be coming. But others have argued heatedly that it is important to > minimize the number of messages in an IKE exchange, and this would > result in an eight message exchange while some of the other proposals > work in six. > > I'm really glad it's not my job anymore to herd the cats towards one > approach or the other. > > --Charlie > > p.s. If you are going to define a new ID type, it would need to be added > to the IANA registry for IKEv2. The procedure for this is "expert > review". It could probably be defined in some EAP RFC and ratified by > some expert chosen by the security ADs, but I don't know. > > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Jari Arkko > Sent: Monday, August 16, 2004 4:17 AM > To: IPsec WG > Cc: Bernard Aboba > Subject: [Ipsec] IKEv2 identifier issue with EAP > > > First some background: In traditional EAP usage, the client's identifier > has been determined through the EAP Identity Request/Response exchange. > The identifier is typically a Network Access Identifier (NAI). Basically > an identifier similar to an e-mail address, used to identify the user > and to find the right home network in case of a roaming user. > > IKEv2-14 says the following: > > Note that since IKE passes an indication of initiator identity in > message 3 of the protocol, EAP based prompts for Identity SHOULD NOT > be used. > > it also defines one of the identity type as follows: > > ID_RFC822_ADDR 3 > > A fully-qualified RFC822 email address string, An example of > a ID_RFC822_ADDR is, "jsmith@example.com". The string MUST > not contain any terminators. > > In the RADEXT and EAP WGs, we have recently discussed some > problems that this causes. Here are the issues: > > 1. A revision of the NAI specification, RFC 2486bis, intends > to extend the existing user@domain format in > draft-arkko-roamops-rfc2486bis-02.txt, partially based on > existing practise. This spec is currently in WGLC in the > RADEXT WG. > > One of the extensions is to allow the client's identity > to be hidden from the access server / IKEv2 gateway, > if the used EAP method supports end-to-end encrypted > tranmission of the identity. Syntactically, this > happens through specifying an empty username, "@domain" > but keeping the domain pawrt in order to make the AAA > routing possible. > > The issue with IKEv2 is strictly speaking, this > string would be illegal in RFC 822. Hence an IKEv2 > implementation can not be relied upon to accept such > "privacy" user names. > > 2. Another extension from this draft is internationalized > NAIs. The domain parts are IDNs, i.e., converted to ASCII > via a specific mapping, but the username part is UTF-8. > Again, this is strictly speaking not conformant to RFC 822, > so sending an internationalized username via IKEv2 might > not be possible. For instance, someone might be assigned > a username for WLAN access, but the usage of this username > for IKEv2 purposes might not be possible if it contains > international characters. > > Some of the possible solutions to avoid this problem > include > > o Decide that support of privacy & international usernames > is not necessary in IKEv2. > > o Remove the privacy and international username (not domain) > parts from RFC 2486bis. > > o Change the international username part so that instead of > UTF-8, it uses a IDN-like ASCII mapping which can represent > non-ASCII characters but it looks like ASCII to the carrier. > Either remove the privacy feature or just say it can not > be used in all carrier protocols. > > o Define a new IKEv2 ID type to carry the new types NAIs. > (If so, would this type be defined in the NAIbis, IKEv2 > or some other draft?) > > o Rely on IKEv2 implementations to not check the contents > of the identifier for RFC 822 compliance. > > o Go against the SHOULD NOT when the given NAI requires this. > > 3. Ongoing work (and some existing practise) provides some > information through the EAP identity request. More specifically, > the client can get a hint of what type of identifier it should > offer. See draft-adrangi-eap-network-discovery-03.txt. > > This functionality does not appear to be present when running > EAP over IKEv2. (I have not heard of any customer who wanted > this functionality in this context, but I'd like to avoid > special cases where possible.) -- to unsubscribe send a message to 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, 16 Aug 2004 06:59:26 +0000 Message-ID: <2A8DB02E3018D411901B009027FD3A3F046864EC@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Yoshihiro Ohba'" , radiusext@ops.ietf.org Subject: RE: IKEv2 issue in RFC2486bis Date: Mon, 16 Aug 2004 08:57:40 +0200 MIME-Version: 1.0 Content-Type: text/plain hi yoshi, i am very much in favour of your proposal for adding new IKEv2 ID type. i have sent the ikev2 folks a mail about this issue many months ago. no reply. i hope it will be different now. ciao hannes ps: i also dislike the mentioned paragraph from section 3.16. > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Sunday, August 29, 2004 7:12 PM > To: radiusext@ops.ietf.org > Subject: IKEv2 issue in RFC2486bis > > Hi, > > I had a discussion with Jari, Bernard and Pasi on an IKEv2 > issue of RFC2486bis and the following is the summary of the > discussion (please correct if I am wrong): > > Section 3.16 of draft-ietf-ipsec-ikev2-14.txt says: > > " > Note that since IKE passes an indication of initiator identity in > message 3 of the protocol, EAP based prompts for Identity > SHOULD NOT > be used. > " > > This means that an RFC2486bis NAI may be carried in an IKEv2 > Identity Payload when EAP is used in IKEv2. In this case, > there is an issue of which ID Type of IKEv2 Identification > Payload is appropriate to carry the RFC2486bis NAI. > > One possibility is using ID_RFC822_ADDR, but RFC822 address > is not compatible with RFC2486bis NAI at least in that (i) > RFC822 address does NOT allow the characters preceding "@" > (i.e., local-part) to be null and (ii) RFC822 address does > NOT allow ASCII control characters to appear in local-part > without being quoted as quoted-string (thus a > UTF-8 encoded username with containing ASCII control > characters is not compatible with local-part of RFC822 address.) > > Since IKEv2 specification does not prohibit an implementation > to perform strict check against RFC 822 format and returns an > error Notification with "INVALID_SYNTAX" when the strict > check fails, I think using ID_RFC822_ADDR for RFC2486bis NAI > has an interoperability problem. Using ID_KEY_ID is not > appropriate to carry RFC2486bis either, since it is used for > carrying certain proprietary types of identification. > > To solve the problem, I would suggest defining a new IKEv2 > Identification Payload Type to carry RFC2486bis NAI. > > Also, draft-ietf-ipsec-ikev2-iana-02.txt says: > > " > 7.1 Amending formula for IKEv2 Identification Payload ID Types > > IKEv2 Identification Payload ID Types may be allocated by > Specification Required. > " > > So I think RFC2486bis could be the Specification where the > new IKEv2 ID Type is defined. > > This was not discussed, but when a given RFC2486bis NAI also > conforms to RFC822 address, I think such an NAI can also be > carried as ID_RFC822_ADDR ID type. > > Best regards, > > Yoshihiro Ohba > > -- > to unsubscribe send a message to > 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: Sun, 15 Aug 2004 20:50:56 +0000 Message-ID: <411FCC6B.6060301@piuha.net> Date: Sun, 15 Aug 2004 23:49:47 +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: Bernard Aboba Cc: Yoshihiro Ohba , radiusext@ops.ietf.org Subject: Re: IKEv2 issue in RFC2486bis Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >>Question: Would this be part of the NAIbis RFC, or a >>separate RFC? > > > It should be fixed in the IKEv2 I-D that is now under evaluation. The IKEv2 people will be glad when they hear about this. >>My interpretation is that this allows any type of text >>(even non-ASCII), except ASCII control characters. There's >>also a special treatment for " and \. So it seems that we >>can carry an internationalized username here, or even a >>privacy NAI (but the latter would not make sense with >>current Digest algorithms). > > > OK. So is the SIP "username" a subset or superset of the NAI user-name > grammar? Taking a new look at the RFCs, there's really three answers: (1) If you allow for escape (\x), then both syntaxes can represent exactly the same username strings. Technically, this means that you can take any HTTP Digest username value and put into a legal NAI, but you may have to add/remove some escape characters. (2) If you do not allow for escape or don't do the related conversion, then there are some strings that are legal in a HTTP Digest username value, but illegal in a NAI. Example: @example.net (3) NAI spec requires that the domain name part actually be a domain name. RFC 2617 did not require that for the username part. So conceivably you could use fred@foo_9.com in SIP, but that would be invalid as a NAI. Also, a AAA node trying to use the domain name part in some manner might get into trouble. --Jari -- to unsubscribe send a message to 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, 15 Aug 2004 15:21:40 +0000 Date: Sun, 15 Aug 2004 08:15:31 -0700 (PDT) From: Bernard Aboba To: Jari Arkko cc: Yoshihiro Ohba , radiusext@ops.ietf.org Subject: Re: IKEv2 issue in RFC2486bis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Question: Would this be part of the NAIbis RFC, or a > separate RFC? It should be fixed in the IKEv2 I-D that is now under evaluation. > My interpretation is that this allows any type of text > (even non-ASCII), except ASCII control characters. There's > also a special treatment for " and \. So it seems that we > can carry an internationalized username here, or even a > privacy NAI (but the latter would not make sense with > current Digest algorithms). OK. So is the SIP "username" a subset or superset of the NAI user-name grammar? -- to unsubscribe send a message to 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, 15 Aug 2004 08:21:28 +0000 Message-ID: <411F1CBC.5090809@piuha.net> Date: Sun, 15 Aug 2004 11:20:12 +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: Bernard Aboba Cc: Yoshihiro Ohba , radiusext@ops.ietf.org Subject: Re: IKEv2 issue in RFC2486bis Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >>o Define the new IKEv2 ID type as Yoshihiro suggests >> below. > > > I'd support this alternative. IKEv2 is already incompatible with RFC > 2486, so this would need to be done anyway. Question: Would this be part of the NAIbis RFC, or a separate RFC? >>Finally, does anyone have a full list of places where the >>NAI can appear? Either because the protocol specs say that >>a particular field is a NAI, or because people take a >>particular application identifier and put it into a place >>which traditionally carries a NAI (such as RADIUS User-Name). >>I think we are talking about PPP, EAP, RADIUS, Diameter, >>SIP and Mobile IPv4, but is this all? What do these specifications >>say about non-RFC822 compliant names? > > > In PPP, EAP, RADIUS and Diameter the structure of the NAI is not > constrained, so I don't think there is an issue. > > In RFC 2794, it defines the NAI field as "A string in the NAI format > defined in [1]." So I don't think there is an issue there either. Ok. Thanks for the info. > I didn't know that SIP utilized the NAI. Where is this usage defined? It is not defined directly as a NAI. It falls into the class of fields that get copied into a place that traditionally carries a NAI. When using HTTP digest with SIP, a system implementing either the RADIUS or Diameter SIP application will put the "username" field from the Digest headers into the AAA User-Name AVP. Here's the syntax of the "username" field from RFC 2616-2617: username = "username" "=" username-value username-value = quoted-string quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) qdtext = > quoted-pair = "\" CHAR TEXT = CTL = CR = LF = SP = HT = CRLF = CR LF LWS = [CRLF] 1*( SP | HT ) My interpretation is that this allows any type of text (even non-ASCII), except ASCII control characters. There's also a special treatment for " and \. So it seems that we can carry an internationalized username here, or even a privacy NAI (but the latter would not make sense with current Digest algorithms). --Jari -- to unsubscribe send a message to 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: Sat, 14 Aug 2004 13:27:38 +0000 Date: Sat, 14 Aug 2004 06:21:53 -0700 (PDT) From: Bernard Aboba To: Jari Arkko cc: Yoshihiro Ohba , radiusext@ops.ietf.org Subject: Re: IKEv2 issue in RFC2486bis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > o Define the new IKEv2 ID type as Yoshihiro suggests > below. I'd support this alternative. IKEv2 is already incompatible with RFC 2486, so this would need to be done anyway. > Finally, does anyone have a full list of places where the > NAI can appear? Either because the protocol specs say that > a particular field is a NAI, or because people take a > particular application identifier and put it into a place > which traditionally carries a NAI (such as RADIUS User-Name). > I think we are talking about PPP, EAP, RADIUS, Diameter, > SIP and Mobile IPv4, but is this all? What do these specifications > say about non-RFC822 compliant names? In PPP, EAP, RADIUS and Diameter the structure of the NAI is not constrained, so I don't think there is an issue. In RFC 2794, it defines the NAI field as "A string in the NAI format defined in [1]." So I don't think there is an issue there either. I didn't know that SIP utilized the NAI. Where is this usage defined? -- to unsubscribe send a message to 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: Sat, 14 Aug 2004 10:54:44 +0000 Message-ID: <411DEF31.9050504@piuha.net> Date: Sat, 14 Aug 2004 13:53:37 +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: Yoshihiro Ohba Cc: radiusext@ops.ietf.org Subject: Re: IKEv2 issue in RFC2486bis Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Oh, and I forgot one more possibility, see below: >>From the 10.000 ft point of view, I see the following > possibilities: > > o Decide that support of privacy & international usernames > is not necessary in IKEv2. > > o Remove the privacy and international username (not domain) > parts from RFC 2486bis. > > o Change the international username part so that instead of > UTF-8, it uses a IDN-like ASCII mapping which can represent > non-ASCII characters but it looks like ASCII to the carrier. > Either remove the privacy feature or just say it can not > be used in all carrier protocols. > > o Define the new IKEv2 ID type as Yoshihiro suggests > below. o Rely on IKEv2 implementations to not check the contents of the identifier for RFC 822 compliance. --Jari -- to unsubscribe send a message to 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: Sat, 14 Aug 2004 07:48:04 +0000 Message-ID: <411DC36A.4070307@piuha.net> Date: Sat, 14 Aug 2004 10:46:50 +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: Yoshihiro Ohba Cc: radiusext@ops.ietf.org Subject: Re: IKEv2 issue in RFC2486bis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks for bringing this issue up, Yoshihiro. I think this problem is serious and we need to decide what to do about it. >From the 10.000 ft point of view, I see the following possibilities: o Decide that support of privacy & international usernames is not necessary in IKEv2. o Remove the privacy and international username (not domain) parts from RFC 2486bis. o Change the international username part so that instead of UTF-8, it uses a IDN-like ASCII mapping which can represent non-ASCII characters but it looks like ASCII to the carrier. Either remove the privacy feature or just say it can not be used in all carrier protocols. o Define the new IKEv2 ID type as Yoshihiro suggests below. Finally, does anyone have a full list of places where the NAI can appear? Either because the protocol specs say that a particular field is a NAI, or because people take a particular application identifier and put it into a place which traditionally carries a NAI (such as RADIUS User-Name). I think we are talking about PPP, EAP, RADIUS, Diameter, SIP and Mobile IPv4, but is this all? What do these specifications say about non-RFC822 compliant names? --Jari Yoshihiro Ohba wrote: > Hi, > > I had a discussion with Jari, Bernard and Pasi on an IKEv2 issue of > RFC2486bis and the following is the summary of the discussion > (please correct if I am wrong): > > Section 3.16 of draft-ietf-ipsec-ikev2-14.txt says: > > " > Note that since IKE passes an indication of initiator identity in > message 3 of the protocol, EAP based prompts for Identity SHOULD NOT > be used. > " > > This means that an RFC2486bis NAI may be carried in an IKEv2 Identity > Payload when EAP is used in IKEv2. In this case, there is an issue of > which ID Type of IKEv2 Identification Payload is appropriate to carry > the RFC2486bis NAI. > > One possibility is using ID_RFC822_ADDR, but RFC822 address is not > compatible with RFC2486bis NAI at least in that (i) RFC822 address > does NOT allow the characters preceding "@" (i.e., local-part) to be > null and (ii) RFC822 address does NOT allow ASCII control characters > to appear in local-part without being quoted as quoted-string (thus a > UTF-8 encoded username with containing ASCII control characters is not > compatible with local-part of RFC822 address.) > > Since IKEv2 specification does not prohibit an implementation to > perform strict check against RFC 822 format and returns an error > Notification with "INVALID_SYNTAX" when the strict check fails, I > think using ID_RFC822_ADDR for RFC2486bis NAI has an interoperability > problem. Using ID_KEY_ID is not appropriate to carry RFC2486bis > either, since it is used for carrying certain proprietary types of > identification. > > To solve the problem, I would suggest defining a new IKEv2 > Identification Payload Type to carry RFC2486bis NAI. > > Also, draft-ietf-ipsec-ikev2-iana-02.txt says: > > " > 7.1 Amending formula for IKEv2 Identification Payload ID Types > > IKEv2 Identification Payload ID Types may be allocated by > Specification Required. > " > > So I think RFC2486bis could be the Specification where the new IKEv2 > ID Type is defined. > > This was not discussed, but when a given RFC2486bis NAI also conforms > to RFC822 address, I think such an NAI can also be carried as > ID_RFC822_ADDR ID type. > > Best regards, > > Yoshihiro Ohba > > -- > to unsubscribe send a message to 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, 13 Aug 2004 22:56:17 +0000 Date: Sun, 29 Aug 2004 13:12:26 -0400 From: Yoshihiro Ohba Subject: IKEv2 issue in RFC2486bis To: radiusext@ops.ietf.org Message-id: <20040829171226.GA12038@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6+20040803i Hi, I had a discussion with Jari, Bernard and Pasi on an IKEv2 issue of RFC2486bis and the following is the summary of the discussion (please correct if I am wrong): Section 3.16 of draft-ietf-ipsec-ikev2-14.txt says: " Note that since IKE passes an indication of initiator identity in message 3 of the protocol, EAP based prompts for Identity SHOULD NOT be used. " This means that an RFC2486bis NAI may be carried in an IKEv2 Identity Payload when EAP is used in IKEv2. In this case, there is an issue of which ID Type of IKEv2 Identification Payload is appropriate to carry the RFC2486bis NAI. One possibility is using ID_RFC822_ADDR, but RFC822 address is not compatible with RFC2486bis NAI at least in that (i) RFC822 address does NOT allow the characters preceding "@" (i.e., local-part) to be null and (ii) RFC822 address does NOT allow ASCII control characters to appear in local-part without being quoted as quoted-string (thus a UTF-8 encoded username with containing ASCII control characters is not compatible with local-part of RFC822 address.) Since IKEv2 specification does not prohibit an implementation to perform strict check against RFC 822 format and returns an error Notification with "INVALID_SYNTAX" when the strict check fails, I think using ID_RFC822_ADDR for RFC2486bis NAI has an interoperability problem. Using ID_KEY_ID is not appropriate to carry RFC2486bis either, since it is used for carrying certain proprietary types of identification. To solve the problem, I would suggest defining a new IKEv2 Identification Payload Type to carry RFC2486bis NAI. Also, draft-ietf-ipsec-ikev2-iana-02.txt says: " 7.1 Amending formula for IKEv2 Identification Payload ID Types IKEv2 Identification Payload ID Types may be allocated by Specification Required. " So I think RFC2486bis could be the Specification where the new IKEv2 ID Type is defined. This was not discussed, but when a given RFC2486bis NAI also conforms to RFC822 address, I think such an NAI can also be carried as ID_RFC822_ADDR ID type. Best regards, Yoshihiro Ohba -- to unsubscribe send a message to 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, 09 Aug 2004 13:50:59 +0000 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FD61@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: aboba@internaut.com Cc: radiusext@ops.ietf.org Subject: AW: [AAA-WG]: AW: Comments to draft-sterman-aaa-sip-03 and draft- ietf-aaa-sip-a pp-03 Date: Mon, 9 Aug 2004 15:50:31 +0200 MIME-Version: 1.0 Content-Type: text/plain Bernard, >> After converting the draft to flat attributes, I tried to save attribute >> space. It is a scarce resource in RADIUS. > > Point of process. In the RADEXT WG, issues are not resolved by assertion. > They are resolved by WG discussion. Just take my response to Miguel as a contribution to the WG discussion. > Also, saving attribute space is not a design goal of this document. > Diameter compatibility *is* a design goal. If we can do both, why shouldn't we? If not, I've no problem adding attributes to the draft. Wolfgang -- to unsubscribe send a message to 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, 09 Aug 2004 13:47:16 +0000 Message-ID: <41178038.9010909@piuha.net> Date: Mon, 09 Aug 2004 16:46: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: Bernard Aboba Cc: "Beck01, Wolfgang" , radiusext@ops.ietf.org, Miguel Garcia Subject: Re: [AAA-WG]: AW: Comments to draft-sterman-aaa-sip-03 and draft-ietf-aaa-sip-a pp-03 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Wolfgang Beck wrote: > After converting the draft to flat attributes, I tried to save attribute > space. It is a scarce resource in RADIUS. Bernard Aboba wrote: > Also, saving attribute space is not a design goal of this document. > Diameter compatibility *is* a design goal. In general, I'd rather have a larger number of attributes in a draft than cause problems for translation. Of course we can build special cases for attributes, but I'd rather have NASREQ-style completely automatic mapping (attribute => AVP from RADIUS space) or at least simple table driven mapping (attribute => AVP from Diameter space with same type). Note: if RADIUS attribute space really runs out, we can create more, through an IETF "vendor" attribute, for instance. --Jari -- to unsubscribe send a message to 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, 09 Aug 2004 12:55:44 +0000 Date: Mon, 9 Aug 2004 05:50:30 -0700 (PDT) From: Bernard Aboba To: "Beck01, Wolfgang" cc: radiusext@ops.ietf.org Subject: Re: [AAA-WG]: AW: Comments to draft-sterman-aaa-sip-03 and draft-ietf-aaa-sip-a pp-03 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > After converting the draft to flat attributes, I tried to save attribute > space. It is a scarce resource in RADIUS. Point of process. In the RADEXT WG, issues are not resolved by assertion. They are resolved by WG discussion. Also, saving attribute space is not a design goal of this document. Diameter compatibility *is* a design goal. Issue 4 will remain open until the Diameter compatibility implications are discussed and understood. -- to unsubscribe send a message to 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, 09 Aug 2004 07:28:00 +0000 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FD5F@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: Miguel.An.Garcia@nokia.com, radiusext@ops.ietf.org, aaa-wg@merit.edu, baruch@kayote.com, dscreat@dscreat.com, david@kayote.com, dwilli@cisco.com Cc: maria.carmen.belinchon@ericsson.com, miguel-angel.pallares@ericsson.com, carolina.canales@ericsson.com, mccap@lucent.com, jaakko.rajaniemi@nokia.com, kalle.tammi@nokia.com Subject: AW: Comments to draft-sterman-aaa-sip-03 and draft-ietf-aaa-sip-a pp-03 Date: Mon, 9 Aug 2004 09:27:04 +0200 MIME-Version: 1.0 Content-Type: text/plain Miguel, > 1) Abstract: The abstract looks more like an introduction to me, > providing a motivation for this work. I think the abstract should just > indicate what this document provides, rather than a historical > description of the capabilities of RADIUS, SIP and HTTP. I would suggest > a text around this lines: > > "This document specifies an extension to RADIUS that allows a RADIUS > client in a SIP/HTTP server, upon reception of a SIP/HTTP request, > retrieve and compute Digest authentication information from a RADIUS > server. Additionally, a scenario describing the authentication of a > user emiting a SIP/HTTP request is provided." Thank you for this proposal. > 3) draft-sterman defines a Digest-Body attribute. But actually, the > attribute will not contain a body, but the hash of a body. I would > suggest to rename this attribute to Digest-Entity-Body-Hash. It happens > that this is the name of the same AVP in Diamter SIP app. Digest-Body-Digest looked a bit strange to me and Digest-Entity-Body-Hash a bit long. But I've no problem changing it. > 4) I noticed that draft-sterman does not specified a Digest-Nextnonce > attribute, but we have a Digest-Nextnonce AVP in Diameter SIP app. It > seems that draft-sterman reuses Digest-Nonce to transport a nextnonce. > While the mechanism probably works, I would suggest to define a new > Digest-Nextnonce attribute in draft-sterman, since the semantics of > Nonce and Nextnonce are completely different, so they are sent in > different parameters in the Digest header. Is this acceptable? > > 5) Similar to #4 above, I noticed that draft-sterman defines a > Digest-Response that presumably is used to map it to both "response" and > "rspauth" in Digest. As in #4, the semantics of both Digest parameters > are different, so the attributes should be. In Diameter SIP app. we > define Digest-Response and Digest-Response-Auth AVPs. I would suggest > that draft-sterman splits Digest-Response similarly. Is this acceptable? After converting the draft to flat attributes, I tried to save attribute space. It is a scarce resource in RADIUS. > 6) Question of documentation. I noticed that all the attribute > descriptions in draft-sterman include a figure containing the position > of Type, Length and String. I wonder if it is needed to repeat the > figure in all the attribute descriptions or whether you can indicate in > a general paragraph the commonality shared by all the attributes (among > others, the structure represented in those figures). OK. > 7) Section 2.1 in draft-sterman. The definition of Type says: > Type > DIG-RES for Digest-Response. Early implementations have used > the experimental type 206. > > I would suggest to remove the last sentence. It is not relevant for > this document the value an early implementation has used or not. What is > important is the value assigned by IANA. OK. > 8) Section 2.16, Digest-Stale. I notice that draft-sterman and Diameter > SIP app are not synchronized with the possible values of this attribute. > > Draft-sterman indicates that if Digest-Stale is present, its value will > always be set to "1". This will be mapped to the stale="true" parameter > in Digest. I understan that if Digest-Stale is not present, then the > RADIUS client should assume that stale="false" or simple not present in > Digest > [..] > My proposal is that draft-sterman aligns with Diameter SIP app and the > value of the Digest-Stale AVP includes a quoted string that is straight > forward mapped to the stale parameter in Digest. Is this acceptable? Yes. > In general, I found that this section 4 has to be rewritten once we > agree on the proposals in this e-mail. It would become easier to map > both documents now. There will be some more changes as I will use Access-Challenge in the next version of the draft. > 11) Section 5: > > I would expect that this section starts with the following sentence: > > "This document serves as IANA registration request for ..." > > Particularly, I would remove the dependency on becoming a working group > (item) or IESG document. OK. > 12) Examples in Section 7: > > This one was a shock to me. It violates all the rules of writing RFCs. > For instance, it does not use the IP address space suggested for > examples, it does not use the example.com domain name. > > The SIP examples luck a few mandatory headers (e.g., Max-Forwards), > contains the name of commertial products, contains undocumented > extensions to SDP, misses recommendations of populating several SIP > headers and SDP lines... > > If you want to continue in this path, I may suggest that an expert > reviewer assigned by the transport AD should inspect this examples. > > I have a better suggestion: at the end of the day, this draft is about > Digest and RADIUS. So why don't you focus on Digest and RADIUS in the > examples? create some sort of abstract SIP/HTTP request, and just write > down the Digest headers, but not the whole SIP message. To be honest, I took the examples without much review from the -00 version which was based on RfC 2543. Thank you for this detailed review, Wolfgang -- Wolfgang Beck T-Systems Internet Netzplattformen +49 6151 937 2863 Am Kavalleriesand 3 64295 Darmstadt -- to unsubscribe send a message to 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, 06 Aug 2004 10:54:07 +0000 Date: Fri, 6 Aug 2004 03:49:05 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Presentations from IETF60 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Are available at: http://www.drizzle.com/~aboba/IETF60/radext/ -- 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, 05 Aug 2004 07:43:50 +0000 Message-Id: <5.2.0.9.2.20040805033703.03e56148@mail.funk.com> Date: Thu, 05 Aug 2004 03:43:26 -0400 To: rchou@arubanetworks.com,radiusext@ops.ietf.org From: Paul Funk Subject: Re: shared secret vulnerability Cc: cchaplin@sj.symbol.com,Joshua Wright Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Randy, See my last email. (I responded before I saw this one.) I will clarify the actual vs. effective entropy issue in the next draft. Also, I'll put some text in about the precomputed dictionary attack, which isn't in the current draft. Paul Randy Chou wrote: Yes, you're right. I also missed that the first time I read Paul's draft. Entropy would only be increased if the possible number of outputs increased. Since the salt is fixed (and known anyways based on PKCS#5), the number of possible outputs only depends on the precursor secret itself. The representation of the output increased so that would make it harder to brute force. But that's not to say that someone would not be able to find a faster way to reach the result besides the brute force method. It just seems very very difficult. So Paul, the following comment may need to be revised depending on interpretation: > Differently stated, 20 bits of effective entropy are added to a secret when hashed one million times; thus, a secret with 40 bits of entropy provides 60 bits of effective entropy after amplification Regards, -- Randy -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Clint Chaplin Sent: Wednesday, August 04, 2004 2:00 PM To: jwright@hasborg.com; radiusext@ops.ietf.org Subject: Re: shared secret vulnerability My impression is that hashing doesn't add any more entropy than was already present in the input. Yes, hashing adds time to the calculation, but the output itself isn't any more entropic than the input was. Am I incorrect? Clint (JOATMON) Chaplin >>> Joshua Wright 08/04/04 13:54 PM >>> Paul Funk wrote: > The idea is that you take an ordinary secret, hash it many times, > and get a resulting "amplified" shared secret that multiplies the > difficulty of attack by the number of times it has been hashed. The > draft suggests 0x100000 (~ one million) iterations, adding 2 ^ 20 > bits of effective entropy to the secret. While I believe this algorithm is effective at adding entropy to a password such as the RADIUS secret, it does not resolve the issue of a widespread shared secret distributed throughout an organization. Without a mechanism in place to regularly change the secret, the use of shared secrets in this fashion is reminiscent of WEP pre-shared keys. As most people are painfully aware, shared secret do not stay secretive. That being said, I like Paul's idea for effectively adding entropy to the shared secret that will prolong a brute-force attack. However, I do not believe that this is effective at resolving weak authentication between the RADIUS authentication server and NAS. -Joshua Wright jwright@sans.org or jwright@hasborg.com -- -Joshua Wright jwright@hasborg.com http://home.jwu.edu/jwright/ pgpkey: http://home.jwu.edu/jwright/pgpkey.htm fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73 Paul Funk Funk Software, Inc. 617 497-6339 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, 05 Aug 2004 07:35:21 +0000 Message-Id: <5.2.0.9.2.20040805032253.0385cb30@mail.funk.com> Date: Thu, 05 Aug 2004 03:34:56 -0400 To: cchaplin@sj.symbol.com,radiusext@ops.ietf.org From: Paul Funk Subject: Re: shared secret vulnerability Cc: Joshua Wright Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_231727500==.ALT" --=====================_231727500==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Clint, Yes, the entropy isn't really increased. In the amplification draft, I often used the term "effective entropy", since it is really that the added difficulty in attacking the hashed secret makes it equivalent in entropy to a stronger secret for the purpose of dictionary attack. There is a "precomputed" type of dictionary attack in which a dictionary is computed in advance and stored on, say, CD-ROM. The CD-ROM items are then used to attack a signature. Thus, if the attacker first created a CD-ROM of all amplified shared secrets based on likely precursor secrets, the attack from such a CD-ROM against a signature with an amplified secret would be no harder than an attack against a signature based on a precursor secret. This illustrates your point about conservation of entropy. However, to create such a CD-ROM would take a very, very long time and you'd need lots of CD-ROMs. Paul Clint Chapin wrote: My impression is that hashing doesn't add any more entropy than was already present in the input. Yes, hashing adds time to the calculation, but the output itself isn't any more entropic than the input was. Am I incorrect? Clint (JOATMON) Chaplin >>> Joshua Wright 08/04/04 13:54 PM >>> Paul Funk wrote: > The idea is that you take an ordinary secret, hash it many times, > and get a resulting "amplified" shared secret that multiplies the > difficulty of attack by the number of times it has been hashed. The > draft suggests 0x100000 (~ one million) iterations, adding 2 ^ 20 > bits of effective entropy to the secret. While I believe this algorithm is effective at adding entropy to a password such as the RADIUS secret, it does not resolve the issue of a widespread shared secret distributed throughout an organization. Without a mechanism in place to regularly change the secret, the use of shared secrets in this fashion is reminiscent of WEP pre-shared keys. As most people are painfully aware, shared secret do not stay secretive. That being said, I like Paul's idea for effectively adding entropy to the shared secret that will prolong a brute-force attack. However, I do not believe that this is effective at resolving weak authentication between the RADIUS authentication server and NAS. -Joshua Wright jwright@sans.org or jwright@hasborg.com -- -Joshua Wright jwright@hasborg.com http://home.jwu.edu/jwright/ pgpkey: http://home.jwu.edu/jwright/pgpkey.htm fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73 Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com --=====================_231727500==.ALT Content-Type: text/html; charset="us-ascii" Clint,

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

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

Paul

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

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

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

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

-Joshua Wright
jwright@sans.org or
jwright@hasborg.com

--
-Joshua Wright
jwright@hasborg.com
http://home.jwu.edu/jwright/

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



Paul Funk
Funk Software, Inc.
617 497-6339
paul@funk.com
--=====================_231727500==.ALT-- -- 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, 05 Aug 2004 07:28:36 +0000 Message-ID: <05e001c47abe$6ef10280$020aa8c0@FATCAT> From: "Randy Chou" To: , "Paul Funk" Cc: , , "Bernard Aboba" Subject: Re: shared secret vulnerability Date: Thu, 5 Aug 2004 00:32:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Comments inline before I go to sleep...[rc]... Regards, -- Randy ----- Original Message ----- From: Paul Funk To: radiusext@ops.ietf.org ; rchou@arubanetworks.com Cc: merv@arubanetworks.com ; jwright@sans.org ; Bernard Aboba Sent: Thursday, August 05, 2004 12:04 AM Subject: Re: shared secret vulnerability Randy, See inline. (My comments marked [pf] ). Paul --- from Randy Chou --- Thanks Paul for your draft and discussing with me on Monday. We can go into further detail during Thursday's meeting, but here are some comments to think about: - The draft-funk-radiusext-shared-secret-amp-00.txt doc provides a practical way for people to still remember short passwords while providing good entropy. It would be good IMO to categorize the environments this provides adequate security and the environments that it doesn't. [pf] I agree. I think intra-domain vs. inter-domain might be a way to slice this. Also, the ability to segregate administrative traffic from user traffic is important. [rc] I like that. Especially now that there are Radius services on the internet being provided for 802.1x. Scary eh? - As I pointed in a previous email, this still wouldn't protect cases where the shared secret is somehow exposed. Perhaps we can document this better in the radius_vuln_00.txt draft as comments so far have been focusing on short shared secrets which was only one aspect of what was documented. Consumers have been educated for many years to understand that exposure to the private key (assuming RSA) of a certificate is the only way to decrypt packets through sniffing during TLS handshakes. So certs are protected very carefully and access to it is very limited. However, in a wifi environment w/ 802.1x, exposure of a previous Radius shared secret can also allow an attacker to decrypt wireless packets. So from an encryption point of view, losing the current or any previously used Radius shared secret can be as fatal as losing the server cert. I don't think many consumers understand that correlation and many would be shocked if they knew. The more security-conscious consumers use a combination of DH w/ RSA or ephemeral RSA so even losing the server cert doesn't allow for data decryption. The fact that data decryption is still achievable only through the loss of the Radius shared key makes Radius look very bad IMO. [pf] I agree that people should understand the implications of their security choices. But since they are entering shared secrets into security servers, you'd think people would understand that it must be important to the security of their operations. [rc] Note that the shared secrets also go into generic NAS devices that normally don't provide security features. [pf] Yes, DH will provide perfect forward secrecy, though I'm not sure how many people attempt to configure that vs. use whatever the default cipher suite happens to be. [pf] Whether you are protecting a private key or a shared secret, you need to secure the equipment that uses it. I'm not sure that a shared secret on a server is any less secure than a private key. Also, you have to worry about your backup tapes! [rc] Agreed, and this isn't just a Radius problem (SNMP, telnet,...etc). I think a shared secret versus cert difference is that the shared secret also resides on many NAS devices which makes it much more difficult to protect. - Would like to understand why you think IPSEC is so hard to use. They're available in most generic OSes where Radius servers are run and on many NAS devices. As to ease of deployment, I think this needs to be compared to having to rotate RADIUS shared keys routinely on potentially hundreds of NAS devices without duplicate usage, and making sure previous keys are never exposed. [pf] If it's not hard to use, why isn't it used more? Maintaining a PKI is administratively challenging. Yes, OSes have built in support, but NASes may run on platforms where IPsec is not readily available. I doubt also that diligent shared secret rotation is all that common. [rc] IPSEC is deployed widely for end-users. My theory as to why it's not commonly used for Radius (there are some that do use it) is because of lack of understanding (amongst consumers) of the seriousness of the problem and because it's only a recommendation in the RFC as opposed to an absolute requirement. Hence the draft we wrote. - Would like to hear security analysis of other uses of Radius besides 802.1x/wireless if anyone else has something to share. Regards, -- Randy ----- Original Message ----- From: "Paul Funk" To: Cc: ; ; ; "Bernard Aboba" Sent: Monday, August 02, 2004 10:11 AM Subject: shared secret vulnerability > To further the discussion of shared secret vulnerability brought > up in radius_vuln_00.txt, here is a proposal for using PKCS-5 > to create shared secrets with enhanced resistance to dictionary > attack. > > The idea is that you take an ordinary secret, hash it many times, > and get a resulting "amplified" shared secret that multiplies the > difficulty of attack by the number of times it has been hashed. The > draft suggests 0x100000 (~ one million) iterations, adding 2 ^ 20 > bits of effective entropy to the secret. > > The draft can be found at: > http://www.funk.com/documents/draft-funk-radiusext-shared-secret-amp-00.txt > > A demo of shared secret amplification can be found at: > http://www.funk.com/passwordamplifier > > Here is the abstract: > > This draft describes how a mechanism defined in [PKCS-5] can be used > to amplify the security of a RADIUS shared secret; namely, that a > precursor secret is hashed many times to produce an amplified shared > secret for use in RADIUS. > > A dictionary attack against the resulting shared secret will be > infeasible due to its high entropy. A dictionary attack against the > precursor secret will require the attacker to apply the same hashing > process to each candidate precursor secret to derive a candidate > RADIUS shared secret, prior to applying it to the RADIUS packet. > > This approach allows administrators to use the same types of secrets > that they are comfortable with as precursor secrets. The algorithm > to generate the amplified shared secret is deterministic, so the > precursor shared secret is all that needs to be remembered. > > Unlike approaches that require changes to RADIUS servers and > clients, the amplification approach is compatible with all current > equipment. It is simply a means to generate a shared secret, which > then may be configured in the NAS or RADIUS server just as any > shared secret would be. For example, a simple utility can accept the > precursor secret, amplify it, and present it to the administrator, > who may copy and paste it into the configuration application of a > RADIUS server or NAS. > > Paul > > > Paul Funk > Funk Software, Inc. > 617 497-6339 > paul@funk.com > > 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, 05 Aug 2004 07:21:14 +0000 Message-Id: <5.2.0.9.2.20040805030652.03e56008@mail.funk.com> Date: Thu, 05 Aug 2004 03:17:02 -0400 To: radiusext@ops.ietf.org,Joshua Wright From: Paul Funk Subject: Re: shared secret vulnerability Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Joshua, Yes, widespread use of the same secret makes it less likely to stay secret. One of things the amplification draft discusses is use of a salt to allow it to be easier to use different shared secrets on different devices. The salt is set by the administrator and defines the minimum entropy of all shared secrets derived from it. Each technician can then make up different precursor secrets for different devices; these can be much weaker, since the salt entropy is added to the entropy of the precursor. Note that the salt as used here is has a different purpose than as defined in PKCS-5. It is not random data generated for each use of a secret and displayed as clear text. It itself is kept secret. In fact, it's best if the salt is a closely held secret of the administrator, and baked into a utility that technicians can use when they amplify the precursor secrets. Paul Joshua Wright wrote: Paul Funk wrote: > The idea is that you take an ordinary secret, hash it many times, > and get a resulting "amplified" shared secret that multiplies the > difficulty of attack by the number of times it has been hashed. The > draft suggests 0x100000 (~ one million) iterations, adding 2 ^ 20 > bits of effective entropy to the secret. While I believe this algorithm is effective at adding entropy to a password such as the RADIUS secret, it does not resolve the issue of a widespread shared secret distributed throughout an organization. Without a mechanism in place to regularly change the secret, the use of shared secrets in this fashion is reminiscent of WEP pre-shared keys. As most people are painfully aware, shared secret do not stay secretive. That being said, I like Paul's idea for effectively adding entropy to the shared secret that will prolong a brute-force attack. However, I do not believe that this is effective at resolving weak authentication between the RADIUS authentication server and NAS. -Joshua Wright jwright@sans.org or jwright@hasborg.com -- -Joshua Wright jwright@hasborg.com http://home.jwu.edu/jwright/ 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, 05 Aug 2004 07:05:23 +0000 Message-Id: <5.2.0.9.2.20040805023926.03e57c08@mail.funk.com> Date: Thu, 05 Aug 2004 03:04:35 -0400 To: , From: Paul Funk Subject: Re: shared secret vulnerability Cc: ,, "Bernard Aboba" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_229906781==.ALT" --=====================_229906781==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Randy, See inline. (My comments marked [pf] ). Paul --- from Randy Chou --- Thanks Paul for your draft and discussing with me on Monday. We can go into further detail during Thursday's meeting, but here are some comments to think about: - The draft-funk-radiusext-shared-secret-amp-00.txt doc provides a practical way for people to still remember short passwords while providing good entropy. It would be good IMO to categorize the environments this provides adequate security and the environments that it doesn't. [pf] I agree. I think intra-domain vs. inter-domain might be a way to slice this. Also, the ability to segregate administrative traffic from user traffic is important. - As I pointed in a previous email, this still wouldn't protect cases where the shared secret is somehow exposed. Perhaps we can document this better in the radius_vuln_00.txt draft as comments so far have been focusing on short shared secrets which was only one aspect of what was documented. Consumers have been educated for many years to understand that exposure to the private key (assuming RSA) of a certificate is the only way to decrypt packets through sniffing during TLS handshakes. So certs are protected very carefully and access to it is very limited. However, in a wifi environment w/ 802.1x, exposure of a previous Radius shared secret can also allow an attacker to decrypt wireless packets. So from an encryption point of view, losing the current or any previously used Radius shared secret can be as fatal as losing the server cert. I don't think many consumers understand that correlation and many would be shocked if they knew. The more security-conscious consumers use a combination of DH w/ RSA or ephemeral RSA so even losing the server cert doesn't allow for data decryption. The fact that data decryption is still achievable only through the loss of the Radius shared key makes Radius look very bad IMO. [pf] I agree that people should understand the implications of their security choices. But since they are entering shared secrets into security servers, you'd think people would understand that it must be important to the security of their operations. [pf] Yes, DH will provide perfect forward secrecy, though I'm not sure how many people attempt to configure that vs. use whatever the default cipher suite happens to be. [pf] Whether you are protecting a private key or a shared secret, you need to secure the equipment that uses it. I'm not sure that a shared secret on a server is any less secure than a private key. Also, you have to worry about your backup tapes! - Would like to understand why you think IPSEC is so hard to use. They're available in most generic OSes where Radius servers are run and on many NAS devices. As to ease of deployment, I think this needs to be compared to having to rotate RADIUS shared keys routinely on potentially hundreds of NAS devices without duplicate usage, and making sure previous keys are never exposed. [pf] If it's not hard to use, why isn't it used more? Maintaining a PKI is administratively challenging. Yes, OSes have built in support, but NASes may run on platforms where IPsec is not readily available. I doubt also that diligent shared secret rotation is all that common. - Would like to hear security analysis of other uses of Radius besides 802.1x/wireless if anyone else has something to share. Regards, -- Randy ----- Original Message ----- From: "Paul Funk" To: Cc: ; ; ; "Bernard Aboba" Sent: Monday, August 02, 2004 10:11 AM Subject: shared secret vulnerability > To further the discussion of shared secret vulnerability brought > up in radius_vuln_00.txt, here is a proposal for using PKCS-5 > to create shared secrets with enhanced resistance to dictionary > attack. > > The idea is that you take an ordinary secret, hash it many times, > and get a resulting "amplified" shared secret that multiplies the > difficulty of attack by the number of times it has been hashed. The > draft suggests 0x100000 (~ one million) iterations, adding 2 ^ 20 > bits of effective entropy to the secret. > > The draft can be found at: > http://www.funk.com/documents/draft-funk-radiusext-shared-secret-amp-00.txt > > A demo of shared secret amplification can be found at: > http://www.funk.com/passwordamplifier > > Here is the abstract: > > This draft describes how a mechanism defined in [PKCS-5] can be used > to amplify the security of a RADIUS shared secret; namely, that a > precursor secret is hashed many times to produce an amplified shared > secret for use in RADIUS. > > A dictionary attack against the resulting shared secret will be > infeasible due to its high entropy. A dictionary attack against the > precursor secret will require the attacker to apply the same hashing > process to each candidate precursor secret to derive a candidate > RADIUS shared secret, prior to applying it to the RADIUS packet. > > This approach allows administrators to use the same types of secrets > that they are comfortable with as precursor secrets. The algorithm > to generate the amplified shared secret is deterministic, so the > precursor shared secret is all that needs to be remembered. > > Unlike approaches that require changes to RADIUS servers and > clients, the amplification approach is compatible with all current > equipment. It is simply a means to generate a shared secret, which > then may be configured in the NAS or RADIUS server just as any > shared secret would be. For example, a simple utility can accept the > precursor secret, amplify it, and present it to the administrator, > who may copy and paste it into the configuration application of a > RADIUS server or NAS. > > Paul > > > Paul Funk > Funk Software, Inc. > 617 497-6339 > paul@funk.com > > Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com --=====================_229906781==.ALT Content-Type: text/html; charset="us-ascii" Randy,

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

Paul

--- from Randy Chou ---

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

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

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

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

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

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

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

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

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

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

Regards,

--
Randy


----- Original Message -----
From: "Paul Funk" <paul@funk.com>
To: <radiusext@ops.ietf.org>
Cc: <rchou@arubanetworks.com>; <merv@arubanetworks.com>; <jwright@sans.org>;
"Bernard Aboba" <aboba@internaut.com>
Sent: Monday, August 02, 2004 10:11 AM
Subject: shared secret vulnerability


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


Paul Funk
Funk Software, Inc.
617 497-6339
paul@funk.com
--=====================_229906781==.ALT-- -- 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, 04 Aug 2004 23:28:26 +0000 Message-Id: <6.1.2.0.0.20040804192250.01dc9d00@getmail.mitton.com> Date: Wed, 04 Aug 2004 19:28:01 -0400 To: radiusext@ops.ietf.org From: David Mitton Subject: Re: shared secret vulnerability Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 8/4/2004 04:50 PM, Joshua Wright wrote: >While I believe this algorithm is effective at adding entropy to a >password such as the RADIUS secret, it does not resolve the issue of a >widespread shared secret distributed throughout an organization. Without a >mechanism in place to regularly change the secret, the use of shared >secrets in this fashion is reminiscent of WEP pre-shared keys. As most >people are painfully aware, shared secret do not stay secretive. While I agree with the sentiment, I'd like to attempt to point out another possible implementation issue. Unlike WEP, there is nothing in RADIUS that requires the shared secrets to be the same for all partners. In many (most?) implementations, the secret can be unique for each source IP address. Essentially any pair of RADIUS client/servers can have unique secrets. Dave. -- to unsubscribe send a message to 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, 04 Aug 2004 22:36:16 +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: shared secret vulnerability Date: Wed, 4 Aug 2004 15:35:05 -0700 Message-ID: Thread-Topic: shared secret vulnerability Thread-Index: AcR6ZoXEL8bmacyfSvOnbVaU4Yvo/wAC1jQA From: "Randy Chou" To: "Clint Chaplin" , , Yes, you're right. I also missed that the first time I read Paul's draft. Entropy would only be increased if the possible number of outputs increased. Since the salt is fixed (and known anyways based on PKCS#5), the number of possible outputs only depends on the precursor secret itself. The representation of the output increased so that would make it harder to brute force. But that's not to say that someone would not be able to find a faster way to reach the result besides the brute force method. It just seems very very difficult. So Paul, the following comment may need to be revised depending on interpretation: > Differently stated, 20=20 bits of effective entropy are added to a secret when hashed one=20 million times; thus, a secret with 40 bits of entropy provides 60=20 bits of effective entropy after amplification Regards, -- Randy -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Clint Chaplin Sent: Wednesday, August 04, 2004 2:00 PM To: jwright@hasborg.com; radiusext@ops.ietf.org Subject: Re: shared secret vulnerability My impression is that hashing doesn't add any more entropy than was already present in the input. Yes, hashing adds time to the calculation, but the output itself isn't any more entropic than the input was. Am I incorrect? Clint (JOATMON) Chaplin >>> Joshua Wright 08/04/04 13:54 PM >>> Paul Funk wrote: > The idea is that you take an ordinary secret, hash it many times, > and get a resulting "amplified" shared secret that multiplies the > difficulty of attack by the number of times it has been hashed. The > draft suggests 0x100000 (~ one million) iterations, adding 2 ^ 20 > bits of effective entropy to the secret. While I believe this algorithm is effective at adding entropy to a=20 password such as the RADIUS secret, it does not resolve the issue of a=20 widespread shared secret distributed throughout an organization. Without a mechanism in place to regularly change the secret, the use of shared=20 secrets in this fashion is reminiscent of WEP pre-shared keys. As most=20 people are painfully aware, shared secret do not stay secretive. That being said, I like Paul's idea for effectively adding entropy to=20 the shared secret that will prolong a brute-force attack. However, I do not believe that this is effective at resolving weak authentication=20 between the RADIUS authentication server and NAS. -Joshua Wright jwright@sans.org or jwright@hasborg.com --=20 -Joshua Wright jwright@hasborg.com http://home.jwu.edu/jwright/ pgpkey: http://home.jwu.edu/jwright/pgpkey.htm fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73 -- to unsubscribe send a message to 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: -- 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, 04 Aug 2004 21:00:30 +0000 Message-Id: Date: Wed, 04 Aug 2004 13:59:35 -0700 From: "Clint Chaplin" To: , Subject: Re: shared secret vulnerability Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline My impression is that hashing doesn't add any more entropy than was = already present in the input. Yes, hashing adds time to the calculation, = but the output itself isn't any more entropic than the input was. Am I = incorrect? Clint (JOATMON) Chaplin >>> Joshua Wright 08/04/04 13:54 PM >>> Paul Funk wrote: > The idea is that you take an ordinary secret, hash it many times, > and get a resulting "amplified" shared secret that multiplies the > difficulty of attack by the number of times it has been hashed. The > draft suggests 0x100000 (~ one million) iterations, adding 2 ^ 20 > bits of effective entropy to the secret. While I believe this algorithm is effective at adding entropy to a=20 password such as the RADIUS secret, it does not resolve the issue of a=20 widespread shared secret distributed throughout an organization. Without=20= a mechanism in place to regularly change the secret, the use of shared=20 secrets in this fashion is reminiscent of WEP pre-shared keys. As most=20 people are painfully aware, shared secret do not stay secretive. That being said, I like Paul's idea for effectively adding entropy to=20 the shared secret that will prolong a brute-force attack. However, I = do=20 not believe that this is effective at resolving weak authentication=20 between the RADIUS authentication server and NAS. -Joshua Wright jwright@sans.org or jwright@hasborg.com --=20 -Joshua Wright jwright@hasborg.com http://home.jwu.edu/jwright/ pgpkey: http://home.jwu.edu/jwright/pgpkey.htm fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73 -- to unsubscribe send a message to 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, 04 Aug 2004 20:51:43 +0000 Message-ID: <41114C1A.4000604@hasborg.com> Date: Wed, 04 Aug 2004 16:50:34 -0400 From: Joshua Wright User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: shared secret vulnerability Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Paul Funk wrote: > The idea is that you take an ordinary secret, hash it many times, > and get a resulting "amplified" shared secret that multiplies the > difficulty of attack by the number of times it has been hashed. The > draft suggests 0x100000 (~ one million) iterations, adding 2 ^ 20 > bits of effective entropy to the secret. While I believe this algorithm is effective at adding entropy to a password such as the RADIUS secret, it does not resolve the issue of a widespread shared secret distributed throughout an organization. Without a mechanism in place to regularly change the secret, the use of shared secrets in this fashion is reminiscent of WEP pre-shared keys. As most people are painfully aware, shared secret do not stay secretive. That being said, I like Paul's idea for effectively adding entropy to the shared secret that will prolong a brute-force attack. However, I do not believe that this is effective at resolving weak authentication between the RADIUS authentication server and NAS. -Joshua Wright jwright@sans.org or jwright@hasborg.com -- -Joshua Wright jwright@hasborg.com http://home.jwu.edu/jwright/ pgpkey: http://home.jwu.edu/jwright/pgpkey.htm fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73 -- to unsubscribe send a message to 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, 04 Aug 2004 07:09:47 +0000 Message-ID: <032f01c479f2$894abe40$020aa8c0@FATCAT> From: "Randy Chou" To: , "Paul Funk" Cc: , , "Bernard Aboba" , "Randy Chou" Subject: Re: shared secret vulnerability Date: Wed, 4 Aug 2004 00:13:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thanks Paul for your draft and discussing with me on Monday. We can go into further detail during Thursday's meeting, but here are some comments to think about: - The draft-funk-radiusext-shared-secret-amp-00.txt doc provides a practical way for people to still remember short passwords while providing good entropy. It would be good IMO to categorize the environments this provides adequate security and the environments that it doesn't. - As I pointed in a previous email, this still wouldn't protect cases where the shared secret is somehow exposed. Perhaps we can document this better in the radius_vuln_00.txt draft as comments so far have been focusing on short shared secrets which was only one aspect of what was documented. Consumers have been educated for many years to understand that exposure to the private key (assuming RSA) of a certificate is the only way to decrypt packets through sniffing during TLS handshakes. So certs are protected very carefully and access to it is very limited. However, in a wifi environment w/ 802.1x, exposure of a previous Radius shared secret can also allow an attacker to decrypt wireless packets. So from an encryption point of view, losing the current or any previously used Radius shared secret can be as fatal as losing the server cert. I don't think many consumers understand that correlation and many would be shocked if they knew. The more security-conscious consumers use a combination of DH w/ RSA or ephemeral RSA so even losing the server cert doesn't allow for data decryption. The fact that data decryption is still achievable only through the loss of the Radius shared key makes Radius look very bad IMO. - Would like to understand why you think IPSEC is so hard to use. They're available in most generic OSes where Radius servers are run and on many NAS devices. As to ease of deployment, I think this needs to be compared to having to rotate RADIUS shared keys routinely on potentially hundreds of NAS devices without duplicate usage, and making sure previous keys are never exposed. - Would like to hear security analysis of other uses of Radius besides 802.1x/wireless if anyone else has something to share. Regards, -- Randy ----- Original Message ----- From: "Paul Funk" To: Cc: ; ; ; "Bernard Aboba" Sent: Monday, August 02, 2004 10:11 AM Subject: shared secret vulnerability > To further the discussion of shared secret vulnerability brought > up in radius_vuln_00.txt, here is a proposal for using PKCS-5 > to create shared secrets with enhanced resistance to dictionary > attack. > > The idea is that you take an ordinary secret, hash it many times, > and get a resulting "amplified" shared secret that multiplies the > difficulty of attack by the number of times it has been hashed. The > draft suggests 0x100000 (~ one million) iterations, adding 2 ^ 20 > bits of effective entropy to the secret. > > The draft can be found at: > http://www.funk.com/documents/draft-funk-radiusext-shared-secret-amp-00.txt > > A demo of shared secret amplification can be found at: > http://www.funk.com/passwordamplifier > > Here is the abstract: > > This draft describes how a mechanism defined in [PKCS-5] can be used > to amplify the security of a RADIUS shared secret; namely, that a > precursor secret is hashed many times to produce an amplified shared > secret for use in RADIUS. > > A dictionary attack against the resulting shared secret will be > infeasible due to its high entropy. A dictionary attack against the > precursor secret will require the attacker to apply the same hashing > process to each candidate precursor secret to derive a candidate > RADIUS shared secret, prior to applying it to the RADIUS packet. > > This approach allows administrators to use the same types of secrets > that they are comfortable with as precursor secrets. The algorithm > to generate the amplified shared secret is deterministic, so the > precursor shared secret is all that needs to be remembered. > > Unlike approaches that require changes to RADIUS servers and > clients, the amplification approach is compatible with all current > equipment. It is simply a means to generate a shared secret, which > then may be configured in the NAS or RADIUS server just as any > shared secret would be. For example, a simple utility can accept the > precursor secret, amplify it, and present it to the administrator, > who may copy and paste it into the configuration application of a > RADIUS server or NAS. > > Paul > > > Paul Funk > Funk Software, Inc. > 617 497-6339 > 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: Mon, 02 Aug 2004 17:14:48 +0000 Message-Id: <5.2.0.9.2.20040802125051.03d20230@mail.funk.com> Date: Mon, 02 Aug 2004 13:11:10 -0400 To: radiusext@ops.ietf.org From: Paul Funk Subject: shared secret vulnerability Cc: rchou@arubanetworks.com,merv@arubanetworks.com,jwright@sans.org, Bernard Aboba Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed To further the discussion of shared secret vulnerability brought up in radius_vuln_00.txt, here is a proposal for using PKCS-5 to create shared secrets with enhanced resistance to dictionary attack. The idea is that you take an ordinary secret, hash it many times, and get a resulting "amplified" shared secret that multiplies the difficulty of attack by the number of times it has been hashed. The draft suggests 0x100000 (~ one million) iterations, adding 2 ^ 20 bits of effective entropy to the secret. The draft can be found at: http://www.funk.com/documents/draft-funk-radiusext-shared-secret-amp-00.txt A demo of shared secret amplification can be found at: http://www.funk.com/passwordamplifier Here is the abstract: This draft describes how a mechanism defined in [PKCS-5] can be used to amplify the security of a RADIUS shared secret; namely, that a precursor secret is hashed many times to produce an amplified shared secret for use in RADIUS. A dictionary attack against the resulting shared secret will be infeasible due to its high entropy. A dictionary attack against the precursor secret will require the attacker to apply the same hashing process to each candidate precursor secret to derive a candidate RADIUS shared secret, prior to applying it to the RADIUS packet. This approach allows administrators to use the same types of secrets that they are comfortable with as precursor secrets. The algorithm to generate the amplified shared secret is deterministic, so the precursor shared secret is all that needs to be remembered. Unlike approaches that require changes to RADIUS servers and clients, the amplification approach is compatible with all current equipment. It is simply a means to generate a shared secret, which then may be configured in the NAS or RADIUS server just as any shared secret would be. For example, a simple utility can accept the precursor secret, amplify it, and present it to the administrator, who may copy and paste it into the configuration application of a RADIUS server or NAS. Paul Paul Funk Funk Software, Inc. 617 497-6339 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: Mon, 02 Aug 2004 15:58:47 +0000 Date: Mon, 2 Aug 2004 08:54:06 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: REMINDER: Slides needed! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII If you are presenting at the RADEXT WG meeting today, please send your slides to myself and David NOW. The meeting is tightly scheduled and so we will have all the slides preloaded on the laptop, ready to go. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: