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 attrs) 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 | | | | | | Mechanism Selection | | | |<-----(3)-----<| | NAI transmitted to RP | | | | | Discovery | | | |>=====(5)====================>| Access request from RP to IdP | | | | |< - - (6) - -<| EAP method to Client | | | | | | 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 ( This indicates IdP to use. – Inner tunnel contains credentials (e.g. & 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 RadSecRadSec GSSGSS EAPEAP EAPEAP Service (Relying Party) Client RP Proxy IdP Proxy Access-AcceptAccess-Accept Access-AcceptAccess-Accept SessionSession Flow with pre-configured keys

RadSecRadSec Trust Router RadSecRadSec TPQTPQ Temporary Identity GSSGSS EAPEAP EAPEAP Client Trust Router Trust Router RP Proxy IdP Proxy T.I.T.I. Access-AcceptAccess-Accept Access-AcceptAccess-Accept SessionSession 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 thats 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++ EAPs 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 reqs 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?