Subject: [scim] Security considerations: sensitive data

From: Phil Hunt <[email-masked]>
Date: Thu, 17 Jul 2014 11:52:54 -0700

At present we do not have any security considerations for sensitive data (e.g. passwords).  

Am thinking we should have some general verbiage around the issues/best practice around things like passwords that need to be salted/hashed appropriately.  To some implementers as a pure provisioning protocol there may be no impact. But for those building SCIM on top of a persistence system (e.g. database), the considerations become important. There’s lots of stuff to reference here, especially from the OAuth Threat Model document as well as LDAP.

The other issue is whether this goes in the API or the core-schema draft (or both).

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Leif Johansson <[email-masked]>
Date: Fri, 18 Jul 2014 16:06:18 +0200

I think we should say that scim is not an authentication protocol and any resemblance to one is accidental and that using scim for provisioning credentials should be avoided. 

Thats the way to avoid lots of ratholes!

> 17 jul 2014 kl. 20:52 skrev Phil Hunt <[email-masked]>:
> 
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Bill Mills <[email-masked]>
Date: Fri, 18 Jul 2014 10:18:17 -0700

In fact SCIM is very weak/silent on the whole authn/authz subject.

On Friday, July 18, 2014 7:06 AM, Leif Johansson <[email-masked]> wrote:

Phil

@independentid
[email-masked]

---

From: Phil Hunt <[email-masked]>
Date: Fri, 18 Jul 2014 10:41:45 -0700

I posted some improved authen text in another thread.

I believe strongly we are going to have to address credential management one way or another in a future charter.

The real issue is because people are building web UI servers and HTML5 code that contact SCIM endpoints to provide user self-service features.  From a protocol perspective, its hard to differentiate from a client doing the bad thing of sync’ing passwords, to a UI component simply setting the password via a cloud SCIM endpoint.  For example, a set-top box might make a SCIM call to update a password as it presents its own UI to the end-user.  The set top box may use an OAuth token that enables the SCIM endpoint to trust the box to make such a change.

I am ok with saying SCIM does not do authentication. But to say that passwords cannot be validated(matched) would be wrong. At best it can be simply a single factor confirmation. An authentication system SHOULD be much more than this (e.g. establishing a session, validating multiple factors).  All of which fall out of scope of SCIM.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Leif Johansson <[email-masked]>
Date: Fri, 18 Jul 2014 19:42:19 +0200

> 18 jul 2014 kl. 19:18 skrev Bill Mills <[email-masked]>:
> 

Right  - I suggest that adding more words may get us in trouble. There are a bucnh of credential mgmt protocols around and trying to make scim behave like one is just going to garner attention from everybody who has a favorite authentication protocol.  Best say 'don't do it' and leave it for extensions.

---

From: Leif Johansson <[email-masked]>
Date: Fri, 18 Jul 2014 19:44:25 +0200

> 18 jul 2014 kl. 19:41 skrev Phil Hunt <[email-masked]>:
> 

Lets deal w this when somebody defines an extension for it!

> I am ok with saying SCIM does not do authentication. But to say that passwords cannot be validated(matched) would be wrong. 

There are many a rat buried there.

> At best it can be simply a single factor confirmation. An authentication system SHOULD be much more than this (e.g. establishing a session, validating multiple factors).  All of which fall out of scope of SCIM.
> 
> Phil
> 
> @independentid
> www.independentid.com
> [email-masked]
> 
> 
>

---

From: Bill Mills <[email-masked]>
Date: Fri, 18 Jul 2014 10:51:22 -0700

"SCIM is a data syndication/publication/query tool, as such it may be used as the data source/sink for an authentication system acting as a client or peer."

On Friday, July 18, 2014 10:45 AM, Leif Johansson <[email-masked]> wrote:

---

From: Phil Hunt <[email-masked]>
Date: Fri, 18 Jul 2014 11:12:42 -0700

+1

I would add “provisioning” to that as well. 8-)

Phil

@independentid
www.independentid.com
[email-masked]

On Jul 18, 2014, at 10:51 AM, Bill Mills <[email-masked]> wrote:

>> The real issue is because people are building web UI servers and HTML5 code that contact SCIM endpoints to provide user self-service features.  >From a protocol perspective, its hard to differentiate from a client doing the bad thing of sync’ing passwords, to a UI component simply setting the password via a cloud SCIM endpoint.  For example, a set-top box might make a SCIM call to update a password as it presents its own UI to the end-user.  The set top box may use an OAuth token that enables the SCIM endpoint to trust the box to make such a change.
>>

---

From: Bill Mills <[email-masked]>
Date: Fri, 18 Jul 2014 12:34:26 -0700

Works for me to add provisioning.  If it's not in the spec it could be to make clear it's not an auth system.

On Friday, July 18, 2014 11:12 AM, Phil Hunt <[email-masked]> wrote:

+1

Phil

@independentid

---

From: Mahalingam Mani <[email-masked]>
Date: Fri, 18 Jul 2014 12:48:49 -0700

+1.

Moreover, in addition to the question of password field, other fields that
have PI (personal identifier) /PII (personnally identifable information)
significance; will also need some security guidance on authorization for
access/modification.
Thus, at least in security considerations section there needs to reference
to the exposures/threats and some guidance on countermeasures.

-mani
============

On Fri, Jul 18, 2014 at 11:12 AM, Phil Hunt <[email-masked]> wrote:

> "SCIM is a data syndication/publication/query tool, as such it may be used
> as the data source/sink for an authentication system acting as a client or
> peer."
>
>
> The real issue is because people are building web UI servers and HTML5
> code that contact SCIM endpoints to provide user self-service features.
>  >From a protocol perspective, its hard to differentiate from a client
> doing the bad thing of sync’ing passwords, to a UI component simply setting
> the password via a cloud SCIM endpoint.  For example, a set-top box might
> make a SCIM call to update a password as it presents its own UI to the
> end-user.  The set top box may use an OAuth token that enables the SCIM
> endpoint to trust the box to make such a change.
>
> I am ok with saying SCIM does not do authentication. But to say that
> passwords cannot be validated(matched) would be wrong.
>
>
> At best it can be simply a single factor confirmation. An authentication
> system SHOULD be much more than this (e.g. establishing a session,
> validating multiple factors).  All of which fall out of scope of SCIM.
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
>
>
> I think we should say that scim is not an authentication protocol and any
> resemblance to one is accidental and that using scim for provisioning
> credentials should be avoided.
>
> Am thinking we should have some general verbiage around the issues/best
> practice around things like passwords that need to be salted/hashed
> appropriately.  To some implementers as a pure provisioning protocol there
> may be no impact. But for those building SCIM on top of a persistence
> system (e.g. database), the considerations become important. There’s lots
> of stuff to reference here, especially from the OAuth Threat Model document
> as well as LDAP.
>