[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: one time use saml artifact (BETTER FORMATTING! FEWER TYPOS!)
> [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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC