Re: [secdir] Secdir review of draft-ietf-regext-10

["Linlin Zhou" <[e-mail]>]

Hi Charlie,

Thanks for your review.

Maybe I can give some arcane explanations for these words.

According to RFC5730, EPP can use authentication information associated with objects to confirm object-transfer authority. With an <obj:authInfo> element, the server operators can confirm the authorized or unauthorized requests.

The original design of this draft has <org:authInfo> that is associated with org object to facilitate transfer operations. After some discussions, this element was removed for some reason in the XML schema and element descriptions. Given that the element was removed, it is indeed inappropriate to have these words here to make readers confused. It is our neglect. So we suggest deleting these words.

 

Regards,

Linlin


-----原始邮件-----
发件人:"Charlie Kaufman" <[e-mail]>
发送时间:2018-10-03 12:01:25 (星期三)
收件人: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
抄送:
主题: Secdir review of draft-ietf-regext-10



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