Subject: [HOKEY] Comments on draft-ietf-hokey-erp-aak-02

From: Tom Taylor <[email-masked]>
Date: Tue, 06 Jul 2010 22:34:11 -0400

Hi, I've just been reading the draft and I thought you might like to fix a few 
nits.

1. Is "authenticator" the right term, in the Abstract? Or should it be 
"attachment point"?

2. Figure 1, actions in the EA Server box include: "EE keying materials 
dervied". I assume that should be "EA ...".

3. Second-last paragraph of section 3, last sentence currently reads:
    " . . . the ERP/AAK server should determine
    each CA whether accepts the pMSK and whether the peer could be
    attached to."
That would read a little better with a few more words:
    " . . . the ERP/AAK server should determine
    whether each CA accepts the pMSK and whether the peer is allowed to
    attached to it."
I may have misunderstood your intention with the word "allowed". Perhaps you 
meant "able to attach to it".

4. Next paragraph: I suggest "To finish" instead of "At last", and "accessible" 
instead of "determinate".

5. Flag E has moved between Figure 4 and Figure 5. I don't think that would 
parse correctly unless Code is different between the two messages. Aside from 
that, you show two more flags (R, L) in Figure 5 but don't explain them.

More tomorrow, I didn't get much sleep last night.

Tom Taylor

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 7 Jul 2010 12:24:58 +0700

> 1. Is "authenticator" the right term, in the Abstract? Or should it be

Since we're talking about ERP & RFC 5296 uses the term "authenticator", I think that that is correct in this context.

> dervied". I assume that should be "EA ...".

OK

> meant "able to attach to it".

I'm not really willing to wordsmith this unless/until it's clear that it is even possible w/o unholy layer violations ;-).

> instead of "determinate".

Ditto.

> that, you show two more flags (R, L) in Figure 5 but don't explain them.

The flags are taken from the definitions of the corresponding packets in RFC 5296; EAP-Initiate/Re-auth-Start messages can be distinguished from the other two message types using the 'Type' field.  You raise a good point, though: the document is inconsistent about what is (implicitly) imported from RFC 5296 and what is explicitly discussed.  For example, the cryptosuites defined for ERP/AAK are identical to those used in ERP but they are explicitly called out...