FW: AuthN and Credentials - One Dissenting View

[Greg Wilson <Greg.Wilson@baltimore.com>]

[Forwarded on behalf of Irving Reid, whose subscription to
this list is in flux at the moment. -- Greg]

-----Original Message-----
From: Irving Reid [mailto:Irving.Reid@baltimore.com]
Sent: Wednesday, February 28, 2001 7:20 PM
To: security-use@lists.oasis-open.org;
Subject: AuthN and Credentials - One Dissenting View


As far as I know, I'm the main dissenter on AuthN/Credentials; the one who
voted that we _should_ include AuthN methods in SAML. I'll try to explain
why, with liberal cut&paste from the preceding messages. Even if you skip
the big hunk of exposition below, please read at least the first quote and
response; I suggest new wording for the AuthN related issues.

I really wish I could make it to the F2F; since I can't, I'm going to have
to be quite verbose in an attempt to avoid misunderstandings. I hope that
some of the people who _are_ able to attend will try to represent these
issues in my absence.


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.

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.


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.

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.

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.


Now for the specific responses to quoted text...


> -----Original Message-----
> From: Evan Prodromou [mailto:evan@outlook.net]
> Sent: Wednesday, February 28, 2001 2:24 AM
> To: 'UseCaseList '
> Subject: Re: AuthN and Credentials
> 
> 
> >>>>> "MP" == Mishra, Prateek <pmishra@netegrity.com> writes:
> 
>     Me> Our high-level goal here is not to burden SAML with the actual
> 
>     MP> Agreed. This was the main point of
>     MP> ISSUE:[UC-5-03:AuthNThrough]; no expression of authentication
>     MP> within SAML
> 
> Agreed, and it seems that the overwhelming majority of people in the
> subcommittee agree (10-1!). Unfortunately, some people felt that the
> wording of the non-goal was unclear or incorrect (at least that's my
> guess as to why they voted against the particular non-goal). I think
> that we need to find a better formulation that the dissenters could
> agree to. Any dissenters have a suggestion?
> 
> My guess is that the quibble is about "authentication." If one is
> being strictly formal, I think that accepting (say) an S2ML name
> assertion as proof of identity is also a form of "authentication." Is
> there a clear way we can state the difference?

I think we could make this clearer by presenting more than one issue. The
first ones are positive requirements:

[R-NameAssertion] SAML Relying Parties must be able to authenticate users
based on Name Assertions.
[R-NameAssertionInfo] SAML must provide a way for information about
authentication to be associated with Name Assertions


As for the non-goals:

[NON_GOAL-LoginService] SAML will NOT specify a login service that provides
Name Assertions in response to other forms of authentication.

[NON_GOAL-OtherCredentials] SAML will NOT specify a way to convey
credentials other than Name Assertions.

As far as the actual content of Name Assertions:

[ISSUE-whatever-whatever-Authn]: [R-NameAssertionInfo] requires the ability
to attach additional information to Name Assertions. The envisioned
application of this requirement is to include such things as "the
authentication occurred at date-time X", "the authentication method was
biometric toe-smell", etc.

Resolutions:
1(a) SAML will define an extensible format for Name Assertions that includes
additional information
OR
1(b) The aforementioned additional information will be associated with Name
Assertions using the oft-mentioned 'Authorization Data' SAML object, with a
reference to the Name Assertion. After all, what's so different (at a strict
data representation level, rather than semantically) about saying "The
subject of <NameAssertion> is a member of group 'Administrators'" or "The
subject of <NameAssertion> authenticated using the method identified as
URI://saml.oasis.org/Toe-Smell"?

Independent of the choice of 1(a) or 1(b), the second issue is whether to
provide a standard (and extensible) way of describing the authentication
method; I think there are existing Issues that cover this question.


> -----Original Message-----
> From: Mishra, Prateek [mailto:pmishra@netegrity.com]
> Sent: Tuesday, February 27, 2001 6:33 PM
> To: 'Orchard, David'; UseCaseList
> Cc: Ahmed, Zahid
> Subject: RE: Inputs to Strawman/Issue List - Group 2: B2B Scenario
> Variations
> 
> 
> David,
> 
> if we exclude credentials from SAML we are going to be left
> with very little in the way of identifying subjects. What is
> the point of a name assertion if we do not have standard ways
> of calling out "names" within it: public keys, string tokens, 
> X509 DNs,
> Certificates, and yes, even name and password (just another
> secret credential). How can we have an interesting notion of 
> an Az service
> if there
> are no standard credentials? 
> 
> > 
> > I believe this was voted out of scope for SAML version 1.0, 
> 
> I have no reason to believe we have agreed not to standardize
> credentials. It remains on the issue list (I believe with
> an  8Yes/ 3No vote) and remains very much part of our
> discussion.

I think this really ties back to the re-wording I suggested above. I suspect
that the 10-1 vote was really a vote against specifying a Login Service. I
would be surprised if anyone suggested that we shouldn't support
"authentication" of Name Assertions, where "authentication" means checking
their structural validity by verifying signatures or such like, deciding
whether to believe the Name Assertion based on the identity of the Asserting
Party, and deciding what authorization response is appropriate based on the
identity (or anonymity) of the subject, the identity of the Asserting Party,
and the associated information related to the Name Assertion (such as AuthZ
Attributes or descriptions of authentication methods).

That said, the authentication I describe above really isn't any of SAML's
business. As long as we specify the _format_ of the Name Assertion, the
Relying Party is free to interpret the content however they choose. They
probably won't get many customers if their interpretation is silly, but
that's their problem.

Hmm. I just thought of another possibility - Are there people who
interpreted the "Authentication Service" question as meaning a service that,
given a Name Assertion, returns an opinion as to the validity of the Name
Assertion? In that case, I can see why we're debating. 'validity' of a name
assertion, aside from at the lowest level of signature verification, is
entirely application-specific.

I suspect that what Prateek means when he says "standardise credentials" is
_not_ "standardise how SAML implementations are required to assign trust to
credentials", but rather "standardise how to describe what sort of
credentials were presented". The second form is necessary in order to make
policy decisions such as "Allow <subject> to <verb> <object> only if they
logged in using an X9.9 Challenge-Response."