Re: [scim] Comments for draft-ietf-scim-cursor-pagination-04

Hi Nancy -- I authored the Security Considerations section of the draft so
will be happy to address those questions:

* Section 5: it would be good to mention that this draft is under the same
> Security and privacy considerations of those described in RFC 7644.

 Sure, Anjali has added this in her most recent PR:

https://github.com/ietf-scim-wg/draft-ietf-scim-cursor-pagination/pull/12/commits

Which we worked on approving this morning.

* Section 5.1 is a nice overview, however guidance to this document’s
> affects
> Should be described.  That is….I am not sure this document has in scope to
> Provide guarantees of the authenticity nor the entitlements of the
> entities
> Acting as either clients or Service Providers.  My suggestion is to either
> remove
> This or provide a note that implementers but provide guards against source
> Depletion or DOS attacks.

Sure, Danny, Anjali and I had several good discussions about this.
Ultimately we decided to defer to this guidance from the IETF Wiki on Sec
Dir <https://wiki.ietf.org/group/sec/typicalSECareaissues>:

*"This document introduces no new security considerations [on top of the
base protocol spec]" is rarely true. They may not be substantially
different from existing ones or significant given the broader context, but
that doesn't mean we can skip discussing them.*

Thus our preference is to keep section 5.1 present and intact as-is. We
feel that the considerations we wrote up in section 5 *are* those that are
most relevant to the new (cursor based pagination) functionality introduced
in this draft; we did not try to address the broader security
considerations of 7644 as those do definitely belong in 7644. If there are
any

If there is other IETF guidance we should be looking at, let us know and we
can incorporate that into the draft. If there are specific considerations
we listed that you feel aren't relevant to cursor-based pagination, let us
know which those are and we can reconsider those.

> Section 5.2/5.3: why should this be different than what is
> called/described in RFC 7644?

As above, the SECDIR guidance seems to point towards encouraging
discussions about the additive considerations over and above the base spec.
In this case, a well-meaning but not-security-aware implmentor might choose
to support cursor-based pagination by, for instance, making a static copy
of a data result set and letting the requestor page through it. This would,
then, not reflect changes in the requestor's permissions -- thus we noted
that authorization checks MUST be continuously applied. We do feel that
this and the other considerations in 5.1/5.2 are valuable elements for
implementors to be made aware of and are considerations that go beyond
those in the base spec's section 7
<https://datatracker.ietf.org/doc/html/rfc7644#section-7> -- but again, let
us know if there are specific considerations we listed that you don't feel
are specific to cursor-based pagination.

Thanks,

--Paul

On Tue, Mar 12, 2024 at 5:31 PM Nancy Cam-Winget (ncamwing) <ncamwing=
40cisco.com@dmarc.ietf.org> wrote:

> Hi!
>
>
>
> I’ve read version -04 of the Cursor Pagination draft and have the
> following feedback:
>
>
>
> *General comments*
>
> * I do not see any of the “should” as “SHOULD” though in some of the
> reading
>
>  Perhaps there are instances in which they are perhaps requirements and
> should be capitalized.
>
> Simli
>
> * Section 2.4 “…method as-is will not impact”,  this statement implies
> that
>
>    any implementation that adds cursor-based pagination support not impact
>
>    existing clients but that is based on implementation, my recommendation
>
>    is to make the “will” to a “should”.
>
>
>
> * Section 4: in trying to be complete with the descriptions,
>
>  It would be good to include descriptions of: what happens if the
> pagination
>
> configuration omits the one of the two values e.g. “cursor” or “index”,
> should
>
> That result in an error?  And obviously (but better to make explicit) that
> it
>
> Is a misconfiguration to have both be false.  Lastly, the absence of this
>
> Configuration setting means only index is supported.
>
> What does it mean for both to be supported?  How could a client use
>
> Both index and cursor pagination? Is it, that the cursor is “reset” from
> cursor
>
> By the use of startIndex (for example?) or is the intent that a client
> only use
>
> One or the other?
>
>
>
> * Section 5: it would be good to mention that this draft is under the same
>
> Security and privacy considerations of those described in RFC 7644.
>
>
>
> * Section 5.1 is a nice overview, however guidance to this document’s
> affects
>
> Should be described.  That is….I am not sure this document has in scope to
>
> Provide guarantees of the authenticity nor the entitlements of the
> entities
>
> Acting as either clients or Service Providers.  My suggestion is to either
> remove
>
> This or provide a note that implementers but provide guards against source
>
> Depletion or DOS attacks.
>
>
>
> Section 5.2/5.3: why should this be different than what is
> called/described in RFC 7644?
>
>
>
> *Editorial Nits*
>
> * Section 2.1 “…other error condition” should read “….other error
> conditions”
>
>
>
> Let me know if you have any questions on the above.  Otherwise, I would
> like to see
>
> Another revision as well as feedback from Barry, Roni and Julien to ensure
> their comments
>
> Are also addressed.
>
>
>
> Thanks, Nancy
>
>
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim
>