Subject: Re: [drinks] Review of draft-ietf-drinks-spprov-07

From: Jean-Francois Mule <[email-masked]>
Date: Wed, 6 Jul 2011 11:31:25 -0600

Dean,

   Thank you for your comments.  See some of my inputs inline.

Jean-Francois.

On 05/25/2011 21:27, "Dean Willis" <[email-masked]> wrote:

[snip]
>As I seem to recall Sumanth asking me to do so, I've just done a read
>through of draft-ietf-drinks-spprov-07.
>
>It's a pretty solid document with a couple of nits that may need fixing.
>I'm also thinking that the security considerations and related discussion
>around authentication and authorization issues are a bit light and are
>likely to draw fire from the IESG.

Based on multiple vendor implementations of SPPP like protocols for the
same kind of data provisioning, we the authors had decided to leave each
Registry implementation free to choose whatever data authorization model
they wanted to implement on top of the data provisioning protocol.
Therefore, we pulled back from doing anything on how one client user gets
authorized to access some data or not.
All we say is that the protocol should provide the means for a user to
authenticate with the server.

>I'll discuss my points in the order I noted them while going through the
>document, since I'm too lazy to actually organize by priority or in any
>more meaningful way.
>
>4.1/4.2 NIT: We have some inconsistent capitalization oddities relating
>to words like "client", "server", "request" and "response", which are
>sometimes capitalized and sometimes aren't. There may be some sort of
>not-obvious--to-me rule in play about where they are being used as proper
>nouns vs. ordinary nouns, but it was a bit distracting and is likely to
>get changed by the RFC editor anyhow. I suggest quoting the word in its
>definition, then just using lower case everywhere else: For example, a
>"special term" may be defined in the text, but once it has been so
>defined, it's a just a special term.
fixed.

>4.4 Discusses authentication, which section 3.1 says is mostly out of
>scope for this document.
We think it is.

>However, there are some subtleties that it seems like the core spprov
>document needs to think about.  Is there a requirement for selective
>authorization? 
If you can authenticate a client based on some credentials, the server can
decide whether the client has access to these resources.  It is no
different that an HTTP client requesting access to a given URL with some
credentials and the HTTP server using its own data model to validate
whether or not data access can be granted.

>Given that SPPP intro and 3.2 seems to describe a registry as being
>provisioned by multiple SSPs, this could be important. Do we need  the
>request to model to 1) carry a subset specifier,
We had tried to model a Registrar ID rar in earlier versions of the
document.  We realized we could really do without this and implementers
did not want to carry that extra identifier in the msging.

>or 2) provision selective access capabilities?
It can be done with what we have.

>Do we need the response model to discuss authorization failures in a
>useful way, for example saying "This part of your request failed, but
>that part would have succeeded?"
I prefer the yes | no answer to an authorization failure.  Adding more
info only helps if you want the client to then replay some messages with
some deltas in the data being provisioned.

>Indeed, spprov 4.4 talks about "authentication of the Client by the
>Server is expected to be used to identify and further authorize the
>Client to certain resources on the Server." Does the protocol have a need
>to allow a client to specify which other clients can change the data it
>submitted?
This was the concept we had in Registrar Ids in the beginning.
See http://tools.ietf.org/wg/drinks/minutes?item=minutes80.html (section
2) for some of the discussions

>
>What is the relationship, if any, of the of orgId data element to
>authentication and authorization?
Depends on the registry implementation. In the protocol draft 07, the
orgId is for the registrant ID (entity that owns/serves these TNs/PUIs).
It could be that the registry implementation allows a tight coupling
between the registrant and registrar entities or that it allows them to be
decoupled and separate.

>
>
>4.5  Confidentiality and Integrity. Requirement for confidentiality and
>integrity protection is good, but "by providing encryption capabilities"
>is an unsatisfying follow-on, either insufficient to assure the
>requirements, or restrictive of techniques that might alternately assure
>confidentiality and integrity protection. Easiest fix is to truncate the
>sentence short of the quoted text. EKR has many times told me that
>encryption is not a magic hammer and that, in a requirements sentence,
>it's better to declare that which must be protected than to claim
>everything is fixed by encryption.
Fixed.
Truncated the sentence but added an example.