[Security] e2e requirements

[Peter Saint-Andre]

In XEP-0188 and earlier XEP-0116, Ian Paterson and I defined a set of 
requirements for end-to-end encryption of XMPP stanzas. I'll repeat them 
(with sequential numbers) here so that we can discuss them and hopefully 
gain consensus. These requirements refer to the concept of an "ESession" 
(encrypted session) but should be generalizable to any technology that 
we choose to adopt.

******

1. Confidentiality

The one-to-one XML stanzas exchanged between two entities MUST NOT be 
understandable to any other entity that might intercept the communications.

2. Integrity

Alice and Bob MUST be sure that no other entity may change the content 
of the XML stanzas they exchange, or remove or insert stanzas into the 
ESession undetected.

3. Perfect Forward Secrecy

The encrypted communication MUST NOT be revealed even if long-lived keys 
are compromised in the future (e.g., Steve steals Bob's computer).

4. Replay Protection

Alice or Bob MUST be able to identify and reject any communications that 
are copies of their previous communications resent by another entity.

5. PKI Independence

The protocol must not rely on any public key infrastructure (PKI), 
certification authority, web of trust, or any other trust model that is 
external to the trust established between Alice and Bob. However, if 
external authentication or trust models are available then Alice and Bob 
must be able to use them to enhance any trust that exists between them.

6. Authentication

Each party to a conversation MUST know that the other party is who they 
want to communicate with (Alice must be able to know that Bob really is 
Bob, and vice versa).

7. Identity Protection

No other entity should be able to identify Alice or Bob. The JIDs they 
use to route their stanzas are unavoidably vulnerable to interception. 
However, the public keys they use SHOULD NOT be revealed to other 
entities using a passive attack. Bob SHOULD also be able to choose 
between protecting either his public key or Alice's public key from 
disclosure through active ("man-in-the-middle") attacks.

8. Repudiability

Alice and Bob MUST be able to repudiate any stanza that occurs within an 
ESession. After an ESession has finished, it SHOULD NOT be possible to 
prove cryptographically that any transcript has not been modified by a 
third party.

9. Robustness

The protocol must provide more than one difficult challenge that must be 
overcome before an attack can succeed (for example, by generating 
encryption keys using as many shared secrets as possible - like retained 
secrets or optional passwords).

10. Upgradability

The protocol must be upgradable so that, if a vulnerability is 
discovered, a new version can fix it. Alice MUST tell Bob which versions 
of the protocol she is prepared to support. Then Bob MUST either choose 
one or reject the ESession.

11. Generality

The solution should be generally applicable to the full content of any 
XML stanza type (<message/>, <presence/>, <iq/>) sent between two 
entities. It is deemed acceptable for now if the solution does not apply 
to many-to-many stanzas (e.g., groupchat messages sent within the 
context of multi-user chat) or one-to-many stanzas (e.g., presence 
"broadcasts" and pubsub notifications); end-to-end encryption of such 
stanzas may require separate solutions or extensions to the one-to-one 
session solution.

12. Implementability

The only good security technology is an implemented security technology. 
The solution should be one that typical client developers can implement 
in a relatively straightforward and interoperable fashion.

13. Usability

The requirement of usability takes implementability one step further by 
stipulating that the solution must be one that organizations may deploy 
and humans may use with 100% transparency (with the ease-of-use of 
https:). Experience has shown that: solutions requiring a full public 
key infrastructure do not get widely deployed, and solutions requiring 
any user action are not widely used. If the users are prepared to verify 
the integrity of their copies of each other's keys then the necessary 
actions should be limited to a one-time out-of-band verification of a 
string of up to 6 alphanumeric characters.

14. Efficiency

Cryptographic operations are highly CPU intensive, particularly public 
key and Diffie-Hellman operations. Cryptographic data structures can be 
relatively large especially public keys and certificates. The solution 
should perform efficiently even when CPU and network bandwidth are 
constrained. The number of stanzas required for ESession negotiation 
should be minimized.

15. Flexibility

The solution should be compatible with existing (and future) 
cryptographic algorithms and identity certification schemes (including 
X.509 and PGP). The protocol should also be able to evolve to correct 
the weaknesses that are inevitably discovered once any cryptographic 
protocol is in widespread use.

16. Interoperability

Ideally, it would be possible for an XMPP user to exchange encrypted 
messages (and, potentially, presence information) with users of non-XMPP 
messaging systems.

17. Offline Sessions

Ideally, it should be possible to encrypt one-to-one communications that 
are stored for later delivery instead of being delivered immediately, 
such as so-called "offline messages". However, any vulnerabilities 
introduced to enable offline communications must not make online 
communications more vulnerable.

18. Object Encryption

For cases where a session is not desired, it should be possible to 
encrypt, sign and send a single stanza in isolation, so-called "object 
encryption".

******


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/security/attachments/20070316/ac50f7e3/smime.bin