[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [saml-dev] notBefore/notOnOrAfter unnecessary?
Yeah, I'm looking at those sections. My point is that, if bullet point 3 in 4.1.1.9.1 was firmed up to MUST from SHOULD, then bullet points 1, 4, 5, and the first sentence of 6 could be removed as redundant: 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 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. 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. 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. 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> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC