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

["Mishra, Prateek" <pmishra@netegrity.com>]

>>> [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.
>>[Hal]
>>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. 
>>
[Prateek]

Hal, a vendor provided security system can easily map
a SAML assertion into cookies or some other performant
security representation. URLs are only being used to
communicate information in
an extremely limited way: when a user moves from the 
source site (AP) to the destination site (RP).

I dont see it as a must have
in SAML 1.0. At its core this issue is a performance enhancement
request.

Notice also that we will end up expending time in calling out
two distinct "variations" on the same web browser profile. 
Before doing that I would like to establish a compelling
reason for moving in this direction.


>>> 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]
>>Ok, so my question is: can the Artifact be derived from the 
>>contents of an
>>Assertion? If so, I consider this a security risk.
>> 
[Prateek]

There is no relationship whatsoever between the contents of 
the assertion and its assertion handle contained within an
artifact. The proposal is that an AP would draw the assertion
handle from a sequence of random numbers generated by the AP.
The assumption is that the AP maintains a table of assertions
indexed by assertion handles. As I understand it, your proposed
architecture approaches the linkage of assertion handle to
assertion differently, but is otherwise complementary
to the current web browser profile.

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

[Prateek]
Agreed, these lines require some improvement in text. However,
we do require the RP to "refuse" access to the TARGET URL to
the browser. This refusal is based on the AP indicating to
the RP that artifact in question has been "used up".

>> [Hal]
>>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.
>> 

[Prateek]
No problem with that. I am trying to maximize participation
in the bindings group, if you examine the e-mail trail on the bindings
group you may find some evidence of  that!

>>[Hal]
>>All my comments were based on the notion of implementing 
>>one-time use by
>>browser, not RP. Please disregard.
>>
>>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.
>>

[Prateek]
No problem, I am just trying to get the word out there that
people with substantive "bindings" 
issues should try to join the bindings
group dialog. It is reasonable to do so by e-mail, i needed
to have responded earlier.

>>[Hal]
>>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?

[Prateek]
The assumption is that the AP has some form of security engine
in place that can track its own authenticated users. Typically,
this takes place thru a session which is represented in some
form in an encrypted cookie and some additional state
information at the AP. Certainly, this is a strong assumption
but one which does seem to be met by a large class of security
systems.

When the user returns to the AP, the AP examines the security
context of the user and determines if the user session is still
valid. 

Some of these issues were discussed in the bindings con-call and
in the minutes I issued
http://lists.oasis-open.org/archives/security-bindings/200107/bin00000.bin

>>[Hal]
>> 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?
>>

[Prateek]

Yes, you are on the money here. Every transfer from an AP to an
RP requires the use of a "new" assertion and assertion handle. 
I do not view the signing of the assertion to be mandatory:
it may be enough that the AP and RP maintain a mutually authenticated
channel for "pulling" assertions from the AP. 
Signing is required only if a non-repudiation token is also
required.




- prateek