Re: [security-services] Clarifying validity times in profile proposal

["RL 'Bob' Morgan" <rlmorgan@washington.edu>]

> I will say this though...we need better text about
> NotBefore/NotOnOrAfter and we need to say either that they mean nothing
> in the absence of a profile or add more profiles to define them for more
> general uses other than the SSO piece, or something.

I do think it's the case that these conditions appear in SAML because more
or less the same elements appear in X.509, and are theoretically obvious
and well-understood there.  To the extent that their use in X.509 is
obvious and well-understood, it is only in a particular use case:  the use
of public-key certificates in authentication (and perhaps in verification
of signing).  This is a narrow use of a very specific kind of assertion
(in the plain English sense).  SAML assertions/statements are more
general, but I think the effect of this is just that more kinds of time
constraints are needed to cover the requirements; but the basic notion of
"validity period of the assertion" remains useful, I think, if defined
precisely enough.  See below.

Even in the case of using X.509 PKCs for authentication, as we discussed
at the F2F, there is no general notion about the effect of certificate
validity period on any session or other long-lived data established as a
result of the authentication.  TLS, for example, doesn't say anything
about this, nor does any IETF application protocol profile of TLS.

Poking further through X.509, just for grins, it defines "validity" as:

  validity is the time interval during which the CA warrants that it will
  maintain information about the status of the certificate

an operational sort of definition that doesn't specify any particular
effect of validity period on any purpose for which the cert might be used;
but this definition is based on the principle that CAs will provide
revocation information during that period.  Since we avoid revocation
concepts in SAML, this makes this general X.509 notion of validity period
not very applicable, seems to me.

Path validation, an "application" of sorts that is defined within X.509
(and PKIX) does specify that certs have to be within their validity period
to be used as part of a path.

There is also an extension:

  PrivateKeyUsagePeriod

via which the time during which a private key can be used for signing can
be made shorter than the time of the PKC (since you might want to verify
using the public key for a longer time).  So, an example of different
"usefulness" periods in the same cert, for different purposes.

X.509 attribute certs also have a plain old validity period and a more
complicated "time specification" extension for things like 9-5 M-F.  But
this is always expressed as being about the time when "privilege
assertion", meaning evaluation of the cert as a statement of privileges,
is applicable.  AC path processing is done for a particular "time of
evaluation" (maybe the present time, maybe not), and all certs in the path
must have valid privs at that time for the path to be valid.  But nothing
in any of this that I can see says anything about time constraints on any
results of privilege evaluation.

So yeah:  expressing constraints on sessions is a new thing, and deserves
its own carefully specified values.  I think everyone agrees on that.

But I think plain old notbefore/after conditions have a simple general
use:  when some application (or profile, if you prefer) defines doing
something with SAML assertions, at some point an assertion recipient is
processing the assertion, and the first step is figuring out if it's
valid.  If the "effective time of processing" is outside the validity
period, then the assertion is invalid, and the application rules say what
to do in that case (or say that nothing more can be said about that case,
or something).  This time-constraint concept may not be useful in all
apps, in which case the app should say that these conditions should not be
put into assertions for use with that app.

> I guess I can accept the argument that a SSO assertion is some special
> beast (even if I disagree, I think it's only the packaging in a Response
> to an AuthnRequest that makes an authn assertion apply to that use
> case). But then we need to address the other instances where assertions
> might come to be.

I think what you're saying here is that the assertion containing the
authentication statement has *only* the meaning: "this authentication
event happened".  Making this simple statement into a protocol message
that is to be interpreted by a recipient as "establish a security context
for the subject, as part of this overall profile" is what is done by
wrapping it in a Response.

I agree that this is a reasonable way to think about these objects.  I
think the alternative point of view is:  the meaning of the assertion
containing the authn statement is "establish a security context", and the
wrapping in Response is just some fluff to get this useful info to its
recipient.  This is probably also a reasonable position (though it isn't
my position), but obviously is different than the one above.  So we need
to decide on one or the other, and stick with it.

I think we've discussed that these two views might largely be based on
alternative views of the authn authority and its handling of authn
assertions.  In one view the authn authority, after a user authentication,
creates an assertion and stores it, and pumps it out when requested,
appropriately wrapped.  In the other view the authn authority just stores
the event info, and creates the authn assertion afresh upon each request.
Obviously you'd have to do the latter to stick per-request stuff in it.

> <Response IssueInstant="">
> 	<Assertion IssueInstant="">
> 		<Conditions NotOnOrAfter="">
> 			<BindingCondition NotOnOrAfter=""/>
> 		</Conditions>
> 	</Assertion>
> </Response>
> ...
> Meanwhile, the BindingCondition attempts to impose constraints not on
> use of the assertion in general, but on the acceptability of the
> assertion in the message context in which its delivered (again, I view
> the assertion as a payload, the "message" in SSO is always a Response).
> In this case, it's a constraint on the latest time at which the
> assertion can be delivered in a Response. One could call it a
> ProtocolCondition, I suppose.

Are there other kinds of BindingConditions that you have in mind that are
similar enough to make this a general mechanism?

Seems to me the point of this is to constrain the validity period for
bearer assertions to be used for authentication; why not just say that in
a condition and be done with it.  "BearerAuthenticationValidity" is
cumbersome but precise IMHO (assuming that this special condition is
needed at all).

 - RL "Bob"