Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-01.txt

From: [email-masked]
Date: Mon, 26 Nov 2012 09:29:23 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF.

	Title           : Security Services for the Registration Data Access Protocol
	Author(s)       : Scott Hollenbeck
                          Ning Kong
	Filename        : draft-ietf-weirds-rdap-sec-01.txt
	Pages           : 9
	Date            : 2012-11-26

Abstract:
   The Registration Data Access Protocol (RDAP) provides "RESTful" web
   services to retrieve registration metadata from domain name and
   regional internet registries.  This document describes information
   security services, specific requirements for RDAP, and approaches to
   provide RDAP security services.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-weirds-rdap-sec-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-rdap-sec-01

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 26 Nov 2012 17:33:02 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Monday, November 26, 2012 12:29 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-01.txt
> 
> 

This version of the document has been edited extensively to include requirements and approaches to meet those requirements based on mailing list and in-room IETF-85 discussion. Please take a look and let me know if Ning and I missed something.

Scott

---

From: Edward Lewis <[email-masked]>
Date: Tue, 27 Nov 2012 14:31:49 -0500

Comments on:

> 	Filename   : draft-ietf-weirds-rdap-sec-01.txt

Item #1

This section 3.1 requirement isn't testable:

   REQUIREMENT: The RDAP authentication framework MUST be capable of
   supporting future authentication methods defined for use with HTTP.
In the sense that we can't know the future...

I wonder if there is another way to write this.  I'm taking a pot shot here in case I'm misinterpreting something...

The RDAP authentication framework MUST conform with the authentication methods and approach in use by HTTP in order to anticipate future improvements to HTTP authentication methods.

Item #2

Section 3.1.1, federated authentication, seems to be an ill-fit in a requirements document.  The possible approaches are fine descriptions as far as they go, but, they aren't requirements.  It's not bad to place hold them here until there's a document detailing a solution or a solution approach, but - well, they aren't requirements.

But it's the requirement that is there that seems flakey.  I understand the utility of a federated authentication model but don't see how it is germane to the definition of this protocol.  I mean - authentication is merely the task of proving I am who I claim to be.  If this is done via a trusted third party that is trusted by many servers (in the sense that there are clients, servers and third parties), that is fine.

It's a good discussion to have, but I don't see it as a requirement.  I can see 3.1.1. being labeled as a note on how to build the authentication system.

Item #3

In 3.2:

   REQUIREMENT: RDAP MUST include an authorization framework that is
   capable of providing granular (per registration data object) access
   controls according to the policies of the operator.

The granularity probably ought to be extended to the other side of the table - the actors.  I.e., per actor, not just per class of actor.  This is a suggestion, perhaps there's only a need for "anonymous" and "privileged" but I can see the latter quickly being subdivided into "law enforcement in the jurisdiction" and "sponsoring registrar" and "this registrant" classes...just to thrown down examples.

Item #4

In 3.4, another "future" requirement:

   REQUIREMENT: RDAP MUST be capable of supporting future data
   confidentiality methods defined for use with HTTP.
Perhaps what is needed is "sticking with the plan" so to speak of HTTP.

Item #5

Maybe it's just me...but when I think of security concerns there are lower-in-the-stack problems like message insertion and forgery.  Those things not a concern in here because we assume a transport better than unreliable datagram.  Perhaps it would be good to state the "floor" assumption that there's a stream based transport (TCP) and more involved.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.

---

From: "John Levine" <[email-masked]>
Date: 28 Nov 2012 03:41:58 -0000

>Section 3.1.1, federated authentication, seems to be an ill-fit in a requirements document. 
>The possible approaches are fine descriptions as far as they go, but, they aren't
>requirements.  It's not bad to place hold them here until there's a document detailing a
>solution or a solution approach, but - well, they aren't requirements.

I have to agree.  I'd just say something like the design MUST NOT do
anything to preclude federated authentication, e.g., credentials required
to be tied to the specific server.

>   controls according to the policies of the operator.

It seems to be an open question whether there will be a strict
hierarchy of credentials, so a level N+1 password provides everything
from level N plus other stuff, or whether there will be multiple
baskets and each password will provide access to some group of
baskets, or something else.  I don't see any need to try to answer it
here, because we can be sure that server operators will do whatever
works for them.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 29 Nov 2012 20:43:10 +0000

I'm going to ask Ning to talk to your comments on the federated authentication stuff in Item #2. I did some editing, but the spirit of the text is his. We'll work together to rework it.

Item #1, #4: Agreed, they can be reworded.

Item #3: So you're suggesting that we should include some sort of capability in the protocol to identify roles? Enumerating roles always leads to some that we miss, or that appear in the future, so I feel much better about leaving the responsibility of defining access controls to the server operator.

Item #5: Comments like this are always a little vexing. We've already established that we're using HTTP, so do we _really_ need to also state that we've got TCP and stream-based transport?

Scott

From: [email-masked] [mailto:[email-masked]] On Behalf Of Edward Lewis
Sent: Tuesday, November 27, 2012 2:32 PM
To: [email-masked]
Cc: Edward Lewis
Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-01.txt

Comments on:

On Nov 26, 2012, at 12:29, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:
          Title           : Security Services for the Registration Data Access Protocol
          Author(s)   : Scott Hollenbeck
                            Ning Kong
          Filename   : draft-ietf-weirds-rdap-sec-01.txt

Item #1

Item #2

Item #3

In 3.2:

Item #4

Item #5

---

From: Edward Lewis <[email-masked]>
Date: Thu, 29 Nov 2012 16:27:30 -0500

Regarding #3 - no, no need to try to identify the roles (via enumeration), just state that I should be able to say per object what can be seen per role.

E.g., ARIN might allow DMRs to see who is the registered DMR of another organization, whereas this would be not applicable to the non-member-having .com registry.  The requirement should give the capability to ARIN to designate per object what members could see, what a law enforcement agent (*) could see, etc  (* - who/what is a law enforcement agent aside, I'm just using that as the example most often tossed around)

Regarding #5 - from the charter:

The framework shall be for data to be delivered via a
    RESTful data service using HTTP (optionally using TLS), and may use
    standard features of HTTP to support differential service levels
    to different classes of user.

That's in the charter, I guess where I am missing the boat is that I don't see where the security draft says that the protocol will use HTTP.   I know that sounds stupid, but I see statements like "available to existing HTTP clients and servers" and "Web services commonly use HTTP Over TLS" in the draft, but never an explicit "this protocol will run over HTTP."  I kept taking the statements as a comparison, not as an indication this protocol will be over HTTP too.  I guess I just never found the "smoking gun" statement that this protocol will only ever exist over HTTP.  (Maybe it's in the two drafts in section 1.)

Maybe in Section 3:
RDAP itself does not include native security services.  Instead, RDAP
   relies on features that are available in other protocol layers to
   provide needed security services including authentication,
   authorization, availability, and data confidentiality.  
This is where it should be mentioned that RDAP will assume all of the security 'features' of HTTP(S), which rules out the stuff I'm generally afraid of (thanks to work with UDP-based protocols).

On Nov 29, 2012, at 15:43, Hollenbeck, Scott wrote:

> I’m going to ask Ning to talk to your comments on the federated authentication stuff in Item #2. I did some editing, but the spirit of the text is his. We’ll work together to rework it.
>  
> Item #3: So you’re suggesting that we should include some sort of capability in the protocol to identify roles? Enumerating roles always leads to some that we miss, or that appear in the future, so I feel much better about leaving the responsibility of defining access controls to the server operator.
>  
> Item #5: Comments like this are always a little vexing. We’ve already established that we’re using HTTP, so do we _really_ need to also state that we’ve got TCP and stream-based transport?
>  
> Scott
>  
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: Andy Newton <[email-masked]>
Date: Thu, 29 Nov 2012 22:04:04 +0000

From: Edward Lewis <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 29, 2012 4:27 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Edward Lewis <[email-masked]<mailto:[email-masked]>>
Subject: Re: [weirds] I-D Action: draft-ietf-weirds-rdap-sec-01.txt

E.g., ARIN might allow DMRs to see who is the registered DMR of another organization

Just for everyone's clarity, this is not a real use case. :)

-andy