Re: [secdir] Secdir review of draft-ietf-simple-chat-14
"Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com> Mon, 16 April 2012 10:27 UTC
Return-Path: <miguel.a.garcia@ericsson.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28AA621F8608; Mon, 16 Apr 2012 03:27:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.194
X-Spam-Level:
X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0ds+kq+hyrB; Mon, 16 Apr 2012 03:27:23 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4EB21F85E6; Mon, 16 Apr 2012 03:27:22 -0700 (PDT)
X-AuditID: c1b4fb2d-b7b76ae0000063d8-6d-4f8bf408e3a9
Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0184"; auth=fail (cipher=AES128-SHA)
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0184", Issuer "esessmw0184" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 25.D7.25560.904FB8F4; Mon, 16 Apr 2012 12:27:21 +0200 (CEST)
Received: from [159.107.24.207] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Apr 2012 12:27:20 +0200
Message-ID: <4F8BF405.5030708@ericsson.com>
Date: Mon, 16 Apr 2012 12:27:17 +0200
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Vincent Roca <vincent.roca@inria.fr>
References: <51DE5E2E-1D51-4025-B55C-4B09EFA62468@inria.fr>
In-Reply-To: <51DE5E2E-1D51-4025-B55C-4B09EFA62468@inria.fr>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Cc: "draft-ietf-simple-chat.all@tools.ietf.org" <draft-ietf-simple-chat.all@tools.ietf.org>, IESG IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-simple-chat-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Apr 2012 10:27:24 -0000
Hi Vincent. Thanks for your comments. Allow me to reply you inline. On 04/04/2012 15:50, Vincent Roca wrote: > Hello, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > General: > > The authors, in section 11, discuss several simple security issues. > However I have the feeling that there aren't enough details on how to > avoid/mitigate them. Additionally, I'm not sure the section provides a > comprehensive analysis of security aspects. What about intelligent, > more elaborate attacks? > > > Details for section 11 "Security considerations" > --------------------------------------------------------------- > > ** The second paragraph explains several situations where a message can > be sent to several recipients without the sender knowing. It's a good > point to identify this problem, but I'd like to know how it can be > avoided (if possible). Effort was made to lower the barrier of endpoints, so that conference-unaware participants were able to join and still have some basic chat functionality. If possible, we would like to keep this feature. I see a couple of immediate possible solutions: 1) We forbid conference-unaware participants to join the chat room, for example, by accepting the session to a virtual chat room where the only participants is the MSRP switch itself, which sends a message indicating that the client does not support the required features, and disconnects it. This forbids conference-unaware participants joining the chat room, and it is not desirable. 2) We force the MSRP switch to send one or more messages to conference-unaware participants, indicating that this is a chat room, their client does not support all the features, we send the roster as text, and indicate that all messages will be further distributed to the whole chat room. Basically, we tell the user (and not its software) that this is a chat room. If 2 is acceptable, I will go for it. > > ** It is said: > "It's up to the policy of the MSRP > switch if the messages are forwarded to the other participant's in > the chat room using TLS [RFC5246] transport." > > I'm surprised to see that a participant has no way to enforce a secure > end-to-end connection. At a minimum, can the participant know the > situation in order to take a decision? A participant can control if TLS is used between his endpoint and the MSRP switch. But this participant cannot control if the MSRP switch uses TLS to deliver messages to the rest of the participant. This is because each pair of endpoint-MSRPswitch session is independent of each other, so, it is possible for the chat room to have a mixture of secure and non-secure MSRP session. It is possible for an MSRP switch to have a local policy enforcing that TLS will be required for sending/receiving MSRP messages. Since this does not affect interoperability, we haven't mentioned anything, but if you guys feel more comfortable indicating this fact, we can always add a paragraph. > > ** It is said: > "To avoid takeovers the MSRP switch MUST make sure that a nickname is > unique inside a chat room." > > Do you mean the protocol does not guaranty by design that a nickname is > unique at some point of time in a chat room? If this is the case it's > clearly a flaw that should be addressed within the protocol description, > not in the security considerations section. Yes, the selection of a nickname guaranties that a nickname is unique in the chat room. This is described in Section 7.1: The reservation of a nickname can also fail if the value of the Use-Nickname header field of the NICKNAME request is a reserved word (not to be used as a nickname by any user) or that particular value is already in use by another user. In this case the MSRP switch MUST answer the NICKNAME request with a 425 response code. That paragraph you quoted is just implicitly referring to the paragraph that I just quoted. > > Another remark: it's not sufficient to guaranty the uniqueness of the > nickname. Phishing attacks show us that two close URLs can mislead a > user, even if the URLs differ by at least one character. It would be > wiser to recommend that nicknames be significantly different (the MSRP > can probably check the distance between a proposed nickname and those > already registered in the chat session). We can add such paragraph. However, there has been some e-mail discussion on the topic, in conjunction with the internationalization of characters in nicknames. I will point you to a couple of interesting e-mails. Peter Saint-Andre mention here that avoiding confusable nicknames should be optional: http://www.ietf.org/mail-archive/web/simple/current/msg09894.html And in this other e-mail, Peter indicates the confusion that different (but still similar) characters can create http://www.ietf.org/mail-archive/web/simple/current/msg09887.html I believe it is hard, if not impossible, to fight the latter. > > ** last sentence: > The following sentence is a bit strange and unclear: > "If a nickname can be reserved if it previously has been used by another > participant in the chat room, is up to the policy of the chat room." > I suggest: > > NEW: > It is up to the policy of the chat room to determine if a nickname that > has been previously used by another participant of the chat room can > be reserved or not. Absolutely right. Fixed > > ** General: > Several threats are missing in this document. In particular, > what about attacks where some traffic is intercepted and modified > on-the-fly by the attacker? If TLS is used for delivering MSRP messages, then this attack should not be possible. > What about faked messages sent by an > attacker to the MSRP? TLS will also prevent this attack. If TLS is used to transport MSRP messages, then an attacker could not impersonate a participant and inject false messages. > Can a participant use some integrity service? > This is not discussed. Here the solution should either be TLS or S/MIME. For all the threats, remember that this draft builds on MSRP. Therefore, the security considerations of RFC 4975 apply. TLS and S/MIME is discussed in there, and they apply to this draft. > > I'd like to see guidelines on how a participant or MSRP administrator > can define a secure mode of operation. If not possible, I'd like to > see a detailed discussion of existing risks. Can you please elaborate what else on top of RFC 4975 we need to discuss? Are you referring to indicating that it is RECOMMENDED that the MSRP switch only accepts TLS-protected MSRP sessions or is it something else? Thanks for your review. Looking forward to your comments, Miguel > > > Cheers, > > Vincent -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain
- [secdir] Secdir review of draft-ietf-simple-chat-… Vincent Roca
- Re: [secdir] Secdir review of draft-ietf-simple-c… Miguel A. Garcia
- Re: [secdir] Secdir review of draft-ietf-simple-c… Vincent Roca