OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[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