Draft: draft-ietf-gnap-core-protocol

Commentary: Deploy Preview for gnap - core - protocol - editors - draft ready ! Explore the source changes : Inspect the deploy log : Browse the preview : 
 Please take a look a BCP 107 ( a.k.a . RFC 4107 ) . You may need a reference here . 
 Please take a look a BCP 107 ( a.k.a . RFC 4107 ) . You may need a reference here . Originally posted by in 
 Ok but should this text be updated ? In 2005 , potential quantum threats were not even anticipated ( with impacts on key size for instance ) 
 I think the overall message remains accurate , but you are right that quantum computing was not a concern when RFC 4107 was written . Any updates to RFC 4107 are not part of your task in the GNAP WG . 
 Sure , thanks for the feedback . 
 I do n'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 ? 
 I take the opposite view about their inclusion -- it does n't make sense to disallow them because there 's no 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 does n'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 should n't disallow those schemes . Right now we do n't even mention those , but that 's more for the security considerations as it does n'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 ? 
 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 . 
 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 as well , which further proves my point that they are a footgun . 
 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 does n'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 . 
 answered by 
 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 . 
 I do n'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 ? 
 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 . 
 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 do n't support asymmetric keys ) . But I get your point . 
 Summarizing some offline discussion , we might relax the sentence related to PQ threats and symmetric keys , and enhance the security considerations ( symmetric keys are n't intended as human memorable password or a value derived from one ) .
Paragraph (version B):
The security of GNAP relies on the cryptographic security of the keys
themselves.  When symmetric keys are used in GNAP, a key management
system or secure key derivation mechanism MUST be used to supply the
keys.  Symmetric keys MUST NOT be a human memorable password or a
value derived from one.  Symmetric keys MUST NOT be passed by value
from the client instance to the AS.
Paragraph (version A):
Both the AS and client software can use systems such as hardware
security modules to strengthen their key security storage and
generation for both asymmetric and symmetric keys.
Paragraph (version B):
Both the AS and client software can use systems such as hardware
security modules to strengthen their key security storage and
generation for both asymmetric and symmetric keys (see also key-
protection).