Re: [Rats] Android attestations: Re: draft-richardson-rats-usecases-00 comments

[Carl Wallace <[e-mail]>]

inline...

On Fri, Jul 5, 2019 at 4:35 PM Michael Richardson <[e-mail]>
wrote:

>
> Carl Wallace <[e-mail]> wrote:
>     > [CW] The problem that motivated the question is establishment of
> trust in a
>     > public key associated with a specific device (i.e., the device in my
> hand
>     > not any authentic XYZ device). The suggestion is to use an
> attestation
>     > encrypted for a given relying party to convey something the relying
> party
>     > can verify (i.e., a challenge password or TOTP value) along with the
> key
>     > attestation. This could establish trust more conveniently than more
> manual
>     > mechanisms like verifying hashes. An app could certainly perform this
>     > function given an attestation but there may be value in performing
> this
>     > step at a lower level, depending on whether the lower level
> validated the
>     > key at all (else just doing encryption in the app would be
> equivalent).
>
> Some other emails and slides went back and forth privately.
>
> Carl is looking at a self-service SCEP situation where a Time-base One-Time
> Password (TOTP) is used to validate an enrollment process.
>
> If he were using a strictly online mechanism like EST(RFC7030), then the
> TOPT
> could be used to authenticate the TLS connection (using some EAP method,
> for
> instance).
>
> But, my understanding is that this goal is a mechanism which can operate
> with
> some kind of store and forward situation such that an object-based security
> for the PKCS10 CSR.
>
> I'm not convinced this is in scope as a RATS use case.
> Please tell me otherwise.
>
> [CW] I hadn't seen encrypted claims discussed so worth a mention.


>     >> When you say challenge password, I think you mean some kind of nonce
>     >> a relying party might send to the device in order to maintain
> freshness.
>     >> That also seems like a solution to a problem, the nature of which
> I'm
>     >> unclear
>     >> about.
>
>     > [CW] In the solution that motivated the question two TOTP values are
> used
>     > to establish trust in a device key. The first used to present a
> fresh key
>     > to a portal, the second used to capture affirmation of a person that
> the
>     > hash check was performed and the device key is trusted. If the first
> OTP
>     > was encrypted with an attestation, the second is potentially
> unnecessary.
>
> So the trusted base of the system would be attesting that the hash check
> was
> displayed to the user?    Maybe I don't understand what is being checked
> by a
> human that could be skipped.
>
[CW] The OTP was capturing affirmation of a hash check. The idea here is
attaching it to the attestation in encrypted form could replace that.

>
>
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>