Re: [EAT] [Rats] Attestation BoF charter updates? - Program of Work section

[Laurence Lundblade <[e-mail]>]

The new charter looks pretty good to me. 

Some comments on claims formats.

The way I’ve been thinking of support for multiple formats (JSON, CBOR, ASN.1...) is that we do the main work of defining the claim semantics first. Those semantics are in common for all the syntaxes. JSON, CBOR, etc. are just syntaxes.

Agreed we should look at existing claim definitions and avoid re inventing. They should be from any source though, not just ASN.1. 

I want to bring up the issue of interoperability when there are multiple syntaxes (CBOR, JSON, ASN.1…) and securing schemes (COSE, JOSE, CMS…). I think the device should be able to pick one format and only implement that. I don’t think there should be format negotiation. The relying party thus must implement all variants for there to be full interoperability. 

It might be possible to have some intermediate service that translates the syntax of claims (e.g. from CBOR to ASN.1), but then that intermediary would have to re sign which means it would have to be fully trusted as part of the end-end security model.

So I am making some argument against ASN.1 and anything beyond JSON and CBOR.  The more formats there are the more work the relying parties will have to do and of course some won’t implement all the formats and then we’ll have less interop.

LL

BTW, the first EAT implementation I did used CMS because COSE wasn’t ready. I did a pretty small CMS implementation and then later a pretty small COSE Sign1 implementation. COSE Sign1 was easier and less code.



> On Oct 25, 2018, at 1:19 AM, Smith, Ned <[e-mail]> wrote:
> 
> [nms] The Program of Work section (2.) has the following statement:
> "Specify interoperable cross-platform claims which provide information about systems and entities in support of the required use-cases, and extending the set of claims defined in RFC7519 and RFC8392. The specification will describe the syntax for each claim in at least the following formats:
> 
> CBOR [RFC7049]
> JSON [RFC7159]
> using modeling languages, such as:
> 
> YANG [RFC6020]
> CDDL [I-D.ietf-cbor-cddl]
> while retaining interoperability with existing formats based on ASN.1, if possible and feasible."
> [nms] The intent is (should be?) that existing ASN.1 formatted claims should be semantically similar/same as their CBOR/JSON/YANG/CDDL counterparts. If the WG defines claims for which there isn't a pre-existing standardized ASN.1 representation. It should be within the scope of the WG to define the ASN.1 representation. Hence, the sentence "...while retaining interoperability with existing formats based on ASN.1, if possible and feasible." Might better be stated as:
> "...while retaining interoperability with existing formats based on ASN.1, where claim semantics are the same (very similar)."
> "Claims that are unique to the efforts of this working group may include definition of its ASN.1 representation."
> -Ned
> 
> On 10/24/18, 5:56 AM, "EAT on behalf of Henk Birkholz" <[e-mail] on behalf of [e-mail]> wrote:
> 
>    Hi all,
> 
>    based on Jeremy's proposal we did another big refactoring - also tried 
>    to address everybody's comments, inputs and concerns.
> 
>> https://github.com/ietf-rats/charter/blob/RC3/ietf-rats-charter.md
> 
>    Please note that this charter text is intended to be a first phase, 
>    which is the reason why, for example, there still is no mentioning about 
>    provisioning, profiles, or more details about out-of-band dependencies.
> 
>    As Michael highlighted, most types of content belong into drafts. That 
>    said - on one hand the charter is a kind of "contract" wrt to scope and 
>    output, on the other hand we do not want to boil the ocean (at least not 
>    all at once...).
> 
>    Viele Grüße,
> 
>    Henk
> 
>    On 10/24/2018 01:36 PM, Jeremy O'Donoghue wrote:
>> HI Eric,
>> 
>>> On 23 Oct 2018, at 19:04, Eric Voit (evoit) <[e-mail] 
>>> <mailto:[e-mail]>> wrote:
>>> 
>>> Hi Jeremy,
>>> Thanks for taking a cut at this charter simplification.  There are a 
>>> few areas covered within theGitHub Goals 
>>> <https://github.com/ietf-rats/charter/blob/RC2/ietf-rats-charter.md>which 
>>> I can’t easily map to your text below.  Could you talk about how these 
>>> elements are covered (or not)?   For context, I am working from the 
>>> perspective ofremote attestation application 
>>> <https://www.cisco.com/c/dam/en/us/td/docs/cloud-systems-management/application-policy-infrastructure-controller-enterprise-module/1-5-x/integrity_verification/user-guide/Cisco_Integrity_Verification_Application_APIC-EM_User_Guide_1_5_0_x.pdf>developer 
>>> trying to standardize the interfaces between a controller (which is 
>>> acting as a claim verifier) and a network element (which includes TCG 
>>> based subsystems.)
>>> For my application to work properly, there are several things needed 
>>> within a network controller to validate the asserted claims coming out 
>>> of a router.  These include:
>>> ·How do we expose the attestation evidence which can be used to 
>>> validate asserted claims?
>> 
>> I think that the need to address this is covered sufficiently for a WG 
>> Charter by the statement "Produce a specification defining procedures 
>> and corresponding architectures
> supporting verification of Claims".
>> 
>> If verification of Claims requires specific forms of attestation 
>> evidence (e.g. a set of measurements generated by a TPM), then it is 
>> properly a matter for an RFC to specify this, as Michael suggests.
>> 
>>> ·How do we know which root of trust which was used to generate the 
>>> attestation evidence (e.g., application event logs), and how does a 
>>> verifier differentiate this from the root-of-trust which asserts 
>>> claims made upon this evidence?
>> 
>> Again, I think this is a matter for specification rather than charter. 
>> There are a number of different ways in which Roots of Trust can be 
>> realised and many possible device architectures. The EAT draft allows 
>> one RoT to include an attestation generated by a different RoT, for 
>> example. I believe the RATS draft also provides technical mechanisms by 
>> which this can be achieved.
>> 
>>> ·What entities are allowed to read the info asserted claims?  What 
>>> subset of these can see the raw attestation evidence?
>>> These questions are significant because routers/switches are not 
>>> monolithic devices.  In fact, they are composed of subsystems with 
>>> different levels of trustworthiness. As the IETF often aims at 
>>> protocol specifications at the inter-device level, I am looking for 
>>> coverage of such questions in the charter.
>> 
>> I agree with you here as the same issue applies to claims with privacy 
>> implications. As an example, I may wish to present a unique device ID to 
>> a social media website but not my location.
>> 
>> I have added bullet point 3 to the draft - which I will post separately. 
>> Let me know if you think this addresses your concerns sufficiently.
>> 
>> Best regards
>> Jeremy
>> 
>>> Thanks,
>>> Eric
>>> *From:*Jeremy O'Donoghue, October 23, 2018 10:40 AM
>>> 
>>> On 22 Oct 2018, at 22:01, Michael Richardson <[e-mail] 
>>> <mailto:[e-mail]>> wrote:
>>> 
>>> 
>>>    Jeremy O'Donoghue <[e-mail]
>>>    <mailto:[e-mail]>> wrote:
>>> 
>>>        This is a very useful contribution, Laurence.
>>> 
>>> 
>>> 
>>>        The current draft text is too strongly biased towards
>>>        attestation based
>>>        on measurement, and does not adequately cover other mechanisms
>>>        which
>>>        are already
>>> 
>>> 
>>>    But, it's for the charter, for the WG, it's not a treatise on
>>>    attestation
>>>    itself.
>>> 
>>>    This is all supposed to be *meta* text about attestation, about
>>>    what we want
>>>    to say about attestation in the documents, not about what
>>>    attestation is.
>>> 
>>>    Please go read some other IETF charters:
>>> 
>>>    https://datatracker.ietf.org/wg/6lo/about/
>>>    https://datatracker.ietf.org/wg/6tisch/about/
>>>    https://datatracker.ietf.org/wg/suit/about/
>>> 
>>> Fair comment.
>>> We have two existing proposals - EAT and RATS - which address a 
>>> similar problem space but using different mechanisms. While I believe 
>>> the RATS and EAT contributors are in broad agreement that there is 
>>> significant benefit in bringing both work streams under a single 
>>> umbrella, trying to properly incorporate EAT through incremental 
>>> modification to the draft RATS WG charter text is proving challenging.
>>> The below probably diverges too far from the current text for some 
>>> tastes, but it may address your point and provide a basis for 
>>> discussion (at this point the GitHub draft 
>>> <https://github.com/ietf-rats/charter/blob/RC2/ietf-rats-charter.md> seems 
>>> a long way behind the list). It is deliberately significantly shorter 
>>> than the current draft - I have tried to re-use as much existing text 
>>> as possible, but it is heavily re-organised and abridged.
>>> I have taken on board the comment from Carsten that perhaps a minimum 
>>> level of terminology is acceptable in charter text, but deliberately 
>>> tried to keep the language simple and fairly generic to enable the 
>>> proper work of terminology definition to take place in the 
>>> requirements document as you suggest.
>>> 
>>> Introduction
>>> 
>>> ------------
>>> 
>>> Remote attestation procedures can be incorporated in network protocols to
>>> provide the basis for establishing claims about an entity in a trustworthy
>>> manner. Such claims may include, but are not limited to, device identity,
>>> manufacturing origin, system integrity, configuration, operational 
>>> state and
>>> measurements of steps which led to the operational state. Such procedures
>>> expose entity characteristics in the form of claim sets which allow remote
>>> parties to establish the trustworthiness of a device, provide evidence 
>>> that a
>>> particular set of operations and functions are supported and/or that the
>>> entity is actually what it claims to be.
>>> 
>>> In the absence of such procedures, while domain-specific attestation
>>> mechanisms such as TCG TPM, FIDO Alliance attestation and Android Keystore
>>> attestation exist, there is no common way for a remote party to tell 
>>> if data
>>> originates from a trustworthy device (e.g. a Trusted System designed to
>>> support a specific set of operations/functionalities) or not.
>>> 
>>> The following minimal terminology is defined for the purposes of 
>>> clarifying the
>>> Working Group charter text:
>>> 
>>> - attestation: a set of claims which can be verified as originating in an
>>>          entity.
>>> 
>>> - claim:  as defined in RFC7519.
>>> 
>>> - entity: a device or device sub-module that can generate a claim or 
>>> set of
>>>          claims which can be verified by a remote party.
>>> 
>>> - remote party: an actor remote from an entity that wishes to verify 
>>> whether
>>>          a claim or set of claims originated in a given entity.
>>> 
>>> Description of the Working Group
>>> 
>>> --------------------------------
>>> 
>>> The Working Group will define:
>>> 
>>> - Standardized and interoperable mechanisms to establish a sufficient 
>>> level
>>>  of confidence that data originates from a trustworthy entity designed to
>>>  support a specific set of operations/functionalities.
>>> - Standardized and interoperable mechanisms building on (1) to allow 
>>> remote
>>>  parties to know the provenance and characteristics of an entity that 
>>> may be
>>>  requesting services.
>>> 
>>> The Working Group will identify security goals which it expects a 
>>> trustworthy
>>> execution context to address, which will assume the presence of Roots of
>>> Trust (as defined by NIST [SP800-164]). The detailed specification of such
>>> contexts is out of scope.
>>> 
>>> The Working Group will maintain close relationships with bodies 
>>> undertaking
>>> complementary work streams in the area of remote attestation such as
>>> GlobalPlatform, Trusted Computing Group and FIDO Alliance.
>>> 
>>> The Working Group will cooperate with the TEEP Working Group, which may
>>> generate requirements for claims relevant to TEE.
>>> 
>>> Work Items
>>> 
>>> ----------
>>> 
>>> The Working Group will develop specifications supporting the creation of
>>> interoperable remote attestation procedures for entities which 
>>> incorporate
>>> Roots of Trust. The main deliverables are as follows.
>>> 
>>> - Produce a requirements document establishing a common vocabulary for 
>>> remote
>>>  attestation, identifying mechanisms which will be supported for 
>>> establishing
>>>  trust between an entity and a remote party, and enumerating sample 
>>> use-cases
>>>  for remote attestation.
>>> 
>>> - Produce specification text defining interoperable cross-platform 
>>> claims which
>>>  provide information about an entity in support of the required 
>>> use-cases, and
>>>  extending the set of claims defined in RFC7519 and RFC8392. The 
>>> specification
>>>  will describe the syntax for each claim in at least the following 
>>> formats:
>>>    - CBOR [RFC7049]
>>>    - JSON [RFC7159]
>>>    - YANG [RFC6020]
>>> 
>>> - Produce specification text defining procedures and corresponding 
>>> architectures
>>>  supporting verification of claims within an attestation based on 
>>> measured file
>>>  execution procedures and supporting:
>>>    - Explicit attestation wherein a set of claims is transported in 
>>> the attestation;
>>>    - Implicit attestation wherein a set of claims is implied by 
>>> possession of a secret.
>>> 
>>> - Produce specification text defining procedures and corresponding 
>>> architectures
>>>  supporting verification of claims encapsulated in:
>>> 
>>>    - CBOR Web Token structures [RFC8392]
>>>    - JSON Web Token structures [RFC7519]
>>> 
>>> - Perform privacy analysis of both claims and the cryptographic 
>>> procedures used to
>>>  establish trust. This information will be included as appropriate in the
>>>  deliverable specifications, and may imply extension of procedures 
>>> defined in
>>>  other specifications in support of privacy goals.
>>> 
>>> It seems to me that there are two ways to produce the main 
>>> specification deliverables. I have deliberately left the text above 
>>> slightly vague on this.
>>> 
>>>  * A claims specification common to RATS and EAT with separate RATS
>>>    and EAT procedure specifications.
>>>  * A claims specification also incorporating EAT procedures and a
>>>    separate RATS procedure specification. This would be my preferred
>>>    option.
>>> 
>>>      o I believe there are very few procedures needed for EAT other
>>>        than the possible need to support a nonce to ensure freshness
>>> 
>>> Jeremy
>>> 
>>> 
>>>    Notice how by about the second paragraph (6tisch takes a bit
>>>    longer), each
>>>    gets into what the WG will do?
>>> 
>>>    --
>>>    Michael Richardson <[e-mail]
>>>    <mailto:[e-mail]>>, Sandelman Software Works
>>>    -= IPv6 IoT consulting =-
>>>    _______________________________________________
>>>    EAT mailing list
>>>    [e-mail] <mailto:[e-mail]>
>>>    https://www.ietf.org/mailman/listinfo/eat
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> EAT mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/eat
>> 
> 
>    _______________________________________________
>    EAT mailing list
>    [e-mail]
>    https://www.ietf.org/mailman/listinfo/eat
> 
> 
> _______________________________________________
> EAT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/eat