headers
internet-drafts | 3 Jan 2012 19:37
Picon
Favicon

I-D Action: draft-ietf-emu-chbind-12.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the EAP Method Update Working Group of the IETF.

	Title           : Channel Binding Support for EAP Methods
	Author(s)       : Sam Hartman
                          T. Charles Clancy
                          Katrin Hoeper
	Filename        : draft-ietf-emu-chbind-12.txt
	Pages           : 31
	Date            : 2012-01-03

   This document defines how to implement channel bindings for
   Extensible Authentication Protocol (EAP) methods to address the lying
   NAS as well as the lying provider problem.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-emu-chbind-12.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-emu-chbind-12.txt
Permalink | Reply | 1 comment |
headers
Sam Hartman | 3 Jan 2012 19:43
Picon
Favicon

Re: I-D Action: draft-ietf-emu-chbind-12.txt

The chairs asked me to prepare a new version with the following changes:

1)  collapse the registrations in the lower layer type registry as
requested by Sean.

2) Add a paragraph to the beginning of Appendix A.

I believe I've made these changes.  If folks are happy with these two
minor changes I think we're ready to send this to the IESG.
Permalink | Reply | 0 comments |
headers
Sam Hartman | 10 Jan 2012 23:40
Picon
Favicon

Re: I-D Action: draft-ietf-emu-chbind-13.txt

Hi, folks, at the chairs request I made a couple of changes

1) Replaced MUST not with MUST NOT in one instance

2) Added a reference to Bernard's radext-wlan draft. There was already
textual reference, but not an xref tag.

While doing that I noticed that there was a missing against in the
sesentence where I fixed the MUST noNOT, so now we MUST not send
attributes back where we failed to validate *against* what the peer
sends.
Permalink | Reply | 0 comments |
headers
Joe Salowey | 11 Jan 2012 06:30
Picon
Favicon

Request to publish draft-ietf-emu-chbind-13.txt

Please publish draft-ietf-emu-chbind-13.txt as an Proposed Standard RFC.  The Proto write-up is
included below.  

Thanks,

Joe

(1.a) Who is the Document Shepherd for this document? Has the
       Document Shepherd personally reviewed this version of the 
       document and, in particular, does he or she believe this 
       version is ready for forwarding to the IESG for publication? 

Joe Salowey, EMU working group co-chair, is the Working Group Shepherd for this document.  The shepherd has
reviewed the current version and believes it is ready for publication.

 (1.b) Has the document had adequate review both from key WG members 
       and from key non-WG members? Does the Document Shepherd have 
       any concerns about the depth or breadth of the reviews that 
       have been performed?  

The document has had review from both key Working Group and Non-working group members.  This includes
members of the ABFAB community which relies upon this document.

 (1.c) Does the Document Shepherd have concerns that the document 
       needs more review from a particular or broader perspective, 
       e.g., security, operational complexity, someone familiar with 
       AAA, internationalization or XML? 

No
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cakulev, Violeta (Violeta | 11 Jan 2012 21:16
Favicon

draft-cakulev-emu-eap-ibake

All,
Back in IETF 80 we presented EAP-IBAKE. The link to the I-D is provided below:
http://tools.ietf.org/html/draft-cakulev-emu-eap-ibake-01

This EAP method is based on the Identity-Based Authenticated Key Exchange  (IBAKE) protocol.  IBAKE is a
protocol for mutual authentication and key agreement between two or more endpoints. It is based on a
public-key based authentication mechanism, where each message is encrypted with the public key of the
corresponding endpoint, as per the Identity Based  Encryption (IBE) principles.  As a result of the IBAKE
protocol, a shared symmetric key is generated by each endpoint.

EAP-IBAKE is specified in ETSI TS 102 690 (stage 2) and ETSI TS 102 921 (stage 3) as a method for access network
independent device and gateway bootstrapping.
Both specifications are approved and are awaiting publication of EAP-IBAKE (among other things).

While this document could be of interest to emu WG, it would probably require changes to the WG charter.

Group's opinion about specifying EAP-IBAKE in emu WG as well as possible changes to the WG charter is highly appreciated.

Thanks,
-Violeta
Permalink | Reply | 12 comments |
headers
Sam Hartman | 11 Jan 2012 21:33
Picon
Favicon

Crypto Binding: MITM and draft-ietf-emu-eap-tunnel-method


I'd like to thank Margaret Wasserman for coming up with a series of
proposed attacks that lead to the following comments.

In the context of implementing channel binding and a system that takes
advantage of it, I've been focusing on MITM attacks. I'd like to give a
example of the sorts of attacks that are worrying me.  I thought these
were supposed to be solved by crypto binding, but I no longer think that
existing implementation of crypto binding are strong enough.

First, in a channel binding world, some NASes are significantly more
trusted than others. In my ABFAB world that's especially true.

We have clients using EAP-TTLS as a tunnel method with some inner
password method (MSCHAPv2, some PAKE method, whatever. We'll assume that
it generates a key.) We're adding support the EAP-TTLS for channel
binding. That's realistic and is consistent with the approach we've been
trying to standardize. We want the tunnel methods to support channel
binding and perform the channel binding exchange there so we don't have
to modify all EAP methods. NEA needs something similar for data they
plan to transport over EAP.

Consider a compromised print server. It would like to impersonate
someone's bank. (In an ABFAb world, EAP is used for things other than
network access. I can construct a network access version of this attack
if you'd like too.)

The print server  impersonates the bank enough to get the client to
connect to it. It then starts authentication. We're using ABFAB to
authenticate the client to the server and the server to the client. The
(Continue reading)

Permalink | Reply | 13 comments |
headers
Tschofenig, Hannes (NSN - FI/Espoo | 12 Jan 2012 08:07

Re: draft-cakulev-emu-eap-ibake

Hi Violeta, 

What problem are you trying to solve with this EAP method? 

Ciao
Hannes

> -----Original Message-----
> From: emu-bounces <at> ietf.org [mailto:emu-bounces <at> ietf.org] On Behalf Of
> ext Cakulev, Violeta (Violeta)
> Sent: Wednesday, January 11, 2012 10:16 PM
> To: emu <at> ietf.org
> Subject: [Emu] draft-cakulev-emu-eap-ibake
> 
> All,
> Back in IETF 80 we presented EAP-IBAKE. The link to the I-D is
provided
> below:
> http://tools.ietf.org/html/draft-cakulev-emu-eap-ibake-01
> 
> This EAP method is based on the Identity-Based Authenticated Key
> Exchange  (IBAKE) protocol.  IBAKE is a protocol for mutual
> authentication and key agreement between two or more endpoints. It is
> based on a public-key based authentication mechanism, where each
> message is encrypted with the public key of the corresponding
endpoint,
> as per the Identity Based  Encryption (IBE) principles.  As a result
of
> the IBAKE protocol, a shared symmetric key is generated by each
> endpoint.
(Continue reading)

Permalink | Reply | 11 comments |
headers
Alan DeKok | 12 Jan 2012 11:47
Favicon
Gravatar

Re: Crypto Binding: MITM and draft-ietf-emu-eap-tunnel-method

Sam Hartman wrote:
> Then, assuming we're using TTLSv1, the client will do crypto
> binding. Intuitively you'd kind of think that crypto binding would help
> here; I'll discuss in a bit whether it's supposed to. It's quite clear
> it doesn't though. Crypto binding uses the MSK of the inner method for
> the binding.

  RFC 5281 (TTLS) says:

   Keying material for the subsequent data connection between client and
   access point (Master Session Key / Extended Master Session Key
   (MSK/EMSK); see Section 8) is generated based on secret information
   developed during the TLS handshake between client and TTLS server.

> However, as part of the access-accept, the home EAP server
> discloses the MSK to the print server.  So, the print server has the
> material it needs to perform crypto binding and the generate the final
> MSK.

  I don't see how.  The print server MUST use the MSK from it's TLS
session for crypto bindings.  The MSK (if any) received from the home
server isn't used for anything.

  On top of that, the client will verify that any random data
(challenges, etc.) are generated from the MSK derived from the TLS session:

   When a challenge-based authentication mechanism is used, both client
   and TTLS server use the pseudo-random function to generate as many
   octets as are required for the challenge, using the constant string
   "ttls challenge", based on the master secret and random values
(Continue reading)

Permalink | Reply | 4 comments |
headers
Alan DeKok | 12 Jan 2012 12:21
Favicon
Gravatar

Re: Crypto Binding: MITM and draft-ietf-emu-eap-tunnel-method

Sam Hartman wrote:
> The print server  impersonates the bank enough to get the client to
> connect to it. It then starts authentication. We're using ABFAB to
> authenticate the client to the server and the server to the client. The
> user indicates their home realm in an identity response. 
> The print server, like the bank is a valid participant in the AAA
> fabric. So it sends an access-request to the home EAP server and gets a
> method request.

  As a variant to this attack, if the print server send *NON* EAP
requests to the home server, then this will work.  The print server will
MITM the connection, terminate the TLS tunnel, and do cryptographic
bindings.  The inner authentication will be handled by the home server,
and the client will be unaware.

  The simplest use-case is PAP.  There is no challenge, so crypto
bindings don't apply,

  The next use-case is CHAP.  Crypto bindings apply, but most AAA
servers will accept *both* the challenge and response in the same
request.  This means that the MITM server can calculate the challenge
using crypto bindings, and send it to the home server.  The home server
will then authenticate the user.

  MS-CHAPv1 has the same issue as CHAP.  MS-CHAPv2 does not, but it can
be trivially converted to MS-CHAPv1.  Most AAA servers will accept both
v1 and v2.

  EAP-MD5 and EAP-MSCHAP don't have this issue.  But they can be
trivially converted to CHAP / MS-CHAPv1.  So they have the same issues
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan DeKok | 12 Jan 2012 12:36
Favicon
Gravatar

Re: Crypto Binding: MITM and draft-ietf-emu-eap-tunnel-method

  This is the third message in my response to Sam's long post.  This
topic: channel bindings.

Sam Hartman wrote:
> I'll note that a lot of use cases such as channel binding where the
> tunnel method is considered without certificate verification are
> entirely inappropriate if the inner method is terminated at a different
> place than the tunnel method.

  How do we want to solve that problem?

  The current crypto bindings tie the inner tunnel authentication to the
TLS MSK.  We can't use the TLS MSK to sign the channel binding data, as
a MITM server could just sign it, and never send it to the home server.

  The only solution I can think of is to tie the channel binding data to
the authentication credentials.  This could be done by using an HMAC
over the channel binding data, using a key derived from the users
authentication credentials.

  The client could then sign the channel binding data using this HMAC.
The home server could verify it, and sign its response using the same
method.  The client would then verify the response.  This method still
allows MITM attacks, but ensures that the home server has seen the
channel binding data.

  We could also key the HMAC using a key derived from *both* the TLS MSK
and from the users authentication credentials.  This would ensure that
MITM attacks are impossible.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane