MarandaMetronome 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
MarandaSo 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
dwdJust 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. :-)
dwdAlso: 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.
dwdlarma, Final note - we're stuck with -PLUS because that comes from the SASL layer (or quite possibly the GS2 layer).
nycohas joined
dwdMaranda, 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
larmadwd: 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
GuusIs there someone in here with administrative powers on tigase.org ?
Neustradamus_Guus: tigase@muc.tigase.org
GuusGiven 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
GuusThanks
Dele Olajidehas joined
larmaNeustradamus_: 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
dwdBut it's largely a profile of XMPP for a specific purpose - specifically, it doesn't update RFC 6120.
Neustradamus_Guus: Andrzej from Tigase here
dwdAnd if it had tried to, I would have shot that one down.
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
larmaIt also says servers MUST support at least SCRAM or EXTERNAL. Which obviously should not apply to all XMPP usecases.
larmaNeustradamus_: that doesn't make RFC8600 relevant in this context
reedhhwhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
reedhhwhas left
larmaNobody 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
larmaI 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
Marandadwd: I didn't say it does, I said that "in Metronome it does"
dwdMaranda, Ah, gotcha.
debaclehas joined
MarandaThe 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
larmaNeustradamus_, 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)
larmaHowever 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.
larmajonas’, that is indeed true 😉
larmabut 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.
larmaIMO there is also a design fail in how we login that I have to present the mechanisms *before* knowing the login name.
larmaWas that tackled by sasl2?
jonas’larma, presenting the mechanisms afterwards would be a security problem
jonas’you could test user existence then
larmaas if that wasn't possible already through various ways...
larmaalso 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.
larmaserver 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.
larmaHowever 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.
larmaeven 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
larmaIMO, 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.
larmaright.
jonas’s/enumerate/probe/
larmawell there are a ton of XEPs where you can probe users
jonas’but only after the users did sometihng to allow that
larmanot even sure if it's not possible by RFC, but certainly by CS2020
larmaPEP 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)
larmathat you have PEP?
jonas’that you have a PEP node which is world-readable
larmayou don't need that
jonas’you don’t?
larmaeven if it's not readable, you get different errors
jonas’that’s a bug then
jonas’either in the standard or in the implementations
larmaalso 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
larmajonas’, 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.
larmabut if a user doesn't exist it also doesn't have a pep service on it's jid
jonas’larma, servers could easily pretend that
jonas’larma, servers could easily pretend that there is an empty pep service.
larmaI 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
larmaDo 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
larmaok, 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.
HolgerUsers love changing passwords for random reasons.
larmaNeustradamus_, 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.
HolgerWe should just switch *TODAY*.
ZashFlag day?
Holger(kk I'll get coffee and quite trolling.)
Holgerquit
DanielThis will instantly make xmpp 256 times more secure
larmaNeustradamus_, they all store passwords in both sha1 and sha256? doubt that... They probably support sha1 and sha256 when password is stored in plaintext
ZashI'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
Zashlarma, 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
larmaZash, 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
ZashThere's no upgrade path anyways
larmaThere could be, we just don't have one yet.
larmaeven if the upgrade only happens when you do your next password change, that's an upgrade path
larmaor 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)
larmahowever 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
larmaand this should be per user.
jonas’which is indistinguishable from a downgrade attack, by the way.
Zashthis
larmaa downgrade attack through an authenticated channel?
ZashIf I somehow steal your cert+privkey and get your clients to connect to me and I only offer PLAIN, I can steal their passwords.
larmaonly if they have the passwod in cleartext, which they shouldn't if your server supported scram
larmaI 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
larmaalso 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
ZashIs there an "upgrade required"?
larmajonas’, but then I can probe users again
jonas’larma, yes
larmaalso mechanism-too-weak will probably fail on clients
jonas’can I swing my "arrogant developer hammer" again? ;)
larmaassuming 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, ...
Neustradamus_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
larmaNeustradamus_, 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?
MarandaI just said that I generate server keys for each hashing algorythm I support for SCRAM
larmaMaranda, 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
larmawhich kind of is the point of using sha-256 over sha-1
MarandaAnd 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.
ZashCould 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!!!
Zashbam, sha1 forever
pdurbinhas joined
larma.... that's not how this works...
Marandalarma: 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
larmaMaranda, sounds like a great plan, except it doesn't work because legacy clients will always be around.
Marandalarma: oh really? 😘
larma😉
Zash(and scram-sha-512-plus is undefined and doesn't exist)
larmacan we do scram-argon2d-plus please?
Zashsure
larma*Argon2id
ZashI the SCRAM construct doesn't depend that much on PBKDF2
ZashThe SCRAM construct doesn't depend that much on PBKDF2
Zashany ƒ(password, salt, iterations) → blob would do in theory
ZashGets weird if it takes other parameters than those tho
larmawell, it already does that
larmaSCRAM-SHA-256 has ƒ(password, salt, iterations) = sha2(32, password, salt, iterations)
ZashYou mean PBKDF2(hmac-sha-256, ..., output size)
karoshihas left
karoshihas joined
ZashHi() is a special case of PBKDF2 with some predefined parameters
larmawhatever 😉 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
larmabut probably not gonna happen soonish anyway 🙁
larmaprobably never
ZashNot with that attitude :P
larmawould be too good if we weren't discussing upgrading to something that's already outdated...
ZashSHA-2 isn't outdated?
larmathere is SHA-3, so by definition SHA-2 is outdated
ZashSHA-2 isn't broken yet afaik
larmayeah, wasn't saying broken
larmasha-1 also isn't broken for our usage
ZashI 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
ZashYeah, so why the push to SHA-2?
ZashWe gain nothing but pain atm
larmaIt's not me who is pushing 😉
larmaI am just pushing for an upgrade path, so we can handle it should it become necessary
larmaplan the upgrade now so it can happen in 10 years or so
larmadon't do another 12-byte IV 😀
ZashInvent 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
ZashSure
stpeterhas joined
Neustradamus_SCRAM SHA-3 is planned yes
larmaAnd SCRAM Argon2id?
pdurbinhas left
calvinhas joined
ZashIt'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:)
ZashAnd weeks/months ago.
larmamaybe we should have clients propose mechanism to the server not the other way round
ZashI'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
larmait adds complexity to the attack
jonas’not much though
MarandaOh heaven so this is about brute forcing SCRAM?
larmamaybe we need a stateful authentication protocol and abandon passwords after first login
jonas’Maranda, no
jonas’larma, like the thing dave wrote?
MarandaAnd/or possibility of
jonas’also, I’m all for it
jonas’Maranda, no
Marandajonas’: better
Jeybehas left
Marandahas a log tail which could have been more interesting in that case 👨💻
larmajonas’, 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.
ZashOAuth?
larmaAlternatively 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.
ZashWhat was that combined auth and stream resumption token spec called?
Zashlarma, haha
larmaZash, 397?
ZashThat's the one
jonas’https://tools.ietf.org/html/draft-cridland-kitten-clientkey-00 that’s the one I meant
andrey.ghas left
larmaE_TOO_MANY_PROTOCOLS
ZashBring back https://xmpp.org/extensions/xep-0078.html !!!!11! /s
larmaZash, IIRC in OAuth the client has to register a-priori with the service to receive the client-key, no?
ZashIt Depends!
larmawhich is also why OAuth for email got no traction. email clients only support Google and Microsoft for OAuth
ZashIf you use deprecated parts of OAuth you can get a token using a password.
larmaAh, right. But that's not how it's supposed to be.
larmaBecause you can't make use of service specific login pages that do 2fa and alike then.
stpeterhas left
ZashIf you're going to use OAuth "as it's supposed to be" then you can't have nice things, only browser and web services.
larmawell non-browser clients can open a web browser to authenticate than callback to the client
larmathat's how thunderbird does googlemail
Zashfrom another part of my script, I say "if I have to open a browser then I hate it"
larmathat's ok, you can still do PLAIN
larmawith 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
dwdXEP-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
larmadwd, 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)
dwdOh, wait. Wrong XEP.
larmaoh, and xep-0397 also doesn't have expiry
dwdXEP-0399.
larmaI kind of wonder why all the TOTP is part of those XEPs
larmaseems kind of arbitrary to put it in there, as it could be completely ignored
larmaI see it makes things easier if TOTP is required, but it also works and makes sense without TOTP
andyhas left
larmabut in general, I'd rather see 399 being pushed than SCRAM-SHA-256
dwdFor '399? That was the driving factor for Surevine, as it happens.
larmaI 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.
dwdSo 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.
larmaAlso CLIENT-KEY and CLIENT-KEY-PLUS would need to be IANA registered first, right?
dwdThe '399 code is also public, but it's an earlier design.
larmadwd, yeah I guessed that TOTP was the driving force here 😉
dwdlarma, Sorta. Eventually. But they're in I-D form now.
dwdlarma, 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.
larmaYes, I am fine with mentioning that, basically the 4th sentence in §2.
larmaAlso probably the other way round, mention it in 400, no?