Skip to main content

Last Call Review of draft-ietf-mpls-gach-adv-06
review-ietf-mpls-gach-adv-06-secdir-lc-johansson-2013-02-21-00

Request Review of draft-ietf-mpls-gach-adv
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-02-27
Requested 2013-02-14
Authors Dan Frost , Stewart Bryant , Matthew Bocci
I-D last updated 2013-02-21
Completed reviews Genart Last Call review of -06 by Martin Thomson (diff)
Genart Telechat review of -06 by Martin Thomson (diff)
Secdir Last Call review of -06 by Leif Johansson (diff)
Assignment Reviewer Leif Johansson
State Completed
Request Last Call review on draft-ietf-mpls-gach-adv by Security Area Directorate Assigned
Reviewed revision 06 (document currently at 08)
Result Has nits
Completed 2013-02-21
review-ietf-mpls-gach-adv-06-secdir-lc-johansson-2013-02-21-00
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 technology is somewhat outside my area of expertise but I found
the document relatively easy to follow anyway.

I'm a fan of writing crypto-related algorithms with very little left 
for the imagination of the reader. To that end I would strongly suggest 
specifying what goes into the GAP message hash even more clearly. 

In this case I suspect the intent is that the inner hash is over all 
bytes of GAP message except the GAP authentication TLV which is added 
to the message _after_ the hash is computed.

Conversely the validation phase needs to clearly say what bits of the
message are to be included in computing the hash.

Also I would change the timestamp verification step to use normative
language, eg: "... the receiver MUST, upon successfully authenticating
a message verify that the timestamp field corresponds... The receiver 
MUST silently discard a GAP message that fails timestamp verification."