RE: conference call - March 29

[Philip Hallam-Baker <pbaker@verisign.com>]

Title:

 

I am having trouble understanding your reply to my questions.

 

First you did not seem to reply to my request for clarification:

 

>In the 0.3 version of the document, I am unclear about the box at the top of page 11 that starts "Alternate means of

>identifying the assertion" Are these design alternatives or are you proposing to support a number of different ways of

>identifying the same assertion? 

Those are design alternatives for identifying the assertion. I would suggest that we want to decide which or how many we would want to support. This is a 'ticket' encoding issue however which is not so much a priority for me. My plan was to write down the spec for all the options and then if people think it would simplify matters we can vote out those considered redundant.

Second, I am unclear as to what aspect of my comment you agree with.

 

Let me propose that we distinguish between the initial Authentication performed by a system entity using password, private key, etc. (Authentication) and the verification of the binding of some assertion or ticket to a session, principal or request (VOB). [If anybody can think of a more natural term which does not already have other meanings, please suggest it.]

 

I assume that in your message, where you say "authentication" you mean VOB.

Really the authentication comes down to an authentication of the token.

 Clearly the MAC scheme proposed in the document involves a pre-shared secret. However the hashing scheme I proposed does not and in fact is as secure as any cookie-type* scheme can be.

OK, now I have it, the utility of having an authentication field in the cookie is only that the PEP can reject a fake cookie without reference to the PDP. So the authentication field should be optional at the very least.

 

It appears to me that the cookie issue comes down to what inferences can be drawn from a particular cookie. I don't think we can get to one size fits all. If we have a SAML aware, PKI enabled browser we don't even want the cookie to be used for authentication at all, all it is then is a pointer to the assertion.

 

Perhaps what we need is some kind of field in the cookie that specifies what the inference that can be drawn is. I am concerned about the 802.11b style attacks in which two parties assume the other correctly performed the authentication when they did not.

I am not sure exactly what you mean by the second paragraph, but I don't think I am on shaky ground if I say that any scheme that requires all participants to have keys and certificates is a complete non-starter.

 I certainly would not suggest that public key be a requirement at the client level, however it has to be possible to use a public key for authentication, hence the second example.

 

        Phill

Phillip Hallam-Baker (E-mail).vcf