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

From: Stephen Farrell <[email-masked]>
Date: Sun, 23 Oct 2011 17:52:11 +0100

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.

---

From: Glen Zorn <[email-masked]>
Date: Sat, 29 Oct 2011 21:29:20 +0700

On 10/23/2011 11:52 PM, Stephen Farrell wrote:
> 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.

> hokey security considerations.  

I think that it's pretty much OK as-is.

> I'd prefer the latter, as I'd

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.

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

> 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

There you go ;-)

> 
> Cheers,
> Stephen.
> 
> 
> 
> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hokey

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 29 Oct 2011 15:53:24 +0100

Hi Glen,

On 10/29/2011 03:29 PM, Glen Zorn wrote:
> discovery&  selection thing is very specific to the lower layer in use.
>

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.

> 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
> Actually, it does&  it doesn't: a couple of new keys are derived, but
> authenticators&  authentication servers.  Basically, if EAP/AAA is OK

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.

> maybe it should supply it.  Or maybe not.

Ok. See below.

> 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

Of course. Me too.

>> possible if you wanna try.)

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.

---

From: Glen Zorn <[email-masked]>
Date: Sat, 29 Oct 2011 22:25:38 +0700

(pasted from the attachment)

> not quite nits:
>
> - I realise that this document references lots of others that define
> things, but a bit of ascii art at the start would have been helpful.
> Its not obvious where e.g. the "ER server" might live from the
> current text.

Actually I removed the ASCII art that was there because I thought that
it was way confusing.  I suppose that it can be put back.

> - p16, I don't get 6.4 really - why is inter-technology the same as
> intra-domain?

I guess that in the case of hokey, it's because we never defined an
authentication protocol for the inter-domain case (ERP is strictly for
intra-domain re-authentication). So, for hokey, inter-technology _is_
intra-domain.

> nits:
>
> - p5, "For the purpose of this draft" is wrong. s/draft/memo/?

OK.

> - p5, "All three mechanisms..." This description is a bit confusing,
> since there are many RFCs referenced.  I think it'd be improved if
> you listed the three mechanisms as bullets.

How's this:

   All three early authentication mechanisms provide means to securely
   establish authenticated keying material on a Candidate Access Point
   (CAP) while still being connected to the Serving Access Point (SAP)
   but vary in their respective system assumptions and communication
   paths.

> - p5, ER is used as an acronym - expand on 1st use as well as in
> section 2 would be better

OK

> - p6, s/can be integrated/whether or not it can be integrated/?

How's this:

   However, it is currently unclear how
   the necessary handover infrastructure can be deployed and
   integrated into existing EAP infrastructures.

Although I think that this is really a non-issue, as far as the IETF is
concerned: every deployment will be different; as long as we don't
inadvertently (or purposely, for that matter) outlaw a reasonable design
I think that we're fine.

> - p7 - cute that you reference 2119 anyway:-) I wonder if this is its
> first informative reference?

Maybe ;-).  I hate to miss a chance to annoy the idnits robot, but maybe
just lose the reference?

> - p7, What is a re-authenticaiton root key? (3.2) I see its defined
> in 5296 but wouldn't it be ok to just say "required keys" here - do
> you *need* to be so precise?

I don't think so.

> If so, then maybe add a ref to 5296 to
> help point the reader to the right place?

> - p8 - what is a "HOKEY server"?

I think that it is generic term for a server supporting hand-over keying
-- could be a ER server or an AAK server, for example.

> should that be in the terminology
> section?

Since it seems to appear only once, maybe we could just try to rephrase
the sentence?

> - p8, 1st para of 4.1 just confuses me - is it needed really?  Maybe
> you could lose that and just s/subsystem/subsystem provided by HOKEY/
> in the next para and that'd be good enough?

Works for me.

> (If you do keep the
> current text, I also wonder if the "This section" at the start refers
> to setction 4 generally or 4.1 only? As-is its a little ambiguous
> looking.)

> - p9, end of page - Got any references to that work in progress?

I think that that is RFC 5296bis, so yes.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 29 Oct 2011 16:41:54 +0100

Hi Glen,

Those all look fine and are changes that can IMO be made before
or after IETF LC. (Once we bottom out on handling the comment
from the other mail, then that'll tell me whether this should
go revised ID needed or to IETF LC.)

I'd keep the idnits-robot-annoying reference myself, but
whatever:-)

S.

---

From: Glen Zorn <[email-masked]>
Date: Sun, 30 Oct 2011 19:10:54 +0700

> you tell me that the real readership would know all that then I'm

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.

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

> authenticated the CAP? Is that really the same as any old

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

> doc or PROTO write up and we treat b) along with any other IETF

OK w/me.

...

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 30 Oct 2011 14:47:17 +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.

>     specific to the lower layer in use.

Thanks that works for me.

> find a reasonable way to get it into the SecCons, too.

Grand.

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

>> doc or PROTO write up and we treat b) along with any other IETF

Grand.

S.

---

From: Glen Zorn <[email-masked]>
Date: Mon, 31 Oct 2011 12:43:15 +0700

On 10/30/2011 9:47 PM, Stephen Farrell wrote:
> you shoot out a revised ID before the cutoff? 

Yes, though it may not have everything we've discussed in it (I have to
get on a plane in about 5 hours).

> If so, then

...

> Does that make sense? (I'm not 100% sure it does, mind you;-)

The part I'm not getting is how AAK "implicitly authenticates the
CAP/SAP" any more than the possession of a valid MSK authenticates a
regular AP w/regular EAP.

...

---

From: Glen Zorn <[email-masked]>
Date: Mon, 31 Oct 2011 13:10:05 +0700

> it was way confusing.  I suppose that it can be put back.

Looking again at the ASCII art I removed, it doesn't appear to me to be
what you're asking for anyway; it it's necessary, it will take awhile
(i.e., > 1 hour to do...

...

> Since it seems to appear only once, maybe we could just try to rephrase

Here's a first cut:

OLD:
   To provide better deployment scalability, there should be no
   requirement for co-location of the HOKEY server and AAA servers or
   proxies.  Separation of these entities may cause problems with
   routing, but allows flexibility in deployment and implementation.

NEW:
   To provide better deployment scalability, there should be no
   requirement for co-location of entities proving handover keying
   services (e.g., ER servers) and AAA servers or proxies.  Separation
   of these entities may cause problems with routing, but allows greater
   flexibility in deployment and implementation.

...