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

From: "Kathleen Moriarty" <[email-masked]>
Date: Tue, 28 Apr 2015 17:54:48 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-scim-api-17: 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-api/

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

Thanks for your work on this draft.  I have a few items I'd like to
discuss and have provided suggestions to help the discussion.  I think
this should be fairly easy to get through.

1. OAuth is used for authorization and is limited to insecure methods of
authentication via HTTP supported methods and of those, OAuth only has a
few registered.  HTTP Basic authentication is the default, which is
horrible.  Later in this draft, SCIM encourages the use of asymmetric
crypto.  Can this be the preferred option and there be more details
listed on how to do with (references)?

What is specified now is really an authorization protocol, so you'll need
to say if HTTP Basic is what's used for authentication with OAuth
(default) or something else and then the security considerations for
OAuth bearer tokens and HHTP Basic.  Here are some links to help:

A reference to security considerations from this draft will be needed:
see: https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions
Reference to the HTTP Basic draft will be needed to show the security
issues with this option:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/

OAuth can't use something like HOBA in RFC7486, which was designed to
avoid the need for passwords when using HTTP Authentication.  Can SCIM
work directly with other HTTP Auth methods like HOBA? The OAuth folks are
thinking about this problem, but aren't there yet (non-password auth
methods to then use Oauth authorization tokens). 

2. The Holder-of-Key Assertions would get you a lot more security than
the bearer token.  Why are all the examples bearer token?  Or is there no
support for proof of possession of the key?

3. Section 7.1
I'm guessing the text on TLS versions is old and this was overlooked in
last call.  The minimum version that should be supported is 1.2.  TLS 1.0
is not considered a good starting point these days and browsers, such as
Chrome show it as obsolete.  The text on implementation information for
TLS 1.2 is no longer correct, it's widely implemented and is pretty much
the standard at the moment (1.3 will be soon enough).  Referencing the
TLS BCP would be preferred,
https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/.  It not only
starts from v1.2, but includes preferred algorithms and other
configuration/implementation details to avoid attacks.  It is close to
final publication and is ahead int he queue of this draft.

4. Section 7.2
Please review the Privacy Considerations,
https://tools.ietf.org/html/rfc6973.  I was expecting to see more
specific guidance as to what needs to be protected and options to protect
the data since there is quite a bit of personal information passed in
this protocol.  We care about this for the protection of user's privacy,
not just because it is required by laws.  You can leave mention of the
laws out, but it would be helpful to be specific on options to protect
the data or options to leave out certain data elements to protect privacy
(such as, make them optional or provide a way to encrypt/obscure, etc.). 
RFC6973 will help with current guidance and IETF considerations.  If it
is a per element or attribute consideration, a pointer to that text from
the privacy considerations section to the schema draft may be more
appropriate than covering the options in this draft.  Then  a better TLS
option will help as well so the session is less subject to attacks.

I see there is some text on privacy n the schema draft, but it's probably
not enough.  I'll read that within the next few days and give feedback to
help improve the text.

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

This is really just here to see if better Authentication options are
possible in current implementations and guidance for SCIM.

Section 7.5
While I like this bullet:
    o Avoid passwords and consider use of asymmetric cryptography based
      credentials.
Earlier in this draft the use of OAuth is specified, and the default for
that is passwords  via HTTP basic.  If asymmetric crypto is an option,
can that be the preferred option?  If it's possible, more detail on how
to do that would be good as that's not a supported option with OAuth.

Thanks!

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 29 Apr 2015 13:23:44 -0400

Hi Phil,

Just a quick response for now and more later.  I'll find the specific references and registry for authentication used with OAuth.  I'm the AD and have been reading their drafts carefully.

Thanks,
Kathleen

Sent from my iPhone

> On Apr 29, 2015, at 1:13 PM, Phil Hunt <[email-masked]> wrote:
> 
> Kathleen,
> 
> Thanks for your comments. My comments in line…
> 
> General comment.  At the end of the day, SCIM is just an HTTP protocol (an application) and as such can use any of the normal HTTP mechanisms. In OAuth terms it is just a resource server.  I wonder what we can point to as a general best practice for authentication and authorization. 
> 
> The use of OAuth was in part, a reflection of the growing popularity of OAuth at the time of writing, and I believe a conscious attempt by the original authors to discourage the use of simple password authentication such as RFC2617’s basic authentication.  For this reason we did not want to use Basic in the examples.  
> 
> Phil
> 
> [email-masked]
> 
>> On Apr 28, 2015, at 5:54 PM, Kathleen Moriarty <[email-masked]> wrote:
>> 
> [PH]  
> The text suggests OAuth is recommended but not required reflects what current implementers have been doing. I am opening to reducing this from “RECOMMENDED” and allowing deployers to use other equally secure mechanisms and to point out that the text based examples use bearer tokens to illustrate the use of the authorization header and are not normative.
> 
> Regarding OAuth.  I don’t see why OAuth can’t use HOBA.  OAuth doesn’t care how authentication happens only that the parties are authenticated before authorizing.  OAuth and for that matter OIDC both depend on using traditional (and emerging) authentication schemes to authenticate users.
> 
> That said, I see no reason why SCIM could not work directly with HOBA.  SCIM does not care, it merely assumes clients are authenticated (presumably via session cookie or the authorization header).
> 
> Regarding asymmetric crypto, I believe you are referring to section 7.5. See comment below...
> 
> 
>> 
> [PH] SCIM has no specific attachment to any authorization format. We just had to pick one.  
> 
> Probably the one thing we should avoid is the use of Basic Auth as there is a strong tendency by deployers to treat SCIM as being the equivalent of LDAP and perpetuate the mis-use of LDAP Bind as an authentication protocol as well as promoting the use of single-factor authentication.  I think a better approach is to emphasize that SCIM is just an HTTP based Protocol (Application) and uses HTTP mechanisms for authentication.  
> 
> Maybe we need some text indicating the use of “Bearer” tokens are illustrative purposes and should not be considered normative.
>> 
>> 
>> 3. Section 7.1
> [PH] Agreed, we should update this. 
>> 
>> 4. Section 7.2
> [PH] The core schema draft does have more information on privacy as it is in the context of talking about attributes (which often have personal information) rather than protocol.
> 
> Would it be appropriate to explicitly call out the core schema security considerations as foundational to the SCIM Protocol draft?
>> 
> [PH] I will await your comments.
>> 
>> 
> [PH] The context of that comment was to avoid using “password” based authentication and instead use other approaches such as asymmetric crypto approaches. Again this was an attempt to discourage use of Basic Auth in favour of any other mechanism that uses crypto. For example, Mutual-auth TLS would fit.  There are many ways to fulfill this, including TLS, HOBA, OAuth POP tokens and so on.
> 
> BTW…I know of nothing in OAuth that suggests HTTP Basic is the default. I think the point of using OAuth is to keep SCIM specifically out of doing authentication as per the charter.  That said, there are many other mechanisms equally workable.
> 
>> Thanks!
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 29 Apr 2015 16:08:29 -0400

Phil and I chatted a bit and he is working up some text with specific
authentication options.  I said I would look up some more references and am
providing them inline here.

On Wed, Apr 29, 2015 at 1:23 PM, Kathleen Moriarty <
[email-masked]> wrote:

> Hi Phil,
>
> Just a quick response for now and more later.  I'll find the specific
> references and registry for authentication used with OAuth.  I'm the AD and
> have been reading their drafts carefully.
>
> Thanks,
> Kathleen
>
> Sent from my iPhone
>
> > General comment.  At the end of the day, SCIM is just an HTTP protocol
> (an application) and as such can use any of the normal HTTP mechanisms. In
> OAuth terms it is just a resource server.  I wonder what we can point to as
> a general best practice for authentication and authorization.
>

Yes, the issue I hit was that the text of this draft said that OAuth is the
authentication protocol, when it's only an authorization protocol.  As
such, a reader might jump to a conclusion that HTTP Basic is the way to go
since it's the first method (and default) for OAuth in the OAuth 2.0
framework.  Recent drafts that mention the same registry where the
supported authentication protocols from the client to the AS have not
updated that short list.  If you could rewrite the text to specify
recommended authentication types, that would be good.

See section 2.3 of https://tools.ietf.org/html/rfc6749
and the 3 methods defined are stated again in the dyn registry draft(
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg), basically
saying to authenticate to use a token, these methods are available:

token_endpoint_auth_method
      String indicator of the requested authentication method for the
      token endpoint.  Values defined by this specification are:

      *  "none": The client is a public client as defined in OAuth 2.0
         and does not have a client secret.
      *  "client_secret_post": The client uses the HTTP POST parameters
         defined in OAuth 2.0 section 2.3.1.
      *  "client_secret_basic": the client uses HTTP Basic defined in
         OAuth 2.0 section 2.3.1

      Additional values can be defined via the IANA OAuth Token Endpoint
      Authentication Methods Registry established in Section 4.2.
      Absolute URIs can also be used as values for this parameter
      without being registered.  If unspecified or omitted, the default
      is "client_secret_basic", denoting HTTP Basic Authentication
      Scheme as specified in Section 2.3.1 of OAuth 2.0.

>
> > The use of OAuth was in part, a reflection of the growing popularity of
> OAuth at the time of writing, and I believe a conscious attempt by the
> original authors to discourage the use of simple password authentication
> such as RFC2617’s basic authentication.  For this reason we did not want to
> use Basic in the examples.
>

It's specified as the default in OAuth 2.0 when using a token.  see above.

Phil and I already chatted and he's planning to specify recommendations
that are more secure since SCIM can use other authentication methods.

Please take a look at the reference I gave that spells out the security
considerations for bearer tokens.  They are not secure in of themselves and
require the use of TLS 1.2 to prevent attacks.  This needs to be clearly
stated as well with a reference included to the draft I provided that
already details the risks with bearer tokens.

Thanks,
Kathleen

> >> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > The text suggests OAuth is recommended but not required reflects what
> current implementers have been doing. I am opening to reducing this from
> “RECOMMENDED” and allowing deployers to use other equally secure mechanisms
> and to point out that the text based examples use bearer tokens to
> illustrate the use of the authorization header and are not normative.
> >
> > Regarding OAuth.  I don’t see why OAuth can’t use HOBA.  OAuth doesn’t
> care how authentication happens only that the parties are authenticated
> before authorizing.  OAuth and for that matter OIDC both depend on using
> traditional (and emerging) authentication schemes to authenticate users.
> >
> > That said, I see no reason why SCIM could not work directly with HOBA.
> SCIM does not care, it merely assumes clients are authenticated (presumably
> via session cookie or the authorization header).
> >
> > Probably the one thing we should avoid is the use of Basic Auth as there
> is a strong tendency by deployers to treat SCIM as being the equivalent of
> LDAP and perpetuate the mis-use of LDAP Bind as an authentication protocol
> as well as promoting the use of single-factor authentication.  I think a
> better approach is to emphasize that SCIM is just an HTTP based Protocol
> (Application) and uses HTTP mechanisms for authentication.
> >
> > Maybe we need some text indicating the use of “Bearer” tokens are
> illustrative purposes and should not be considered normative.
> >>
> >>
> >> 3. Section 7.1
> > [PH] The core schema draft does have more information on privacy as it
> is in the context of talking about attributes (which often have personal
> information) rather than protocol.
> >
> > Would it be appropriate to explicitly call out the core schema security
> considerations as foundational to the SCIM Protocol draft?
> >>
> > [PH] The context of that comment was to avoid using “password” based
> authentication and instead use other approaches such as asymmetric crypto
> approaches. Again this was an attempt to discourage use of Basic Auth in
> favour of any other mechanism that uses crypto. For example, Mutual-auth
> TLS would fit.  There are many ways to fulfill this, including TLS, HOBA,
> OAuth POP tokens and so on.
> >
> > BTW…I know of nothing in OAuth that suggests HTTP Basic is the default.
> I think the point of using OAuth is to keep SCIM specifically out of doing
> authentication as per the charter.  That said, there are many other
> mechanisms equally workable.
> >
> >> Thanks!
> >
>

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 29 Apr 2015 16:27:39 -0400

Hi Phil,

On Wed, Apr 29, 2015 at 4:15 PM, Phil Hunt <[email-masked]> wrote:

> Am I correct in assuming  authentication is specifically excluded per the
> charter. The assumption was/is SCIM uses typical http authen/authz schemes
> and does not provide or mandate a method.
>
> That said we have reservations about using 2617 mechanisms and prefer
> stronger options.
>

Good.  This needs to be stated explicitly because of existing standards.
My concerns are because of this text in your draft:

2.  Authentication and Authorization

   Because SCIM builds on the HTTP protocol, it does not itself define a
   scheme for authentication and authorization.  SCIM depends on
   standard HTTP authentication schemes.  Implementers SHOULD support
   existing authentication/authorization schemes.  In particular, OAuth2

   (see [RFC6749], [RFC6750]) is RECOMMENDED.

Because it says OAuth2 is recommended for authentication and you are using
this for bearer tokens, I am going to assume that the 3 options established
for that purpose are being used, with the default being HTTP Basic.  In my
original discuss, I provided a link to the updated version of Basic (in the
RFC editor queue).  When you recommend against it's use, you should refer
to the security considerations section of that draft, it updates 2617 for
Basic.  Digest is in a separate update.

Since bearer tokens are used, I have to assume all of the security issues
with those as well.  First is the IETF registered and supported
authentication methods, then the lack of security in the token itself.
Holder-of-key tokens require proof of possession (there is some crypto to
do this).  The only thing you can do to protect a bearer token is to use
TLS and there needs to be a reference to the security section I mentioned
in my original post so users know where to look to understand issues with
bearer tokens.

I hope that helps.

>
> Is this is the approach we are looking for?
>
Yes, being explicit would be very helpful as I'll assume defaults and
limitations like registered/supported methods.

Thank you,
Kathleen

> Thanks,
>
> Phil
>
> > On Apr 29, 2015, at 13:08, Kathleen Moriarty <
> >>> Regarding asymmetric crypto, I believe you are referring to section
> 7.5=
>

-- 

Best regards,
Kathleen

---

From: Phil Hunt <[email-masked]>
Date: Wed, 29 Apr 2015 13:31:33 -0700

Thanks. I think we have a plan!

Phil

> On Apr 29, 2015, at 13:27, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hi Phil,
> 
>> Am I correct in assuming  authentication is specifically excluded per the charter. The assumption was/is SCIM uses typical http authen/authz schemes and does not provide or mandate a method.
>> 
>> That said we have reservations about using 2617 mechanisms and prefer stronger options.
> 
> Good.  This needs to be stated explicitly because of existing standards.  My concerns are because of this text in your draft:
> 
> Because it says OAuth2 is recommended for authentication and you are using this for bearer tokens, I am going to assume that the 3 options established for that purpose are being used, with the default being HTTP Basic.  In my original discuss, I provided a link to the updated version of Basic (in the RFC editor queue).  When you recommend against it's use, you should refer to the security considerations section of that draft, it updates 2617 for Basic.  Digest is in a separate update.
> 
> Since bearer tokens are used, I have to assume all of the security issues with those as well.  First is the IETF registered and supported authentication methods, then the lack of security in the token itself.  Holder-of-key tokens require proof of possession (there is some crypto to do this).  The only thing you can do to protect a bearer token is to use TLS and there needs to be a reference to the security section I mentioned in my original post so users know where to look to understand issues with bearer tokens.
> 
> I hope that helps.
>> 
> Yes, being explicit would be very helpful as I'll assume defaults and limitations like registered/supported methods. 
> 
> Thank you,
> Kathleen
> 
>> 
>> Thanks,
>> 
>> Phil
>> 
>> > On Apr 29, 2015, at 13:08, Kathleen Moriarty <[email-masked]> wrote:
>> >
>> >>> Regarding asymmetric crypto, I believe you are referring to section 7.5=
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim