Re: WG Last Call: draft-ietf-sasl-rfc2222bis-02.txt

[Jeffrey Hutzelman <[e-mail]>]

On Wednesday, October 08, 2003 13:38:33 +0100 Alexey Melnikov 
<[e-mail]> wrote:

>>>> 8.3.  Change control
>>>>
>>>>   Once a SASL mechanism registration has been published by IANA, the
>>>>   author may request a change to its definition.  The change request
>>>>   follows the same procedure as the registration request.
>>>
>> This sounds a lot like the stringprep loophole, and it makes me nervous.
>
> Can you be more specific in what do you want to be changed.

No.  Perhaps I'm being paranoid, but the concern is that if mechanism FOO 
gets registered and implemented, no one should be able to come along later 
and change FOO to mean some other, non-compatible mechanism.  Maybe it's 
not worth worrying about..

In any case, no, I can't be more specific; I don't know what change could 
make this better, and I don't think I was really asking for one.  It just 
makes me nervous.

> Would you rather reference the SASL WG as the Change Controller?

No, especially since the SASL WG will likely conclude within the 
foreseeable future.

>>>>   In certain situations, it is reasonable to use SASL underneath one of
>>>>   these Transport Security services.  The transport service would
>>>>   secure the connection, either service would authenticate the client,
>>>>   and SASL would negotiate the authorization identity.  The SASL
>>>>   negotiation would be what moves the protocol from "unauthenticated"
>>>>   to "authenticated" state.  The "EXTERNAL" SASL mechanism is
>>>>   explicitly intended to handle the case where the transport service
>>>>   secures the connection and authenticates the client and SASL
>>>>   negotiates the authorization identity.
>>>>
>>>>   When using SASL underneath a sufficiently strong Transport Security
>>>>   service, a SASL security layer would most likely be redundant.  The
>>>>   client and server would thus probably want to negotiate off the use
>>>>   of a SASL security layer.
>>>
>>
>> Please don't say this without a _lot_ more text explaining when it is
>> safe. A common configuration is to run SASL under TLS, using SASL for
>> client authentication and negotation of the authorization identity.
>> In this configuration, it is _not_ safe to skip using a SASL security
>> layer if the client did not check the server's certificate (there is a
>> tunnelling MitM attack), and it's not a particularly good idea even if
>> the server cert was checked, because the client's authentication is
>> still not bound to the encryption keys used at the TLS layer.
>>
>> We already have problems with people who think it is actively bad to
>> use a SASL security layer under TLS.  The result is that some insecure
>> configurations are now widely deployed.  Let's not encourage this any
>> further.
>
> Should I just drop this paragraph?

Yeah, IMHO it would be reasonable to just drop the paragraph starting "When 
using SASL underneath..."

>> Put the TOC at the _top_ of the document, just after the abstract.
>> See the "Tabel of Contents" section at
>> http://www.rfc-editor.org/policy.html
>
> This is editorial and I don't want to spend time doing this at this stage.
> I am going to sort this out with the RFC editor directly.

Fair enough.