Hi Michael,
Here's some figures from I-Ds to illustrate what I'm talking about.
Some of the overhead is because both of these are technically client-
server protocols but IKEv2 is initiated by the initiator/client and
EAP is initiated by the responder/server (due to fact that it's design
was for PPP and authentication begins after "link up" notification to
the server-- a call is received at a modem bank, an 802.11 association
completed, etc). Both of these end with a message from the responder/
server so to fit these things together it requires some overhead beyond
a simple +1 message.
Here's the IKEv2 message exchange for EAP-only from the I-D:
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni,
[N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)] -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ],
[N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)]
HDR, SK { IDi, [IDr], SAi2, TSi, TSr,
N(EAP_ONLY_AUTHENTICATION),
[CP(CFG_REQUEST)] } -->
<-- HDR, SK { IDr, EAP(Request) }
HDR, SK { EAP(Response) } -->
<-- HDR, SK { EAP(Request) }
HDR, SK { EAP(Response) } -->
<-- HDR, SK { EAP(Success) }
HDR, SK { AUTH } -->
<-- HDR, SK { AUTH, SAr2, TSi, TSr,
[CP(CFG_REPLY] }
Notice there are 3 messages for IKEv2 handling before the EAP stuff
and then 2 more messages after the EAP stuff. So it's 5 plus whatever
the EAP method adds. What the EAP method adds is indeterminate and depends
on the particular EAP method used (it shows 5 but that's just an example).
So let's plug in an EAP method that has been proposed for use in EAP-only,
EAP-pwd (EAP-EKE has also been proposed but it is exactly the same). This
is figure 2 from the EAP-pwd I-D (soon to be an RFC!):
+--------+ +--------+
| | EAP-pwd-ID/Request | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-pwd-ID/Response | |
| |------------------------------------>| |
| | | |
| | EAP-pwd-Commit/Request | |
| |<------------------------------------| |
| | | |
| | EAP-pwd-Commit/Response | |
| |------------------------------------>| |
| | | |
| | EAP-pwd-Confirm/Request | |
| |<------------------------------------| |
| | | |
| | EAP-pwd-Confirm/Response | |
| |------------------------------------>| |
| | | |
| | EAP-Success | |
| |<------------------------------------| |
+--------+ +--------+
So you see this EAP method does 3 request-response exchanges then a
success. That's 7 messages and 7 + 5 = 12 messages to do this exchange
using the EAP-only technique.
Here's the same underlying key exchange done in SPSK, figure 4 from
the I-D:
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
HDR, SK {IDi, Commit, [IDr,]
SAi2, TSi, TSr} -->
<-- HDR, SK {IDr, Commit, Confirm}
HDR, SK {Confirm, AUTH} -->
<-- HDR, SK {AUTH, SAr2, TSi, TSr}
That's 6 messages.
So we have 6 messages for SPSK and 12 for EAP-only plus EAP method.
A more uncharitable, but arguably accurate, way of looking at this is
to note that the IKEv2 exchange, by itself, is 4 messages so SPSK only
adds 2 while EAP-only plus an EAP method adds 8. So really EAP-only plus
an EAP method is _4 times the number of messages_ of SPSK, not double.
And any channel bindings solution necessary for EAP-only will just
increase the number of messages.
Dan.
On Mon, December 7, 2009 4:34 am, Michael Richardson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>>>>>> "Dan" == Dan Harkins <dhark...@lounge.org> writes:
> >>> 2. solves the specific problem it is aimed at poorly-- doubling
> >>> of the number of messages, requiring writing and testing of new
> >>> state EAP state machines that are, otherwise, unnecessary; and,
> >> Does it double, or does it really just "n+1", which is doubling
> >> if the rest of the protocol has "n=1"? I also wonder if this is
> >> really a sufficiently compelling reason to have two sets of code.
>
> Dan> For the proposed EAP methods, EAP-EKE and EAP-PWD, it really
> Dan> is double. I don't think it's possible to do the kind of
> Dan> exchange that's required-- mutual authentication, key
> Dan> generation-- in n=1 messages.
>
> Dan> If you look at the SPSK draft, it is doing essentially the
> Dan> same exchange as EAP-PWD and doing it in 6 messages total. If
> Dan> you do EAP-only plus EAP-PWD (or EAP-only plus EAP-EKE, doesn't
> Dan> matter) it's 12 messages total.
>
> Is this 6 messages, times 2 directions?
> Or just 6 messages. I can not quite see why the EAP encapsulation
> *doubles* the number of round trips. I can see how it might increase it
> by 1, due to need to do some EAP thing.
>
> Dan> One of the big problems with EAP is that it is a completely
> Dan> underspecified shim. That's why every EAP method needs to
> Dan> roll-its-own identity exchange (the identity obtained by EAP is
> Dan> not suitable for authentication purposes) and roll-its-own
>
> Yes, I completed understand this problem.
> I'm suggesting that if we care for channel bindings for EAP, that we
> (security people who care) need to solve this once and for all.
>
> Dan> Keep in mind, though, that however channel bindings gets
> Dan> solved, it is only going to further increase the number of
> Dan> messages necessary to get what you can get in SPSK in 6, and
> Dan> only 6, messages :-)
>
> Again, I do not know why it has to double the number of round trips.
> I see one extra round trip caused by the EAP-ID process, and then it's
> the same number both ways.
>
> Perhaps you can draw a time-sequence diagram for this to convince me?
>
> - --
> ] He who is tired of Weird Al is tired of life! |
> firewalls [
> ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net
> architect[
> ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
> driver[
> Kyoto Plus: watch the video
> <http://www.youtube.com/watch?v=kzx1ycLXQSE>
> then sign the petition.
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Finger me for keys
>
> iQEVAwUBSxz2WICLcPvd0N1lAQInLQgAiLf0gKq8aHRAKq4r7oaAUXGYYqt9q3Kk
> g+KQYGjBrTmfXCEOYziSNonIN7XrjX4ePn7LHWk9AsWWh22y/esYF3Y5n4fkhktV
> an2SY9AE9CYz2PsXACZut2oRAM/YtHSeSnvvPbTzQ6i5bYoVeJqwthM4XIhpoFL1
> 6J9wY2owu1JzPI5KZeDDefbZscNjI7JVvHvI5deR8qtdykn2W2oOaxhaEEEpPY7p
> gIwkBIhFsnwSslF2sWUPmosDI/CTmo+KKFCa0QbXOP/D93raAgnNmKdDno9AwGjU
> FgAXkh/Z7102hkytkc64D6Lg7wU0fhxo+T+m5OkKV3RlfszjSQe9YA==
> =nC7X
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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
