[Security] e2e requirements
mridul at sun.com
Sat Mar 24 05:05:10 CDT 2007
Just some comments about the requirements.
I am not as familiar with esessions as I would like to be, so it likely
that I am missing something. But looking from point of xmpp requirements
in general ...
1) pki independence and authentication.
Typically authentication/verification would require pki dependence.
Since auth is mentioned as a MUST, I am not sure how we can achieve both.
2) Identity Protection
Not sure about this ... encrypt with public key, receiver decrypts with
private key : maybe I misunderstood the intent here ? Why should the
public key used not be known to others ?
3) Description about repudiability
Just to get it clarified - the intent of the description is not to allow
repudiation between participants while a session is in progress, but
w.r.t others once a session is over right ? (ability to deny)
This feels like reverse of most security requirements I have seen, so
want to get it clarified.
How does this affect stored/archived data ? (may not be relevant here ?)
5) Offline Sessions
Not sure how we can support this if repudiability and perfect forward
secrecy are requirements. What about upgradability ?
Also, from what I see, otr, xtls, etc cannot satisfy this.
As already voiced in the conference, usability as a primary requirement
is a bit tough to solve - without different solutions for different
requirements (need for compliance vs otr for example : 136 does attempt
try to combine both nicely btw).
Also, isn't replay protection not a subset of integrity here ?
One of the other things which is nagging me is - Perfect forward secrecy
I can think of validation followed by generation of short term random
key which gets used for the actual session encryption, etc: but not sure
if that was the intent, and how interoperable such an approach would be.
Peter Saint-Andre wrote:
> 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
More information about the Security