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

Glen Zorn <> Mon, 31 October 2011 05:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 01E8021F8C86 for <>; Sun, 30 Oct 2011 22:43:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ow4Rlcmpc8jw for <>; Sun, 30 Oct 2011 22:43:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 664B921F8C80 for <>; Sun, 30 Oct 2011 22:43:23 -0700 (PDT)
Received: by gyh20 with SMTP id 20so6681715gyh.31 for <>; Sun, 30 Oct 2011 22:43:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id f4mr21285719pbk.62.1320039801718; Sun, 30 Oct 2011 22:43:21 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id x8sm47557621pbx.15.2011. (version=SSLv3 cipher=OTHER); Sun, 30 Oct 2011 22:43:20 -0700 (PDT)
Message-ID: <>
Date: Mon, 31 Oct 2011 12:43:15 +0700
From: Glen Zorn <>
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 <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Glen Zorn <>,
Subject: Re: [HOKEY] AD review of draft-ietf-hokey-arch-design
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: HOKEY WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.