[Anima-bootstrap] on using TLS Authorization Extension (RFC5878) for ownership voucher transfer

[Michael Richardson <[e-mail]>]

I gave myself the homework:
ACTION ITEM for MCR: Can we use RFC5878 (SAML) to replace ownership / auth
                     token extension need?


RFC5878 defines the: Transport Layer Security (TLS) Authorization Extensions
Abstract
   This document specifies authorization extensions to the Transport
   Layer Security (TLS) Handshake Protocol.  Extensions are carried in
   the client and server hello messages to confirm that both parties
   support the desired authorization data types.  Then, if supported by
   both the client and the server, authorization information, such as
   attribute certificates (ACs) or Security Assertion Markup Language
   (SAML) assertions, is exchanged in the supplemental data handshake
   message.

As it says, in this document we methods to transfer PKIX ACs, and SAML
assertions are defined. In other documents:
   RFC 6042 Transport Layer Security (TLS) Authorization Using KeyNote
   RFC 7562 Transport Layer Security (TLS) Authorization Using Digital
            Transmission Content Protection (DTCP) Certificates
   RFC 6406 Session PEERing for Multimedia INTerconnect (SPEERMINT) Architecture
            (but, I can't figure out why it is referenced)

(as well as TLS1.3 and an IANA update document)

My opinion is that we don't want to go the direction of ASN.1 based ACs.
I looked over SAML again, and I think that more XML is also not something
we want.
   If you looking for SAML docs:
   https://www.oasis-open.org/committees/download.php/35711/sstc-saml-core-errata-2.0-wd-06-diff.pdf


Keynote can do what we want, but it will require a unique parser for this
RFC822-like format.  That may well be reuseable code on some platforms
though. (Given SIP, HTTP, etc. also use that format).  It is already defined,
and I think has some deployment (still checking though)

JSON Web Tokens do very much what we want.  Writing a draft to say how to put
them into a TLS Authorization Extension would be pretty short, 6042 is very
short and simple.  The IANA registry is "Specification Required", and JWT
is quite active, so I think it would be quick.
(I have BCC'ed Mike Jones, but I don't think he needs replies too)

In addition, we would need to define a claim for JWT to say "ownership", it
would look something like:

{ "iss": "http://manufacturer.example.com/",
  "sub": "http://network.operator.example.net/",  <- really HASH
  "aud": "device:12345678",      <- device specific
   "owned_by":true               <- something we'd have to register.
}

which then gets base64 encoded and signed according to the JSON Web Signature.
It could alternatively be encrypted for privacy.

======= HOWEVER.

RFC5878's Security Consideration section notes two issues with this
extension, which is that the ownership voucher would be passed in the clear.
For signed objects which mention the network which will own the device, this
is a privacy problem only.  For bearer tokens, this is a big problem as it
would disclose the bearer token to third parties.

5878 suggests doing an initial TLS handshake, relying upon the privacy
provide, and then rekeying with the extensions.  If both ends needed
authorization extensions to function, then the first TLS handshake would be
trivially man-in-the-middle attacked.  Fortunately in our case,  regardless
of whether which direction initiates, the pledge can be authenticated to
the registrar using the Manufacturer Installed Certificate.   Here is a state
diagram from 5878, annotated a bit.
0 - no confidentiality.
1 - confidentiality+authentication by pledge certificate only.
2 - full authentication.

I added in the middle, essentially, we have the exact same provisional state
that we had before!!! Except that it's a potentially buried in the TLS state
machine, rather than in the application state machine, and again, this only
matters if we want to support bearar tokens.

I think that bearer tokens are useful.
They would be things obtained from a QR code on the side of package for
instance.   Putting an ownership token is not the only way to use that,
it could also just be PSK.

I've looked through TLS1.3, and while the extension would be encrypted
in 1.3, it would be sent by the peer prior to that peer verifying
the Finished message which authenticates that peer.    We could send
the extension afterwards, but then we still wind up with a "provisional"
state of some kind.  Again, possibly it will all be down in the TLS
state machine.



Client                                                   Server

    ClientHello (no extensions) -------->                            |0
                                        ServerHello (no extensions)  |0
                                                       Certificate*  |0
                                                 ServerKeyExchange*  |0
                                                CertificateRequest*  |0
                                <--------           ServerHelloDone  |0
    Certificate*                                                     |0
    ClientKeyExchange                                                |0
    CertificateVerify*                                               |0
    [ChangeCipherSpec]                                               |0
    Finished                    -------->                            |1
                                                 [ChangeCipherSpec]  |0
                                <--------                  Finished  |1

                  { THIS IS PROVISIONAL STATE!!!! }

    ClientHello (w/ extensions) -------->                            |1
                                        ServerHello (w/ extensions)  |1
                                  SupplementalData (w/ authz data)*  |1
                                                       Certificate*  |1
                                                 ServerKeyExchange*  |1
                                                CertificateRequest*  |1
                                <--------           ServerHelloDone  |1
    SupplementalData (w/ authz data)*                                |1
    Certificate*                                                     |1
    ClientKeyExchange                                                |1
    CertificateVerify*                                               |1
    [ChangeCipherSpec]                                               |1
    Finished                    -------->                            |2
                                                 [ChangeCipherSpec]  |1
                                <--------                  Finished  |2


Here is some thinking about flipped, with a MITM marked for TLS 1.2.


    PLEDGE                                                REGISTRAR
                                <--MITM-- ClientHello (w/ extensions)

    ServerHello (no extensions) ---MITM->
    Certificate (IDevID)
    ServerKeyExchange* (DH)
    CertificateRequest
    ServerHelloDone
                                <X-MITM--  SupplementalData (w/ authz data)*
                                               Certificate*
                                               ClientKeyExchange
                                               CertificateVerify*
                                               Finished

                                <---MITM   ClientHello
                                           ....


    Finished                    ---MITM->
                           <CRYPTO STARTS HERE>





--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-