Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Sections 8 - 9)
On Tue, 11 Dec 2018, Fernando Pereñíguez García wrote: These answers look fine. Thanks. Paul (the other emails will take a little more time :) Date: Tue, 11 Dec 2018 13:52:13 From: Fernando Pereñíguez García Cc: ynir.i...@gmail.com, i2...@ietf.org, ipsec@ietf.org, Rafa Marin Lopez , Gabriel López Millán To: p...@nohats.ca Subject: Re: [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Sections 8 - 9) X-Spam-Flag: NO Hi Paul, all, Next you can find our answers to your comments on sections 8 and 9. Section 8: Is this section supposed to be an "Implementation Details" Section as per RFC 7942? If so, it is missing the required note to the RFC Editor to remove the entire section before publication as RFC. [Authors] Agree. We will include it. Section 9.1: In case 1, add a note to use only strong PSKs, with a minimal length and strength. [Authors] Agree. We will add it. Section 9.2: when ESP is used Hoping my advise is taken to only use ESP and not AH, and to use ESP-null in the case of encryption being unwanted, please remove this comment as ESP would always be used. includes the keys for integrity and encryption If we only allow AEAD's, maybe rewrite or leave this out. [Authors] s/"In the case 2, the controller sends the IPsec SA information to the SAD that includes the keys for integrity and encryption (when ESP is used)" / "In the case 2, the controller sends the IPsec SA information to the SAD that includes the required cryptographic keys for ESP or AH" Regards, Fernando. -- Fernando Pereñíguez García, PhD Department of Sciences and Informatics University Defense Center, (CUD), San Javier Air Force Base, MDE-UPCT C/ Coronel Lopez Peña, s/n, 30720, San Javier, Murcia - SPAIN Tel: +34 968 189 946 Fax: +34 968 189 970 -- ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Sections 8 - 9)
Hi Paul, all, Next you can find our answers to your comments on sections 8 and 9. Section 8: Is this section supposed to be an "Implementation Details" Section as per RFC 7942? If so, it is missing the required note to the RFC Editor to remove the entire section before publication as RFC. [Authors] Agree. We will include it. Section 9.1: In case 1, add a note to use only strong PSKs, with a minimal length and strength. [Authors] Agree. We will add it. Section 9.2: when ESP is used Hoping my advise is taken to only use ESP and not AH, and to use ESP-null in the case of encryption being unwanted, please remove this comment as ESP would always be used. includes the keys for integrity and encryption If we only allow AEAD's, maybe rewrite or leave this out. [Authors] s/"In the case 2, the controller sends the IPsec SA information to the SAD that includes the keys for integrity and encryption (when ESP is used)" / "In the case 2, the controller sends the IPsec SA information to the SAD that includes the required cryptographic keys for ESP or AH" Regards, Fernando. -- Fernando Pereñíguez García, PhD Department of Sciences and Informatics University Defense Center, (CUD), San Javier Air Force Base, MDE-UPCT C/ Coronel Lopez Peña, s/n, 30720, San Javier, Murcia - SPAIN Tel: +34 968 189 946 Fax: +34 968 189 970 -- ___ 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
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, 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
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] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Appendix A)
Hi Paul, all: > > Appendix A: > > Why is it "eipsec" and not "ipsec” ? [Authors] We have fixed this now. > > Why is the organization not the IETF? Is this commonly done for yang models? [Authors] You're right. We will change this to: "IETF I2NSF (Interface to Network Security Functions) Working Group" > > encryption-algorithm-t - I think this should only list the MUST/SOULD items, > so AES_GCM (1 flavour), AES_CCM (1 flavour) CHACHAPOLY1305 and NULL > > description "Encryption algorithms - RFC_5996”; [Authors] Right. Our doubt here is if we should refer instead to https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-02 such as https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-08 is doing. If you check this link you will notice is referring to ct:rsa2048 which is referring to ietf-crypto-types > > RFC 5996 is an obsolete reference. It should either refer to RFC 7296, or it > should simply refer to the IANA registry involved. [Authors] OK. > > integrity-algorithm-t: If the above is agreed, this enumeration should only > contain "none" and the entries from aes-cmac-96 and up. That is, > not contain des,md5,sha1 and aes_xcbc. Same obsolete reference is used here > in the description. [Authors] Ok. > > type-autostartup: Maybe instead of RESPOND-ONLY, a better word is "STANDBY"? > That way, the node could decide itself to bring a connection up > without _requiring_ a remote signal, and could be triggered locally as as > well as remotely to come up. [Authors] Sounds reasonable. We should provide a better description of each value as well. > > description "Different types of how IKEv2 starts the IPsec SAs"; > > I would say "different policies of when to start an IKEv2 based IPsec SA". > Does it need clarification this value is ignored or unused for the > "case 2" scenario? [Authors] This typedef is not used in the part of the model associated to case 2 but we can something in the description. > > auth-protocol-type: This should only contain IKEv2. The enum should remain > in case we get IKEv2.1 or IKEv3 in the future. [Author] Agree. > > description "Peer authentication protocols”; > > I would say "IKE authentication protocol version", unless you want to keep > the option open to have a non-IKE protocol. But I think that would > run into many more issues of having parameters that are not defined for IKE? [Author] Agree. > > ipsec-mode: It should only contain Tunnel and Transport Mode. It would be > nice to see some text that forbids using Transport Mode when NAT is > requested, just to avoid a lot of problems and disappointments. L2TP/IPsec > still has major scars due to its use of Transport Mode with NAT. [Authors] Sounds reasonable. > > esp-encap: as stated before, we are missing the port entry. I can also image > that multiple encaps could be allowed, such as TCP-443 and TLS-443. > Also note that the RFC for ESP over TCP recommends to continiously check if > UDP encapsulation has become available, since it is so much prefered > over TCP. But that only makes sense when the remote is a roaming client, and > makes less sense if the network consists of data centers. [Authors] Ok. Let's add the port entry. In any case, I believe that is something that implementation in the NSF (in particular the NETCONF server) could check (UDP encapsulation) > > ipsec-protocol: I think this should only contain esp. See earlier comments. > Notably, if supporting ipcomp here, the yang model must be clear > that it could need an ipcomp + esp IPsec SA for a single 'connection'. Even > if we only leave esp as a valid option, keep this enum in case > we come up with a new esp version of some esp-lite version. [Authors] We are in favour on leaving only ESP. If the WG agrees, let's proceed that way. > > lifetime-action only has "terminate" and "rekey". For libreswan we use > "clear", "hold" and "restart". The difference > between clear and hold is what kernel policy to install for cleartext > packets. For roadwarrionrs coming in, you > want clear to leave no trace. for a site-to-site VPN you generally want > "hold" to ensure you drop all packets until > a new tunnel is established (possible ondemand, so this is different from > restart) [Authors] Basically we have "terminate" and "rekey" since RFC 4301 says: "Lifetime of this SA: a time interval after which an SA must be replaced with a new SA (and new SPI) or terminated, plus an indication of which of these actions should occur." We are realizing that RFC 4301 should also be updated to reflect these new possibilities. In any case, could you elaborate a little bit more about the difference between clear and hold and the effect in the kernel? We are assuming that affects the SAD. > > ipsec-traffic-direction: > > Traditionally, freeswan ony used inbound/outbound and not forward. > Unfortunately, KAME and Linux/XFRM kept forward there. But I
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
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
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
