Subject: [Teep] OTrP message for proposed optimization

From: Dave Thaler <[email-masked]>
Date: Mon, 22 Oct 2018 15:28:47 +0000

At IETF 102, in slide 4 of my presentation (https://datatracker.ietf.org/meeting/102/materials/slides-102-teep-teep-hackathon-report-03)
I proposed a new message from the OTrP client to the TAM, to optimize the flow.
It was not in response to any message from the TAM, but was instead the first message in the session.
Using the same style as appears in the OTrP draft for other messages, here's strawman details.
(I haven't checked it for errors, but you should get the idea.)

Dave

===
X.X.X.  TADependencyNotification Message

The message has the following structure.

  {
    "TADependencyTBSNotification": {
        "ver": "1.0",
        "signerreq": true | false,
        "edsi": "<Encrypted JSON DSI information>"
    }
  }

where

signerreq -   true if the TAM should send its signer certificate and
    OCSP data again in the subsequent messages.  The value may be
    "false" if the TEE caches the TAM's signer certificate and OCSP
    status.

edsi -   the main data element whose value is JSON encrypted message
    over the following Device State Information (DSI).

The Device State Information (DSI) message consists of the following.

   {
       "dsi": {
           "tfwdata": {
               "tbs": "<TFW to be signed data is the tid>"
               "cert": "<BASE64 encoded TFW certificate>",
               "sigalg": "Signing method",
               "sig": "<TFW signed data, BASE64 encoded>"
           },
           "tee": {
               "name": "<TEE name>",
               "ver": "<TEE version>",
               "cert": "<BASE64 encoded TEE cert>",
               "cacert": "<JSON array value of CA certificates up to
                           the root CA>",
               "sdlist": {          // optional
                   "cnt": "<Number of SD owned by this TAM>",
                   "sd": [
                       {
                           "name": "<SD name>",
                           "spid": "<SP owner ID of this SD>",
                           "talist": [
                             {
                                "taid": "<TA application identifier>",
                                "taname": "<TA application friendly
                                          name>" // optional
                             }
                           ]
                       }
                   ]
               },
               "teeaiklist": [
                   {
                       "spaik": "<SP AIK public key, BASE64 encoded>",
                       "spaiktype": "<RSA | ECC>",
                       "spid": "<sp id>"
                   }
               ],
               "talist": [                  // THIS IS THE NEW FIELD
                 {
                    "taid": "<TA application identifier>",
                    "taname": "<TA application friendly
                              name>" // optional
                 }
               ]
           }
       }
   }

   The encrypted JSON message looks like the following.

   {
       "protected": "<BASE64URL encoding of encryption algorithm header
                      JSON data>",
       "recipients": [
           {
               "header": {
                   "alg": "RSA1_5"
               },
               "encrypted_key": "<encrypted value of CEK>"
           }
       ],
       "iv": "<BASE64URL encoded IV data>",
       "ciphertext": "<Encrypted data over the JSON object of dsi
                       (BASE64URL)>",
       "tag": "<JWE authentication tag (BASE64URL)>"
   }

   Assume we encrypt plaintext with AES 128 in CBC mode with HMAC SHA
   256 for integrity, the encryption algorithm header is:

      {"enc":"A128CBC-HS256"}

   The value of the property "protected" in the above JWE message will
   be

      eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0

   In other words, the above message looks like the following:

   {
       "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
        "recipients": [
           {
               "header": {
                   "alg": "RSA1_5"
               },
               "encrypted_key": "<encrypted value of CEK>"
           }
       ],
       "iv": "<BASE64URL encoded IV data>",
       "ciphertext": "<Encrypted data over the JSON object of dsi
                       (BASE64URL)>",
       "tag": "<JWE authentication tag (BASE64URL)>"
   }

   The full response message looks like the following:

   {
     "TADependencyTBSNotification": {
       "ver": "1.0",
       "signerreq": "true | false" ,
       "edsi": {
         "protected": "<BASE64URL encoding of encryption algorithm
                        header JSON data>",
         "recipients": [
           {
             "header": {
               "alg": "RSA1_5"
             },
             "encrypted_key": "<encrypted value of CEK>"
           }
         ],
         "iv": "<BASE64URL encoded IV data>",
         "ciphertext": "<Encrypted data over the JSON object of dsi
                         (BASE64URL)>",
         "tag": "<JWE authentication tag (BASE64URL)>"
       }
     }
   }

   The CEK will be encrypted by the TAM public key in the device.  The
   TEE signed message has the following structure.

   {
     "TADependencyNotification": {
       "payload": "<BASE64URL encoding of the JSON message
                    GetDeviceTEEStateTBSResponse>",
       "protected": "<BASE64URL encoding of signing algorithm>",
       "signature": "<BASE64URL encoding of the signature value>"
     }
   }

   The signing algorithm shall use SHA256 with respective key type, see
   Section 7.5.1.

   The final TADependencyNotification message consists of an
   array of TEE notifications.

   {
       "TADependencyNotifications": [ // JSON array
          {"TADependencyNotification": ...},
          ...
          {"TADependencyNotification": ...}
       ]
   }

X.X.X.  TAM Processing Requirements

   Upon receiving a TADependencyNotifications message at a TAM, the TAM
   MUST validate the following.

   o  Parse to get list of TADependencyNotification JSON objects

   o  Parse the JSON "payload" property and decrypt the JSON element
      "edsi".  The decrypted message contains the TEE signer
      certificate.

   o  Validate the TADependencyNotification JSON signature.  The signer
      certificate is extracted from the decrypted message in the last
      step.

   o  Extract TEE information and check it against its TEE acceptance
      policy.

   o  Extract the TFW signed element, and check the signer and data
      integration against its TFW policy.

   o  Check the TA list and prepare for a subsequent command
      such as "InstallTA" to install the indicated TA(s).