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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sun, 30 October 2011 14:47 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 1A40521F8B2A for <hokey@ietfa.amsl.com>; Sun, 30 Oct 2011 07:47:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.916
X-Spam-Level:
X-Spam-Status: No, score=-101.916 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, GB_ABOUTYOU=0.5, J_CHICKENPOX_12=0.6, USER_IN_WHITELIST=-100]
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 88KlG3Ks8FIO for <hokey@ietfa.amsl.com>; Sun, 30 Oct 2011 07:47:22 -0700 (PDT)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id EEE7321F8ACC for <hokey@ietf.org>; Sun, 30 Oct 2011 07:47:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D536E157AAD; Sun, 30 Oct 2011 14:47:19 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1319986039; bh=/VjnH+aWXOGcTs vSEOJZNaIGlJnGTCOBrxmIh2L7/vU=; b=3KCkuvmDNdRj9Qxwi4hMt+K5AVgclY q7z+Qmgt7cP7zd2OWvmlwzhqfIOBs0ddjDjkeFHXkBbL9o6Qg97qCX3+cAerLgRn MDDqVCQ6hQpSd8bL/wVRrrlFkbNDBXA8xkSTNIPWe1PZAKLI0R1jyzNkncLnNJWI ORFY1DMDux1v00tmkH0S0RlNz2H4hMkeuypDfuj3/tVKrKeucDVn2swOI9tfweIV g43zM/v3Aw0YsmOl2/+ZeblzQBWCgwnFlO8S5kSBDR3NYo6qUGmT8bwj6PD04CGq UrIwJf9CHI55o+pH7cx5UAYxC3gormUgaffnf+ox3SOtVrspV+hGgKYw==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id GhJzE+jPUJmN; Sun, 30 Oct 2011 14:47:19 +0000 (GMT)
Received: from [10.87.48.12] (unknown [86.41.5.169]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 3D9E6171C5A; Sun, 30 Oct 2011 14:47:18 +0000 (GMT)
Message-ID: <4EAD6375.4070405@cs.tcd.ie>
Date: Sun, 30 Oct 2011 14:47:17 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Glen Zorn <gwz@net-zen.net>
References: <4EA4463B.6000304@cs.tcd.ie> <4EAC0DC0.1030107@gmail.com> <4EAC1364.3080309@cs.tcd.ie> <4EAD3ECE.5010207@net-zen.net>
In-Reply-To: <4EAD3ECE.5010207@net-zen.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 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: Sun, 30 Oct 2011 14:47:23 -0000

Hiya,

Coupla things below. But the immediate question is: can
you shoot out a revised ID before the cutoff? 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.

On 10/30/2011 12:10 PM, Glen Zorn wrote:
> On 10/29/2011 9:53 PM, Stephen Farrell wrote:
>>
>> Hi Glen,
>>
>> On 10/29/2011 03:29 PM, Glen Zorn wrote:
>>> On 10/23/2011 11:52 PM, Stephen Farrell wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I've had a look at this and have a couple of questions (below) I'd
>>>> like to chat about before mving this forward to IETF LC.
>>>>
>>>> I've also a couple of questions for which I'd be interested in
>>>> the answers and a load of nits, (in the attached file) but I'm
>>>> happy for all but the two below to be handled with any other IETF
>>>> LC feedback.
>>>>
>>>> So my questions:
>>>>
>>>> 1) I was hoping this document might help me understand ways in which
>>>> candidate access points might be identified.
>>>
>>> Sorry!
>>>
>>>> It didn't though.
>>>
>>> Nope.
>>>
>>>> Was it supposed to tell me that?
>>>
>>> Nope, that is specifically out of scope.
>>>
>>>> If not, then what would tell me that?
>>>
>>> Possibly one of the many documents available from the WiMAX Forum, 3GPP,
>>> 3GPP2, IEEE, etc.  That's why it was deemed out of scope: the whole CAP
>>> discovery&   selection thing is very specific to the lower layer in use.
>>>
>>>> (Maybe there is, or is not, a change needed for this, I don't know
>>>> yet.)
>>
>> Ok, thanks. It'd have helped me if it'd said that somewhere but if
>> you tell me that the real readership would know all that then I'm
>> ok with that.
>
> How about a sentence at the end of section 3 clarifying that?
>
> OLD:
>     This section investigates the design goals for the HOKEY
>     architecture.  These include reducing the signaling overhead for re-
>     authentication and early authentication, integrating local domain
>     name discovery, enabling fault-tolerant reauthentication and
>     improving deployment scalability.  These goals supplement those
>     discussed in Section 4 of RFC 5169 [RFC5169].
>
> NEW:
>     This section investigates the design goals for the HOKEY
>     architecture.  These include reducing the signaling overhead for re-
>     authentication and early authentication, integrating local domain
>     name discovery, enabling fault-tolerant reauthentication and
>     improving deployment scalability.  These goals supplement those
>     discussed in Section 4 of RFC 5169 [RFC5169].  Note that the
>     identification and selection of Candidate Access Points is
>     not a goal of the architecture, since those operations are generally
>     specific to the lower layer in use.

Thanks that works for me.

>>>> 2) Section 9 doesn't do it for me, sorry;-) Two possibilities -
>>>> either you argue convincingly that its ok as-is (in mail and then the
>>>> PROTO write up please) or else you try to address/reference generic
>>>> hokey security considerations.
>>>
>>> I think that it's pretty much OK as-is.
>>
>> Ok, so we're not in agreement here. But not that far apart either
>> maybe.
>>
>>>> I'd prefer the latter, as I'dk
>>>> otherwise expect the current empty section 9 to generate DISCUSSes if
>>>> nothing's done. The ones that occur to me that might not be elsewhere
>>>> would include: a) hokey implies moving more keys about in various new
>>>> ways, summarise the argument that none of these are leaking key bits,
>>>
>>> Actually, it does&   it doesn't: a couple of new keys are derived, but
>>> the way in which they are moved and the types of entities between which
>>> they are transferred are just the same as with regular old EAP: AAA,
>>> authenticators&   authentication servers.  Basically, if EAP/AAA is OK
>>> (which I admit is questionable) then hokey's OK, too.
>>
>> What's wrong with saying that in the sec. cons. of the document or
>> the PROTO write up? I think its a good thing to know and that the
>> architecture doc is a good place to tell the reader.
>
> I would prefer to put it in the PROTO write-up but I'll see if I can't
> find a reasonable way to get it into the SecCons, too.

Grand.

>>>> b) AAK seems to have a potential DoS if e.g.  someone causes AAK to
>>>> be done with loads of CAPs, or loads of AAK with one CAP, and maybe
>>>
>>> I need to think about this a bit: I'm pretty sure that that is the case
>>> w/regular EAP as well, but if I remember correctly 802.11 has a defense
>>> against that; since AAK doesn't have a L@ to rely upon for such things,
>>> maybe it should supply it.  Or maybe not.
>>
>> Ok. See below.
>>
>>>> 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;-)

>> Anyway, if you do think that's the case, this is also a good
>> thing to say in the document or PROTO write up.
>>
>>> I'm kind of opposed
>>> to solving all the world's problems here...
>>
>> Of course. Me too.
>>
>>>> There could also
>>>> be more of course, but that's what occurs to me. Note that I think a
>>>> sentence or two on each with a pointer to the RFC where its further
>>>> discussed would be fine if there's such an RFC.  (I think tihs does
>>>> need a change, and I'm reluctant to be convinced otherwise, but its
>>>> possible if you wanna try.)
>>>
>>> There you go ;-)
>>
>> How's about you add your reactions to a) and c) either to the
>> doc or PROTO write up and we treat b) along with any other IETF
>> LC feedback received?
>
> OK w/me.

Grand.

S.