Subject: [Emu] Security considerations text for draft-ietf-emu-chbind

From: Sam Hartman <[email-masked]>
Date: Mon, 12 Mar 2012 16:12:49 -0400

Hi.
I'm posting a new version of the channel bindings draft in response to
AD review comments.
I've been requested to develop security considerations text in response
to attacks I wrote about on the list.

Here's the text I'm including in the new draft.
Comments are welcome.

I don't know if Sean will simply issue the IETF last call and allow us
to comment on this text during the last call or if he'll seek comments
on this text before the last call.  Either way, you should send comments
on this new security considerations text now if you have some.

At the bottom of section 9.1 I've added:

   This trust model is a significant departure from the standard EAP
   model.  In many EAP deployments today attacks where one NAS can
   impersonate another are out of scope.  Channel bindings brings these
   attacks into scope; the system as a whole needs to be analyzed to
   evaluate cases where one NAS may impersonate another and to evaluate
   the impact of this impersonation.

   One attractive implementation strategy for channel binding is to add
   channel binding support to a tunnel method which can tunnel an inner
   EAP authentication.  This way, channel binding can be achieved with
   any method that can act as an inner method even if that inner method
   does not have native channel binding support.  The requirement for
   mutual authentication and key derivation is at the layer of EAP that
   actually performs the channel binding.  Tunnel methods sometimes use
   cryptographic binding, a process where a peer proves that the peer
   for the outer method is the same as the peer for an inner method to
   tie authentication at one layer together with an inner layer.
   Cryptographic binding does not always provide mutual authentication;
   its definition does not require the server to prove that the inner
   server and outer server are the same.  Even when cryptographic
   binding does attempt to confirm that the inner and outer server are
   the same, the Master Session Key (MSK) is typically used to protect
   the binding.  However, the MSK is disclosed to the NAS, which can
   typically attack cryptographic binding if it terminates the tunnel at
   the NAS instead of the EAP server.  This attack was not in scope for
   existing threat models for cryptographic binding because one NAS
   impersonating another is considered out of scope.  Thus, existing
   cryptographic binding does not typically provide mutual
   authentication required for channel binding.

I've added a new section 9.3:

9.3.  Bid-Down Attacks

   EAP methods that add channel binding will typically negotiate its
   use.  Even for entirely new EAP methods designed with channel binding
   from the first version, some deployments may not use it.  It is
   desirable to protect against attacks on the negotiation of channel
   bindings.  An attacker including the NAS SHOULD NOT be able to
   prevent a peer and server who support channel bindings from using it.

   Unfortunately existing EAP methods may make it difficult or
   impossible to protect against attacks on negotiation.  For example,
   many EAP state machines will accept a success message at any point
   after key derivation to terminate authentication.  EAP success
   methods are not integrity protected; an attacker who could insert a
   message can generate one.  The NAS is always in a position to
   generate a success message.  Common EAP servers take advantage of
   state machines accepting success messages even in cases where an EAP
   method might support a protected indication of success.  It may be
   challenging to define channel binding support for existing EAP
   methods in a manner that permits peers to distinguish an old EAP
   server that sends a success indication and does not support channel
   binding from an attacker injecting a success indication.

---

From: Sean Turner <[email-masked]>
Date: Mon, 12 Mar 2012 16:32:12 -0400

I'd like to see any comments by March 16th.

spt

On 3/12/12 4:12 PM, Sam Hartman wrote:
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
>