Re: DIGEST-MD5 interop testing and comments

[Alexey Melnikov <mel@xxxxxxxxxxxx>]

Cyrus Daboo wrote:

> Hi folks,
> At last weeks MailConnect 6 event hosted by the IMC in San Jose, we did
> some DIGEST-MD5 interop testing with some client and server
> implementations. Some question wrt to the current draft arose from this
> and I'll list those below.
>
> If anyone else is interested in interop testing of DIGEST-MD5 please
> post to this list so that we can all do this. We (Cyrusoft
> International) have a DIGEST-MD5 plugin for Mulberry (IMAP email
> client) available now and want to test with whatever server
> implementations are currently available.
>
> Comments:
>
> 1) Section 2.1.2.1
> The definition for A2 includes the 'digest-uri-value'. Does this have
> to be present or can it be NULL?

It seems that it might be NULL

> I'm assuming that if the client does
> not send a 'digest-uri' as part of the digest-response (Section 2.1.2)
> then the value in A2 should be NULL.

It might be not NULL, but "AUTHENTICATE:".

> This needs more explanation.

This have to be explicitly defined, because at least two persons (Cyrus
and I) understand it differently.

> 2) Section 2.1.3
> The purpose of Step 3 seems to be missing. Why is it present?
> Presumably so that the client can validate the server response.

Exactly.

> It should be stated explicitly that the client should abort the
> authentication if the wrong values are returned, i.e. the client must
> calculate and compare the response-auth sent by the server.

I agree.

> 3) Section 4: Example
> The example does not include Step 3 or does it? Its also not clear to
> me what happens after Step 3 - does the server immediately respond with
> a tagged OK response or does it wait for something from the client,
> since the client may reject step three? If the example does include
> Step 3 then it would be the line immediately preceeding the a OK line,
> in which case the example is not at all clear. Perhaps using the 'C:'
> and 'S:' prefixes for each response would make things clearer.

Example is broken.
As I understand:

Step 3: Server sends "rspauth=...". Clients verifies it. If it is
successful, it sends to server zero-length response. Then server sends
back success indication flag (this is true for SMTP, POP3, IMAP4 because
they don't have the ability to send additional data with success
indicator)

> --Cyrus Daboo

For all interested parties I propose to arrange "DIGEST dinner" during
IETF 44. Any propositions about date? (I'll be in Minneapolis from Sunday
up to Wednesday)


--
Regards,
Alexey Melnikov