Inline...
On Wed, Jan 23, 2019 at 3:07 PM Richard Barnes <r...@ipv.sx> wrote:
> Inline.
>
> On Sun, Jan 20, 2019 at 3:04 PM Rifaat Shekh-Yusef <rifaat.i...@gmail.com>
> wrote:
>
>> I looked at the TNAuthList draft, and as far as I understand, the
>> framework seems
>> a bit different from this proposal:
>>
>> 1. A Token Authority is authoritative for multiple identifier spaces
>> (e.g.
>> TNAuthList with telephone numbers and service providers), while a
>> Device
>> Authority is responsible for one identifier space, i.e. the devices
>> manufactured by a specific vendor.
>>
>
> Just because the framework can address the case where a single authority
> can speak for multiple identifier spaces doesn't mean it can't also address
> the single identifier space case.
>
> True, but it slightly complicates the solution for this use case (see more
below).
>
>
>> 2. A certificate issued to an entity controlled by a Token Authority is
>> specific
>> to that entity independent of any domain, while a certificate issued
>> to
>> a device controlled by a Device Authority is specific to the device
>> *and* the
>> Client domain (based on a Client account with ACME).
>>
>
> What do you mean by "domain" here?
>
>
By domain I am talking about a service that the device is expected to
consume.
For example, a SIP phone that is expected to connect to a SIP network to
get
configuration and SIP services.
What I am trying to achieve is that the certificate that would be issued to
the
device is not only an attestation to the device as an independent entity,
but a
valid device with permission to access a specific service.
>
>>
>> Also, I noticed that the TNAuthList proposal does support redirection, as
>> an
>> optional feature. In the Device Authority case this is not critical and
>> could be
>> left as optional too, which will simplify the flow even further, as it
>> would
>> allow us to drop Steps 3 & 4 from the flow described in section 2.4,
>> which would
>> look as follows without the redirection:
>>
>> Client Device Authority
>> ACME CA
>> (customer.com) (as.vendor.com) (
>> acme.com)
>> | |
>> |
>> | [01] POST /new-order [kid=customer.com, url=vendor.com,
>> identifier={mac}|
>>
>> |------------------------------------------------------------------------>|
>> | |
>> |
>> | [02] 201
>> |
>> | [authorizations=vendor.com/acme/authz/1234,
>> |
>> | finalize=
>> customer.com/acme/order/asdf/finalize] |
>>
>> |<------------------------------------------------------------------------|
>> | |
>> |
>> | [03] Use OAuth to obtain a device JWT
>> |
>> |<==================================>|
>> |
>> | |
>> |
>> | [04] POST /vendor.com/acme/authz/1234 [JWT]
>> |
>>
>> |------------------------------------------------------------------------>|
>> | |
>> |
>> | | [05] 200
>> [status=valid] |
>>
>> |<------------------------------------------------------------------------|
>> | |
>> |
>> | [06] POST /customer.com/acme/order/asdf/finalize [CSR]
>> |
>>
>> |------------------------------------------------------------------------>|
>> | |
>> |
>> | [07] 200 [certificate=customer.com/acme/cert/asdf]
>> |
>>
>> |<------------------------------------------------------------------------|
>> | |
>> |
>> | [8] GET /customer.com/acme/cert/asdf
>> |
>>
>> |------------------------------------------------------------------------>|
>> | |
>> |
>> | | [8] 200
>> [certificate] |
>>
>> |<------------------------------------------------------------------------|
>> | |
>> |
>>
>>
>> Unless I missed something, because of the above and to keep this
>> mechanism as
>> simple as possible, I would like to keep this proposal independent of the
>> Token
>> Authority framework at this stage.
>>
>
> I'm confused. Issuing with authority tokens entails exactly the flow
> you've laid out. It's just that the interaction between the client and the
> token authority is undefined in that doc, so you can fill it in with your
> step 03.
>
>
There are few differences between the Device Authority (DA) and the Token
Authority (TA) flows.
Let's discuss the flow without redirection. Here is what I think is the TA
flow:
Client Token Authority ACME
CA
(customer.com) (ta.example.com) (
acme.com)
| |
|
| [01] POST /new-order [kid=customer.com, url=customer.com,
identifier={mac}]
|------------------------------------------------------------------------>|
| [02] 201
|
| [authorizations=customer.com/acme/authz/1234,
|
| finalize=customer.com/acme/order/asdf/finalize]
|
|<------------------------------------------------------------------------|
| |
|
| [03] POST /customer.com/acme/authz/1234
|
|------------------------------------------------------------------------>|
| [04] 200 OK [url=customer.com/acme/authz/1234/0]
|
|<------------------------------------------------------------------------|
| |
|
| [05] Obtain a JWT |
|
|<==================================>|
|
| |
|
| [06] POST /customer.com/acme/authz/1234/0 [JWT]
|
|------------------------------------------------------------------------>|
| | [07] 200 [status=valid]
|
|<------------------------------------------------------------------------|
| |
|
| [08] POST /customer.com/acme/order/asdf/finalize [CSR]
|
|------------------------------------------------------------------------>|
| [09] 200 [certificate=customer.com/acme/cert/asdf]
|
|<------------------------------------------------------------------------|
| |
|
| [10] GET /customer.com/acme/cert/asdf
|
|------------------------------------------------------------------------>|
| [11] 200 [certificate]
|
|<------------------------------------------------------------------------|
| |
|
With TA, the new_order request (step [01]) the kid and the url contain the
Client's domain.
With the DA, the kid contains the Client's domain while the url contains
the DA's domain.
This would allow the CA to discover the domain of the authority that will
issue the token,
and make a decision on whether it is supported or not at this stage.
With TA, the 201 response contains an authorizations and finalize urls with
the Client's domain,
while with DA the authorizations url contains the DA's domain.
With TA, the Client would need to send another request to obtain the
challenges, steps
[03] & [4], to obtain details about the token to be used, and a second
authorizations resource.
With DA this is not needed and the Client should be able to send the JWT to
first authorizations url.
Having said all of that, I am not suggesting that this proposal cannot be
made to
work with the TA framework, but that the flow seems to become a bit more
complicated
for the use case I have in mind.
Regards,
Rifaat
> --Richard
>
>
>>
>> Thoughts?
>>
>> Regards,
>> Rifaat
>>
>>
>> On Thu, Jan 17, 2019 at 1:51 AM Richard Barnes <r...@ipv.sx> wrote:
>>
>>> It seems like the core of this draft is identifier delegation. Namely,
>>> the CA recognizes the DA as an authority for a certain identifier space
>>> (e.g., the first few octets of a MAC address), and the JWT delegates
>>> permission to issue certificates for some identifier in that space to the
>>> Client.
>>>
>>> Given that, it seems to me like this could fit under the rubric of the
>>> "authority token" challenge. If you were to do what this draft wants to do
>>> with that framework, the Client would have two separate interactions -- an
>>> OAuth interaction with the DA to get a token, then an ACME interaction with
>>> the CA to issue the certificate. The only specification needed would be to
>>> specify the identifier and token type, as has been done for TNAuthList [2].
>>>
>>> The only thing that would then be missing with regard to this draft is
>>> that the CA wouldn't provide the redirect to the DA. Whether that makes
>>> sense depends on the use case, but I suspect that in most cases it does
>>> not. The design in the draft presumes there's a single DA per identifier,
>>> and that the CA keeps a mapping table from possible identifiers to DAs.
>>> That seems unlikely for most identifier spaces and most CAs with reasonably
>>> broad coverage. So losing this property of the draft doesn't seem like a
>>> big issue.
>>>
>>> So net/net, I think this draft should be restructured along the lines of
>>> [2], to just define a token type and maybe an identifier type.
>>>
>>> --Richard
>>>
>>> [1] https://tools.ietf.org/html/draft-ietf-acme-authority-token
>>> [2]
>>> https://tools.ietf.org/wg/acme/draft-ietf-acme-authority-token-tnauthlist/
>>>
>>> On Wed, Jan 16, 2019 at 12:33 PM Rifaat Shekh-Yusef <
>>> rifaat.i...@gmail.com> wrote:
>>>
>>>> All,
>>>>
>>>> I have just submitted new updated version to address the issues raised
>>>> by Ilari and Ryan.
>>>> I would appreciate any more reviews and comments.
>>>>
>>>> Regards,
>>>> Rifaat
>>>>
>>>>
>>>> ---------- Forwarded message ---------
>>>> From: <internet-dra...@ietf.org>
>>>> Date: Wed, Jan 16, 2019 at 3:28 PM
>>>> Subject: New Version Notification for
>>>> draft-yusef-acme-3rd-party-device-attestation-01.txt
>>>> To: Rifaat Shekh-Yusef <rifaat.i...@gmail.com>
>>>>
>>>>
>>>>
>>>> A new version of I-D,
>>>> draft-yusef-acme-3rd-party-device-attestation-01.txt
>>>> has been successfully submitted by Rifaat Shekh-Yusef and posted to the
>>>> IETF repository.
>>>>
>>>> Name: draft-yusef-acme-3rd-party-device-attestation
>>>> Revision: 01
>>>> Title: Third-Party Device Attestation for ACME
>>>> Document date: 2019-01-16
>>>> Group: Individual Submission
>>>> Pages: 9
>>>> URL:
>>>> https://www.ietf.org/internet-drafts/draft-yusef-acme-3rd-party-device-attestation-01.txt
>>>> Status:
>>>> https://datatracker.ietf.org/doc/draft-yusef-acme-3rd-party-device-attestation/
>>>> Htmlized:
>>>> https://tools.ietf.org/html/draft-yusef-acme-3rd-party-device-attestation-01
>>>> Htmlized:
>>>> https://datatracker.ietf.org/doc/html/draft-yusef-acme-3rd-party-device-attestation
>>>> Diff:
>>>> https://www.ietf.org/rfcdiff?url2=draft-yusef-acme-3rd-party-device-attestation-01
>>>>
>>>> Abstract:
>>>> This document defines a Third-Party Device Attestation for ACME
>>>> mechanism to allow the ACME CA to delegate some of its authentication
>>>> and authorization functions to a separate trusted entity, to automate
>>>> the issuance of certificates to devices.
>>>>
>>>>
>>>>
>>>>
>>>> Please note that it may take a couple of minutes from the time of
>>>> submission
>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>
>>>> The IETF Secretariat
>>>>
>>>> _______________________________________________
>>>> Acme mailing list
>>>> Acme@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/acme
>>>>
>>>
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
