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?