IETF Authentication and Authorization for Constrained Environments ACE

IETF Authentication and Authorization for Constrained Environments (ACE) Hannes Tschofenig

Two Io. T Deployment Extremes

Cloud-based Approach Data OAuth HTTP Smart Phone App Data OAuth HTTP OAuth API Web Site Data Store Authentication, Authorization Server Data Co. AP/HTTP/MQTT DTLS/TLS Io. T Devices

Local Network Approach LOCAL NETWORK

Prior Activities • Smart Object Workshop (March 2011) • Smart Object Security Workshop (March 2012) • Many relevant IETF working group activities this work builds on, including CORE, 6 lowpan/6 low, lwig, dice, etc. • Various interoperability events

Problem Statement Client Resource Server PUT “ 1” /lock GET /bloodpressure PUT “ 2. 5 mg” /sedative Resource server, client and network may be constrained. How to support explicit and dynamic authorization?

ACE Stack Authorization n Server sio i c De t en m rce nfo E Client Resource Server

ACE Charter • (Constrained Environments) • standardized solution for authentication and authorization • use Co. AP and leverage DTLS security where possible • employ additional less-constrained devices in order to relieve the constrained nodes • existing authentication and authorization protocols are used and re-applied. . . restricting the options within each of the specifications • operate across multiple domains • intermittent connectivity of resource server

Constrained Device? • • Flash Memory (e. g. , ~ 512 KB) RAM (e. g. , 32 KB) CPU power Cost Form factor Energy constraints No user interface/unattended

Gap Analysis Hannes Tschofenig

• The IETF has developed a number of security technologies that are applicable to the presented use cases. • Is there possibility for re-use? • Go through a few selected technologies to identify gaps.

Non-Goals • Design the solution in this room. Don’t get hung up on the details.

Tutorials • Tutorials available for Kerberos, OAuth, “PKI/Certificate Model”, AAA, ABFAB. • http: //www. tschofenig. priv. at/wp/? p=1012

ABFAB +--------+ | Authorization | | Server | | | +-^-----^--+ * EAP o RADIUS * o +-------+ +-v-----v--+ | | | Client | EAP/EAP Method | Resource | | |<********>| Server | | | GSS-API | |<-------->| | Application | | Data | |<========>| | +-------+ +--------+

Gaps • Real-time interaction between the AAA server and the resource server. • ABFAB architecture uses layering of EAP within the GSS-API, which adds additional overhead. • A binding for the transport of EAP payloads in Co. AP, for example, does not exist. • No unified authorization policy language has been defined for the AAA/EAP architecture. Instead, RADIUS attributes carry information about access control decisions.

Kerberos +--------+ | Authorization | | Server | +--------+ ^ / Request / / Ticket / /Ticket / /{SK}C-KDC / / / / v +-----------+ | | Ticket + Authenticator | Resource | | Client |-------------->| Server | | |<==============>| | +------+ Application Data +------+

Gaps • Each ticket is only usable for a single service (intentionally). • Kerberos uses ASN. 1 for encoding of the ticket and various messages. • No access control policy language has been standardized. – Standardization in KITTEN in progress. – Proprietary policies are, however, used in real-world deployments. • A Co. AP binding for the KRB_PRIV and the KRB_SAFE message exchanges not been defined. • Ticket and Authenticator rely on symmetric key only.

OAuth +-------+ |Authorization| |Server | +-------+ ^ / Request / / Access / / Token / /Access Token / / / / O / v /| +-----------+ | -----> | | Access Token | Resource | / <----- | Client |--------->| Server | Resource | |<========>| | Owner +------+ Application Data +------+

Gaps • Support for cross-realm interaction has not been standardized. • A binding for Co. AP does not exist for the client to authorization server nor for the client to resource server. • The OAuth architecture does not standardize the authentication procedure of the resource owner to the authorization server itself. • Profile is needed to navigate through the options (since OAuth provides a lot of flexibility). • Co. AP/DTLS bindings currently not defined.

“PKI/Certificate Model” +-------+ |Certification| | Authority | +-------+ ^ / Request / / Short / / Lived / /Short Lived Cert / / Certificate / / / / v +-----------+ | | DTLS with certificate | | or app layer msg w/cert |Resource | | Client |-------------->|Server | | |<==============>| | +------+ Application Data +------+

Gaps • The certificate format and the PKI management protocols use ASN. 1. • No UDP or Co. AP transport is defined for CMC/CMP/SCEP. For PKCS#10 no transport is defined at all. • Asymmetric cryptography is computationally more expensive than symmetric cryptography but offers additional security benefits.

Info • ACE Mailing List: https: //www. ietf. org/mailman/listinfo/ace • CORE (for Co. AP): https: //ietf. org/wg/core/ • DICE (for profile of DTLS): https: //ietf. org/wg/dice/ • 6 Lo: https: //ietf. org/wg/6 lo/ • ACE Charter: http: //datatracker. ietf. org/doc/charter-ietf-ace/ • Book: 6 Lo. WPAN: The Wireless Embedded Internet