Re: [Teep] AD review of draft-ietf-teep-otrp-over-http-12

[Dave Thaler <[e-mail]>]

I've updated the transport document and will post -13 shortly.  See responses below with [DT].



-----Original Message-----
From: Benjamin Kaduk <[e-mail]>
Sent: Friday, January 7, 2022 12:04 PM
To: [e-mail]
Cc: [e-mail]
Subject: AD review of draft-ietf-teep-otrp-over-http-12



This is also in good shape, modulo §5.2, and will want a new I-D before IETF Last Call.



-Ben



It's possible that some of these topics might be more properly addressed in the architecture doc than here; I didn't put a huge amount of thought into that division, and trust that the author overlap will help make the right thing happen.



I put some editorial nits in https://github.com/ietf-teep/otrp-over-http/pull/34



[DT] PR merged.  Thanks!



Section 4



   When HTTPS is used, clients MUST use the procedures detailed in

   Section 6 of [RFC6125] to verify the authenticity of the server.  See



The RFC 6125 procedures rely on the consuming specification to provide a couple more inputs to the procedure.  In particular, the client needs to have a list of acceptable reference identifiers, and protocols using the RFC

6125 procedures usually will say that the client needs to match against a particular type of name (I would expect DNS-ID here), and how to obtain the specific name to use for a given interaction.  In this case, the DNS-ID would probably be obtained from the authority component of the TAM URI ...

which is basically the same procedure described in

https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-semantics#section-4.3.4.  So we might consider using that as the primary reference, mentioning that it incorporates the RFC 6125 procedures but not directly incorporating the RFC 6125 procedures ourselves.



[DT] Replaced reference to 6125 with reference you mentioned which is already in the RFC editors queue.  After reading the text, I didn’t see a need to specifically mention it incorporates the 6125 procedures since that is obvious by following the reference and there’s no text in our doc that would make one look for 6125 discussion elsewhere in the doc.



   [BCP195] for additional TLS recommendations and [RFC7925] for TLS

   recommendations related to IoT devices.



I note that both RFC 6125 and RFC 7525 (BCP 195) have active "bis" drafts in UTA.  If I remember correctly, some of the 6125bis changes are "big", but even so, we would likely want to pull in the updated versions if they are available by the time we are ready for publication, with the caveat that if we defer to httpbis-semantics, that would take precedence.  (Since we'll be waiting for draft-ietf-teep-protocol, it's a little hard to predict exactly when that will be.)



[DT] No change, since they’re only drafts.  But we can pull in later if they are available before draft-ietf-teep-protocol is done, as you mention.



Section 5.1.1



   If the TEEP Agent passes back a TAM URI with no message buffer, the

   TEEP/HTTP Client attempts to create session state, then sends an

   HTTP(S) POST to the TAM URI with an Accept header with the TEEP media

   type requested, and an empty body.  [...]



I'm having a bit of trouble around "with the TEEP media type requested", as it seems to imply that the TEEP Agent has requested a specific media type, and that media type request needs to be propagated through to the TAM.  But in the previous section we only talked about a TAM URI being passed back, not a TAM URI and some other (meta)data.  This makes me wonder if we're just saying "populate the Accept header field with the single media type application/teep+cbor", since that's the single defined media type for TEEP.

But elsewhere in the document we seem to be careful about providing flexibility about what media type is in use.



[DT] The wording around media types was a holdover from when draft-ietf-teep-protocol included multiple ones (JSON vs CBOR).  Now that it only has one, I have updated the text throughout the transport spec to just reference “the” media type defined by the protocol spec.





Section 5.2



This section overall seems kind of incohesive.  It's supposed to be about what to do when an application tells a broker that a previously installed TA is not needed anymore; an "uninstall request", as it were.  But then we go on to say:



   *  Optionally, any requirements that may affect the choice of TEE, if

      multiple are available to the TEEP Broker.



and



   When a TEEP Broker receives such a notification, it first identifies

   in an implementation-dependent way which TEE (if any) is appropriate

   based on the constraints expressed, as in Section 5.1.



that talk about picking a TEE in the same way we would for an installation, as if there is no advance knowledge that the TA is already installed in some specific TEE.  Now, it may not be feasible for the broker to track state on which TA is installed in which TEE at behest of which rich application, so we probably can't just say "use the TEE that had this TA installed due the request of this rich application", but we could frame the discussion to acknowledge that there *is* some single TEE that has the copy of the TA that we're trying to uninstall, and we're trying to use as reliable a procedure as possible to direct the uninstall-request to the right TEE.  So, instead of the above, we might refer to any requirements "that would have affected the choice of TEE to originally install the TA into" and having the broker identify "which TEE is believed to contain the TA in need of uninstallation".



[DT] Updated text as suggested.



   The TEEP/HTTP Client then informs the TEEP Agent in that TEE by

   invoking an appropriate "UnrequestTA" API that identifies the

   unneeded TA.  The TEEP/HTTP Client need not know whether the TEE

   actually has the TA installed.



We also jumped from the TEEP Broker to the TEEP/HTTP Client, here, whereas in §5.1 we had the Broker delegate the action to "the TEEP/HTTP Client for that TEE".  We should probably have a similar transition in this section.



[DT] Updated text as suggested.



   The TEEP Agent will either (a) pass no data back, (b) pass back a TAM

   URI to connect to, or (c) pass back a message buffer and TAM URI to

   send it to.  The TAM URI passed back may or may not be the same as

   the TAM URI, if any, provided by the TEEP/HTTP Client, depending on

   the TEEP Agent's configuration.  If they differ, the TEEP/HTTP Client

   MUST use the TAM URI passed back.



This looks like just a copy/paste of the text from §5.1 ... but we didn't mention the possibility of getting a TAM URI from the application installer in this section, so (b) feels out of place without such a previous lead-in.



[DT] Updated, added such a previous lead-in for consistency.



   Processing then continues as in Section 5.1.1.



I might consider (but might not end up actually) mentioning here that we still have to create session state even for the UnrequestTA action, since the session state relates to an ongoing/active TEEP Agent/TAM exchange, and is not persistent during normal TA operation.



[DT] Ok I considered and didn’t end up actually mentioning it 😊   My opinion is that the text is already clear enough and since you figured out the correct meaning and suggested you might not mention it either, I didn’t do so.



Section 5.3



   When a TEEP Agent passes a message buffer (and TAM URI) to a TEEP/

   HTTP Client, the TEEP/HTTP Client MUST do the following, using the

   TEEP/HTTP Client's session state associated with its API call to the

   TEEP Agent.



As written, this only covers case (c), but I'm inferring that we intend for it to also cover case (b).  In order to cover case (b) as well as case (c), we'd need to not require that a message buffer is passed back (or at least, clarify that this buffer might be empty), and could instead talk about the client having an outstanding HTTP request (which might entail pushing the construction of the request back into an earlier section in the "got a message buffer" case).



[DT] Updated section heading and text so that it is more clear that it does cover both (b) and (c).



   The TEEP/HTTP Client sends an HTTP POST request to the TAM URI with

   Accept and Content-Type headers with the TEEP media type in use, and

   a body containing the TEEP message buffer provided by the TEEP Agent.

   The HTTP request is then associated with the TEEP/HTTP Client's

   session state.



The Content-Type requirement is already in place for responses due to the text in §4.  It seems like we might incorporate the requirements on HTTP requests into that section (which, after all, is "Use of HTTP as a

Transport") and avoid repeating them here.



[DT] No change, since I think the repeating is helpful to implementers and
you only said “might” so sounded like you didn’t feel strongly.   Will reconsider
if others complain during IETF Last Call.



Section 5.6



   If any HTTP request results in an HTTP error response or a lower

   layer error (e.g., network unreachable), the TEEP/HTTP Client calls

   the TEEP Agent's "ProcessError" API, and then deletes its session

   state and informs its caller of a failure.



The lower-layer errors are often very unauthenticated (e.g., ICMP), and in some scenarios we see guidance to not act on such signals *immediately*, to give a competing successful response a chance to arrive.  But I'm okay classifying such behavior as "quality of implementation" and leaving this text unchanged.



[DT] Yes.  No change, which you said you’re okay with too.



Section 6



It seems like there needs to be some out-of-band agreement between TAM and TEEP/HTTP server as to what media type(s) are supported.  That is probably worth mentioning somewhere, though I'm not sure if this is quite the best place to do so.



[DT] As in my response earlier above, the TEEP protocol now only has 1, so updated text here accordingly.  No out-of-band agreement is needed now.



Section 6.1



   If the TAM does not receive the appropriate Content-Type header

   fields, the TAM SHOULD fail the request, returning a 415 Unsupported

   Media Type response.  Similarly, if an appropriate Accept header

   Media Type response.  Similarly, if an appropriate Accept header

   field is not present, the TAM SHOULD fail the request with an

   appropriate error response.  [...]



I just want to confirm that "SHOULD" is the right requirements level here.

I do see that §4.13 of BCP56bis only indicates a need to require *clients* to fail on the wrong Content-Type, and this section applies to the server, so we may not want/need to have a hard requirement.



[DT] It is the right requirements level.   BCP56bis doesn’t require it so it’s not a MUST, but the WG believes it is useful to prevent bugs and encourage interoperability so leaving it as SHOULD which passed WGLC.



   When an HTTP POST request is received with an empty body, the TEEP/

   HTTP Server invokes the TAM's "ProcessConnect" API.  The TAM will

   then pass back a (possibly empty) message buffer.



I'm a little confused at when the resulting message buffer would be empty, as the ProcessConnect API appears to exist in order to create a session so that TEEP Agent and TAM can communicate.  At this point we don't have any information at all about which TEEP Agent is initiating the session, and thus it seems premature to make a conclusion that this TAM has nothing further to say to that TEEP Agent.  Would the empty buffer only result in an error or execption case, e.g., if the TAM was shutting down?  (I recall that the empty buffer will be treated by the TEEP/HTTP Client as a signal to destroy session state and make not further requests to that TAM.)



[DT] It can never be empty in that case (draft-ietf-teep-protocol section 6 says the TEEP Agent will always send a QueryRequest message), so updated text to remove the “possibly empty” phrase.



Section 8



A few more topics that we might want to cover in these security

considerations:



Part of the design/requirements is a periodic check for policy changes (§5.5); the listed options here all seem to place the Broker or TEEP/HTTP client in the critical path for the policy-check workflow.  Since these are (to some extent) untrusted components, we could talk about the possibility for the periodic policy check to be missed, what risks that exposes the TEE/TAs to, and perhaps mention that there are countermeasures available to the TEEP Agent (with caveat that a "dead-man's switch" would give no service rather than vulnerable service and be subject to DoS attack).



Similarly, the Broker as an untrusted component is involved in the mechanics of installing new TAs.  It might be worth reiterating that the authority for what TAs are running in a given TEE is assigned amongst the TEEP Agent and the TAM, and while the Broker can in effect "make suggestions", it doesn't actually decide or enforce what runs where.  (Modulo the ever-present DoS risk, of course.)  In contrast to the previous point, the Broker does seem to have full control over which TEE a given installation request is directed at, and there might be some security considerations relating to how the broker picks amonst multiple TEEs to try to use.



The authorization model for the UnrequestTA operation is quite weak, with essentially any untrusted application in the rich execution environment being able to request the operation.  We might be able to do something vaguely like a "capability URL" where the "unique identifier of the TA" is hard to guess and acts as a bearer token, but I don't think the architecture allows anything better.  I don't have a great sense for what countermeasures are available to respond to a (successful) malicious UnrequestTA operation; the main thing that comes to mind is to have the application in the rich execution environment that still needs the TA to notice its absence and request it back, but there are probably others, possibly even within the TEEP Agent or TAM.



[DT] Agree these are good considerations, but going back to your comment at the top I think these are best addressed in the architecture document since they are really independent of what the transport protocol is and we may have others in the future (like where HTTPS is in the opposite direction, TAM-to-TEEP Agent).   So I’ve added them there, and a sentence here that points to the TEEP architecture security considerations section. See https://github.com/ietf-teep/architecture/pull/232 for the additions to the architecture document.



Dave