IETF Authentication and Authorization for Constrained

Environments (ACE)Hannes Tschofenig

Two IoT Deployment Extremes

Cloud-based Approach

Data Store

IoT DevicesOA

uth

AP

I

Smart Phone App

Authentication, Authorization

Server

DataCoAP/HTTP/MQTTDTLS/TLS

Web Site

DataOAuthHTTP

DataOAuthHTTP

Local Network Approach

LOCAL NETWORKLOCAL 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, 6lowpan/6low, lwig, dice, etc.

• Various interoperability events

Problem Statement

PUT “1” /lock

GET /bloodpressure

Resource server, client and network may be constrained. How to support explicit and dynamic authorization?

PUT “2.5mg” /sedative

Client Resource Server

ACE StackDecision

Client

Enforcement

Resource Server

Authorization Server

ACE Charter

• (Constrained Environments) • standardized solution for authentication and

authorization • use CoAP 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., ~ 512KB)

• RAM (e.g., 32KB)

• CPU power

• Cost

• Form factor

• Energy constraints

• No user interface/unattended

Gap Analysis

<draft-tschofenig-ace-overview>

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 * 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 CoAP, 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 CoAP 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 CoAP 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).

• CoAP/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 CoAP 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 CoAP): https://ietf.org/wg/core/

• DICE (for profile of DTLS):https://ietf.org/wg/dice/

• 6Lo: https://ietf.org/wg/6lo/

• ACE Charter: http://datatracker.ietf.org/doc/charter-ietf-ace/

• Book: 6LoWPAN: The Wireless Embedded Internet