Straw-man for security parameter placement

[Brent Putman]

On 3/12/14 6:23 PM, Cantor, Scott wrote:
> On 3/12/14, 5:33 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>> 2) in the later actions that do the encryption e.g. Assertions:
>>
>> if (effectivelyEncryptAssertion()) {
>>  EncryptionParameters params = getEncryptionParams(relyingPartyContext)
>>  encryptAssertion(assertion, params)
>> }
> The crux of my message was this, I misunderstood your intent. I thought
> you said you wanted the presence of the parameters to signal whether to
> encrypt, so that meant that a single parameters instance wouldn't be
> enough.

Ok.  I'm not sure exactly what I said or where, but in general:  If
there is a natural place in the PRC tree to put the EncryptionParameters
for each of the 3 cases so as to use the presence/absence to signal
(either hanging a SecurityParametersContext underneath something, or
adding named slot(s) for the params), than that's fine.  If not, then
having the IdP config params evaled twice (early on for resolution,
later for the encryption op) is also fine.  I'm actually neutral on
that, I don't have strong feelings either way.

I was mainly just pointing out that, for a given RP, the
EncryptionParams for the 3 cases would all contain the same data, if not
literally be the same instance (assuming we don't want it to contain an
auto-generated ephemeral data encryption key).


>
> I think what you meant to say was you wanted the option to encrypt to
> determine whether to resolve the parameters, which isn't quite the same
> thing. Same with signing, except that in that case, it's at least
> coincidentally possible to actually use that as a signal later because
> there are only two locations where we'd put parameters for signing, and
> those match the two common cases for signing, the assertions and the
> response.

Yes.  Signing is easier as you say, because there's already 2 natural
distinct spots to put the params (MessageContext for protocol message,
somewhere underneath the ProfileRequestContext for assertion).

For encryption, I'd say it's just whatever makes the most sense.  You
are much more familiar with the PRC hierarchy than I am.



>
>>
>> 1) It could turn out that based on -Configurations + metadata +
>> whitelist/blacklist, you wind up with different resolved values for the
>> data encryption algorithm URI.  In general I guess you then attempt to
>> extract the lowest (or highest) common denominator.
>> But it's also possible (based on say whitelist/blacklist values) that
>> you could theoretically wind up with mutually exclusive choices.  So then
>> I'm not sure what you do...
> I thought of that recently, and I think given the obscureness of the use
> case itself, we don't need to do more than behave predictably (which right
> now might mean failing or needing a new class we haven't implemented yet).


Short of failing, an option of last resort that seems easy and
defensible is perhaps just falling back to an algorithm that is required
to be supported by the XML Encryption spec.  AES-128-CBC and AES-256-CBC
are, for example.  Although the CBC mode is of course problematic.

I just realized that there is also theoretically a parallel issue with
signing.  For the protocol message signature I think it's pretty clear
that you only consider the SAML requester's metadata prefs and IdP
configuration.  But for the assertion, it's less clear since the
assertion itself will be consumed by multiple RP's.  I suppose we could
just say that the SAML requester's prefs and config wins.  And maybe a
similar strategy makes sense for the encryption data encryption
algorithm URI also.  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140312/47b77457/attachment-0001.html