1 / 26

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 OAuth HTTP. Data Store. Data CoAP/HTTP/MQTT DTLS/TLS. Authentication, Authorization Server. Web Site. Data OAuth HTTP. OAuth API.

lan
Download Presentation

IETF Authentication and Authorization for Constrained Environments (ACE)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Two IoT Deployment Extremes

  3. Cloud-based Approach Data OAuth HTTP Data Store Data CoAP/HTTP/MQTT DTLS/TLS Authentication, Authorization Server Web Site Data OAuth HTTP OAuth API IoT Devices Smart Phone App

  4. Local Network Approach LOCAL NETWORK

  5. 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

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

  7. ACE Stack Authorization Server Decision Enforcement Resource Server Client

  8. 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

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

  10. Gap Analysis <draft-tschofenig-ace-overview> Hannes Tschofenig

  11. 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.

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

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

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

  15. 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.

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

  17. 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.

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

  19. 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.

  20. “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 +-----------+

  21. 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.

  22. 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

More Related