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

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

Trevor,


>> the 
>>source site would
>>be required to respond with assertions within their validity 
>>period, so the
>>destination site wouldn't need to check for this. 

This is quite simply backwards. It is the relying party that
needs to check the validity of the received assertion. The sequence
of interactions that begin with the creation of an artifact and
terminate with consumption of the assertion by a relying party may
take several minutes. There is a possibility of the artifact
being stolen via several different means. The issuing party would like to
reduce its risk by narrowing the lifetime of the assertion. The relying
party should carefully check the validity of the same.

 This would 
>>not increase
>>the risk for the assertion issuer, as a stolen artifact would 
>>still have its
>>validity checked, but at the source site only instead of 
>>(redundantly) at
>>both the source and destination sites.  

I am afraid I cannot agree with this point of view. 


>>
>>If the destination site has its own requirements about timeliness of
>>authentication, it can check the age of the IssueInstant or
>>AuthenticationInstant values, as Scott points out.  
>>

As I have observed in my reply, this is merely an alternative
mechanism to control the time window of vulnerability. It may
be preferable in some way, but fundamentally it is no different.

>>This would simplify the processing required by the 
>>destination, and remove
>>the time-synch issue, which is otherwise going to require more text to
>>specify the slop values, and will be a common source of 
>>deployment problems.

Please consider the following simple attack:

(1) I log into the source site and am issued an artifact,
(2) I abandon the attempt to access the destination site,
(2) the artifact is now stolen by some means,
(3) the next day is the artifact is used to impersonate
me at the destination site.

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. 


- prateek

>>
>>Trevor
>>
>>-----Original Message-----
>>From: Mishra, Prateek [mailto:pmishra@netegrity.com]
>>Sent: Friday, June 21, 2002 7:13 AM
>>To: 'Scott Cantor'; 'Trevor Perrin'; saml-dev@lists.oasis-open.org
>>Subject: RE: [saml-dev] notBefore/notOnOrAfter unnecessary?
>>
>>
>>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>
>>>>
>>