Draft: draft-ietf-gnap-core-protocol

Commentary: Built To edit notification comments on pull requests , go to your . 
 The last paragraph of Sec .  is a bit off . From an IETF perspective , we should be using " transport layer " ( TCP , or OSI layer 4 ) instead of " socket layer " . More importantly , modern TLS uses session resumption heavily , meaning that the trust relationship does not end when the  connection ends . Granted that we often need to re - authenticate , but the explanation should be more precise . 
 If you can , please provide more precise text to help this section out . Thanks ! 
 I can not agree more on that . The specification may also suggest setting the Connection HTTP header to " close " when it is n't desirable to reuse the same connection . 
 I tried rewriting the text but then realized that the text is incorrect in a deeper way than I commented on . The current text is : The word " continuity " is misused here . MTLS does provide mutual authentication of the TLS session ( a TLS session consists of multiple connections ) . But it does n't provide continuity , in the sense that each TLS session is authenticated separately , and there is no session identifier bound to all requests . So we need to figure out if " continuity " is a requirement , if it is , address it , otherwise we should n't claim to have it but settle on mere mutual auth . 
 It seems the initial intent is indeed to go beyond mutual authentication , although the related " discontinuity " risks are not called out . For my understanding , by TLS continuity , do we mean a way to resume sessions ? Like session ID or session tickets or PSK ? Or something else ? In my view ( perhaps incorrect , because I 'm just a basic user of such systems , not a TLS / mTLS designer ) : a big part of the difference between TLS + PSK and mTLS seems related to key management . with PSK a secret key is shared between client and server , so we get back to the discussion on out of band key distribution with PKI , we only need one private key per entity , and possibly the setup is simplified by a trusted certificate chain 
 I would suggest to drop the " continuity " word , and instead , have a normative statement saying that both client and server ( server only when using MTLS ) MUST validate the other party 's identity ( RFC 6125 - bis , possibly with our own twist ) on each new L4 connection . 
 Yes , we 'll do that .
Paragraph (version A):
TLS functions at the socket layer, ensuring that only the parties on
either end of that socket connection can read the information passed
along that connection.  Each time a new socket connection is made,
such as for a new HTTP request, a new trust is re-established that is
unrelated to previous connections.  As such, it is not possible with
TLS alone to know that the same party is making a set of calls, and
therefore TLS alone cannot provide the continuity of security needed
for GNAP.  However, mutual TLS (MTLS) does provide such security
characteristics through the use of the TLS client certificate, and
thus MTLS is acceptable as a key-presentation mechanism when applied
as described in mtls.
Paragraph (version B):
TLS functions at the transport layer, ensuring that only the parties
on either end of that connection can read the information passed
along that connection.  Each time a new connection is made, such as
for a new HTTP request, a new trust is re-established that is mostly
unrelated to previous connections.  While modern TLS does make use of
session resumption, this still needs to be augmented with
authentication methods to determine the identity of parties on the
connections.  In other words, it is not possible with TLS alone to
know that the same party is making a set of calls over time, since
each time a new TLS connection is established, both the client and
the server (or the server only when using mtls) have to validate the
other party's identity.  Such a verification can be achieved via
methods described in I-D.ietf-uta-6125bis), but these are not enough
to establish the identity of the client instance in many cases.
Paragraph (version B):
To counter this, GNAP defines a set of key binding methods in
binding-keys that allow authentication and proof of possession by the
caller, which is usually the client instance.  These methods are
intended to be used in addition to TLS on all connections.