IETF Authentication and Authorization for Constrained Environments (ACE)
description
Transcript of IETF Authentication and Authorization for Constrained Environments (ACE)
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