Subject: [eap] Channel Binding analysis

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 12 May 2006 11:00:25 -0400

[1] Jari's original proposal:

"
Channel Binding

A secure mechanism for ensuring that a chosen set of channel
properties (such as endpoint identifiers) are agreed upon by the EAP
peer, authenticator and server.
"

I believe this is the right definition.  If the agreement is just
between the EAP peer and server, because the two-party agreement does
not assure the identity of the authenticator.

[2] Case study: Kerberos

Let me do some case study on an existing three-party key management
protocol, Kerberos.

In Kerberos, a client asks a Ticket Granting Server (TGS) for a ticket
needed for communicating with an application server.  The ticket
generated by the TGS consists of the identity of the client and a
session key, all encrypted in the application server's key.  The TGS
returns the ticket and a copy of the session key to the client, all
encrypted in the client's key.  However, this exchange does not by
itself provide any assurance of the identity of the client.  Assurance
of the identity of the client is made by another exchange between the
client and application server based on verifying the ticket.

The TGS agrees on the client's identity by issuing the ticket.  The
client and application server agree on the client's identity by
verifying the ticket issued by the TGS.  The three-party agreement on
the client identity is made securely based on cryptographic proof of
possession of the session key between the client and application
server, where the ticket has the binding between the session key and
client's identity.

[3] Going back to Channel Binding issue

One may see the roles of the TGS, client and application server in
Kerberos are similar to those of the EAP server, authenticator and
peer.  

In the analysis below, for simplicity but without losing generality,
it is assumed that authenticator's identity is used as the channel
property.

In key mixing approach, the EAP server agrees on the authenticator's
identity by key mixing.  The authenticator and peer agree on the
authenticator's identity by running SAP using the mixed key.  The
three-party agreement on the authenticator's identity is made securely
based on cryptographic proof of possession of the mixed key between
the peer and authenticator, where the mixed key itself has the binding
with authenticator's identity.

In data transferring approach, the EAP server and peer agree on the
authenticator's identity by exchanging the authenticator's identity
over a protected EAP method and checking the exchanged data.  The
authenticator and peer agree on the authenticator's identity by
running SAP using the MSK.  The three-party agreement on the
authenticator's identity is made based on cryptographic proof of
possession of the MSK between the peer and authenticator, however, it
is not sure whether the three-party agreement is *securely* made
because there is no cryptographic proof of what the first check has
ever been performed.

draft-arkko-eap-service-identity-auth-04.txt captures this fact:

"
   The overall result of both approaches is the same, but there are
   subtle security differences: One difference is that in the EAP
   approach we need to trust the endpoints to actually perform the
   check, whereas the key-based check is implicit and "non-skippable" in
   the latter approach; if the parameters mismatch the keys simply do
   not work.
"

I don't think this difference is subtle because Channel Binding is a
key management issue.  Or we might need to think about what "secure
agreement" means.

Best regards,
Yoshihiro Ohba
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 12 May 2006 10:34:16 -0700

* On the CB definition: I like something along the lines of

"   The main idea of channel bindings is to be able to verify information
    from two sources, such as comparing what the EAP authenticator has
    told the peer and the server.  Different designs could implement this
    check at different nodes: at the peer, the server, or both."

from draft-arkko-eap-service-identity-auth-04.txt.

* On the comparison with Kerberos, I am not sure I want to venture 
there.  Kerberos is a "true" 3-party exchange. EAP itself is a 
2-party protocol.

* On CB verification vs. binding CB to key derivation, I have the 
same thoughts as Jari and Pasi have (I think others have too), and 
that is we should rely on verification and not key binding.

Whereas key binding may *seem* like an obvious way to make sure 
verification is not skipped or something like that, a closer look at 
any security protocol tells us that we rely on end-points verifying 
something all the time.  Sure there are subtle differences in one 
verification over another, but nevertheless, verification is 
ok.  Furthermore, there is an important practical consideration.  As 
Jari and Pasi list in Section 4.2 of 
draft-arkko-eap-service-identity-auth-04.txt, there may be a long 
list of CB parameters, and not just IDs.  Furthermore, it is 
plausible that the authenticator does indeed report different things 
to the server and the peer.  All we care about verifying is that 
whether the information advertised to the peer is "consistent" (a 
loose word; perhaps "subset of" is better) with the information known 
to the server.  More specifically, some information may be more 
important than the other, based on administrative definitions even.

As long as we are discussing this, let's explore an example.  I was 
told (thanks to Vidya, Joe and others) that the goal is to ensure 
that a peer is not getting duped by an Authenticator.  If all service 
in the world is uniform, it doesn't matter which Authenticator 
provides access, the peer gets access and it doesn't care about 
anything else; CB is not required.  Any data protection worries are 
to be addressed by end-to-end security.  If the peer cares about 
which Authenticator it wants to get access with based on its 
preferences on (filtering, whatever) policy, QoS, billing practices, 
etc., CB looks like one of the solutions.  However, notice that 
depending on what the peer might care about, it may send only a 
portion of the information advertised by the Authenticator to the 
server for verification.  The server could verify that and state 
whether the information is valid or not!  So, sending information via 
EAP seems unavoidable to me.

Whether the verified information is bound to key derivation or not 
might be an orthogonal topic!  Note also that verification and 
communication of the result is an integral part so the 
protocol  works correctly.

regards,
Lakshminath