Hi Scott,
I see the point, thank you. However AES support in hardware is not always
available, so I still think that having a single crypto primitive is better in
this
situation.
But your explanations brings me to a conclusion, that the protocol could me
modified. Please see my logical chain.
The necessity to perform a linear serach of the ppk keys (and thus spending
some CPU power) makes a responder more succeptible to DoS attack,
because it must spend resources in response to any IKE_SA_INIT exchange
even from spoofed IP address. In this situation a sane responder would try to
defend itself sending a cookie request - this would guarantee that the
initiator is alive and the IP address is not spoofed. So, if the cookie request
is
to be sent in most cases when the IKE_SA_INIT message contains ppk
extension anyway, then the protocol could be modified to make cookie
request mandatory in this situation. Then the IKE_SA_INIT exchange would
look like:
HDR, SAi1, KEi, Ni, N(PPK_SUPPORTED) -->
<-- HDR, N(COOKIE), N(PPK_SUPPORTED,
crypto=xxx,
random_data=zzz)
The responder selects prf (and encryption, if it is used) algorithms from the
SAi1 payload. It also supplies random_data that the initiator must use when it
encodes the ppk. The initiator computes an encoded ppk and retries the
request.
HDR, N(COOKIE), SAi1, KEi, Ni, N(PPK_KEY) -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
This variant has a disadvantage that ppk will always require an additional
round trip.
However it has the following benefits:
1. Full support for algorithms agility
2. No need to perform CPU-intensive operations until the initiator's IP is
confirmed 3. In this variant it is the responder who supplies random_data to
initiator to encode ppk,
so it is on the responder discretion how to choose them. For example,
it may precompute the encoded ppk values when it is idle, or it can
reuse random_data several times. This allow the responder to perform
the ppk search in sub-linear time in some circumstances.
4. The additional round trip requires a minimum change to IKEv2,
since cookie request must be supported anyway.
What do you think?
I like it. Someone acting as an active server could determine if two people have the same ppk
(by giving them the same random data); however an active server can determine their identities
anyways, and so that's not a concern. That does mean that we're allowing the server to make
the trade-off between computational complexity and client privacy; if everyone else is OK with that,
so am I.
The one part that I would ask is that the crypto=xxx be a simple field (for example, it's a 32 bit value
in the payload), and not a more complicated payload. My fear is that if we make that parsing
more complex, that would add little-used complexity to the protocol (and parts of the protocol
that are little used/tested are just havens for exploitable bugs).
By crypto=xxx I meant a generic indication of what crypto primitive(s) are to
be used by initiator.
In your original proposal you used two primitives: encryption (AES) and prf
(HMAC_SHA256).
If you accept my proposal then I think it is better to simplify things and use
only one
primitive - prf (for two reasons - first now server can choose a sutable
tradeoff between
client's privacy and the server's CPU load, and second - with generic
encryption you
won't always get any speed benefit from using both encryption and prf).
So I'd suggest to use only prf. In this case crypto=xxx becomes prf=xxx, where prf is a 16-bit
integer containing one of the the values defined in IANA-IKEv2 table "Transform Type 2 -
Pseudo-random Function Transform IDs", and the server selects it from what is present
in the initiator's SA payload in transfoms of type 2. This guarantees that the
initiator
supports that prf (otherwise he wouldn't include it in the SA payload).
In this case the initiator would then compute prf(prf(ppk, "A"), random_bytes).
And there is no need that this selected prf is equal to the prf that is
negotiated
later and used in all SKEYSEED etc claculations - they are not related.
The fact that they are not related simplifies their selection (for example,
you don't need to look at the local policy when selecting mutually supported
prf for ppk).
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
