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. firstname.lastname@example.org & 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?