[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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/members/leave _workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]