OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: one time use saml artifact


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.

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.


  

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.

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.

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).  

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 the user
can copy and distribute. 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.

 

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.
 

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? 

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". 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?

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

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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC