Subject: [weirds] Security Service Summary

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 30 Oct 2012 14:24:22 +0000

This is what I think I read while reviewing the discussion of the multiple security service notes that I posted a few weeks ago. Please feel free to identify any important points that I might have missed. I've added open questions where I have them.

Authentication: We have a requirement to specify an HTTP-based authentication mechanism. QUESTION: which one? HTTP basic? HTTP digest?  HTTP basic could be used with https (see data confidentiality below).

Authorization: We have a requirement to include an authorization framework that is capable of providing granular (per registration data object) permissions (access controls). We have another requirement to provide an anonymous access mechanism that may be turned on or off based on the policy of an operator.

Availability: we have a DDoS security consideration that can be addresses with a normative reference to RFC 4732. We have a requirement to support query and display of contact entities for abuse reporting.

Data Confidentiality: in the context of encryption the only *protocol* requirement that I've been able to identify is that authentication credentials MUST be protected while in transit between client and server. There is no requirement to encrypt queries or responses.

RFC 3707 says that when a value in an answer to a query is given, the protocol MUST be capable of tagging the value with the following labels:

1. do not redistribute
2. special access granted

QUESTION: Is this a requirement for RDAP?

Data Integrity: we have not identified a requirement to provide this service. There may, however, be a requirement to provide some sort of response element that confirms that an element has been "validated" or "verified", which some people will likely confuse with a data integrity service. QUESTION: how do we want to approach this?

Non-repudiation: we have not identified a requirement to provide this service.

Scott