http://bugzilla.lysator.liu.se/show_bug.cgi?id=133
------- Additional Comments From ceder@lysator.liu.se 2005-03-11 12:52 ------- (From update of attachment 84) I like this patch better than the previous, but it is still a bit too vague.
+* login-acquired-credentials:: e Login using acquired credentials (124)
This should probably be moved to a separate bug, unless you plan to implement it now. If you do implement it now, the specification for start-tls should say that the client can provide a client certificate that can give credentials to log in without a password using the login-acquired-credentials request.
+@example
1 123 @holl{6,server}
@t{=1}
<CLIENT starts negotiation>
+@end example
+Indicates that the client wants to begin TLS (see RFC 2246) +negotiation. Returns successfully if the server is willing, after +which the client immediately begins negotiating.
RFC 2222 states that a profile of it must specify several things. Some of them are relevant here as well, and the current documentation is vague. Quoting RFC 2222, with my comments inside []-brackets:
3. A definition of the method by which the authentication protocol exchange is carried out [a TLS negotiation in our case], including how the challenges and responses are encoded [not -- we are using an 8-bit channel], how the server indicates completion or failure of the exchange [TLS alerts? What happens after a failure to negotiate TLS? Can it fail?], how the client aborts an exchange [I don't know if that is applicable to us], and how the exchange method interacts with any line length limits in the protocol [not applicable, as there are no such limits].
4. Identification of the octet where any negotiated security layer starts to take effect, in both directions. [Immediately after the newline of the start-tls command in the direction from client to server, and immediately after the newline in the response to that command in the other direction, I presume.]
+@subheading Security considerations
+There is a security issue involving man-in-the-middle attack that +client implementators should be aware of. Someone acting as a MITM can +interfere with the response to this request, inhibiting the use of TLS +(causing authentication tokens to be transferred in clear over the +network). It is recommended that clients warn if servers that have +previously been willing to perform TLS negotiating are no longer +willing.
+Another security issue is that while a successful TLS negotiation can +provide server authentication (through different means, including +X.509 certificates, OpenPGP keys and SRP), it only guarantees to +provide a secure channel between the parties involved in the +negotiation (meaning MITM attacks are possible even when using TLS).
insert "unless a server authentication mechanism is used" for clarity.
------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.
lyskomd-qa@lists.lysator.liu.se