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

[Stephen Farrell <[e-mail]>]

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. It didn't though. Was it
supposed to tell me that?  If not, then what would tell me that?
(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'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,
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
c) if someone chooses the wrong CAP then they might have been fooled
into sending all the user's traffic via a bad actor. 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.)

Cheers,
Stephen.