1. No category

ABFAB for Internet-of-Things
Rhys Smith, Janet
Sam Hartman & Margaret Wasserman,
Painless Security
Agenda
• ABFAB Overview
• ABFAB for IoT
• Q&A
ABFAB OVERVIEW
What is ABFAB?
• Federated Identity for AuthN/AuthZ for any
application/service
• Designed to take the best of breed of existing
technologies, giving:
– Security
– Flexibility / wide scope
– Ease of integration
– Scaling
Fundamentals of ABFAB
• ABFAB builds on AAA technologies
– EAP (RFC 3748): strong & extensible mutual
authentication
– RADIUS (RFC 2865) / RadSec (RFC 6614): federation
between domains
• To this, ABFAB adds
– SAML (OASIS standard), for rich authorisation
semantics
– Integration using operating system security APIs
• SSPI: Windows
• GSS-API (RFC 2078): Other operating systems
• SASL (RFC 4422): Windows and other operating systems
EAP
• Extensible Authentication Protocol
– Authentication Framework – Decouples actual
authn method from your protocol.
– Protocol negotiates particular authn method
– Many exist (54 values currently registered) e.g.
•
•
•
•
EAP-PSK – Pre-shared key
EAP-TLS – X509
EAP-SIM – SIM card authn (GSM uses this)
EAP-TTLS – X509 to create tunnel, then further authn
within tunnel (e.g. PAP / MSCHAP)
RADIUS / RadSec
• RADIUS - AAA protocol over UDP
• RadSec – RADIUS over TCP & TLS
• Can encapsulate EAP
AuthZ over AAA
• EAP is an authn protocol
• What about authz?
• RADIUS /RadSec enables authz to be separate
from authn
– Directly, but may be limited (RADIUS attr’s)
• ABFAB also defines SAML over AAA for finergrained, flexible, authz information
GSS-API / SSPI / SASL
• How to integrate applications?
– GSS-API / SSPI / SASL are ways to abstract security
from applications
– GS2 (RFC 5801) bridges SASL and GSS-API
• ABFAB defines a GSS-API EAP mechanism
(GSS-EAP)
Actors in ABFAB
• Client
– Application/device attempting to access RP
• Relying Party (RP)
– Service that is ABFAB enabled
• Identity Provider (IdP)
– Authenticates users on behalf of that organisation
• N.B.
– Trust relationship between IdP and RP.
Protocol Overview
----- = Between Client App and RP
===== = Between RP and IdP
- - - = Between Client App and IdP
(via RP)
Relying
Client
Identity
Party
App
Provider
|
(1)
| Client Configuration
|
|
|
|<-----(2)----->|
| Mechanism Selection
|
|
|
|<-----(3)-----<|
| NAI transmitted to RP
|
|
|
|<=====(4)====================>| Discovery
|
|
|
|>=====(5)====================>| Access request from RP to IdP
|
|
|
|
|< - - (6) - -<| EAP method to Client
|
|
|
|
|< - - (7) - ->| EAP Exchange to authenticate
|
|
| Client
|
|
|
|
|
(8 & 9) Local Policy Check
|
|
|
|<====(10)====================<| IdP Assertion to RP
|
|
|
(11)
|
| RP processes results
|
|
|
|>----(12)----->|
| Results to client app.
Discovery
• Most EAP methods have inner and outer
tunnels
– Stuff in outer tunnel is readable by bits in the
middle
– Stuff in inner tunnel only readable by the
endpoints
– Outer tunnel contains realm only ( e.g. @mit.edu)
• This indicates IdP to use.
– Inner tunnel contains credentials (e.g.
someuser@mit.edu & password)
Discovery
• The RP and IdP need to know where each
other are, and have keys for each other
– Options:
• Statically configured bi-lateral trust – RADIUS
• Statically configured hierarchical trust = RADIUS (e.g.
eduroam)
• Dynamically created trust = Trust Router
Flow with pre-configured keys
Service (Relying Party)
GSSSession
EAP
EAP RadSec
Access-Accept
Client
RP
Proxy
RadSec
Access-Accept
IdP
Proxy
Flow with Trust Router
Service (Relying Party)
GSSSession
EAP
EAP RadSec
Access-Accept
Client
RP
Proxy
TPQ
T.I.
RadSec
Access-Accept
Trust
Router
Trust
Router
Temporary Identity
IdP
Proxy
Trust
Router
Requirements
• Client
– ABFAB libraries, Identity Selection Mechanism
• Service
– ABFAB libraries, RADSEC
• RP
– ABFAB libraries, RADSEC server
• IdP
– ABFAB libraries, RADSEC server, SAML server (opt)
ABFAB libraries?
• Moonshot
– major implementation of ABFAB, from Janet.
– Largely open source
– Builds on Kerberos & Shibboleth SP code
– GSS-API implementation (GSS-EAP)
ABFAB AND INTERNET-OF-THINGS
Overview
• An ABFAB-style mechanism seems appropriate
– Decoupled AuthN/AuthZ from core protocol
• In a way that is flexible and extensible
– Could use GSS-EAP directly – but that’s built for
our application/service layer use cases
– Or could use a custom ABFAB mechanism that
better fits IoT requirements
• i.e. GSS-less ABFAB
• E.g. EAP for authn, DTLS
ABFAB++
• EAP’s decoupling of credential types and trust
establishment from rest of system
• ABFAB-style architecture – Separate out
AuthN from AuthZ
• Flexibility about client and AuthZ server.
• Programmatic way of approaching AuthZ (AAA
attributes)
ABFAB-• Multiple round trips in EAP – power req’s of
this!
– Need to optimise EAP
– & use appropriate EAP method
Making ABFAB better for ACE
• An EAP method that works well with
DICE/DTLS
• Optimising EAP
– Removing unnecessary EAP round trips
• RADIUS over DTLS with DICE constraints (for
authz server on constrained device)
• Compression/better encoding of authz info
• New instantiation of ABFAB arch – DTLS based
Q&A?