Skip to main content

Last Call Review of draft-hollenbeck-rfc4933bis-

Request Review of draft-hollenbeck-rfc4933bis
Requested revision No specific revision (document currently at 02)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-05-28
Requested 2009-05-24
Authors Scott Hollenbeck
I-D last updated 2009-06-05
Completed reviews Secdir Last Call review of -?? by Sandra L. Murphy
Secdir Telechat review of -?? by Sandra L. Murphy
Assignment Reviewer Sandra L. Murphy
State Completed
Review review-hollenbeck-rfc4933bis-secdir-lc-murphy-2009-06-05
Completed 2009-06-05
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.

The draft updates RFC 4933, the EPP Contacts Mapping spec.  The updates 

listed are relatively minor - updates to references and a few minor 

updates to text.

Many of my comments below apply to language that was in RFC4933, but 

perhaps it is OK to suggest changes from the original at this point.

First:  EPP, as in RFC4930 and draft *-rfc4930bis-01*, employs a very 

simple authentication scheme that is cleartext password based. 

It therefore mandates:

                     Specifically, EPP instances MUST be protected using
   a transport mechanism or application protocol that provides
   integrity, confidentiality, and mutual strong client-server

This mandate is inherited by the rfc4933bis draft, which also says

             Both client and server MUST ensure that authorization
   information is stored and exchanged with high-grade encryption
   mechanisms to provide privacy services.

I would expect that this would make the protocol subject to channel 

binding issues.  I probably am not up on the whole idea, but the I 

reviewed RFC5060 and the description of the problem sure sounds like it 

applies to EPP as well.

OTOH, I seem to recall several drafts recently that relied on the security 

of their transport layers, and no one has been talking about how they deal 

with channel binding.  Maybe I'm way off.

Also, the security considerations there and in rfc4930bis do not address 

the cases when completion of a pending request is communicated by an 

out-of-band mechanism.  I don't know if there are security concerns for 

those notifications, but given that they are not covered by the security 

of the transport mechanism, advice would be good.

sect 2.2, page 5

   -  pendingCreate, pendingDelete, pendingRenew, pendingTransfer,

      A transform command has been processed for the object, but the
      action has not been completed by the server.  Server operators can
      delay action completion for a variety of reasons, such as to allow
      for human review or third-party action.  A transform command that
      is processed, but whose requested action is pending, is noted with
      response code 1001.

   When the requested action has been completed, the pendingCreate,
   pendingDelete, pendingTransfer, or pendingUpdate status value MUST be

Later, sect 3.3 page 27 says (indirectly) that the status MUST be set if 

the action is delayed:

             The status of the corresponding object MUST clearly reflect
   processing of the pending action.

If the MUST for removal is here, it would be good to be consistent and put 

the MUST for setting the status as well.  (As a matter of fact, it would 

be nice to mention the pending<action> status being set in the description 

of the transform commands as well.)

(By the way: why is a pendingRenew status defined when section 3.2 says 

there is no mapping defined for the Renew command?)

Same section, immediately following:

             All clients involved in the transaction MUST be notified
   using a service message that the action has been completed and that
   the status of the object has changed.

Later sections (p 17 sec 3.2 and p 28 sec 3.3) add qualifications to this 

MUST: "Other notification methods MAY be used" and "or by using an 

out-of-band mechanism."

sect 2.9, page 7

                               A server operator MUST reject any
   transaction that requests disclosure practices that do not conform to
   the announced data collection policy with a 2308 error response code.

When servers are compling with client specified exceptional disclosure 

handling for some data elements, does this same requirement apply, and 

with the same error code?

sect 3.1.2, page 14

The <info> response example contains:

   S:        <contact:voice x="1234">+1.7035555555</contact:voice>
   S:        <contact:fax>+1.7035555556</contact:fax>
   S:        <contact:disclose flag="0">
   S:          <contact:voice/>
   S:          <contact:email/>
   S:        </contact:disclose>

Section 2.9, page 7 says

                                 In conjunction with this disclosure
   requirement, this mapping includes data elements that allow a client
   to identify elements that require exceptional server operator
   handling to allow or restrict disclosure to third parties.

but then also

                                   A value of "false" or "0" (zero)
   notes a client preference to not allow disclosure of the specified
   elements as an exception to the stated data collection policy.

Between "require .. operator handling" and "client preference", I'm not 

sure of the obligation the server has to refrain from disclosing data 

elements that the client has requested be prohibited from disclosing

But at any rate, this example seems to me to be ignoring the client's 

request.  True?  If so, and allowed, it would deserve more discussion.

sect 3.2, page 17

   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.

Is that "MUST be rejected" only in the case that the server operator 

decides that they will confirm authorization?

sect 3.2.2, page 20

   A contact object SHOULD NOT be deleted if it is associated with other
   known objects.  An associated contact SHOULD NOT be deleted until
   associations with other known objects have been broken.  A server
   SHOULD notify clients that object relationships exist by sending a
   2305 error response code when a <delete> command is attempted and
   fails due to existing object relationships.

Do these object associations and object relationships include cases where 

the status is "clientDeleteProhibited" or "serverDeleteProhibited"?  If 

not, should there be this (or some other) error message in those status 

cases as well?  The prohibition status values don't seem to show up in the 

discussions of server response to commands.  Perhaps those prohibitions 

are covered under the "An EPP error response MUST be returned if the ... 

command cannot be processed for any reason".  I believe an explicit 

discussion would be good, including the appropriate error code.  (Same 

comment in the Transfer and Update commands.)

sect 3.2.5, page 24

   At least one <contact:add>, <contact:rem>, or <contact:chg> element
   MUST be provided if the command is not being extended.  All of these
   elements MAY be omitted if an <update> extension is present.  The
   <contact:add> and <contact:rem> elements contain the following child

   -  One or more <contact:status> elements that contain status values
      to be associated with or removed from the object.  When specifying
      a value to be removed, only the attribute value is significant;
      element text is not required to match a value for removal.

Who is responsible for ensuring the valid status combinations discussed in 

sect 2.2?  I.e., if the client is adding a prohibition, does the server 

remove the "ok" status or must the client include that removal in the 

update?  if the removal is in the same update, does the order in the 

update matter (removal first?)?

Note: the example adds a prohibition without removing an "ok" status, 

implying that the client is not responsible.  But it is not necessarily 

the case that the "ok" status was there, so the implication isn't certain.

sect 3.3, page 27

rfc4930bis says:

                                      The server MUST also notify the
   client when offline processing of the action has been completed.
   Object mappings SHOULD describe standard formats for notices that
   describe completion of offline processing.

Section 3.3 contains an example of the contents of the notification for a 

create command.  But Delete, Update and Transfer may also be pending. 

Should there be a description of their notification service messages also?