This is clearly an area of some controversy. First, it is my
opinion this issue has nothing to do with [UC-1-04:ARundgrenPush]
so I will not address that issue at all.
The exact text of this requirement is taken from S2ML 0.8a, p.7,
Section 2.5. The context for this requirement is the following:
S2ML incorporates a credential validation service called (misnamed)
Authentication. In order to maintain (at least my own) sanity, I will
refer to this service as S2ML_Auth.
S2ML_Auth is characterized in the following manner:
(p.7, Section 2.5)
<quote>
Native authentication services in S2ML 1.0 are limited to login,
based on name and password, validation of X.509v3 certificates
and public keys.
Challenge-Response authentication protocols are outside the
scope of S2ML 1.0
</quote>
We have not as yet discussed a service similar to S2ML_Auth within [OSSML],
so in a sense the whole discussion has been somewhat without foundation. If
we are going to include a service such as S2ML_Auth than we could return to
this discussion. I have issued a note explaining the rationale for such
a service [3] and I look forward to further discussion on this topic.
--------------------------------------
Returning to relevant discussion on the list:
Hal [2] comments:
<quote>
1) So far as I can determine so far, the only thing we plan to do
with authn
is define a way for somebody to say "I have authenticated so & so,
and I
used the such and such method." We have said we are not designing
any new
authn methods. I see nothing to suggest we are going to define a
series of
methods for passing authentication tokens back and forth, in the
manner of
GSSAPI or RADIUS.
If I am correct, is seems all we need is a registered set of values
for each
type of authn and that is the end of it. If this is the case, why
not
support lots of methods?
</quote>
Further, Nigel [1] points out that
<quote>
My vision of how assertions will work is that
they will carry around information about how entities have
authenticated.
...
I does not seem too onerous to define lots of methods. It also
doesn't
mean all conforming implementations have to support all
authentication
schemes. If a principal authenticates at a site A, using scheme X,
site
A could create an assertion and make that available to site B. Site
B could
understand this assertion without itself directly supporting
authentication
scheme X.
Also I believe we should allow for extensibility, so that new types
can be added if a deployment requires it (another requirement ;-)).
</quote>
This sounds good to me, except that we do need to call out some standard
forms of credential. The <AuthData> element in S2ML attempts to do so;
as suggested above, some better structured form of extensibility is also
required in this space.
In [OSSML] we are so far dealing only with the end-results of a subject's
authentication
act; do we need to go further? Is there a need for a credential validation
service that certifies credentials? Is this another form of
[UC-4-02:AttributeAuthority]?
- prateek mishra
[1] http://lists.oasis-open.org/archives/security-use/200102/msg00038.html
[2] http://lists.oasis-open.org/archives/security-use/200102/msg00036.html
[3] http://lists.oasis-open.org/archives/security-use/200101/msg00053.html
> -----Original Message-----
> From: RL 'Bob' Morgan [mailto:]
> Sent: Monday, February 12, 2001 5:05 AM
> To: OASIS Security-Use List
> Subject: Re: ISSUE[UC-5-01:AuthCProtocol]
>
>
>
> > > 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.
>
> Ding ding ding. "Authentication" is an overloaded term, and has many
> valid meanings at many levels as this discussion shows. We
> are obliged to
> agree on precise terms to distinguish the different uses if
> we are to have
> a productive discussion about them.
>
> In a fundamental sense "authentication" is the act of
> verifying that an
> object is authentic, where "authentic" in this sense means
> both "of known
> origin" and "not tampered with". It is (mostly) the nature
> of the object
> being authenticated that differentiates the different kinds of
> authentication.
>
> For example, a "message authentication code" (MAC) is a basic
> technique
> for providing integrity protection on transmitted data. Every SSL
> "record" (for example) has a MAC, which is verified by the
> receiver. Is
> this "authentication"? Of course it is, it's "message
> authentication", or
> more precisely "SSL record authentication".
>
> This is different, even in the SSL case, from the
> "authentication" of the
> endpoints of the SSL session. This "authentication" is
> providing strong
> assurance of the identity of the session participant (which
> is optional in
> SSL; every record has a MAC, though). This is, I think,
> sometimes called
> "origin authentication" (or "data origin authentication"),
> meaning that
> the origin of the other end of the communication channel is
> verified. We
> might also call this "session authentication" since it's the
> initiation of
> the session that is verified to be "authentic" and that
> authenticity is
> extended to each message/record in the session (but then
> "session" has its
> own overloading problems).
>
> This is different, yet again, from "authentication" as used
> in the phrase
> "user authenticates to the source web site" (use case 1 from
> strawman 2).
> This kind of authentication involves a user (whether human or process)
> knowingly using some secret information to verifiable
> identify itself to a
> service for purposes of conducting some transactions. I
> suggest that this
> is more precisely called "sign-on" (or "login" perhaps).
>
> Thus, in use case 1, the user "signs on" to the sign-on service (aka
> "source web site"). The sign-on service gives a "sign-on
> token" to the
> user as evidence of this. This sign-on token is sent to the
> destination
> web site and provides "origin authentication", ie assurance
> of the user's
> identity without the user having "signed on" to the
> destination web site.
> Individual PDUs of the user's traffic with the destination
> web site will
> be protected by "message authentication".
>
> So, given all this, I *still* don't understand what the Non-Goal
> "Challenge-response authentication protocols are outside the scope of
> [OSSML]" is supposed to mean. Either it has to be clarified,
> in terms of
> which kind of authentication it's about, or it has to be removed.
>
> - RL "Bob"
>
>
