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

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

> I'd prefer the latter, as I'd
> 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.

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

> 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.  I'm kind of opposed
to solving all the world's problems here...

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

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