Why do we even support symmetric keys?

[yaronf]

I don't see any reason to support symmetric keys for Client identification etc. Removing them will remove a (small) point of complexity, at zero cost.

Moreover, whenever people use "shared keys" nowadays these are usually passwords (even if we say explicitly not to use passwords as keys) and those come with a bunch of security issues.

In other words, is anybody still using shared symmetric keys in a justified and secure way?

[jricher]

I take the opposite view about their inclusion -- it doesn't make sense to disallow them because there's no added complexity. Symmetric keys can be referenced just like public keys/keypairs, and if we are referring to keys by reference rather than value, then the security is comparable in many ways. The security problems with symmetric crypto tends not to be in the actual crypto but in the key management and distribution. GNAP firmly says that it doesn't have any part in symmetric key management: any key you present by value has to be a public key. You can also do secure key derivation that ends up with a symmetric algorithm in the end, so you take the registered key and some other part of the request to create the derived key to be used with the actual request, and we shouldn't disallow those schemes. Right now we don't even mention those, but that's more for the security considerations as it doesn't have a direct effect on the protocol itself.

Another argument for allowing symmetric cryptography is to look toward post-quantum signatures. I'm not an expert here but it's my understanding that many symmetric algorithms are more robust against quantum attacks.

I'd like to see this raised as part of a larger security review. Maybe this is an issue to bring to CRFG or a similar crowd?

[agropper]

I tend to worry about implementation barriers for novices like me. Unless there are major security benefits, I hope we consider if symmetric keys could be an easier way for developers to transition from OAuth or other authorization schemes into GNAP. This is the kind of stuff that I'm having trouble understanding as we move our project from UMA 2 and OIDC to GNAP, RAR, DIDs, and VCs.

[yaronf]

@agropper I'll try to say it without sounding obnoxius... This is exactly what I'm worried about. Developers who have a hard time using public/private key pairs (and I understand why it is difficult and totally agree we should document specific implementations and how these keys can be et up) are the same developers who'd easily end up using passwords instead of symmetric keys and NOT using sophisticated key management.

I understand Justin's position but given that he's talking about sophisticated large scale systems, it still makes sense to leave it for a future extension. BTW, symmetric keys have been the root cause of security issues in JOSE as well, which further proves my point that they are a footgun.

[fimbault]

Symmetric keys are only supported by reference, so I think it's quite explicit their management needs to be external to gnap. And anyways, as soon as you authorize the management of keys by reference (meaning: that doesn't necessarily have to be managed within GNAP itself), the case will happen. Having some wording calling for caution, as is done currently in the text, seems the best we can do.

[fimbault]

answered by #304

[yaronf]

The more I'm reading the new Security Considerations, the more I am convinced that we need to get rid of symmetric keys. They add complexity, and they basically prevent any meaningful security proofs (because any system role can pretend to be any other role). Again, this is best left to an extension.

BTW, even if we authorize management of keys by reference, we can still restrict the type of keys allowed by the protocol.

[fimbault]

I don't think that changes anything to security proofs of the GNAP protocol itself. Of course the assumption is that keys are well managed and that each party maintains the identity of its counterparts. So there's always the need to make the correspondance between the keys and the roles. Or am I missing something?

[yaronf]

As far as security proofs are concerned, if you have access to a secret key you might as well be the key's owner. So, the AS can impersonate the Client etc. Security proofs (usually) do not assume that people are playing by the rules.

[fimbault]

Well, sharing a secret between the client and the AS seems far stretched (but ok, if you read the spec very literally without refering to security considerations, maybe someone could come up with the idea). I was more thinking of a scenarii like a joint RS-AS service backed by some cloud KMS (usually they don't support asymmetric keys).

But I get your point.

[fimbault]

Summarizing some offline discussion, we might relax the sentence related to PQ threats and symmetric keys, and enhance the security considerations (symmetric keys aren't intended as human memorable password or a value derived from one).