RE: AuthN and Credentials - One Dissenting View

[Irving Reid <Irving.Reid@baltimore.com>]

> From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> Sent: Thursday, March 01, 2001 5:57 PM
> 
> Irving Reid wrote:
[trim trim trim]
> Let me take this opportunity to point out one subtle issue. I take
> Credentials to mean the stuff needed to authenticate. One output of an
AuthN
> is an "identity." Typically this is the same as one of the credentials,
but
> IMO it does not have to be. In fact, to support Anonymity, as we agreed, I
> don't think it can be. I think it is valid for the user to say "I am Joe,
> password foo." and the AuthN system to say "User 5879f0cd logged in
> successfully."

Agreed, and if I understand the Shibboleth use cases, we may want an even
more drastic form - the Name Assertion might not have any sort of unique ID
so that neither the relying party or the asserting party can track your
activity after it is issued.

[much trimmed]

> But what you want is not just the ability to Authenticate, 
> but to act as a
> middle man to allow the user to authenticate to somebody else, in the
> fashion of RADIUS. This is complicated for several reasons:
> 
> 1. Most of us want to support off-the-shelf browsers. Suppose 
> it is doing
> SSL with client certs. How do you do pass thru Authentication?

There are a couple of approaches to this. One is to empower the web server
(or an SAML agent installed in the web server) to generate name assertions.
Another is to treat the web server/agent as being inside your "trust
boundary" (perhaps by peer-peer authentication), and issue the Name
Assertion based on the assumption that the web server has done the
proof-of-possession. Whether either of these is sufficiently secure will
vary from case to case.

> 2. The many types of authentication in use have different patterns of
> messages to be transfered. Designing a protocol to handle 
> them all is very
> complex. Note that RADIUS did not even try.
> 
> My sense of the use case team is a desire to agree on 
> something reasonably
> simple as quickly as possible and defer harder problems.

If I'm not mistaken, RADIUS does allow for a generic multi-stage
conversation sufficient for basic challenge-response systems like X9.9.

I definitely agree with the desire to do something simple that can be agreed
on quickly. Even if we don't specify a way to do multi-stage authn
conversations, it would be good to make sure it will be possible to add them
as extensions later.

> > In a more philosophical sense, these Name Assertions have 
> to come from
> > somewhere. They could appear out of thin air, or they could 
> > be produced by a
> > security service in response to some user input. Just for 
> > argument, I'll
> > call the latter case a "login service". I'm specifically 
> > avoiding the term
> > "authentication service", because to me "login" specifically 
> > implies that
> > the _user_ is supplying the evidence.
> 
> But philosphically, if you trust somebody else to tell you 
> "Joe is an Admin"
> why not trust them to say "Joe logged in at 3:00 by using a password"
> instead of insisting on passing "Joe" and "foo" to be checked?

I'm trying to solve the case where I'm the one generating the "Joe logged in
at 3:00 by password". In order to do that, I need to get the password...

> > If we don't specify a login service in SAML, every one of us 
> > is going to
> > have to go off and design our own, or convert the one we've 
> > already got so
> > that it produces SAML name assertions. This means that 
> > customers, system
> > integrators, application infrastructure vendors, etc. are 
> > still going to
> > need custom code for each SAML implementation they want to 
> > support, because
> > 99+44/100% of their applications are going to require a login 
> > service at
> > _some_ point.
> 
> I don't really follow this. I can implement code to assert 
> "Joe logged in"
> or "Joe is an Admin" quite easily. If I have to implement the 
> client and
> server end of a protocol to do pass thru AuthN that is a lot 
> harder. If
> somebody else's user comes to me, I can pass them off to 
> their home domain.

I'm specifically discussing the PEP-PDP use case, where we _are_ the user's
home domain. I agree that it's easy to generate the name assertion. The hard
part is the authentication. Somewhere in the system there has to be
something that knows how to look up usernames and find passwords, talk to
RADIUS and SecurID servers, do certificate path validation and cert policy
checking, and so on. We can either build all that goo every time our systems
need to generate SAML name assertions, or we can build it into the PDP and
let developers of SAML-based systems take advantage of it without having to
do the hard stuff again and again.

 - irving -