[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [saml-dev] notBefore/notOnOrAfter unnecessary?
> How does your proposal protect against this attack? The > source and destination systems must have somewhat > synchronized clocks. This issue has nothing to do with (explicit) usage of > NotBefore/ NotOnOrAfter attributes vs. Scott's proposal which > takes a more "implicit" viewpoint. That's true, and we need to distinguish the case Trevor is interested in, the artifact case, from the one I focus on, the POST. In the POST, you quite simply must have time sync, and the target must check validity somehow, whether via IssueInstant or the Condition. The advantage of IssueInstant is that the source can issue a longer lived assertion that has downstream usefulness (say, an AttributeStatement). As it is, you simply have to bundle a second assertion with longer life into the response. Not a big deal, but it illustrates why bounding the other assertion tightly in the first place isn't all that important. The purpose of the time check is to protect the target. Prateek argues that the source site should have control over the upper bound, but since the source site isn't relying on anything here, I don't know why it would care, offhand. In the artifact case, the point Trevor's making is that the time check is for the source site's benefit, *not* the target's. It's a bound on the artifact's use, not really on the assertion's use. And since the source is responding to the artifact request, it can enforce that constraint by means of its methods to maintain artifact state. The target is still the final relying party, but it's communicating synchronously with a trusted source, and strictly speaking, it could choose not to care what the time Condition says, and wouldn't be any more or less vulnerable to an attack. For consistency with SAML processing rules, any assertion with a time constraint should be treated consistently, so I don't think disregarding it is a good idea, but it is true that absent other considerations, time sync is not strictly needed for the artifact profile to work. But by the time you move down a layer to the trust model, though, chances are bad time is going to mess you up anyway. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC