RE: [security-services] Encryption Usecases and Requirements

["Mishra, Prateek" <pmishra@netegrity.com>]

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/members/leave
_workgroup.php.