Last Call Review of draft-ietf-regext-org-10
review-ietf-regext-org-10-secdir-lc-kaufman-2018-10-04-00

Request Review of draft-ietf-regext-org
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-10-08
Requested 2018-09-24
Other Reviews Genart Last Call review of -10 by Stewart Bryant (diff)
Review State Completed
Reviewer Charlie Kaufman
Review review-ietf-regext-org-10-secdir-lc-kaufman-2018-10-04
Posted at https://mailarchive.ietf.org/arch/msg/secdir/65YjYpaRZkz-fF1f0S_BFa6Ve5Q
Reviewed rev. 10 (document currently at 11)
Review result Has Nits
Draft last updated 2018-10-04
Review completed: 2018-10-04

Review
review-ietf-regext-org-10-secdir-lc-kaufman-2018-10-04

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 specification defines a syntax for extending the Extensible Provisioning Protocol (EPP) [RFC 5730] to support a new object type representing organizations. It does not change any aspect of the security of the protocol, and I believe it therefore does not require any sort of detailed security review.


There was one line that I found curious. It might be a typo, or there might be some arcane explanation:


The last paragraph of section 4.2 reads:

"Server operators SHOULD confirm that a client is authorized to perform a transform command on a given object. Any attempt to transform an object by an unauthorized client MUST be rejected, and the server MUST return a 2201 response code to the client to note that the client lacks privileges to execute the requested command."


Given that unauthorized requests MUST be rejected, it seems curious that server operators only SHOULD confirm that the requestor is authorized. I don't know how else the server operator could know to reject unauthorized requests. Perhaps this relates to the question of whether a queued request is rejected before it is queued or only as it is eventually processed.

But this is truly a nit, and even if wrong I don't believe it would ever cause an implementation to be incorrect.


 --Charlie