Chris,
I might be wrong, but I don't see how an authentication mechanism which
will need more than *one* exchange between the server and the client to be
validate can be implemented through this scheme.
Reading this document, I understand:
In "2.1.3 Step Three": The server receives and validates the
"digest-response". = the Authentication is either accepted or reject, and
the challenge is always closed.
For some authentication method one or more additional challenge/response
are needed before being able to judge the validity of the authentication.
A typical example for such multiple exchange need is SecurID in next token
mode where *two* challenge are needed.
Did I miss something?
jean
At 02:18 PM 2/7/99 -0800, someone using Chris Newman's login wrote:
>On Thu, 4 Feb 1999, Martin Forssen wrote:
>> Attached below follows a proposal for a new authentication method for
>> SSH2. This new method implements general challenge-response
>> authentication.
>
>If you do a challenge response mechanism, make it compatible with HTTP
>Digest and the DIGEST mechanism:
>
> <http://www.ietf.org/internet-drafts/draft-leach-digest-sasl-01.txt>
>
>As was noted by others, ill-conceived security APIs like PAM actually make
>network security harder so convergence on a single challenge-response
>mechanism is important for multi-protocol code reuse and interoperability.
>
> - Chris
>
- jean -
