Am 28.10.2016 um 21:01 schrieb Sam Whited:
On Fri, Oct 28, 2016 at 1:51 PM, Philipp Hancke
<[email protected]> wrote:
It was not clear to me what the shared secret is used for here
I originally had a different mechanism drafted out for this that used
a shared secret. Turns out I had several things left over in the
document from when I removed the other mechanism; there is no shared
secret anymore. Will remove the reference; thanks!
Since the user part of the JID is exposed to other clients how are replay
attacks prevented?
That's a good thing for the security considerations; the idea was that
the burner JID could only be used by the owner of the real JID that
created it. Servers should verify that the burner JID is only used
from within a session that is autenticated as the user that created
the burner JID.
I assumed that a new connection was used for the burner id. If so how
would you do this verification if not using a shared secret mechanism?
Or did I misunderstand things and you authenticate as the real id with
authcid and password and use the burner jid as authorization identify
(authzid).
I wonder how long it takes until dwd is going to beat me up for getting
RFC 4616 wrong ;-)
Security considerations:
- should those JIDs be traceable to the account that created them for the
operator? I think that is desirable, also to limit the number of such jids.
Agreed. Burner JIDs should keep you anonymous from third parties
(other servers, MUC participants, etc.), but not from your server
operator. For anonymity from the server operator as well, use SASL
ANONYMOUS.
It makes them pseudonyms at most though which is ok for the use-cases that
this XEP wants to address. Full anonymity... is a hard claim.
Agreed; realistically they're just temporary alias' for your JID.
Registrar considerations:
An authorization service that provides ephemeral "burner" identities.
I would remove "burner" here.
Wilco.
Thanks!
—Sam
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
