[anonsec] details of IKE/IPsec channel binding
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
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? */
Look at RFC2743 or RFC2744 and look at the function signatures for
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
[*] Total failure in the GSS-API case, partial failure for SASL/GS2.
More information about the ANONSEC