wamp-proto
Support for structured authmethod names [was: Will support SM2 and SM3 algorithm?]
Hello everyone,
I am implementing the advanced profile part, and I would like to ask, do we support Chinese cryptographic algorithms: SM3 (hash function) and SM2 (public-private key cryptography)?
They are Chinese national cryptography standards, and all Chinese commercial softwares MUST implement them.
So, if we don't support them officially, other Chinese engineers or I will need to fork a spec for China.
Well, this is an interesting and important question we should decide as a community ("rough consensus").
I would like to keep WAMP as open and adaptable as possible, giving users sufficient and relevant information to decide themself what features to use. And users will have different priorities, constraints or whatever.
Let me constraint above with what I would still do (as said, open for discussion) rgd the WAMP spec:
- it MUST be transparent and allow users to make an informed choice
- it MUST NOT enforce weak security on WAMP in total (its architecture or such)
- it SHOULD recommend secure options by default
Of course these "standards" could get tricky. Trust is tricky.
Personally, I'm probably on the paranoid side of things. The standards I used in WAMP-cryptosign and WAMP end-to-end encryption are all promoted by djb
https://safecurves.cr.yp.to/ https://blog.cr.yp.to/
I don't understand the math in detail, but I do trust this guy and associated researchers. More than any nation state standards, no matter which country.
Anyways, making it more concrete, the places where hashes are used in WAMP are all from the AP:
oberstet@intel-nuci7:~$ find scm/wamp-proto/wamp-proto/rfc -name "*.md" -exec grep -Hi "sha256" {} \;
scm/wamp-proto/wamp-proto/rfc/text/advanced/ap_45_interface_catalogs.md:openssl sha256 example.zip
scm/wamp-proto/wamp-proto/rfc/text/advanced/ap_50_payload_passthru_mode.md:*: The least significant 20 bytes (160 bits) of the SHA256 of the public key (32 bytes) of the data encryption key,
scm/wamp-proto/wamp-proto/rfc/text/advanced/ap_33_authentication_cra.md: signature := HMAC[SHA256]_{secret} (challenge)
scm/wamp-proto/wamp-proto/rfc/text/advanced/ap_33_authentication_cra.md:That is, compute the HMAC-SHA256 using the shared `secret` over the `challenge`.
scm/wamp-proto/wamp-proto/rfc/text/advanced/ap_35_authentication_cryptosign.md:| sha256 | Session Authentication (WAMP-Cryptosign authentication) |
scm/wamp-proto/wamp-proto/rfc/text/advanced/ap_35_authentication_cryptosign.md:Note that `sha256` refers to the SHA-2 algorithm, while `sha3-256` is a different algorithm refering to SHA-3.
scm/wamp-proto/wamp-proto/rfc/text/advanced/ap_34_authentication_scram.md:* `SHA256(str)`: The SHA-256 cryptographic hash function.
scm/wamp-proto/wamp-proto/rfc/text/advanced/ap_34_authentication_scram.md:StoredKey = SHA256(ClientKey)
scm/wamp-proto/wamp-proto/rfc/text/advanced/ap_34_authentication_scram.md:StoredKey = SHA256(ClientKey)
scm/wamp-proto/wamp-proto/rfc/text/advanced/ap_34_authentication_scram.md:RecoveredStoredKey = SHA256(RecoveredClientKey)
Which hashes specifically?
I don't understand the math in detail, but I do trust this guy and associated researchers.
Yes, but, in the first link, the footer shows that it was updated in January 2017. Chinese SM serials first time added into OpenSSL is September 2018 (OpenSSL 1.1.1 Release Note).
Which hashes specifically?
All SHA256 can be replaced by SM3.
all Chinese commercial softwares MUST implement them
Is it MUST or MUST ONLY?
Rgd WAMP-CRA (ap_33_authentication_cra): is HMAC allowed in China?
Rgd WAMP-SCRAM (ap_34_authentication_scram): not sure if it works with SM3. ping @ecorm
Rgd WAMP-Cryptosign: again, not sure, I haven't looked at SM3/SM2, a deeper look is needed whether those could be used as drop-in in the current scheme. ping @meejah
In general, rgd these auth methods: none of those have crypto primitive negotiation built in (this is by design). What we could do is name the CN auth methods eg like wampcra-cn or similar
That is basically new CN flavors as new auth methods.
rgd
ap_45_interface_catalogs ap_50_payload_passthru_mode
this is a much more involved discussion. one reason is, this is supposed to lay the foundations for a world-wide compatible scheme (for catalogs on ethereum) and user-stays-in-control-no-matter-what e2e encryption ... mmmh
rereading my para above, I should make clear I'm +1 in general, because if developers want to but cannot use WAMP because of whatever constraints, we (as a project) should really try our best to enable/support what's needed. find the right sweet spot for developers and end users.
fwiw, curve25519 is used (ed25519 signatures) in WAMP-cryptosign (and the e2e stuff ..)
oberstet@intel-nuci7:~$ find scm/wamp-proto/wamp-proto/rfc -name "*.md" -exec grep -Hi "25519" {} \;
scm/wamp-proto/wamp-proto/rfc/text/advanced/ap_35_authentication_cryptosign.md:*public-private key cryptography*. Specifically, it is based on [Ed25519](https://ed25519.cr.yp.to/) digital signatures as described in [@!RFC8032].
scm/wamp-proto/wamp-proto/rfc/text/advanced/ap_35_authentication_cryptosign.md:**Ed25519** is an [elliptic curve signature scheme](https://ed25519.cr.yp.to/ed25519-20110926.pdf) that instantiates the Edwards-curve Digital Signature Algorithm (EdDSA) with elliptic curve parameters which are equivalent to [Curve25519](https://cr.yp.to/ecdh.html).
scm/wamp-proto/wamp-proto/rfc/text/advanced/ap_35_authentication_cryptosign.md:**Curve25519** is a [SafeCurve](https://safecurves.cr.yp.to/), which means it is easy to implement and avoid security issues resulting from common implementation challenges and bugs.
scm/wamp-proto/wamp-proto/rfc/text/advanced/ap_35_authentication_cryptosign.md:Ed25519 is intended to operate at around the 128-bit security level, and there are robust native implementations available as open-source, e.g. [libsodium](https://github.com/jedisct1/libsodium), which can be used from script languages, e.g. [PyNaCl](https://github.com/pyca/pynacl).
scm/wamp-proto/wamp-proto/rfc/text/advanced/ap_35_authentication_cryptosign.md:| curve25519 | Session Authentication (WAMP-Cryptosign authentication) |
scm/wamp-proto/wamp-proto/rfc/text/advanced/ap_35_authentication_cryptosign.md:| ed25519 | Session Authentication (WAMP-Cryptosign Authentication) |
scm/wamp-proto/wamp-proto/rfc/text/advanced/ap_35_authentication_cryptosign.md:When no channel binding is active, the Ed25519 signature over the 32 bytes message MUST be computed using the WAMP-Cryptosign *private key* of the authenticating client.
oberstet@intel-nuci7:~$
I think the WAMP spec may be too monolithic and could be split into several RFCs. Extensible things like transports and authentication methods could be their own RFCs that build on top of the "core" WAMP spec. We could set up a registry of URIs and numbers that identify these extensions.
Someone wanting their own specialized authentication method using different cryptographic functions could just write their own RFC that references the "core" WAMP spec and possibly one of the WAMP extension RFCs.
I write the above knowing that it's more convenient from a maintenance standpoint to just have the one big monolithic document.
Rgd WAMP-SCRAM (ap_34_authentication_scram): not sure if it works with SM3. ping @ecorm
I haven't touched SCRAM since I wrote that part of the spec years ago. I haven't even implemented it (yet). I would have to re-learn it the same as anybody else. Even after I relearn it, I'm not sure I'm qualified to comment on the suitability of substituting SHA256 with SM3.
Is it MUST or MUST ONLY?
It is MUST, not MUST ONLY. But more and more software uses the SM series as the primary algorithm, and only use the SHA family as legacy-compatible algorithm.
Rgd WAMP-CRA (ap_33_authentication_cra): is HMAC allowed in China?
Of course, China also uses HMAC, but the hash part should be SM3, that is, HMAC-SM3.
Rgd WAMP-SCRAM (ap_34_authentication_scram): not sure if it works with SM3.
It also works, just use SM3 instead of SHA256 as the hash function.
Rgd WAMP-Cryptosign: again, not sure
I haven't implemented this part yet, but it's still possible as long as the spec doesn't restrict having to use the listed algorithms.
In general, rgd these auth methods: none of those have crypto primitive negotiation built in (this is by design). What we could do is name the CN auth methods eg like wampcra-cn or similar
I think, we just need to add a field "hashalgo" in the Extra dict of CHALLENGE and/or AUTHENTICATE message, the value can be "SHA256", "SM3" or other hash algorithm.
fwiw, curve25519 is used (ed25519 signatures) in WAMP-cryptosign (and the e2e stuff ..)
The latest TLS v1.3 RFC8446 not contains SM ciphers, but here have another informational level RFC8998 describe SM ciphers for TLS.
I mean, WAMP-Cryptosign can using SM for authentication, but can't using them for TLS channel binding before TLS include SM ciphers.
I think, we just need to add a field "hashalgo" in the Extra dict of CHALLENGE and/or AUTHENTICATE message, the value can be "SHA256", "SM3" or other hash algorithm.
Let's consider treating them as separate authentication methods so that they can be negotiated, e.g. wamp-scram-sm3.
I see that there are currently two flavors of wamp-scram: argon2id13 and pbkdf2. I regret that we didn't treat them as two separate auth methods. I don't remember the rationale for merging them in the same auth method with a kdf option to distinguish the two. The reasoning might be somewhere in the long discussions of the pull request or associated issue.
Let's consider treating them as separate authentication methods so that they can be negotiated
No, SM3 is just a hash function, not a key derivation function, it is not suitable to be a new authentication method independently, but it can be used in combination with pbkdf2, namely: PBKDF2-HMAC-SM3.
Well, interesting question! For example, in E2EE part, we have options to specify the encryption scheme; anyone can build its own scheme and use it. But we missed that for the authentication part. So I think it would be better to create a separate auth scheme like @ecorm suggests. This way we can preserve backward compatibility. @SunFulong Yeah, I understand that it is just a hash function and not a brand-new auth flow. We can add an algo/scheme name to the options dictionary. That's a pretty natural place. But we need to figure out how all current implementations can work without breaking...
But we need to figure out how all current implementations can work without breaking...
My opinion is: the new algo/scheme field is an optional item. If not passed, the router default algorithm will be used. As a client, before connecting to a router, users should clearly know what the default algorithm used by the router is through the router's documentation.
I don't remember the rationale for merging them in the same auth method with a kdf option to distinguish the two. The reasoning might be somewhere in the long discussions of the pull request or associated issue.
Merging the two flavors of wamp-scram was requested in this comment: https://github.com/wamp-proto/wamp-proto/issues/135#issuecomment-371653110
No, SM3 is just a hash function, not a key derivation function, it is not suitable to be a new authentication method independently, but it can be used in combination with pbkdf2, namely: PBKDF2-HMAC-SM3.
What I meant was this:
-
wamp-scram(PBKDF+SHA256 or Argon2+SHA256) -
wamp-scram-sm3(PBKDF+SM3 or Argon2+SM3)
But in the case of wamp-scram, I concede that an option for the hash function would indeed be more consistent with the way the KDF is currently specified as an option.
I still think it was a mistake to not treat the two current flavors wamp-scram as distinct auth methods, but I suppose it may be too late to change it now. I think what would have been more ideal is something like:
-
wamp-scram-pbkdf-sha256 -
wamp-scram-argon2id-13-sha256 -
wamp-scram-pbkdf-sm3 -
wamp-scram-argon2id-13-sm3
as distinct auth methods. A simple lookup table in a router implementation can determine which KDF and hash functions are requested in a specific wamp-scram-* auth method.
in E2EE part, we have options to specify the encryption scheme; anyone can build its own scheme and use it
yes, anyone can fork the spec, call it XYZ, and do what he wants!
but "Payload Passthru Mode" specifies only very concrete ciphers: https://wamp-proto.org/wamp_latest_ietf.html#section-14.1-35
basically xsalsa20poly1305 or aes256gcm
"e2e encryption" goes much further, and specifies (but it's still a PR)
https://github.com/wamp-proto/wamp-proto/blob/f400554704ff96d39d7aa8a92c6f21b56751b823/_work/ap_51_e2e_encryption.pdf
but I suppose it may be too late to change it now.
Yes, it's too late for me too!
The entire authentication section uses SHA-256 as the default hash function, there is no field or property describing which hash function should be used.
Let's assume: If in the next year, SHA256 is not safe and needs to be replaced by SHA3-512, what should we do?
Let's assume: If in the next year, SHA256 is not safe and needs to be replaced by SHA3-512, what should we do?
Good point!
If in the next year, SHA256 is not safe and needs to be replaced by SHA3-512, what should we do?
remove the old broken authmethod altogether, and define a new (supposedly secure) one.
the complete removal of any negotiation from authentication methods is by design
the rationale is: choose the most secure auth method today as default, if that becomes insecure, throw away old crap immediately. eg also followed in wireguard, explained https://www.youtube.com/watch?v=88GyLoZbDNw
here is Noise protocol
http://noiseprotocol.org/noise.html#dh-functions-cipher-functions-and-hash-functions http://noiseprotocol.org/noise.html#hash-functions-and-hashing
Let's assume: If in the next year, SHA256 is not safe and needs to be replaced by SHA3-512, what should we do?
There are two possibilities:
- Add a
hashalgooption as you suggest - Define a new authmethod using the new hash function and make the old one obsolete (edit: as @oberstet remarked at the same time I was typing this)
- Add a
hashalgooption as you suggest
I'm -1 on that
Define a new authmethod
if we want to support CN hash funs etc, this would be the +1 approach for me
Add a hashalgo option as you suggestI'm -1 on that
Then, to be consistent, the wamp-scram auth method should be deprecated in favor of wamp-scram-pbkdf-sha256 and wamp-scram-argon2id-13-sha256 which gets rid of the kdf option. I don't know if there are other auth methods that have selectable algorithm options.
remove the old broken authmethod altogether, and define a new (supposedly secure) one.
If the spec can accept the continuous addition and deletion of authmethod, I don't care about anything else.
Will we really do this?
If the spec can accept the continuous addition and deletion of authmethod, I don't care about anything else.
This is why I think the large, monolithic WAMP spec should be broken up into a "core" part, and separate documents for extensions like transports and authentication methods. This is very common approach for other IETF standards.
If WAMP ever goes beyond IETF draft status, you could claim your product implements RFCxxxx for the core WAMP standard, plus RFCyyyy for the authentication method that uses algorithms approved by your government.
This is why I think the large
I agree with you, but for now, maybe we should focus more on completing the full spec.
A simple lookup table in a router implementation can determine which
yes! and we do have negotiation at this outer, basic level already. I just rechecked, and the spec text isn't sufficient .. IMO ... didn't we fix that already?
eg
The HELLO.Details.authmethods|list is used by the client to announce the authentication methods it is prepared to perform.
yes! but it's only here https://wamp-proto.org/wamp_latest_ietf.html#name-example-message-flow
If the router is unwilling or unable to perform WAMP-Cryptosign authentication, it'll either skip forward trying other authentication methods (if the client announced any) or send an ABORT message.
yes! but it's only here https://wamp-proto.org/wamp_latest_ietf.html#section-13.4.1.2-9
in essence, the client announces an ordered list of auth methods it is ready to do (prioritized in list order), and the router chooses one of these - one it supports and prioritizes, and SHOULD use the first from client announced list order
crossbar will chose the first authmethod in the client announced list it supports:
https://github.com/crossbario/crossbar/blob/427cf58e42014499a623d4c17e06c6e3440273f9/crossbar/router/session.py#L914
If the spec can accept the continuous addition and deletion of authmethod, I don't care about anything else. Will we really do this?
the discussion seems to go in that direction .. lets see where we end up;)
fwiw, I like what @ecorm suggests, not coming up with arbitrarily named authmethods, but with some structure like roughly wamp-scram-argon2id-13-sha256
however, I would look we can come up with 1 separator char that splits a string properly along "parameters/flavors" of a given auth method class
pending_auth_methods = [
'anonymous',
'anonymous-proxy',
'ticket',
'wampcra',
'tls',
'cryptosign',
'cryptosign-proxy',
'scram',
'scram-argon2id13',
'scram-argon2id13-sha256',
'scram-argon2id13-cm3',
]
the
-proxything is a crossbar specific thing ... mmh;)
here is another argument pro using different auth methods to expose different flavors in an auth scheme:
as a client or router impl, if I want to support scram-argon2id13-cm3, I likely need to add a new dependency with potentially associated hassles and attack surface. this is an important decision to make. if I don't want to take that chance, it's easy and straightforward to do
eg in crossbar (when stuff isn't installed), the respective auth method simply won't be accepted:
https://github.com/crossbario/crossbar/blob/427cf58e42014499a623d4c17e06c6e3440273f9/crossbar/router/auth/init.py#L64
I agree with you, but for now, maybe we should focus more on completing the full spec.
The problem is that the spec will never be complete while its scope is too ambitious. :cry:
I agree with you, but for now, maybe we should focus more on completing the full spec.
The problem is that the spec will never be complete while its scope is too ambitious. cry
I can see your point:/
I'd say: the basic profile is "done". the advanced profile is still evolving and expanding. but maybe we should split it up further into separate parts.
however, I think it would be best to discuss that with the WG chair in IETF that we need to start to work with at some point in time ... I mean, approach them and start a real WG ... otherwise there won't be a spec - in RFC sense - also;)
rgd starting a "real" IETF WG: we need a host/chair, but https://datatracker.ietf.org/person/Salvatore%20Loreto https://www.linkedin.com/in/salvatoreloreto/ some time ago told me he'd probably be willing to help!
rgd starting a "real" IETF WG: we need a host/chair, but https://datatracker.ietf.org/person/Salvatore%20Loreto https://www.linkedin.com/in/salvatoreloreto/ some time ago told me he'd probably be willing to help!
Oh that's cool!
I'm +1 on structured wamp authentication scheme names. So someday we can remove old ones (i hope)... And what is good — as @oberstet mentioned — we already have most of the parts prepared for that. So restructuring auth methods names and modifying a bit auth chapter won't be hard. And as we still preserve the current methods — all implementations should work.
Oh that's cool!
alright, I'll reach out to Salvatore, hope he remembers me;)
Salvatore was the WG chair of the HyBI group that designed WebSocket, looong ago ... spent many hours on the WG, and on creating the WebSocket fuzzing testsuite ... anyways
I'd say: the basic profile is "done". the advanced profile is still evolving and expanding. but maybe we should split it up further into separate parts.
As an example of how a "core" RFC can be extended, check out the CBOR registry for tags: https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml
Things that can be registered as WAMP extension points include:
- Authentication method strings (as we've been discussing here)
- Serialization format numbers (e.g. JSON, Msgpack, CBOR, etc)
- Transports (Websocket, raw sockets, etc)
- Message options not included in the basic profile
- Feature announcement labels
- Error URIs
Note that in CBOR, multiple tags can point to the same document. So there could be a separate RFC for an Advanced WAMP RPC document that groups all the existing, well-defined, advanced RPC features together.
A registry for WAMP extension points could be maintained in this repo for now.