OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-bindings message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: ISSUE:[UC-12-01:Encryption] (was RE: Comments on Straw Man 2 : Protection of message contents)


I think the terminology needs to be used very carefully here.  There are
three "quality of protection"
attributes we could talk about:

(1) Confidentiality : protection of information against disclosure to
parties without a need to know
(2) Integrity : protection of information against modification by parties
not authorized to modify it
(3) Privacy : protection of sensitive, individually identifiable
information against disclosure without the subject's consent

I think the note below uses "privacy" when it means "confidentiality".

Confidentiality and integrity SHOULD be the job of the binding; privacy
probably CANNOT be protected by
any mechanism we specify in the binding, except in the trivial sense that
we can protect private data from
disclosure to eavesdroppers and active wiretappers (which is
indistinguishable from confidentiality protection).

--bob

Bob Blakley
Chief Scientist
Enterprise Solutions Unit
Tivoli Systems, Inc. (an IBM Company)


"Ahmed, Zahid" <zahid.ahmed@commerceone.com> on 02/26/2001 11:22:20 PM

To:   "'Irving Reid'" <Irving.Reid@baltimore.com>,
      security-use@lists.oasis-open.org
cc:   "'security-bindings@lists.oasis-open.org'"
      <security-bindings@lists.oasis-open.org>
Subject:  RE: ISSUE:[UC-12-01:Encryption]  (was RE: Comments on Straw Man 2
      : Pr otection of message contents)



>Each binding must include a description of how the privacy and
>integrity of SAML messages can be protected within that binding.
>Examples:
S/MIME for MIME, HTTP/S for HTTP.

I agree with above suggestion; some discussion of this binding
approach is included in the S2ML v. 0.8 spec, particularly for
securing SAML assertions S/MIME based message payloads in
Section 6.3 of S2ML v. 0.8.

The Binding group, IMO, will need to specify general requirements
of protecting SAML assertions included in a message (message
integrity protection and message privacy both are needed) across
a range of messaging and application protocols.

Suggestion#1 of employing XML encryption, in support of SAML
information being accessible to an authorized party, will not be
sufficient in itself although could be applicable in conjunction
with a secure transport or S/MIME messaging. Furthermore, XML
encryption is a standard-in-progress.

----Zahid



-----Original Message-----
From: Irving Reid [mailto:Irving.Reid@baltimore.com]
Sent: Monday, February 26, 2001 8:10 PM
To: security-use@lists.oasis-open.org
Subject: ISSUE:[UC-12-01:Encryption] (was RE: Comments on Straw Man 2:
Pr otection of message contents)


This clearly can't be ready for ballot before the F2F, but I thought I'd
respond to Darren's suggestion. What follows is my modified suggestion for
issue ballot text:


ISSUE:[UC-12-01:Encryption] 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 implementors is to use secure channels between
relying party and asserting party. Another is to use encryption, either
with
a shared secret or with public keys.

Possible Resolutions:

1) Include an allowance for explicit use of encryption, such as XML
Encryption (http://www.w3.org/Encryption/2001/), within SAML messages. SAML
messages could then be transferred securely on any protocol.
2) Specify security properties in the Bindings documents. Each binding must
include a description of how the privacy and integrity of SAML messages can
be protected within that binding. Examples: S/MIME for MIME, HTTP/S for
HTTP.

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: security-use-request@lists.oasis-open.org

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: security-use-request@lists.oasis-open.org




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC