Last Call Review of draft-ietf-mile-rfc6046-bis-
review-ietf-mile-rfc6046-bis-secdir-lc-johansson-2012-01-23-00

Request Review of draft-ietf-mile-rfc6046-bis
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-01-17
Requested 2012-01-05
Draft last updated 2012-01-23
Completed reviews Genart Last Call review of -?? by Alexey Melnikov
Secdir Last Call review of -?? by Leif Johansson
Tsvdir Last Call review of -?? by Mark Allman
Assignment Reviewer Leif Johansson
State Completed
Review review-ietf-mile-rfc6046-bis-secdir-lc-johansson-2012-01-23
Review completed: 2012-01-23

Review
review-ietf-mile-rfc6046-bis-secdir-lc-johansson-2012-01-23

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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.

These document updates RFC6046 - Transport of Real-time Internetwork
Defense (RID) Messages over HTTP/TLS

This document defines HTTP/TLS as a transport for RID/IODEF messages
and is part of a joint update of RFC6046 and RFC6045.

In general I find the document clearly written. I have only a few
comments

- - The text on PKI requirements from RFC6045bis should be more clearly
and consistently referenced in RFC6046bis. In particular I found the
following somewhat confusing:

  "At minimum, each RID system MUST trust a set of X.509
   Issuer identities ("Certificate Authorities") [RFC5280] to directly
   authenticate RID system peers with which it is willing to exchange
   information, and/or a specific white list of X.509 Subject identities
   of RID system peers."

Does the "directly" mean that there should be no intermediary CAs? I
would move any discussion on the nature of the PKI beast to RFC6045bis
and reference it from here.

- - The RID-Callback-Token is underspecified, or I'm missing a reference
to where its defined.

I would have liked to see ABNF (yes I know its very simple), the
semantics for how the peer should act when receiving a callback token
(which may have expired, not point to anything useful, etc etc) some
advice on how to generate the tokens and a discussion (in the security
considerations!) on what can happen if you screw up and introduce
collisions.

	Cheers Leif
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - 

http://enigmail.mozdev.org/



iEYEARECAAYFAk8VbAcACgkQ8Jx8FtbMZncXtQCdH6EXyJxECGipAYbiSQvXSj8L
KxcAoKMQWwNgCubVfHR98jbhzOJPYrgQ
=KK6r
-----END PGP SIGNATURE-----