Security defaults

[Brent Putman]

On 5/17/14 12:47 PM, Cantor, Scott wrote:
> So, correct me, but the purpose of listing multiple algorithms is
> basically to "survive" a blaclist imposed at some level? So if the first
> one in the list is blacklisted, the order matters because it will pick the
> second.

Yes, exactly.

Think of the algorithm lists as expressions of:

1) capability (just by virtue of presence in the list)
2) preference (ordered, so first one wins)

In contrast, the whitelist/blacklist is an expression of policy.  An
algorithm must pass the whitelist/blacklist eval, or it doesn't get
used, period (applies to algos in metadata as well).

So in the effectively configured algorithm list (i.e. all the configs
logically combined in order), you need to enumerate all the ones you are
capable and (potentially) willing to use.  As I earlier mentioned,
listing multiples is practically speaking really only necessary for the
special case of the lowest level default config, just to get them all in
there.  That's to then allow a more natural use of the higher
order-of-precedence configs, wherein:

1) you just might list the single algorithm that you want to state as a
preference at that level (goes to the head of the list in front of the
others)
or
2) you just blacklist/whitelist some algorithms at that level, e.g.
setting an IdP or RP-specific policy



>
> It's a little confusing I think because if you look at, say, RSA PKCS 1.5
> key transport, which we'll be blacklisting, having it listed in the global
> defaults seems kind of odd.

Ah, I just missed that particular one.  I didn't know we literally
wanted to blacklist that.  If that is the case, then we would do like I
already did there for the MD5 signing and digest variants: put it in the
blacklist and do NOT put it in the algorithm list.



> I guess I understand the point, not having to add it back there if
> somebody wants to override the blacklist for a particularly regressive SP?


No, my intention would be the opposite: if someone really wants to use a
weak or broken algorithm (and that we blacklist by default) for a
regressive SP, they absolutely should have to jump through hoops. 
Specifically:
1) they would have to include that algo in the appropriate algorithm
list, obviously.  It's not otherwise listed by us by default.
2) blacklists merge now by default (as of last night), so they'd have to
also set the blacklist merge flag on the RP-specific config to false. 
Otherwise the blacklist from the global config would preclude it.


Speaking of blacklists: I suppose that for the IdP, the blacklists could
be explicitly duplicated in the IdP global config, with merging set to
false.  Then it becomes more explicit to people what is blacklisted, and
theoretically makes it possible for them to easily change (although we
obviously wouldn't recommend it, at least for the IdP-wide config).


>
> It's going to be pretty crucial to document the steps you want to take to
> do certain things here.


I agree, although I've tried to design this so that doing things for the
common cases is easy and natural and requires minimal data/typing.

It's true that in some cases, depending on what you want to do, there
may be more than one way to achieve a particular desired effect, so that
certainly deserves documenting.  For example, in the absence of metadata
info (so algorithms coming solely from config), adding an algo (assumed
to already be in the config somewhere) to the RP's whitelist would have
the same effect as adding it explicitly to RP's algorithm list: it's the
one that would get used, albeit for different reasons (policy vs
preference).  However, in the presence of relevant metadata info, the
behavior would potentially be different: metadata algos are considered
before looking at config algos and will be used as long as they pass the
whitelist/blacklist policy.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140517/70d51d95/attachment.html