RE: AuthN and Credentials - One Dissenting View

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

Irving Reid wrote:
> As I see it, AuthN comes down to: A subject asserts their 
> "identity", and
> provides some reason why that assertion should be believed. 
> This combination
> of "identity" and "corroborating evidence" is what _I_ mean when I say
> "Credentials"; others may differ.

No, this is the meaning in the glossary and the one we agreed on on the last
concall.

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

Also, in the case of PKI AuthN, the credentials would presumably include the
private key.

> Typically, the assertion is "username = irving" and the 
> reason is "password
> = whatever". In more sophisticated cases, the assertion might be
> "Certificate = <big ASN1 blob>" and reason is "successfully 
> proved posession
> of the corresponding private key".
> 
> The direction SAML seems to be going is that the only sort of 
> credentials we
> support are "Identity = <arbitrary data>", "evidence = 
> Because foo.com's
> security service says so". As an aside, we may attach further 
> information so
> that foo.com's security service can explain _why_ they say so, but it
> doesn't make any fundamental difference to the validity of 
> the credential.
> 
> As far as I can see, there are two different arguments going 
> on. Some people
> are talking about the structure and content of the "foo.com's security
> service explains _why_ they say so" mentioned in the previous 
> paragraph. I
> don't see this as a big issue; we can do something like 
> provide standard
> URIs for the common cases, and allow people to invent their 
> own URIs for the
> cases we haven't thought of yet, and apply for 
> standardisation of them later
> (sort of an IANA / clearinghouse process); there are other 
> ways to solve the
> problem, and I'm sure we can pick one without serious contention.

I agree.
 
> The other argument, and the one I really care about, is the 
> argument about
> whether having a single sort of SAML credential, which was 
> described in S2ML
> as a "Name Assertion", is sufficient. The reason I think it isn't is
> somewhat selfish: we perform authentication based on various sorts of
> credential over our PEP-PDP protocol. If SAML works out, we 
> intend to switch
> over to SAML as our native PEP-PDP protocol. When we do, if 
> SAML doesn't
> already support interesting forms of authentication we'll 
> immediately need
> to extend it. At that point we run into all the usual problems of
> non-standard extensions - poor interoperation, maintenance 
> headaches, etc.

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?

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.

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

Regards,

Hal