Re: Last Call: <draft-ietf-weirds-rdap-sec-04.txt> (Security Services for the Registration Data Access Protocol) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



At 16:06 15-07-2013, The IESG wrote:
The IESG has received a request from the Web Extensible Internet
Registration Data Service WG (weirds) to consider the following document:
- 'Security Services for the Registration Data Access Protocol'
  <draft-ietf-weirds-rdap-sec-04.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@xxxxxxxx mailing lists by 2013-07-29. Exceptionally, comments may be

According to Section 1, the Registration Data Access Protocol is a Lookup Format, JSON Responses and HTTP usage. This looks like a weird protocol to me. If the said protocol is HTTP + JSON (responses) it would be clearer to the reader to explain that in one specification. Section 1 mentions that:

  "One goal of RDAP is to provide security services that do not exist in
   the WHOIS"

I don't see how adding a fourth document helps to achieve that goal.

In Section 3.1:

  'To that end, RDAP clients and servers MUST implement the
   authentication framework specified in "HTTP Authentication:
   Basic and Digest Access Authentication" [RFC2617].'

This draft refers to the above authentication framework as the RDAP authentication framework. The draft then explains how the "basic" and "digest" schemes work. This is "how-to" stuff. The draft sets the following requirement:

  'If the "basic" scheme is used, HTTP Over TLS [RFC2818] MUST be used
   to protect the client's credentials from disclosure while in transit
  (see Section 3.4).'

If I understood correctly HTTPS is needed for security only if the "basic" scheme" is used.

  "RDAP SHOULD be capable of supporting future authentication methods
   defined for use with HTTP."

That sounds like a "SHOULD CONSIDER". Given how ill-defined the protocol is I doubt that the above is actionable.

In Section 3.1.1:

  "RDAP MAY include a federated authentication mechanism that permits
   a client to access multiple RDAP servers in the same federation
   with one credential."

Using an upper-case "may" does not bring much in terms of security. The draft takes the stance that security is an optional feature.

Section 3.1.1 looks like an executive summary for federated authentication.

In Section 3.3:

  "An RDAP service has to be available to be useful.  There are no RDAP-
   unique requirements to provide availability, but as a general
   security consideration a service operator needs to be aware of the
   issues associated with denial of service."

The text says that the service must be available to be useful and that there isn't any requirement for the service to be available.

In Section 3.4:

  "Web services such as RDAP commonly use HTTP Over TLS [RFC2818] to
   provide that protection by encrypting all traffic sent on the
   connection between client and server."

The above describes the protocol as a web service.

  "When this scheme is used, HTTP Over TLS MUST be used to protect the
   client's credentials from disclosure while in transit.'

The above repeats a "MUST" mentioned in a previous section.

In Section 5:

  "RDAP might need to be extended to provide this service in the future."

This does not look like a security consideration.

  "Code injection refers to adding code into a computer system
   or program to alter the course of execution."

I can only wonder about who is the target audience after reading the above.

The security considerations section seems like an attempt to write something about security as there isn't nothing to say about the protocol.

Overall, the draft does not look like a technical specification. It looks like the working group took FYI 36 as a template for designing a security service instead of thinking about security and designing a security service.

Regards,
-sm




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]