Subject: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT)

From: "Kathleen Moriarty" <[email-masked]>
Date: Mon, 11 May 2015 17:45:39 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-scim-core-schema-19: 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 https://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:
https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/

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

Thanks for your work on this draft and the updates that took care of most
of the items I wanted to discuss.  There is just one left and maybe an
email response will clear up the scope of SCIM for me.  I'm not entirely
clear on how data might pass between service providers on behalf of a
customer, or if this is just between an customer and a service provider. 
The latter doesn't have to worry about some security considerations of
the former, so it would be good to know how the scope is limited.

4. It would help to have a statement that lists the scope of where SCIM
is used and that the protocol design requires encryption when this data
is in transit (per the api draft), since most of the attributes defined
would contain PII when used.  

I'm making some assumptions, so please correct the text to the scope of
SCIM.  The abstract has the following sentence:
   "This schema is intended for exchange and use with cloud
   service providers."
What about the following:
   "This schema is intended for exchange and use with cloud
   service providers and their customers."

There is also this statement int he introduction:
   "This schema is intended for exchange and use with
   cloud service providers and other cross-domain scenarios."

Is it also used between service providers?  If so, permission to provide
customers user information between service providers gets tricky and I
don't think that was covered in the API draft, but please let me know if
I missed it.

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

Thanks for addressing the SecDir review adding text on clear text/hashed
passwords and best practices (to avoid storing clear text, etc.). 
https://www.ietf.org/mail-archive/web/secdir/current/msg05678.html

Thanks for the additional privacy considerations, pointing out that most
of the data that could be sent using the SCIM schema could be sensitive
in addition to the id and externalId.

Thanks for the additional text to out-of-scope some of the security
controls that are really in the hands of implementers and may be
specified through security SLAs or contracts.

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 12 May 2015 14:23:11 -0400

Hi Phil,

Thanks for your response.  in-line.

On Tue, May 12, 2015 at 2:12 PM, Phil Hunt <[email-masked]> wrote:

> Kathleen,
>
> My understanding of the SCIM WG charter indicates the use cases are
> intended to cover both enterprise to cloud provider and cloud-to-cloud
> scenarios. Unless I am missing something, I think the latest drafts do
> handle the issue appropriately.
>
> In particular, in the last update, the text put in regarding SLAs and
> privacy covers the issues raised regarding the cloud-to-cloud and
> enterprise-to-cloud cases:
>
> From the Core Schema Privacy Section (9.3):
>    Information should be shared on an as-needed basis.  A SCIM client
>    should limit information to what it believes a service provider
>    requires, and a SCIM service provider, should only accept information
>    it needs.  Clients and service providers should take into
>    consideration that personal information is being conveyed across
>    technical (e.g., protocol and applications), administrative (e.g.
>    organizational, corporate), and jurisdictional boundaries.  In
>    particular information security and privacy must be considered.
>
>    Security service level agreements for the handling of these
>    attributes are beyond the scope of this document, but are to be
>    carefully considered by implementers and deploying organizations.
>
>    Please see the Privacy Considerations section of [
> I-D.ietf-scim-api
> ],
>    for more protocol specific considerations for handling of SCIM
>    information.
>

This text is good and helpful, my concern is that it doesn't say anywhere
that data could be transferred from a customer, to their service provider,
then to another service provider (except with the cross-domain sentence).
How does one track where their data went and would that type of scenario be
negotiated in contracts or could that happen without the customer's
knowledge?

>
> I also note that while core schema spec doesn’t explicitly call for TLS
> (since it is a schema spec) it does so implicitly as we call attention to
> the protocol spec:
>
> 9.1.  Protocol
>
>    SCIM data is intended to be exchanged using SCIM Protocol.  It is
>    important when handling data to implement the security considerations
>    outlined in Section 7 of [
> I-D.ietf-scim-api].
>
> Section 7.2 of SCIM Protocol indicates TLS 1.2 is required.
>

TLS 1.2 is already required, so this text is good.

>
> Would you like stronger, more explicit wording?  E.g. regardless of
> protocol, the exchange of sensitive information MUST be protected by
> encryption such as TLS 1.2 or better?
>
> Or, be more limited and specifically say TLS 1.2 *and* SCIM Protocol MUST
> be used.
>
> Let me know if you think we need to put any more introductory information
> in or explicitly repeat some of the api security requirements.
>
> Regarding the text suggestions:
>
> This suggestion is ok with me.
>

OK, but could it go on to another service provider?  That part wasn't clear
to me with the cross domain text.

Thank you!
Kathleen

> Regarding:
>   cloud service providers and other cross-domain scenarios.”
>
>
> I’m thinking the text pasted above does address the concern you raise
> regarding permissions.
>
> Does this address your concern?
>
> Phil
>
> [email-masked]
>
> On May 11, 2015, at 5:45 PM, Kathleen Moriarty <
> [email-masked]> wrote:
>
>

-- 

Best regards,
Kathleen

---

From: Phil Hunt <[email-masked]>
Date: Tue, 12 May 2015 11:12:45 -0700

Kathleen,

My understanding of the SCIM WG charter indicates the use cases are intended to cover both enterprise to cloud provider and cloud-to-cloud scenarios. Unless I am missing something, I think the latest drafts do handle the issue appropriately.

In particular, in the last update, the text put in regarding SLAs and privacy covers the issues raised regarding the cloud-to-cloud and enterprise-to-cloud cases:

I also note that while core schema spec doesn’t explicitly call for TLS (since it is a schema spec) it does so implicitly as we call attention to the protocol spec:

9.1.  Protocol

Would you like stronger, more explicit wording?  E.g. regardless of protocol, the exchange of sensitive information MUST be protected by encryption such as TLS 1.2 or better?

Or, be more limited and specifically say TLS 1.2 *and* SCIM Protocol MUST be used.

Let me know if you think we need to put any more introductory information in or explicitly repeat some of the api security requirements. 

>   cloud service providers and other cross-domain scenarios.”

I’m thinking the text pasted above does address the concern you raise regarding permissions.

Phil

[email-masked]

> On May 11, 2015, at 5:45 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
>

---

From: Leif Johansson <[email-masked]>
Date: Tue, 12 May 2015 20:58:07 +0200

> 
> This text is good and helpful, my concern is that it doesn't say
> anywhere that data could be transferred from a customer, to their
> service provider, then to another service provider (except with the
> cross-domain sentence).  How does one track where their data went and
> would that type of scenario be negotiated in contracts or could that
> happen without the customer's knowledge?

To me it sounds like we've ventured away from the realm of protocol
design and into the realm of contracts and SLAs. I'm not sure I see
how we could put anything other than a "nota bene" about this in
the text.

	Cheers Leif

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 12 May 2015 15:03:38 -0400

> how we could put anything other than a "nota bene" about this in

I'm thinking more along the lines of a security warning, since the data
might go beyond where a customer thinks it is going.  It would be good for
users to be aware of this possibility so they know if they need to take
precautions.  An N.B. is fine.  I didn't meant to imply that contracts
should be mentioned with this, but rather that users were aware and they
might take that step because the security consideration was noted.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Leif Johansson <[email-masked]>
Date: Tue, 12 May 2015 21:10:26 +0200

On 05/12/2015 09:03 PM, Kathleen Moriarty wrote:
> 
> 
> On Tue, May 12, 2015 at 2:58 PM, Leif Johansson <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
>     >
> might go beyond where a customer thinks it is going.  It would be good
> for users to be aware of this possibility so they know if they need to
> take precautions.  An N.B. is fine.  I didn't meant to imply that
> contracts should be mentioned with this, but rather that users were
> aware and they might take that step because the security consideration
> was noted.
> 

So this is like saying "if you send an email, somebody might forward
it". I'm not trying to be facetious but I'm struggling to understand
why this is a particular feature of SCIM...

... or maybe we just decided to up the stakes a bit on privacy. I would
be totally fine with that answer!
	
	Cheers Leif

---

From: Barry Leiba <[email-masked]>
Date: Tue, 12 May 2015 20:21:51 +0100

> why this is a particular feature of SCIM...

Yes, this is what I was thinking, before Leif responded.  We might be
getting into a situation where, in order to make things privacy-aware,
we're going beyond the reasonable realm of protocol specifications.
We should be putting things in our protocol documentation to encourage
good practices and to raise awareness of privacy concerns.  But we
shouldn't be sticking something into every protocol that says that
information you give to another part might go places you didn't
anticipate -- unless that protocol has specific aspects that make
dissemination more likely.

It's already the case that any information you give when you sign up
for any service (whether it be your ISP, Google, or LL Bean) can be
passed on to advertisers, bad guys, or whomever.  We, as a community,
need to raise awareness of that, but the place to do it isn't in every
protocol document we write.

Is there more to this request than that?

Barry

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 12 May 2015 15:22:08 -0400

> why this is a particular feature of SCIM...

I'd say this is pretty different from email, but even with that it's well
documented that email goes through relays and could be copied at any point
along the way... when in a mail queue on a server where it's not protected
by transport encryption.

> be totally fine with that answer!

It doesn't concern you that your info could be forwarded legitimately using
the protocol and that isn't mentioned explicitly?  I'm putting my hat back
on as a former CISO, head of security, etc. where I evaluated such services
and I would need to know this bit of information for the handling of
sensitive and privacy related information.  I know I was a PITA to the
service providers and vendors I worked with, but this is exactly the kind
of thing I'd want to know - where are all the places my data could flow to
and how does it flow there (you've answered the latter already- all TLS
protected).

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 12 May 2015 15:23:49 -0400

> Is there more to this request than that?

If the scope of SCIM is to allow this data to be transferred between
customers and their service providers, and from your service provider to
another one, why is there opposition to stating that clearly?

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Leif Johansson <[email-masked]>
Date: Tue, 12 May 2015 21:35:12 +0200

> It doesn't concern you that your info could be forwarded legitimately

It would concern me a lot more if the intended user of SCIM was the
end-user - i.e if SCIM was more like OpenSocial (something that was
discussed and rejected by the WG btw: there is no @me in SCIM). Had
this been the case the implementer of SCIM could be advised to
display warnings etc...

> using the protocol and that isn't mentioned explicitly?  I'm putting my
> hat back on as a former CISO, head of security, etc. where I evaluated
> such services and I would need to know this bit of information for the
> handling of sensitive and privacy related information.  I know I was a
> PITA to the service providers and vendors I worked with, but this is
> exactly the kind of thing I'd want to know - where are all the places my
> data could flow to and how does it flow there (you've answered the
> latter already- all TLS protected).

... and if I was CISO and was reviewing a deployment of SCIM for
provisioning my company employee data to LL Bean then I'd make
sure to have controls to cover that in the contracts.

My point is that I'm going to do that regardless of what it sais
in the SCIM protocol spec, right?

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Tue, 12 May 2015 21:36:22 +0200

> another one, why is there opposition to stating that clearly?

fwiw - I don't feel very strongly about this either way and I'm pretty
sure the authors don't either. I just thought it an interesting point to
discuss.

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 12 May 2015 15:41:22 -0400

> sure the authors don't either. I just thought it an interesting point to

It's something I would want pointed out if I were evaluating the use of
SCIM and would want to know what security considerations I should think
about - where could my data go and how?  Scope is usually stated in the
routing drafts that come through, which is great, because it eliminates
security concerns in most cases (within a closed environment).  I think
this is an important security consideration and is easy enough to address
by clearly stating the scope of use by altering a sentence in the
introduction to state it more clearly.  I think the scope here rises above
just a comment as the impact could be big if the security consideration
were not realized.

Thanks,

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 12 May 2015 15:43:47 -0400

> in the SCIM protocol spec, right?

I would and you would, but not everyone does.  Another problem is that
often times you wind up talking to sales and it's really hard to get an
answer.  It's much easier if we do a good job of listing out security
considerations.

-- 

Best regards,
Kathleen

---

From: Michael Hammer <[email-masked]>
Date: Tue, 12 May 2015 19:46:05 +0000

That sounds like another WG's tagging to let partners know 
which communities you can share with, outside of which 
you are violating some policy rule.

Versus an note to say:  if you share, it is public.

________________________________
Michael Hammer
Principal Engineer
[email-masked]
Mobile: +1 408 202 9291
542 Gibraltar Drive
Milpitas, CA 95035 USA
www.yaanatech.com

-----Original Message-----
From: scim [mailto:[email-masked]] On Behalf Of Leif Johansson
Sent: Tuesday, May 12, 2015 3:10 PM
To: Kathleen Moriarty
Cc: [email-masked]; Phil Hunt;
[email-masked];
[email-masked]; The IESG;
[email-masked]; [email-masked]
Subject: Re: [scim] Kathleen Moriarty's Discuss on
draft-ietf-scim-core-schema-19: (with DISCUSS and COMMENT)

On 05/12/2015 09:03 PM, Kathleen Moriarty wrote:
> I'm thinking more along the lines of a security warning, since the 
> data might go beyond where a customer thinks it is going.  It would be 
> good for users to be aware of this possibility so they know if they 
> need to take precautions.  An N.B. is fine.  I didn't meant to imply 
> that contracts should be mentioned with this, but rather that users 
> were aware and they might take that step because the security 
> consideration was noted.
> 

So this is like saying "if you send an email, somebody might forward it".
I'm not trying to be facetious but I'm struggling to understand why this is
a particular feature of SCIM...

... or maybe we just decided to up the stakes a bit on privacy. I would be
totally fine with that answer!
	
	Cheers Leif

_______________________________________________
scim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/scim

---

From: Barry Leiba <[email-masked]>
Date: Tue, 12 May 2015 20:52:25 +0100

> another one, why is there opposition to stating that clearly?

If that's all you want said, there's no opposition.

b

---

From: Leif Johansson <[email-masked]>
Date: Tue, 12 May 2015 22:13:29 +0200

> If that's all you want said, there's no opposition.
+1

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 12 May 2015 16:51:20 -0400

> you are violating some policy rule.

Sure, that's what the info sharing communities do and my request doesn't go
near that... just really to state the scope of SCIM, so folks know it could
go from their SP to another SP.

> Versus an note to say:  if you share, it is public.

This is at least a bit more controlled than that, I hope ;-)

Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 12 May 2015 16:52:04 -0400

On Tue, May 12, 2015 at 4:05 PM, Phil Hunt <[email-masked]> wrote:

> I agree.
>
> Maybe what we want is an addition qualifier to the SLA statement that says
> parties should also consider whether sharing with 3rd parties (e.g.
> cloud-provider to partner or competing cloud-provider) is appropriate and
> permissible?
>

That sounds great or just altering the scope statement in the intro.

Thank you!
Kathleen

>
> Phil
>
> [email-masked]
>
> > On May 12, 2015, at 12:52 PM, Barry Leiba <[email-masked]>
> wrote:
> >

-- 

Best regards,
Kathleen

---

From: Phil Hunt <[email-masked]>
Date: Tue, 12 May 2015 15:30:19 -0700

Proposed additional text for the introduction:

While the SCIM protocol and core schema specifications are intended to cover point-to-point scenarios, implementers and deployers should consider multi-hop and multi-party scenarios such as a service provider acting as a general profile service for in-domain applications; as well as, scenarios where a service provider in turn passes information to a 3rd party service provider either by acting as a SCIM client or as a SCIM service provider. Implementers and deployers should consider carefully their service level agreements and privacy agreements when distributing or propagating personal information (see also Section 9.3 Privacy Considerations).

Phil

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

> On May 12, 2015, at 1:52 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> 
> 
> On Tue, May 12, 2015 at 4:05 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
> I agree.
> 
> Maybe what we want is an addition qualifier to the SLA statement that says parties should also consider whether sharing with 3rd parties (e.g. cloud-provider to partner or competing cloud-provider) is appropriate and permissible?
> 
> [email-masked] <mailto:[email-masked]>
> 
> > On May 12, 2015, at 12:52 PM, Barry Leiba <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/scim <https://www.ietf.org/mailman/listinfo/scim>
> 
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 12 May 2015 20:31:59 -0400

That's great, thank you!

Kathleen 

Sent from my iPhone

> On May 12, 2015, at 6:30 PM, Phil Hunt <[email-masked]> wrote:
> 
>>> > On May 12, 2015, at 12:52 PM, Barry Leiba <[email-masked]> wrote:
>>> >

---

From: Phil Hunt <[email-masked]>
Date: Tue, 12 May 2015 17:37:13 -0700

Great! I will post tonight (pacific time) unless I see any -1s or other proposed refinements.

Phil

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

> On May 12, 2015, at 5:31 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> That's great, thank you!
> 
> Kathleen 
> 
> Sent from my iPhone
> 
> On May 12, 2015, at 6:30 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>
>>> On May 12, 2015, at 1:52 PM, Kathleen Moriarty <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 
>>>

---

From: Phil Hunt <[email-masked]>
Date: Tue, 12 May 2015 13:05:34 -0700

I agree. 

Phil

[email-masked]