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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 5 Aug 2013 10:36:14 -0700

Hi SM, thanks for your comments.  I'm shepherding the document, so replies
inline:

On Wed, Jul 24, 2013 at 12:21 PM, SM <[email-masked]> wrote:

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

RDAP is far from the first protocol specification to exist across multiple
RFCs, so this approach isn't uncommon.  That said, I take it you believe
the material here should be rolled into one of the other documents?

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

Correct, that's what it says.

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

You said two important things here:

1) Can you please elaborate on why you think this is "ill-defined" and, if
possible, how this could be remedied?

2) Insofar as this draft amounts to a requirements document, I take "SHOULD
be capable" to mean the actual implementation needs to have hooks for the
stated capability, or have a very good reason for not providing those hooks
(e.g., the same capability is available some other way).

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

More precisely, the draft takes the stance that federated authentication is
an option.  The working group doesn't feel the need to elevate this to
SHOULD or MUST, likely because operators might not be compelled to federate
themselves with anyone for whatever local security or privacy reasons apply.

>
> Section 3.1.1 looks like an executive summary for federated authentication.
>

Right, and the benefits it provides in the context of RDAP.  Is that a
criticism or an observation?  What do you suggest?

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

The next sentence (which you omitted) provides the context.  Operators are
advised to be aware of denial-of-service considerations, and there's a
document referenced that provides useful information.  Depending on the
uptake of RDAP and the other services that begin to depend upon it, it
might become a DoS target.  Hardening against such attacks will be
important to begin with, but might become critical later.  I think this is
not a waste of space.

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

It is a web service, in as much as it uses web protocols.  Is there some
improvement you'd like to suggest?

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

True, this can be fixed by replacing it with a reference to Section 3.1.

>
> In Section 5:
>
>   "RDAP might need to be extended to provide this service in the future."
>
> This does not look like a security consideration.
>

Non-repudiation (which is the context of the paragraph from which that
sentence was taken) is one of the classic properties of security, so I
don't agree.  It's useful to point out to the reader that non-repudiation
is not provided by any of the capabilities discussed here, and its absence
might be conspicuous.

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

It's true that the specific things called out in that paragraph are not
specific to RDAP, but rather to anything built atop HTTP.  Do you suggest
something else, perhaps something more general like a statement that any
known HTTP-based attack might also affect an RDAP service?

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

SecDir often scratches its head when a document says very little, so what
you're saying is often the case.  However, sometimes it's enough to say
"This is built on top of HTTP, so all the security issues known about HTTP
and HTTPS also apply here."  Do you have a specific suggestion?

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

That seems a little sharp.

This draft is manifestly not a technical specification insofar as it does
not define a new protocol.  I would say it's partly a requirements document
and partly an applicability statement, and the latter at least is normally
a standards track document.

I don't know what "thinking about security" we are expected to do beyond
making use of the security services that have already been made available
to applications built atop HTTP.  Do you have any specific suggestions?

-MSK

---

From: SM <[email-masked]>
Date: Tue, 13 Aug 2013 05:06:22 -0700

Hi Murray,
At 10:36 AM 8/5/2013, Murray S. Kucherawy wrote:
>RDAP is far from the first protocol specification to exist across 
>multiple RFCs, so this approach isn't uncommon.  That said, I take 
>it you believe the material here should be rolled into one of the 
>other documents?

Yes.

>That sounds like a "SHOULD CONSIDER".  Given how ill-defined the 
>protocol is I doubt that the above is actionable.
>
>
>1) Can you please elaborate on why you think this is "ill-defined" 
>and, if possible, how this could be remedied?

It's difficult to understand what RDAP is as it is not clearly 
defined.  That is what I meant by "ill-defined".  In the above 
example, the "SHOULD" does not specify anything.  It  looks like a 
"forward-looking statement" as the "future authentication methods" are unknown.

I would look at the specification in terms of what is required to 
achieve interoperability now instead of trying to define future 
needs.  In terms of protocol it would be what the two sides have to 
do to talk to each other.  One of the issues in MILE what that there 
wasn't a clear separation of the HTTP aspect and the MILE aspect.  In 
simple terms it is better not to redefine how HTTP works; i.e. a 404 
is a 404 instead of a contextual meaning of that code.

>2) Insofar as this draft amounts to a requirements document, I take 
>"SHOULD be capable" to mean the actual implementation needs to have 
>hooks for the stated capability, or have a very good reason for not 
>providing those hooks (e.g., the same capability is available some other way).

The draft is intended as a proposed standard.  In my opinion that is 
different from a requirements document.   The usage of SHOULD does 
not make it implementable.  It is like using SHOULD to beat people up 
if they do not implement some future capability. :-)

>More precisely, the draft takes the stance that federated 
>authentication is an option.  The working group doesn't feel the 
>need to elevate this to SHOULD or MUST, likely because operators 
>might not be compelled to federate themselves with anyone for 
>whatever local security or privacy reasons apply.

I mean that the draft does not contain any security feature which is 
mandatory to implement.

>Right, and the benefits it provides in the context of RDAP.  Is that 
>a criticism or an observation?  What do you suggest?

I don't think that the executive summary provides much value.  I 
suggest dropping the tutorial material. :-)

>The next sentence (which you omitted) provides the 
>context.  Operators are advised to be aware of denial-of-service 
>considerations, and there's a document referenced that provides 
>useful information.  Depending on the uptake of RDAP and the other 
>services that begin to depend upon it, it might become a DoS 
>target.  Hardening against such attacks will be important to begin 
>with, but might become critical later.  I think this is not a waste of space.

Ok.

>It is a web service, in as much as it uses web protocols.  Is there 
>some improvement you'd like to suggest?

The approach taken can create interoperability issues.  I would look 
at this in terms of what the codes has to do.

>Non-repudiation (which is the context of the paragraph from which 
>that sentence was taken) is one of the classic properties of 
>security, so I don't agree.  It's useful to point out to the reader 
>that non-repudiation is not provided by any of the capabilities 
>discussed here, and its absence might be conspicuous.

This draft looks like a tutorial for the not-well-informed. 
:-)  There is likely some BCP which already discusses about non-repudiation.

>It's true that the specific things called out in that paragraph are 
>not specific to RDAP, but rather to anything built atop HTTP.  Do 
>you suggest something else, perhaps something more general like a 
>statement that any known HTTP-based attack might also affect an RDAP service?

I would use that as the starting point and then discuss attacks which 
are specific to the service.

>SecDir often scratches its head when a document says very little, so 
>what you're saying is often the case.  However, sometimes it's 
>enough to say "This is built on top of HTTP, so all the security 
>issues known about HTTP and HTTPS also apply here."  Do you have a 
>specific suggestion?

It would be better to point to the relevant sections if the objective 
is to help the reader identify relevant issues.

>That seems a little sharp.

The comments were strong. :-(

>This draft is manifestly not a technical specification insofar as it 
>does not define a new protocol.  I would say it's partly a 
>requirements document and partly an applicability statement, and the 
>latter at least is normally a standards track document.

I personally think that there is a lack of understanding of what an 
applicability statement is.  I commented on the draft from a 
technical specification angle.

>I don't know what "thinking about security" we are expected to do 
>beyond making use of the security services that have already been 
>made available to applications built atop HTTP.  Do you have any 
>specific suggestions?

It is a lot of work to explain or suggest text.  It's not worth 
putting in the effort if the working group believes that the draft is okay.

Regards,
-sm