Re: [Cfrg] Including "internal APIs" in CFRG security analysis

[Hannes Tschofenig <[e-mail]>]

Reading Ran’s text I was thinking about APIs from Global Platform used to communicate between the normal world and the secure world on Cortex A class devices, the Platform Security Architecture (PSA) APIs introduced for M-class devices (for attestation, crypto and secure storage). Those would be applicable to the TEEP, RATS, and the SUIT work.

The information flow on modern devices tends to be somewhat complex given all layers of privilege isolation going on.

From: Blumenthal, Uri - 0553 - MITLL <[e-mail]>
Sent: Sonntag, 13. Oktober 2019 13:29
To: Hannes Tschofenig <[e-mail]>
Cc: Canetti, Ran <[e-mail]>; cfrg <[e-mail]>
Subject: Re: [Cfrg] Including "internal APIs" in CFRG security analysis

Back in the days of SNMPv3, faced with a similar problem, we introduced a concept of ASI (Abstract Service Interface) that defined what input and output each architecture component used, and what the expected/allowed reaction was.

IMHO, it served us well.
Regards,
Uri

Sent from my iPhone

On Oct 13, 2019, at 07:25, Hannes Tschofenig <[e-mail]<mailto:[e-mail]>> wrote:
Hi Ran,

I agree with you that it would be super useful to consider APIs that are internal to endpoints in security assessments.
Sometimes it may be useful to even standardize such endpoint internal APIs.

I do, however, wonder how many people in the IETF/IRTF have insight into endpoint internal implementation details (or want to be exposed to those details). Acquiring this knowledge requires a lot of time.
In practice, this will be a showstopper.

I believe statements like “An IETF standard is secure" is in general of little value because you still have to implement a spec, test the spec, configure the implementation, and then put it into a larger system. The IETF does not help with any of these tasks.

Ciao
Hannes

From: Cfrg <[e-mail]<mailto:[e-mail]>> On Behalf Of Canetti, Ran
Sent: Sonntag, 13. Oktober 2019 07:52
To: cfrg <[e-mail]<mailto:[e-mail]>>
Subject: [Cfrg] Including "internal APIs" in CFRG security analysis




BTW, a more general thought & suggestion, while at it:



One basic limitation of the IETF as a platform for standardizing security

of protocols is that the IETF traditionally shies away from standardizing

APIs that are “internal to endpoints”. However, it is hard to  meaningfully

discuss the security of protocols/ components without pinpointing  these very same

internal APIs: Need to define how other components provide inputs to the analyzed component, how

they obtain outputs from the analyzed component, and what other forms of

information exchange exist between the analyzed component and the rest of

the endpoint system (eg, shared databases). Without such determination, one cannot

meaningfully make a statement of the sort “An IETF standard is secure".

(Indeed, TLS1.* is a quintessential case where such specifications are

sorely missing from the standard.)





The CFRG is a good place to change (or, rather, complement) that - and

the current discussion on PAKE protocols is a good a place to start:

let's ask that PAKE standards (and proposals) specify how  they interact with the other relevant components within each

party, down to the API. This includes the APIs with TLS, with the secure session protocol,

with HTTPS, with the long-term signature module, with the password

store(s), etc etc…





Best, Ran
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.
_______________________________________________
Cfrg mailing list
[e-mail]<mailto:[e-mail]>
https://www.irtf.org/mailman/listinfo/cfrg
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.