Subject: Re: [Emu] Agenda Take 2

From: "SeongHan Shin" <[email-masked]>
Date: Mon, 3 Mar 2008 12:16:45 +0900

Dear all,

This is Shin.
I read the below ID (Password only Mechanism)
http://tools.ietf.org/id/draft-harkins-emu-eap-pwd-00.txt
to be presented at IETF 71.

The idea of the protocol seems interesting.
However, I found that the protocol is susceptible to off-line dictionary
attack.
If someone is interested, I'll show how the attack works.
(you may already know that.)

Best regards,
Shin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joseph
Salowey (jsalowey)
Sent: Thursday, February 28, 2008 8:04 AM
To: [email-masked]
Subject: [Emu] Agenda Take 2

EMU Agenda
IETF 71
THURSDAY, March 13, 2008
0900-1130 Morning Session I
---------------------------------------------
+ Administrivia (5 min)
 - agenda, blue sheets, note takers

+ Document Status (5 min)
 - EAP-TLS  - draft-simon-emu-rfc2716bis-13.txt
 - EAP-GPSK - draft-ietf-emu-eap-gpsk-08.txt

+ Charter Revision Status (70 min)
 - General text (10 min)
 - Tunnel Method (20 min) 
 - Secure Password Only Method (20 min)
 - Channel Bindings (20 min)
 
+ Tunnel Method Requirements (30 min)
 - draft-salowey-emu-eaptunnel-req-00.txt

+ Channel Bindings (20 min)
 - draft-clancy-emu-chbind-00.txt
 - draft-clancy-emu-aaapay-00.txt

+ Password only Mechanism (20 min)
 - draft-harkins-emu-eap-pwd-00.txt
_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu

_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 2 Mar 2008 21:16:46 -0800 (PST)

Hi Shin,

  That draft has been updated. Please see the -01 version. That is
the one that will be presented in Philly and is, I believe, resistant
to off-line dictionary attack. If you know of an attack against it
I would be extremely interested in hearing about it.

  regards,

  Dan.

---

From: "SeongHan Shin" <[email-masked]>
Date: Mon, 3 Mar 2008 15:27:28 +0900

Dear Dan Harkins,

Sorry, I didn't know that the ID is updated.
Anyway, I'll go through the new ID.

By the way, is "pwe" in section 2.6.4.2 the same as "PWE"?

Best regards,
Shin

-----Original Message-----
From: Dan Harkins [mailto:[email-masked]] 
Sent: Monday, March 03, 2008 2:17 PM
To: SeongHan Shin
Cc: [email-masked]; 'Kazukuni Kobara'
Subject: Re: [Emu] Agenda Take 2

  Hi Shin,

  regards,

  Dan.

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 2 Mar 2008 23:06:21 -0800

> By the way, is "pwe" in section 2.6.4.2 the same as "PWE"?

Yes.

...

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 2 Mar 2008 23:07:11 -0800 (PST)

Hi Shin,

  I'll put this on the list for cleanup in the -02 version.
In section 2.6.3.2 it describes constructing the password element
for a prime modulus group. It says:

      pwd-value = KDF(pwd-seed, "EAP-pwd Affixing the PWE", len(p))

      PWE = pwd-value mod p

this should be:

      pwd-value = pwd-value mod p

We want to ensure the value stretched to the length of the prime is
numerically less than the prime. Section 2.6.3.2 goes on to say:

   The PWE is then computed by exponentiating the pwd-value to the value
   ((p-1)/r) modulus the prime.

      PWD = pwd-value ^ ((p-1)/r) mod p

I'm not sure where PWD came from :-). The convention is capitals for
elliptic curve groups to distinguish between elements and scalars. There
is no such convention for prime modulus groups so it should be:

   The pwe is then computed by exponentiating the pwd-value to the value
   ((p-1)/r) modulus the prime.

      pwe = pwd-value ^ ((p-1)/r) mod p

And then that "pwe" is used in 2.6.4.2. The idea is we take a pwe-seed
derived from the secret and identities and stretch that using the KDF
into a pwd-value which we reduce modulo the prime. The pwd-value is then
used to construct the password element, pwe, by exponentiating as
described above-- pwd-value ^ ((p-1)/r) mod p. I obviously messed up the
description of that.

  As I said, I'll clean this up in the next version. If you do find any
security issues with this draft please let me know. And also if there are
other typographical errors or similar issues you come across please tell
me so I can clean them up.

  regards,

  Dan.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 10 Mar 2008 14:54:33 -0700

Hi Dan,

Could you describe the technical differences between the approach in
draft-harkins-emu-eap-pwd-00.txt and existing approaches of SRP, SPEKE
and EKE?  

Thanks,

Joe 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dan Harkins
> Sent: Sunday, March 02, 2008 11:07 PM
> To: SeongHan Shin
> Cc: 'Kazukuni Kobara'; [email-masked]
> In section 2.6.3.2 it describes constructing the password 
> element for a prime modulus group. It says:
> 
> We want to ensure the value stretched to the length of the 
> prime is numerically less than the prime. Section 2.6.3.2 
> goes on to say:
> 
> I'm not sure where PWD came from :-). The convention is 
> capitals for elliptic curve groups to distinguish between 
> elements and scalars. There is no such convention for prime 
> modulus groups so it should be:
> 
> And then that "pwe" is used in 2.6.4.2. The idea is we take a 
> pwe-seed derived from the secret and identities and stretch 
> that using the KDF into a pwd-value which we reduce modulo 
> the prime. The pwd-value is then used to construct the 
> password element, pwe, by exponentiating as described above-- 
> pwd-value ^ ((p-1)/r) mod p. I obviously messed up the 
> description of that.
> 
>   As I said, I'll clean this up in the next version. If you 
> do find any security issues with this draft please let me 
> know. And also if there are other typographical errors or 
> similar issues you come across please tell me so I can clean them up.
> 
>   regards,
> 
>   Dan.
> 
> >   That draft has been updated. Please see the -01 version. 
> That is the 
> > one that will be presented in Philly and is, I believe, 
> resistant to 
> > off-line dictionary attack. If you know of an attack against it I 
> > would be extremely interested in hearing about it.
> >
> >   regards,
> >
> >   Dan.
> >
> >> However, I found that the protocol is susceptible to off-line 
> >> dictionary attack.
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of 
> >> Joseph Salowey (jsalowey)

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 10 Mar 2008 14:56:08 -0700

Sorry, make that draft-harkins-emu-eap-pwd-01  

> Behalf Of Joseph Salowey (jsalowey)
> Sent: Monday, March 10, 2008 2:55 PM
> To: Dan Harkins; SeongHan Shin
> Cc: Kazukuni Kobara; [email-masked]
> Could you describe the technical differences between the 
> approach in draft-harkins-emu-eap-pwd-00.txt and existing 
> approaches of SRP, SPEKE and EKE?  
> 
> Thanks,
> 
> Joe 
> 
> Behalf Of 
> > Dan Harkins
> capitals for 
> > elliptic curve groups to distinguish between elements and scalars. 
> > There is no such convention for prime modulus groups so it 
> should be:
> > 
> > into a pwd-value which we reduce modulo the prime. The pwd-value is 
> > then used to construct the password element, pwe, by 
> exponentiating as 
> > described above-- pwd-value ^ ((p-1)/r) mod p. I obviously 
> messed up 
> > the description of that.
> > 
> >   As I said, I'll clean this up in the next version. If you do find 
> > any security issues with this draft please let me know. And also if 
> > there are other typographical errors or similar issues you 
> come across 
> > please tell me so I can clean them up.
> > 
> >   regards,
> > 
> >   Dan.
> >

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 10 Mar 2008 15:52:38 -0700 (PDT)

Hi Joe,

  _Technically_ there is not a whole lot of difference. They all are
resistant to passive attack, active attack, and dictionary attack.
But they go about it differently. I'm not sure how deep to go into
the differences but here goes nothing....

  EAP-pwd is symmetric while SRP is asymmetric. By this I mean that
in EAP-pwd each side generates the same thing in the same way. In SRP
there are separate formulas for Alice and Bob, they produce different
things and use each other's contribution differently.

  SRP is similar to SPEKE in that they both use exponentiation of a
shared generator, g, modulus a shared prime, p, and random numbers
chosen by each side, Alice chooses a, Bob chooses B, and they end up
with something that looks like g^abx mod p, where x=F(password) for
some defined function F. SRP is a little different in that the result
is, I believe, g^(a+bx) mod p.

  EAP-pwd is similar to SPEKE in that a "password element" is derived.
In SPEKE you note that the secret is g^abx mod p and due to the protocol
that's (g^x)^ab mod p, which actually ends up using g^x as a generator.
If you read SPEKE the author notes that g^x, where x=F(password) might
make an unsafe subgroup for some function F. It therefore lists a whole
slew of options on how to ensure that the generator is safe. EAP-pwd uses
one of these techniques for fixing the password element (for the prime
modulus group ONLY, and NOT for elliptic curve groups) but not just to stop
weak sub-group attacks but because there is an attack against EAP-pwd
that Scott Fluhrer pointed out where an attacker is able to recover the
shared secret by launching an active attack and sending "illegal" data
(whose illegality cannot be determined by the person being attacked). So
the reason for, and use of, the password element is different. Also, in
EAP-pwd the secret is not of the form (g^x)^ab because if was the attack
would be possible-- the attacker could run through passwords until he was
able to generate g^x and then would know the password and be able to
recover the secret, an attack not possible in SPEKE. That's the whole
reason EAP-pwd fixes the password element (there's a description of the
attack in the Security Considerations of the EAP-pwd -01 draft).

  EAP-pwd is different than SPEKE because addition is used to hide the
random number and both a scalar and element from the group are exchanged
by each side. In SPEKE what is sent by each side is an element in which
the random number is the exponent that generated it for some generator.
The element used by EAP-pwd is to unmask the hidden random value only.

  EKE is different than EAP-pwd because in EKE the Diffie-Hellman public
values are encrypted with a key based on the password. There is no
encryption used in EAP-pwd.

  There are non-technical differences too which I will be happy to go
into during the session on Thursday. I hope 20 minutes will be enough :-)

  regards,

  Dan.