Re: [IPsec] Mutual authnull to mutual authenticated upgrade
Paul Wouters writes: > >> 2) Are we correct with our assumption that you either end up on mutual > >> authnull or with mutual authentication, or do people believe there > >> is a use case for asymmetric authentication as well, in which case > >> the responder could also send AUTH plus N(AUTHNULL) > > > > Actually doesn't that automatically already happen with authnull? I > > mean authentication can be asymmetric, i.e., one end can use > > pre-shared keys and another certificates, and I think authnull also > > allows that, i.e., responder can use certificates to authenticate > > himself and initiator can use authnull. At least Introduction section > > lists all those asymmetric cases as uses cases for NULL auth. > > That doesn't end up favouring authenticated over authnull. See above > disagreement that this matters :) I think it does. See below > > Are the certificates signed by known trust anchor, and is that trust > > anchor already configured in all nodes initially? > > No. Some nodes still have no certificates whatsoever, and some nodes > have been updated to have certificates. Ok. > > On the other hand if you have not trust anchors installed and you need > > to find that out during the handshake, you can use the fact whether > > you get CERTREQs in the exchange to indicate that other end has proper > > trust anchors installed, and if you do not get trust anchors mathing > > your certificate from the other you use NULL auth, and if you do get > > matching trust anchors and you have certificate, then you use > > signatures. > > Some implementations always send CERTREQs even if they only allow PSK, > in case the other end wants to use CERT based auth while this end > uses something else (eg psk or null) So how does they manage to send CERTREQ having hash in them matching your trust anchor, if they have not been configured with that trust anchor? If you have manually configured them to send CERTREQs with trust anchor hashes you do not trust, then I think that is configuration error and it must be fixed. I.e. if you see CERTREQ which has hash matching the trust anchor that signed your certificate, then you can quite safely assume that the other end do support certificates, and has the required trust anchor installed, so you can always use the certificate based authentication yourself. This will cause you to favor certificate based authentications over auth null if it is possible. If remote end sends empty CERTREQ, then fix the configuration in the other end so it will include the hashes of the trust anchors instead. It should be easier to do that, than to implement new protocol... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-11.txt
> On Jul 19, 2018, at 2:09 PM, Paul Wouters wrote: > > On Thu, 19 Jul 2018, internet-dra...@ietf.org wrote: > >> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-11.txt > >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-11 > > This is probably wrong: > > Any INTERNAL_DNSSEC_TA attribute that is not immediately preceded by an > INTERNAL_DNS_DOMAIN attribute MUST be ignored and treated as aprotocol > error. > > Because you can have more then one INTERNAL_DNSSEC_TA for one domain. > Instead, it should read: > > Any INTERNAL_DNSSEC_TA attribute that is not immediately preceded by an > INTERNAL_DNS_DOMAIN or another INTERNAL_DNSSEC_TA attribute applying to > the same domain name MUST be ignored and treated as a protocol error. Good point, agreed on this text. > > From the previous diff, I'm confused about: > > IKE clients MUST use a preconfigured whitelist of one or more domain > which it will allow INTERNAL_DNSSEC_TA updates. > > It could have an empty white list and use direct IP without split-dns ? > Or use the VPN as an "encrypted DNS" provider for everything (which is > allowed according to the spec, that is it does not violate a MUST NOT) > > Also, since we allow signaling of "upgrade your IKE config out of band" > if you see a new unconfigured domain name in the reply, it could be that > you start with 0 and get a new one. Which also requires an empty list. That's fair. Can you propose a sentence here to replace with? Tommy > > Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Mutual authnull to mutual authenticated upgrade
On Thu, 19 Jul 2018, Tero Kivinen wrote: Paul Wouters writes: So we have the following possibilities: 1) authby=authnull -> authby=authnull 2) authby=authnull,cert -> authby=authnull 3) authby=authnull,cert -> authby=authnull,cert (must yield real authentication) 4) authby=authnull -> authby=authnull,cert Actually all of those (including the last one) are just authnull always. If you do not require authentication then Man in the middle attacker can just modify the exchange so that authnull is only one offered. You can prefer authentication over unauthenticated. You could do different things. But yes, this is a migration path that mostly avoids some kind of flag day or a rollout where one non-updated node prevents all the network from using authenticated communication. 1 and 5 are existing known working deployments. And 2-4 are exactly same as 1 from security point of view. No, a cert-cert connection is still proving there is no MITM :P Note, that you can already do this in standardized ways by using multiple authentications RFC 4739. I.e., initially do normal authnull and include MULTIPLE_AUTH_SUPPORTED in IKE_SA_INIT response and 1st IKE_AUTH request. If both included it, then you know they have certificates, thus you can do 2nd round of authentication by adding ANOTHER_AUTH_FOLLOWS too to the 1st IKE_AUTH request. Then you do 2nd IKE_AUTH exchange which does the certificate based authentication. I guess we did not support that, but it is a fair point. 2) Are we correct with our assumption that you either end up on mutual authnull or with mutual authentication, or do people believe there is a use case for asymmetric authentication as well, in which case the responder could also send AUTH plus N(AUTHNULL) Actually doesn't that automatically already happen with authnull? I mean authentication can be asymmetric, i.e., one end can use pre-shared keys and another certificates, and I think authnull also allows that, i.e., responder can use certificates to authenticate himself and initiator can use authnull. At least Introduction section lists all those asymmetric cases as uses cases for NULL auth. That doesn't end up favouring authenticated over authnull. See above disagreement that this matters :) Are the certificates signed by known trust anchor, and is that trust anchor already configured in all nodes initially? No. Some nodes still have no certificates whatsoever, and some nodes have been updated to have certificates. On the other hand if you have not trust anchors installed and you need to find that out during the handshake, you can use the fact whether you get CERTREQs in the exchange to indicate that other end has proper trust anchors installed, and if you do not get trust anchors mathing your certificate from the other you use NULL auth, and if you do get matching trust anchors and you have certificate, then you use signatures. Some implementations always send CERTREQs even if they only allow PSK, in case the other end wants to use CERT based auth while this end uses something else (eg psk or null) Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-11.txt
On Thu, 19 Jul 2018, internet-dra...@ietf.org wrote: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-11.txt A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-11 This is probably wrong: Any INTERNAL_DNSSEC_TA attribute that is not immediately preceded by an INTERNAL_DNS_DOMAIN attribute MUST be ignored and treated as aprotocol error. Because you can have more then one INTERNAL_DNSSEC_TA for one domain. Instead, it should read: Any INTERNAL_DNSSEC_TA attribute that is not immediately preceded by an INTERNAL_DNS_DOMAIN or another INTERNAL_DNSSEC_TA attribute applying to the same domain name MUST be ignored and treated as a protocol error. From the previous diff, I'm confused about: IKE clients MUST use a preconfigured whitelist of one or more domain which it will allow INTERNAL_DNSSEC_TA updates. It could have an empty white list and use direct IP without split-dns ? Or use the VPN as an "encrypted DNS" provider for everything (which is allowed according to the spec, that is it does not violate a MUST NOT) Also, since we allow signaling of "upgrade your IKE config out of band" if you see a new unconfigured domain name in the reply, it could be that you start with 0 and get a new one. Which also requires an empty list. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPsecME@IETF102 Montreal meeting minutes
On Thu, 19 Jul 2018, Scott Fluhrer (sfluhrer) wrote: If you ask my opinion, I think it's cleaner if we use fresh nonces; however I do not believe that there is any security difference. Yes, let us never ever re-use nonces just to make it super clear what a nonce is, even if it would be harmless. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKE_AUX comments
Hi Valery, opinions inline On 2018-07-19, 10:14 AM, "Valery Smyslov" mailto:smyslov.i...@gmail.com>> wrote: Hi, as it often happens, good thoughts come a bit late... While I agreed before on using all-zero key for PRF and even put this into my yesterday's presentation, while keeping thinking about the issue I came across a good reason to use SK_pi/SK_pr instead of all-zero keys. My reasoning is as follows. We define IKE_AUX as a more generic mechanism for transporting large amount of data in initial IKE exchanges. While currently QSKE looks like primary application for this mechanism, I can imagine that it can be applicable for other use cases too. Then, while we all are waiting for appearing Quantum Computers and are trying to be prepared to this, we really don't know when it happens and whether it happens at all (the story of TOKAMAK https://en.wikipedia.org/wiki/Tokamak is a good example of situation, when engineering issues keep unresolved for decades). So we can expect that at least for some period of time there will be applications that would not be concerned with Quantum Computers, but they would probably use IKE_AUX. For such use cases we can assume that initial shared keys computed as a result of IKE_SA_INIT are not known to attacker, and if we use SK_pi/SK_pr as a keys for PRF, then there is no reason to restrict choice of PRFs by excluding XCBC and CMAC. On the other hand, if later some new QSKE method appear, that will have small enough public keys, so that it can be used in IKE_SA_INIT, and IKE_AUX would be used for some purposes other then QSKE, then again the key would not be known to attacker and there would be no reason to restrict the choice of PRFs. In this example, assuming that one is using a QSKE because they want quantum safety, the PRFs will still have to be restricted simply because PRF_AES128_XCBC and PRF_AES128_CMAC only provide 64 bits of protection against a quantum computer. So, my suggestions: 1. use SK_pi/SK_pr as keys for PRF that authenticate IKE_AUX messages If using IKE_AUX in a non-QSKE use-case then any encrypted payload is already protected by the encryption algorithm + integrity algorithm (or AEAD encryption), but any unencrypted payloads + the IKE header wouldn’t be protected using a 0 key, so your proposal sounds reasonable. 2. don't impose any restrictions on the choice of PRF in the IKE_AUX draft (but probably write some words in the Security Considerations) 3. in QSKE document add a restriction on PRF choice, excluding those, that a) are not secure in PQ world and b) are not secure against preimage attack in case of known key. Sounds reasonable, since in order to establish a QS SA there will have to be restrictions on encryption/integrity algorithms anyways, with the caveat that for encryption/integrity we only have to say “use something with 256 bits of security”, whereas for PRF that wouldn’t be sufficient if for example PRF_AES256_CMAC became a thing. Any opinions? Scott, Daniel, what do you think about this? Regards, Valery. All three work (that is, they prevent any undetected modifications to the IKE_AUX payloads); I quite understand if (1) would be considered an undesirable option. As for (2) and (3), they are largely the same; (3) limits the PRF’s to the ones which include second-preimage-resistant hash functions. I can see the attraction of not requiring a separate negotiation; I’m just worried about someone ignoring our ‘don’t use XCBC/CMAC’ mandate… Also, for (3), you have to be careful to specify which SK_p[ir] to use; in our draft, the IKE_AUX message updates them; the obvious thing to do is specify that you’ll use the SK_p[ir] values that were in effect at the beginning of the IKE_AUX message in question. Actually, for security, we don’t need a secret key, having both sides use, say, an all zero key, would achieve the same security goal, however that does feel weird… Using an all zero key does feel weird, however it could help avoid potential incompatible implementation errors. There are two sets of SK_p[ir] available to use in the case where an IKE_AUX includes a key exchange, the values in effect at the beginning of the IKE_AUX exchange, and the updated values resulting from the IKE_AUX exchange. Depending on the order in which implementations recalculate the SKEYSEED and SK_* keys, vs when they perform the PRF on the IXE_AUX data, the “current” SK_p[ir] values could be the old or new values and so some implementations may have to maintain both the old and new keys until the IKE_AUX digest is calculated. All this is to say, if it doesn’t affect the security it may just be simpler and easier for compatibility to use an all zero key. Regards, Valery. Thanks, Daniel ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPsecME@IETF102 Montreal meeting minutes
Scott Fluhrer (sfluhrer) writes: > "I put it in there because we reused an existing key update > mechanism, and as that mechanism used nonces, we included them" Updated to: Valery: I like it. You outlined that you send Nonce payload for each KE exchange, and not reuse one from IKE_SA_INIT. Is it neceesary for security? Scott: No, but I put it in there because we reused an existing key update mechanism, and as that mechanism used nonces, we included them. > I don't know if we really thought about it; the mechanism needed > nonces, so we included them. We didn't really consider reusing > previously exchanged nonces... > > If you ask my opinion, I think it's cleaner if we use fresh nonces; > however I do not believe that there is any security difference. I agree on that, and we might have cases where there might be security resons to do it, for example the nonce length required might be different (i.e., some method requiring exactly 512 bits of nonces, i.e., 256 bits from both ends). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Mutual authnull to mutual authenticated upgrade
Paul Wouters writes:
> So we have the following possibilities:
>
> 1) authby=authnull -> authby=authnull
> 2) authby=authnull,cert -> authby=authnull
> 3) authby=authnull,cert -> authby=authnull,cert (must yield real
> authentication)
> 4) authby=authnull -> authby=authnull,cert
Actually all of those (including the last one) are just authnull
always. If you do not require authentication then Man in the middle
attacker can just modify the exchange so that authnull is only one
offered.
I.e., the option 4 is still insecure until you go and change
configuration to 5. So the question there is if you do not care about
authentication you should just install certs everywhere, and then
start requiring authentication like you have in your case 5 below:
> When all nodes have gotten a cert, you can remove authnull so end up with:
>
> 5) authby=cert -> authby=cert
>
> 1 and 5 are existing known working deployments.
And 2-4 are exactly same as 1 from security point of view.
> 1) Is this useful enough to write up as RFC ?
As all cases 2-4 are just authnull really, and do not offer anything
for security, I am not sure there is point of adding them as RFC.
Note, that you can already do this in standardized ways by using
multiple authentications RFC 4739. I.e., initially do normal authnull
and include MULTIPLE_AUTH_SUPPORTED in IKE_SA_INIT response and 1st
IKE_AUTH request. If both included it, then you know they have
certificates, thus you can do 2nd round of authentication by adding
ANOTHER_AUTH_FOLLOWS too to the 1st IKE_AUTH request.
Then you do 2nd IKE_AUTH exchange which does the certificate based
authentication.
This has exactly same (bad) security properties than what you are
doing, meaning man in the middle can still remove the payloads and
cause us fall back to authnull, but at least it uses already
specified protocol.
Initiator Responder
--- ---
1. HDR, SA, KE, Ni -->
<-- 2. HDR, SA, KE, Nr, [CERTREQ],
N(MULTIPLE_AUTH_SUPPORTED)
3. HDR, SK { IDi, [CERT+], [CERTREQ+], [IDr], AUTH,
SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED),
N(ANOTHER_AUTH_FOLLOWS) } -->
<-- 4. HDR, SK { IDr, [CERT+], AUTH }
5. HDR, SK { IDi, [CERT+], AUTH } -->
<-- 6. HDR, SK { SA, TSi, TSr }
> 2) Are we correct with our assumption that you either end up on mutual
> authnull or with mutual authentication, or do people believe there
> is a use case for asymmetric authentication as well, in which case
> the responder could also send AUTH plus N(AUTHNULL)
Actually doesn't that automatically already happen with authnull? I
mean authentication can be asymmetric, i.e., one end can use
pre-shared keys and another certificates, and I think authnull also
allows that, i.e., responder can use certificates to authenticate
himself and initiator can use authnull. At least Introduction section
lists all those asymmetric cases as uses cases for NULL auth.
So I do not think you actually need to do MULTIPLE_AUTH_SUPPORTED or
hacks what you are doing.
Are the certificates signed by known trust anchor, and is that trust
anchor already configured in all nodes initially?
If so then asymmetric authentication should just work. I.e., in case 2
the initiator will authenticate himself with certificates, and
responder can verify that, but still use NULL auth himself. In case 4
it will be other way around.
On the other hand if you have not trust anchors installed and you need
to find that out during the handshake, you can use the fact whether
you get CERTREQs in the exchange to indicate that other end has proper
trust anchors installed, and if you do not get trust anchors mathing
your certificate from the other you use NULL auth, and if you do get
matching trust anchors and you have certificate, then you use
signatures.
Or am I missing something now?
--
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPsecME@IETF102 Montreal meeting minutes
> -Original Message- > From: IPsec On Behalf Of Tero Kivinen > Sent: Thursday, July 19, 2018 11:23 AM > To: Valery Smyslov > Cc: ipsec@ietf.org; 'Paul Wouters' > Subject: Re: [IPsec] IPsecME@IETF102 Montreal meeting minutes > > Valery Smyslov writes: > > No, I asked why each new KE in IKE_AUX incorporates its own nonce, > > instead of re-using nonces from IKE_SA_INIT. I have no problem with > > this if it is needed for security, my question was driven by > > curiosity. > > I.e., so this would be (more?) correct: > -- > Valery: I like it. You outlined that you send Nonce payload for each > KE exchange, and not reuse one from IKE_SA_INIT. Is it > neceesary for security? > > Scott: No, but I put it in there because it kept the existing >code/protocol intact. Yes; not the wording I used, but that's what I meant. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPsecME@IETF102 Montreal meeting minutes
Valery Smyslov writes: > No, I asked why each new KE in IKE_AUX incorporates its own nonce, instead > of re-using > nonces from IKE_SA_INIT. I have no problem with this if it is needed > for security, my question was driven by curiosity. I.e., so this would be (more?) correct: -- Valery: I like it. You outlined that you send Nonce payload for each KE exchange, and not reuse one from IKE_SA_INIT. Is it neceesary for security? Scott: No, but I put it in there because it kept the existing code/protocol intact. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPsecME@IETF102 Montreal meeting minutes
Paul Wouters writes: > On Thu, 19 Jul 2018, Tero Kivinen wrote: > > > Thanks for Brian Weis taking minutes from the IPsecME WG meeting. I > > did some editing and posted them on the datatracker: > > https://datatracker.ietf.org/meeting/102/materials/minutes-102-ipsecme-00 > > ossible mis-use by DNS server -> possible mis-use by VPN server > > (added after meeting to clarify: It is assumed a CA/provisioning server > is more secure then a VPN gateway) Fixed and added. > Regarding: > > Valery: I like it. You outlined that . Is it neceesary for > security? > > Scott: No, but I put it in there because . > > I believe this was about sending KE payloads for each exchange? And > Scott left it in because it kept the existing code/protocol intact? Like this: Valery: I like it. You outlined that sending KE payload for each exchange. Is it neceesary for security? Scott: No, but I put it in there because it kept the existing code/protocol intact. > Dan H: Are only NIST protocols two message protocols? > > That should be "Are all NIst protocols two message protocols?" Fixed. > Paul W: One one hand you're saying you don't have enough memory to do > full DH, but you're doing it. > > My question was actually: > > Paul W: One one hand you're saying you don't have enough memory to do > thousands of DH, but on the other hand you can store 1000 DH > keys? Or "On one hand ..."? Paul W: On one hand you're saying you don't have enough memory to do thousands of DH, but on the other hand you can store 1000 DH keys? -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] I-D Action: draft-ietf-ipsecme-split-dns-11.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Split DNS Configuration for IKEv2 Authors : Tommy Pauly Paul Wouters Filename: draft-ietf-ipsecme-split-dns-11.txt Pages : 13 Date: 2018-07-19 Abstract: This document defines two Configuration Payload Attribute Types for the IKEv2 protocol that add support for private DNS domains. These domains are intended to be resolved using DNS servers reachable through an IPsec connection, while leaving all other DNS resolution unchanged. This approach of resolving a subset of domains using non- public DNS servers is referred to as "Split DNS". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-11 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-split-dns-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPsecME@IETF102 Montreal meeting minutes
> -Original Message- > From: IPsec On Behalf Of Valery Smyslov > Sent: Thursday, July 19, 2018 10:21 AM > To: 'Paul Wouters' ; 'Tero Kivinen' > Cc: ipsec@ietf.org > Subject: Re: [IPsec] IPsecME@IETF102 Montreal meeting minutes > > Hi Paul, > > > Valery: I like it. You outlined that . Is it neceesary > for > > security? > > > > Scott: No, but I put it in there because . "I put it in there because we reused an existing key update mechanism, and as that mechanism used nonces, we included them" > > > > I believe this was about sending KE payloads for each exchange? And > > Scott > left > > it in because it kept the existing code/protocol intact? > > No, I asked why each new KE in IKE_AUX incorporates its own nonce, instead > of re-using nonces from IKE_SA_INIT. I have no problem with this if it is > needed for security, my question was driven by curiosity. I don't know if we really thought about it; the mechanism needed nonces, so we included them. We didn't really consider reusing previously exchanged nonces... If you ask my opinion, I think it's cleaner if we use fresh nonces; however I do not believe that there is any security difference. > > Regards, > Valery > > ___ > 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
[IPsec] Mutual authnull to mutual authenticated upgrade
We had to support the following deployment. A large group of nodes is deployed with mutual authnull. This offers passive attack protection on the network. At a later stage, nodes are given their certificate for authentication. The goal was to go from mutual authnull to mutual RSA. If either node does not yet support authentication, both nodes use auth null. So we have the following possibilities: 1) authby=authnull -> authby=authnull 2) authby=authnull,cert -> authby=authnull 3) authby=authnull,cert -> authby=authnull,cert (must yield real authentication) 4) authby=authnull -> authby=authnull,cert When all nodes have gotten a cert, you can remove authnull so end up with: 5) authby=cert -> authby=cert 1 and 5 are existing known working deployments. 2-4 have a scenario where you have to pick an IKE_AUTH method. Depending on the responder you got it right or wrong. If wrong, you have to restart IKE_INIT to try the other method. We wanted to do this IKE_AUTH in 1 roundtrip without a restart of IKE_INIT. Note all these scenarions yield a symmetric authentication. It will be either authnull or mutual "real" authentication (eg RSA or DigitalSignature) So what we ended up doing is similar to the NO_PPK_AUTH trick. We added sending a notify N(AUTHNULL) (40960 private use number) to the IKE_AUTH exchange on the initiator which is a notify containing an AUTH payload using authnull. So this becomes: request --> IDi, [CERT+,] [N(INITIAL_CONTACT),] [N(AUTHNULL)] <- New item [[N(HTTP_CERT_LOOKUP_SUPPORTED),] CERTREQ+,] [IDr,] AUTH, [CP(CFG_REQUEST),] [N(IPCOMP_SUPPORTED)+,] [N(USE_TRANSPORT_MODE),] [N(ESP_TFC_PADDING_NOT_SUPPORTED),] [N(NON_FIRST_FRAGMENTS_ALSO),] SA, TSi, TSr, [V+][N+] The IKE_AUTH response is unmodified. If the responder supports this payload, AND local policy can do authentication, it will ignore this payload and use the regular AUTH payload. If it only has a configuration for authnull, it will use the N(AUTHNULL) as the received AUTH payload instead or the actual AUTH payload. The responder will send back only a real AUTH payload. If the initiator had N(AUTHNULL) but the responder can do regular authentication, it will just send back an real authentication AUTH payload. If the responder can only do authnull, it will send an authnull based AUTH payload. The responder never sends a N(AUTHNULL) payload as we did not need/want to support asymmetrical authentication where one part is authnull and the other is not, as we either have a CA+EE cert for ourselves AND the peer, or we only have authnull for everything. See our test cases: http://testing.libreswan.org/results/testing/v3.25-195-gb3ef436-master/mixoe-03-authanon-anon/ http://testing.libreswan.org/results/testing/v3.25-195-gb3ef436-master/mixoe-02-anon-authanon/ http://testing.libreswan.org/results/testing/v3.25-195-gb3ef436-master/mixoe-01-authanon-authanon/ My questions are: 1) Is this useful enough to write up as RFC ? 2) Are we correct with our assumption that you either end up on mutual authnull or with mutual authentication, or do people believe there is a use case for asymmetric authentication as well, in which case the responder could also send AUTH plus N(AUTHNULL) Paul and Vukasin ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPsecME@IETF102 Montreal meeting minutes
Hi Paul, > Valery: I like it. You outlined that . Is it neceesary for > security? > > Scott: No, but I put it in there because . > > I believe this was about sending KE payloads for each exchange? And Scott left > it in because it kept the existing code/protocol intact? No, I asked why each new KE in IKE_AUX incorporates its own nonce, instead of re-using nonces from IKE_SA_INIT. I have no problem with this if it is needed for security, my question was driven by curiosity. Regards, Valery ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPsecME@IETF102 Montreal meeting minutes
On Thu, 19 Jul 2018, Tero Kivinen wrote: Thanks for Brian Weis taking minutes from the IPsecME WG meeting. I did some editing and posted them on the datatracker: https://datatracker.ietf.org/meeting/102/materials/minutes-102-ipsecme-00 ossible mis-use by DNS server -> possible mis-use by VPN server (added after meeting to clarify: It is assumed a CA/provisioning server is more secure then a VPN gateway) Regarding: Valery: I like it. You outlined that . Is it neceesary for security? Scott: No, but I put it in there because . I believe this was about sending KE payloads for each exchange? And Scott left it in because it kept the existing code/protocol intact? Dan H: Are only NIST protocols two message protocols? That should be "Are all NIst protocols two message protocols?" Paul W: One one hand you're saying you don't have enough memory to do full DH, but you're doing it. My question was actually: Paul W: One one hand you're saying you don't have enough memory to do thousands of DH, but on the other hand you can store 1000 DH keys? ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
