RE: [security-services] Encryption Usecases and Requirements

["Hal Lockhart" <hlockhar@bea.com>]

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.