Benjamin Kaduk <ka...@mit.edu> wrote:
    doc> The MASA and the registrars SHOULD be prepared to support TLS client
    doc> certificate authentication and/or HTTP Basic or Digest
    doc> authentication as described in [RFC7030] for EST clients.  This
    doc> connection MAY also have no client authentication at all (Section
    doc> 7.4)

    >> > I don't see discussion of skipping client authentication in Section
    >> 7.4.  > It would be great to have some, there!

    >> It's buried in point 2.

    > Oh, the "not verifying ownership" part?  I somehow was interpreting
    > that as "we still require client authentication, but don't have a fancy
    > database mapping owner to hardware, so any authenticated registrar can
    > get a voucher for any device".

There are multiple models on how to operate a MASA.
We think that which one is right depends a lot on the value of the device
(in the ACP space, $100K routers vs $100 CPE devices), and also at the degree
of sales channel integration.
There is value in authenticating the Registrar, even if one does not know
which device has been deployed.  In particular, this model supports the <4h
SLA on service repair that most vendors have, and which they support by
stocking spares in the local city, but not for a specific customer.

I see that I've answered the rest already.
The perils of all these CCs.

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

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Reply via email to