Re: [abfab] Comments on draft-linus-abfab-ephemeral-keying-00

Linus Nordberg <linus@nordberg.se> Tue, 25 February 2014 15:35 UTC

Return-Path: <linus@nordberg.se>
X-Original-To: abfab@ietfa.amsl.com
Delivered-To: abfab@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2BD1A0033 for <abfab@ietfa.amsl.com>; Tue, 25 Feb 2014 07:35:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.601
X-Spam-Level:
X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDqrsagXOrYs for <abfab@ietfa.amsl.com>; Tue, 25 Feb 2014 07:35:37 -0800 (PST)
Received: from smtp.nordberg.se (smtp.nordberg.se [193.10.5.87]) by ietfa.amsl.com (Postfix) with ESMTP id BC70B1A0794 for <abfab@ietf.org>; Tue, 25 Feb 2014 07:35:25 -0800 (PST)
Received: from amnesia.nordberg.se (afo4.torproject.afo-tm.org [85.114.142.168]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.nordberg.se (Postfix) with ESMTPSA id 42B701152E; Tue, 25 Feb 2014 16:35:20 +0100 (CET)
From: Linus Nordberg <linus@nordberg.se>
To: Jim Schaad <ietf@augustcellars.com>
References: <07af01cf2cdd$761361d0$623a2570$@augustcellars.com> <87vbw4pfwm.fsf@nordberg.se> <029e01cf3183$9b1f99d0$d15ecd70$@augustcellars.com>
Date: Tue, 25 Feb 2014 15:34:41 +0000
In-Reply-To: <029e01cf3183$9b1f99d0$d15ecd70$@augustcellars.com> (Jim Schaad's message of "Mon, 24 Feb 2014 09:12:32 -0800")
Message-ID: <877g8jkxym.fsf@nordberg.se>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/qRO_Ww7qCZZp3ZUxRHt8PNrbRbY
Cc: draft-linus-abfab-ephemeral-keying@tools.ietf.org, abfab@ietf.org
Subject: Re: [abfab] Comments on draft-linus-abfab-ephemeral-keying-00
X-BeenThere: abfab@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" <abfab.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/abfab>, <mailto:abfab-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/abfab/>
List-Post: <mailto:abfab@ietf.org>
List-Help: <mailto:abfab-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/abfab>, <mailto:abfab-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2014 15:35:40 -0000

"Jim Schaad" <ietf@augustcellars.com> wrote
Mon, 24 Feb 2014 09:12:32 -0800:

| > | Section 2.2 - Passive observers may also be able to fingerprint the
| > | client based on TLS restart information.
| > 
| > What does "TLS restart" mean in this context? Do you mean a RadSec client
| > re-establishing a torn down connection? Or maybe TLS renegotiation?  Or,
| > most probably, something third that I'm not familiar with?
| 
| Something else - TLS Session Resumption using server State or PAC (see
| sections 3.2.1 and 3.2.2 of draft-ietf-emu-eap-tunnel-method)

Good point. I added the following to upcoming -01.

--8<---------------cut here---------------start------------->8---
In cases where a TLS-based EAP method is used, a passive observer may
be able to fingerprint the client based on TLS session resumption, for
example as described in {{RFC5077}} section 5.8.
--8<---------------cut here---------------end--------------->8---


| > | Section 2.3 - This should include exposing the realm of the user (or
| > | the full user name in bad implementations).
| > 
| > Do you refer to the "Mechanism Name", as described in RFC7055 section 3.1.
| > or is user realm (and possibly name) carried somewhere else?
| 
| I was referring to exposing the user name, for those cases where people
| don't either tunnel it or don't truncate it to just the realm in the initial
| EAP message sent to the acceptor.

This is mentioned in 2.1. One could indeed argue that it should go here
instead, or both there and here.


| > |    [ maybe expand on how TEAP [draft-ietf-emu-eap-tunnel-method
| > | <http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method> ] could
| > |    solve the problem of AAA proxies learning the MSK, impersonating the
| > |    RP ]
| > |
| > | I would be very interested in seeing how you think there could
| > | possibly be a solution in this space.  I can't see one.

I still haven't worked this through really. Please let me know what's
wrong with the following sketch.

If an EAP peer and server (i.e. ABFAB client and IdP) establish a TLS
session using TEAP with a DHE key exchange, they will share an ephemeral
key which is not known to any intermediaries. The question is how peer
and server authenticate each other. In an ABFAB setting, client and IdP
share a secret in the user pass phrase and can use that as a PSK using a
TLS_DHE_PSK cipher suite.

An alternative authentication method might be TEAP password
authentication (Basic-Password-Auth-Req/Resp). Unless it isn't.


| > | There probably needs to be a nod to using an application level tunnel
| > | as well.  While I think that it might be nice to have this in the
| > | GSS-EAP layer, we cannot ignore this as an option.

What about something like this, as an addition to section 3.1.?

--8<---------------cut here---------------start------------->8---
An alternative place to protect ABFAB authentication with a short
lived key would be in the application level protocol. While some
applications are using protocols already able to protect the GSS-API
traffic using a TLS session with an ephemeral key (XMPP, IMAP, SMTP)
it's not mandatory to use such a tunnel. Other applications use
protocols which might be hard to protect in a tunnel (NFS, SSH).
--8<---------------cut here---------------end--------------->8---