[anonsec] details of IKE/IPsec channel binding

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Julien" == Julien Laganier <julien.IETF at laposte.net> writes:
    >> We seem to be willing to accept this pathological condition.  The
    >> only question is: why not go with the way that doesn't have this
    >> corner case?
    >> 
    >> Possible reasons to reject
    >> public-keys-of-peers-as-channel-bindings:
    >> 
    >> - doesn't work for IKEv2 w/ EAP authentication

    Julien> When IKEv2 is used with EAP authentication, the channel
    Julien> binding blob could fallback from being peers' public keys to
    Julien> a PRF of the EAP MSK. Both peers know that EAP was used, so
    Julien> that doesn't even require additional signalling to let peers
    Julien> generate the appropriate blob.

  This suffers from all the problems that using something derived from
the DH SKEYSEED has.  I don't see a *BTNS* case for doing EAP and then
using channel binding, but I might be wrong.  

  (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.)

  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().

  This is the fundamental API issue. Is the API:

#1 memcpy suffices:

       u_char *my_channel_binding_blob;
       int     my_channel_binding_blob_len;

       u_char *his_channel_binding_blob;
       int     his_channel_binding_blob_len;

       ipsec_get_iToken_attr(iToken, CHANNEL_BINDING,
			     &my_channel_binding_blob, 
			     &my_channel_binding_blob_len);

       gssapi_somefoo_send_channel_binding(my_channel_binding_blob, 
				           my_channel_binding_blob_len);
       /* do I look like I know anything about gssapi? */

       gssapi_somefoo_recv_channel_binding(&his_channel_binding_blob, 
				           &his_channel_binding_blob_len);

       if(my_channel_binding_blob_len == his_channel_binding_blob_len &&
	  memcmp(my_channel_binding_blob, his_channel_binding_blob,
					  his_channel_binding_blob_len)==0))
       {
          return TRUE;
       } else {
          printf("Mallor has been seen!\n");
          return FALSE;
       }


#2 channel binding needs to be checked:
	   			
       u_char *my_channel_binding_blob;
       int     my_channel_binding_blob_len;

       u_char *his_channel_binding_blob;
       int     his_channel_binding_blob_len;

       ipsec_get_iToken_attr(iToken, CHANNEL_BINDING,
			     &my_channel_binding_blob, 
			     &my_channel_binding_blob_len);

       gssapi_somefoo_send_channel_binding(my_channel_binding_blob, 
				           my_channel_binding_blob_len);
       /* do I look like I know anything about gssapi? */

       gssapi_somefoo_recv_channel_binding(&his_channel_binding_blob, 
				           &his_channel_binding_blob_len);

       if(ipsec_check_channel_binding(my_channel_binding_blob, 
				      my_channel_binding_blob_len,
				      his_channel_binding_blob,
			              his_channel_binding_blob_len) {
       {
          return TRUE;
       } else {
          printf("Mallor has been seen!\n");
          return FALSE;
       }


Obviously, case #1 can be implemented inside of case #2.
Case #2 may, however, involve a round trip through the kernel to talk to
the keying deamon if the channel binding blob can not be fully
authenticated without key material that the keying daemon prefers not to
disclose.

- -- 
]            Bear: "Me, I'm just the shape of a bear."          |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr at xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRhJmpoCLcPvd0N1lAQJjOQf7BODO76X1E5uQUacDJN/TtGoesesJ1MJh
/BjBB3yCmj20C4GjAXkJh4biwvS8/0E+H90i+aHTdtVUckvictGwgDQL+CXGAQkm
77q6maFB13PSLPHLpsc2nctmk8l4AI6MMRUBmWuFrt/C9D0k6GGrhr/q5cOSbNtJ
cygPsaKSoFa5RJ4Sb9yeF+l5yZu/QzRBrncbRZPIs2ELG0J9IInXB/uw3a1NH00x
+uc5ax2n3YokXK2FdG3sePhcPxMBWUcYKIQwN9ochThrxIZ6tT51Ua0h2DIlyKEw
AiDeL6kMS+Atx8FosWQLbAynJMzl+frtivOfRTjKRburqZPMcBembQ==
=PS/1
-----END PGP SIGNATURE-----