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

["Mishra, Prateek" <pmishra@netegrity.com>]

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:rlmorgan@washington.edu]
> 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"
> 
>