Re: [abfab] AD review of draft-ietf-abfab-arch-09

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 16 December 2013 17:31 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 56E681ADFE6 for <abfab@ietfa.amsl.com>; Mon, 16 Dec 2013 09:31:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level:
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 kN3ZnC3Ujnfc for <abfab@ietfa.amsl.com>; Mon, 16 Dec 2013 09:31:37 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id ABF581ADFD5 for <abfab@ietf.org>; Mon, 16 Dec 2013 09:31:37 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4B5A3BE4C; Mon, 16 Dec 2013 17:31:36 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0W1khnACFBP2; Mon, 16 Dec 2013 17:31:36 +0000 (GMT)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 49670BE5D; Mon, 16 Dec 2013 17:31:32 +0000 (GMT)
Message-ID: <52AF38F4.2000407@cs.tcd.ie>
Date: Mon, 16 Dec 2013 17:31:32 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Sam Hartman <hartmans@painless-security.com>
References: <52AF2A4C.5000304@cs.tcd.ie> <tsl1u1cvj1f.fsf@mit.edu>
In-Reply-To: <tsl1u1cvj1f.fsf@mit.edu>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "<abfab@ietf.org>" <abfab@ietf.org>
Subject: Re: [abfab] AD review of draft-ietf-abfab-arch-09
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: Mon, 16 Dec 2013 17:31:41 -0000

Hi Sam,

On 12/16/2013 04:48 PM, Sam Hartman wrote:
>>>>>> "Stephen" == Stephen Farrell <stephen.farrell@cs.tcd.ie> writes:
> 
> 
>     Stephen> (1) Am I reading this right? 4.2.2 says: "The EAP MSK is
>     Stephen> transported between the IdP and the RP over the AAA
>     Stephen> infrastructure, for example through RADIUS headers.  This
>     Stephen> is a particularly important privacy consideration, as any
>     Stephen> AAA Proxy that has access to the EAP MSK is able to decrypt
>     Stephen> and eavesdrop on any traffic encrypted using that EAP MSK
>     Stephen> (i.e. all communications between the Client and IdP)." Does
>     Stephen> that mean that if a client authenticates with a password
>     Stephen> say, then that password could be read after the fact by any
>     Stephen> RP or AAA proxy involved in the transaction.  Wouldn't that
>     Stephen> be unacceptable, if e.g.  the equivalent of web-bugs or
>     Stephen> trackers could be inserted into a UI so as to get
>     Stephen> first-shot before a user has authenticated?  And that seems
>     Stephen> to contradict step 7 in 1.4 unless those messages also go
>     Stephen> via the RP, which is not shown in the diagram in 1.4.  What
>     Stephen> am I missing?
> 
> Fortunately, I think you're reading this slightly wrong.
> Learning the MSK is not sufficient to snoop on traffic  between the
> peer/client and IDP.
> Only on traffic between the peer/client AND RP.
> 
> The issue is that if the peer-client use the MSK to encrypt traffic say
> using the GSS per-message services or the GSS PRF, that an attacker who
> learns the MSK can decrypt that traffic.  They should not (and with EAP
> methods that are typically used are believed to be unable to) learn keys
> needed to observe the authentication conversation between peer/client
> and IDP.
> 
> honestly, I consider proxies being able to observe session traffic to be
> quite bad from a perpass standpoint, thus my interest in adding DH
> between client/peer and RP.

So when the text says "(i.e. all communications between the Client
and IdP)" I don't get what that means. Is it just a typo maybe?

S.


> 
>