Re: [IPsec] replacing PSKs: CFRG and PAKE
Yoav Nir wrote: > I don’t think the idea is to replace a 128-bit PSK derived from a properly > seeded DRBG with “ip5ecmeRockz!” using a PAKE. Please! The official PSK is "makemetastegoat" -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] replacing PSKs: CFRG and PAKE
Hi, Valery > On 12 Dec 2018, at 11:02, Valery Smyslov wrote: > >>> I see this as a social issue, not a technical one. We can't prevent >>> administrators from being careless, either with PSKs or with passwords. >> >> We can make more secure deployments easier. >> >> If the only change on the site-to-site config is to change the keyword >> "psk" to "pake" and that prevents offline dictionary attacks, that's an >> easy win. > > I'm not so sure. Replacing PSK with password+PAKE could in fact decrease > security. > Properly chosen PSK provides high level of protection against both passive > and active attacks. On the other hand, PAKE, as far as I know, > only makes it difficult for passive eavesdropper to perform offline > dictionary attack. But an active attacker may still try out all possible > password values (due to small search space). Yes, you can easier > detect active attackers and block them (and site-to-site VPNs > usually have fixed IPs, that simplifies the task), but I still feel a bit > uncomfortable > by the idea of replacing perfectly secure crypto mechanism with a weaker one. > I'd rather educate administrators :-) And note, that no PAKE will > save you if administrators will select passwords like "foobar" or "12345". > > I think that PAKE is a very good mechanism for remote access > in situation when certificates (or raw public keys) cannot be used > for various reasons. E.g. f simple CPE that has no memory > to securely store private key. I don’t think the idea is to replace a 128-bit PSK derived from a properly seeded DRBG with “ip5ecmeRockz!” using a PAKE. I think we’re assuming the administrator will configure “ip5ecmeRockz!” (or “foobar”) regardless of what we call it, so we might as well give them a better mechanism to use this value. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] replacing PSKs: CFRG and PAKE
> > I see this as a social issue, not a technical one. We can't prevent > > administrators from being careless, either with PSKs or with passwords. > > We can make more secure deployments easier. > > If the only change on the site-to-site config is to change the keyword > "psk" to "pake" and that prevents offline dictionary attacks, that's an > easy win. I'm not so sure. Replacing PSK with password+PAKE could in fact decrease security. Properly chosen PSK provides high level of protection against both passive and active attacks. On the other hand, PAKE, as far as I know, only makes it difficult for passive eavesdropper to perform offline dictionary attack. But an active attacker may still try out all possible password values (due to small search space). Yes, you can easier detect active attackers and block them (and site-to-site VPNs usually have fixed IPs, that simplifies the task), but I still feel a bit uncomfortable by the idea of replacing perfectly secure crypto mechanism with a weaker one. I'd rather educate administrators :-) And note, that no PAKE will save you if administrators will select passwords like "foobar" or "12345". I think that PAKE is a very good mechanism for remote access in situation when certificates (or raw public keys) cannot be used for various reasons. E.g. f simple CPE that has no memory to securely store private key. Regards, Valery. > I care a little less for group psk's because well, it is a group so even > a pake won't buy us that much extra if dozens or thousands of people > have the pake secret. > > Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] replacing PSKs: CFRG and PAKE
On Tue, 11 Dec 2018, Valery Smyslov wrote: What I heard from the IPsecME record was that many in the room felt that this was where ther was a weakness. I see this as a social issue, not a technical one. We can't prevent administrators from being careless, either with PSKs or with passwords. We can make more secure deployments easier. If the only change on the site-to-site config is to change the keyword "psk" to "pake" and that prevents offline dictionary attacks, that's an easy win. I care a little less for group psk's because well, it is a group so even a pake won't buy us that much extra if dozens or thousands of people have the pake secret. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] replacing PSKs: CFRG and PAKE
On Tue, 11 Dec 2018, Nico Williams wrote:
- you're not entirely sure that you don't have weak PSKs and would like
to strengthen them
I think that this is the major reason.
OK, but you can always convert the real weak PSKs to either PK-{I,raw}
or EAP depending on whether the "client" is a user or not and/or its
capabilities.
I hate the idea of turning weak PSKs, possibly already logged by nation
states, and turn these into PAKEs. I would really hope people do NOT do
that or part of the point of obsoleting PSK's for PAKEs is lost.
I'e, this reason doesn't seem pressing, unless what's pressing is that
somehow a non-EAP PAKE would be much less work for some implementors or
operators (or users) than EAP (w/ EAP-PWD or equivalent).
Yes. Please no EAP where possible.
The moment someone says "and let's add OTP" I think EAP is definitely
the better answer if it already ticks all the capability boxes.
That I can agree too. In general, the OTP use case is a really a
deployment with a human driver in the seat, and not site-to-site or
mesh-node encryption. It's almost always remote access vpn within the
same organisation.
(I wouldn't object, but if EAP fits the bill as to PAKE already, then
thw WG could object to spending its resources on adding PAKE to
IKEv2.)
As explained before. site to site has no way of doing EAP in practise.
I tend to agree. The only case where that's not true is when you have a
site that doesn't already have RADIUS/DIAMETER/WHATEVER AAA
infrastructure and would rather not deploy one. Not sure the WG should
cater to such users.
That is a common case, imagine your 4 home users connecting back to your
simple home vpn gateway.
A site-to-site PAKE is more useful if it isolated from any AAA
infrastructure.
Sure, but does this WG want to cater to that?
Yes we do! One of the goals was to get PSK phased out. So to me this is
the primary use case.
I think a reasonable compromise would be to add a PAKE (both options,
balanced and augmented) but no second factor support.
I have been convinced this is likely the right way forward.
Paul
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] replacing PSKs: CFRG and PAKE
On Tue, Dec 11, 2018 at 07:21:26AM -0500, Michael Richardson wrote:
> Nico Williams wrote:
> > On Mon, Dec 10, 2018 at 09:20:54PM -0500, Michael Richardson wrote:
> > > Paul Wouters wrote:
> > > > > yes, typo, "not for road-warrior"
> > > >
> > > > I understood. I disagree with the “not”. Road warriors using
> > > > group psk is a thing, sadly.
> > >
> > > But they aren't cross-domain, they can do EAP-foobar, and they
> > > could use a certificate without a lot of hassle about what set of
> > > trust anchors.
> > >
> > > If we stick to the site-to-site then I think we can do something
> > > rather simple and quick, and our security considerations section
> > > will be much simpler.
> >
> > I mean, if road warriors should always be using either EAP or user
> > certs, then we don't need PAKE for anything because presumably the
> > shared keys used in PSKs are strong enough that PAKEs don't improve
> > security and only slow things down...
>
> It's the enterprise-to-enterprise connection that is hard to convert
> to certificates for the reasons that Paul explained.
Is it not better to think of it as federation? Is it not federation?
> > (I'm assuming you mean to use an EAP method like EAP-PWD (RFCs 5931 and
> > 8146), yes?)
> >
> > Assuming you can always use EAP, the only real reasons to use a PAKE in
> > IKEv2 are:
> >
> > - you're not entirely sure that you don't have weak PSKs and would like
> >to strengthen them
>
> I think that this is the major reason.
OK, but you can always convert the real weak PSKs to either PK-{I,raw}
or EAP depending on whether the "client" is a user or not and/or its
capabilities.
I'e, this reason doesn't seem pressing, unless what's pressing is that
somehow a non-EAP PAKE would be much less work for some implementors or
operators (or users) than EAP (w/ EAP-PWD or equivalent).
The moment someone says "and let's add OTP" I think EAP is definitely
the better answer if it already ticks all the capability boxes.
> > - you don't always want EAP for users who don't have certs for reasons
> >that escape me
> >
> >(I wouldn't object, but if EAP fits the bill as to PAKE already, then
> >thw WG could object to spending its resources on adding PAKE to
> >IKEv2.)
>
> I think that a user-oriented PAKE is more useful if it can be
> backended into a AAA infrastructure, which EAP can.
I tend to agree. The only case where that's not true is when you have a
site that doesn't already have RADIUS/DIAMETER/WHATEVER AAA
infrastructure and would rather not deploy one. Not sure the WG should
cater to such users.
> A site-to-site PAKE is more useful if it isolated from any AAA
> infrastructure.
Sure, but does this WG want to cater to that?
I think a reasonable compromise would be to add a PAKE (both options,
balanced and augmented) but no second factor support.
Nico
--
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] replacing PSKs: CFRG and PAKE
> > I think that using PAKE for road warriors is more important than for > > site-to-site VPNs. In the latter case the SGWs are usually administered > > by (presumably :-)) experienced administrators, who can select a > > high-entropy > > PSK, and these PSKs need not to be memorable by users. So, generally > > speaking, > > it is more secure to use good PSK than passwords (since any PAKE defends > > only > > If we assume highly competent administrators, then we don't need a PAKE > at all. For remote access where certificates or raw public key cannot be used, PAKE is extremely useful. > What I heard from the IPsecME record was that many in the room > felt that this was where ther was a weakness. I see this as a social issue, not a technical one. We can't prevent administrators from being careless, either with PSKs or with passwords. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] replacing PSKs: CFRG and PAKE
Valery Smyslov wrote: > I think that using PAKE for road warriors is more important than for > site-to-site VPNs. In the latter case the SGWs are usually administered > by (presumably :-)) experienced administrators, who can select a high-entropy > PSK, and these PSKs need not to be memorable by users. So, generally > speaking, > it is more secure to use good PSK than passwords (since any PAKE defends > only If we assume highly competent administrators, then we don't need a PAKE at all. What I heard from the IPsecME record was that many in the room felt that this was where ther was a weakness. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] replacing PSKs: CFRG and PAKE
Nico Williams wrote: > On Mon, Dec 10, 2018 at 09:20:54PM -0500, Michael Richardson wrote: > > Paul Wouters wrote: > > > > yes, typo, "not for road-warrior" > > > > > > I understood. I disagree with the “not”. Road warriors using group psk is > > > a > > > thing, sadly. > > > > But they aren't cross-domain, they can do EAP-foobar, and they could use a > > certificate without a lot of hassle about what set of trust anchors. > > > > If we stick to the site-to-site then I think we can do something rather > > simple and quick, and our security considerations section will be much > > simpler. > > I mean, if road warriors should always be using either EAP or user > certs, then we don't need PAKE for anything because presumably the > shared keys used in PSKs are strong enough that PAKEs don't improve > security and only slow things down... It's the enterprise-to-enterprise connection that is hard to convert to certificates for the reasons that Paul explained. > (I'm assuming you mean to use an EAP method like EAP-PWD (RFCs 5931 and > 8146), yes?) > > Assuming you can always use EAP, the only real reasons to use a PAKE in > IKEv2 are: > > - you're not entirely sure that you don't have weak PSKs and would like >to strengthen them I think that this is the major reason. > > - you don't always want EAP for users who don't have certs for reasons >that escape me > >(I wouldn't object, but if EAP fits the bill as to PAKE already, then >thw WG could object to spending its resources on adding PAKE to >IKEv2.) I think that a user-oriented PAKE is more useful if it can be backended into a AAA infrastructure, which EAP can. A site-to-site PAKE is more useful if it isolated from any AAA infrastructure. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] replacing PSKs: CFRG and PAKE
Hi Paul, I think that using PAKE for road warriors is more important than for site-to-site VPNs. In the latter case the SGWs are usually administered by (presumably :-)) experienced administrators, who can select a high-entropy PSK, and these PSKs need not to be memorable by users. So, generally speaking, it is more secure to use good PSK than passwords (since any PAKE defends only against passive attacks, an attacker can still perform active probes and the search space is limited for passwords). So I think that augmented PAKE is more important than balanced. It can be used e.g. in those cases when it is impossible to securely store certificate's private key on a user devices. I'm not against selecting balanced PAKE too, but I think it's less important. And I agree that it's better to avoid using EAP for PAKE. But why do you want to deprecate RFC 6467? It is just a framework that must be suitable for any PAKE. Regards, Valery. > >> That is still missing OTP support :( > > > > If you have the private keys locked unextractably in a hardware token > > that requires a PIN to unlock, then you have two factors right there. > > That's not generic two-factor authentication though, and it certainly > > isn't OTP. > > Right. So I guess what I'd like PSK-replacement-PAKE to support is using > OTP, without EAP. But I guess that's not really possible if I understand > things correctly. > > With XAUTH, we had a way to transfer a password in an encrypted payload, > and the password could be in the syntax of ":" > > If we are going to basically obsolete/deprecate RFC 6628 and 6467, it > would be nice if we did it in such a way that we can still have OTP > support. > > >> I'd want the PAKE method to support OTP. > > > > It's doable. > > Great :) > > >> Explaining these differences on this list would be useful for me and > >> possibly others. > > Thanks for these. > > > A PAKE is a zero-knowledge password proof protocol (ZKPP) that also > > provides authenticated key exchange with forward security. A ZKPP is a > > password-based authentication protocol where neither eavesdroppers nor > > active attackers get to mount off-line dictionary attacks on captured > > protocol material. > > > > I had never seen the word "balanced" used to refer to "not augmented", > > but I like it. > > > > A "balanced" PAKE is one where both sides share a secret or secret- > > equivalent. > > > > An "augmented" PAKE is a PAKE where the credentials are asymmetric so > > that relying parties (servers, acceptors, responders, whatever you call > > them) store "verifiers" rather than password-equivalent secrets. > > > > A verifier is much like a hash of a password: not password-equivalent, > > but susceptible to off-line dictionary attack. > > > > Compromise of shared secrets (via server compromise) is catastrophic for > > a balanced PAKE since until you're able to change all the secrets the > > attacker can impersonate all the users to the server. > > > > Compromise of verifiers (via server compromise) is much less disastrous > > for an augmented PAKE because you have some time in which to change all > > the weak secrets: the time it would take the attacker to recover > > passwords via off-line dictionary attack. The verifiers would all be > > salted, naturally, so if your secrets are reasonably strong then that > > might be a lot of time to change all those passwords. > > > > A balanced PAKE is symmetric as to initiator/responder roles. An > > augmented PAKE is not quite. > > In that case, the gain of augmented PAKE seems small. If the server is > compromised, they can just pretend the AUTH payload is OK if they _want_ > you to connect to them and get all your traffic. And the client needs to > know the password, and not just the verifier. > > For the case where a VPN gateway should not have the password > credentials itself, it would (should?) be using some kind of EAP > mechanism anyway? So we don't need an augmented PAKE for that? > > > > The asymmetry in roles in augmented PAKEs means that in order to > > function as an IKE responder (and thus maintain IKE initiator/responder > > role symmetry), the IKE PAKE extension would have to permit one side to > > request that the other initiate the augmented PAKE exchange. > > that feels the wrong method for a site-to-site VPN connecting two > enterprises. One would have a better security after compromise than > the other side? > > So it seems to me one balanced PAKE would be enough, but I'll go reread > some older messages again. > > Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] replacing PSKs: CFRG and PAKE
On Mon, Dec 10, 2018 at 09:20:54PM -0500, Michael Richardson wrote: > Paul Wouters wrote: > > > yes, typo, "not for road-warrior" > > > > I understood. I disagree with the “not”. Road warriors using group psk is a > > thing, sadly. > > But they aren't cross-domain, they can do EAP-foobar, and they could use a > certificate without a lot of hassle about what set of trust anchors. > > If we stick to the site-to-site then I think we can do something rather > simple and quick, and our security considerations section will be much > simpler. I mean, if road warriors should always be using either EAP or user certs, then we don't need PAKE for anything because presumably the shared keys used in PSKs are strong enough that PAKEs don't improve security and only slow things down... (I'm assuming you mean to use an EAP method like EAP-PWD (RFCs 5931 and 8146), yes?) Assuming you can always use EAP, the only real reasons to use a PAKE in IKEv2 are: - you're not entirely sure that you don't have weak PSKs and would like to strengthen them - you don't always want EAP for users who don't have certs for reasons that escape me (I wouldn't object, but if EAP fits the bill as to PAKE already, then thw WG could object to spending its resources on adding PAKE to IKEv2.) Right? Nico -- ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] replacing PSKs: CFRG and PAKE
On Mon, Dec 10, 2018 at 08:58:15PM -0500, Paul Wouters wrote: > On Mon, 10 Dec 2018, Nico Williams wrote: > >>That is still missing OTP support :( > > > >If you have the private keys locked unextractably in a hardware token > >that requires a PIN to unlock, then you have two factors right there. > >That's not generic two-factor authentication though, and it certainly > >isn't OTP. > > Right. So I guess what I'd like PSK-replacement-PAKE to support is using > OTP, without EAP. But I guess that's not really possible if I understand > things correctly. No you very much can get PAKE + OTP. We'll get into the details of what is difficult later. > If we are going to basically obsolete/deprecate RFC 6628 and 6467, it > would be nice if we did it in such a way that we can still have OTP > support. Sure. > >A balanced PAKE is symmetric as to initiator/responder roles. An > >augmented PAKE is not quite. > > In that case, the gain of augmented PAKE seems small. If the server is No, the gain of an augmented PAKE is very large. > compromised, they can just pretend the AUTH payload is OK if they _want_ They can do that in both cases, but in the balanced PAKE case the attacker who has the shared secret can not only impersonate the server to the user, but vice-versa, and they can MITM the two. In the augmented case the attacker who has the verifier can impersonate the server to the user, but NOT the user to the server (not without first successfully mounting a dictionary attack on the verifier). > you to connect to them and get all your traffic. And the client needs to > know the password, and not just the verifier. The client is always expected to know the password. The verifier can always be computed from the password (and salt). > For the case where a VPN gateway should not have the password > credentials itself, it would (should?) be using some kind of EAP > mechanism anyway? So we don't need an augmented PAKE for that? EAP has its use: federation. Augmented PAKE is better than augmented in all cases when dealing with a username and password as a credential. Balanced PAKE is only useful (IMO) as a transition tool so that you can start using the PSK secrets you already have as PAKE secrets then change passwords to switch to secret/verifier augmented PAKE from that point forward. > >The asymmetry in roles in augmented PAKEs means that in order to > >function as an IKE responder (and thus maintain IKE initiator/responder > >role symmetry), the IKE PAKE extension would have to permit one side to > >request that the other initiate the augmented PAKE exchange. > > that feels the wrong method for a site-to-site VPN connecting two > enterprises. One would have a better security after compromise than > the other side? It just means that when the SG/whatever wants to initiate an IKE exchange with the user it needs an extra message: "Hey yo, start augmented PAKE with me", followed by the rest of an IKE exchange as if the now-resonder client had initiated. > So it seems to me one balanced PAKE would be enough, but I'll go reread > some older messages again. Please opt for both. Balanced so you can start using existing PSKs, augmented so you can better secure the password database on the server side. Nico -- ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] replacing PSKs: CFRG and PAKE
Paul Wouters wrote: > > On Dec 10, 2018, at 19:51, Michael Richardson wrote: > > > > > > Paul Wouters wrote: > >>> Because I share Paul's view that the PSKs we care about are generally > >>> identical in both directions > >> > >> I agree here. > >> > >>> , and this use is primarily about site-to-site > >>> inter-company VPNs. This is note for road-warrier accesss. > >> > >> But not here. weak group PSK's for roadwarriors is a thing :( > > > > yes, typo, "not for road-warrior" > > I understood. I disagree with the “not”. Road warriors using group psk is a > thing, sadly. But they aren't cross-domain, they can do EAP-foobar, and they could use a certificate without a lot of hassle about what set of trust anchors. If we stick to the site-to-site then I think we can do something rather simple and quick, and our security considerations section will be much simpler. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] replacing PSKs: CFRG and PAKE
On Mon, 10 Dec 2018, Nico Williams wrote: That is still missing OTP support :( If you have the private keys locked unextractably in a hardware token that requires a PIN to unlock, then you have two factors right there. That's not generic two-factor authentication though, and it certainly isn't OTP. Right. So I guess what I'd like PSK-replacement-PAKE to support is using OTP, without EAP. But I guess that's not really possible if I understand things correctly. With XAUTH, we had a way to transfer a password in an encrypted payload, and the password could be in the syntax of ":" If we are going to basically obsolete/deprecate RFC 6628 and 6467, it would be nice if we did it in such a way that we can still have OTP support. I'd want the PAKE method to support OTP. It's doable. Great :) Explaining these differences on this list would be useful for me and possibly others. Thanks for these. A PAKE is a zero-knowledge password proof protocol (ZKPP) that also provides authenticated key exchange with forward security. A ZKPP is a password-based authentication protocol where neither eavesdroppers nor active attackers get to mount off-line dictionary attacks on captured protocol material. I had never seen the word "balanced" used to refer to "not augmented", but I like it. A "balanced" PAKE is one where both sides share a secret or secret- equivalent. An "augmented" PAKE is a PAKE where the credentials are asymmetric so that relying parties (servers, acceptors, responders, whatever you call them) store "verifiers" rather than password-equivalent secrets. A verifier is much like a hash of a password: not password-equivalent, but susceptible to off-line dictionary attack. Compromise of shared secrets (via server compromise) is catastrophic for a balanced PAKE since until you're able to change all the secrets the attacker can impersonate all the users to the server. Compromise of verifiers (via server compromise) is much less disastrous for an augmented PAKE because you have some time in which to change all the weak secrets: the time it would take the attacker to recover passwords via off-line dictionary attack. The verifiers would all be salted, naturally, so if your secrets are reasonably strong then that might be a lot of time to change all those passwords. A balanced PAKE is symmetric as to initiator/responder roles. An augmented PAKE is not quite. In that case, the gain of augmented PAKE seems small. If the server is compromised, they can just pretend the AUTH payload is OK if they _want_ you to connect to them and get all your traffic. And the client needs to know the password, and not just the verifier. For the case where a VPN gateway should not have the password credentials itself, it would (should?) be using some kind of EAP mechanism anyway? So we don't need an augmented PAKE for that? The asymmetry in roles in augmented PAKEs means that in order to function as an IKE responder (and thus maintain IKE initiator/responder role symmetry), the IKE PAKE extension would have to permit one side to request that the other initiate the augmented PAKE exchange. that feels the wrong method for a site-to-site VPN connecting two enterprises. One would have a better security after compromise than the other side? So it seems to me one balanced PAKE would be enough, but I'll go reread some older messages again. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] replacing PSKs: CFRG and PAKE
> On Dec 10, 2018, at 19:51, Michael Richardson wrote: > > > Paul Wouters wrote: >>> Because I share Paul's view that the PSKs we care about are generally >>> identical in both directions >> >> I agree here. >> >>> , and this use is primarily about site-to-site >>> inter-company VPNs. This is note for road-warrier accesss. >> >> But not here. weak group PSK's for roadwarriors is a thing :( > > yes, typo, "not for road-warrior" I understood. I disagree with the “not”. Road warriors using group psk is a thing, sadly. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] replacing PSKs: CFRG and PAKE
Paul Wouters wrote: > > Because I share Paul's view that the PSKs we care about are generally > > identical in both directions > > I agree here. > > > , and this use is primarily about site-to-site > > inter-company VPNs. This is note for road-warrier accesss. > > But not here. weak group PSK's for roadwarriors is a thing :( yes, typo, "not for road-warrior" > > I would prefer that the PAKE method was not wrapped in EAP. > > Indeed. As I explained at the last IETF's presentation, it CANNOT use EAP > because then site-to-site admins cannot use it to connect two different > enterprises because none wants to reconfigure their equipment to trust > the other party's authentication infrastructure. > > EAP is not suitable to interconnect different enterprises. +1. signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] replacing PSKs: CFRG and PAKE
On Mon, Dec 10, 2018 at 06:47:25PM -0500, Paul Wouters wrote: > On Mon, 10 Dec 2018, Nico Williams wrote: > > >There's no reason to not also add support for an augmented PAKE for road > >warriors. It's true that road warriors are already well-supported via > >PKIX user certificates > > That is still missing OTP support :( If you have the private keys locked unextractably in a hardware token that requires a PIN to unlock, then you have two factors right there. That's not generic two-factor authentication though, and it certainly isn't OTP. > >, so perhaps there's no need, but it's very little > >extra work to support both, augmented and non-augmented. > > I'd want the PAKE method to support OTP. It's doable. > >(Should I be saying "balanced" instead of "non-augmented"?) > > Explaining these differences on this list would be useful for me and > possibly others. A PAKE is a zero-knowledge password proof protocol (ZKPP) that also provides authenticated key exchange with forward security. A ZKPP is a password-based authentication protocol where neither eavesdroppers nor active attackers get to mount off-line dictionary attacks on captured protocol material. I had never seen the word "balanced" used to refer to "not augmented", but I like it. A "balanced" PAKE is one where both sides share a secret or secret- equivalent. An "augmented" PAKE is a PAKE where the credentials are asymmetric so that relying parties (servers, acceptors, responders, whatever you call them) store "verifiers" rather than password-equivalent secrets. A verifier is much like a hash of a password: not password-equivalent, but susceptible to off-line dictionary attack. Compromise of shared secrets (via server compromise) is catastrophic for a balanced PAKE since until you're able to change all the secrets the attacker can impersonate all the users to the server. Compromise of verifiers (via server compromise) is much less disastrous for an augmented PAKE because you have some time in which to change all the weak secrets: the time it would take the attacker to recover passwords via off-line dictionary attack. The verifiers would all be salted, naturally, so if your secrets are reasonably strong then that might be a lot of time to change all those passwords. A balanced PAKE is symmetric as to initiator/responder roles. An augmented PAKE is not quite. The asymmetry in roles in augmented PAKEs means that in order to function as an IKE responder (and thus maintain IKE initiator/responder role symmetry), the IKE PAKE extension would have to permit one side to request that the other initiate the augmented PAKE exchange. Nico -- ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] replacing PSKs: CFRG and PAKE
On Mon, 10 Dec 2018, Nico Williams wrote: There's no reason to not also add support for an augmented PAKE for road warriors. It's true that road warriors are already well-supported via PKIX user certificates That is still missing OTP support :( , so perhaps there's no need, but it's very little extra work to support both, augmented and non-augmented. I'd want the PAKE method to support OTP. (Should I be saying "balanced" instead of "non-augmented"?) Explaining these differences on this list would be useful for me and possibly others. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] replacing PSKs: CFRG and PAKE
On Mon, 10 Dec 2018, Michael Richardson wrote: Why do you think balanced PAKE is more appropriate for us than augmented? Because I share Paul's view that the PSKs we care about are generally identical in both directions I agree here. , and this use is primarily about site-to-site inter-company VPNs. This is note for road-warrier accesss. But not here. weak group PSK's for roadwarriors is a thing :( I would prefer that the PAKE method was not wrapped in EAP. Indeed. As I explained at the last IETF's presentation, it CANNOT use EAP because then site-to-site admins cannot use it to connect two different enterprises because none wants to reconfigure their equipment to trust the other party's authentication infrastructure. EAP is not suitable to interconnect different enterprises. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] replacing PSKs: CFRG and PAKE
On Mon, Dec 10, 2018 at 06:00:18PM -0500, Michael Richardson wrote: > Valery Smyslov wrote: > > Why do you think balanced PAKE is more appropriate for us than augmented? > > Because I share Paul's view that the PSKs we care about are generally > identical in both directions, and this use is primarily about site-to-site > inter-company VPNs. This is note for road-warrier accesss. There's no reason to not also add support for an augmented PAKE for road warriors. It's true that road warriors are already well-supported via PKIX user certificates, so perhaps there's no need, but it's very little extra work to support both, augmented and non-augmented. (Should I be saying "balanced" instead of "non-augmented"?) > I would prefer that the PAKE method was not wrapped in EAP. +1 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] replacing PSKs: CFRG and PAKE
On Mon, Dec 10, 2018 at 11:22:46AM +0300, Valery Smyslov wrote: > > I think we should ask the CFRG to pick a single balanced PAKE for us. > > Why do you think balanced PAKE is more appropriate for us than augmented? Speaking for myself rather than Michael, I think augmented is more appropriate when the key is based on a memorable password. However, but transition reasons, it's desirable to support a non-augmented PAKE with _existing_ password-derived keys. Also, even for non-password-derived symmetric keys, a PAKE automatically adds forward security, so it seems like a nice simplification to use a non-balanced PAKE in all cases where the credentials are shared secret keys. So in fact we probably want both. > > If the CFRG want to pick another PAKE for other purposes, that's fine. > > I think that letting CFRG pick two PAKEs for different purposes might > > free up the log jam? > > They've just announced in Bangkok a desire to start the process of selecting > "zero or more" recommended PAKE(s) for IETF community. > I believe IPsec is included :-) Oh? I thought the CFRG SPAKE2 I-D was further along. I'll have to ask the I-D authors and RG chairs. In any case, KITTEN WG is moving along with a Kerberos extension to use the CFRG SPAKE2 protocol -- this is past WGLC and awaiting shepherding to the IESG now. If CFRG ultimately picks a different PAKE, or no PAKE, that could be a problem for the KITTEN work. > Another problem with PAKE is that it must be integrated into IKE > somehow. EAP definitely can be used for this, but it's a bit Do you mean enrolment and password change protocols? Enrolment could be left unspecified, but a password change protocol is required. > expensive from protocol point of view. We also have RFC 6467, but Oh, no, you meant a document like RFC 6467. Yes, such a document would be necessary -- I don't think Michael meant to imply otherwise. > it's Informational and I'm not sure it's widely supported. And while > the RFC 6467 framework is flexible enough, it is still not clear for > me if it can accommodate PAKEs like OPAQUE... It might be possible to build a single IKE extension that can handle any number of PAKEs, since they will generally involve a small number of round trips of exchanges of PAKE-specific octet strings, followed by a generic key confirmation exchange that involves binding in the PAKE's transcripts and at least the IKE ID payloads. There's also the opportunity to add support for second factors (e.g., OTPs). The KITTEN SPAKE work does that, though it's got some issues, so this WG might not want to copy that approach. Note that there are all these things to negotiate: - PAKE - including whether to use a symmetric or augmented variant - curve/group - second factor The KITTEN WG SPAKE work did not include PAKE negotiation nor augmented vs. not-augmented negotiation :( Nico -- ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] replacing PSKs: CFRG and PAKE
Valery Smyslov wrote: > > I'm watching the video (in five minute intervals for unexplained > > reasons... it seems like I've been watching this video for days). > > > > I want to +1 Dan: we need a balanced PAKE. > > > > I sincerely wish Tero was right: that there was no excuse not to use digital > > signatures for good site-to-site, even between companies. The reason we > > don't have this is because digital signatures keep getting confused with > > PKIs, something John Gilmore realized 20 years ago. > > > > I think we should ask the CFRG to pick a single balanced PAKE for us. > > Why do you think balanced PAKE is more appropriate for us than augmented? Because I share Paul's view that the PSKs we care about are generally identical in both directions, and this use is primarily about site-to-site inter-company VPNs. This is note for road-warrier accesss. I would prefer that the PAKE method was not wrapped in EAP. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] replacing PSKs: CFRG and PAKE
Hi Michael, > I'm watching the video (in five minute intervals for unexplained > reasons... it seems like I've been watching this video for days). > > I want to +1 Dan: we need a balanced PAKE. > > I sincerely wish Tero was right: that there was no excuse not to use digital > signatures for good site-to-site, even between companies. The reason we > don't have this is because digital signatures keep getting confused with > PKIs, something John Gilmore realized 20 years ago. > > I think we should ask the CFRG to pick a single balanced PAKE for us. Why do you think balanced PAKE is more appropriate for us than augmented? > If the CFRG want to pick another PAKE for other purposes, that's fine. > I think that letting CFRG pick two PAKEs for different purposes might > free up the log jam? They've just announced in Bangkok a desire to start the process of selecting "zero or more" recommended PAKE(s) for IETF community. I believe IPsec is included :-) Another problem with PAKE is that it must be integrated into IKE somehow. EAP definitely can be used for this, but it's a bit expensive from protocol point of view. We also have RFC 6467, but it's Informational and I'm not sure it's widely supported. And while the RFC 6467 framework is flexible enough, it is still not clear for me if it can accommodate PAKEs like OPAQUE... Regards, Valery. > I also heard Dan offer to remain silent, and I just wanted to get that > on the record. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works| network architect [ > ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails > [ > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] replacing PSKs: CFRG and PAKE
Hi Nico, > > I think we should ask the CFRG to pick a single balanced PAKE for us. > > They've done so! Not so sure. In Bangkok the CFRG just decided to start the process of selecting "one or more" (that after discussion turned out into "zero or more") recommended PAKE(s). Regards, Valery. > https://tools.ietf.org/html/draft-irtf-cfrg-spake2 > > That specifies one non-augmented, and one augmented PAKE. > > I think the I-D is close to ready to publish. As it happens I sent in > some comments this past weekend. > > Nico > -- > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] replacing PSKs: CFRG and PAKE
Nico Williams wrote: > > I'm watching the video (in five minute intervals for unexplained > > reasons... it seems like I've been watching this video for days). > > Which video? The video of ipsecme from IETF103. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
