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