[anonsec] details of IKE/IPsec channel binding
Nicolas Williams
Nicolas.Williams at sun.com
Wed Apr 4 12:56:17 PDT 2007
On Tue, Apr 03, 2007 at 10:37:28AM -0400, Michael Richardson wrote:
> I don't see a *BTNS* case for doing EAP and then
> using channel binding, but I might be wrong.
Well, I don't see a use for channel binding to EAP-authenticated IPsec
channels (subtle difference).
That's because EAP, by its applicability, would be used in IPsec
VPN-type use cases, and so the end-points of the channel would be the
client and the SG, which have already authenticated each other, so why
authenticate again at the application layer?
> (I can see BTNS for PARENT_SA "authentication", and then EAP for
> further authentication of the SA, but at which point, it might be
> unnecessary to actually do a channel binding. That's is in theory, but
> perhaps in practice, there isn't the total awareness necessary to avoid
> this.)
Well, the channel binding could be done inside EAP, and this could be
used to enroll client public keys (a useful use case if you want to do
two-factor authentication where one factor is a BTNS key and it is
enrolled by one-time one-factor authentication).
> I raised this question, because I felt that it needed to be resolved
> in some way, or resolved that we are comfortable with what we had
> already. The above proposal has the advantage that, like the
> concatenated public keys, it can be checked with memcmp().
Unique and end-point channel bindings can both be checked with memcmp()
(or memcmp() of a hash/MAC of the channel bindings).
> /* do I look like I know anything about gssapi? */
No :)
Look at RFC2743 or RFC2744 and look at the function signatures for
GSS_Init_sec_context()/GSS_Accept_sec_context().
In the GSS-API (and in SASL/GS2) channel bindings are as an input to a
black box at each peer -- both have to provide the same channel binding
octet strings, else -> failure[*].
The black box can (and does, e.g., in the case of the Kerberos V GSS
mech) cause hashes/MACs of the channel bindings octet strings to be
exchanged.
[*] Total failure in the GSS-API case, partial failure for SASL/GS2.
Nico
--
More information about the ANONSEC
mailing list