Hi,
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.
4) Upgradability
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
and authentication.
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.
Regards,
Mridul
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
encryption".
******
