Subject: Re: [Cfrg] I-D Action:draft-sheffer-emu-eap-eke-00.txt

From: "Steven M. Bellovin" <[email-masked]>
Date: Sun, 1 Feb 2009 12:35:20 -0500

On Thu, 29 Jan 2009 15:25:53 -0800 (PST)
"Dan Harkins" <[email-masked]> wrote:

> 
>   Hi,
> 
>   This draft specifies AES in CBC mode for encrypting the
> Diffie-Hellman exponentials. Since the data being encrypted is a
> random element in the chosen group is the additional randomization
> provided by the IV necessary?
> 
>   Normally ECB mode is an insecure encryption scheme (even if the
> underlying block cipher is secure) due to its determinism and a
> protocol that uses it is therefore flawed, but is EKE a special case
> in which security can be achieved even with ECB mode?
> 
>   Protocol designers are told by cryptographers to always authenticate
> what is being encrypted and to never use ECB. Is EKE an exception to
> those two rules?
> 
I suspect that integrity-checking is irrelevant here, though I want to
think about it some more.  I'm concerned about ECB, though perhaps only
in a theoretical sense.  Take your dictionary of guesses, and
(somehow...) build a codebook of those words encrypting a plaintext
block.  Compare each of the ciphertext blocks to your encrypted
dictionary.  If there are any matches, you have a candidate password.
If there is more than one match for the same password, it becomes very
likely.

Now -- this is theoretical, given the 128-bit blocksize of AES.  Still,
it's significantly weaker than EKE should be, since it's a form of
partition attack and hence does not require solving an instance of the
discrete log problem.  

		--Steve Bellovin, http://www.cs.columbia.edu/~smb
_______________________________________________
Cfrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/cfrg

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 1 Feb 2009 12:52:08 -0800 (PST)

Hi Steve,

> If there is more than one match for the same password, it becomes very

  The two parties share only a password. Wouldn't integrity checking the
encrypted D-H public value open up the exchange to a dictionary attack?
An attacker could record an exchange and then run through the dictionary
until the integrity checks are verified.

  It is also assumed that each party chooses a random private value with
which to generate the D-H public value. That means the D-H public value
is going to be, effectively, a random element in the field. My thought on
ECB (probably incorrect) was that the randomness of the data means that
there shouldn't be a need to add any more randomness to the encryption
process. It's like the intuition behind deterministic "key wrapping".

> partition attack and hence does not require solving an instance of the

  Well, I guess my questions were theoretical. Thank you for responding.

  regards,

  Dan.

---

From: "Scott Fluhrer" <[email-masked]>
Date: Sun, 1 Feb 2009 23:11:56 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Steven M. Bellovin
> Sent: Sunday, February 01, 2009 12:35 PM
> To: Dan Harkins
> Cc: David McGrew; [email-masked]
> Subject: Re: [Cfrg] I-D Action:draft-sheffer-emu-eap-eke-00.txt
> 
> On Thu, 29 Jan 2009 15:25:53 -0800 (PST) "Dan Harkins" 
> <[email-masked]> wrote:
> 
> > 
> >   Hi,
> > 
> I suspect that integrity-checking is irrelevant here, though 
> I want to think about it some more.  I'm concerned about ECB, 
> though perhaps only in a theoretical sense.  Take your 
> dictionary of guesses, and
> (somehow...) build a codebook of those words encrypting a 
> plaintext block.  Compare each of the ciphertext blocks to 
> your encrypted dictionary.  If there are any matches, you 
> have a candidate password.
> If there is more than one match for the same password, it 
> becomes very likely.

One thing to note about this scenario is that the base security assumptions
are backwards to normal cryptology.  Normally, we assume that the key has
strong security properties, and that the data may have little.  Here, we
assume that the key has weak security properties (the attack may have a list
of possible keys), and hence we need to ensure that the data has strong
properties (indistinguishable from random).  This difference may mean that
conventional wisdom in cryptology might not apply in this case.

In that particular case of integrity-checking, it would appear that Dan's
intuition is correct; if it based on the password, it would allow an
attacker to validate a potential key, and thus would invalidate the security
properties.

As for ECB, well, I don't see any immediate problem.  The attacker cannot
"build a codebook", as the plaintext is indistinguishable from random, and
so he would be quite incapable of deciding what should be in the codebook.
More of a concern would be the mutability properties of ECB (for example, an
attacker can shuffle plaintext blocks by shuffling the corresponding
ciphertext blocks, or create a plaintext that he knows will consist of
repeated blocks by creating a ciphertext with repeated blocks).  However, I
cannot think of a way that an attacker could actually use these mutability
properties to make even a theoretical attack on the underlying DH.  However,
my initial inclination would be to stick with CBC (which, admittedly, has
its own mutability properties), not because it is necessarily stronger, but
because I don't see any reason not to use CBC.

-- 
scott

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 2 Feb 2009 09:07:55 -0800

>conventional wisdom in cryptology might not apply in this case.

This is an excellent summary, one that should be reflected in the document itself.

--Paul Hoffman, Director
--VPN Consortium

From: Yaron Sheffer <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 10 Feb 2009 22:30:56 +0200
Accept-Language: en-US
acceptlanguage: en-US
Subject: [Cfrg] FW: I-D Action:draft-sheffer-emu-eap-eke-01.txt

Hi everyone,

Version -01 of our draft closes the vulnerability that was pointed out by S=
cott Fluhrer, by defining a new MODP group (the common Group 14, but with a=
 different generator). Your further comments are welcome.

Thanks,
        Yaron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, February 10, 2009 12:45
To: [email-masked]
Subject: I-D Action:draft-sheffer-emu-eap-eke-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.

        Title           : An EAP Authentication Method Based on the EKE Pro=
tocol
        Author(s)       : Y. Sheffer, et al.
        Filename        : draft-sheffer-emu-eap-eke-01.txt
        Pages           : 24
        Date            : 2009-02-10

The Extensible Authentication Protocol (EAP) describes a framework
that allows the use of multiple authentication mechanisms.  This
document defines an authentication mechanism for EAP called EAP-EKE,
based on the Encrypted Key Exchange (EKE) protocol.  This method
provides mutual authentication through the use of a short, easy to
remember password.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sheffer-emu-eap-eke-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Email secured by Check Point

From: David McGrew <[email-masked]>
To: [email-masked]
Date: Fri, 27 Feb 2009 06:23:13 -0800
Subject: [Cfrg] CFRG Mail List Archiving Incorrectly

This is just for your information, but the CFRG mail list has not been  
archiving correctly this month; the problem has been identified and  
will be fixed.

David

Begin forwarded message:
> -------- Original Message --------
> Subject: 	[IAB] Some WG Mail Lists Archiving Incorrectly
> Date: 	Thu, 26 Feb 2009 16:11:49 -0800
> From: 	Alexa Morris <[email-masked]>
> To: 	[email-masked]
> CC: 	[email-masked]
>
>
>
> On February 3rd we upgraded the Mailman list archives in order to keep
> spammers from sending spam directly to our archives. It has since been
> brought to our attention that, as side effect of this upgrade, some
> mail lists with previously public archives had their list
> configuration reset to private archiving, which means that these
> archives have not been available for several weeks.
>
> We are currently going through the Mailman settings for each of these
> lists and resetting the archives so that they will once again be
> publicly available. We anticipate that the list archives will be
> properly repaired by early next week. The complete tally of impacted
> lists is included below.
>
> As always, please feel free to contact me with any questions or
> concerns.
>
> Impacted Mail Lists:
>
> 16ng
> adslmib
> ason-routing
> bmwg
> bofchairs
> bridge-mib
> cfrg
> crisp
> dccp
> diffserv-interest
> dns-dir
> ecrit
> enum
> gsmp
> hubmib
> ietf-message-headers
> imap
> intersecs
> ipcdn
> ipdir
> ipoverib
> ipv6-adoption
> irtf-announce
> isis-update
> kmart
> l1vpn
> l2vpn
> l3vpn
> ldap-dir
> lemonade
> malloc
> media-feature-tags
> megaco
> midcom
> mip4
> mip6
> mipshop
> mobopts
> mpls
> mpls-interop
> nemo
> new-work
> nsis
> numbers
> ops-dir
> ospf-wireless-design
> p2pi-com
> pana
> pim
> port-srv-reg
> pppext
> proxies
> pwe3
> rai-discuss
> rfced-ietf
> rip
> rir-ietf
> rmonmib
> rmt
> rohc
> rserpool
> rtg-bfd
> rtg-dir
> rtg-mibs
> rtg-rdd
> rtgwg
> saad
> sigtran
> sitescope-list
> spam-discussion
> speechsc
> ssm
> tcpao-security
> tmc
> tsv-dir
> uri-review
> urn-nid
> videomgmt
> vpim
> vpn-dir
> vrrp
> w3c-policy
> xcon
>
> Regards,
> Alexa
>
> -----------
> Alexa Morris / Executive Director / IETF
> 48377 Fremont Blvd., Suite 117, Fremont, CA  94538
> Phone: +1.510.492.4089 / Fax: +1.510.492.4001
> Email: [email-masked]
>
> Managed by Association Management Solutions (AMS)
> Forum Management, Meeting and Event Planning
> www.amsl.com <http://www.amsl.com/>
>
> IRSG mailing list
> [email-masked]
> http://mailman.isi.edu/mailman/listinfo/irsg