Subject: [secdir] Secdir review of draft-ietf-simple-chat-14

From: Vincent Roca <[email-masked]>
Date: Wed, 4 Apr 2012 15:50:10 +0200

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). 
   
** 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? 
   
** 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.

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

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

** 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? What about faked messages sent by an
attacker to the MSRP? Can a participant use some integrity service? 
This is not discussed.
              
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.

Cheers,

    Vincent

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 16 Apr 2012 12:27:17 +0200

Hi Vincent.

Thanks for your comments.

Allow me to reply you inline.

> Details for section 11 "Security considerations"

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.

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

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

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

>    has been previously used by another participant of the chat room can

Absolutely right. Fixed

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

> 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

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain