Metronome if the internal hashed auth backend is used just stores sha-1/256/384/512 server keys hash variants in the account credentials datastore whenever a password is generated
DebXWoodyhas joined
stpeterhas joined
mukt2has joined
archas left
archas joined
Maranda
So it's more if you see DIGEST-MD5 offered to be a symptom that passwords are stored in plain
sonnyhas left
sonnyhas joined
krauqhas left
krauqhas joined
archas left
archas joined
archas left
archas joined
stpeterhas left
archas left
archas joined
archas left
archas joined
lovetoxhas joined
adiaholic_has left
adiaholic_has joined
goffihas joined
xeckshas joined
mukt2has left
adiaholic_has left
adiaholic_has joined
Jeybehas left
Jeybehas joined
Jeybehas left
Jeybehas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
mukt2has joined
Danielhas left
Danielhas joined
mukt2has left
nycohas left
mukt2has joined
dwdhas joined
debaclehas joined
dwd
Just reading back, I'm not actually sure of the reason I made SASL2 use a distinct stream feature. But as I've previously said, anything that makes SASL2 have a namespace bump to urn:xmpp:sasl:2 is fine by me. :-)
dwd
Also: https://tools.ietf.org/html/rfc5802#section-6.1 does indeed say that servers MUST tls-unique, and that clients SHOULD. But all normative requirements can be altered by negotiation, meaning that clients implicitly MAY use anything that the server explicitly says it can support.
debaclehas left
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
Neustradamus_
Thanks people to look SCRAM-SHA-256 and TLS Binding for -PLUS SCRAM variants.
dwd
larma, Final note - we're stuck with -PLUS because that comes from the SASL layer (or quite possibly the GS2 layer).
nycohas joined
dwd
Maranda, DIGEST-MD% doesn't need to store a plaintext password, though it does essentially mandate a plaintext equivalent. CRAM-MD5 has to store plaintext passwords, though, unless you do really shady things with partially computed HMACs.
mukt2has left
lovetoxhas left
Neustradamus_
If you search more informations: Do not lost this link: https://github.com/scram-xmpp/info/issues/1
rionhas left
karoshihas joined
rionhas joined
larma
dwd: I don't read the SCRAM RFC as if there was no way to work without -PLUS.
paulhas left
mukt2has joined
Dele Olajidehas joined
Neustradamus_
Do not forget the RFC 8600: https://tools.ietf.org/html/rfc8600 which it was published 2019-06-21 (soon one year):
"When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802]".✎
Neustradamus_
Do not forget the RFC 8600: https://tools.ietf.org/html/rfc8600 which has been published 2019-06-21 (soon one year):
"When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802]". ✏
krauqhas left
Guus
Is there someone in here with administrative powers on tigase.org ?
Neustradamus_
Guus: tigase@muc.tigase.org
Guus
Given that I want to discuss connectivity issues, that's not ideal. 🙂
Neustradamus_
I have informed you some days ago ;)
Neustradamus_
I have invited people here
Dele Olajidehas left
Guus
Thanks
Dele Olajidehas joined
larma
Neustradamus_: RFC 8600 is not relevant for most XMPP software (especially anything chat related). It merely "defines how to use XMPP for the exchange of security notifications on a controlled-access network among authorized entities"
stpeterhas joined
Neustradamus_
Maybe but SCRAM part is important.
Neustradamus_
And it is logic.
debaclehas joined
Andrzejhas joined
adiaholic_has left
adiaholic_has joined
dwd
But it's largely a profile of XMPP for a specific purpose - specifically, it doesn't update RFC 6120.
Neustradamus_
Guus: Andrzej from Tigase here
dwd
And if it had tried to, I would have shot that one down.
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
larma
It also says servers MUST support at least SCRAM or EXTERNAL. Which obviously should not apply to all XMPP usecases.
Neustradamus_: that doesn't make RFC8600 relevant in this context
reedhhwhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
reedhhwhas left
larma
Nobody is saying implementing SCRAM-SHA-256/-512 is a bad idea. But that doesn't mean it necessarily has the priority you are suggesting everywhere.
reedhhwhas joined
larma
I bet that if you do a pull request to any software that doesn't implement it yet, it would be accepted. But you can't blame developers for not giving it the priority you'd like.
Steve Killehas left
Neustradamus_
larma: the point is have the good order from best to worst SCRAM and RFC 8600 (stpeter is an author):
"When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802]".
Neustradamus_
It is not SCRAM-SHA-256 = SCRAM-SHA-1 or SCRAM-SHA-1 is preferred to SCRAM-SHA-256...
Neustradamus_
We can understand: SCRAM-SHA-256-PLUS > SCRAM-SHA-256 > SCRAM-SHA-1-PLUS > SCRAM-SHA-1
Steve Killehas joined
Neustradamus_
It is like DIGEST-MD5 > CRAM-MD5
Neustradamus_
Of course if the XMPP server supports, we can see in XMPP clients:
- if only SCRAM-SHA-1 it is easy
- if only SCRAM-SHA-256 it is easy
- if SCRAM-SHA-1-PLUS and SCRAM-SHA-1 // SCRAM-SHA-1-PLUS > SCRAM-SHA-1
- if SCRAM-SHA-256 and SCRAM-SHA-1 // SCRAM-SHA-256 > SCRAM-SHA-1
- if SCRAM-SHA-256-PLUS, SCRAM-SHA-256, SCRAM-SHA-1-PLUS, SCRAM-SHA-1 // SCRAM-SHA-256-PLUS > SCRAM-SHA-256 > SCRAM-SHA-1-PLUS > SCRAM-SHA-1
- if SCRAM-SHA-256-PLUS, SCRAM-SHA-1-PLUS // SCRAM-SHA-256-PLUS > SCRAM-SHA-1-PLUS✎
Neustradamus_
Of course if the XMPP server supports, we can see in XMPP clients:
- if only SCRAM-SHA-1 it is easy
- if SCRAM-SHA-1-PLUS and SCRAM-SHA-1 // SCRAM-SHA-1-PLUS > SCRAM-SHA-1
- if only SCRAM-SHA-256 it is easy
- if SCRAM-SHA-256-PLUS and SCRAM-SHA-256 // SCRAM-SHA-256-PLUS > SCRAM-SHA-256
- if SCRAM-SHA-256 and SCRAM-SHA-1 // SCRAM-SHA-256 > SCRAM-SHA-1
- if SCRAM-SHA-256-PLUS, SCRAM-SHA-256, SCRAM-SHA-1-PLUS, SCRAM-SHA-1 // SCRAM-SHA-256-PLUS > SCRAM-SHA-256 > SCRAM-SHA-1-PLUS > SCRAM-SHA-1
- if SCRAM-SHA-256-PLUS, SCRAM-SHA-1-PLUS // SCRAM-SHA-256-PLUS > SCRAM-SHA-1-PLUS ✏
Maranda
dwd: I didn't say it does, I said that "in Metronome it does"
dwd
Maranda, Ah, gotcha.
debaclehas joined
Maranda
The only auth backend that does provide DIGEST-MD5 is the internal plain one
paulhas joined
adiaholic_has left
adiaholic_has joined
lovetoxhas joined
xsfhas left
Neustradamus_has left
Neustradamus_has joined
lskdjfhas joined
larma
Neustradamus_, I think it's clear to everyone that IF both server and client support both SHA-1 and SHA-256, SHA-256 should be preferred. And that IF both server and client support -PLUS, -PLUS should be preferred. You apparently left out the small sidecase where SCRAM-SHA-1-PLUS and SCRAM-SHA-256 are supported, because it's not obvious what is to be preferred then (IMO it's -PLUS).
jonas’
(agreed on -PLUS over SHA2)
larma
However the default today is
a) servers typically don't offer SHA-256 because the password is hashed with SHA-1 in database, making it impossible to offer SHA-256. There is no proper upgrade path from SHA-1 to SHA-256.
b) clients don't offer SHA-256 because servers typically don't and it's not worth the effort to implement it for the very few cases where servers do. Because basically in all cases one can just fallback to PLAIN anyway without significant loss in security (if users follow best practices for passwords)
jonas’
in my arrogant developer opinion, if implementing SHA-256 is hard after you have the SHA-1 variant implemented, you are in dire need of refactoring.
larma
jonas’, that is indeed true 😉
larma
but it needs to be tested, which is already hard enough given there are so few servers in practice supporting it 😉
jonas’
I’m a believer in test-driven development, and if my SHA-1 implementation passes the test vectors, I’m confident enough that the SHA-256 variant will work flawlessly.
larma
IMO there is also a design fail in how we login that I have to present the mechanisms *before* knowing the login name.
larma
Was that tackled by sasl2?
jonas’
larma, presenting the mechanisms afterwards would be a security problem
jonas’
you could test user existence then
larma
as if that wasn't possible already through various ways...
larma
also servers could answer with fake mechanisms if user doesn't exist...
sonnyhas left
sonnyhas joined
jonas’
larma, the fake mechanisms would still look different than some user’s real mechanisms
sonnyhas left
sonnyhas joined
jonas’
and AFAIK user enumeration is a problem we generally avoid *by default* if possible.
larma
server could send the mechanisms that are send to the largest amount of users on the server. Than it's still possible to detect some users, but not all.
jonas’
yeah, and expensive to figure that out.
larma
However the advantage is huge as that would allow an upgrade path for the hash algorithm
jonas’
could do that with SASL2 already, though it requires offering *only* the old mechanism until all accounts have been upgraded.
larma
even in that case you have to store both password hashes for the time until all accounts upgraded. If it was per user, you could just do it per user. You could even decide server-side based on the clients that connected previously if you want to upgrade a user or not.
jonas’
yes, but that’s not feasible unless you want to allow user enumeration.✎
jonas’
yes, but that’s not feasible unless you want to allow user probing. ✏
jonas’
which RFC 6120 and RFC 6121 go a long way to avoid.
jonas’
nevermind that vcard-temp and possibly other things allow it if the user explicitly published some data
larma
IMO, user enumeration is when I can get a list of users, not when I can try out every possible JID.
jonas’
but the default is that you can’t enumerate accounts.
jonas’
larma, that’s why I /correct’d my message.
larma
right.
jonas’
s/enumerate/probe/
larma
well there are a ton of XEPs where you can probe users
jonas’
but only after the users did sometihng to allow that
larma
not even sure if it's not possible by RFC, but certainly by CS2020
larma
PEP for example makes users probe-able
jonas’
I’m aware of that
jonas’
but it shouldn’t be the default.
jonas’
(and it isn’t)
larma
that you have PEP?
jonas’
that you have a PEP node which is world-readable
larma
you don't need that
jonas’
you don’t?
larma
even if it's not readable, you get different errors
jonas’
that’s a bug then
jonas’
either in the standard or in the implementations
larma
also pubsub nodes MUST be disco-able
jonas’
I’m fairly certain that you can always return <forbidden/> if you don’t want to let someone read nodes
larma
jonas’, you could but it wouldn't be XEP-compliant. Also that doesn't solve the pubsub must be disco-able. If it wasn't you couldn't have world-readable PEP nodes.
jonas’
larma, then the XEP needs to be fixed
jonas’
but I’m sitll fairly certain that you can do that without having to fix the XEP
jonas’
ah, maybe only returning the items you can actually see would suffice already
karoshihas left
jonas’
my point is: those are issues which can and need to be fixed
karoshihas joined
jonas’
that they exist is no reason to open more issues.
larma
but if a user doesn't exist it also doesn't have a pep service on it's jid
larma, servers could easily pretend that there is an empty pep service. ✏
larma
I think it's just plain ignorant to claim that users are not probe-able and thus we should design protocols such that this remains true.
jonas’
that’s a valid opinion. I disagree.
Nekithas left
Nekithas joined
larma
Do you think it's likely we'll ever reach the state where user probing is not possible?
jonas’
yes
pdurbinhas left
nycohas left
nycohas joined
larma
ok, so how would you like to do the upgrade then?
jonas’
as I wrote above
jonas’
you’ll have to wait for all accounts to be upgraded
jonas’
typically that’s done with a deadline after which users have to use a password reset facility to regain access
jonas’
or their account is deleted
Neustradamus_
It is possible to have SCRAM-SHA-256(-PLUS) and SCRAM-SHA-1(-PLUS) enabled on an XMPP server but some users with only SCRAM-SHA-1 passwords (if originally not in PLAIN).
If the user change of password, SCRAM-SHA-1 and SCRAM-SHA-256 will be here.
Holger
Users love changing passwords for random reasons.
larma
Neustradamus_, upgrade only makes sense when we don't support SHA-1 afterwards (or at least that's when it really makes a difference)
Neustradamus_
Currently: Jackal XMPP server, Metronome IM, Mongoose IM master (soon a release), Prosody 0.12-dev, Tigase are already good.
Holger
We should just switch *TODAY*.
Zash
Flag day?
Holger
(kk I'll get coffee and quite trolling.)
Holger
quit
Daniel
This will instantly make xmpp 256 times more secure
larma
Neustradamus_, they all store passwords in both sha1 and sha256? doubt that... They probably support sha1 and sha256 when password is stored in plaintext
Zash
I'll get right to work hacking into every existing deployment and invalidating all credentials!
jonas’
Zash, easy!
jonas’
just publish mod_av which claims to enable A/V support immediately
Zash
larma, correct in the case of Prosody 0.12. Hashed credentials are stored in one or the other and can't be changed afterwards.
stpeterhas joined
larma
Zash, which means *proper* setups have no upgrade path to sha-256, which is exactly what I'd like to tackle somehow before we blame everyone for not implementing things that can't be upgraded on anyway
Zash
There's no upgrade path anyways
larma
There could be, we just don't have one yet.
larma
even if the upgrade only happens when you do your next password change, that's an upgrade path
larma
or it happens when you next sign in with a device that does PLAIN
larma
(which happens as soon as a client only supports PLAIN and SHA-256 and your server is still on SHA-1)
larma
however the upgrade path requires a way for the server to signal that they currently don't have the sha256 hash and thus can't use SCRAM-SHA-256
larma
and this should be per user.
jonas’
which is indistinguishable from a downgrade attack, by the way.
Zash
this
larma
a downgrade attack through an authenticated channel?
Zash
If I somehow steal your cert+privkey and get your clients to connect to me and I only offer PLAIN, I can steal their passwords.
larma
only if they have the passwod in cleartext, which they shouldn't if your server supported scram
larma
I was talking about a newly connecting client, and that would be fooled by such attack anyways
jonas’
FTR, we do have: https://tools.ietf.org/html/rfc6120#section-6.5.9
larma
also when I can get you to connect to me without -PLUS I can already steal all your messages from MAM which is probably worth way more than the password...
jonas’
given that the initial data in SCRAM is enough to identify the user, servers could reply with mechanism-too-weak on a migrated account
jonas’
not sure what to do with a non-migrated account though
Zash
Is there an "upgrade required"?
larma
jonas’, but then I can probe users again
jonas’
larma, yes
larma
also mechanism-too-weak will probably fail on clients
jonas’
can I swing my "arrogant developer hammer" again? ;)
larma
assuming clients exist that only do plain and sha-1 and server supports plain,sha-1 and sha-256 in general, but for a specific account only plain+sha-256 (because account was upgraded), the client should try sha-1 and then would get <mechanism-too-weak/> which shouldn't be interpreted as "try plain instead"
stpeterhas left
larma
= in this upgrade path a proper client would stop working for no good reason.
mukt2has left
mukt2has joined
Neustradamus_
larma: if an XMPP client has only SCRAM-SHA-1 and server has PLAIN and SCRAM-SHA-256, it fails.
Marandahas left
Marandahas joined
Neustradamus_
Note that an XMPP client can have in settings : force PLAIN password, ...
Gajim via nbxmpp has SCRAM-SHA-256(-PLUS) and SCRAM-SHA-1(-PLUS)
https://dev.gajim.org/gajim/python-nbxmpp/commit/f2a203387891455c052d44f8b1ceae711773cb81
Neustradamus_
lovetox: ^
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
mukt2has left
larma
Neustradamus_, I think you are missing the point here really. There is no client that does not support PLAIN. And it's unlikely there ever will be.
mukt2has joined
calvinhas joined
LNJhas joined
Dele Olajidehas left
mukt2has left
calvinhas left
etahas left
etahas joined
mukt2has joined
Ge0rGhas left
Maranda
> Neustradamus_, they all store passwords in both sha1 and sha256? doubt that... They probably support sha1 and sha256 when password is stored in plaintext
Why not that's what I exactly do✎
Maranda
> Neustradamus_, they all store passwords in both sha1 and sha256? doubt that... They probably support sha1 and sha256 when password is stored in plaintext
Why not that's what I exactly do larma ✏
Ge0rGhas joined
Neustradamus_
Maranda: How it is done with Metronome and your XMPP server?
Maranda
I just said that I generate server keys for each hashing algorythm I support for SCRAM
larma
Maranda, but then you don't have the advantage of the more secure hashing algorithm to protect password from cracking (if password database is leaked). Because I can just attack the hash with the lowest security (sha-1)
moparisthebesthas joined
larma
which kind of is the point of using sha-256 over sha-1
Maranda
And then most bussness infrastructures out there do still have the requirement to have at least reversible encrypted passwords, so the whole argument is kind of "a good purpose" one but again all it matters is safety and trust of the who deals with 'em.
Zash
Could someone find a cryptomath wizard and ask them to calculate the ratio of securityness between sha-256 and sha-1
Zash
... and then we just increase the minimum iteration count by that ratio!!!
Zash
bam, sha1 forever
pdurbinhas joined
larma
.... that's not how this works...
Maranda
larma: i'd ditch all other mechanisms for scram-sha-512-plus already just get all clients to support that and channel binding and we have a deal
larma
Maranda, sounds like a great plan, except it doesn't work because legacy clients will always be around.
Maranda
larma: oh really? 😘
larma
😉
Zash
(and scram-sha-512-plus is undefined and doesn't exist)
larma
can we do scram-argon2d-plus please?
Zash
sure
larma
*Argon2id
Zash
I the SCRAM construct doesn't depend that much on PBKDF2✎
Zash
The SCRAM construct doesn't depend that much on PBKDF2 ✏
Zash
any ƒ(password, salt, iterations) → blob would do in theory
Zash
Gets weird if it takes other parameters than those tho
larma
well, it already does that
larma
SCRAM-SHA-256 has ƒ(password, salt, iterations) = sha2(32, password, salt, iterations)
Zash
You mean PBKDF2(hmac-sha-256, ..., output size)
karoshihas left
karoshihas joined
Zash
Hi() is a special case of PBKDF2 with some predefined parameters
larma
whatever 😉 sha-256 already is sha-2 + 32 byte. So any SCRAM-ARGON-X could do the same
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
larma
but probably not gonna happen soonish anyway 🙁
larma
probably never
Zash
Not with that attitude :P
larma
would be too good if we weren't discussing upgrading to something that's already outdated...
Zash
SHA-2 isn't outdated?
larma
there is SHA-3, so by definition SHA-2 is outdated
Zash
SHA-2 isn't broken yet afaik
larma
yeah, wasn't saying broken
larma
sha-1 also isn't broken for our usage
Zash
I thought the point of picking a SHA-3 was to have something in case the very foundational concepts that SHA-2 (and SHA-1) are built on were broken, and that's not happen yet
Zash
Yeah, so why the push to SHA-2?
Zash
We gain nothing but pain atm
larma
It's not me who is pushing 😉
larma
I am just pushing for an upgrade path, so we can handle it should it become necessary
larma
plan the upgrade now so it can happen in 10 years or so
larma
don't do another 12-byte IV 😀
Zash
Invent a better SCRAM, one that can tell the client in a secure manner "yo, you gonna need to reset your password for security upgrade reasons"
jonas’
Zash, you can do that with SASL2 after successfully authenticating with SCRAM first
Zash
Sure
stpeterhas joined
Neustradamus_
SCRAM SHA-3 is planned yes
larma
And SCRAM Argon2id?
pdurbinhas left
calvinhas joined
Zash
It's tricky since you don't know at the time when you're offering mechanisms whether the user supports them.
!XSF_Martinhas left
!XSF_Martinhas joined
jonas’
we’ve been at this point two hours ago
Zash
:)
Zash
And weeks/months ago.
larma
maybe we should have clients propose mechanism to the server not the other way round
Zash
I'm just copying from a script actually :P
jonas’
larma, and then what? you can still probe by looking at the mechanisms accepted for $randomUUID vs. $guessedUsername
larma
it adds complexity to the attack
jonas’
not much though
Maranda
Oh heaven so this is about brute forcing SCRAM?
larma
maybe we need a stateful authentication protocol and abandon passwords after first login
jonas’
Maranda, no
jonas’
larma, like the thing dave wrote?
Maranda
And/or possibility of
jonas’
also, I’m all for it
jonas’
Maranda, no
Maranda
jonas’: better
Jeybehas left
Marandahas a log tail which could have been more interesting in that case 👨💻
larma
jonas’, not sure about the exact protocol, but yeah something that gives you a per-client token that can be stored by the client and also can be revoked if necessary.
Zash
OAuth?
larma
Alternatively we could only announce PLAIN in mechanisms, than get told the mechanisms supported by server *after* succesful login and be able to use SCRAM-* on later logins, ignoring that only PLAIN is announced.
Zash
What was that combined auth and stream resumption token spec called?
Zash
larma, haha
larma
Zash, 397?
Zash
That's the one
jonas’
https://tools.ietf.org/html/draft-cridland-kitten-clientkey-00 that’s the one I meant
andrey.ghas left
larma
E_TOO_MANY_PROTOCOLS
Zash
Bring back https://xmpp.org/extensions/xep-0078.html !!!!11! /s
larma
Zash, IIRC in OAuth the client has to register a-priori with the service to receive the client-key, no?
Zash
It Depends!
larma
which is also why OAuth for email got no traction. email clients only support Google and Microsoft for OAuth
Zash
If you use deprecated parts of OAuth you can get a token using a password.
larma
Ah, right. But that's not how it's supposed to be.
larma
Because you can't make use of service specific login pages that do 2fa and alike then.
stpeterhas left
Zash
If you're going to use OAuth "as it's supposed to be" then you can't have nice things, only browser and web services.
larma
well non-browser clients can open a web browser to authenticate than callback to the client
larma
that's how thunderbird does googlemail
Zash
from another part of my script, I say "if I have to open a browser then I hate it"
larma
that's ok, you can still do PLAIN
larma
with a single-use password you somehow retrieved from your service
larma
(probably using a browser)
Dele Olajidehas joined
robertooohas left
robertooohas joined
govanifyhas left
govanifyhas joined
govanifyhas left
govanifyhas joined
adiaholic_has left
adiaholic_has joined
andrey.ghas joined
waqashas joined
dwd
XEP-0397 is CLIENTKEY, but the SASL bits live in the I-D. The other thing you could do is XEP-0257 (or similar).
emushas left
emushas joined
larma
dwd, xep-0397 doesn't have the counter part built-in. And it's also not asking for TOTP (which probably shouldn't have been in clientkey anyway)
dwd
Oh, wait. Wrong XEP.
larma
oh, and xep-0397 also doesn't have expiry
dwd
XEP-0399.
larma
I kind of wonder why all the TOTP is part of those XEPs
larma
seems kind of arbitrary to put it in there, as it could be completely ignored
larma
I see it makes things easier if TOTP is required, but it also works and makes sense without TOTP
andyhas left
larma
but in general, I'd rather see 399 being pushed than SCRAM-SHA-256
dwd
For '399? That was the driving factor for Surevine, as it happens.
larma
I mean TOTP is obviously non-normative in '399, so I am fine with that, but I'd probably want to get rid of that before moving it to draft.
dwd
So we had a requirement from the market for second-factor, based on TOTP. So we had SASL2+TOTP (in Openfire, code public), but it was a browser-based client, so we needed to avoid forcing the user to re-enter TOTP every time they refreshed, hence '399.
larma
Also CLIENT-KEY and CLIENT-KEY-PLUS would need to be IANA registered first, right?
dwd
The '399 code is also public, but it's an earlier design.
larma
dwd, yeah I guessed that TOTP was the driving force here 😉
dwd
larma, Sorta. Eventually. But they're in I-D form now.
dwd
larma, But I wouldn't remove 2FA entirely from '399 - while CLIENTKEY isn't dependent on it, it feels important that a client shouldn't ordinarily get a TOTP challenge when using CLIENTKEY, since the client installation has become the second factor, sort of.
larma
Yes, I am fine with mentioning that, basically the 4th sentence in §2.
larma
Also probably the other way round, mention it in 400, no?