I'd like to see any comments by March 16th.
spt
On 3/12/12 4:12 PM, Sam Hartman wrote:
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.
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
