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

[Glen Zorn <[e-mail]>]

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.

> 
>>> 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.

> 
>>> 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).

> 
> 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.

...