Hi Dan,
as you say below, PACE uses a notification for the initiator to indicate
its support of the protocol. In fact, both sides get a chance to
indicate their support.
SPSK uses the Critical (a.k.a. Mandatory) bit for the initiator to
indicate this support, and relies on an error indication from the
responder if the responder doesn't like the protocol.
While the SPSK mechanism sort of works in an SPSK-only world, it makes
the life of implementations that want to support multiple methods much
harder.
Suppose that Alice wants to talk to Bob. Alice supports PACE, SPSK and
even EAP-pwd, but has no idea what Bob supports. After the IKE_SA_INIT
exchange, Alice will know if Bob supports PACE, but will not know if he
supports SPSK (EAP method negotiation is another can of worms, let's
leave it for another day). So Alice embarks on the IKE_AUTH exchange
with only partial knowledge.
If Alice now initiates SPSK (by sending COMi), but it turns out that Bob
does not support it after all, Bob will reply with an
UNSUPPORTED_CRITICAL_PAYLOAD. Alice will now have to restart the whole
exchange with the knowledge of Bob's abilities. This is certainly more
complex than doing it all within the same exchange. Moreover, since
authentication never completed, Bob's response is subject to an
undetected downgrade attack.
Alice would be eternally grateful if an SPSK_SUPPORTED notification were
added into the IKE_SA_INIT exchange :-)
I'm not sure if there's any valid use for the Critical bit (i.e. for
non-critical payloads in IKEv2), but negotiating an authentication
method doesn't appear to be such use.
Thanks,
Yaron
It might be possible to get the authors of the competing drafts to
rely on a common method of identifying the intent of the initiator
(currently PACE uses a Notify and SPSK uses the mandatory bit) and
ensure that their protocols all look the same-- send a blob, get a blob,
send another blob, get another blob-- and to mix results from PAKE
exchange into results of the D-H exchange in a uniform manner and we might
get the equivalent of what he's proposing without Yet Another Pluggable
Architecture (which I guess we both agree would be not-so-good).
Now the drafts are in LC. Maybe a few comments could get the authors
to align their drafts so they look architecturally identical while
implementing different exchanges.
regards,
Dan.
_______________________________________________
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
