Search This Blog

Wednesday, March 17, 2010

IETF Internet Draft: Requirements for End-to-End Encryption in XMPP

Members of the IETF Extensible Messaging and Presence Protocol (XMPP)Working Group have published an Internet Draft specifying "Requirementsfor End-to-End Encryption in the Extensible Messaging and PresenceProtocol (XMPP)." The Extensible Messaging and Presence Protocol isan open technology for real-time communication, which powers a widerange of applications including instant messaging, presence, multi-partychat, voice and video calls, collaboration, lightweight middleware,content syndication, and generalized routing of XML data.
XMPP technologies are typically deployed using a client-serverarchitecture. As a result, XMPP endpoints (often but not alwayscontrolled by human users) need to communicate through one or moreservers. For example, the user 'juliet@capulet.lit' connects to the'capulet.lit' server and the user 'romeo@montague.lit' connects to the'montague.lit' server, but in order for Juliet to send a message toRomeo the message will be routed over her client-to-server connectionwith capulet.lit, over a server-to-server connection between'capulet.lit' and 'montague.lit', and over Romeo's client-to-serverconnection with montague.lit. Although the XMPP-CORE specificationrequires support for Transport Layer Security to make it possible toencrypt all of these connections, when XMPP is deployed any of theseconnections might be unencrypted. Furthermore, even if theserver-to-server connection is encrypted and both of theclient-to-server connections are encrypted, the message would stillbe in the clear while processed by both the 'capulet.lit' and'montague.lit' servers.
Thus, end-to-end ('e2e') encryption of traffic sent over XMPP is adesirable goal. Since 1999, the Jabber/XMPP developer community hasexperimented with several such technologies, including OpenPGP, S/MIME,and encrypted sessions. More recently, the community has explored thepossibility of using Transport Layer Security (TLS) as the basetechnology for e2e encryption. In order to provide a foundation fordeciding on a sustainable approach to e2e encryption, this documentspecifies a set of requirements that the ideal technology would meet.
This specification primarily addresses communications security('commsec') between two parties, especially confidentiality, dataintegrity, and peer entity authentication. Communications security canbe subject to a variety of attacks, which RFC 3552 divides into passiveand active categories. In a passive attack, information is leaked(e.g., a passive attacker could read all of the messages that Julietsends to Romeo). In an active attack, the attacker can add, modify,or delete messages between the parties, thus disrupting communications...Ideally, any technology for end-to-end encryption in XMPP could beextended to cover any of: One-to-one communication sessions betweentwo 'online' entities, One-to-one messages that are not transferredin real time, One-to-many information broadcast, Many-to-manycommunication sessions among more than two entities. However, bothone-to-many broadcast and many-to-many sessions are deemed out-of-scopefor this document, and this document puts more weight on one-to-onecommunication sessions..." also Cryptographic Key Management:

1 comment:

Anonymous said...

Really cool blog brother. I've been coming here for quite some time, but I've never commented before. This blog is a constant inspiration like Generic Viagra Thanks for sharing so much.