[Security] e2e requirements
Peter Saint-Andre
stpeter at jabber.org
Fri Mar 16 11:51:35 CDT 2007
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
More information about the Security
mailing list