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

["Hoeper Katrin-QWKN37" <[e-mail]>]

To sum up the previous discussion, here my proposed 3 changes to
draft-ietf-hokey-key-mgm-09.txt to address Kurt's and Glen's comments.
Please let me know if the changes are sufficient.

1.
OLD (Section 5, second paragraph)
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.

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

2.
OLD (Section 5, third paragraph)
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. In this case, the local ER server (acting as
KRS) MUST include a KDE-Request message in the AAA message that carries
an EAP-Initiate message with the bootstrapping flag turned on.  

NEW 
Here, the peer sends an EAP-Initiate message with the bootstrapping flag
turned on. The local ER server (acting as KRS) MUST include a
KDE-Request message in the AAA message that carries the peer's
EAP-Initiate message and sends it to the peer's home AAA server.

3.
OLD (Section 6, first paragraph) 
This section provides security requirements and an analysis on
transporting EAP keying material using an AAA protocol.

NEW
This section provides security requirements and a discussion of
distributing RK without peer consent.

Best regards,
Katrin


> -----Original Message-----
> From: Glen Zorn [mailto:[e-mail]]
> Sent: Tuesday, August 11, 2009 10:42 PM
> To: Hoeper Katrin-QWKN37; 'Glen Zorn'; 'Kurt Zeilenga'
> Cc: [e-mail]; [e-mail]; draft-ietf-hokey-key-
> [e-mail]
> Subject: RE: [secdir] SECDIR review of draft-ietf-hokey-key-mgm
> 
> Hoeper Katrin-QWKN37 [mailto:[e-mail]] writes:
> 
> ...
> 
> > > 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).
> > >
> > > ...
> > >
> > [KH] Glen, I think you are talking about Section 5 not 3, are you
> > looking at the current version
> >
(http://ietfreport.isoc.org/all-ids/draft-ietf-hokey-key-mgm-09.txt)?
> >
> > Could you please re-check? I am sure your comments still apply, but
I'd
> > like to know which parts are affected.
> 
> Yes, you're right.  I really hate it when people change documents in
the
> middle of reviews. It's really annoying, especially since I just did
it
> myself a couple of days ago ;-).
> 
> >
> > AFAIK, Section 5 is in complete alignment with RFC 5296 and uses the
> > same terminology and same protocol description. I understand that
there
> > are some problems in RFC 5296 and there is a request for errata
> > (http://www.rfc-editor.org/errata_search.php?rfc=5296&eid=1825).
> >
> > Should I wait until this (and possibly other) errata has been
approved
> > and then modify the key management draft accordingly? If I make
changes
> > now, with the current RFC 5296, we would have a description on how
to
> > use KDE with ERP that does not match the description in RFC 5296.
> 
> The problem is that RFC 5296 says to do things that just aren't
possible,
> so
> we have a situation where we can either continue to create incorrect
> specifications or correctly specify behavior that contradicts a
published
> RFC.  Personally, I'd go for the latter: change the draft to specify
what
> the authors of 5296 obviously _meant_ to say & update 5296 later.