Re: [Ace] AD review of draft-ietf-ace-coap-est-12

[Benjamin Kaduk <[e-mail]>]

I'll try to respond to Peter and Jim in one go.

On Fri, Aug 30, 2019 at 01:12:46PM +0200, Peter van der Stok wrote:
> HI Jim and Ben,
> 
> Ben, many thanks for a nice and elaborate  review of the draft.
> 
> beginning next week I will provide partial answers to the review.
> Some small remarks below to the much appreciated explanations by Jim.
> 
> An initial answer to the first point precedes the answers by Jim.
> 
> cheerio,
> 
> Peter
> _____________________________________________________________
> 
> Section 2
> 
>    This document also profiles the use of EST to only support
>    certificate-based client authentication.  HTTP Basic or Digest
>    authentication (as described in Section 3.2.3 of [RFC7030]) are not
>    supported.
> 
> Is the intent just to exclude HTTP-layer authentication, or to
> specifically prefer client certificate authentication?  7030 does allow
> for non-certificate TLS-layer authentication (e.g., TLS-SRP), which
> would be compatible with DTLS just fine.  There's also recurrent talk of
> getting modern PAKE(s) integrated with TLS, which might also be an
> option in the constrained space.
> [There are subsequent parts of the document that continue to assume
> only-certificates, so I'm mostly assuming that the intent is
> specifically to prefer client certificates, and have not made specific
> notes at those other places in the document.]
> 
> <pvds>
> client certificate authentication is preferred based on the following
> history:
> est_coaps was initially written as extension to anima BRSKI for small
> devices.
> In that context the only reasonable use case is client certificate
> authentication.
> In a later stage a wider audience of the document was identified beyond
> BRSKI also with a certificate authentication use case.
> The draft is limited to the certificate authentication, other
> authentications are not considered.
> I am not sure if this falls under preference of certificate
> authentication or exclusion of http layer authentication.
> If http layer authentication is wanted, my suggestion is that another
> document specifies this. This draft does not forbid the use of http
> layer authentication.
> Did I interpret your remark as you intended?
> </pvds>

Thanks for the extra background; it seems that there's reasonable
justification for the preference for certificate authentication; if a
TLS-layer password-based use case does arise, it should be possible to
write a companion document.

> Jim Schaad schreef op 2019-08-30 01:15:
> 
> > A couple of answers from my own perspective
> > 
> > -----Original Message-----
> > From: Ace <[e-mail]> On Behalf Of Benjamin Kaduk
> > Sent: Wednesday, August 28, 2019 4:37 PM
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: [Ace] AD review of draft-ietf-ace-coap-est-12
> > 
> > Hi all,
> > 
> > A good number of comments here, though many are just nits.  We may need some
> > more in-depth discussion about only using certificates for client
> > authentication (immediately below) and how we discuss server-keygen.
> > 
> > Thanks,
> > 
> > Ben
> > 
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> > 
> > When proof-of-possession is desired, a set of actions are required
> > regarding the use of tls-unique, described in Section 3.5 in
> > [RFC7030].  The tls-unique information consists of the contents of
> > 
> > I see the note in the shepherd writeup about converting EST to use TLS
> > exporters rather than tls-unique in a separate update document.  Where is
> > that work happening?  The discussion in Section 10.1 is helpful (and we
> > could do well to reference it from here) but does not inspire great
> > confidence in the reader that such work will come to fruition.
> > I think we also need to at least mandate extended-master-secret to be used
> > on the underlying DTLS connection.  (That is, assuming that we don't want to
> > lock down to specific, non-vulnerable, ciphersuites -- RFC 7925 only has
> > TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as MTI, not MTU.)
> > 
> > [JLS]  If this work is going to happen it needs to be done as an update to
> > the EST RFC.  I don't know if it would be better to do that in LAMPS rather
> > than here.  Currently I do not know of anybody who is going to do this.
> > This is my issue and I am willing to let it slide for the time being.
> > 
> > <pvds> I am happy with an update to LAMPS </pvds>

I don't think we'd want to do it in ACE, so LAMPS is a likely home (note
that I haven't checked with Roman).

> > In the context of CoAP, the presence and location of (path to) the
> > EST resources are discovered by sending a GET request to "/.well-
> > known/core" including a resource type (RT) parameter with the value
> > "ace.est*" [RFC6690].  The example below shows the discovery over
> > 
> > Is that a literal asterisk, for ace dot est star?
> > (1) Why?
> > (2) It probably merits a mention in the text to confirm it for the reader.
> > 
> > [JLS] This is standard CoAP searching with the "rt" parameter.  The start is
> > a) literal and b) means a wild chard with the expected meaning.  I don't
> > think that this needs any additional text.
> > <pvds> agree; new text will look much like repetition of text in other documents </pvds>

Okay, that's good to know.  I should probably read up on it a bit more...

> > It's a little unfortunate that we can only indicate ct=62 for the last two,
> > and there's no way to indicate what content types we expect within that
> > container.
> > 
> > [JLS] This was a big topic of discussion both in ace and more importantly in
> > core for the multipart content type.  If this is solved it should be solved
> > in CoRE and not here.  (I recognize from the text that you don't expect it
> > to be solved in this document.)
> > <pvds> finding the other ct's means parsing the CBOR content</pvds>

Agreed on all counts.

> > I can (grudgingly) accept that people are going to do server-side key
> > generation, so I do not propose to remove it from the document.  The policy
> > case is a clear example of why the feature needs to be available, but I'm
> > not 100% sure that I believe that server-keygen could be "more secure" given
> > that the client needs to be able to produce secure random numbers for DTLS
> > (though I do accept that some people will believe it to be so!).  It seems
> > likely to only be possible in some intermediate situation where the
> > client-generated random numbers could be attacked but at substantial
> > expense, such that paying that expense for a single handshake is "too much"
> > for the attacker to bear, but doing it for the key generation that would
> > give the attacker all transactions would make the expense worthwhile; this
> > intermediate situation seems to also be transitory, since attacks only get
> > better/cheaper.
> > For the other case, if we were doing RSA keygen, then going from random
> > numbers to prime generation could be enough incremental expense that
> > offloading to the server would make sense, but I didn't think the elliptic
> > curve stuff had the same kind of issues, so I'd like to hear more about the
> > resource-consumption aspect as well.
> > 
> > [JLS] I would disagree that there is any requirement for a client using
> > DTLS to have any type of secure random numbers to still get a secure
> > channel.  If you do PSK authentication, then it is not required.  The
> > "random numbers" in the protocol are not really random, this is really true
> > because they are public numbers, you would like them to be non-predictable
> > but I do not know that this is even a requirement.  The only question is how
> > much you want to avoid some type of static-ephemeral key agreement state
> > which looses the PFS but is still potentially not horrid to have.
> > <pvds> I would prefer my co-authors to react to this aspect </pvds>

(To be clear, I'm asking for a bit of email discussion here, and not
necessarily any changes to the text.  Hearing Jim's thoughts is helpful,
but should not preclude others from chiming in as well.)

> > with other requests in the same DTLS connection SHOULD revalidate the
> > server certificate chain against the updated Explicit TA from the
> > /crts response before proceeding with the subsequent requests.  If
> > the server certificate chain does not authenticate against the
> > database, the client SHOULD close the connection without completing
> > the rest of the requests.  The updated Explicit TA MUST continue to
> > be used in new DTLS connections.
> > 
> > I'm not going to say you shouldn't do this check, but it seems pretty easy
> > for an attacker that knows it's servicing a /crts request to supply a
> > response that includes a (potentially bogus) trust anchor that can certify
> > the certificate it used for the current connection.  So it's not clear how
> > much protection this really provides.
> > 
> > [JLS] Right, of course the attacker that is going to do this needs to have
> > gotten a trusted channel set up initially to provide that (potentially
> > bogus) trust anchor over.  If you can do that then there is no longer any
> > trust in the system at all.
> > 
> > As described in CMC, Section 6.7 of [RFC5272], "For keys that can be
> > used as signature keys, signing the certification request with the
> > private key serves as a POP on that key pair".  The inclusion of tls-
> > unique in the certificate request links the proof-of-possession to
> > the TLS proof-of-identity.  This implies but does not prove that only
> > the authenticated client currently has access to the private key.
> > 
> > Do we want to further clarify that this means the PoP is weaker than it
> > could be?  ("no" is a fine answer, as always.)
> > 
> > [JLS] My response would be no.  I have spent hours describing the issues
> > that arise here without it always being clear that I have succeeded.  Trying
> > to do this in text and get the corner cases well described is extremely
> > difficult.

Okay.  (And thank you for having spent the time trying!)

> > It also assumes the Registrar has a trust relationship with the
> > upstream EST server in order to act on behalf of the clients.  When a
> > client uses the Implicit TA database for certificate validation, she
> > SHOULD confirm if the server is acting as an RA by the presence of
> > the id-kp-cmcRA EKU [RFC6402] in the server certificate.
> > 
> > Why is this only a SHOULD?
> > 
> > [JLS] Because it could be done by a different method.

Ah, it is supposed to be a "SHOULD do it this way", not "SHOULD check"; I
may have misread it.  I don't have any alternative phrasings that aren't
more words, so it's unclear if we want to make a change.  ("When a client
uses the Implicit TA database for certificate validation, she needs to know
whether the server is acting as an RA; she SHOULD confirm this by checking
for the presence of the id-kp-cmcRA EKU [RFC6402] in the server
certificate" would be one such longer alternative.)

Thanks,

Ben