[standards-jig] JEP 102 XMPP security extension background

Jean-Louis Seguineau/EXC/ENG jean-louis.seguineau at antepo.com
Fri Jul 4 20:03:11 UTC 2003


Hi All,

In view of the comments that have so far been made regarding XMPPsec
extensions, I believe important to state what I had in mind when writing the
first spec. Comments are showing that my concerns were less generic that I
though in the first place, and that there is room for improvement. I welcome
any constructive proposal to evolve this JEP to a better state.

1/ The landscape
- beside authentication, there was no XMPP way to implement a full set of
security tools addressing integrity, signature and confidentiality of XMPP
stanzas. Separate attempts had been made (such as the use of PGP for message
encryption) but no coherent attempt at covering the full requirement.
- W3C had ratified XMLSec and XMLDsig as the emerging standards for XML
encryption and signature. These standards share with XMPP their
extensibility, as they had been designed to be used with any kind of XML
documents.
- PKI infrastructures exist and are here to stay for certain industries.
They often require integrating specialized security code that could lead to
a cumbersome customization process. They also imply the use of a "trusted"
authority, which is not an issue in the enterprise world, but may be one in
the consumer world. That said, as more and more devices ship with support
for PKI, it will have to be part of the JEP at some stage.
- XMPP make provision for a transport layer security through the use of TLS,
but did not at the time address the end to end concern. This as evolved
since, but only in the XMPP WG which has specific and restrictive constraint
that restrain its ability to provide a generic solution (it's more a least
common denominator approach)

2/ The problem (limited to IM)
- provide a flexible and efficient way to secure end-to-end conversations on
the fly. The specification should allow two end points to agree an encrypted
session and use it without resorting to any third party.
- as crypto functions are more efficient on symmetric keys, provide a way to
negotiate crypto material to be used for symmetric encryption. At the same
time make the framework flexible enough to allow asymmetrical keys (PKI) to
be used instead.
- provide a key exchange mechanism to support the above (this is not defined
in any XML security standards)
- allow for key transportation between end points in case a key would be
re-used several time between more than two parties (such as when dealing
with secure chat rooms)


3/ The tentative answer expressed in the JEP
- provide a set of technical recommendations to meet the subset of security
requirements defined earlier.
- use as much as possible the existing XML standards as they provide
vocabularies for representing security information using XML technology.
They
are also designed to offer the flexibility and extensibility aspects of XML,
and bode perfectly with the XMPP philosophy.
- XML security technologies may be applied to end-to-end security, which is
important when XMPP messages are routed through a number of intermediaries.
In XML, persistent security is associated with the content rather than with
a transport layer. They can also be used in conjunction with transport layer
security techniques like TLS.
- define a key exchange mechanism by adapting existing internet key exchange
mechanism to XMPP. Doing so would keep the quality of the original mechanism
as to forward security and all responses to possible threats.

I agree that there is room for improvement, and certainly for some
reorganization of the document. Peter (Ronez) definitively made the point
that the foreword could benefit from some improvement (and I am certain he
red it), I would welcome his reworded version :)
Matt made several remarks that all point out to a need of better specifying
how PKI fits into XMPPsec. I have been thinking also of a way to use the
XKMS into the picture to provide key management services through an XMPP
server. Once again, Matt I would welcome any substantial suggestion that
would turn this subject into a great and workable addition to the JEP.

Hope this provides an adequate background for the current state of the JEP.
I am looking forward to the next steps, and I think as temas does that it
could become a great addition to XMPP.

Best regards

--jean-louis





More information about the Standards mailing list