Re: [HOKEY] AD review of draft-ietf-hokey-arch-design

Glen Zorn <glenzorn@gmail.com> Mon, 31 October 2011 05:43 UTC

Return-Path: <glenzorn@gmail.com>
X-Original-To: hokey@ietfa.amsl.com
Delivered-To: hokey@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E8021F8C86 for <hokey@ietfa.amsl.com>; Sun, 30 Oct 2011 22:43:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ow4Rlcmpc8jw for <hokey@ietfa.amsl.com>; Sun, 30 Oct 2011 22:43:23 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 664B921F8C80 for <hokey@ietf.org>; Sun, 30 Oct 2011 22:43:23 -0700 (PDT)
Received: by gyh20 with SMTP id 20so6681715gyh.31 for <hokey@ietf.org>; Sun, 30 Oct 2011 22:43:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=I2ky4awtATc2UrBqCK6co53go+S6BWQlnjrJf5AViMU=; b=o1Xfe+eA3pRH8ExQynN+8Jp1A+G1CQWO7f0v2gQWHgmBbomeij7Y+r1ofFUWQPJTH+ tTrbzXQzgwh9MygovjXD/OIqliHYCuVqDb3ulah9shHLnB9sKL1+VxCa6gyrnPbV9ri0 nSVQnFlwF3jy7FQuNDFK8ZW2aJU4AoNJmckkk=
Received: by 10.68.38.100 with SMTP id f4mr21285719pbk.62.1320039801718; Sun, 30 Oct 2011 22:43:21 -0700 (PDT)
Received: from [192.168.1.99] (ppp-171-96-16-9.revip8.asianet.co.th. [171.96.16.9]) by mx.google.com with ESMTPS id x8sm47557621pbx.15.2011.10.30.22.43.18 (version=SSLv3 cipher=OTHER); Sun, 30 Oct 2011 22:43:20 -0700 (PDT)
Message-ID: <4EAE3573.6090603@gmail.com>
Date: Mon, 31 Oct 2011 12:43:15 +0700
From: Glen Zorn <glenzorn@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <4EA4463B.6000304@cs.tcd.ie> <4EAC0DC0.1030107@gmail.com> <4EAC1364.3080309@cs.tcd.ie> <4EAD3ECE.5010207@net-zen.net> <4EAD6375.4070405@cs.tcd.ie>
In-Reply-To: <4EAD6375.4070405@cs.tcd.ie>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Glen Zorn <gwz@net-zen.net>, hokey@ietf.org
Subject: Re: [HOKEY] AD review of draft-ietf-hokey-arch-design
X-BeenThere: hokey@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: HOKEY WG Mailing List <hokey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hokey>, <mailto:hokey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hokey>
List-Post: <mailto:hokey@ietf.org>
List-Help: <mailto:hokey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hokey>, <mailto:hokey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Oct 2011 05:43:24 -0000

On 10/30/2011 9:47 PM, Stephen Farrell wrote:
> 
> Hiya,
> 
> Coupla things below. But the immediate question is: can
> you shoot out a revised ID before the cutoff? 

Yes, though it may not have everything we've discussed in it (I have to
get on a plane in about 5 hours).

> If so, then
> I'll wait for that then start IETF LC. If not, then I'll
> go ahead anyway since I think we're in good enough shape,
> but better of course if we can get that revised ID first
> so's we don't all have to remember stuff to change/check
> later.
> 

...

>>>>> c) if someone chooses the wrong CAP then they might have been fooled
>>>>> into sending all the user's traffic via a bad actor.
>>>>
>>>> Again, that is not specific to hokey, re-authentication or mobility:
>>>> any
>>>> WiFi AP to which one connects could be a bad actor.
>>>
>>> Doesn't hokey make the client believe its implicitly
>>> authenticated the CAP? Is that really the same as any old
>>> AP?
>>
>> I don't think that that is true, at least in the cases of ERP and AAK;
>> there, (like w/regular EAP), the client never authenticates the AP
>> (unless, of course, the AP is running a stand-alone authenticator).
> 
> Maybe let me try again. Hokey provides a way to move keys
> about so that a CAP can become a SAP. When used successfully
> those keys implicitly authenticate the CAP/SAP as being ones
> that have some kosher reason for being an AP that's "safe"
> for the client.
> 
> Choosing the CAP is (as you've said) not part of hokey.
> Therefore a bad actor might be able to cause AAK to be run
> with a "bad" CAP, perhaps so that that AP can record user
> traffic or to mess with billing.
> 
> The new vulnerability is the ability to influence how AAK
> is being used, previously I guess the client would have
> just picked, which may be more vulnerable in lots of ways,
> but this is (I think) a specific new vulnerability due to
> hokey, that might be exploitable in a systematic way at
> least in theory.
> 
> Does that make sense? (I'm not 100% sure it does, mind you;-)

The part I'm not getting is how AAK "implicitly authenticates the
CAP/SAP" any more than the possession of a valid MSK authenticates a
regular AP w/regular EAP.

...