rfc2222bis-13: challenges, responses and other messages

[Hallvard B Furuseth <h.b.furuseth@xxxxxxxxxxx>]

I'm having a look at rfc2222bis again:

The definitions and uses of challenges, responses, etc seem unclear or
inconsistent.

I always thought "Initial response" referred to the optional response
sent with the authentication command, and the wordings in sections 3 and
4 seem to me to say that.  rfc2222bis-10 explicitly uses the term that
way.

However, the example in section 3 uses it to mean just the first message
with client data.  I guess the text can be read to allow that meaning
too, but at least to me it's not the most natural way to read it.  Most
other text now seems to use that meaning.  I don't quite see the point
of giving that response any particular name though.

(One other meaning which it could make sense to give a name is the first
client data when the client sends data first - either with the auth
command or when prompted by an empty challenge.  That doesn't seem to be
the meaning used in this draft though.)

Since several mechanisms in RFC 2222 define the initial response, does
that mean text now says these support protocols whose authentication
commands do not include an initial response?

E.g. RFC 2222 required EXTERNAL to have an initial response, while
rfc2222bis until recently explicitly added support for no initial
response, and now that support is gone again.

"Initial challenge" just seems to be a descriptive phrase now, not a
defined term.  I think it meant the challenge when the server sends data
first, but if it means that or not doesn't seem to matter in rfc2222bis.

> 3.3 Request Authentication Exchange

>  Where the mechanism is defined to allow the client to send data first,
>  and the protocol's request message includes an optional initial
>  response field, the client may include the response to the initial
>  challenge in the authentication request message.

The last two lines have gotten scrambled.  That initial response is not
a response to any challenge.

BTW, I wonder if s/includes/supports/ here and elsewhere would be
clearer, to better distinguish from when the server/client includes the
optional field in some message it sends.

> 3.4. Challenges and Responses
>
>  The authentication exchange involves one or more pairs of
>  server-challenges and client-responses, the particulars of which are
>  mechanism specific.

I don't remember if this has been discussed before, but:

This seems to say one or more pairs of (challenge, the response to that
challenge) are exchanged.

But if the client sends data first and the server responds with the
final outcome, there are two messages but no such "pair".

I suppose this could be stated as "conceptual" pairs in that this should
be considered equivalent to the exchange where both auth command and
outcome had no data.  (However I'm not sure if a mechanism may be
specified so that the the client may send data with the auth command,
but if it does not the server may send a non-empty challenge.  If so
that "conceptual" exchange would have another semantics to the one using
the initial response in the auth command.)

Anyway if that's OK that might fix another problem too: I understand
correctly an the auth command with no initial response is not a
"response", and an outcome with no data is not a "challenge".  So there
is no challenge involved if the client sends an auth command and the
server responds with the outcome message and no data - e.g. EXTERNAL
when the auth command included the initial response.

OTOH, if the client sends no data, there is no response involved either.
(E.g. an ANONYMOUS-like mechanism with no trace info field.)  So that
will still not be supported.

-- 
Hallvard