RE: [saml-dev] notBefore/notOnOrAfter unnecessary?

["Mishra, Prateek" <pmishra@netegrity.com>]

If you look at Section 4.1.9.1 and 4.1.1.9.5 of the specification, you
will find a discussion of 
the role of NotBefore and NotOnOrAfter as part of a counter-measure
against assertion theft (similarly 4.1.2.7.1 and 4.1.2.7.4). 

I agree that these fields could be eliminated but with a definite increase
in
risk for assertion issuer. The "constraint on the use of 
assertion" helps narrow the time window in which this type of attack
could take place.

The real issue here is clock synchronization. We expect system clocks to
be somewhat synchronized. But SAML authorities and consumers need to cope
with the possible differences in clock settings. This leads to the
difficulties
that Trevor points to. 

The solution here is not to eliminate NotBefore and NotOnOrAfter but instead
ensure that their range incorporates some reasonable notion of clock skew. 
For example, setting NotBefore to a few minutes BEFORE the current time is a

reasonable solution. The SAML consumer continues to insist on strict
assertion validity, the issuer compensates for the lack of strict clock 
synchronization (and accepts additional risk).

- prateek

>>
>>No, it's actually not. The Response in that case contains an
>>IssueInstant and is signed, so you can just enforce a maximum elapsed
>>time against that value. The significance of bounding the assertion is
>>about the same as in the artifact case, and would seem to be intended
>>more as a constraint on the use of the assertion, rather than as
>>protection against some kind of attack.
>>
>>I argued, fairly weakly, against requiring short-lived 
>>assertions in the
>>POST case, but I didn't waste a lot of breath on it.
>>
>>-- Scott
>>
>>
>>----------------------------------------------------------------
>>To subscribe or unsubscribe from this elist use the subscription
>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>