Re: [Rats] Review of draft-ietf-rats-eat-01

["Smith, Ned" <[e-mail]>]

There were some BOF documents that related the architecture terminology to EAT terminology to show the non-lossy mapping can be made. At some point it will make sense to update all relevant drafts to use terminology consistently. 

On 7/22/19, 5:58 AM, "RATS on behalf of Thomas Fossati" <[e-mail] on behalf of [e-mail]> wrote:

    Hi Giri,
    
    Thanks for the taking care of our comments.
    
    > > At a certain point we should probably do a pass to harmonise the
    > > terminology between the architecture draft and EAT (section 1.3 in
    > > particular)
    >
    > OK.  Currently Sec. 1.3 defines 3 actors (entity/manufacturer/RP) and
    > architecture doc defines 4 (attester/claimant/verifier/RP).  In the
    > EAT doc the RP can be the verifier or rely on a verification service.
    > However, I am not convinced that entity = attester and claimant =
    > manufacturer.  This could be something for discussion in the F2F.
    
    Sure; I didn't want to imply a specific direction of alignment, only to
    flag this as early as possible to avoid related documents drifting
    apart.
    
    > > The need for profiling EAT to make it work in reality is pretty
    > > obvious
    >
    > Agreed.  A key attestation profile could be another example.
    
    Ack
    
    > > "The EAT is always signed by the attestation key material
    > > provisioned by the manufacturer." This seems to prevent nested_eat
    > > use cases (e.g., cloud workloads with container/VM entities) where
    > > the outer EAT is signed with an "ephemeral" attestation key
    > > associated with the instance that is itself attested by the inner
    > > EAT signed with the AKM.  I suggest removing the sentence.
    >
    > Filed https://github.com/ietf-rats-wg/eat/issues/19, but I am not sure
    > how ephemeral keys can provide the same level of assurance as
    > manufacturer-issued key material unless the environment in which the
    > key is generated can also be attested.  Rather than simply removing
    > the sentence, perhaps we can add something along the lines as:
    >
    >   "The EAT SHOULD be signed by the attestation key material
    >   provisioned by the manufacturer.  The EAT may be signed by
    >   dynamically-generated keys, but this key material itself may require
    >   its own attestation to achieve the same level of assurance as
    >   manufacturer-provided key material."
    
    LGTM (maybe the "SHOULD" could be lower-cased?)
    
    > > "No particular signing algorithm or signing scheme is required by
    > > this standard."
    > > Isn't this a basic interop concern?  Is a EAT verifier supposed to
    > > implement every possible signing/verification algorithm? If we want
    > > to keep the above as-is, I think the following: "It is expected that
    > > EAT profiles or other specs building on EAT, either in the IETF or
    > > outside, will *mandate* a set of applicable signing schemes."
    >
    > Agreed that interop is aided by limiting the set of singing
    > algorithms.  However, we have a COSE algm. registry
    > (https://www.iana.org/assignments/cose/cose.xhtml) that bounds the set
    > of algorithms that can be used for EAT.  It seems also that any
    > ensuing profiles would leverage the registry.  Some defined profiles
    > may mandate a subset of the registry, but some may allow any algm.’s
    > in the registry to be used.  "will mandate" seems to be too strong a
    > statement.
    
    Great, it may be worth making the dependency on COSE registry
    (specifically, the subset of algorithms that are Sign1-compatible)
    explicit?
    
    > > "All claims that are not understood by implementations MUST be
    > > ignored"
    > > While this is generally the right approach to support evolution, I'd
    > > avoid making this a requirement here and let EAT profiles decide for
    > > themselves instead.
    >
    > This can be softened to a SHOULD requirement.  Note that an issue has
    > been filed at https://github.com/ietf-rats-wg/eat/issues/18 to better
    > define verification procedures.
    
    Ack, thanks.
    
    > > "Note that intrinsically by the nature of a nonce no security is
    > > needed for its transport"
    >
    > > Not sure about the above: what about avoiding confusing the
    > > principals, and/or reordering of messages from one principal?  In
    > > fact, it seems it's exactly the opposite and that some security
    > > considerations would be in order.  That, or dropping the sentence
    > > altogether.
    >
    > I agree that the statement above needs clarification, but the above
    > statement is about transport security – it is not about all security
    > considerations associated with challenges.  An RP should not rely on
    > transport security alone for protection of the nonce.  It should be
    > tracking the nonce sent to the device, and verifying the response
    > accordingly.  One possibility is to remove the above statement, but
    > add a discussion on the uses of nonces in the Security Considerations
    > section (which is still a work-in-progress).
    
    SvGTM
    
    > > "No two products anywhere, even in completely different industries
    > > made by two different manufacturers in two different countries
    > > should have the same UEID"
    > > Not sure how this assertion is compatible with type RAND UEIDs which
    > > – unlike the other types – are constrained only by a local choice
    > > (e.g., a "good enough" random generator) and not by any governance
    > > regime.
    >
    > Agreed that the choice of rand gen and seed affects this.  I think it
    > should be taken up in a security considerations section.  Added an
    > issue - https://github.com/ietf-rats-wg/eat/issues/21.
    
    Just an editorial suggestion: if a claim raises specific security or
    privacy implications, it'd be good to reference that discussion from the
    subsection that contains the claim definition.
    
    > > Security level is a certification-like claim except it's not backed
    > > by a 3rd party certification entity.  And even though the proposed 4
    > > levels look somewhat reasonable, I wonder what the benefits of
    > > having this claim are?  ISTM that self-proclaiming sec levels adds
    > > nothing at best, whilst altering the security perception in the
    > > worst case.  That said, I'd not be against defining a generic
    > > "certification" container that can be specialised by the specific
    > > EAT profile according to an existing or future scheme, but that
    > > would be a pretty different thing from this.
    >
    > I look forward to discussing this topic at the F2F.  There is an issue
    > filed – see https://github.com/ietf-rats-wg/eat/issues/4.  However,
    > this issue is not about a generic certification container.
    
    I read the issue but I cannot understand what is it about.  It looks
    like this needs some TLC :-)
    
    > Can you provide a proposal?
    
    Sure, I’ll be back to you as soon as I find some time to jot it down.
    
    > > I'm pretty sure we want to have something like this, but I'm not
    > > sure the current definition is good enough.  Would this be better as
    > > a single value with 4 states?
    > > One problem with the current proposal is that "debug permanent
    > > disable" implies "debug disable" but they can be set independently
    > > and therefore inconsistently.
    >
    > Note that this claim set was created based on what the editors
    > understood about lifecycle based on our employer’s products (Qualcomm)
    > and on what we were able to survey from other manufacturers.  I don’t
    > think we will have a consistent view among vendors about how to best
    > express the device state lifecycle in claim information.  This is why
    > follow-on proposals such as the PSA profile are important.
    >
    > Nevertheless, the differences between different debug disable states
    > should be better highlighted in the text and how the claim values
    > should be set by the attester.  For instance, if the attester sets
    > debug full permanent disable, then it should not set the other debug
    > disable states.  This can be addressed within CDDL itself using the
    > choices option – see Sec. 2.2.2 of RFC 8610.  I have filed an issue -
    > https://github.com/ietf-rats-wg/eat/issues/22.
    
    SGTM, thanks.
    
    > > This needs some privacy considerations, in particular explaining the
    > > interaction with UEID (the combo location & stable identity
    > > correlator is pretty explosive.)  There is probably lots to be
    > > extracted from previous GEOPRIV work (see, e.g., RFC6280).
    >
    > There is an issue filed -
    > https://github.com/ietf-rats-wg/eat/issues/13.  However, I think if we
    > are going to address privacy in the context of attestation then we
    > should not just fixate on location but address all aspects of
    > attestation that could result in device fingerprinting/tracking.  As
    > an example - the Webauthn spec attempts to describe privacy
    > implications related to attestation in general -
    > https://www.w3.org/TR/webauthn/#sec-attestation-privacy.
    
    SGTM -- I didn’t want to exclude other privacy dimensions, just flag the
    one that looks obvious and (yet) undocumented.
    
    > Moreover, in some ways, location is unusual in that there already
    > exists a permissions framework by which the end user can manage
    > privacy (e.g.
    > seehttps://www.w3.org/TR/webauthn/#browser-permissions-framework-extensions
    > for a discussion on browser permissions impacts).  There may not be a
    > similar permissions framework for other claims in the attestation
    > token, which means that the ability for the end user to manage privacy
    > with respect to such claims may not be readily available.
    
    Yes, I guess IoT devices that lack a UI are perfect targets for extended
    privacy considerations on location (and possibly similar) claim(s).
    
    > > "Seconds since the token was created"
    > > I assume the "token creation" happens when the signature is
    > > applied?  If so, I don't understand how can this information be
    > > sealed in the token with a value different from 0.  If instead the
    > > age is "per-claim", then a single global value is clearly
    > > insufficient.  Alternatively, if it has "per-profile" semantics
    > > (e.g., "time since boot measurements taken"), then this again can't
    > > be global, as it'd have profile-specific semantics.
    >
    > This claim is meant to cover the time lapsed between when the claim
    > info was provided and when the token was created.  Would the following
    > text make it more clear:
    >
    >   "The "age" claim contains a value that represents the number of
    >   seconds that have elapsed between when the claim information (e.g.
    >   measurement, location) was obtained and when the token was created"
    
    Perfect, thanks.
    
    > > "It is either a full CWT or JWT including the COSE or JOSE signing."
    > > Maybe worth a hint to dispatch it to the right decoder to avoid
    > > trial & error and/or content-type snooping.
    >
    > If a verification procedures section is added, this seems to appropriate guidance to add.
    
    I guess what I was trying to suggest is to add an explicit
    nested_eat_mime_type field inside the claim, to ease the job of the
    decoder.
    
    Cheers!
    
    IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
    _______________________________________________
    RATS mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/rats