Last Call Review of draft-ietf-ecrit-additional-data-33
review-ietf-ecrit-additional-data-33-secdir-lc-nystrom-2015-09-03-00

Request Review of draft-ietf-ecrit-additional-data
Requested rev. no specific revision (document currently at 38)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-09-01
Requested 2015-08-13
Other Reviews Genart Last Call review of -33 by Francis Dupont (diff)
Genart Telechat review of -34 by Francis Dupont (diff)
Review State Completed
Reviewer Magnus Nystrom
Review review-ietf-ecrit-additional-data-33-secdir-lc-nystrom-2015-09-03
Posted at https://www.ietf.org/mail-archive/web/secdir/current/msg05982.html
Reviewed rev. 33 (document currently at 38)
Review result Has Issues
Last updated 2015-09-03

Review
review-ietf-ecrit-additional-data-33-secdir-lc-nystrom-2015-09-03

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.

This memo provides fundamental data structure definitions and procedural rules for providing auxiliary information to public service answering points (PSAPs) when emergency calls are being made.

This reads as an important memo and has been at least five years in the making. I don't find the Security (and Privacy) Considerations section lacking per se, but do have these questions:

- Why require HTTPS for the reference case but not the value case (I can understand why you don't require it for the value case, but couldn't it be a choice for the PSAP also in the reference case? This would also seem to simplify during an introductory phase when a wide-spread PKI solution is not yet in place.)?

- When HTTPS is required, I assume the PSAP needs a client certificate - i.e., that the mutual auth option of TLS is being used, perhaps this needs to be clarified?

- Was there any discussion around any MTI TLS cipher suites?

- I assume there's not only a privacy issue but also a potential spoofing issue - the PSAPs don't want to be overly susceptible to spoofed calls (although they rather err on the side of safety, of course. Thus, should integrity of infomation in the direct case be considered? I.e., by n/w or service providers in the path to the PSAP vouching for the information?

Thanks,

-- Magnus