Subject: [scim] Security considerations

From: Melinda Shore <[email-masked]>
Date: Fri, 13 Apr 2012 11:26:29 -0800

I've been going through the drafts and while the security discussions
aren't the worst I've seen in BOF-stage work they're pretty thin.  Even
saying "Use TLS" isn't going to be sufficient to address
interoperability or trust issues.

I haven't been able to find anything that looks like a framework or
problem statement draft but that would be the place to say "Here are the
security issues we'll need to address" without getting into the specific
mechanisms that would be implemented to solve the security problems that
have been identified.  It seems that both because there are regulatory
requirements in some industries for protecting PII and because, well,
you really do want to do the right thing, there's going to be a need to
be at least a little rigorous about both privacy issues and protecting
the integrity of the data.

Barry wrote "I worry that there's no consideration in the charter for
security aspects of this, other than to specifically *exclude* work on
authentication and authorization. It's probably good not to spin up
new mechanisms for these, but I'd like the charter to say something
about how the system *will* address issues of authentication,
authorization, access control, privacy, and integrity."  It seems to me
that the "something about how" should probably be replaced with "that"
or something along those lines, with the "how" reserved for the specs.

Melinda

---

From: Barry Leiba <[email-masked]>
Date: Fri, 13 Apr 2012 17:09:08 -0400

> or something along those lines, with the "how" reserved for the specs.

Mostly, yes... but it's very easy to put a sentence in a charter that
says, "The working group will address security-related issues," and it
doesn't really say much, does it?  The charter won't have answers, of
course, but I'd like to see that there was *some* thought put into it,
and that there isn't just a sentence in there to make a few ADs smile.

Barry

---

From: Melinda Shore <[email-masked]>
Date: Fri, 13 Apr 2012 13:45:08 -0800

> and that there isn't just a sentence in there to make a few ADs smile.

What about something along the lines of:

"Given both the sensitivity of the information being conveyed in scim
(or whatever) messages and the regulatory requirements around the
privacy of personally identifiable information, the working group
will pay particular attention to issues around authenticity and
privacy, in addition to the usual requirements around security
consideration."

I've been involved with working groups where there was very explicit
language around security in the charter, mostly to mollify the IESG,
and where ultimately the working group punted, and I'll bet you have,
too.  In the end it comes down to the working group.

As an aside I'd hate to see "Just use oauth bearer tokens" join "just
use TLS" and "just use ipsec" on the heap of unthoughtful/
uninteroperable security text.

Melinda

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 16 Apr 2012 11:44:49 -0600

On 4/13/12 3:45 PM, Melinda Shore wrote:
>> Mostly, yes... but it's very easy to put a sentence in a charter
>> that says, "The working group will address security-related
>> issues," and it doesn't really say much, does it?  The charter
>> won't have answers, of course, but I'd like to see that there was
>> *some* thought put into it, and that there isn't just a sentence
>> in there to make a few ADs smile.
> 
> "Given both the sensitivity of the information being conveyed in
> scim (or whatever) messages and the regulatory requirements around
> the privacy of personally identifiable information, the working
> group will pay particular attention to issues around authenticity
> and privacy, in addition to the usual requirements around security 
> consideration."
> 
> I've been involved with working groups where there was very
> explicit language around security in the charter, mostly to mollify
> the IESG, and where ultimately the working group punted, and I'll
> bet you have, too.  In the end it comes down to the working group.

IMHO it also comes down to security review both within the WG and the
broader IETF community. A protocol without any security features just
isn't going to pass muster with the SecDir, ADs, etc.

> As an aside I'd hate to see "Just use oauth bearer tokens" join
> "just use TLS" and "just use ipsec" on the heap of unthoughtful/ 

Indeed.

Your proposed text looks good to me.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/