Skip to main content

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 revision No specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-10-08
Requested 2018-09-24
Authors Linlin Zhou , Ning Kong , Guiqing Zhou , Jiankang Yao , James Gould
Draft last updated 2018-10-04
Completed reviews Secdir Last Call review of -10 by Charlie Kaufman (diff)
Genart Last Call review of -10 by Stewart Bryant (diff)
Opsdir Last Call review of -11 by Jürgen Schönwälder (diff)
Genart Telechat review of -11 by Stewart Bryant (diff)
Assignment Reviewer Charlie Kaufman
State Completed
Review review-ietf-regext-org-10-secdir-lc-kaufman-2018-10-04
Reviewed revision 10 (document currently at 12)
Result Has Nits
Completed 2018-10-04
review-ietf-regext-org-10-secdir-lc-kaufman-2018-10-04-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.

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