abfab for internet-of-things
Post on 23-Feb-2016
40 Views
Preview:
DESCRIPTION
TRANSCRIPT
ABFAB for Internet-of-Things
Rhys Smith, JanetSam 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 finer-grained, 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 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.
----- = Between Client App and RP===== = Between RP and IdP- - - = Between Client App and IdP (via RP)
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
RadSecRadSec
GSSEAP
EAP
Service (Relying Party)
Client
RPProxy
IdPProxyAccess-Accept
Access-Accept
Session
Flow with pre-configured keys
RadSec
TrustRouter
RadSec
TPQ
Temporary Identity
GSSEAP
EAP
Client
TrustRouter
TrustRouter
RPProxy
IdPProxy
T.I.
Access-AcceptAccess-Accept
Session Service (Relying Party)
Flow with 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?
top related