Hi Daniel, thanks very much for writing down the proposal! I like the principal idea very much, and I have just some small questions and remarks.
* Daniel Gultsch <[email protected]> [2017-04-27 17:59]: > * Clients subscribe to private PEP node. (See XEP-0223 on how to make a pep > node private) > * One client (the first client that ever wants to create a token) generates > a 32 byte secret key and uploads that key into the node (base64) > * New tokens are created by generating a 16 byte IV, an expiration date as > unix time stamp (2 byte) (Expiration date should be choose about 24-72h > into the feature depending on use case)). 16 byte IV + 8 byte (as corrected in the followup) date + 16 byte AES256 output = 40 bytes --> base64 = 54 characters. that's an awfully long token. > The 2 byte expiration date is encrypted using AES256-GCM using the 32 > byte key and the 16 byte IV. What would be wrong with a truncated HMAC-SHA256(timestamp)? I don't see the need to add an IV to invitation links, and I'd rather use an HMAC than something semi-hand-crafted. > * A server which is also in possession of the secret key (due to it being > in the PEP node) can 'decrypt' the tokens and check if the expiration date > is >= NOW() and authenticate a subscription request on the users behalf. That's a very elegant idea! > * A server which can do that should probably announce the pars namespace on > the account. Is there a specific need for that, except than to boost its compliance ranking? ;-) > * Any client can at any given time upload a new 32 byte secret invalidating > all old tokens I think this also provides a great UX to the invalidation case. > * A token can be used multiple times. However I consider that desirable > because I a) want to send the same link to multiple recipients b) avoid the > UX problem of having the user decide if they want to create a single use > token or a multi use token. I see the UX problems, but I'm not sure if this is a good idea security-wise. I'd like to hear other opinions on this. The pros of this approach are: - a lifetime (24-72h) is a useful mitigation - it doesn't matter if an attacker who got your token can subscribe to your presence once or a thousand times - pending subscriptions are a similar DoS in most clients as completed subscriptions. The cons currently boil down to my gut feeling that limiting tokens to "once" or "N times" with a small N is useful. Greetings Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? || ++ IRCnet OFTC OPN ||_________________________________________________||
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
