Re: [Emu] [saag] Feedback on Salted EAP draft

[Dan Harkins]

  Hi Joe,

On Sun, August 16, 2015 9:33 pm, Joseph Salowey wrote:
> Hi Dan,
>
> I read the latest version of the draft (-02) and it looks mostly good to
> me.   some comments:
>
> I think you want to change the RFC references in the abstract from RFC
> 2751
> to RFC 2759.

  Yes, good catch! I am not referring to the "Signaled Preemption
Priority Policy Element." :-)

> One question I have is there any reason why you specify the input of the
> hash function as password | salt instead of the other way around?  Is this
> the way it is done in practice?

  I actually asked whether this was how it was done in eduroam and
did not get definitive answer back. When I poked around in the results
of a "how to hash passwords" query there were a few examples that had
code and they did it that way. If you know of a counter example, please
speak up while the cement has yet to dry.

  regards,

  Dan.

> Thanks,
>
> Joe
>
> On Thu, Aug 13, 2015 at 2:35 PM, Dan Harkins  wrote:
>
>>
>>   Hi Christian,
>>
>> On Tue, July 14, 2015 10:50 am, Christian Huitema wrote:
>> [snip]
>> > The draft is short and clear enough, but it acknowledges a pretty big
>> > security issue: "the salted
>> > password from a compromised database can be used directly to
>> impersonate
>> > the client-- there
>> > is no dictionary attack needed to recover the plaintext password."
>> >
>> > That's a pretty big caveat, but there are still some advantages over
>> > operating with unsalted passwords. The draft aligns server side
>> password
>> > management for EAP-pwd  with standard industry practices, which is
>> good.
>> > In case of server compromise, the immediate effect of the compromise
>> is
>> an
>> > attack on the already compromised server, and the per-user salt make
>> > password discovery harder. The security section should be expanded to
>> > explain this tradeoff.
>>
>>   Yes, it's a big caveat and, as I mentioned, I'm trying to
>> be as blunt as possible about it. I have updated the Security
>> Considerations to include the point you are making about server
>> compromise and the per-user salt still making password recovery
>> harder.
>>
>> > Nits:
>> >
>> > - in the abstract, missing "not" in " but did (not?) include support
>> for
>> > salted passwords."
>>
>>   Nice catch.
>>
>>   An -02 version has been posted. Would you please take a look
>> and let me know whether it satisfactorily addresses your comments?
>>
>>   regards,
>>
>>   Dan.
>>
>>
>> ___
>> saag mailing list
>> s...@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag
>>
>


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] [saag] Feedback on Salted EAP draft

[Joseph Salowey]

Hi Dan,

I read the latest version of the draft (-02) and it looks mostly good to
me.   some comments:

I think you want to change the RFC references in the abstract from RFC 2751
to RFC 2759.

One question I have is there any reason why you specify the input of the
hash function as password | salt instead of the other way around?  Is this
the way it is done in practice?

Thanks,

Joe

On Thu, Aug 13, 2015 at 2:35 PM, Dan Harkins  wrote:

>
>   Hi Christian,
>
> On Tue, July 14, 2015 10:50 am, Christian Huitema wrote:
> [snip]
> > The draft is short and clear enough, but it acknowledges a pretty big
> > security issue: "the salted
> > password from a compromised database can be used directly to impersonate
> > the client-- there
> > is no dictionary attack needed to recover the plaintext password."
> >
> > That's a pretty big caveat, but there are still some advantages over
> > operating with unsalted passwords. The draft aligns server side password
> > management for EAP-pwd  with standard industry practices, which is good.
> > In case of server compromise, the immediate effect of the compromise is
> an
> > attack on the already compromised server, and the per-user salt make
> > password discovery harder. The security section should be expanded to
> > explain this tradeoff.
>
>   Yes, it's a big caveat and, as I mentioned, I'm trying to
> be as blunt as possible about it. I have updated the Security
> Considerations to include the point you are making about server
> compromise and the per-user salt still making password recovery
> harder.
>
> > Nits:
> >
> > - in the abstract, missing "not" in " but did (not?) include support for
> > salted passwords."
>
>   Nice catch.
>
>   An -02 version has been posted. Would you please take a look
> and let me know whether it satisfactorily addresses your comments?
>
>   regards,
>
>   Dan.
>
>
> ___
> saag mailing list
> s...@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] [saag] Feedback on Salted EAP draft

[Dan Harkins]

  Hi Christian,

On Tue, July 14, 2015 10:50 am, Christian Huitema wrote:
[snip]
> The draft is short and clear enough, but it acknowledges a pretty big
> security issue: "the salted
> password from a compromised database can be used directly to impersonate
> the client-- there
> is no dictionary attack needed to recover the plaintext password."
>
> That's a pretty big caveat, but there are still some advantages over
> operating with unsalted passwords. The draft aligns server side password
> management for EAP-pwd  with standard industry practices, which is good.
> In case of server compromise, the immediate effect of the compromise is an
> attack on the already compromised server, and the per-user salt make
> password discovery harder. The security section should be expanded to
> explain this tradeoff.

  Yes, it's a big caveat and, as I mentioned, I'm trying to
be as blunt as possible about it. I have updated the Security
Considerations to include the point you are making about server
compromise and the per-user salt still making password recovery
harder.

> Nits:
>
> - in the abstract, missing "not" in " but did (not?) include support for
> salted passwords."

  Nice catch.

  An -02 version has been posted. Would you please take a look
and let me know whether it satisfactorily addresses your comments?

  regards,

  Dan.


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] [saag] Feedback on Salted EAP draft

[Stefan Winter]

Hi,

> Is there interest in reviewing this draft?  Sam pointed out the
> importance of moving this work forward, it would be helpful to have
> volunteers to review the work and also to understand the level of
> interest (if any) before this goes forward as AD sponsored.

FWIW, I read and commented on the draft in its -00 state. I'm still very
interested in this document as it enables contemporary real-life
password databases to work with pwd. I'm still happy to be the doc
shepherd once the time has come to move the document forward.

Greetings,

Stefan Winter

> 
> Thank you!
> 
> On Fri, Mar 27, 2015 at 1:34 PM, Sam Hartman  > wrote:
> 
> > "Kathleen" == Kathleen Moriarty
>  > writes:
> 
> Kathleen>I meant to send the link to Dan's draft:
> Kathleen>
> https://tools.ietf.org/html/draft-harkins-salted-eap-pwd-01
> Kathleen> Long week...
> 
> I have briefly reviewed the goals behind this proposal and a sketch of
> the details but have not done a technical review of the proposal.
> 
> The underlying goal is important and valuable.
> This issue is the same issue that was behind my response to your AD
> review of the oauth dynamic registration draft.
> The more we can do to make it possible to use  deployed password
> databases with more modern security, the more we will be able to employ
> that modern security.
> 
> However, take careful note of section 5 of the draft.
> 
> Assuming that  you can get positive technical reviews of the proposal,
> this draft seems to solve an important problem that would be valuable to
> solve in the EAP community.
> 
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen
> 
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
> 


-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66


0x8A39DC66.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] [saag] Feedback on Salted EAP draft

[Sam Hartman]

> "Christian" == Christian Huitema  writes:

Christian> On Tuesday, July 14, 2015 9:01 AM, Kathleen Moriarty wrote:
>> Is there interest in reviewing this draft?  Sam pointed out the
>> importance of moving this work forward, it would be helpful to
>> have volunteers to review the work and also to understand the
>> level of interest (if any) before this goes forward as AD
>> sponsored.

Christian> The draft is short and clear enough, but it acknowledges
Christian> a pretty big security issue: "the salted password from a
Christian> compromised database can be used directly to impersonate
Christian> the client-- there is no dictionary attack needed to
Christian> recover the plaintext password."

If you want to use an pre-existing salted database and you want to use some
cryptographic mechanism rather than transporting plaintext passwords
over encrypted transport, I think you have to accept that particular
vulnerability or something similar.

To defeat this you'd need some function that the peer, knowing the full
plaintext password could compute, and the EAP server knowing the salted
database entry could verify, but an attacker could not verify.
Most of the ways I can think of of doing that would defeat other
properties that the eap-pwd designers would probably consider
important. You might be able to do something with a secondary
authentication after the primary authentication had succeeded
(vulnerable to attackers who own your database).  Of course once an attacker 
gets your database, they could impersonate
the server towards the peer and defeate this secondary authentication.
However if the plaintext password were strong enough they could not log
into the original server.

Which is to say there are probably different tradeoffs that could be
made, but the ones in this protocol are ones that reasonable folks have
considered acceptable in the past.


I'll note that password-protected Kerberos as described in RFC 4120/6112
is an example of another system with this vulnerability.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] [saag] Feedback on Salted EAP draft

[Dan Harkins]

  Hi Christian,

On Tue, July 14, 2015 10:50 am, Christian Huitema wrote:
> On Tuesday, July 14, 2015 9:01 AM, Kathleen Moriarty wrote:
>
>> Is there interest in reviewing this draft?  Sam pointed out the
>> importance of moving
>> this work forward, it would be helpful to have volunteers to review the
>> work and also
>> to understand the level of interest (if any) before this goes forward as
>> AD sponsored.
>
> The draft is short and clear enough, but it acknowledges a pretty big
> security issue: "the salted
> password from a compromised database can be used directly to impersonate
> the client-- there
> is no dictionary attack needed to recover the plaintext password."
>
> That's a pretty big caveat, but there are still some advantages over
> operating with unsalted passwords. The draft aligns server side password
> management for EAP-pwd  with standard industry practices, which is good.
> In case of server compromise, the immediate effect of the compromise is an
> attack on the already compromised server, and the per-user salt make
> password discovery harder. The security section should be expanded to
> explain this tradeoff.

  Yea, that is a big caveat. There are existing databases of salted
passwords that cannot be used with RFC 5931 so the motivation for
this draft is to support those currently deployed databases. The
Security Considerations are intended to be as blunt as possible.

> Nits:
>
> - in the abstract, missing "not" in " but did (not?) include support for
> salted passwords."

  Thanks for finding this; I'll fix it in an update.

  regards,

  Dan.

> -- Christian Huitema
>
>
> ___
> saag mailing list
> s...@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] [saag] Feedback on Salted EAP draft

[Kathleen Moriarty]

Hello,

Is there interest in reviewing this draft?  Sam pointed out the importance
of moving this work forward, it would be helpful to have volunteers to
review the work and also to understand the level of interest (if any)
before this goes forward as AD sponsored.

Thank you!

On Fri, Mar 27, 2015 at 1:34 PM, Sam Hartman  wrote:

> > "Kathleen" == Kathleen Moriarty 
> writes:
>
> Kathleen>I meant to send the link to Dan's draft:
> Kathleen> https://tools.ietf.org/html/draft-harkins-salted-eap-pwd-01
> Kathleen> Long week...
>
> I have briefly reviewed the goals behind this proposal and a sketch of
> the details but have not done a technical review of the proposal.
>
> The underlying goal is important and valuable.
> This issue is the same issue that was behind my response to your AD
> review of the oauth dynamic registration draft.
> The more we can do to make it possible to use  deployed password
> databases with more modern security, the more we will be able to employ
> that modern security.
>
> However, take careful note of section 5 of the draft.
>
> Assuming that  you can get positive technical reviews of the proposal,
> this draft seems to solve an important problem that would be valuable to
> solve in the EAP community.
>



-- 

Best regards,
Kathleen
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] [saag] Feedback on Salted EAP draft

[Sam Hartman]

> "Kathleen" == Kathleen Moriarty  writes:

Kathleen>I meant to send the link to Dan's draft:
Kathleen> https://tools.ietf.org/html/draft-harkins-salted-eap-pwd-01
Kathleen> Long week...

I have briefly reviewed the goals behind this proposal and a sketch of
the details but have not done a technical review of the proposal.

The underlying goal is important and valuable.
This issue is the same issue that was behind my response to your AD
review of the oauth dynamic registration draft.
The more we can do to make it possible to use  deployed password
databases with more modern security, the more we will be able to employ
that modern security.

However, take careful note of section 5 of the draft.

Assuming that  you can get positive technical reviews of the proposal,
this draft seems to solve an important problem that would be valuable to
solve in the EAP community.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu