[standards-jig] Re: JEP-0102

Matt Tucker matt at jivesoftware.com
Thu Jul 3 03:25:00 UTC 2003


Hello all,

This JEP was originally seen on the security jig mailing list and I made 
some comments there that may be good to discuss again here.

As outlined in my email below, I still have two major concerns with this 
JEP:

  1) I believe that arbitrary packets should be encryptable, which this 
JEP does not allow.
  2) I think the key exchange in this JEP is too complex. XMLEnc 
provides a simpler mechanism, or perhaps key negotiation should be 
broken off into a seperate JEP so that those that already have a PKI can 
use the encryption but not the key exchange in this JEP.

Regards,
Matt

--------------------------------------------------------

Hey all,

There is lot of interesting content in the JEP. I'm very impressed with 
Jean-Louis's thoroughness! My comments so far:

  * Secret key negotiation is fairly complex, as demonstrated by the 
fact that most of the JEP is devoted to it. I'd be curious to know why 
secret keys were pursued rather than just relying on public/private key 
encryption like S/MIME, etc does. I think there is the potential for a 
massively simplified spec if key exchange is as simple as sharing public 
keys. Clients are then free to trust the public key certs if they desire 
(using root CA's, etc).

  * The approach taken by the JEP is to attach encrypted content as 
extra information, such as:

<message from="initiator at domain" to="responder@ domain" id="msg-0">
<body>
The real body is protected.
</body>
<x xmlns="xmpp:security">
<EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
     Type="http://www.w3.org/2001/04/xmlenc#Element">
   <CipherData>
     <CipherValue>ad5Anasd4</CipherValue>
   </CipherData>
</EncryptedData>
</x>
</message>

This is not quite the "standard" XMLEnc approach from what I can tell by 
reading the spec. Instead, encryption simply replaces with standard xml 
stanzas with an encrypted form. So, a message packet might look like:

<message from="initiator at domain" to="responder@ domain" id="msg-0">
<EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
     Type="http://www.w3.org/2001/04/xmlenc#Element">
   <CipherData>
     <CipherValue>ad5Anasd4</CipherValue>
   </CipherData>
</EncryptedData>
</message>

The decryption step is essentially a form of packet pre-processing then 
-- the message would look like a normal message packet after being 
decrypted. From an implementation perspective, this often means 
dynamically modifying the DOM of the XML sub-packet on the fly. In fact, 
this is how all the XMLEnc libraries are implemented that I've seen.

I think this "pre-processing decryption" approach will be a requirement 
for any e2e spec. Otherwise, it will be impossible to encrypt arbitrary 
packet information. For example, let's say one want so encrypt an IQ 
packet (something not covered by the Antepo spec but that is an e2e 
requirement as far as I know).

Given the following IQ packet:

<iq>
   <query xmlns='jabber:iq:time'>
     <utc>20020910T17:58:35</utc>
     <tz>MDT</tz>
     <display>Tue Sep 10 12:58:35 2002</display>
   </query>
</iq>

The Antepo spec would have no possible way to encrypt this. However, if 
we use a pre-processing approach the encrypted packet looks like:

<iq>
<EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
     Type="http://www.w3.org/2001/04/xmlenc#Element">
   <CipherData>
     <CipherValue>ad5Anasd4</CipherValue>
   </CipherData>
</EncryptedData>
</iq>

After it's decrypted, it looks like a normal IQ and is passed to the 
standard XMPP packet parser.

Thanks,
Matt




More information about the Standards mailing list