Transcript Dia 1 - Hannes Tschofenig

IETF Authentication and
Authorization for Constrained
Environments (ACE)
Hannes Tschofenig
Two IoT Deployment Extremes
Cloud-based Approach
Data
OAuth
HTTP
Smart
Phone App
Data
OAuth
HTTP
OAuth API
Web Site
Data Store
Authentication,
Authorization
Server
Data
CoAP/HTTP/MQTT
DTLS/TLS
IoT 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,
6lowpan/6low, lwig, dice, etc.
• Various interoperability events
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?
ACE Stack
Client
Authorization
Server
Resource
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