NotBefore condition in assertions

[Michael A Grady]

Scott, thanks for your answers and thoughts on this. I'd like to start a conversation about a possible patch to the latest IdP release that would add a configuration parameter concerning NotBefore, a patch that Unicon would propose to do as part of contributing back to the community. See below.

On Oct 16, 2012, at 10:09 PM, Cantor, Scott wrote:

> 
>> So maybe the security of SAML would be compromised if SAML assertions did
>> not contain NotBefore, but if that's the case, I'd like to understand
>> exactly why it is key to have it. Because the one thing I see NotBefore
>> yielding now is interoperability problems, because a number of SPs are
>> incapable/unwilling to apply skewing factors.
> 
> Omit it, and now a different set of SPs (or possibly some of the same
> ones) break.
> 

So from your feedback, it would appear that we have at least two problems with NotBefore:

 - SPs that interpret it "literally", and without any allowance for clock skew, and reject assertions for even just milliseconds of time difference (I've encountered this case, and there is clearly evidence in the Shib mailing list in the past that others have encountered this interoperability problem.)

 - SPs that have decided that NotBefore is a *must* rather than optional, and reject assertions that don't contain a NotBefore condition. (I've never seen this myself, but since my IdP experience to date is with the Shib IdP, and the Shib IdP always sends NotBefore, I guess I wouldn't have come across this one. And is, for the same reason, also unlikely to have come up on the Shib mailing list.)

What we don't know -- unless someone on this list does and can confirm such -- is if there are SPs out there for which *both* of the above are true -- will fail if NotBefore is not present, and interpret NotBefore without allowance for skew.

> It's on the list of yet more toggles and switches to add to the IdP to
> deal with interoperability bugs.

And that's what Unicon would propose to do for NotBefore. If the community would like to see this, and if we can come up with an approach that the community is supportive of.

Now, unfortunately, the approach that I think is likely most effective, but that I imagine there would be strong objections to (including that it potentially goes against the standard and seems "nonsensical") would be to allow the IdP itself to support a "clock skew" amount for NotBefore -- have a configurable number of seconds that it subtracts from "now" (from the assertion issueInstant), so that NotBefore is actually earlier than the assertion was issued. (On a per Relying Party basis.) I certainly agree that seems nonsensical, saying "this assertion was valid even before it was created", but it would be effective even for an SP (if such exists) that have both of the above problems. It appears that Microsoft/ADFS ended up deciding to support this, see:

 http://blogs.technet.com/b/askds/archive/2008/11/21/adfs-saml-tokens-and-validation-issues-when-federated-with-tfim.aspx

although that does date back to 2008, so perhaps it isn't the case with the latest and greatest ADFS today.

So, assuming we discard that approach (any thoughts on the above are most welcome), the approach that would clearly fit into the SAML standard would be to allow for a configurable option to not add a NotBefore condition in the assertions (i.e. leave it out of the assertions altogether). And given the two different problems above, we'd want that option to be on a per-Relying Party basis. If we were to create such a configuration attribute, what should it be called? Would "omitNotBeforeCondition" with a default value of "false", but which could be set to "true", be ok? Or would it be easier to understand/"harder to misinterpret" if we did that in a positive tone and made it "includeNotBeforeCondition", with a default value of "true"? Or something else entirely?

Any thoughts on this? Anyone else who would like to see this option exist in the IdP? (Note I'm intentionally starting this discussion on the Users list, for the widest input/feedback/thoughts, but recognize that eventually the conversation would most appropriately move to the Dev list.)

p.s. Scott, what other proposed toggles/switches to the IdP are on that 'list" you mentioned?

> 
> -- Scott
> 


--
Michael A. Grady
Senior IAM Consultant, Unicon, Inc.