Distributed Authorisation Infrastructures X 509 Attribute Certificates

Distributed Authorisation Infrastructures – X. 509 Attribute Certificates and SAML u Stephen u Farrell stephen. farrell@baltimore. ie

Authori[sz]ation u Operating Systems tend to have more-or-less consistent authorization models – Multics, Unix, Windows – All offer an authorization infrastructure (as do mainstream DBMSs) u Hasn’t really worked well for – Application layer authorisation when that doesn’t map nicely to OS entities – Distributed Systems – Despite some valiant attempts (e. g DCE, Corba)

Why this lack of infrastructure? u If we think in terms of subjects, objects and permissions – The subjects may not map well to OS accounts – The objects may not map well to any OS entity (mainly files) – The permissions may not map well to OS permissions (e. g. rwx insufficient) Authorization infrastructures are complex u Relatively few applications required a real infrastructure u So application developers tend to either (somewhat artificially) try to map to OS or DB concepts or else invent their own solutions (over and over again) u

Who tried what? u Military: Bell-La. Padula, MLS, various others u DCE: Authentication and Kerberos adata field and distributed ACLs u ECMA/SESAME: Kerberos/PKI + Privilege Attribute Certificates + PVF u Win 2 k: Similar to the above! u Corba: Secure IIOP, DCE RPC and/or SESAME

In-play authorisation infrastructures u X. 509: Attribute Certificates – RFC 3281, ETSI-EESSI u SAML: XML authorization framework – XACML, Xr. ML, Liberty

X. 509 & PKIX Originally part of X. 500 (Directory) set of ISO/ITU-T standards u Defines Public Key Certificate (PKC) and Attribute Certificate (AC) data structures and semantics u – Does not define supporting protocols u In 1995 an IETF working group (PKIX) was chartered to profile X. 509 and to define supporting protocols – PKC profile RFCs 3279, 3280 – AC profile RFC 3281 – Management Protocols RFC 2510 (CMP), 2797 (CMC) – Certificate Status RFC 2560 (OCSP)

X. 509 Attribute Certificates u Mainline description is based on RFC 3281 – Exceptions as noted u Basic idea is to have an AC issuer who encodes privileges and other attributes of a “holder” into an attribute certificate – Looks almost the same as an X. 509 PKC but with attributes instead of a public key – Well defined attributes include: Authentication Information, Identities (Access, Charging), Role, Group, Clearance – All this can also be done using PKC extensions but…

AC fields u ACs are signed; To-be-Signed structure: – version – holder – issuer – signature – serial. Number – attr. Cert. Validity. Period – attributes – extensions

Other AC concepts u Holder linkage u Audit identity extension u Targetting u Attribute encryption u Revocation u AA controls (for AC issuer’s PKC)

AC Usage for access control u Short-lived ACs are not unusual (minimum 1 second) u Entities involved: AC Issuer, AC Owner, AC verifier – Verifier “trusts” Issuer to only issue “good” ACs – Owner provides evidence (e. g. digital signature) of ownership – Verifier checks AC and (all being well) associates attributes with owner and makes an access decision

“Pull” Model AC-Issuer Actually could be “in front” of the real issuer 2. AC Request and Response AC-Holder 1. Application Protocol (no ACs) AC-Verifier

“Push” Model AC-Issuer 1. AC Request and Response AC-Holder 2. Application Protocol (with ACs) AC-Verifier

Proxying AC-Issuer 2. AC Request and Response AC-Holder 1. Application Protocol (no ACs) AC-Verifier Note: This is one model for proxying, others exist! 3. Application Protocol (with ACs)

AC Delegation u X. 509 model includes extensions supporting delegation and “chains” of Acs – Note: Not part of RFC 3281 – Delegation: Alice (AC Issuer 1) says that Bob (AC Issuer 2) says that Charlie (Owner) is an administrator – AC Chains provide a way to implement this – AC 1=[Issuer: Alice, Owner: Bob; Extensions=“AC issuer”] – AC 2=[Issuer: Bob, Owner: Charlie; Attributes: role=“administrator”] – Chain = AC 1 + AC 2 – If Dave (AC Verifier) “trusts” Alice, then he can tell that Charlie is an administrator without explicit configuration about Bob.

X. 509 Delegation Concept

(Killer!) Issues with AC delegation u Practical: How does owner (Charlie) or verifier (Dave) find superior ACs? – Similar (but easier) issue for PKCs u Theoretical: Given a selection, how can Charlie know which AC chain is good for Dave? – Much worse than for PKCs – keys do “chain”, attributes don’t – Dave could expose his full set of ACLs, but that doesn’t seem wise – And doesn’t reference Bob in any case, so only serves to further confuse Charlie! u A Canadian Do. D study (at 2002 NIST/Internet 2 PKI Research Workshop) of procurement processes found that 109 certificates (both PKCs and ACs) were needed to buy a bar of soap!

ACs and Electronic Signatures u ETSI EESSI group defining ASN. 1 (& near-XML: -) based data structures and ancilliary standards aimed at matching electronic signature legislation to digital signature mechanisms – Bascially an extension of S/MIME aka CMS Signed. Data aka PKCS#7 – Not explicitly supported by RFC 3281 u Includes use of ACs (as does CMS!) – To indicate “authority” for electronic signature – E. g. “Alice (Issuer) says that Bob (Owner) is allowed to electronically sign for soap purchases” u Not clear if this approach will take off (maybe due to current lack of supporting s/w)

General Issues with X. 509 ACs u Even RFC 3281 has issues though – Current lack of support in protocols, toolkits and applications u But: – Authorisation mangagement is a real problem – More-so today with “web services” than previously – Web services really does involve multi-vendor application layer interoperability u And XML is the flavour of the month anyway!

A concrete problem for today Two separate networks at two different companies u Each has own security and technology deployment u Companies form an online partnership u

The Problem Two separate networks at two different companies u Each has own security and technology deployment u Companies form an online partnership u Want on-line customers to be able to traverse each other’s Web sites with Single Sign-on u ?

The Old Solution u The Two companies get their IT departments together u They share user information u They hack together a SSO solution u They may be forced to open up components of their network to their partners u Both companies spend too much time maintaining the solution

The Problem Made Worse Along comes a third company u It wishes to join the two company alliance u Now all three companies must make changes u Maintaining the system across three networks is a nightmare u Then along comes company number four…. u

SAML: TNG Solution u Industry adopted standard way to provide SSO between separate networks u Companies only need to maintain their own data u Scalable to any number of partners u Allows companies to control which information is shared with its partners on a partner by partner basis u All cross company communications protected by strong cryptography

SAML: How Does It Work? Company A Web Environment Company B Web Environment SAML Service Browser

SAML: How Does It Work? Company A Web Environment Company B Web Environment SAML Service Browser 1. The user authenticates to Company A’s Web system and browses through the site

SAML: How Does It Work? Company A Web Environment http: //Visit Our Partner! SAML Service Company B Web Environment SAML Service Browser 2. User clicks on a link that takes her to Company B. The link is setup to automatically take the User to Company A’s SAML server.

SAML: How Does It Work? Company A Web Environment Company B Web Environment SAML Service From: Company A Ref: User X Browser 3. Company A’s SAML server redirects the user’s browser to Company B’s SAML server. Some site specific information is added to the redirect data for use by Company B’s SAML server.

SAML: How Does It Work? Company A Web Environment SAML Service Company B Web Environment What’s up with User X? SAML Service Is Partner B allowed to get this info? Browser 4. Company B’s SAML uses the site specific information to communicate with Company A’s SAML server.

SAML: How Does It Work? Company A Web Environment SAML Service Company B Web Environment SAML Assertion SAML Service Browser 5. Company A and B’s SAML servers authenticate each other. Then Company A passes to Company B, for this specific user, the information they have agreed to share with each other

SAML: How Does It Work? Company A Web Environment SAML Service User: X Auth: Password Cust. Status: Gold … Drinks: Coffee Company B Web Environment SAML Service Browser 5. Company A and B’s SAML servers authenticate each other. Then Company A passes to Company B, for this specific user, the information they have agreed to share with each other

SAML: How Does It Work? Company A Web Environment Company B Web Environment SAML Service Add: User X Browser 6. Company B’s SAML server updates the authorization system with the new user information received from Company A.

SAML: How Does It Work? Company A Web Environment SAML Service Company A password auth accepted! Company B Web Environment SAML Service Browser 7. User gets redirected to Company B’s Web system. Company B’s authorization system determines her access permissions.

SAML u The user is automatically redirected to Company B’s web site with no further action other than the initial click on the link u Company B now has the required user information so that it can make authorization checks u SAML exchanged data ages and gets thrown away so that it doesn’t linger

SAML Security Issues All communications are over SSL u SAML servers authenticated each other before talking u SAML sites will only pass user information to the correct destination SAML server u Users are properly authenticated each step of the way even if they are not prompted u SAML assertions are identified by originating site u Replay attacks to get SAML information are prevented u Cached data in SAML servers has limited lifetime u

SAML vs. X. 509 ACs u Actually quite similar concepts – One with ASN. 1, one with <Angle. Brackets> (XER anyone!) u Any system architecture for one can work for the other given suitable fussing with details u Privacy issues: both the same, but perception will (probably) be that SAML is worse u Performance: again similar, though SAML may end up better

SAML u SAML maps better to current web services primitives – URIs/URLs and HTTP re-direct in particular SAML maps better to legacy authentication schemes u Much better industry support today u – Esp. amongst authorisation product vendors (including guess who? ) u Associated developments: XACML, Liberty – Not necessarily a benefit to SAML though! (Complexity) u Overall security of multi-vendor SAML-based systems still needs to be seen to be demonstrated (for a while longer) in the wild – But, properly implemented and deployed, SAML is definitely better than what’s there now

Attribute Certificates u ACs map better to X. 509 based PKI – When all is said and done PKI is the only real authentication infrastructure other than passwords or OS account mechansims u More military systems work has considered ACs (might well change) u Security considerations more mature and with fewer external dependencies u Lack of software the main problem

Conclusions There’s a whole lot of well-defined infrastructure stuff u X. 509 ACs and SAML are both real, usable technologies u SAML is definitely more fashionable and will clearly “win” if/when “web services” takes off u X. 509 AC model however still provides lots of lessons that ought not be ignored u Format issues are not the main game in any case! u – Populating the database of privileges is the real challenge – So dual-support or migrating back and forth is possible

Thank you! u Questions? – Nice, easy ones preferred : -)