Subject: [Emu] salted EAP-pwd

From: "Dan Harkins" <[email-masked]>
Date: Tue, 30 Sep 2014 12:02:15 -0700 (PDT)

Hello EMU,

  I've had requests to add support for salted password databases
to EAP-pwd. A newly posted draft does just that:

   http://tools.ietf.org/html/draft-harkins-salted-eap-pwd-00

  Please take a look and comment.

  regards,

  Dan.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 30 Sep 2014 14:16:29 -0700

I can see two problems right off the bat.

1.  It does not allow me to use a different salted method for different
people so I can upgrade by salt function piecemeal.

2.  It does not allow me to do both SASLprep and salting on the same
password.

Jim

-----Original Message-----
From: Emu [mailto:[email-masked]] On Behalf Of Dan Harkins
Sent: Tuesday, September 30, 2014 12:02 PM
To: [email-masked]
Subject: [Emu] salted EAP-pwd

  Hello EMU,

  I've had requests to add support for salted password databases to EAP-pwd.
A newly posted draft does just that:

  regards,

  Dan.

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

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 30 Sep 2014 16:24:44 -0700 (PDT)

Hi Jim,

> people so I can upgrade by salt function piecemeal.

  Sure it does. The EAP-Identity/Response from the client will indicate
the identity, the server looks up that identity in the password database,
sees how it's salted and responds appropriately. One entry in the database
could be SHA-1 and another could be SHA-256.

> 2.  It does not allow me to do both SASLprep and salting on the same

  Yes, I see that might be needed if SASLprep was done on the password
before it was salted and stored. Given that SASLprep is already a password
pre-processing technique (and it is the value 0x02 while "none" is 0x00
preventing the distinction being a low-order bit) I see no choice but to
double all the proposed salting indicators, one for SASLprep before the
hashing and one for do nothing to the password before hashing.

  Would that be satisfactory to you?

  regards,

  Dan.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 30 Sep 2014 17:13:57 -0700

-----Original Message-----
From: Dan Harkins [mailto:[email-masked]] 
Sent: Tuesday, September 30, 2014 4:25 PM
To: Jim Schaad
Cc: [email-masked]
Subject: RE: [Emu] salted EAP-pwd

  Hi Jim,

On Tue, September 30, 2014 2:16 pm, Jim Schaad wrote:
> 1.  It does not allow me to use a different salted method for 
> different people so I can upgrade by salt function piecemeal.

  Sure it does. The EAP-Identity/Response from the client will indicate the
identity, the server looks up that identity in the password database, sees
how it's salted and responds appropriately. One entry in the database could
be SHA-1 and another could be SHA-256.

[JLS] Ok - so if I understand this correctly.  
Server sends a message saying <EAP-PW, name="server", preprocess="SHA-256",
Cipher="foo"> to the client
Client returns a message saying <EAP-PW, name="dan", preprocess="SHA-256",
cipher="foo"> to the server.

Server looks up dan and says - ouch - that should have been SHA-1 because
that password is not upgraded yet. --- 

I based this comment on the first paragraph of section 2.4 which says:

   Like all EAP methods, EAP-pwd is server initiated.  The server is
   required to indicate its intentions, including the password pre-
   processing it wishes to use, before it knows the identity of the
   client.

Thus if the pre-processing is client identity based it would not know this.

You might be able to get around this if the client identity in the
EAP-Identity message is what is used for the lookup in the database and not
the string sent in the EAP-pwd-ID/response.

[JLS] It would solve the immediate problem.  I don't really care for it as a
solution though.

  regards,

  Dan.