Authorization architecture sketches

draft-selander-core-access-control-02draft-gerdes-core-dcaf-authorize-02

draft-seitz-ace-design-considerations-00

Göran SelanderIETF 89 ACE BOFMarch 5, 2014

• Goal: Protected access for authorized client C to resources on RS allowing explicit and dynamic access policies

• But constrained devices may be unable to handle management and decisions with generic access control polices

Client Resource access

Architecture sketch

Resource Server

Authorization Server

ClientResource Server

• Separate authorization decision from enforcement• Introduce less constrained node called AS

Decision

Enforcement

Architecture sketch Resource Owner

(out of scope)

Authorization Server

Client

Key establishment

(out of scope)Information flow: authorization info

Resource Server

AuthZinfo

• The RS must authenticate the authorization info and that itcomes from a trusted AS

Authorization Server

Client

AuthZinfo

Information flow: resource access

Resource Server

• The RS enforces access control based on authZ info• Multiple resource requests as long as authZ info is valid

Established keys

Resource access

Authorization Server

Client

AuthZinfo

Resource access

Information flow:Keys for protecting resource access

Resource Server

AuthN infoabout C

AuthN info about RS

• The RS must be able to verify that a requesting Client is encompassed by the authorization information

• AS may support key management between C and RS

Established keys

Authorization Server

Client

AuthZinfo

Resource access

Alternative information flow

Resource Server

AuthN Info about C

• RS and AS may not be connected at the time of the request

Established keys

AuthN info about RS

Authorization Server

Client

Cross domain

Resource Server

Resource access

AuthN info

Established keys

Esta

blis

hed

keys

AuthN info AuthZinfo

AuthN info

Authorization Server

• Alternative information flows are possible

Design considerations

• Need multi-party security protocol– Profile existing security protocol? Which protocol?– Consider tradeoffs e.g. between messaging and crypto relevant

for constrained environments• Session security or object security or hybrid?

– E.g. securing transfer of authorization information• Symmetric or asymmetric keys

– for verifying authorization information?– for establishing security between the parties

• Is revocation required or is authZ info with short time validity sufficient?– Access to revocation information?

Thank you!

Questions/comments?