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

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 10 Aug 2009 09:49:02 -0700

I have reviewed this document as part of the security directorate's  
ongoing effort to review all IETF documents being processed by the  
IESG.  These comments were written primarily for the benefit of the  
security area directors.  Document editors and WG chairs should treat  
these comments just like any other last call comments.

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.  That is, the "analysis" appears to be  
limited to a particular concern.  Is this the only concern?
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).
Beyond this, I'm afraid I do not have sufficient experience in the key  
technologies to be able to determine if security considerations are  
well covered or not.
Regards, Kurt

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 10 Aug 2009 10:29:24 -0700

Kurt Zeilenga [mailto://[email-masked]] writes:

...

> material in an APP protocol.  

No.  AFAIK, the only existing protocols in which EAP key transport take
place are AAA.

> That is, the "analysis" appears to be
> limited to a particular concern.  

What the double quotes?

? Is this the only concern?

I would assume so; does that need to be spelled out?

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

> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 10 Aug 2009 11:33:34 -0700

> No.  AFAIK, the only existing protocols in which EAP key transport  

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

> I would assume so; does that need to be spelled out?

Not necessarily.

> 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.  I find  
statements such as:

	ERP security considerations are discussed in [RFCxxxx].  EAP security  
considerations are discussed in [RFCyyyy].

useful as they further encourage the reader to consider security  
considerations of key technologies.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 10 Aug 2009 18:23:30 -0700

> transporting EAP keying material using an AAA protocol".

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

...

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 10 Aug 2009 18:35:23 -0700

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

The following change would align the text of 6 with the content of its  
two subsections:

OLD:
NEW:

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

-- Kurt

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 10 Aug 2009 18:39:16 -0700

...

> distributing RK without peer consent.

Thanks!

---

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Tue, 11 Aug 2009 18:00:44 -0400

Hi Kurt,

Thank you for your comments.

I agree that the sentence in Section 6 is misleading and will make the
changes you proposed.

Best regards,
Katrin 

> -----Original Message-----
> From: Glen Zorn [mailto:[email-masked]]
> Sent: Monday, August 10, 2009 8:39 PM
> To: 'Kurt Zeilenga'
> Cc: [email-masked]; [email-masked]; draft-ietf-hokey-key-
> [email-masked]; [email-masked]
> Subject: RE: [secdir] SECDIR review of draft-ietf-hokey-key-mgm
>

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 11 Aug 2009 20:42:00 -0700

Hoeper Katrin-QWKN37 [mailto:[email-masked]] writes:

...

> > Thanks for pointing that out.  In fact, the document should _not_
> talk
> > about
> > EAP-Initiate and EAP-Finish messages are exchanged between the peer
> and
> > the
> > set"; unfortunately, this is impossible, since the peer and AAA
> server
> do
> > 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
> [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.

---

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Tue, 11 Aug 2009 18:27:14 -0400

Please find my reply to Glen's comments in-line.

Katrin

> Sent: Monday, August 10, 2009 8:24 PM
> To: 'Kurt Zeilenga'
><snip> 
and

---

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Wed, 12 Aug 2009 10:47:06 -0400

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

Best regards,
Katrin

> From: Glen Zorn [mailto:[email-masked]]
> Sent: Tuesday, August 11, 2009 10:42 PM
> To: Hoeper Katrin-QWKN37; 'Glen Zorn'; 'Kurt Zeilenga'
> [email-masked]
> > > the use of KDE in ERP, since it doesn't exist ;-).
Re-re-re-reading
> > ;-)
> > > the first EAP-Response   message from the peer".  This _should_
say "
> > In
> The problem is that RFC 5296 says to do things that just aren't
possible,
> so