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.
- [HOKEY] AD review of draft-ietf-hokey-arch-design Stephen Farrell
- Re: [HOKEY] AD review of draft-ietf-hokey-arch-de… Glen Zorn
- Re: [HOKEY] AD review of draft-ietf-hokey-arch-de… Stephen Farrell
- Re: [HOKEY] AD review of draft-ietf-hokey-arch-de… Glen Zorn
- Re: [HOKEY] AD review of draft-ietf-hokey-arch-de… Stephen Farrell
- Re: [HOKEY] AD review of draft-ietf-hokey-arch-de… Glen Zorn
- Re: [HOKEY] AD review of draft-ietf-hokey-arch-de… Stephen Farrell
- Re: [HOKEY] AD review of draft-ietf-hokey-arch-de… Glen Zorn
- Re: [HOKEY] AD review of draft-ietf-hokey-arch-de… Glen Zorn