Hi Hugo,
The subject line (and the comment on Bellovin attack) caught my eye. I don't
follow the discussions in this list so I don't know how much the need and
dangers of unauthenticated methods were discussed here. I want to point out
that (and probably many did before me) that un-authentication is a very tricky
option especially in a protocol that was created with mutual authentication as
a core requirement and assumption. I can see potential benefits and uses but I
can also see it abused and misused (the internet draft doesn't do too good a
job warning about it but even if it did, people will misuse it).
I agree that the draft's Security Consideration section in its current form is
incomplete.
And I hope that if the draft is adopted then it will draw an attention of many
people,
who will help to improve the Security Considerations to list all the caveats,
to make all possible warning and to give advice how to safely use this mode.
But requirements aside, I cannot vow for the security of IKE's key exchange
in a one-way authentication mode. No one (that I know, definitely not me)
designed this protocol to support one-way authentication. So the question of
whether it is secure in this setting has not been investigated. Moreover, I see
that the draft uses shared-key fields for theanonymous side of the
communication and, I imagine, the other can use signature-based authentication.
What security properties do you get from that mix-and-match authentication
methods?
IKEv2 currently allows the peers to use different authentication methods.
So, if one of the peers uses preshared key, while the other uses
digital signature, then it is considered legal and secure from
protocol's design point of view. If the peer, using preshared key in this
scenario,
uses key, known to everyone, then we will get one-way authentication
with the current IKEv2. The next step, that the draft does - get rid of
well-known preshared key and compute the content of the AUTH Payload
the same way it is computed currently in IKEv2 when it is used
with non key generating EAP methods - using SK_pi (or SK_Pr) as the key
I believe the draft doesn't change the way cryptography is used in IKEv2.
One likely misuse of this technique is that people will use unauthenticated
(or one-way) IKE and will run some other authentication on top of it (say,
password based or whatever). Well, protocols do not necessarily compose
securely. TLS had many failures like that (BEAST, re-negotiation, triple
handshake, ...) and IPsec saw examples of that in the combinations of
unauthenticated ESP and AH. IKE's cryptographic design has endured the test of
time but these variations (or improvisations) endanger it.
Well, sometimes mutual authentication is impossible or undesirable.
Sometimes privacy is more important and people are ready to
sacrifice some level of security to keep their privacy.
And sometimes the choice is - either use plaintext
or unauthenticated encryption. The latter at least
prevents passive eavesdropping...
Finally, since Bellovin's attack was mentioned, I want to make sure that no
one is thinking of not using the MAC authentication at the IP packet level,
right?
Absolutely.
Hugo
Regards,
Valery Smyslov.
On Mon, Sep 8, 2014 at 10:54 AM, <[email protected]> wrote:
On Sep 7, 2014, at 2:53 PM, Yaron Sheffer <[email protected]> wrote:
> Dear working group,
>
> This is a call for adopting draft-smyslov-ipsecme-ikev2-null-auth as a WG
document. Please respond to this mail with a Yes or No and a short rationale,
at latest by Friday Sep. 12.
Maybe.
I understand and support the rationale for this draft.
The Security Considerations seems to be inadequate. Whenever possible,
real authentication should be used. So the Security Considerations should
explicitly and strongly emphasize that, and recommend that products that
incorporate Null authentication should strive to avoid its use whenever
possible, and steer users away from its use when they can.
A related question: does the use of Null authentication open up the
Bellovin attack? It seems that it would. If so, my answer changes to “NO”.
paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
------------------------------------------------------------------------------
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
