Re: [secdir] review of draft-hollenbeck-rfc4933bis-01

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: Sandra Murphy [mailto:[e-mail]] 
> Sent: Thursday, June 04, 2009 2:43 PM
> To: [e-mail]; [e-mail]; Hollenbeck, Scott
> Subject: review of draft-hollenbeck-rfc4933bis-01
> 
> 
> 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
>     authentication.
> 
> 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.

I would need more specific information to know if there's something to
be done with this comment.  Reliance on security mechanisms provided at
the transport layer has been part of this specification since day one.
I am not aware of any implementation issues.

> 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.

What about adding something like this to the Security Considerations
section of 4930bis:

"As described in Section 2, EPP includes features that allow for offline
review of transform commands before the requested action is actually
completed.  The server is required to notify the client when offline
processing of the action has been completed. Notifications can be sent
using an out-of-band mechanism that is not protected by the mechanism
used to provide EPP transport security.  Notifications sent without
EPP's transport security services should be protected using another
mechanism that provides an appropriate level of protection for the
notification."

> sect 2.2, page 5
> 
>     -  pendingCreate, pendingDelete, pendingRenew, pendingTransfer,
>        pendingUpdate
> 
>        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
>     removed.
> 
> 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.)

Maybe, but this hasn't been an issue for implementers.  I'd prefer to
leave the text as-is, particularly given that changing it here would
make it inconsistent with the other documents in the series.

> (By the way: why is a pendingRenew status defined when 
> section 3.2 says there is no mapping defined for the Renew command?)

That's a good catch!  pendingRenew should be removed.

> 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."

The situations are different.  The text in section 2.2 describes a
specific requirement for notification when a status value is changed.
The later sections address notification mechanisms for completion of
offline processing.

> 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?

Yes.  If the client asks the server to do something outside the stated
policy, a 2308 response would be appropriate.

> 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.

Not true, because the response is being sent to a client that is
authorized ("Example <info> response for an authorized client") to see
the full data record.  The response would be different if the query were
performed by a client that isn't authorized to see the full record.

> 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?

Yes.  That's why the MUST refers to an "unauthorized client".

> 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.)

No, this text refers to relationships where a contact is associated
with, for example, a domain object.  The 2304 response code is used to
identify a failure due to a status constraint.

> 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
>     elements:
> 
>     -  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.

The server implementation is responsible for validating status
combinations.

> 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?

I don't think so, because elsewhere in the spec it states that the
format of the messages is outside the scope of the spec.

> --Sandy
>