RE: one time use saml artifact (BETTER FORMATTING! FEWER TYPOS!)

[Hal Lockhart <hal.lockhart@entegrity.com>]

> [Hal]
> It is my understanding that it has been proposed that SAML 
> generate an 
> Artifact to be returned via cookie or encoded URL to the 
> browser. This 
> Artifact will act as a bearer instrument equivalent to an 
> Authentication 
> Assertion. Obviously, the Artifact must contain sufficient 
> information to 
> identify the corresponding Assertion.
>  
> [Prateek Mishra] 
> 
> I think  this is essentially accurate. We are staying away from
> cookies and considering only URLs. Cookies only work within
> a single cookie domain; URLs can work across any pair of sites.

I think it would be a good idea to use both. It is my understanding that
coded URLs prevent page caching. You might consider cookies within domains
and URLs between them. 

> 
> The idea is that an artifact consists of two parts:
> 
>      (2-byte) type code,  (4-byte) Partner Id, (8-byte) 
> Assertion Handle
> 
> The partner id identifies the partner "generating" the artifact and
> referenced
> assertion. The AP and RP will bilaterally agree on the partner id. One
> choice might be
> the ip address of the AP. The assertion handle is an opaque string
> generated by the AP; it is proposed that the AP draw it from a 
> sequence of random numbers.

Ok, so my question is: can the Artifact be derived from the contents of an
Assertion? If so, I consider this a security risk.
 
> [Hal]
> 
> It has further been proposed that this Artifact have the 
> property of being 
> one time or single use. That is to say, whenever the browser 
> presents the 
> Artifact it will be given a new one with the same properties, but a 
> different value.
>  
> [Prateek Mishra] 
> 
> This is where I begin to be unable to follow your discussion. 
> Our model
> comprises the following: a user visits an AP and authenticates.
> At some point the user "transits" from the AP to the RP thru
> some distinguished URL. At this
> point the AP generates an assertion and an artifact. The AP maintains
> the (Assertion, assertion handle) in persistent store. 
> 
> The artifact itself is placed on the query string component 
> of the RP URL.
> The RP
> removes the artifact from the query string, checks the partner id and
> "calls back" the AP over a mutually authenticated
> channel requesting the assertion based on the assertion handle. The
> AP returns the assertion and the RP makes its authorization judgement
> based on the contents of the assertion.
> 
> It is proposed that the AP will return the generated 
> assertion "once" per
> assertion handle request,
> Subsequent requests to the AP using the assertion handle MUST fail. 
> 
> This ensures that the artifact cannot be re-used in some strange way
> within the validity period of the assertion. The issue here 
> is that the
> artifact is contained within the state of the browser; it can 
> be accessed
> thru the back button etc. Notice that the user "logging out" 
> has no impact
> on this problem. The use of state in our solution is a direct 
> (and I will
> argue an unavoidable) consequence of the stateful nature of 
> the browser
> client.

Ok, it is clear to me that I was talking about one-time use by the browser
and you are talking about one-time use by the relying party. That eliminates
many of my concerns, but note that draft-sstc-bindings-model-04 lines
449-484 is clearly talking about one-time use by the browser.


> 
> [Hal]
> 
> If this is not correct, I hope somebody will be kind enough 
> to tell me. 
> 
> I would like to agree with those suggesting that one time use 
> should NOT be 
> a requirement for the Artifact. 
> 
> First, let me note that no requirement or use case 
> specifically mandates the
> 
> use of a one time Artifact as opposed to a static value. 
> 
> [Prateek Mishra] 
> 
> I view this issue as entirely within the purview of the bindings
> group. Our charter is to investigate bindings and profiles and to
> secure them against a variety of attacks. Use-cases are at
> an extremely high-level of description. I do not see them as
> providing guidance on detailed designs (such as the SAML artifact
> architecture). 

Well, the binding is ultimately up to the TC as a whole. I was simply arging
that there is no up front mandate for this. I agree that you have to
determine what the detailed requirements are. I was trying to participate in
that process.
 
 
> [Hal]
> Second, as been pointed out by Bob, the one time Artifact 
> provides only a 
> very weak incremental security benefit. Anyone who intercepts 
> or constructs 
> one can use it immediately. The legitimate user may not make 
> another request
> 
> for some time. Further, in the absence of dynamic sessions, the last 
> Artifact is good until the Authentication Assertion expires, 
> which could 
> well be some hours.
>  
> [Prateek Mishra]
> Again, these are issues within the charter of the bindings
> committee. For example, we have recommended that the
> validity period of the
> authentication assertion generated for the web browser
> binding be strongly time-limited. Typically, this should not
> be more than a few minutes. The idea is that we are issuing
> the user an extremely powerful "bearer token" that 
> can be copied and distributed. We would like to limit its validity
> to the narrowest possible time period. In other words,
> I dont understand why you believe that the authentication
> assertion may only expire some hours later.

I don't understand this. I thought the AuthN Assertion would expire when the
user should be forced to re-authenticate. Do you mean the RP has to keep
going back and asking for new Assertions every few minutes?

> 
> [Hal] 
> 
> In order to achieve this modest security benefit, I believe 
> it will be 
> necessary to implement a complex, error prone protocol which 
> will have 
> significant, negative performance implications. Although I 
> have not seen 
> such a protocol proposed in any of the relevant documents or 
> emails, I have 
> arrived at this conclusion by reasoning from first principles.
>  
> [Prateek Mishra] 
> I have given a complete description of the protocol above.
> Statefulness is always a costly thing to implement, but I 
> have argued here that there are good reasons to take it
> into account as opposed to pretending that the threat of
> mis-use of web browser state does not exist.
>
> [Hal]
> 
> In order to to implement a one time artifact over a group of 
> web servers in 
> a single signon environment, I believe it would be necessary 
> for the various
> 
> servers to communicate with each other over a back channel. 
> Although they 
> could use some previously agreed scheme for rekeying the 
> Artifact value, it 
> will still be necessary for the server contacted by the 
> browser to inform 
> all the others that a new value must be computed. In my 
> experience such a 
> protocol will be difficult to keep synchronised in the face 
> of various 
> transient and permanent error conditions. 
> 
> [Prateek Mishra] 
> 
> I am sorry but I am unable to follow the reasoning here. 
> Could you please apply it to the specific protocol described
> in bindings 0.4 or the outline I have provided above? 
> 
> [Hal]
> It addition, as the number of sites increases, the 
> performance impact will 
> be severe. If servers must request an update (pull) the 
> latency of every web
> 
> hit will greatly increase. Conversly, if the occurance of each hit is 
> propagated, broadcast fashion (push), an enormous amount of 
> back channel 
> bandwidth will be required.
>  
> [Prateek Mishra] 
> I am sorry I am completely unable to understand how
> "servers must request an update (pull) the latency of every
> web hit will greatly increase". I see no evidence of this
> in the current web browser construction.
> Could you please explain
> how such a situation could arise with the proposed browser binding??
> 
> 
> There is a cost only when
> a user transits from one security zone to another. In this
> situation, the proposed scheme requires a single "callback"
> from the destination (RP) to the source (AP) utilizing
> the SAML assertion handle. It further requires the AP
> to issue an assertion only "once" against a particular
> handle. Is it your opinion this is an unreasonable cost?
> 
> [Hal]
> Perhaps my logic is in error. I would be pleased to see an 
> alternative 
> proposal for implementing a one time artifact over a number 
> of web servers.
>  
> [Prateek Mishra] 
> I have done just that in the construction above.  

All my comments were based on the notion of implementing one-time use by
browser, not RP. Please disregard.

 
> ---------------------------------------------------------------- 
> [Prateek Mishra] I think we need some clarity on
> the issues above before we can enter into the discussion
> below. I urge you to join the bindings group conference
> call (Thursdays at 12). This a regular (and well advertised
> meeting) that discusses exactly these type of issues.

I am sorry I had time conflicts with the meetings that discussed these
issues. Later, I considered joining the concall, but the announced subject
was something else e.g. SOAP. Therefore, I thought it would be appropriate
to discuss the issue on email. However, since I was basing my comments on
draft-sstc-bindings-model-04, they were not relevant.

I am still not sure I understand the proposed protocol. Is it described in a
posted message? For example, what happens when the browser goes to a second
site? Presumably they are redirected to the AP, but how does the AP know
they are the "same" subject and not force them to re-Authenticate? Does your
scheme require the AP to generate and sign a new AuthN Assn every time it
gets a request? "every few minutes" in your words?

Thanks for your patience.

Hal