RE: [security-services] Encryption Usecases and Requirements

["Philpott, Robert" <rphilpott@rsasecurity.com>]

Well, I believe this was primarily brought up in the context of sending a
query that asks for attributes for a particular subject.  If there is a need
to encrypt info about a subject and their attribute values in a response,
the question was whether there's a requirement to apply the sam privacy
requirements when the subject and the names of the attributes are sent in a
query.  Also, is it reasonable to want to hide the name of the resource that
a subject is attempting to access when sending an Authz request.  What about
an assertion embedded as evidence in a query?  Should some of it's contents
be able to be encrypted?

I'm not sure there is a need on a response to encrypt as long as the entire
assertion within a response can be encrypted.  But there may be requirements
for it in the request/query.

Rob Philpott 
RSA Security Inc. 
The Most Trusted Name in e-Security 
Tel: 781-515-7115 
Mobile: 617-510-0893 
Fax: 781-515-7020 
mailto:rphilpott@rsasecurity.com 


> -----Original Message-----
> From: Hal Lockhart [mailto:hlockhar@bea.com]
> Sent: Tuesday, December 09, 2003 9:58 AM
> To: Mishra, Prateek; security-services@lists.oasis-open.org
> Cc: cantor.2@osu.edu; eve.maler@sun.com
> Subject: RE: [security-services] Encryption Usecases and Requirements
> 
> Sorry I missed to focus group call.
> 
> I left out encrypting requests and responses deliberately. What is the
> reason for encrypting them? In general their contents will mostly be known
> or contain non-sensitive information. I don't object to making this a
> requirement if there is a valid reason, but it will be more trouble so I
> don't want to do it without a justifying use case.
> 
> Like you I am not an XML guy, but as I understand it, making the encrypted
> data schema-valid will require tweaking the entire schema to add optional
> alternative elements everywhere. I want everybody to understand the
> implications of and reasons for this requirement. It would certainly be
> much
> easier to drop it. Both Scott and Eve pressed for it at the F2F. Perhaps
> they can speak to this point on the call today.
> 
> Hal
> 
> > -----Original Message-----
> > From: Mishra, Prateek [mailto:pmishra@netegrity.com]
> > Sent: Friday, December 05, 2003 2:45 PM
> > To: 'Hal Lockhart'; security-services@lists.oasis-open.org
> > Subject: RE: [security-services] Encryption Usecases and Requirements
> >
> >
> > Hi Hal,
> >
> > A couple of comments, most of which originate from the minutes of
> > the focus
> > call.
> >
> > One general comment is that in addition to assertions, requests and
> > responses may also be encrypted.
> >
> > UseCase #1* then reads: Provide confidentiality for all elements in a
> SAML
> > request, response, or assertion.
> >
> > Usecase #4 is stated very generally and raised some concerns. Is
> > the intent
> > here that any sub-elements of a SAML assertion/request/response may be
> > encrypted?
> >
> > If so, should we restate it as:
> >
> > Usecase #4*: Selective encryption of sub-element(s) of a SAML request,
> > response or assertion.
> >
> >
> > Another set of questions had to do with the "Encrypted data remains
> > schema-valid" requirement. I am not an expert in this area but
> > both Usecase
> > #1* and Usecase #4* seem to violate this requirement. So I don't really
> > follow where this requirement originates from. I can see that
> > Usecase #2 or
> > #3 might imply it, but then it is specific to these use-cases? As
> > opposed to
> > a general requirement?
> >
> > - prateek
> >
> > -----Original Message-----
> > From: Hal Lockhart [mailto:hlockhar@bea.com]
> > Sent: Tuesday, November 25, 2003 11:01 AM
> > To: security-services@lists.oasis-open.org
> > Subject: [security-services] Encryption Usecases and Requirements
> >
> > Hopefully this brief message will be sufficient to outline the
> > usecases and
> > requirements for encryption in SAML 2.0. Comments are requested.
> >
> > Usecase #1: Provide confidentiality of all the information in all the
> > statements in a SAML Assertion.
> >
> > The purpose might be to preserve individual privacy or to protect
> > individual
> > or corporate intellectual property via secrecy.
> >
> > Usecase #2: Provide confidentiality of the Name Identifier element.
> >
> > This usecase is identified in "Name Identifier Profiles and Management."
> > This usecase requires that the encrypted Name Identifier be
> > Schema-valid, so
> > that an intermediary can process the entire Assertion
> > syntactically without
> > being able to decrypt the value. It is not clear if the requirment is to
> > encrypt the element or just the value.
> >
> > Usecase #3: Provide confidentiality of an element value
> > containing a secret,
> > such as a password or secret key.
> >
> > The elements most likely to be encrypted in this usecase are
> > SubjectConfirmationData, ds:KeyInfo, Attribute and
> > AttributeValue. (Assuming
> > the Attribute contined some kind of secret.) Since the information in
> the
> > Assertion may be retained for some time and used repeatedly, it is not a
> > requirement that the encryption format provide protection against
> > replay. In
> > other words, a party making use of an encrypted secret should
> > decrypt it and
> > then employ a replay protection mechanism specified elsewhere, if
> > available,
> > in using the value for the purposes of Authentication.
> >
> > Usecase #4: Provide selective confidentiality protection of some of
> > statement contents.
> >
> > The motives are the same as in #1, but for some reason it is desired to
> > protect only portions of the statements. Note that this usecase
> > and #3 imply
> > that distinct portions of statements may be protect with distinct keys,
> so
> > that they may be accessable to distinct receiving parties.
> >
> >
> > Requirements:
> >
> > Encryption of all or any portions of statements.
> > Encryption based on XML Encryption.
> > Encrypted data remains schema-valid.
> > Signature if present, is always applied before any encryption.
> >
> > Non-requirments:
> >
> > Ablity to encrypt Assertion header information.
> > Ability to determine data to be decrypted without parsing entire
> > assertion.
> > Ability to encrypt requests or responses (Use TLS).
> > Ability to perform decryption of selected elements without retaining the
> > entire assertion. (This may turn out to be possible, but it is listed as
> a
> > non-requirement.
> >
> > Open questions:
> >
> > Is a mechanism required to specify the decryption key other than what is
> > provided by XML Encryption?
> > Should we profile XML Encryption to eliminate some options?
> >
> > Hal
> >
> >
> > To unsubscribe from this mailing list (and be removed from the
> > roster of the
> > OASIS TC), go to
> > http://www.oasis-open.org/apps/org/workgroup/security-services/mem
> bers/leave
> _workgroup.php.
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of
> the OASIS TC), go to http://www.oasis-
> open.org/apps/org/workgroup/security-services/members/leave_workgroup.php.