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

[Alexey Melnikov <[e-mail]>]

Jeffrey Hutzelman wrote:

>>> 5.    Protocol profile requirements
>>>
>>>   In order to use this specification, a protocol definition MUST supply
>>>   the following information:
>>>
>>>   A service name, to be selected from the IANA registry of "service"
>>>   elements for the GSSAPI host-based service name form. [GSSAPI]  This
>>>   service name is made available to the authentication mechanism.
>>>
>>>   The registry is available at the URL
>>>   "http://www.iana.org/assignments/gssapi-service-names" A definition
>>
> Paragraph break. 

Yes, this is already fixed in my copy.

>>>   A definition of the method by which the authentication protocol
>>>   exchange is carried out, including how the challenges and responses
>>>   are encoded, how the server indicates completion or failure of the
>>>   exchange, how the client aborts an exchange, and how the exchange
>>>   method interacts with any line length limits in the protocol.
>>>
>>>   The command SHOULD have a method for the server to include an
>>>   optional challenge with a success notification.  This allows the
>>>   server to avoid a round trip when using a mechanism which is defined
>>>   to have the server send additional data along with the indication of
>>>   successful completion.  See section 6.2 of this document for further
>>>   information.
>>
> What command?  Who says "the method by which the authentication 
> protocol exchange is carried out" is a command?  s/The command/The 
> exchange method/ 

Yes.

>>> 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.
Would you rather reference the SASL WG as the Change Controller?

>>>   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?

>>>   The IANA is directed to modify the SASL mechanisms registry as
>>>   follows:
>>
>>
>> Please reword this to be not so demanding.  For example,
>>     It is requested that IANA update the SASL mechanisms registry
>>     as follows:
>
>
> It's not demanting; it's perfectly reasonable usage.  The IANA works 
> for the IETF; it is appropriate for the IETF, in the form of a 
> standards-track document, to direct it to make changes to a registry.  
> It is also common usage. 

I've already changed this to be "nicer" to IANA ;-).

> 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.

Alexey