Subject: [weirds] Kathleen Moriarty's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS and COMMENT)

From: "Kathleen Moriarty" <[email-masked]>
Date: Wed, 29 Oct 2014 18:00:44 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-weirds-rdap-sec-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for your work on this draft and improving security for the whois
function in weirds.  There are a lot of options now and the work is
appreciated.  I have a lot of comments and suggestions that should be
pretty easy to resolve.  You may find a discuss and comment on the same
section, so I've tried to label the start of each item with the draft
section numbers.

Section 3.1
Could you also include a reference to RFC5280?  If the use of PKI and CAs
is listed, a pointer to the security considerations would be very helpful
to the reader.  The pointer should be to the full draft, not just the
security consideration section as it covers important things like the
need for path validation.  Path validation includes checking the
certificate validity, the path/chain (root is trusted), etc.  I'm not
looking for you to add much text, just to punt off to the existing
documents if people are interested in the security behind these
recommendations for federation, authentication, authorization, etc.

Section 3.2
Could you expand on the details here a bit?  Between this draft and the
response draft, I don't see enough information or guidance on how one
might leverage value settings on objects and what are the right actions
to take based on those values.   My discuss on the response draft is
specific to that draft, but the same concept applies here.  If the
guidance belongs in the response draft, then recommended actions or a
list of options if it varies from administrator to administrator would be
helpful at the start of the sections that provide the lists of values
that can be set on objects.

This section of the sec draft should then reference the response draft
letting the reader know where to look for authorization and access
control options and guidelines.

Section 3.4
Since the protocol allows for the use of values to mark objects as
private, obscured, redacted, this should be mentioned in this section
with a pointer to the response draft section 10.2.2 and the recommended
actions in the (hopefully) updated Privacy Considerations section of that
draft.  For confidentially, leaving out the data with the "redacted"
value set if possible will do a lot more than trying to protect it with
TLS, so I think it's important to note that in this section.  The
"private" value should limit access (I'd like to see some mention of how
that is accomplished, but probably in the Response draft).  The
"obscured" value is interesting, but since it is only obscured, it may to
be the best option for confidentially protection.

Possible new section for Access Controls - 
Since user based access is possible, I'd like to see a section added to
cover that as well.  Is access tied to the roles designated in 10.2.4 of
the Response draft?  Should it be?  Having the combination of user roles
and data object values gives a lot of flexibility, but that is talked
about enough in the drafts (IMO).

Security consideration section:
It's good that you are recommending against use of the Null cipher, but
could you add a reference to the UTA TLS best practices draft here as
well?  That will cover quite a few bases with out having to repeat stuff
here. 
https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support Alissa's discuss for a privacy threat model.

Section 3.1
As an FYI (not asking for anything to be done here except to participate
in HTTPAuth last calls) - HTTP Digest and Basic just went through a
revision and are just about done.  There are a few minor updates and the
security considerations in the updated documents spell out the remaining
issues.  Although these are the solutions for HTTP Auth, most people
don't rely on it and use other methods, so we don't have implementations
of better options.  There are a few other options in the HTTPAuth WG
about to go to IETF last call or are WG drafts.  If you are going to rely
on HTTPAuth methods, maybe there should be a push for the improved
options from the WEIRDS WG - at least pitching in to review during last
calls.  
https://datatracker.ietf.org/wg/httpauth/documents/

Section 3.1
I'm a little uneasy with just having a pointer to TLS to fix everything
in OAuth and OpenID.  Could you put in pointers to main framework
documents like RFC6749 with a statement that says security considerations
are included in those drafts?  The security considerations differ between
token types (bearer vs. Holder of Key) and that is out-of scope for this
draft, so punting to the OAuth drafts would be very helpful instead of
just pointing to TLS (but please do leave that in).

This is just a comment the references do appear at end of the Security
considerations section, & I'd recommend you move those up to section 3.1
as it will be a lot easier for the reader.

Section 3.1
Just a question, should SAML 2.0 be listed as an option since this is a
RESTful interface and we are talking about client authentication via a
federated identity scheme or is that not an option?  Thanks.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 30 Oct 2014 11:58:02 +0000

> -----Original Message-----
> From: Kathleen Moriarty [mailto:[email-masked]]
> Sent: Wednesday, October 29, 2014 9:01 PM
> To: The IESG
> Cc: [email-masked]; draft-ietf-weirds-rdap-
> [email-masked]; [email-masked]
> Subject: Kathleen Moriarty's Discuss on draft-ietf-weirds-rdap-sec-10:
> (with DISCUSS and COMMENT)
> 

A reference to RFC 5280 is already included in the 6th paragraph (page 4, 3rd paragraph down from the top).

> control options and guidelines.

I'm not sure what else I can add to this section. Response-object-specific guidance belongs in the response document. Assuming Andy and I make those mods to the response draft, would a reference at the end of Section 3.2 be sufficient?

> be the best option for confidentially protection.

Fine.

> about enough in the drafts (IMO).

Fine. Access to information is tied to the identity of the client and associated authorizations, not the roles identified in the response data records.
 
> https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/

Fine, it's in WG last call. I'll add an informative reference.

There's already a reference to RFC 6749 in Section 3.1.1, where we talk specifically about federated authentication. Would adding a sentence there to specifically refer to the security considerations be sufficient?

> federated identity scheme or is that not an option?  Thanks.

It would be a more appropriate addition to Section 3.1.1. The document currently says:

"Federated authentication mechanisms used by RDAP MUST be fully supported by HTTP. OAuth, OpenID, and CA-based mechanisms are three possible approaches to provide federated authentication." I could add SAML to the list since we're not mandating anything.

Scott

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 30 Oct 2014 12:28:49 -0400

Hi Scott,

Thanks for you quick and detailed response.  My response is inline.

> A reference to RFC 5280 is already included in the 6th paragraph (page 4, 3rd paragraph down from the top).

My bad, sorry I missed that.  There was a lot of reading for this
telechat and what you have looks good.

> I'm not sure what else I can add to this section. Response-object-specific guidance belongs in the response document. Assuming Andy and I make those mods to the response draft, would a reference at…

Yes, a reference is fine since that is specific to the response draft, thanks.

>> be the best option for confidentially protection.

Thanks.

> Fine. Access to information is tied to the identity of the client and associated authorizations, not the roles identified in the response data records.

OK, making that clear would be helpful.  Thanks.

> Fine, it's in WG last call. I'll add an informative reference.

Thank you.

> There's already a reference to RFC 6749 in Section 3.1.1, where we talk specifically about federated authentication. Would adding a sentence there to specifically refer to the security consideratio…

It's fine as-is, this was just a comment because it is in the security
consideration section.  Section 3.1 read to me as TLS is used to
secure it as opposed to just pointing to each of the specs for their
own considerations + recommending TLS.  All the text is there, just
the placement isn't as I would have put it.  It's fine to ignore this
comment.  Thanks.

> "Federated authentication mechanisms used by RDAP MUST be fully supported by HTTP. OAuth, OpenID, and CA-based mechanisms are three possible approaches to provide federated authentication." I could…

If it is used by implementations, that might be helpful.  If it is
not, like you said it is just an option and is fine either way.  This
was just a comment for that reason.  Thanks & I'll leave it up to you.
I just added this because of it's use/adoption with other RESTful
services.  That may or may not be the case here.

Thanks,
Kathleen

-- 

Best regards,
Kathleen