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

[RL 'Bob' Morgan <rlmorgan@washington.edu>]

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