Hi Jim, On Tue, September 30, 2014 4:13 pm, Jim Schaad wrote: > > -----Original Message----- > From: Dan Harkins [mailto:dhark...@lounge.org] > Sent: Tuesday, September 30, 2014 4:25 PM > To: Jim Schaad > Cc: emu@ietf.org > Subject: RE: [Emu] salted EAP-pwd > > > Hi Jim, > > On Tue, September 30, 2014 2:16 pm, Jim Schaad wrote: >> 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. > > 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.
Yes, I see your point. The identity in the EAP-Identity/response has to be used to look up the database and every entry in the database has to be salted using the same digest. The particular entry is determined by the value in the EAP-pwd-ID/response. So this makes upgrading the digest somewhat more involved than the piecemeal modification of individual entries in the database. You'd have to support multiple databases and select which one based on the routable portion of the client's identity in the EAP-Identity/response. I have added words to this effect in -01 of the draft. > >> 2. It does not allow me to do both SASLprep and salting on the same >> password. > > 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? > > [JLS] It would solve the immediate problem. I don't really care for it as > a > solution though. Can't say I like it either. I made a preliminary version of the draft that instructed IANA to partition the registry and treat the lower, older, portion as a bit mask but it was ugly. This is somewhat less ugly. regards, Dan. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
