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

From: Phil Hunt <[email-masked]>
Date: Wed, 6 May 2015 16:02:05 -0700

Kathleen,

Apologies for pasting a lot of text in here, but after considering comments from you and Brian, I wanted to re-think a number of things and try and boil things down a bit (I probably can do some more). I’ve essentially re-written the authentication and security sections with care not to change consensus, but to address the issues you mentioned.  I hope we are close.  Please take a look at the pasted sections below. If you are in agreement, I can post them in the next document update.

Thanks for your help!

Phil

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

------------------------------
Section 2 Proposed:
2.  Authentication and Authorization

   SCIM Protocol is based upon HTTP and does not itself define a SCIM
   specific scheme for authentication and authorization.  SCIM depends
   on the use of TLS and/or standard HTTP authentication and
   authorization schemes as per [RFC7235].  For example, the following
   methodologies could be used among others:

   TLS Client Authentication
      The SCIM service provider MAY request TLS client authentication
      (also known as mutual authentication).  See Section 7.3 [RFC5246].

      HTTP Origin-Bound Authentication (HOBA) is a variation on TLS
      client authentication and uses a digital-signature-based design
      for an HTTP authentication method (see [RFC7486]).  The design can
      also be used in JavaScript-based authentication embedded in HTML.
      HOBA is an alternative to HTTP authentication schemes that require
      passwords and therefore avoids all problems related to passwords,
      such as leakage of server-side password databases.

   Bearer Tokens
      Bearer tokens [RFC6750] MAY be used when combined with TLS and a
      token framework such as OAuth2 [RFC6749].  See Section 7.3 for
      security considerations regarding the use of bearer tokens in
      SCIM.  While bearer tokens most often represent an authorization,
      it is assumed that the authorization was based upon a successful
      authentication of the SCIM client.  Accordingly the SCIM service
      provider must have a method for validating, parsing, and or
      introspecting the bearer token for the relevant authentication and
      authorization information.  The method for this is assumed to be
      defined by the token issuing system and is beyond the scope of
      this specification.

   POP Tokens
      A proof-of-possession token demonstrates the presenter of the
      token possesses a particular key and that the recipient can
      cryptographically confirm proof-of-possession of the key by the
      presenter.  This property is sometimes also described as the
      presenter being a holder-of-key.  See OAuth
      [I-D.ietf-oauth-pop-architecture] for an example of such a token
      and its use.

   Cookies
      Javascript clients MAY assert HTTP cookies over TLS that contain
      an authentication state that is understood by the SCIM service
      provider (see [RFC6265]).  An example of this is scenarios where
      web-form authentication has taken place with the user and HTTP
      cookies were set representing the authentication state.  For the
      purposes of SCIM, the security considerations in Section 7.3
      apply.

   As per Section 4.1 of [RFC7235], a SCIM service provider SHALL
   indicate supported HTTP authentication schemes via the "WWW-
   Authenticate" header.

   For all of the above methodologies, the SCIM service provider MUST be
   able to map the authenticated client to an access control policy in
   order to determine the client's authorization to retrieve and update
   SCIM resources.  For example, while a browser session may have been
   established via HTTP cookie or TLS client authentication, the unique
   client MUST be mapped to a security subject (e.g., User).  The
   authorization model and the process by which this is done is beyond
   the scope of this specification.

   Because SCIM is a protocol for provisioning resources cross domains
   (e.g., user accounts and access control information such as groups),
   weaker authentication mechanisms based on static symmetric secrets
   such as passwords SHOULD NOT be used.  In particular, the
   authentication schemes (e.g., Basic Authentication) described in
   [RFC2617] SHOULD NOT be used.

   When processing requests, the service provider SHOULD consider the
   subject performing the request and whether the action is appropriate
   given the subject and the resource affected by the request.  The
   subject performing the request is usually determined directly or
   indirectly from the "Authorization" header present in the request.
   For example, a subject MAY be permitted to retrieve and update their
   own "User" resource, but will normally have restricted ability to
   access resources associated with other Users.  In other cases, the
   SCIM service provider might only grant access to a subject's own
   associated "User" resource (e.g., for the purpose of updating
   personal contact attributes).

   For illustrative purposes only, examples show an OAuth2 bearer token
   value [RFC6750] in the authorization header; e.g.,

   GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1
   Host: example.com
   Authorization: Bearer h480djs93hd8

   This is not intended to imply that bearer tokens are preferred.
   However, the use of bearer tokens in the specification does reflect
   common implementation practice.

2.1.  Anonymous Requests

   In some SCIM deployments it MAY be acceptable to permit
   unauthenticated (anonymous) requests.  For example, a user self-
   registration request where the service provider chooses to accept a
   SCIM Create request (see Section 3.3) from an anonymous client.  See
   Section 7.5, for security considerations regarding anonymous
   requests.

------------------------------
Section 7 Proposed (note the example in 7.4 needs correction still):

7.  Security Considerations

7.1.  HTTP Considerations

   SCIM Protocol layers on top of Hypertext Transfer Protocol and thus
   subject to the security considerations of HTTP Section 9 [RFC7230]
   and its related specifications.

   As stated in Section 2.7.1 [RFC7230], a SCIM client MUST NOT generate
   the userinfo (i.e., username and password) component (and its "@"
   delimiter) when an "http" URI reference is generated with a message
   as they are now disallowed in HTTP.

7.2.  TLS Support Considerations

   SCIM resources (e.g., Users and Groups) can contain sensitive
   information including passwords.  Therefore, SCIM clients and service
   providers MUST require the use of a transport-layer security
   mechanism when communicating with SCIM service providers.  The SCIM
   service provider MUST support TLS 1.2 [RFC5246] and MAY support
   additional transport-layer mechanisms meeting its security
   requirements.  When using TLS, the client MUST perform a TLS/SSL
   server certificate check, per [RFC6125].  Implementation security
   considerations for TLS can be found in "Recommendations for Secure
   Use of TLS and DTLS" [RFC7525].

7.3.  Bearer and Cookie Considerations

   Since the posession of a bearer token or cookie MAY authorize the
   holder to potentially read, modify, or delete resources, tokens and
   cookies MUST contain sufficient entropy to prevent a random guessing
   attack, such as described in Section 5.2 of [RFC6750] and
   Section 5.1.4.2.2 of [RFC6819].

   As with all SCIM communications, Bearer tokens and HTTP cookies MUST
   be exchanged using TLS.

   Bearer tokens MUST have a limited lifetime that can be determined
   directly or indirectly (e.g., by checking with a validation service)
   by the service provider.  By expiring tokens, clients are forced to
   obtain a new token (which usually involves re-authentication) for
   continued authorized access.  For example, in OAuth2, a client MAY
   use OAuth token refresh to obtain a new bearer token after
   authenticating to an authorization server.  See Section 6 of
   [RFC6749].

   As with Bearer tokens, an HTTP cookie SHOULD last no longer than the
   lifetime of a browser session.  An expiry time should be set that
   limits session cookie lifetime as per Section 5.2.1 of [RFC6265].

7.4.  Privacy Considerations

7.4.1.  Personal Information

   The SCIM Core Schema specifications defines attributes that MAY
   contain personally identifying information as well as other sensitive
   personal data.  The privacy considerations in the Security
   Considerations Section of [I-D.ietf-scim-core-schema] MUST be
   considered.

7.4.2.  Disclosure of Sensitive Information in URIs

   As mentioned in Section 9.4 [RFC7231], SCIM clients requesting
   information using query filters using HTTP GET SHOULD give
   consideration to the information content of the filters and whether
   their exposure in a URI would represent a breach of security or
   confidentiality through leakage in a web browsers or server logs.
   This is particularly true for information that is legally considered
   "personally identifiable information" or is otherwise restricted by
   privacy laws.  In these situations to ensure maximum security and
   confidentiality, clients SHOULD query using HTTP POST (see
   Section 3.4.3 ).

   Servers that receive HTTP GET requests using filters that contain
   restricted or confidential information SHOULD respond with HTTP
   status 403 indicating the operation is FORBIDDEN.  A detailed error,
   "confidential_restricted" may be returned indicating the request must
   be submitted using POST.  A non-normative example:

  HTTP/1.1 403 FORBIDDEN

  {
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
    "Errors":[
      {
        "description":
          "Query filter involving 'name' is restricted or confidential",
        "error":"confidential_restricted"
      }
    ]
  }

7.5.  Anonymous Requests

   If a SCIM service provider accepts anonymous requests such as SCIM
   resource creation requests (via HTTP POST), appropriate security
   measures should be put in place to prevent or limit exposure to
   attacks.  The following counter-measures MAY be used:

   o  Try to authenticate web UI components that forumulate the SCIM
      creation request.  While the end-user MAY be anonymous, the web
      user interface component often has its own way to authenticate to
      the SCIM service provider (e.g., has an OAuth client credential
      [RFC6749]) and the web user interface component may implement its
      own measures (e.g., such as CAPTCHA) to ensure a ligitimate
      request is being made.

   o  Limit the number of requests any particular client MAY make in a
      period of time.

   o  For User resources, default newly created resource with an
      "active" setting of "false" and use a secondary confirmation
      process (e.g., email confirmation) to ensure the resource created
      is real.

7.6.  Secure Storage and Handling of Sensitive Data

   An attacker may obtain valid username/password combinations from the
   SCIM service provider's underlying database by gaining access to the
   database and/or launching injection attacks.  This could lead to
   unintended disclosure of username/password combinations.  The impact
   may extend beyond the domain of the SCIM service provider if the data
   was provisioned from other domains.

   Administrators should undertake industry best practices to protect
   the storage of credentials and in particular SHOULD follow
   recommendations outlines in Section 5.1.4.1 [RFC6819].  These
   recommendations include but are not limited to:

   o  Provide injection attack counter measures (e.g., by validating all
      inputs and parameters),

   o  No cleartext storage of credentials,

   o  Store credentials using an encrypted protection mechanism, and

   o  Avoid passwords and consider use of asymmetric cryptography based
      credentials.

   As outlined in Section 5.1.4.2 [RFC6819], adminitrators SHOULD take
   counter measures to prevent online attacks on secrets such as:

   o  Utilize secure password policy in order to increase user password
      entrophy to hinder online attacks and password guessing,

   o  Mitigate attacks on passwords by locking respective accounts have
      a number of failed attempts,

   o  Use "tar pit" techniques by temporarily locking a respective
      account and delaying responses for a certain duration.  The
      duration may increase with the number of failed attempts, and

   o  Use authentication system that use CAPTCHA's and other factors for
      authenticating users further reducing the possibility of automated
      attacks.

7.7.  Case Insensitive Comparison & International Languages

   When comparing unicode strings such as in query filters or testing
   for uniqueness of usernames and passwords, strings MUST be
   appropriately prepared before comparison.  See Section 5.

> On Apr 29, 2015, at 1:31 PM, Phil Hunt <[email-masked]> wrote:
> 
> Thanks. I think we have a plan!
> 
> Phil
> 
> On Apr 29, 2015, at 13:27, Kathleen Moriarty <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Hi Phil,
>> 
>> On Wed, Apr 29, 2015 at 4:15 PM, Phil Hunt <[email-masked] <mailto:[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 <[email-masked] <mailto:[email-masked]>> wrote:
>> >
>> > 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] <mailto:[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
>> >>
>> >>> On Apr 29, 2015, at 1:13 PM, Phil Hunt <[email-masked] <mailto:[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.
>> >
>> > 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 <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 <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
>> >
>> >
>> >>>
>> >>> Phil
>> >>>
>> >>> [email-masked] <mailto:[email-masked]>
>> >>>
>> >>>> On Apr 28, 2015, at 5:54 PM, Kathleen Moriarty <
>> >> [email-masked] <mailto:[email-masked]>> wrote:
>> >>>>
>> >>>> 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 <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/ <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 <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/ <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).
>> >>> [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=
>> 
>> 
>> 
>> -- 
>> 
>> Best regards,
>> Kathleen
>> _______________________________________________
>> scim mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/scim <https://www.ietf.org/mailman/listinfo/scim>
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Patrick Radtke <[email-masked]>
Date: Wed, 6 May 2015 23:59:43 +0000

Everything looked good to me except the Cookie authentication for JavaScript clients - there is no guidance for CSRF protection.
Two Cookie/CSRF attack scenarios that come to mind (based on this doc)
http://docs.spring.io/spring-security/site/docs/4.0.2.CI-SNAPSHOT/reference/htmlsingle/#csrf-protection-and-json

  1.  Attacker site does cross site POST to /Users endpoint.  The Service provider does not check the Content-Type header, only looks at the Cookie and is fooled into thinking it is a legitimate request.
  2.  Attacker site does cross site POST using a URI suffix to /User.scim or /Users.json. The Service Provider’s REST framework automatically sets a Content-Type header based on URI suffix, and the actual implementation is fooled into thinking Content-Type header was set by the client.

Maybe some guidance along the lines of “To prevent CSRF attacks the service provider MUST check the Content-Type of the request and MUST NOT allow POSTs to uri suffixed endpoints"

-Patrick

From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, May 6, 2015 at 4:02 PM
To: Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, The IESG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scim] Kathleen Moriarty's Discuss on draft-ietf-scim-api-17: (with DISCUSS and COMMENT)

Kathleen,

Thanks for your help!

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

   Bearer Tokens

   POP Tokens

   Cookies

   GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1
   Host: example.com<http://example.com>
   Authorization: Bearer h480djs93hd8

2.1.  Anonymous Requests

7.1.  HTTP Considerations

  HTTP/1.1 403 FORBIDDEN

  {

7.5.  Anonymous Requests

On Apr 29, 2015, at 1:31 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Phil

On Apr 29, 2015, at 13:27, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:

Hi Phil,

On Wed, Apr 29, 2015 at 4:15 PM, Phil Hunt <[email-masked]<mailto:[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.

I hope that helps.

Thank you,
Kathleen

Thanks,

Phil

> On Apr 29, 2015, at 13:08, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:
>
> [email-masked]<mailto:[email-masked]>> wrote:
>
>> Hi Phil,
>>
>>> On Apr 29, 2015, at 1:13 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>> Kathleen,
>>>
> See section 2.3 of https://tools.ietf.org/html/rfc6749
> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg), basically
>>> [email-masked]<mailto:[email-masked]>
>>>
>> [email-masked]<mailto:[email-masked]>> wrote:
>>>>
>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>> https://datatracker.ietf.org/doc/draft-ietf-scim-api/
>>>>
>>>>
>>>>
>>>> see: https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions
>>>> https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/
>>>>

--

Best regards,
Kathleen
_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scim
_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scim

---

From: Phil Hunt <[email-masked]>
Date: Thu, 7 May 2015 08:32:23 -0700

Patrick & Kathleen,

Would a reference to the security considerations for RFC6265 “HTTP State Management Mechanism" cover this adequately?  

Phil

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

> On May 6, 2015, at 4:59 PM, Patrick Radtke <[email-masked]> wrote:
> 
>> It's specified as the default in OAuth 2.0 when using a token.  see above

---

From: Patrick Radtke <[email-masked]>
Date: Thu, 7 May 2015 16:52:38 +0000

I didn¹t catch that reference in my initial read through.
I think that RFC covers all the downsides associated with cookies.

-Patrick

On 5/7/15, 8:32 AM, "Phil Hunt" <[email-masked]> wrote:

>Patrick & Kathleen,
>
>Would a reference to the security considerations for RFC6265 ³HTTP State
>Management Mechanism" cover this adequately?
>
>Phil
>
>@independentid
>www.independentid.com
>[email-masked]
>
>> Everything looked good to me except the Cookie authentication for
>>JavaScript clients - there is no guidance for CSRF protection.
>>  1.  Attacker site does cross site POST to /Users endpoint.  The
>>Service provider does not check the Content-Type header, only looks at
>>the Cookie and is fooled into thinking it is a legitimate request.
>>  2.  Attacker site does cross site POST using a URI suffix to
>>/User.scim or /Users.json. The Service Provider¹s REST framework
>>automatically sets a Content-Type header based on URI suffix, and the
>>actual implementation is fooled into thinking Content-Type header was
>>set by the client.
>> 
>> Maybe some guidance along the lines of ³To prevent CSRF attacks the
>>service provider MUST check the Content-Type of the request and MUST NOT
>>allow POSTs to uri suffixed endpoints"
>> 
>> -Patrick
>> 
>> To: Kathleen Moriarty
>><[email-masked]<mailto:[email-masked]
>>>>
>> Cc: 
>>"[email-masked]<mailto:[email-masked]>"
>> 
>><[email-masked]<mailto:[email-masked]>>
>>, "[email-masked]<mailto:[email-masked]>"
>><[email-masked]<mailto:[email-masked]>>,
>>"[email-masked]<mailto:draft-ietf-scim-api.shepher
>>[email-masked]>" 
>><[email-masked]<mailto:draft-ietf-scim-api.shepher
>>[email-masked]>>, The IESG <[email-masked]<mailto:[email-masked]>>,
>>"[email-masked]<mailto:[email-masked]>"
>><[email-masked]<mailto:[email-masked]>>,
>>"[email-masked]<mailto:[email-masked]>"
>><[email-masked]<mailto:[email-masked]>>
>> Subject: Re: [scim] Kathleen Moriarty's Discuss on
>>draft-ietf-scim-api-17: (with DISCUSS and COMMENT)
>> 
>> Kathleen,
>> 
>> Apologies for pasting a lot of text in here, but after considering
>>comments from you and Brian, I wanted to re-think a number of things and
>>try and boil things down a bit (I probably can do some more). I¹ve
>>essentially re-written the authentication and security sections with
>>care not to change consensus, but to address the issues you mentioned.
>>I hope we are close.  Please take a look at the pasted sections below.
>>If you are in agreement, I can post them in the next document update.
>> 
>> Thanks for your help!
>> 
>> Phil
>> 
>> @independentid
>> On Apr 29, 2015, at 1:31 PM, Phil Hunt
>><[email-masked]<mailto:[email-masked]>> wrote:
>> 
>> On Apr 29, 2015, at 13:27, Kathleen Moriarty
>><[email-masked]<mailto:[email-masked]
>>>> wrote:
>> 
>> Hi Phil,
>> 
>> On Wed, Apr 29, 2015 at 4:15 PM, Phil Hunt
>><[email-masked]<mailto:[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.
>> 
>> 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]<mailto:[email-masked]
>>>m>> wrote:
>>> 
>>>[email-masked]<mailto:[email-masked]
>>>>> wrote:
>>> 
>>>> Hi Phil,
>>>> 
>>>>> On Apr 29, 2015, at 1:13 PM, Phil Hunt
>>>>><[email-masked]<mailto:[email-masked]>> wrote:
>>>>> 
>>>>> Kathleen,
>>>>> 
>>>>> Thanks for your comments. My comments in lineŠ
>>>>> 
>>>> such as RFC2617¹s basic authentication.  For this reason we did not
>>>>want to

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 8 May 2015 08:58:45 +0100

Hi,

The text is very much improved, thank you for your efforts!

I do have some suggestions and will propose text around the bearer tokens text to include text on the defaults for authentication of oauth bearer tokens (http Basic, none & secret) as well as to the link to the security considerations previously mentioned for bearer tokens.  I won't have time until later today, so if you're able to propose something with the previous references provided (including the updated HTTP basic draft for sec considerations, I might be able to clear sooner do you can update the draft.

Thank you!
Kathleen 

Sent from my iPhone

> On May 7, 2015, at 5:52 PM, Patrick Radtke <[email-masked]> wrote:
>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 8 May 2015 09:09:06 -0700

Ok. Sounds good. 

I have some other items from Elwyn to do (on both drafts). Eg use relative uri's in the examples

Based on your comments we are in good shape for a new rev for the weekend which should give lots of time for the telechat. 

Thanks,

Phil

> On May 8, 2015, at 00:58, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hi,
>

---

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

Kathleen,

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:
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> What is specified now is really an authorization protocol, so you'll need
> work directly with other HTTP Auth methods like HOBA? The OAuth folks are
[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...

> 
> 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?

[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
> 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.

[PH] Agreed, we should update this. 
> 
> 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.

[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?
> 
> 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.

[PH] I will await your comments.
> 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:
> 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.

[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: Phil Hunt <[email-masked]>
Date: Wed, 29 Apr 2015 13:15:53 -0700

Thanks,

Phil

> On Apr 29, 2015, at 13:08, Kathleen Moriarty <[email-masked]> wrote:
> 
> [email-masked]> wrote:
> 
>> Hi Phil,
>> 
>>> On Apr 29, 2015, at 1:13 PM, Phil Hunt <[email-masked]> wrote:
>>> 
>>> Kathleen,
>>> 
>> [email-masked]> wrote:
>>>>