Re: [secdir] SECDIR review of draft-ietf-hokey-key-mgm

["Glen Zorn" <[e-mail]>]

Kurt Zeilenga [mailto:[e-mail]] writes:

> On Aug 10, 2009, at 10:29 AM, Glen Zorn wrote:
> 
> > Kurt Zeilenga [mailto://[e-mail]] writes:
> >
> > ...
> >
> >> The security consideration starts by saying:
> >>    This section provides security requirements and an analysis on
> >> transporting EAP keying material using an AAA protocol.
> >> While 6.1 appears to provide the former, 6.2 (the remaining section)
> >> seems to discuss a particular concern in transporting EAP keying
> >> material in an APP protocol.
> >
> > No.  AFAIK, the only existing protocols in which EAP key transport
> > take
> > place are AAA.
> 
> My point that Section 6 description of what section 6.2 provides seems
> not equate (to me) to what 6.2 actually provides.  6.2 seems to
> discuss a particular issue in "transporting EAP keying material using
> an AAA protocol" as opposed to a more comprehensive "analysis on
> transporting EAP keying material using an AAA protocol".

OK.  Can you be a little more specific about what needs to be changed?  

...

> >> I would like to see the Security Consideration section to
> incorporate
> >> by informative references general discussions of security
> >> considerations for key technologies (e.g., EAP).
> >
> > Why?  The EAP (or ERP) authentication is by definition complete by
> > the time
> > any keys are exported by the EAP method, so it's hard to see how
> those
> > considerations are relevant.
> 
> As the document discusses use of KDE in ERP, it would seem to me that
> ERP security considerations would have some relevance.  

Thanks for pointing that out.  In fact, the document should _not_ talk about
the use of KDE in ERP, since it doesn't exist ;-).  Re-re-re-reading ;-)
section 6 (which is what I think you are talking about?), I noticed
A couple of other errors, too.  For example, section 3 says "Here,
EAP-Initiate and EAP-Finish messages are exchanged between the peer and the
home AAA server, with the bootstrapping flag in the EAP-Initiate message
set"; unfortunately, this is impossible, since the peer and AAA server do
not speak the same protocol.  Another example of the same kind of fuzzy
writing is in the second paragraph of the same section: "In this case, the
local ER server requesting the DSRK MUST include a KDE-Request message in
the first EAP-Response   message from the peer".  This _should_ say " In
this case, the local ER server requesting the DSRK MUST include a
KDE-Request message in the AAA packet encapsulating the first EAP-Response
message from the peer" in order to agree with RFC 5296 (in fact, though,
there's no need for the local ERP server to be involved in this at all,
except that that is (erroneously, I think) specified in 5296).
        
...