[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Encryption Usecases and Requirements
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]