Subject: Re: Comments on draft-ietf-sasl-rfc2831

From: Sam Hartman <[email-masked]>
Date: Mon, 07 Apr 2003 13:39:20 -0400

>>>>> "Alexey" == Alexey Melnikov <[email-masked]> writes:

    Alexey> We have to be clear that for the protocols that use the
    Alexey> same format for authentication and authorization ids,
    Alexey> "authzid" is in UTF-8 and MUST NOT be converted to
    Alexey> ISO-8859-1 as username/password are.

No, authz ID is in whatever format the application says it is.  All
the base spec seems to say is that it is a string.

I would recommend replacing the text I complained about with something
that says "The authorization identifier MUST NOT be converted to ISO
8859-1 by this mechanism even if the authentication identifier is
converted for compatibility."

    >> The security discussion seems inadequate.

    Alexey> Suggestions?

I specifically meant the security discussion of the QOP stuff, BTW.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 08 Apr 2003 21:01:48 -0600

> converted for compatibility."

Ok, I've mostly fixed this.

The new text in 2.1.2 looks like:

authzid

The "authorization ID" directive is optional. If present, and the
authenticating user has sufficient privilege, and the server supports it,
then after authentication the server will use this identity for making all
accesses and access checks. If the client specifies it, and the server
does not support it, then the response-value calculated on the server will
not match the one calculated on the client and authentication will fail.

The authorization identifier MUST NOT be converted to ISO 8859-1 even if
the authentication identifier ("username") is
converted for compatibility as directed by "charset" directive.

The server SHOULD verify the correctness of an authzid. For example, an
IMAP [RFC 3501] server will prepare the received authzid using the
"SASLPrep" profile [SASLPrep] of the "stringprep" algorithm [StringPrep].
If preparation of the authzid fails or results in an empty string, the
server MUST fail the authentication exchange.

===
I am not sure whether the last paragraph belongs to this document, or
whether it should be moved to the SASL document or profile documents.
Personally, I would hate to update each profile document with this text.

>>3.6  Man in the Middle

...

>>A possible man-in-the-middle attack would be to substitute a weaker qop
>>scheme for the one(s) sent by the server; the server will not be able to

>>detect this attack. For this reason, the client should always use the
>>strongest scheme that it understands from the choices offered, and
>>should never choose a scheme that does not meet its minimum
>>requirements.

Can you suggest any specific changes to this text?

Cheers,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________

---

From: Sam Hartman <[email-masked]>
Date: Wed, 09 Apr 2003 15:25:01 -0400

>>>>> "Alexey" == Alexey Melnikov <[email-masked]> writes:

    Alexey> === I am not sure whether the last paragraph belongs to
    Alexey> this document, or whether it should be moved to the SASL
    Alexey> document or profile documents.  Personally, I would hate
    Alexey> to update each profile document with this text.

I think that this goes in the base spec.

I'll think about text for the man-in-the-middle case.  I'm not really
sure what we want to happen.

We could recommend that people always mandate integrity protection or
confidentiality, but doing so would create interoperability problems.
We could recommend that people not use digest-md5, but we should have
something to recommend instead.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 07 Apr 2003 13:39:20 -0400

Alexey> Suggestions?

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 08 Apr 2003 21:01:48 -0600

authzid

===

...

Cheers,
Alexey Melnikov

---

From: Sam Hartman <[email-masked]>
Date: Wed, 09 Apr 2003 15:25:01 -0400