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

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.

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

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

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?

S.

>
>>
>> Cheers,
>> Stephen.
>>
>>
>>
>> _______________________________________________
>> HOKEY mailing list
>> HOKEY@ietf.org
>> https://www.ietf.org/mailman/listinfo/hokey
>
>