[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: one time use saml artifact
I have found the discussion on one time use SAML artifacts very confusing. 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. 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. 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. 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. 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. 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. 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. 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. ---------------------------------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC