From daemon@optimus.ietf.org Thu Mar 14 19:42:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06045 for ; Thu, 14 Mar 2002 19:42:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA20490 for sip-security-archive@odin.ietf.org; Thu, 14 Mar 2002 19:42:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20172; Thu, 14 Mar 2002 19:38:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20132 for ; Thu, 14 Mar 2002 19:38:55 -0500 (EST) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05956; Thu, 14 Mar 2002 19:38:52 -0500 (EST) Received: from [129.46.77.186] (eriador.qualcomm.com [129.46.77.186]) by mage.qualcomm.com (8.12.1/8.12.1/1.0) with ESMTP id g2F0c0Jw007529; Thu, 14 Mar 2002 16:38:01 -0800 (PST) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: References: X-Mailer: eudora51carbon-0314020912 X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Thu, 14 Mar 2002 16:37:48 -0800 To: sipping@ietf.org, sip-security@ietf.org From: John W Noerenberg II Cc: Greg Rose , aki.niemi@nokia.com, jari.arkko@ericsson.com, vesa.torvinen@ericsson.fi, James Undery , Sanjoy Sen Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Sip-security] SIP authentication problem when using RES in Digest-AKA Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Greg Rose has identified a security problem when HTTP-Digest is combined with the mechanism proposed in draft-niemi-sipping-digest-aka-00 and draft-undery-sip-auth-00. He's outlined this for the 3GPP TSG SA WG3, one of the TSG security area working groups. Essentially the problem is a consequence of using a RES that is shorter than the key from which it is derived, typically as small as 32 bits. RES's length results from the goal of maintaining backward compatibility with existing USIMs. RES is a choke point that can be used to break the authentication. Instead of using RES, IK has much greater entropy, and makes the attack prohibitively difficult. A description of the attack against RES is given below. The authentication process can be summarized as follows: 1. UE attempts to register. 2. The attempt is rejected because the UE is unauthenticated. The rejection message includes AKA-related information and an HTTP-Digest nonce. 3. UE/USIM checks the AKA information and computes RES. 4. RES is now used as the password shared by the UE and the CSCF. 5. UE computes HTTP-Digest response based on RES, and attempts to register. 6. Registration succeeds. Subsequently 7. UE sends another SIP message (e.g. Invite) and the HTTP-Digest method calculates authentication information based on RES. (Actually, A1 is used, but it is derived from RES). Choke Point Attack An attacker monitoring the traffic would break the scheme as follows: The attacker has all the messages from steps 2 and 5 above. All of the information used in the calculation of the response in step 5, except for the value of RES is present in these messages. Assuming RES is 32 bits, the attacker tries the 2**32 possible values, comparing them to the captured response generated for step 5. With very high probability, he will succeed with exactly one candidate value for RES, in the time needed to calculate 2**31 MD5 hashes. This takes ~5 minutes on a typical laptop. Once the value of RES is known, the attacker can now forge SIP messages or alter them in transit, recalculating the Digest after altering the message. By replacing the use of RES with a higher entropy quantity, this attack can be prevented. As noted above, Greg recommends using IK as a replacement for RES. best, -- john noerenberg jwn2@qualcomm.com -------------------------------------------------------------------------- The truth knocks on the door and you say, "Go away, I'm looking for the truth," and so it goes away. Puzzling. -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974 -------------------------------------------------------------------------- _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Thu Mar 14 19:49:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06232 for ; Thu, 14 Mar 2002 19:49:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA21029 for sip-security-archive@odin.ietf.org; Thu, 14 Mar 2002 19:49:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20915; Thu, 14 Mar 2002 19:48:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20833 for ; Thu, 14 Mar 2002 19:48:45 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06214; Thu, 14 Mar 2002 19:48:43 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2F0mBh16703; Thu, 14 Mar 2002 18:48:11 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 18:48:13 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E011879EA@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'John W Noerenberg II'" , sipping@ietf.org, sip-security@ietf.org Cc: Greg Rose , aki.niemi@nokia.com, jari.arkko@ericsson.com, vesa.torvinen@ericsson.fi, James Undery Date: Thu, 14 Mar 2002 18:48:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CBBB.147ACE80" Subject: [Sip-security] RE: SIP authentication problem when using RES in Digest-AKA Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1CBBB.147ACE80 Content-Type: text/plain; charset="iso-8859-1" draft-undery-sip-auth-00.txt doesn't make any recommendation as to how the password should be computed. However, I remember that when we took the proposal of using Digest for the first time to 3GPP, we had recommended using IK as the password. Sanjoy > -----Original Message----- > From: John W Noerenberg II [mailto:jwn2@qualcomm.com] > Sent: Thursday, March 14, 2002 6:38 PM > To: sipping@ietf.org; sip-security@ietf.org > Cc: Greg Rose; aki.niemi@nokia.com; jari.arkko@ericsson.com; > vesa.torvinen@ericsson.fi; James Undery; Sen, Sanjoy [NGC:B692:EXCH] > Subject: SIP authentication problem when using RES in Digest-AKA > > > Greg Rose has identified a security problem when HTTP-Digest is > combined with the mechanism proposed in > draft-niemi-sipping-digest-aka-00 and draft-undery-sip-auth-00. He's > outlined this for the 3GPP TSG SA WG3, one of the TSG security area > working groups. > > Essentially the problem is a consequence of using a RES that is > shorter than the key from which it is derived, typically as small as > 32 bits. RES's length results from the goal of maintaining backward > compatibility with existing USIMs. RES is a choke point that can be > used to break the authentication. Instead of using RES, IK has much > greater entropy, and makes the attack prohibitively difficult. A > description of the attack against RES is given below. > > The authentication process can be summarized as follows: > > 1. UE attempts to register. > 2. The attempt is rejected because the UE is unauthenticated. The > rejection message includes AKA-related information and an HTTP-Digest > nonce. > 3. UE/USIM checks the AKA information and computes RES. > 4. RES is now used as the password shared by the UE and the CSCF. > 5. UE computes HTTP-Digest response based on RES, and > attempts to register. > 6. Registration succeeds. > > Subsequently > > 7. UE sends another SIP message (e.g. Invite) and the HTTP-Digest > method calculates authentication information based on RES. > (Actually, A1 is used, but it is derived from RES). > > Choke Point Attack > > An attacker monitoring the traffic would break the scheme as follows: > > The attacker has all the messages from steps 2 and 5 above. All of > the information used in the calculation of the response in step 5, > except for the value of RES is present in these messages. Assuming > RES is 32 bits, the attacker tries the 2**32 possible values, > comparing them to the captured response generated for step 5. With > very high probability, he will succeed with exactly one candidate > value for RES, in the time needed to calculate 2**31 MD5 hashes. > This takes ~5 minutes on a typical laptop. > > Once the value of RES is known, the attacker can now forge SIP > messages or alter them in transit, recalculating the Digest after > altering the message. > > By replacing the use of RES with a higher entropy quantity, this > attack can be prevented. As noted above, Greg recommends using IK as > a replacement for RES. > > best, > -- > > john noerenberg > jwn2@qualcomm.com > > -------------------------------------------------------------- > ------------ > The truth knocks on the door and you say, "Go away, I'm looking > for the truth," and so it goes away. Puzzling. > -- Zen and the Art of Motorcycle Maintenance, Robert M. > Pirsig, 1974 > > -------------------------------------------------------------- > ------------ > ------_=_NextPart_001_01C1CBBB.147ACE80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: SIP authentication problem when using RES in = Digest-AKA

draft-undery-sip-auth-00.txt doesn't make any = recommendation as to how the password should be computed. However, I = remember that when we took the proposal of using Digest for the first = time to 3GPP, we had recommended using IK as the password.

Sanjoy

> -----Original Message-----
> From: John W Noerenberg II [mailto:jwn2@qualcomm.com]
> Sent: Thursday, March 14, 2002 6:38 PM
> To: sipping@ietf.org; = sip-security@ietf.org
> Cc: Greg Rose; aki.niemi@nokia.com; = jari.arkko@ericsson.com;
> vesa.torvinen@ericsson.fi; James Undery; Sen, = Sanjoy [NGC:B692:EXCH]
> Subject: SIP authentication problem when using = RES in Digest-AKA
>
>
> Greg Rose has identified a security problem = when HTTP-Digest is
> combined with the mechanism proposed in
> draft-niemi-sipping-digest-aka-00 and = draft-undery-sip-auth-00.  He's
> outlined this for the 3GPP TSG SA WG3, one of = the TSG security area
> working groups.
>
> Essentially the problem is a consequence of = using a RES that is
> shorter than the key from which it is derived, = typically as small as
> 32 bits.  RES's length results from the = goal of maintaining backward
> compatibility with existing USIMs.  RES is = a choke point that can be
> used to break the authentication.  Instead = of using RES, IK has much
> greater entropy, and makes the attack = prohibitively difficult.  A
> description of the attack against RES is given = below.
>
> The authentication process can be summarized as = follows:
>
> 1. UE attempts to register.
> 2. The attempt is rejected because the UE is = unauthenticated.  The
> rejection message includes AKA-related = information and an HTTP-Digest
> nonce.
> 3. UE/USIM checks the AKA information and = computes RES.
> 4. RES is now used as the password shared by = the UE and the CSCF.
> 5. UE computes HTTP-Digest response based on = RES, and
> attempts to register.
> 6. Registration succeeds.
>
> Subsequently
>
> 7. UE sends another SIP message (e.g. Invite) = and the HTTP-Digest
> method calculates authentication information = based on RES.
> (Actually, A1 is used, but it is derived from = RES).
>
> Choke Point Attack
>
> An attacker monitoring the traffic would break = the scheme as follows:
>
> The attacker has all the messages from steps 2 = and 5 above.  All of
> the information used in the calculation of the = response in step 5,
> except for the value of RES is present in these = messages.  Assuming
> RES is 32 bits, the attacker tries the 2**32 = possible values,
> comparing them to the captured response = generated for step 5.  With
> very high probability, he will succeed with = exactly one candidate
> value for RES, in the time needed to calculate = 2**31 MD5 hashes.
> This takes ~5 minutes on a typical = laptop.
>
> Once the value of RES is known, the attacker = can now forge SIP
> messages or alter them in transit, = recalculating the Digest after
> altering the message.
>
> By replacing the use of RES with a higher = entropy quantity, this
> attack can be prevented.  As noted above, = Greg recommends using IK as
> a replacement for RES.
>
> best,
> --
>
> john noerenberg
> jwn2@qualcomm.com
>   
> = --------------------------------------------------------------
> ------------
>    The truth knocks on the door = and you say, "Go away, I'm looking
>    for the truth,"  = and so it goes away.  Puzzling.
>    -- Zen and the Art of = Motorcycle Maintenance, Robert M.
> Pirsig, 1974
>   
> = --------------------------------------------------------------
> ------------
>

------_=_NextPart_001_01C1CBBB.147ACE80-- _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Thu Mar 14 20:18:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06824 for ; Thu, 14 Mar 2002 20:18:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA22720 for sip-security-archive@odin.ietf.org; Thu, 14 Mar 2002 20:18:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22659; Thu, 14 Mar 2002 20:18:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22617 for ; Thu, 14 Mar 2002 20:18:22 -0500 (EST) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06799; Thu, 14 Mar 2002 20:18:19 -0500 (EST) Received: from [129.46.77.186] (eriador.qualcomm.com [129.46.77.186]) by mage.qualcomm.com (8.12.1/8.12.1/1.0) with ESMTP id g2F1HxK2016537; Thu, 14 Mar 2002 17:18:04 -0800 (PST) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: <933FADF5E673D411B8A30002A5608A0E011879EA@zrc2c012.us.nortel.com> References: <933FADF5E673D411B8A30002A5608A0E011879EA@zrc2c012.us.nortel.com> X-Mailer: eudora51carbon-0314020912 X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Thu, 14 Mar 2002 17:15:41 -0800 To: "Sanjoy Sen" From: John W Noerenberg II Cc: sipping@ietf.org, sip-security@ietf.org, Greg Rose , aki.niemi@nokia.com, jari.arkko@ericsson.com, vesa.torvinen@ericsson.fi, James Undery Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Sip-security] [Sipping] RE: SIP authentication problem when using RES in Digest-AKA Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org At 6:48 PM -0600 3/14/02, Sanjoy Sen wrote: >I remember that when we took the proposal of using Digest for the >first time to 3GPP, we had recommended using IK as the password. I couldn't say why you were steered away from IK, since I don't spend any time in the 3GPP world. Based on Greg's analysis, I'd say you had it right the first time. best, -- john noerenberg jwn2@qualcomm.com -------------------------------------------------------------------- We all learn here by the honorable path of horrible mistakes. -- Katherine Paterson, "The Master Puppeteer," 1975 -------------------------------------------------------------------- _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Thu Mar 14 20:20:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06859 for ; Thu, 14 Mar 2002 20:20:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA22909 for sip-security-archive@odin.ietf.org; Thu, 14 Mar 2002 20:20:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22839; Thu, 14 Mar 2002 20:19:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22798 for ; Thu, 14 Mar 2002 20:19:30 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06844; Thu, 14 Mar 2002 20:19:28 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2F1Irh21795; Thu, 14 Mar 2002 19:18:53 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 19:18:55 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E011879EB@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'John W Noerenberg II'" , sipping@ietf.org, sip-security@ietf.org Cc: Greg Rose , aki.niemi@nokia.com, jari.arkko@ericsson.com, vesa.torvinen@ericsson.fi, James Undery Date: Thu, 14 Mar 2002 19:18:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CBBF.5F5B3710" Subject: [Sip-security] RE: SIP authentication problem when using RES in Digest-AKA Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1CBBF.5F5B3710 Content-Type: text/plain; charset="iso-8859-1" Another option to think about is whether there is any need to carry AKA credentials (as is) in the HTTP *-Authenticate and *-Authorization headers. This means that we define AKA as an authentication scheme at par with Digest (instead of using it as a password generation tool, say, for Digest MD5). In HTTP Authentication syntax, challenge = "AKA" AKA-challenge AKA-challenge = 1#(rand | autn | auth-param) credential = "AKA" AKA-response AKA-response = 1#(res | [auts]) where, rand, res, autn, auts (all AKA parameters) are all base64 encoded. One advantage of this approach is that you need not run Digest algorithms (draft-niemi-sipping-digest-aka-00 forces you to run both a Digest algorithm and the AKA authentication algorithm). We discussed about this option but never reached any agreement on whether to go for this. It was not clear whether transferring res will lead to any potential security attacks. Any comments/thoughts? Sanjoy > -----Original Message----- > From: John W Noerenberg II [mailto:jwn2@qualcomm.com] > Sent: Thursday, March 14, 2002 6:38 PM > To: sipping@ietf.org; sip-security@ietf.org > Cc: Greg Rose; aki.niemi@nokia.com; jari.arkko@ericsson.com; > vesa.torvinen@ericsson.fi; James Undery; Sen, Sanjoy [NGC:B692:EXCH] > Subject: SIP authentication problem when using RES in Digest-AKA > > > Greg Rose has identified a security problem when HTTP-Digest is > combined with the mechanism proposed in > draft-niemi-sipping-digest-aka-00 and draft-undery-sip-auth-00. He's > outlined this for the 3GPP TSG SA WG3, one of the TSG security area > working groups. > > Essentially the problem is a consequence of using a RES that is > shorter than the key from which it is derived, typically as small as > 32 bits. RES's length results from the goal of maintaining backward > compatibility with existing USIMs. RES is a choke point that can be > used to break the authentication. Instead of using RES, IK has much > greater entropy, and makes the attack prohibitively difficult. A > description of the attack against RES is given below. > > The authentication process can be summarized as follows: > > 1. UE attempts to register. > 2. The attempt is rejected because the UE is unauthenticated. The > rejection message includes AKA-related information and an HTTP-Digest > nonce. > 3. UE/USIM checks the AKA information and computes RES. > 4. RES is now used as the password shared by the UE and the CSCF. > 5. UE computes HTTP-Digest response based on RES, and > attempts to register. > 6. Registration succeeds. > > Subsequently > > 7. UE sends another SIP message (e.g. Invite) and the HTTP-Digest > method calculates authentication information based on RES. > (Actually, A1 is used, but it is derived from RES). > > Choke Point Attack > > An attacker monitoring the traffic would break the scheme as follows: > > The attacker has all the messages from steps 2 and 5 above. All of > the information used in the calculation of the response in step 5, > except for the value of RES is present in these messages. Assuming > RES is 32 bits, the attacker tries the 2**32 possible values, > comparing them to the captured response generated for step 5. With > very high probability, he will succeed with exactly one candidate > value for RES, in the time needed to calculate 2**31 MD5 hashes. > This takes ~5 minutes on a typical laptop. > > Once the value of RES is known, the attacker can now forge SIP > messages or alter them in transit, recalculating the Digest after > altering the message. > > By replacing the use of RES with a higher entropy quantity, this > attack can be prevented. As noted above, Greg recommends using IK as > a replacement for RES. > > best, > -- > > john noerenberg > jwn2@qualcomm.com > > -------------------------------------------------------------- > ------------ > The truth knocks on the door and you say, "Go away, I'm looking > for the truth," and so it goes away. Puzzling. > -- Zen and the Art of Motorcycle Maintenance, Robert M. > Pirsig, 1974 > > -------------------------------------------------------------- > ------------ > ------_=_NextPart_001_01C1CBBF.5F5B3710 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: SIP authentication problem when using RES in = Digest-AKA

Another option to think about is whether there is any = need to carry AKA credentials (as is) in the HTTP *-Authenticate and = *-Authorization headers. This means that we define AKA as an = authentication scheme at par with Digest (instead of using it as a = password generation tool, say, for Digest MD5). In HTTP Authentication = syntax,

challenge =3D "AKA" AKA-challenge
AKA-challenge =3D 1#(rand | autn | = auth-param)

credential =3D "AKA" AKA-response
AKA-response =3D 1#(res | [auts])

where, rand, res, autn, auts (all AKA parameters) are = all base64 encoded. One advantage of this approach is that you need not = run Digest algorithms (draft-niemi-sipping-digest-aka-00 forces you to = run both a Digest algorithm and the AKA authentication = algorithm).

We discussed about this option but never reached any = agreement on whether to go for this. It was not clear whether = transferring res will lead to any potential security attacks. =

Any comments/thoughts?

Sanjoy


> -----Original Message-----
> From: John W Noerenberg II [mailto:jwn2@qualcomm.com]
> Sent: Thursday, March 14, 2002 6:38 PM
> To: sipping@ietf.org; = sip-security@ietf.org
> Cc: Greg Rose; aki.niemi@nokia.com; = jari.arkko@ericsson.com;
> vesa.torvinen@ericsson.fi; James Undery; Sen, = Sanjoy [NGC:B692:EXCH]
> Subject: SIP authentication problem when using = RES in Digest-AKA
>
>
> Greg Rose has identified a security problem = when HTTP-Digest is
> combined with the mechanism proposed in
> draft-niemi-sipping-digest-aka-00 and = draft-undery-sip-auth-00.  He's
> outlined this for the 3GPP TSG SA WG3, one of = the TSG security area
> working groups.
>
> Essentially the problem is a consequence of = using a RES that is
> shorter than the key from which it is derived, = typically as small as
> 32 bits.  RES's length results from the = goal of maintaining backward
> compatibility with existing USIMs.  RES is = a choke point that can be
> used to break the authentication.  Instead = of using RES, IK has much
> greater entropy, and makes the attack = prohibitively difficult.  A
> description of the attack against RES is given = below.
>
> The authentication process can be summarized as = follows:
>
> 1. UE attempts to register.
> 2. The attempt is rejected because the UE is = unauthenticated.  The
> rejection message includes AKA-related = information and an HTTP-Digest
> nonce.
> 3. UE/USIM checks the AKA information and = computes RES.
> 4. RES is now used as the password shared by = the UE and the CSCF.
> 5. UE computes HTTP-Digest response based on = RES, and
> attempts to register.
> 6. Registration succeeds.
>
> Subsequently
>
> 7. UE sends another SIP message (e.g. Invite) = and the HTTP-Digest
> method calculates authentication information = based on RES.
> (Actually, A1 is used, but it is derived from = RES).
>
> Choke Point Attack
>
> An attacker monitoring the traffic would break = the scheme as follows:
>
> The attacker has all the messages from steps 2 = and 5 above.  All of
> the information used in the calculation of the = response in step 5,
> except for the value of RES is present in these = messages.  Assuming
> RES is 32 bits, the attacker tries the 2**32 = possible values,
> comparing them to the captured response = generated for step 5.  With
> very high probability, he will succeed with = exactly one candidate
> value for RES, in the time needed to calculate = 2**31 MD5 hashes.
> This takes ~5 minutes on a typical = laptop.
>
> Once the value of RES is known, the attacker = can now forge SIP
> messages or alter them in transit, = recalculating the Digest after
> altering the message.
>
> By replacing the use of RES with a higher = entropy quantity, this
> attack can be prevented.  As noted above, = Greg recommends using IK as
> a replacement for RES.
>
> best,
> --
>
> john noerenberg
> jwn2@qualcomm.com
>   
> = --------------------------------------------------------------
> ------------
>    The truth knocks on the door = and you say, "Go away, I'm looking
>    for the truth,"  = and so it goes away.  Puzzling.
>    -- Zen and the Art of = Motorcycle Maintenance, Robert M.
> Pirsig, 1974
>   
> = --------------------------------------------------------------
> ------------
>

------_=_NextPart_001_01C1CBBF.5F5B3710-- _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Thu Mar 14 20:56:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07597 for ; Thu, 14 Mar 2002 20:56:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA25171 for sip-security-archive@odin.ietf.org; Thu, 14 Mar 2002 20:56:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25031; Thu, 14 Mar 2002 20:54:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA24945 for ; Thu, 14 Mar 2002 20:54:24 -0500 (EST) Received: from warlock.qualcomm.com (warlock.qualcomm.com [129.46.64.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07528; Thu, 14 Mar 2002 20:54:20 -0500 (EST) Received: from avalon.qualcomm.com (avalon.qualcomm.com [203.30.171.11]) by warlock.qualcomm.com (8.12.1/8.9.3/8.9) with ESMTP id g2F1rVJL000307; Thu, 14 Mar 2002 17:53:32 -0800 (PST) Received: from NAVAJO.qualcomm.com by avalon.qualcomm.com (8.8.8+Sun/SMI-SVR4) id MAA29557; Fri, 15 Mar 2002 12:52:50 +1100 (EST) Message-Id: <4.3.1.2.20020315124047.05271fd8@127.0.0.1> X-Sender: ggr2@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 15 Mar 2002 12:52:06 +1100 To: "Sanjoy Sen" From: Greg Rose Cc: "'John W Noerenberg II'" , sipping@ietf.org, sip-security@ietf.org, Greg Rose , aki.niemi@nokia.com, jari.arkko@ericsson.com, vesa.torvinen@ericsson.fi, James Undery In-Reply-To: <933FADF5E673D411B8A30002A5608A0E011879EA@zrc2c012.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sip-security] RE: SIP authentication problem when using RES in Digest-AKA Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org At 06:48 PM 3/14/2002 -0600, Sanjoy Sen wrote: >draft-undery-sip-auth-00.txt doesn't make any recommendation as to how the >password should be computed. However, I remember that when we took the >proposal of using Digest for the first time to 3GPP, we had recommended >using IK as the password. That's right. draft-undery-sip-auth-00.txt assumes that the password is strong, and by itself has no problems. draft-niemi-sipping-digest-aka-00 assumes that RES is used as the password only once for the authentication, and by itself has no problems. Put the two together, and there's a problem... BTW, my suggestion to use IK would solve this juxtaposition problem (since a 128 bit "choke point" is not seen to be a problem), but is not seen to be acceptable to 3GPP SA3, because that would mean that IK was to be used for two distinct things potentially at the same time, although I don't agree with this argument (it seems to me that the 3GPP mechanism and draft-undery-... can't both be used at the same time). However the Ciphering Key CK is also available, 128 bits, and is not expected to be used for anything. Anyway, possible solutions can be examined further. Thanks to John Noerenberg for helping me distribute this information. regards, Greg. >Sanjoy > > > -----Original Message----- > > From: John W Noerenberg II > [mailto:jwn2@qualcomm.com] > > Sent: Thursday, March 14, 2002 6:38 PM > > To: sipping@ietf.org; sip-security@ietf.org > > Cc: Greg Rose; aki.niemi@nokia.com; jari.arkko@ericsson.com; > > vesa.torvinen@ericsson.fi; James Undery; Sen, Sanjoy [NGC:B692:EXCH] > > Subject: SIP authentication problem when using RES in Digest-AKA > > > > > > Greg Rose has identified a security problem when HTTP-Digest is > > combined with the mechanism proposed in > > draft-niemi-sipping-digest-aka-00 and draft-undery-sip-auth-00. He's > > outlined this for the 3GPP TSG SA WG3, one of the TSG security area > > working groups. > > > > Essentially the problem is a consequence of using a RES that is > > shorter than the key from which it is derived, typically as small as > > 32 bits. RES's length results from the goal of maintaining backward > > compatibility with existing USIMs. RES is a choke point that can be > > used to break the authentication. Instead of using RES, IK has much > > greater entropy, and makes the attack prohibitively difficult. A > > description of the attack against RES is given below. > > > > The authentication process can be summarized as follows: > > > > 1. UE attempts to register. > > 2. The attempt is rejected because the UE is unauthenticated. The > > rejection message includes AKA-related information and an HTTP-Digest > > nonce. > > 3. UE/USIM checks the AKA information and computes RES. > > 4. RES is now used as the password shared by the UE and the CSCF. > > 5. UE computes HTTP-Digest response based on RES, and > > attempts to register. > > 6. Registration succeeds. > > > > Subsequently > > > > 7. UE sends another SIP message (e.g. Invite) and the HTTP-Digest > > method calculates authentication information based on RES. > > (Actually, A1 is used, but it is derived from RES). > > > > Choke Point Attack > > > > An attacker monitoring the traffic would break the scheme as follows: > > > > The attacker has all the messages from steps 2 and 5 above. All of > > the information used in the calculation of the response in step 5, > > except for the value of RES is present in these messages. Assuming > > RES is 32 bits, the attacker tries the 2**32 possible values, > > comparing them to the captured response generated for step 5. With > > very high probability, he will succeed with exactly one candidate > > value for RES, in the time needed to calculate 2**31 MD5 hashes. > > This takes ~5 minutes on a typical laptop. > > > > Once the value of RES is known, the attacker can now forge SIP > > messages or alter them in transit, recalculating the Digest after > > altering the message. > > > > By replacing the use of RES with a higher entropy quantity, this > > attack can be prevented. As noted above, Greg recommends using IK as > > a replacement for RES. > > > > best, > > -- > > > > john noerenberg > > jwn2@qualcomm.com > > > > -------------------------------------------------------------- > > ------------ > > The truth knocks on the door and you say, "Go away, I'm looking > > for the truth," and so it goes away. Puzzling. > > -- Zen and the Art of Motorcycle Maintenance, Robert M. > > Pirsig, 1974 > > > > -------------------------------------------------------------- > > ------------ > > Greg Rose INTERNET: ggr@qualcomm.com Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/ Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Thu Mar 14 21:03:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07857 for ; Thu, 14 Mar 2002 21:03:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA26427 for sip-security-archive@odin.ietf.org; Thu, 14 Mar 2002 21:03:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA26087; Thu, 14 Mar 2002 21:02:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA26010 for ; Thu, 14 Mar 2002 21:02:33 -0500 (EST) Received: from warlock.qualcomm.com (warlock.qualcomm.com [129.46.64.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07771; Thu, 14 Mar 2002 21:02:30 -0500 (EST) Received: from avalon.qualcomm.com (avalon.qualcomm.com [203.30.171.11]) by warlock.qualcomm.com (8.12.1/8.9.3/8.9) with ESMTP id g2F228JL001273; Thu, 14 Mar 2002 18:02:09 -0800 (PST) Received: from NAVAJO.qualcomm.com by avalon.qualcomm.com (8.8.8+Sun/SMI-SVR4) id NAA29586; Fri, 15 Mar 2002 13:01:28 +1100 (EST) Message-Id: <4.3.1.2.20020315125435.01bd4360@127.0.0.1> X-Sender: ggr2@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 15 Mar 2002 13:00:44 +1100 To: "Sanjoy Sen" From: Greg Rose Cc: "'John W Noerenberg II'" , sipping@ietf.org, sip-security@ietf.org, Greg Rose , aki.niemi@nokia.com, jari.arkko@ericsson.com, vesa.torvinen@ericsson.fi, James Undery In-Reply-To: <933FADF5E673D411B8A30002A5608A0E011879EB@zrc2c012.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sip-security] RE: SIP authentication problem when using RES in Digest-AKA Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org At 07:18 PM 3/14/2002 -0600, Sanjoy Sen wrote: >Another option to think about is whether there is any need to carry AKA >credentials (as is) in the HTTP *-Authenticate and *-Authorization >headers. This means that we define AKA as an authentication scheme at par >with Digest (instead of using it as a password generation tool, say, for >Digest MD5). In HTTP Authentication syntax, > >challenge = "AKA" AKA-challenge >AKA-challenge = 1#(rand | autn | auth-param) > >credential = "AKA" AKA-response >AKA-response = 1#(res | [auts]) > >where, rand, res, autn, auts (all AKA parameters) are all base64 encoded. >One advantage of this approach is that you need not run Digest algorithms >(draft-niemi-sipping-digest-aka-00 forces you to run both a Digest >algorithm and the AKA authentication algorithm). > >We discussed about this option but never reached any agreement on whether >to go for this. It was not clear whether transferring res will lead to any >potential security attacks. I think that somehow doing it directly got tied up with use of EAP to encapsulate everything, and the EAP approach was then dropped. But direct use of AKA instead of doing both AKA and then Digest is (IMO) far preferable. Then A1 for draft-undery-... could be IK (or derived from it) without any problem I'm aware of. I'm not sure what happened to this possibility. The security analysis of 3GPP AKA is available, and it is clear that there is no security exposure in revealing RAND, RES and AUTN publicly (except enabling brute-force offline attack, which was already true for HTTP-Digest). Greg. > > -----Original Message----- > > From: John W Noerenberg II > [mailto:jwn2@qualcomm.com] > > Sent: Thursday, March 14, 2002 6:38 PM > > To: sipping@ietf.org; sip-security@ietf.org > > Cc: Greg Rose; aki.niemi@nokia.com; jari.arkko@ericsson.com; > > vesa.torvinen@ericsson.fi; James Undery; Sen, Sanjoy [NGC:B692:EXCH] > > Subject: SIP authentication problem when using RES in Digest-AKA > > > > > > Greg Rose has identified a security problem when HTTP-Digest is > > combined with the mechanism proposed in > > draft-niemi-sipping-digest-aka-00 and draft-undery-sip-auth-00. He's > > outlined this for the 3GPP TSG SA WG3, one of the TSG security area > > working groups. > > > > Essentially the problem is a consequence of using a RES that is > > shorter than the key from which it is derived, typically as small as > > 32 bits. RES's length results from the goal of maintaining backward > > compatibility with existing USIMs. RES is a choke point that can be > > used to break the authentication. Instead of using RES, IK has much > > greater entropy, and makes the attack prohibitively difficult. A > > description of the attack against RES is given below. > > > > The authentication process can be summarized as follows: > > > > 1. UE attempts to register. > > 2. The attempt is rejected because the UE is unauthenticated. The > > rejection message includes AKA-related information and an HTTP-Digest > > nonce. > > 3. UE/USIM checks the AKA information and computes RES. > > 4. RES is now used as the password shared by the UE and the CSCF. > > 5. UE computes HTTP-Digest response based on RES, and > > attempts to register. > > 6. Registration succeeds. > > > > Subsequently > > > > 7. UE sends another SIP message (e.g. Invite) and the HTTP-Digest > > method calculates authentication information based on RES. > > (Actually, A1 is used, but it is derived from RES). > > > > Choke Point Attack > > > > An attacker monitoring the traffic would break the scheme as follows: > > > > The attacker has all the messages from steps 2 and 5 above. All of > > the information used in the calculation of the response in step 5, > > except for the value of RES is present in these messages. Assuming > > RES is 32 bits, the attacker tries the 2**32 possible values, > > comparing them to the captured response generated for step 5. With > > very high probability, he will succeed with exactly one candidate > > value for RES, in the time needed to calculate 2**31 MD5 hashes. > > This takes ~5 minutes on a typical laptop. > > > > Once the value of RES is known, the attacker can now forge SIP > > messages or alter them in transit, recalculating the Digest after > > altering the message. > > > > By replacing the use of RES with a higher entropy quantity, this > > attack can be prevented. As noted above, Greg recommends using IK as > > a replacement for RES. > > > > best, > > -- > > > > john noerenberg > > jwn2@qualcomm.com > > > > -------------------------------------------------------------- > > ------------ > > The truth knocks on the door and you say, "Go away, I'm looking > > for the truth," and so it goes away. Puzzling. > > -- Zen and the Art of Motorcycle Maintenance, Robert M. > > Pirsig, 1974 > > > > -------------------------------------------------------------- > > ------------ > > Greg Rose INTERNET: ggr@qualcomm.com Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/ Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Fri Mar 15 01:17:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13890 for ; Fri, 15 Mar 2002 01:17:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA19676 for sip-security-archive@odin.ietf.org; Fri, 15 Mar 2002 01:17:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18473; Fri, 15 Mar 2002 01:15:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18357 for ; Fri, 15 Mar 2002 01:15:19 -0500 (EST) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13867; Fri, 15 Mar 2002 01:15:16 -0500 (EST) Received: from piuha.net ([62.248.153.197]) by fep02-app.kolumbus.fi with ESMTP id <20020315061516.SMKI12987.fep02-app.kolumbus.fi@piuha.net>; Fri, 15 Mar 2002 08:15:16 +0200 Message-ID: <3C9191C9.3000507@piuha.net> Date: Fri, 15 Mar 2002 08:16:41 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: John W Noerenberg II CC: sipping@ietf.org, sip-security@ietf.org, Greg Rose , aki.niemi@nokia.com, jari.arkko@ericsson.com, vesa.torvinen@ericsson.fi, James Undery , Sanjoy Sen References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip-security] Re: [Sipping] SIP authentication problem when using RES in Digest-AKA Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit John, Greg, Thanks for an interesting describing this interesting attack! I believe while making draft-niemi the authors have been assuming that we do not use the GSM compatibility mode (which I believe is the reason why the RES could be only 32 bits). That is, when full AKA is used this isn't a problem. So, we could either (1) Require the full use of AKA (2) Switch to using IK and not RES as input in the Digest process Greg, is the IK free of similar limitations when GSM compatibility is used? Jari _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Fri Mar 15 02:41:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22877 for ; Fri, 15 Mar 2002 02:41:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA24390 for sip-security-archive@odin.ietf.org; Fri, 15 Mar 2002 02:41:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA24228; Fri, 15 Mar 2002 02:40:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA24183 for ; Fri, 15 Mar 2002 02:40:48 -0500 (EST) Received: from warlock.qualcomm.com (warlock.qualcomm.com [129.46.64.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22849; Fri, 15 Mar 2002 02:40:46 -0500 (EST) Received: from avalon.qualcomm.com (avalon.qualcomm.com [203.30.171.11]) by warlock.qualcomm.com (8.12.1/8.9.3/8.9) with ESMTP id g2F7dwJL019326; Thu, 14 Mar 2002 23:39:59 -0800 (PST) Received: from NAVAJO.qualcomm.com by avalon.qualcomm.com (8.8.8+Sun/SMI-SVR4) id SAA00065; Fri, 15 Mar 2002 18:39:12 +1100 (EST) Message-Id: <4.3.1.2.20020315183342.02454340@127.0.0.1> X-Sender: ggr2@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 15 Mar 2002 18:38:30 +1100 To: Jari Arkko From: Greg Rose Cc: John W Noerenberg II , sipping@ietf.org, sip-security@ietf.org, Greg Rose , aki.niemi@nokia.com, jari.arkko@ericsson.com, vesa.torvinen@ericsson.fi, James Undery , Sanjoy Sen In-Reply-To: <3C9191C9.3000507@piuha.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sip-security] Re: [Sipping] SIP authentication problem when using RES in Digest-AKA Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org At 08:16 AM 3/15/2002 +0200, Jari Arkko wrote: >Thanks for an interesting describing this interesting attack! I believe >while making draft-niemi the authors have been assuming that we do not >use the GSM compatibility mode (which I believe is the reason why the RES >could be only 32 bits). That is, when full AKA is used this isn't a problem. Regrettably, this is not correct. RES could be as little as 32 bits *even in full AKA*. >So, we could either > >(1) Require the full use of AKA >(2) Switch to using IK and not RES as input in the Digest process IK is the obvious (to me) candidate. >Greg, is the IK free of similar limitations when GSM compatibility >is used? If I understand your question correctly -- yes. IK is always 128 bits coming out of the USIM, even if it is subsequently "dumbed down" for GSM compatibility (which should never happen in anything capable of packet data and IMS). When a *GSM SIM* is used, you will only get out a 64-bit K_c, but even that is a lot better than a 32-bit RES. regards, Greg. Greg Rose INTERNET: ggr@qualcomm.com Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/ Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Fri Mar 15 03:33:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23542 for ; Fri, 15 Mar 2002 03:33:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA27642 for sip-security-archive@odin.ietf.org; Fri, 15 Mar 2002 03:33:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA27080; Fri, 15 Mar 2002 03:29:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA27047 for ; Fri, 15 Mar 2002 03:29:46 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23485 for ; Fri, 15 Mar 2002 03:29:28 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g2F8TPR29554 for ; Fri, 15 Mar 2002 09:29:25 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Mar 15 09:29:23 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Mar 2002 09:19:27 +0100 Message-ID: <29F33B0CF787D51195FC0002A56B3DC10101B75E@efijont103> From: "Vesa Torvinen (LMF)" To: "'Greg Rose'" , Jari Arkko Cc: John W Noerenberg II , sipping@ietf.org, sip-security@ietf.org, aki.niemi@nokia.com, jari.arkko@ericsson.com, James Undery , Sanjoy Sen Date: Fri, 15 Mar 2002 09:28:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip-security] RE: [Sipping] SIP authentication problem when using RES in Digest -AKA Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org > At 08:16 AM 3/15/2002 +0200, Jari Arkko wrote: > >Thanks for an interesting describing this interesting > attack! I believe > >while making draft-niemi the authors have been assuming that > we do not > >use the GSM compatibility mode (which I believe is the > reason why the RES > >could be only 32 bits). That is, when full AKA is used this > isn't a problem. > > Regrettably, this is not correct. RES could be as little as > 32 bits *even > in full AKA*. If this is the case, I suppose that RES could still be used as 'keying material' for Digest. There must be some schemes in which a 'short user password' is made longer or more secure. > >So, we could either > > > >(1) Require the full use of AKA > >(2) Switch to using IK and not RES as input in the Digest process > > IK is the obvious (to me) candidate. IK is not very good candidate if you don't want to change the existing security architecture in 3GPP IP multimedia system (IMS). IK is currently used for integrity protection between the UE and the visited network, and if the same key is also used for authentication to the home network, the visited network will be able to register any user it wants. Currently, IK is available to the visited network before the UE has even received the challenge. So, the visited network could just 'order' authentication keys from any home network, and initiate registrations and calls for any user. If we would go for IK, we must re-design the IMS security architecture. > >Greg, is the IK free of similar limitations when GSM compatibility > >is used? > > If I understand your question correctly -- yes. IK is always 128 bits > coming out of the USIM, even if it is subsequently "dumbed > down" for GSM > compatibility (which should never happen in anything capable > of packet data > and IMS). When a *GSM SIM* is used, you will only get out a > 64-bit K_c, but > even that is a lot better than a 32-bit RES. > > regards, > Greg. > > Greg Rose INTERNET: > ggr@qualcomm.com > Qualcomm Australia VOICE: +61-2-9817 4188 FAX: > +61-2-9817 5199 > Level 3, 230 Victoria Road, > http://people.qualcomm.com/ggr/ > Gladesville NSW 2111 232B > EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C > _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Fri Mar 15 03:53:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23756 for ; Fri, 15 Mar 2002 03:53:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA28684 for sip-security-archive@odin.ietf.org; Fri, 15 Mar 2002 03:53:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28456; Fri, 15 Mar 2002 03:52:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28403 for ; Fri, 15 Mar 2002 03:52:47 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23716; Fri, 15 Mar 2002 03:52:44 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g2F8qJR15801; Fri, 15 Mar 2002 09:52:19 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g2F8qHUD006783; Fri, 15 Mar 2002 10:52:17 +0200 (EET) Message-ID: <3C91B641.6FC4660F@lmf.ericsson.se> Date: Fri, 15 Mar 2002 10:52:17 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Greg Rose CC: Jari Arkko , John W Noerenberg II , sipping@ietf.org, sip-security@ietf.org, aki.niemi@nokia.com, jari.arkko@ericsson.com, vesa.torvinen@lmf.ericsson.se, James Undery , Sanjoy Sen References: <4.3.1.2.20020315183342.02454340@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip-security] Re: [Sipping] SIP authentication problem when using RES inDigest-AKA Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit Greg Rose wrote: > > At 08:16 AM 3/15/2002 +0200, Jari Arkko wrote: > >Thanks for an interesting describing this interesting attack! I believe > >while making draft-niemi the authors have been assuming that we do not > >use the GSM compatibility mode (which I believe is the reason why the RES > >could be only 32 bits). That is, when full AKA is used this isn't a problem. > > Regrettably, this is not correct. RES could be as little as 32 bits *even > in full AKA*. Yes, but don't we have the choice of *requiring* that in order to use AKA in Digest, you have to provide 128 bits? Is there a particular reason why less than 128 bits would have to be produced. In particular, as the draft is currently written, we do not transport the RES over the air, so its length is not an efficiency issue. [By the way Vesa: it does not help extending a short user password, because in the end there's not enough original bits.] Jari _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Fri Mar 15 04:29:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24351 for ; Fri, 15 Mar 2002 04:29:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA01594 for sip-security-archive@odin.ietf.org; Fri, 15 Mar 2002 04:29:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01457; Fri, 15 Mar 2002 04:27:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01415 for ; Fri, 15 Mar 2002 04:27:56 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24306; Fri, 15 Mar 2002 04:27:50 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2F9SYi18793; Fri, 15 Mar 2002 11:28:34 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 15 Mar 2002 11:27:51 +0200 Received: from nokia.com ([172.21.149.105]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 15 Mar 2002 11:27:50 +0200 Message-ID: <3C91BE88.2000507@nokia.com> Date: Fri, 15 Mar 2002 11:27:36 +0200 From: "Niemi Aki (NET/Espoo)" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020212 X-Accept-Language: en-us MIME-Version: 1.0 To: ext Sanjoy Sen CC: "'John W Noerenberg II'" , sipping@ietf.org, sip-security@ietf.org, Greg Rose , jari.arkko@ericsson.com, vesa.torvinen@ericsson.fi, James Undery References: <933FADF5E673D411B8A30002A5608A0E011879EB@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Mar 2002 09:27:50.0871 (UTC) FILETIME=[AD5E9670:01C1CC03] Content-Transfer-Encoding: 7bit Subject: [Sip-security] Re: SIP authentication problem when using RES in Digest-AKA Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit Hi Sanjoy, > Another option to think about is whether there is any need to carry AKA > credentials (as is) in the HTTP *-Authenticate and *-Authorization > headers. This means that we define AKA as an authentication scheme at > par with Digest (instead of using it as a password generation tool, say, > for Digest MD5). In HTTP Authentication syntax, You are right. This is an alternative option, as we have discussed before. As AKA is secure in itself, there shouldn't be a problem sending AKA parameters in the clear. However, by doing this you will lose the one thing that Digest provides, which is authentication of the SIP message, or at least parts of it during the authentication procedure. So all in all, from the AKA perspective, both options should be equally secure, but with Digest AKA, the SIP message is better protected. How desirable exactly this added protection is, and indeed is the added cost of calculating the Digest MD5 worth the received benefits, is open to discussion. Cheers, Aki _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Fri Mar 15 04:40:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24530 for ; Fri, 15 Mar 2002 04:40:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA02782 for sip-security-archive@odin.ietf.org; Fri, 15 Mar 2002 04:40:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02612; Fri, 15 Mar 2002 04:38:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02578 for ; Fri, 15 Mar 2002 04:38:44 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24495; Fri, 15 Mar 2002 04:38:38 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2F9cpZ03047; Fri, 15 Mar 2002 11:38:51 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 15 Mar 2002 11:38:39 +0200 Received: from nokia.com ([172.21.149.105]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 15 Mar 2002 11:38:39 +0200 Message-ID: <3C91C111.1040500@nokia.com> Date: Fri, 15 Mar 2002 11:38:25 +0200 From: "Niemi Aki (NET/Espoo)" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020212 X-Accept-Language: en-us MIME-Version: 1.0 To: ext Greg Rose CC: Sanjoy Sen , "'John W Noerenberg II'" , sipping@ietf.org, sip-security@ietf.org, jari.arkko@ericsson.com, vesa.torvinen@ericsson.fi, James Undery References: <4.3.1.2.20020315124047.05271fd8@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Mar 2002 09:38:39.0271 (UTC) FILETIME=[2FD89370:01C1CC05] Content-Transfer-Encoding: 7bit Subject: [Sip-security] Re: SIP authentication problem when using RES in Digest-AKA Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit Hi Greg, John, Thanks for the comments! On 03/15/2002 03:52 AM, ext Greg Rose wrote: > At 06:48 PM 3/14/2002 -0600, Sanjoy Sen wrote: > >>draft-undery-sip-auth-00.txt doesn't make any recommendation as to how the >>password should be computed. However, I remember that when we took the >>proposal of using Digest for the first time to 3GPP, we had recommended >>using IK as the password. > > That's right. draft-undery-sip-auth-00.txt assumes that the password is > strong, and by itself has no problems. draft-niemi-sipping-digest-aka-00 > assumes that RES is used as the password only once for the authentication, > and by itself has no problems. Put the two together, and there's a problem... I'm a little confused on where the problem actually is. In draft-niemi, we at some point were thinking about adding an HTTP Digest feature called stale nonces to Digest AKA. This would've made it possible to reuse the RES when calculating a Digest response with a "fresh" nonce value. However, we decided not to include that as it turns out that in RFC 2617, the UA can also always ignore the stale flag, and ask the username/password from the user. Thus, the nonce in Digest AKA must always contain the AKA parameters RAND, AUTN, and a new RES is therefore always calculated when the UA receives a Digest AKA challenge. What comes to integrity protection, the draft-undery should definitely always be used with the IK. RES should be seen as a one-time password for authentication only. In fact, I would argue, that reusing the RES in Digest AKA is not possible, even. But I guess that isn't stated very well in draft-niemi and should really be there. We'll add some clarifying text. Cheers, Aki > BTW, my suggestion to use IK would solve this juxtaposition problem (since > a 128 bit "choke point" is not seen to be a problem), but is not seen to be > acceptable to 3GPP SA3, because that would mean that IK was to be used for > two distinct things potentially at the same time, although I don't agree > with this argument (it seems to me that the 3GPP mechanism and > draft-undery-... can't both be used at the same time). However the > Ciphering Key CK is also available, 128 bits, and is not expected to be > used for anything. Anyway, possible solutions can be examined further. > > Thanks to John Noerenberg for helping me distribute this information. > > regards, > Greg. > > >>Sanjoy >> >> > -----Original Message----- >> > From: John W Noerenberg II >> [mailto:jwn2@qualcomm.com] >> > Sent: Thursday, March 14, 2002 6:38 PM >> > To: sipping@ietf.org; sip-security@ietf.org >> > Cc: Greg Rose; aki.niemi@nokia.com; jari.arkko@ericsson.com; >> > vesa.torvinen@ericsson.fi; James Undery; Sen, Sanjoy [NGC:B692:EXCH] >> > Subject: SIP authentication problem when using RES in Digest-AKA >> > >> > >> > Greg Rose has identified a security problem when HTTP-Digest is >> > combined with the mechanism proposed in >> > draft-niemi-sipping-digest-aka-00 and draft-undery-sip-auth-00. He's >> > outlined this for the 3GPP TSG SA WG3, one of the TSG security area >> > working groups. >> > >> > Essentially the problem is a consequence of using a RES that is >> > shorter than the key from which it is derived, typically as small as >> > 32 bits. RES's length results from the goal of maintaining backward >> > compatibility with existing USIMs. RES is a choke point that can be >> > used to break the authentication. Instead of using RES, IK has much >> > greater entropy, and makes the attack prohibitively difficult. A >> > description of the attack against RES is given below. >> > >> > The authentication process can be summarized as follows: >> > >> > 1. UE attempts to register. >> > 2. The attempt is rejected because the UE is unauthenticated. The >> > rejection message includes AKA-related information and an HTTP-Digest >> > nonce. >> > 3. UE/USIM checks the AKA information and computes RES. >> > 4. RES is now used as the password shared by the UE and the CSCF. >> > 5. UE computes HTTP-Digest response based on RES, and >> > attempts to register. >> > 6. Registration succeeds. >> > >> > Subsequently >> > >> > 7. UE sends another SIP message (e.g. Invite) and the HTTP-Digest >> > method calculates authentication information based on RES. >> > (Actually, A1 is used, but it is derived from RES). >> > >> > Choke Point Attack >> > >> > An attacker monitoring the traffic would break the scheme as follows: >> > >> > The attacker has all the messages from steps 2 and 5 above. All of >> > the information used in the calculation of the response in step 5, >> > except for the value of RES is present in these messages. Assuming >> > RES is 32 bits, the attacker tries the 2**32 possible values, >> > comparing them to the captured response generated for step 5. With >> > very high probability, he will succeed with exactly one candidate >> > value for RES, in the time needed to calculate 2**31 MD5 hashes. >> > This takes ~5 minutes on a typical laptop. >> > >> > Once the value of RES is known, the attacker can now forge SIP >> > messages or alter them in transit, recalculating the Digest after >> > altering the message. >> > >> > By replacing the use of RES with a higher entropy quantity, this >> > attack can be prevented. As noted above, Greg recommends using IK as >> > a replacement for RES. >> > >> > best, >> > -- >> > >> > john noerenberg >> > jwn2@qualcomm.com >> > >> > -------------------------------------------------------------- >> > ------------ >> > The truth knocks on the door and you say, "Go away, I'm looking >> > for the truth," and so it goes away. Puzzling. >> > -- Zen and the Art of Motorcycle Maintenance, Robert M. >> > Pirsig, 1974 >> > >> > -------------------------------------------------------------- >> > ------------ >> > > > > Greg Rose INTERNET: ggr@qualcomm.com > Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 > Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/ > Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C > > _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Fri Mar 15 04:43:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24587 for ; Fri, 15 Mar 2002 04:43:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA03082 for sip-security-archive@odin.ietf.org; Fri, 15 Mar 2002 04:43:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02899; Fri, 15 Mar 2002 04:41:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02848 for ; Fri, 15 Mar 2002 04:41:45 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24556; Fri, 15 Mar 2002 04:41:41 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g2F9fTUw010589; Fri, 15 Mar 2002 10:41:29 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g2F9fQUD009677; Fri, 15 Mar 2002 11:41:26 +0200 (EET) Message-ID: <3C91C1C6.E3464A36@lmf.ericsson.se> Date: Fri, 15 Mar 2002 11:41:26 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Greg Rose CC: Sanjoy Sen , "'John W Noerenberg II'" , sipping@ietf.org, sip-security@ietf.org, aki.niemi@nokia.com, jari.arkko@ericsson.com, vesa.torvinen@lmf.ericsson.se, James Undery References: <4.3.1.2.20020315124047.05271fd8@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip-security] Re: SIP authentication problem when using RES in Digest-AKA Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit Greg Rose wrote: > >draft-undery-sip-auth-00.txt doesn't make any recommendation as to how the > >password should be computed. However, I remember that when we took the > >proposal of using Digest for the first time to 3GPP, we had recommended > >using IK as the password. > > That's right. draft-undery-sip-auth-00.txt assumes that the password is > strong, and by itself has no problems. draft-niemi-sipping-digest-aka-00 > assumes that RES is used as the password only once for the authentication, > and by itself has no problems. Put the two together, and there's a problem... We are in agreement that IK should be used as the password for draft-undery. However, I feel that in this discussion we have been mixing draft-undery and draft-niemi in a manner that it doesn't clearly show that this is still being done. Let me try to clarify this situation in light of the 3GPP architecture: 1. Draft-undery is being used for UE - P-CSCF int. protection. Algorithm = MD5, password = IK (communicated to the P-CSCF using method X from the S-CSCF). 2. Draft-niemi is being used for UE - S-CSCF authentication. Algorithm = AKA and no traditional password, just the shared long term secret. The authentication is based on RES. As a side effect an IK is produced (and communicated to the P-CSCF using means beyond draft-niemi). So, in this particular case Draft-Undery *does* use the IK as the password. The only remaining issue is how Draft-Niemi calculates Digest results, and whether that reveals anything interesting to attackers. Draft-niemi is an application of Digest and as such has some integrity protection features, and particular way to calculate Response. This particular way is essentially MD5(... RES ...). So at this point we are not using IK twice anywhere. But perhaps there's an attack that would reveal RES, if it was too short. (I personally think we should simply require it to be long, but I'll ignore that for the moment.) Let's study this by considering two cases: (a) AKA is run at the beginning and if any further communications with the home network take place, the RES is cached and used as a password. This allows the attack described by Greg. But as Aki explained, it seems that we have forbidden this in Draft-niemi. (b) AKA has to be run every time, and a RES can't be reused. Is there a problem left then? Jari _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Fri Mar 15 04:44:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24618 for ; Fri, 15 Mar 2002 04:44:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA03305 for sip-security-archive@odin.ietf.org; Fri, 15 Mar 2002 04:44:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03194; Fri, 15 Mar 2002 04:43:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03146 for ; Fri, 15 Mar 2002 04:43:48 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24604; Fri, 15 Mar 2002 04:43:39 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2F9iOi25489; Fri, 15 Mar 2002 11:44:24 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 15 Mar 2002 11:43:41 +0200 Received: from nokia.com ([172.21.149.105]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 15 Mar 2002 11:43:41 +0200 Message-ID: <3C91C23F.2020607@nokia.com> Date: Fri, 15 Mar 2002 11:43:27 +0200 From: "Niemi Aki (NET/Espoo)" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020212 X-Accept-Language: en-us MIME-Version: 1.0 To: ext Jari Arkko CC: John W Noerenberg II , sipping@ietf.org, sip-security@ietf.org, Greg Rose , jari.arkko@ericsson.com, vesa.torvinen@ericsson.fi, James Undery , Sanjoy Sen References: <3C9191C9.3000507@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Mar 2002 09:43:41.0091 (UTC) FILETIME=[E3BEA730:01C1CC05] Content-Transfer-Encoding: 7bit Subject: [Sip-security] Re: [Sipping] SIP authentication problem when using RES in Digest-AKA Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit Hi All, On 03/15/2002 08:16 AM, ext Jari Arkko wrote: > John, Greg, > > Thanks for an interesting describing this interesting attack! I believe > while making draft-niemi the authors have been assuming that we do not > use the GSM compatibility mode (which I believe is the reason why the RES > could be only 32 bits). That is, when full AKA is used this isn't a problem. > > So, we could either > > (1) Require the full use of AKA > (2) Switch to using IK and not RES as input in the Digest process As far as I understand the authentication/integrity protection schemes of 3GPP IMS, the authentication is between the UE and the S-CSCF, and the integrity protection is between the UE and the P-CSCF. Therefore I can't see a problem in using RES as input for Digest AKA in the authentication, and IK as input for the Digest in integrity protection. The RES would then constitute a one-time password type key, whereas IK is a more long term key for integrity protection. I don't see a need to group the two mechanisms together. Cheers, Aki > Greg, is the IK free of similar limitations when GSM compatibility > is used? > > Jari > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Fri Mar 15 05:07:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25113 for ; Fri, 15 Mar 2002 05:07:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA05868 for sip-security-archive@odin.ietf.org; Fri, 15 Mar 2002 05:07:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA05618; Fri, 15 Mar 2002 05:05:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA05485 for ; Fri, 15 Mar 2002 05:05:16 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25071; Fri, 15 Mar 2002 05:05:12 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 15 Mar 2002 10:05:31 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 15 Mar 2002 10:08:14 -0000 Message-ID: <45730E094814E44488F789C1CDED27AEC552CF@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: SIP authentication problem when using RES in Digest-AKA Thread-Index: AcHLukHDS+VNSM5HRdiN0LwsVn+XAwATIoXw From: "James Undery" To: "John W Noerenberg II" , , Cc: "Greg Rose" , , , , "Sanjoy Sen" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA05488 Subject: [Sip-security] RE: SIP authentication problem when using RES in Digest-AKA Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 8bit Forgive me for being a bit slow, but I can't see how this attack works. Firstly I'll check RES uses a shared secret and some entropy to create a session password to provide forward security? Comments inline. > -----Original Message----- > From: John W Noerenberg II [mailto:jwn2@qualcomm.com] > Sent: 15 March 2002 00:38 > To: sipping@ietf.org; sip-security@ietf.org > Cc: Greg Rose; aki.niemi@nokia.com; jari.arkko@ericsson.com; > vesa.torvinen@ericsson.fi; James Undery; Sanjoy Sen > Subject: SIP authentication problem when using RES in Digest-AKA > > > Greg Rose has identified a security problem when HTTP-Digest is > combined with the mechanism proposed in > draft-niemi-sipping-digest-aka-00 and draft-undery-sip-auth-00. He's > outlined this for the 3GPP TSG SA WG3, one of the TSG security area > working groups. > > Essentially the problem is a consequence of using a RES that is > shorter than the key from which it is derived, typically as small as > 32 bits. RES's length results from the goal of maintaining backward > compatibility with existing USIMs. RES is a choke point that can be > used to break the authentication. Instead of using RES, IK has much > greater entropy, and makes the attack prohibitively difficult. A > description of the attack against RES is given below. > > The authentication process can be summarized as follows: > > 1. UE attempts to register. > 2. The attempt is rejected because the UE is unauthenticated. The > rejection message includes AKA-related information and an HTTP-Digest > nonce. > 3. UE/USIM checks the AKA information and computes RES. > 4. RES is now used as the password shared by the UE and the CSCF. > 5. UE computes HTTP-Digest response based on RES, and > attempts to register. > 6. Registration succeeds. > > Subsequently > > 7. UE sends another SIP message (e.g. Invite) and the HTTP-Digest > method calculates authentication information based on RES. > (Actually, A1 is used, but it is derived from RES). > > Choke Point Attack > > An attacker monitoring the traffic would break the scheme as follows: > > The attacker has all the messages from steps 2 and 5 above. All of > the information used in the calculation of the response in step 5, > except for the value of RES is present in these messages. Assuming > RES is 32 bits, the attacker tries the 2**32 possible values, > comparing them to the captured response generated for step 5. With > very high probability, he will succeed with exactly one candidate > value for RES, in the time needed to calculate 2**31 MD5 hashes. > This takes ~5 minutes on a typical laptop. The RES 'secret' is surely going to be recalculated each time the session entropy (i.e. nonce) changes. Thus I'd modify step 4 and add pre7 4. RES is now used as the password shared by the UE and the CSCF for the register. pre7. UE/USIM checks the AKA information and computes RES. RES is now used as the password shared by the UE and the CSCF until the nonce is changed. The attacker now can obtain the old RES 'secret' and it has bought him zip unless given enough of these he can break the method the RES 'secret' is calculated. > Once the value of RES is known, the attacker can now forge SIP > messages or alter them in transit, recalculating the Digest after > altering the message. > > By replacing the use of RES with a higher entropy quantity, this > attack can be prevented. As noted above, Greg recommends using IK as > a replacement for RES. _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Fri Mar 15 08:21:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28004 for ; Fri, 15 Mar 2002 08:21:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA20211 for sip-security-archive@odin.ietf.org; Fri, 15 Mar 2002 08:21:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19782; Fri, 15 Mar 2002 08:18:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19744 for ; Fri, 15 Mar 2002 08:18:26 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27968; Fri, 15 Mar 2002 08:18:21 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2FDIXZ08534; Fri, 15 Mar 2002 15:18:33 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 15 Mar 2002 15:18:22 +0200 Received: from nokia.com ([172.21.149.105]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 15 Mar 2002 15:18:21 +0200 Message-ID: <3C91F48F.9020207@nokia.com> Date: Fri, 15 Mar 2002 15:18:07 +0200 From: "Niemi Aki (NET/Espoo)" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020212 X-Accept-Language: en-us MIME-Version: 1.0 To: ext Jari Arkko CC: Greg Rose , Sanjoy Sen , "'John W Noerenberg II'" , sipping@ietf.org, sip-security@ietf.org, jari.arkko@ericsson.com, vesa.torvinen@lmf.ericsson.se, James Undery References: <4.3.1.2.20020315124047.05271fd8@127.0.0.1> <3C91C1C6.E3464A36@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Mar 2002 13:18:21.0792 (UTC) FILETIME=[E13DA600:01C1CC23] Content-Transfer-Encoding: 7bit Subject: [Sip-security] Re: [Sipping] Re: SIP authentication problem when using RES in Digest-AKA Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit Hi, On 03/15/2002 11:41 AM, ext Jari Arkko wrote: [snip] > Let's study this by considering two cases: > > (a) AKA is run at the beginning and if any further > communications with the home network take place, > the RES is cached and used as a password. This > allows the attack described by Greg. But as > Aki explained, it seems that we have forbidden > this in Draft-niemi. I would further divide this into two subcases: (a1) The actual Digest credentials are cached, and the UA attempts to use them in further communications with the same server. If the server is not happy with then, it can rechallenge. (a2) The RES is cached, and used again as part of the stale nonce scheme when calculating Digest credentials. From these two, I'd say only the second case seems to be forbidden in draft-niemi. Regards, Aki > (b) AKA has to be run every time, and a RES can't be > reused. Is there a problem left then? > > Jari > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Fri Mar 15 11:26:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03195 for ; Fri, 15 Mar 2002 11:26:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05576 for sip-security-archive@odin.ietf.org; Fri, 15 Mar 2002 11:26:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05482; Fri, 15 Mar 2002 11:25:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05442 for ; Fri, 15 Mar 2002 11:25:12 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03168; Fri, 15 Mar 2002 11:25:09 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2FGOX126284; Fri, 15 Mar 2002 10:24:33 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Mar 2002 10:24:33 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E011879EC@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Niemi Aki (NET/Espoo)'" Cc: "'John W Noerenberg II'" , sipping@ietf.org, sip-security@ietf.org, Greg Rose , jari.arkko@ericsson.com, vesa.torvinen@ericsson.fi, James Undery Date: Fri, 15 Mar 2002 10:24:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CC3D.E2315600" Subject: [Sip-security] RE: SIP authentication problem when using RES in Digest-AKA Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1CC3D.E2315600 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Niemi Aki (NET/Espoo) [mailto:aki.niemi@nokia.com] > Sent: Friday, March 15, 2002 3:28 AM > > However, by doing this you will lose the one thing that > Digest provides, > which is authentication of the SIP message, or at least parts of it > during the authentication procedure. > > So all in all, from the AKA perspective, both options should > be equally > secure, but with Digest AKA, the SIP message is better protected. How > desirable exactly this added protection is, and indeed is the > added cost > of calculating the Digest MD5 worth the received benefits, is open to > discussion. You can always integrity-protect the message body using a separate Authorization header, if so desired. Actually, for integrity protection between UE and the P-CSCF, you would use a separate header anyways. Keeping AKA and MD5 separate gives you the option of *not* using MD5, if so desired. Sanjoy ------_=_NextPart_001_01C1CC3D.E2315600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: SIP authentication problem when using RES in = Digest-AKA

> -----Original Message-----
> From: Niemi Aki (NET/Espoo) [mailto:aki.niemi@nokia.com]
> Sent: Friday, March 15, 2002 3:28 AM

<snip>

>
> However, by doing this you will lose the one = thing that
> Digest provides,
> which is authentication of the SIP message, or = at least parts of it
> during the authentication procedure.
>
> So all in all, from the AKA perspective, both = options should
> be equally
> secure, but with Digest AKA, the SIP message is = better protected. How
> desirable exactly this added protection is, and = indeed is the
> added cost
> of calculating the Digest MD5 worth the = received benefits, is open to
> discussion.

You can always integrity-protect the message body = using a separate Authorization header, if so desired. Actually, for = integrity protection between UE and the P-CSCF, you would use a = separate header anyways. Keeping AKA and MD5 separate gives you the = option of *not* using MD5, if so desired. 

Sanjoy

------_=_NextPart_001_01C1CC3D.E2315600-- _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Fri Mar 15 11:38:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03733 for ; Fri, 15 Mar 2002 11:38:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA06535 for sip-security-archive@odin.ietf.org; Fri, 15 Mar 2002 11:38:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06469; Fri, 15 Mar 2002 11:36:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06434 for ; Fri, 15 Mar 2002 11:36:57 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03635 for ; Fri, 15 Mar 2002 11:36:54 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA07962; Fri, 15 Mar 2002 11:36:18 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA22397; Fri, 15 Mar 2002 11:36:19 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Mar 2002 11:36:18 -0500 Message-ID: <313680C9A886D511A06000204840E1CF57CCC2@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Sanjoy Sen'" , "'Niemi Aki (NET/Espoo)'" Cc: "'John W Noerenberg II'" , sip-security@ietf.org, Greg Rose , jari.arkko@ericsson.com, vesa.torvinen@ericsson.fi, James Undery Date: Fri, 15 Mar 2002 11:36:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CC3F.88456620" Subject: [Sip-security] RE: [Sipping] RE: SIP authentication problem when using RES in Di gest-AKA Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1CC3F.88456620 Content-Type: text/plain; charset="ISO-8859-1" Please folks, can we pick one list for this thread? Use sip-security. If you are going to reply to a message on this thread, delete the sipping@ietf address!!! Brian -----Original Message----- From: Sanjoy Sen [mailto:sanjoy@nortelnetworks.com] Sent: Friday, March 15, 2002 11:25 AM To: 'Niemi Aki (NET/Espoo)' Cc: 'John W Noerenberg II'; sipping@ietf.org; sip-security@ietf.org; Greg Rose; jari.arkko@ericsson.com; vesa.torvinen@ericsson.fi; James Undery Subject: [Sipping] RE: SIP authentication problem when using RES in Digest-AKA > -----Original Message----- > From: Niemi Aki (NET/Espoo) [ mailto:aki.niemi@nokia.com ] > Sent: Friday, March 15, 2002 3:28 AM > > However, by doing this you will lose the one thing that > Digest provides, > which is authentication of the SIP message, or at least parts of it > during the authentication procedure. > > So all in all, from the AKA perspective, both options should > be equally > secure, but with Digest AKA, the SIP message is better protected. How > desirable exactly this added protection is, and indeed is the > added cost > of calculating the Digest MD5 worth the received benefits, is open to > discussion. You can always integrity-protect the message body using a separate Authorization header, if so desired. Actually, for integrity protection between UE and the P-CSCF, you would use a separate header anyways. Keeping AKA and MD5 separate gives you the option of *not* using MD5, if so desired. Sanjoy ------_=_NextPart_001_01C1CC3F.88456620 Content-Type: text/html; charset="ISO-8859-1" RE: SIP authentication problem when using RES in Digest-AKA
Please folks, can we pick one list for this thread?
 
Use sip-security.  If you are going to reply to a message on this thread, delete the
sipping@ietf address!!!
 
Brian
-----Original Message-----
From: Sanjoy Sen [mailto:sanjoy@nortelnetworks.com]
Sent: Friday, March 15, 2002 11:25 AM
To: 'Niemi Aki (NET/Espoo)'
Cc: 'John W Noerenberg II'; sipping@ietf.org; sip-security@ietf.org; Greg Rose; jari.arkko@ericsson.com; vesa.torvinen@ericsson.fi; James Undery
Subject: [Sipping] RE: SIP authentication problem when using RES in Digest-AKA

> -----Original Message-----
> From: Niemi Aki (NET/Espoo) [mailto:aki.niemi@nokia.com]
> Sent: Friday, March 15, 2002 3:28 AM

<snip>

>
> However, by doing this you will lose the one thing that
> Digest provides,
> which is authentication of the SIP message, or at least parts of it
> during the authentication procedure.
>
> So all in all, from the AKA perspective, both options should
> be equally
> secure, but with Digest AKA, the SIP message is better protected. How
> desirable exactly this added protection is, and indeed is the
> added cost
> of calculating the Digest MD5 worth the received benefits, is open to
> discussion.

You can always integrity-protect the message body using a separate Authorization header, if so desired. Actually, for integrity protection between UE and the P-CSCF, you would use a separate header anyways. Keeping AKA and MD5 separate gives you the option of *not* using MD5, if so desired. 

Sanjoy

------_=_NextPart_001_01C1CC3F.88456620-- _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Sun Mar 17 20:27:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14537 for ; Sun, 17 Mar 2002 20:27:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA19594 for sip-security-archive@odin.ietf.org; Sun, 17 Mar 2002 20:27:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19092; Sun, 17 Mar 2002 20:12:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19057 for ; Sun, 17 Mar 2002 20:12:39 -0500 (EST) Received: from warlock.qualcomm.com (warlock.qualcomm.com [129.46.64.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14336 for ; Sun, 17 Mar 2002 20:12:36 -0500 (EST) Received: from avalon.qualcomm.com (avalon.qualcomm.com [203.30.171.11]) by warlock.qualcomm.com (8.12.1/8.9.3/8.9) with ESMTP id g2I1BuJL018149; Sun, 17 Mar 2002 17:11:57 -0800 (PST) Received: from NAVAJO.qualcomm.com by avalon.qualcomm.com (8.8.8+Sun/SMI-SVR4) id MAA03905; Mon, 18 Mar 2002 12:11:24 +1100 (EST) Message-Id: <4.3.1.2.20020318120008.01ac4fb8@127.0.0.1> X-Sender: ggr2@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 18 Mar 2002 12:10:14 +1100 To: "James Undery" From: Greg Rose Cc: "John W Noerenberg II" , , "Greg Rose" , , , , "Sanjoy Sen" In-Reply-To: <45730E094814E44488F789C1CDED27AEC552CF@GBNEWP0758M.eu.ubiq uity.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sip-security] RE: SIP authentication problem when using RES in Digest-AKA Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org [As requested, I've taken "sipping" out of the Cc: line.] At 10:08 AM 3/15/2002 +0000, James Undery wrote: >The RES 'secret' is surely going to be recalculated each time the >session entropy (i.e. nonce) changes. Thus I'd modify step 4 and add >pre7 This is definitely not in line with the intent of AKA, or the existing architecture. Greg. Greg Rose INTERNET: ggr@qualcomm.com Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/ Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Mon Mar 18 07:32:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04096 for ; Mon, 18 Mar 2002 07:32:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA00187 for sip-security-archive@odin.ietf.org; Mon, 18 Mar 2002 07:32:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00105; Mon, 18 Mar 2002 07:31:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00074 for ; Mon, 18 Mar 2002 07:31:18 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04079 for ; Mon, 18 Mar 2002 07:31:11 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2ICVBUw029411 for ; Mon, 18 Mar 2002 13:31:11 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Mon Mar 18 13:31:09 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Mar 2002 13:29:27 +0100 Message-ID: <9BE4301455E0D211966C0008C75D692B0642964C@esemont031.gbg.edt.ericsson.se> From: "Krister Boman (EMW)" To: "'James Undery'" , John W Noerenberg II , sipping@ietf.org, sip-security@ietf.org, Greg Rose Cc: aki.niemi@nokia.com, jari.arkko@ericsson.com, "Vesa Torvinen (LMF)" , Sanjoy Sen Date: Mon, 18 Mar 2002 13:31:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip-security] RE: [Sipping] RE: SIP authentication problem when using RES in Di gest-AKA Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Dear All, sorry if I may repeat something due to coming late into the discussions here. I have anyway some comments especially to the text from John below. I interpret the text below as being 3GPP architecture specific since the terms UE and CSCF are mentioned. I think that regarding authentication and integrity protection 3GPP have the following possible scenarios under discussion: Authentication: 1. Digest AKA is used for authentication and the subscriber could potentially use the RES as a password. Integrity protecion: 2a. Using Extensions to Digest as described in the Undery I-D and in TS33.203 where the *IK* (128 bits) should be used as integrity key/password, please consult TS33.203 version 200 clause C.2.1. 2b. Using IPSec ESP as a basis were SIP take the IKE role etc. Still the same key i.e. *IK* as in 2a has to be transported to the IPSec layer so it would also be 128 bits. So regardless if 2a or 2b is finally the preferred solution still case 1. is applicable for both solutions. Hence 7. below should not occur according to TS33.203. Question: Is there any really security problems which is specifically linked between Digest AKA and the Undery I-D/TS33.203? I cannot see that right now. But maybe I have misinterpreted something? Another question: why cannot 3GPP mandate for case 1. that the RES shall be 128 bits for IMS access if that is used as a password to Digest AKA? Regards Krister Boman Editor of TS33.203 -----Original Message----- From: James Undery [mailto:jundery@ubiquity.net] Sent: fredag 15 mars 2002 11:08 To: John W Noerenberg II; sipping@ietf.org; sip-security@ietf.org Cc: Greg Rose; aki.niemi@nokia.com; jari.arkko@ericsson.com; vesa.torvinen@lmf.ericsson.se; Sanjoy Sen Subject: [Sipping] RE: SIP authentication problem when using RES in Digest-AKA Forgive me for being a bit slow, but I can't see how this attack works. Firstly I'll check RES uses a shared secret and some entropy to create a session password to provide forward security? Comments inline. > -----Original Message----- > From: John W Noerenberg II [mailto:jwn2@qualcomm.com] > Sent: 15 March 2002 00:38 > To: sipping@ietf.org; sip-security@ietf.org > Cc: Greg Rose; aki.niemi@nokia.com; jari.arkko@ericsson.com; > vesa.torvinen@ericsson.fi; James Undery; Sanjoy Sen > Subject: SIP authentication problem when using RES in Digest-AKA > > > Greg Rose has identified a security problem when HTTP-Digest is > combined with the mechanism proposed in > draft-niemi-sipping-digest-aka-00 and draft-undery-sip-auth-00. He's > outlined this for the 3GPP TSG SA WG3, one of the TSG security area > working groups. > > Essentially the problem is a consequence of using a RES that is > shorter than the key from which it is derived, typically as small as > 32 bits. RES's length results from the goal of maintaining backward > compatibility with existing USIMs. RES is a choke point that can be > used to break the authentication. Instead of using RES, IK has much > greater entropy, and makes the attack prohibitively difficult. A > description of the attack against RES is given below. > > The authentication process can be summarized as follows: > > 1. UE attempts to register. > 2. The attempt is rejected because the UE is unauthenticated. The > rejection message includes AKA-related information and an HTTP-Digest > nonce. > 3. UE/USIM checks the AKA information and computes RES. > 4. RES is now used as the password shared by the UE and the CSCF. > 5. UE computes HTTP-Digest response based on RES, and > attempts to register. > 6. Registration succeeds. > > Subsequently > > 7. UE sends another SIP message (e.g. Invite) and the HTTP-Digest > method calculates authentication information based on RES. > (Actually, A1 is used, but it is derived from RES). > > Choke Point Attack > > An attacker monitoring the traffic would break the scheme as follows: > > The attacker has all the messages from steps 2 and 5 above. All of > the information used in the calculation of the response in step 5, > except for the value of RES is present in these messages. Assuming > RES is 32 bits, the attacker tries the 2**32 possible values, > comparing them to the captured response generated for step 5. With > very high probability, he will succeed with exactly one candidate > value for RES, in the time needed to calculate 2**31 MD5 hashes. > This takes ~5 minutes on a typical laptop. The RES 'secret' is surely going to be recalculated each time the session entropy (i.e. nonce) changes. Thus I'd modify step 4 and add pre7 4. RES is now used as the password shared by the UE and the CSCF for the register. pre7. UE/USIM checks the AKA information and computes RES. RES is now used as the password shared by the UE and the CSCF until the nonce is changed. The attacker now can obtain the old RES 'secret' and it has bought him zip unless given enough of these he can break the method the RES 'secret' is calculated. > Once the value of RES is known, the attacker can now forge SIP > messages or alter them in transit, recalculating the Digest after > altering the message. > > By replacing the use of RES with a higher entropy quantity, this > attack can be prevented. As noted above, Greg recommends using IK as > a replacement for RES. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Mon Mar 18 08:36:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04922 for ; Mon, 18 Mar 2002 08:36:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA03004 for sip-security-archive@odin.ietf.org; Mon, 18 Mar 2002 08:36:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02770; Mon, 18 Mar 2002 08:34:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02724 for ; Mon, 18 Mar 2002 08:34:12 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04882 for ; Mon, 18 Mar 2002 08:34:05 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2IDY5Uw011509 for ; Mon, 18 Mar 2002 14:34:05 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Mar 18 14:34:04 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Mar 2002 14:32:21 +0100 Message-ID: <9BE4301455E0D211966C0008C75D692B0642964D@esemont031.gbg.edt.ericsson.se> From: "Krister Boman (EMW)" To: "'James Undery'" , John W Noerenberg II , sipping@ietf.org, sip-security@ietf.org Cc: Greg Rose , aki.niemi@nokia.com, jari.arkko@ericsson.com, "Vesa Torvinen (LMF)" , Sanjoy Sen Date: Mon, 18 Mar 2002 14:33:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip-security] RE: [Sipping] RE: SIP authentication problem when using RES in Di gest-AKA Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Dear All, just realized that the format I used did not come out well on the mailing lists. Hence I re-submit this message that hopefully will be easier to read. Sorry for that. I have anyway some comments especially to the text from John below. I interpret the text below as being 3GPP architecture specific since the terms UE and CSCF are mentioned. I think that regarding authentication and integrity protection 3GPP have the following possible scenarios under discussion: Authentication: 1. Digest AKA is used for authentication and the subscriber could potentially use the RES as a password. Integrity protecion: 2a. Using Extensions to Digest as described in the Undery I-D and in TS33.203 where the *IK* (128 bits) should be used as integrity key/password, please consult TS33.203 version 200 clause C.2.1. 2b. Using IPSec ESP as a basis were SIP take the IKE role etc. Still the same key i.e. *IK* will be used as in 2a but it has to be transported to the IPSec layer but it would also be 128 bits. So regardless if 2a or 2b is finally the preferred solution still case 1. is applicable for both solutions. Hence 7. below should not occur according to TS33.203. Question: Is there any really security problems which is specifically linked between Digest AKA and the Undery I-D/TS33.203? I cannot see that right now. But maybe I have misinterpreted something? Another question: why cannot 3GPP mandate for case 1. that the RES shall be 128 bits for IMS access if that is used as a password to Digest AKA? Regards Krister Boman Editor of TS33.203 -----Original Message----- From: James Undery [mailto:jundery@ubiquity.net] Sent: fredag 15 mars 2002 11:08 To: John W Noerenberg II; sipping@ietf.org; sip-security@ietf.org Cc: Greg Rose; aki.niemi@nokia.com; jari.arkko@ericsson.com; vesa.torvinen@lmf.ericsson.se; Sanjoy Sen Subject: [Sipping] RE: SIP authentication problem when using RES in Digest-AKA Forgive me for being a bit slow, but I can't see how this attack works. Firstly I'll check RES uses a shared secret and some entropy to create a session password to provide forward security? Comments inline. > -----Original Message----- > From: John W Noerenberg II [mailto:jwn2@qualcomm.com] > Sent: 15 March 2002 00:38 > To: sipping@ietf.org; sip-security@ietf.org > Cc: Greg Rose; aki.niemi@nokia.com; jari.arkko@ericsson.com; > vesa.torvinen@ericsson.fi; James Undery; Sanjoy Sen > Subject: SIP authentication problem when using RES in Digest-AKA > > > Greg Rose has identified a security problem when HTTP-Digest is > combined with the mechanism proposed in > draft-niemi-sipping-digest-aka-00 and draft-undery-sip-auth-00. He's > outlined this for the 3GPP TSG SA WG3, one of the TSG security area > working groups. > > Essentially the problem is a consequence of using a RES that is > shorter than the key from which it is derived, typically as small as > 32 bits. RES's length results from the goal of maintaining backward > compatibility with existing USIMs. RES is a choke point that can be > used to break the authentication. Instead of using RES, IK has much > greater entropy, and makes the attack prohibitively difficult. A > description of the attack against RES is given below. > > The authentication process can be summarized as follows: > > 1. UE attempts to register. > 2. The attempt is rejected because the UE is unauthenticated. The > rejection message includes AKA-related information and an HTTP-Digest > nonce. > 3. UE/USIM checks the AKA information and computes RES. > 4. RES is now used as the password shared by the UE and the CSCF. > 5. UE computes HTTP-Digest response based on RES, and > attempts to register. > 6. Registration succeeds. > > Subsequently > > 7. UE sends another SIP message (e.g. Invite) and the HTTP-Digest > method calculates authentication information based on RES. > (Actually, A1 is used, but it is derived from RES). > > Choke Point Attack > > An attacker monitoring the traffic would break the scheme as follows: > > The attacker has all the messages from steps 2 and 5 above. All of > the information used in the calculation of the response in step 5, > except for the value of RES is present in these messages. Assuming > RES is 32 bits, the attacker tries the 2**32 possible values, > comparing them to the captured response generated for step 5. With > very high probability, he will succeed with exactly one candidate > value for RES, in the time needed to calculate 2**31 MD5 hashes. > This takes ~5 minutes on a typical laptop. The RES 'secret' is surely going to be recalculated each time the session entropy (i.e. nonce) changes. Thus I'd modify step 4 and add pre7 4. RES is now used as the password shared by the UE and the CSCF for the register. pre7. UE/USIM checks the AKA information and computes RES. RES is now used as the password shared by the UE and the CSCF until the nonce is changed. The attacker now can obtain the old RES 'secret' and it has bought him zip unless given enough of these he can break the method the RES 'secret' is calculated. > Once the value of RES is known, the attacker can now forge SIP > messages or alter them in transit, recalculating the Digest after > altering the message. > > By replacing the use of RES with a higher entropy quantity, this > attack can be prevented. As noted above, Greg recommends using IK as > a replacement for RES. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Mon Mar 18 13:22:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14241 for ; Mon, 18 Mar 2002 13:22:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA23825 for sip-security-archive@odin.ietf.org; Mon, 18 Mar 2002 13:22:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23639; Mon, 18 Mar 2002 13:18:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23608 for ; Mon, 18 Mar 2002 13:18:37 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14094 for ; Mon, 18 Mar 2002 13:18:33 -0500 (EST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id EA92E6A905; Mon, 18 Mar 2002 20:17:34 +0200 (EET) Message-ID: <3C960ACB.9040907@piuha.net> Date: Mon, 18 Mar 2002 17:42:03 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Greg Rose Cc: James Undery , John W Noerenberg II , sip-security@ietf.org, aki.niemi@nokia.com, jari.arkko@ericsson.com, vesa.torvinen@ericsson.fi, Sanjoy Sen Subject: Re: [Sip-security] RE: SIP authentication problem when using RES in Digest-AKA References: <4.3.1.2.20020318120008.01ac4fb8@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit Greg Rose wrote in response to James Undery: >> The RES 'secret' is surely going to be recalculated each time the >> session entropy (i.e. nonce) changes. Thus I'd modify step 4 and add >> pre7 > > This is definitely not in line with the intent of AKA, or the existing > architecture. What I understood James proposing is that *if* AKA is used for the authentication of an INVITE to the home after being used for authenticating a REGISTER, then AKA should be re-run. In the above, do you mean the 3GPP architecture in 'the existing architecture'? From what I understand the 3GPP architecture only intends to authenticate REGISTERs with AKA. Therefore, if draft-niemi allows anything to happen after the first authentication, it is beyond the 3GPP architecture. If plugging a security hole requires that we never allow AKA authentication to be reused and always need a new full AKA run, I would say that's fine. Greg, does preventing reuse of the same RES help to block the security problem? Also, I have proposed simply requiring 128 bit RES values to be used, that solves the problem but is there any reason why we couldn't require it? Then we have another matter of how the INVITEs are authenticated in 3GPP. That is based on the session keys generated as a side effect of AKA. Let's keep the AKA re-run to the home -discussion separate from this. Jari _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security From daemon@ns.ietf.org Mon Mar 18 15:44:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19478 for ; Mon, 18 Mar 2002 15:44:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA05172 for sip-security-archive@odin.ietf.org; Mon, 18 Mar 2002 15:44:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05054; Mon, 18 Mar 2002 15:43:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05021 for ; Mon, 18 Mar 2002 15:43:26 -0500 (EST) Received: from warlock.qualcomm.com (warlock.qualcomm.com [129.46.64.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19447 for ; Mon, 18 Mar 2002 15:43:21 -0500 (EST) Received: from avalon.qualcomm.com (avalon.qualcomm.com [203.30.171.11]) by warlock.qualcomm.com (8.12.1/8.9.3/8.9) with ESMTP id g2IKgqJL028338; Mon, 18 Mar 2002 12:42:53 -0800 (PST) Received: from NAVAJO.qualcomm.com by avalon.qualcomm.com (8.8.8+Sun/SMI-SVR4) id HAA05530; Tue, 19 Mar 2002 07:42:13 +1100 (EST) Message-Id: <4.3.1.2.20020319073002.01ae0438@127.0.0.1> X-Sender: ggr2@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 19 Mar 2002 07:41:00 +1100 To: jari.arkko@piuha.net From: Greg Rose Subject: Re: [Sip-security] RE: SIP authentication problem when using RES in Digest-AKA Cc: Greg Rose , James Undery , John W Noerenberg II , sip-security@ietf.org, aki.niemi@nokia.com, jari.arkko@ericsson.com, vesa.torvinen@ericsson.fi, Sanjoy Sen In-Reply-To: <3C960ACB.9040907@piuha.net> References: <4.3.1.2.20020318120008.01ac4fb8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Thanks for your questions. At 05:42 PM 3/18/2002 +0200, Jari Arkko wrote: >Greg Rose wrote in response to James Undery: > > >>>The RES 'secret' is surely going to be recalculated each time the >>>session entropy (i.e. nonce) changes. Thus I'd modify step 4 and add >>>pre7 >>This is definitely not in line with the intent of AKA, or the existing >>architecture. > > >What I understood James proposing is that *if* AKA is used for the >authentication of an INVITE to the home after being used for authenticating >a REGISTER, then AKA should be re-run. Yes, in theory that would be fine, but I did not get this from my reading of draft-undery. It appears to me that it uses the same A1 that was calculated during the processing of the register message, in the subsequent step. >In the above, do you mean the 3GPP architecture in 'the existing >architecture'? > From what I understand the 3GPP architecture only intends to authenticate > REGISTERs >with AKA. Therefore, if draft-niemi allows anything to happen after the >first authentication, it is beyond the 3GPP architecture. Yes, true. > If plugging a >security hole requires that we never allow AKA authentication to be reused >and always need a new full AKA run, I would say that's fine. Greg, does >preventing reuse of the same RES help to block the security problem? It helps but it doesn't completely solve the problem. Whatever the process by which RES (old *or new*) is used to calculate the authentication values, can be used by a man-in-the-middle: 1. Mal gets the SIP message, and blocks its onward delivery. 2. He quickly sets his lab of computers to the task of finding 32-bit RES. 3. Before the reply timer expires, he can create any message he wants, and authenticate it using that value of RES, even though it is only used once. Note that even a 64-bit RES probably defeats this. Note also that air-interface ciphering also stops it working, if Mal is on the air interface... but he might not be. >Also, I have proposed simply requiring 128 bit RES values to be used, >that solves the problem but is there any reason why we couldn't require >it? I had understood that there were compatibility issues with this, but that is a question for operators to answer... I don't know. Anyway, I'd be perfectly happy if that was done; all my objections would go away. Thanks, Greg. Greg Rose INTERNET: ggr@qualcomm.com Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/ Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security From daemon@ns.ietf.org Mon Mar 18 16:03:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20013 for ; Mon, 18 Mar 2002 16:03:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA06593 for sip-security-archive@odin.ietf.org; Mon, 18 Mar 2002 16:03:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06549; Mon, 18 Mar 2002 16:02:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06509 for ; Mon, 18 Mar 2002 16:01:58 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19954 for ; Mon, 18 Mar 2002 16:01:40 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id E17696A906; Mon, 18 Mar 2002 23:01:26 +0200 (EET) Message-ID: <3C9655FC.6030500@kolumbus.fi> Date: Mon, 18 Mar 2002 23:02:52 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Greg Rose Cc: aki.niemi@nokia.com, James Undery , John W Noerenberg II , sip-security@ietf.org, torvive , vesa.torvinen@ericsson.fi, Sanjoy Sen Subject: Re: [Sip-security] RE: SIP authentication problem when using RES in Digest-AKA References: <4.3.1.2.20020318120008.01ac4fb8@127.0.0.1> <4.3.1.2.20020319073002.01ae0438@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit Hi Greg and thanks for your response. Some further discussion below. >> What I understood James proposing is that *if* AKA is used for the >> authentication of an INVITE to the home after being used for >> authenticating >> a REGISTER, then AKA should be re-run. > > Yes, in theory that would be fine, but I did not get this from my > reading of draft-undery. It appears to me that it uses the same A1 that > was calculated during the processing of the register message, in the > subsequent step. This may be true, but draft-undery doesn't deal with AKA. Draft-niemi does. If you meant draft-niemi, then we should fix it (it shouldn't do that). > It helps but it doesn't completely solve the problem. Whatever the > process by which RES (old *or new*) is used to calculate the > authentication values, can be used by a man-in-the-middle: > 1. Mal gets the SIP message, and blocks its onward delivery. > 2. He quickly sets his lab of computers to the task of finding 32-bit RES. > 3. Before the reply timer expires, he can create any message he wants, > and authenticate it using that value of RES, even though it is only used > once. > > Note that even a 64-bit RES probably defeats this. Fair enough, I suspected that this might be the case. But a further question. Assuming a MD5(RES) is crackable and the MitM can send his own request, why isn't pure RES crackable in the same way? That is, if we send just the RES, the MitM can just pick the value and without any lab computers he can place the RES in a different request, and the server side can't detect anything. So, while I understand the attack, what does removing MD5 encapsulation give us? >> Also, I have proposed simply requiring 128 bit RES values to be used, >> that solves the problem but is there any reason why we couldn't require >> it? > > I had understood that there were compatibility issues with this, but > that is a question for operators to answer... I don't know. Anyway, I'd > be perfectly happy if that was done; all my objections would go away. Ok, let's try to figure this question out then. Jari _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security From daemon@ns.ietf.org Mon Mar 18 22:32:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02730 for ; Mon, 18 Mar 2002 22:32:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA02924 for sip-security-archive@odin.ietf.org; Mon, 18 Mar 2002 22:32:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02461; Mon, 18 Mar 2002 22:30:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02380 for ; Mon, 18 Mar 2002 22:30:00 -0500 (EST) Received: from warlock.qualcomm.com (warlock.qualcomm.com [129.46.64.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01684 for ; Mon, 18 Mar 2002 22:29:55 -0500 (EST) Received: from avalon.qualcomm.com (avalon.qualcomm.com [203.30.171.11]) by warlock.qualcomm.com (8.12.1/8.9.3/8.9) with ESMTP id g2J3TQJL002754; Mon, 18 Mar 2002 19:29:27 -0800 (PST) Received: from NAVAJO.qualcomm.com by avalon.qualcomm.com (8.8.8+Sun/SMI-SVR4) id OAA06187; Tue, 19 Mar 2002 14:28:48 +1100 (EST) Message-Id: <4.3.1.2.20020319141758.01b38940@127.0.0.1> X-Sender: ggr2@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 19 Mar 2002 14:27:33 +1100 To: Jari Arkko From: Greg Rose Subject: Re: [Sip-security] RE: SIP authentication problem when using RES in Digest-AKA Cc: Greg Rose , aki.niemi@nokia.com, James Undery , John W Noerenberg II , sip-security@ietf.org, torvive , vesa.torvinen@ericsson.fi, Sanjoy Sen In-Reply-To: <3C9655FC.6030500@kolumbus.fi> References: <4.3.1.2.20020318120008.01ac4fb8@127.0.0.1> <4.3.1.2.20020319073002.01ae0438@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org At 11:02 PM 3/18/2002 +0200, Jari Arkko wrote: >This may be true, but draft-undery doesn't deal with AKA. Draft-niemi >does. If you meant draft-niemi, then we should fix it (it shouldn't >do that). As I've said all along, there's no problem with draft-undery by itself. And since I've now identified a problem with even a single message integrity calculation using 32-bit RES, yes, we can focus on draft-niemi. >Fair enough, I suspected that this might be the case. >But a further question. Assuming a MD5(RES) is crackable >and the MitM can send his own request, why isn't pure RES >crackable in the same way? That is, if we send just the >RES, the MitM can just pick the value and without any lab >computers he can place the RES in a different request, and >the server side can't detect anything. So, while I understand >the attack, what does removing MD5 encapsulation give us? This is a very deep philosophical question :-). It has to do with the difference between authentication and message integrity. Just sending RES implies that the real terminal (ISIM) existed and was in contact at this point in time. By itself, it says nothing about the message that contained it. But if RES is also used to calculate some sort of message integrity check, it seems to be promising something that it isn't delivering, namely message integrity via HTTP-digest. >[Just use 128-bit RES then?] >Ok, let's try to figure this question out then. I agree, let's just find out if this is truly an option. regards, and apologies if I sound argumentative, Greg. Greg Rose INTERNET: ggr@qualcomm.com Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/ Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Fri Mar 29 12:34:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24755 for ; Fri, 29 Mar 2002 12:34:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA19885 for sip-security-archive@odin.ietf.org; Fri, 29 Mar 2002 12:34:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19855; Fri, 29 Mar 2002 12:33:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19780 for ; Fri, 29 Mar 2002 12:33:27 -0500 (EST) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24721 for ; Fri, 29 Mar 2002 12:33:22 -0500 (EST) Received: from [129.46.77.186] (eriador.qualcomm.com [129.46.77.186]) by mage.qualcomm.com (8.12.1/8.12.1/1.0) with ESMTP id g2THWZO2019515; Fri, 29 Mar 2002 09:32:36 -0800 (PST) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: <4.3.1.2.20020319141758.01b38940@127.0.0.1> References: <4.3.1.2.20020318120008.01ac4fb8@127.0.0.1> <4.3.1.2.20020319073002.01ae0438@127.0.0.1> <4.3.1.2.20020319141758.01b38940@127.0.0.1> X-Mailer: eudora51carbon-0328020920 X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Fri, 29 Mar 2002 09:29:16 -0800 To: Greg Rose From: John W Noerenberg II Subject: Re: [Sip-security] RE: SIP authentication problem when using RES in Digest-AKA Cc: Jari Arkko , Greg Rose , aki.niemi@nokia.com, James Undery , sip-security@ietf.org, torvive , vesa.torvinen@ericsson.fi, Sanjoy Sen Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org At 2:27 PM +1100 3/19/02, Greg Rose wrote: >>[Just use 128-bit RES then?] >>Ok, let's try to figure this question out then. > >I agree, let's just find out if this is truly an option. Has anyone determined whether or not a 128-bit RES is backward compatible? -- john noerenberg jwn2@qualcomm.com ---------------------------------------------------------------------- While the belief we have found the Answer can separate us and make us forget our humanity, it is the seeking that continues to bring us together, that makes and keeps us human. -- Daniel J. Boorstin, "The Seekers", 1998 ---------------------------------------------------------------------- _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Sat Mar 30 21:45:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09215 for ; Sat, 30 Mar 2002 21:45:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA22091 for sip-security-archive@odin.ietf.org; Sat, 30 Mar 2002 21:45:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA22060; Sat, 30 Mar 2002 21:43:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA22025 for ; Sat, 30 Mar 2002 21:43:43 -0500 (EST) Received: from warlock.qualcomm.com (warlock.qualcomm.com [129.46.64.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09199 for ; Sat, 30 Mar 2002 21:43:39 -0500 (EST) Received: from avalon.qualcomm.com (avalon.qualcomm.com [203.30.171.11]) by warlock.qualcomm.com (8.12.1/8.9.3/8.9) with ESMTP id g2V2gCJn013411; Sat, 30 Mar 2002 18:42:13 -0800 (PST) Received: from [203.30.171.36] by avalon.qualcomm.com (8.8.8+Sun/SMI-SVR4) id MAA11784; Sun, 31 Mar 2002 12:39:26 +1000 (EST) Mime-Version: 1.0 X-Sender: ggr2@avalon.qualcomm.com Message-Id: In-Reply-To: References: <4.3.1.2.20020318120008.01ac4fb8@127.0.0.1> <4.3.1.2.20020319073002.01ae0438@127.0.0.1> <4.3.1.2.20020319141758.01b38940@127.0.0.1> Date: Sun, 31 Mar 2002 12:39:19 +1000 To: John W Noerenberg II From: Greg Rose Subject: Re: [Sip-security] RE: SIP authentication problem when using RES in Digest-AKA Cc: Jari Arkko , aki.niemi@nokia.com, James Undery , sip-security@ietf.org, torvive , vesa.torvinen@ericsson.fi, Sanjoy Sen Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org At 9:29 -0800 29/3/02, John W Noerenberg II wrote: >At 2:27 PM +1100 3/19/02, Greg Rose wrote: >>>[Just use 128-bit RES then?] >>>Ok, let's try to figure this question out then. >> >>I agree, let's just find out if this is truly an option. > >Has anyone determined whether or not a 128-bit RES is backward compatible? Definitely not backward compatible, although that might not yet be a big deal. In the meantime, however, the vote in SA3 has been to go with IPsec for integrity protection, so the problem is now moot; 32-bit RES is sufficient in that context. thanks, Greg. _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security From daemon@optimus.ietf.org Sun Mar 31 01:01:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11840 for ; Sun, 31 Mar 2002 01:01:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA28594 for sip-security-archive@odin.ietf.org; Sun, 31 Mar 2002 01:01:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28582; Sun, 31 Mar 2002 01:01:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28549 for ; Sun, 31 Mar 2002 01:01:01 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11823 for ; Sun, 31 Mar 2002 01:00:56 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 263416A904; Sun, 31 Mar 2002 09:00:52 +0300 (EEST) Message-ID: <3CA69865.8080508@kolumbus.fi> Date: Sun, 31 Mar 2002 08:02:29 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Greg Rose Cc: John W Noerenberg II , aki.niemi@nokia.com, James Undery , sip-security@ietf.org, torvive , vesa.torvinen@ericsson.fi, Sanjoy Sen Subject: Re: [Sip-security] RE: SIP authentication problem when using RES in Digest-AKA References: <4.3.1.2.20020318120008.01ac4fb8@127.0.0.1> <4.3.1.2.20020319073002.01ae0438@127.0.0.1> <4.3.1.2.20020319141758.01b38940@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-security-admin@ietf.org Errors-To: sip-security-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Security Issues for the SIP protocol X-BeenThere: sip-security@ietf.org Content-Transfer-Encoding: 7bit Greg Rose wrote: >> Has anyone determined whether or not a 128-bit RES is backward >> compatible? > > Definitely not backward compatible, although that might not yet be a big > deal. In the meantime, however, the vote in SA3 has been to go with > IPsec for integrity protection, so the problem is now moot; 32-bit RES > is sufficient in that context. As far as I understand, whether IPsec or James' enhanced digest was adopted as the solution for first hop integrity protection does not affect the RES discussion at all. Both use the generated session key, IK, and not RES. The only discussion has been on whether Digest AKA -- the home authentication scheme for 3G networks -- uses RES in the clear or whether it ties the RES to the rest of the message using MD5. The former approach is kind of like basic using one time passwords, the latter is regular digest usage. The former is always vulnerable to someone replacing the message contents but keeping RES; the latter is not vulnerable to this except when RES is short. The input from the IETF meeting was that the Digest approach is favored. Jari _______________________________________________ Sip-security mailing list Sip-security@ietf.org https://www1.ietf.org/mailman/listinfo/sip-security