230 likes | 411 Views
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
E N D
ABFAB for Internet-of-Things Rhys Smith, Janet Sam Hartman & Margaret Wasserman, Painless Security
Agenda • ABFAB Overview • ABFAB for IoT • Q&A
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.
----- = Between Client App and RP===== = Between RP and IdP- - - = Between Client App and IdP (via 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.
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
EAP EAP Flow with pre-configured keys Session GSS Service (Relying Party) Client Access-Accept RadSec RP Proxy Access-Accept RadSec IdP Proxy
EAP EAP Flow with Trust Router Session GSS Service (Relying Party) Client Access-Accept RadSec RP Proxy T.I. TPQ Trust Router Trust Router Access-Accept RadSec Temporary Identity Trust Router IdP Proxy
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)
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 IoTrequirements • 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