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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 15 September 2016 01:54 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima-bootstrap@ietfa.amsl.com
Delivered-To: anima-bootstrap@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C1CA712B122 for <anima-bootstrap@ietfa.amsl.com>; Wed, 14 Sep 2016 18:54:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.409
X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id XZ84ICGA2QgB for <anima-bootstrap@ietfa.amsl.com>; Wed, 14 Sep 2016 18:54:03 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DF4312B0E4 for <anima-bootstrap@ietf.org>; Wed, 14 Sep 2016 18:54:03 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D83902009E for <anima-bootstrap@ietf.org>; Wed, 14 Sep 2016 22:06:43 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 90A446392D for <anima-bootstrap@ietf.org>; Wed, 14 Sep 2016 21:54:02 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: anima-bootstrap <anima-bootstrap@ietf.org>
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Wed, 14 Sep 2016 21:54:02 -0400
Message-ID: <2018.1473904442@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/6QmN7oGCyqfnZll1_RyBQBKYVoY>
Subject: [Anima-bootstrap] on using TLS Authorization Extension (RFC5878) for ownership voucher transfer
X-BeenThere: anima-bootstrap@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <anima-bootstrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima-bootstrap/>
List-Post: <mailto:anima-bootstrap@ietf.org>
List-Help: <mailto:anima-bootstrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Sep 2016 01:54:06 -0000

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
   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

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:

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)
                                <X-MITM--  SupplementalData (w/ authz data)*

                                <---MITM   ClientHello

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

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

Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-