[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: FW: one time use saml artifact (BETTER FORMATTING! FEWER TYPOS!)
Hal, I recall the note now. I had it on my stack to respond, but after seeing Tim's note thought that it was essentially closed. Let me start by adding some comments into your text. [Hal] I have found the discussion on one time use SAML artifacts very confusing. [Prateek Mishra] Fair enough, we are working on getting 0.5 to be somewhat clearer. [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. 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. [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. [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). [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. [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. ---------------------------------------------------------------- [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. - prateek [Hal] If it is accepted that a one time Artifact is not required, I would like to repeat a proposal I made earlier this year. The currently proposed Artifact scheme encrypts several values relating to the subject. This would permit the retrieval of the corresponding Authentication Assertion. In general the Artifact is subject to two attacks. It may be intercepted and it may be guessed or derived from other information. The use of SSL is sufficient to prevent interception. Therefore, the key property is that it not be guessed or derived. I propose a scheme based on a cryptographic hash function. First, a unique, random value of 100-300 bits is generated. This value is used as the Artifact value. Then a cryptographic hash of this value is calculated, using for example, SHA1. The hash value is used as an identifier of the Assertion. For example, it could be combined with a DNS name and used as the Assertion Id. Or it could be stored in another field in the Assertion. The point is that it be possible to retreive the Assertion using this value. Any information that might be desired in the Artifact is instead stored in the Authentication Assertion. Because the value of the Artifact is random, it cannot be guessed. Because the hash is one way, the Artifact can not be derived from the Assertion. There are a number of advantages to this scheme. 1. Any scheme using encryption will either be subject to eventual exposure or will have to implement some form of manual or online key management protocol. A hash completely eliminates this, with no loss in security. 2. If the Artifact contains subject information, some servers will use it directly, without requesting the Artifact it corresponds to. This will make it nearly impossible to implement a dynamic session protocol, because it will be impossible for the session authority to know what servers have been accessed by a particular user. 3. A hash is much faster and more efficient that a reversible encryption. --------------------------------------------------------------------------- The Shoboleth scheme requires the ability to request the attributes of user, without revealing the identity of that user. Further, the attributes revealed are a function of the requestor. This can be accomodated by SAML in the following way. These capabilities are required. 1. The ability to issue an Authentication Assertion whose subject is an "blinded" identifier which can be mapped by an Authentication or Attribute Authority to a particualr subject, but which has a different value each time it is issued for the same subject. 2. The ability to construct an Attribute Assertion for a subject identified by an Authentication Assertion with a "blinded" subject identifier. The Attribute Assertion would be constructed on demand and only contain the attributes appropriate for the requestor, but the means of doing this would not be specified by SAML. The session would go like this. 1. The user would signon and receive a SAML Artifact. 2. The user would present the Artifact, allowing a target server to retrieve the associated "blinded" Authentication Assertion. 3. From this, the necessary Attribute Assertion could be obtained. Steps 2 & 3 could be combined in one request/response sequence. The assertions could also be passed via the user or pushed from the home site. This scheme is independant of either one time Artifacts or hashed vs. encrypted Artifacts. Hal ------------------------------------------------------------------ To unsubscribe from this elist send a message with the single word "unsubscribe" in the body to: security-bindings-request@lists.oasis-open.org ---------------------------------------------------------------- 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