RE: REVISED Issue Group 12, yet again.

[Darren Platt <dplatt@securant.com>]

Irving,

I'm not sure how these options are different (for issue 12-03):

> 1) Add the requirement:
> [R-BindingConfidentiality] Each protocol binding should include a
> description of how the confidentiality of SAML data can be
> protected within
> that binding. Examples: S/MIME for MIME, HTTP/S for HTTP.
>
> 2) Add the requirement:
> [R-BindingConfidentiality] Each protocol binding must ensure that
> SAML data
> is protected from observation by third parties.

I think if I were to require what is in #2, then I'd want a description of
how it is done (which is required by #1).

Sorry for the late comment.

Thanks,

Darren




> -----Original Message-----
> From: Irving Reid [mailto:Irving.Reid@baltimore.com]
> Sent: Thursday, March 29, 2001 2:42 PM
> To: 'security-use@lists.oasis-open.org'
> Subject: REVISED Issue Group 12, yet again.
>
>
> OK, here we go again, based on the discussion during the 03/28 conference
> call.
>
> I've taken most of the previous questions and rolled them into the
> introductory text. I've tried to capture the discussion on possible
> resolution, along with the comments from ballots, in the suggested
> resolutions. I've also reworded things to refer only to confidentiality
> protection; I think [R-Signature] already addresses message integrity.
>
> Please please please comment quickly, if you have comments, so that Darren
> can include this in next week's ballot without generating another round of
> debate. In particular, there are a couple of places where I
> suggest possible
> limits on how much detail we put in the Use Case document.
>
> Note that my use of 'should' in the proposed requirements matches that in
> the existing requirements list in Strawman 3.
>
>  - irving -
>
> ------------------------------------------------------
> Issue Group 12:
>
> UC-9-02:PrivacyStatement addresses the
> importance of sharing data only as needed between security zones (from
> asserting party to relying party). However, it is also important that data
> not be available to third parties, such as snoopers or untrusted
> intermediaries.
>
> One possible solution for protocol bindings to define secure channels
> between
> relying party and asserting  party. Another is specifically
> encrypt the SAML
> data, so that it is protected whether or not the channel is
> secure, and can
> also be stored securely outside of the protocol binding (for example, in a
> cache or as a cookie).
>
> If confidentiality protection is specified both within the SAML message
> format and within protocol bindings, deployments can choose the
> appropriate
> solution. For example, SAML messages within encrypted S/MIME documents may
> not need message-level protection, while SAML messages passed as HTTP
> cookies do.
>
> The issues addressed here also relate to [R-Signature],
> ISSUE:[UC-13-02:EfficientMessages],
> ISSUE:[UC-13-03:OptionalAuthentication],
> and ISSUE:[UC-13-04:OptionalSignatures]. In particular, we would be
> contradicting ourselves if we voted that confidentiality
> protection is required without exception, and at the same time voted for
> option 1 on any of the UC-13 issues listed above. The point raised in the
> UC-13 issues is that within a protected security domain where
> confidentiality
> protection is not a concern, requiring encryption could introduce key
> management and performance issues that could otherwise be avoided.
>
>
> This issue breaks down into several decisions:
>
> Should confidentiality protection of SAML messages be
> required, optional, or unsupported?
>
> Should confidentiality protection be provided by the protocol
> binding or within the SAML message format?
>
> What (if any) encryption method should be used now?
>
> What (if any) encryption method should be used once XML Encryption is
> a published standard?
>
>
> ------------------------------------------------------------------
> ----------
>
> ISSUE:[UC-12-01:Confidentiality]
>
> Add the following requirement:
>
> [R-Confidentiality] SAML data should be protected from
> observation by third
> parties or untrusted intermediaries.
>
> Proposed Solutions:
>
> 1) Add [R-Confidentiality]
> 2) Do not add [R-Confidentiality]
>
> ------------------------------------------------------------------
> ----------
>
>
> IRVING'S NOTE: We could just stop here, and leave the rest of the
> details to
> the Core Assertions, Bindings and Security Considerations groups.
>
>
>
> ------------------------------------------------------------------
> ----------
>
> ISSUE: [UC-12-02:AssertionConfidentiality]
>
> Proposed solutions; choose one of:
>
> 1) Add the requirement:
> [R-AssertionConfidentiality] SAML should define a format so that
> individual
> SAML assertions may be encrypted, independent of protocol bindings.
>
> 2) Add the requirement:
> [R-AssertionConfidentiality] SAML assertions must be encrypted,
> independent
> of protocol bindings.
>
> 3) Add a non-goal:
> SAML will not define a format for protecting confidentiality of individual
> assertions; confidentiality protection will be left to the protocol
> bindings.
>
> 4) Do not add either requirement or the non-goal.
>
> In either case, Use Cases should be edited to call out this requirement
> where appropriate.
>
> ------------------------------------------------------------------
> ----------
> -
>
> ISSUE: [UC-12-03:BindingConfidentiality]
>
> Proposed solutions; choose one of:
>
> 1) Add the requirement:
> [R-BindingConfidentiality] Each protocol binding should include a
> description of how the confidentiality of SAML data can be
> protected within
> that binding. Examples: S/MIME for MIME, HTTP/S for HTTP.
>
> 2) Add the requirement:
> [R-BindingConfidentiality] Each protocol binding must ensure that
> SAML data
> is protected from observation by third parties.
>
> 3) Do not add either requirement.
>
> In either case, Use Cases should be edited to call out this requirement
> where appropriate.
>
> ------------------------------------------------------------------
> ----------
>
> IRVING'S NOTE: I wouldn't mind if
> ISSUE:[UC-12-03:EncryptionMethod] was left
> out of the use cases document, and left up to the other
> subcommittees. It's
> really more of a design issue than a requirement.
>
> ISSUE:[UC-12-03:EncryptionMethod]
>
> If confidentiality protection is included in the SAML assertion
> format (that
> is, you chose option 1 or 2 for ISSUE:
> [UC-12-02:AssertionConfidentiality]),
> how should the protection be provided?
>
> Note that if option 2 (assertion confidentiality is required) was
> chosen for
> UC-12-02, resolution 1 of this issue implies that SAML will not
> be published
> until after XML Encryption is published.
>
> Proposed resolutions; choose one of:
>
> 1) Add the requirement:
> [R-EncryptionMethod] SAML should use XML Encryption.
>
> 2) Add the requirement:
> [R-EncryptionMethod] Because there is no currently published standard for
> encrypting XML, SAML should define its own encryption format.
> Edit the existing non-goal of not creating new cryptographic techniques to
> allow this.
>
> 3) Add no requirement now, but include a note that this issue must be
> revisited in a future version of the SAML spec after XML Encryption is
> published.
>
> 4) Do not add any of these requirements or notes.
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: security-use-request@lists.oasis-open.org
>