RE: ISSUE[UC-5-01:AuthCProtocol]

[Hal Lockhart <hal.lockhart@entegrity.com>]

Anders,

I will make one more try and then give up.

I am not trying to win a debating contest. I am just trying to help you
clearly express your ideas so people can understand what you mean and can
judge them on their merits. In my opinion, if you take a term with a well
established meaning and use it for something else, it will not assist other
people's understanding.

In this committee we are talking about exchanging messages relating to
Authentication, Authorization, Policy Evaluation. It is generally understood
that in this context we are talking about Authentication of the User,
Authorization of the User, etc. Yes, of course there are various components
involved and yes, in order to insure secure operation of the protocols,
these other entities must Authenticate themselves to prevent impersonation,
use checksums to provide integrity protection, use nonces to prevent replay
attacks and so forth.

None of this has to do with Authentication of the User.

---------------------------------------------------------------------

Here is how I see the issue.

In the conventional type of credentials exchange, an AP issues credentials
when asked by a User or RP. The contents obviously depend on the identity of
the user and the policy of the AP. In addition, they could depend on the
identity of the RP and/or the expressed preferences of the User.

In what you have called the Advanced credentials exchange, the RP first
expresses to the AP what sort of credentials it would like to receive. The
AP then issues credentials which depend on all the things listed in the
previous case and in addition on the information received from the RP and
some policy about how to apply that information.

I called this credentials negoiation and I believe a couple of other people
independantly came up with same name. I again invite you to suggest a better
one.

I will now make the following observations.

1. In many scenarios, the AP will need to know which which type of exchange
is being used, because it must either contact the RP or send the
credentials. That is, the choice of schemes cannot always be made
transparent.

2. The first scheme still allows considerable scope for user privacy and the
ability for the User to control what information the AP sends out.

3. The second scheme requires the definition of a number of additional types
of assertions, requests and errors. It may also have runtime response
implications. In other words, it is not "free".

In my opinion, it is not sufficient to justify a proposal like this by
saying it is more flexible. Having no standard at all is the most flexible
alternative! Additional design complexity must be justified by stating a
specific business requirement that cannot be met by the first scheme that
can be met by the second.

Regards,

Hal

> -----Original Message-----
> From: Anders Rundgren [mailto:anders.rundgren@telia.com]
> Sent: Friday, February 09, 2001 6:01 PM
> To: Hal Lockhart; security-use@lists.oasis-open.org
> Subject: Re: ISSUE[UC-5-01:AuthCProtocol]
> 
> 
> Hal,
> 
> Form the use case description SSO push model #2
> 
>             1. Web user authenticates with source Web site. 
>             2. Web user requests link to destination Web site. 
>             3. Source Web site request authorization profile 
> for the resource to be accessed (unsigned)
>             4. Destination Web site returns authorization 
> profile (signed)
>             5. Source Web site requests authorization for Web 
> user to use destination resource from destination Web site (signed)
>             6. Destination Web site returns authorization 
> reference to Source Web site (signed)
>             7. Source Web site provides user with 
> authorization reference and redirects user to destination Web site. 
>             8. User requests destination resource from 
> destination Web site, providing authorization reference. 
>             9. Destination Web site provides resource to Web user. 
> 
> > This is not challenge response authentication, for the 
> simple reason that
> > neither the AP or the RP is being authenticated. If you 
> don't like challenge
> > response I suggest you think of another name, but the 
> exchange you are
> > talking about does not involve authentication. The AP and 
> RP are exchanging
> > what they know about the User. The fact this is done in a 
> way that prevents
> > replay and other attacks does not make it authentication. 
> 
> Actually both parties are fully authenticated by the digital 
> signatures and associated certificates
> of messages 4 and 5.  
> 
> > Challenge response authentication is commonly used to refer to an
> > authentication method wherein the party being authenticted 
> is required to
> > respond to a challenge by performing some crytptographic 
> operation on a
> > piece of information whose value cannot be anticipated. 
> Examples of this
> > include CHAP, MS challenge response and SSL. A major 
> alternative is to use a
> > time-based protocol, of which Kerberos is an example. 
> 
> The cryptographic operation performed by the AP on the 
> challenge/nonce/timestamp in message (4)
> is the digital signature enclosing message (5) that contains 
> (among many things) the challenge as well.
> 
> I agree that this is not described in the use-case text, but 
> this is what I and to some extent Shibboleth propose.
> 
> Anders
> 
>