An Introduction to the Emerging JSON-Based Identity and Security Protocols (OWASP Vancouver edition)

Copyright ©2013 Ping Identity Corporation. All rights reserved.1

An Introduction to the Emerging JSON-Based

Identity and Security Protocols

Brian Campbell@__b_c

November 2013Slides: http://goo.gl/cQIQSf

OWASP Vancouver


• Introductions• Backstory • Technical Overview of a few of the new(ish)

JSON-Based Protocols

Agenda


As Portfolio Architect for Ping Identity, Brian Campbell aspires to one day know what a Portfolio Architect actually does for a living. In the meantime, he's tried to make himself useful with little things like designing and building much of PingFederate, the product that put Ping Identity on the map. When not making himself useful, he contributes to various identity and security standards including a two-year stint as co-chair of the OASIS Security Services Technical Committee (SAML) and is currently contributing to OAuth and JOSE in the IETF as well as OpenID Connect. He holds a B.A., magna cum laude, in Computer Science from Amherst College in Massachusetts. Despite spending four years in the state, he has to look up how to spell "Massachusetts" every time he writes it.

Brian CampbellBrian Campbell


BACKSTORY

A TALE OF TWO

TOKENS


That Sam-I-am!

• Security Assertion Markup Language – SAML sounded better than SCML

• XML-based framework that allows identity and security information to be shared across security domains

• Primarily used for cross domain Web browser single sign-on

• Assertion is a (usually signed, sometimes encrypted) security token– XML Digital Signatures– XML Encryption

• Enterprisy Reputation• Paying my bills for nearly a decade


It was the best of times…

http://flic.kr/s/aHsjAP3nKo


SAML is DEAD!

it was the worst of times…

“Craig Burton is one of the

leading visionaries and analysts in the

computer industry.”*

* http://www.linkedin.com/in/burtonian

SAML

Stan and Kyle are fictional characters from the TV show South Park. I presume the show’s creators, Trey Parker & Matt Stone, are rich enough and busy enough

not to bother suing me over unlicensed use in some nerdy computer presentation.


it was the age of foolishness…

WTF “SAML is dead”? I’ve got a mortgage to

pay…

*Disclaimer: I work with these guys at Ping

But I just started this job!

@paulmadsen

@ian13550


Dave "Crusty Curmudgeon”*

Kearns

** Burton actually said it but Kearns quotes him in http://blogs.kuppingercole.com/kearns/2012/07/31/the-death-and-life-of-a-protocol/ and I really wanted to use “Crusty Curmudgeon”

* @dak3

it was the age of wisdom…

“SAML is the Windows XP of

Identity. No funding. No innovation.

People still use it. But it has no

future.”**

meanwhile I’ve got 29 years of mortgage payments remaining and kids in private school so I thought maybe I should figure out what *is* the

future…


on your deathbed, you will receive total consciousness

*I did actually receive permission to use this photo

Sometimes reinventing the wheel gets you something a little more round

– JSON Web Token– JSON Web Signature– JSON Web Encryption– JSON Web Key

JW* or JW[STEAK]


base64 vs. base64url

• base64url is *almost* like base64 – Both are a means of encoding binary data in a printable ASCII string

format– Each 6 bits -> 1 character (from a 64 character alphabet)– 3 bytes -> 4 characters

• But base64url uses a URL safe alphabet rather than the nearly URL safe alphabet of regular base64 – 62 alphanumeric characters– “-” rather than “+”– “_” rather than “/”– Padding “=” is typically omitted

• A remaining unreserved URI character: “.”– This will prove important shortly


• JSON Web Signature• A way of representing content secured with a

digital signature or MAC using JSON data structures and base64url encoding– Encoded segment are concatenated with a “.”

• Intended for space constrained environments such as HTTP Authorization headers and URI query parameters

• Conceptually Simple:– Header.Payload.Signature

JWS


• JWS Header– A bit of JSON that describes the digital signature or MAC operation applied to create

the JWS Signature value

• Reserved Header Parameter Names– “alg”: Algorithm

• HMAC, RSA and ECDSA • None (controversy!) • Extensible

– “kid”: Key ID– “jku”: JWK Set URL– “jwk”: JSON Web Key– “x5u”: X.509 URL– “x5t”: X.509 Certificate Thumbprint– “x5c”: X.509 Certificate Chain– “typ”: Type– “cty”: Content Type

• Header Example

“I signed this thing with RSA-SHA256 using key ID of ‘9er’ and you can find the corresponding public key at https://www.example.com/jwk”

{"alg":"RS256", "kid":”9er", "jwk”:"https://www.example.com/jwk"}

JWS Header


JWS Algorithms

http://tools.ietf.org/id/draft-ietf-jose-json-web-algorithms-17.html


JWS Example

Payload -> USA #1!base64url encoded payload -> VVNBICMxIQ

Header (going to sign with ECDSA P-256 SHA-256) -> {"alg":"ES256"}base64url encoded header -> eyJhbGciOiJFUzI1NiJ9

Secured Input -> eyJhbGciOiJFUzI1NiJ9.VVNBICMxIQ

base64url encoded signature over the Secured Input -> Zi1ZJeptOMNJ7Yb-WjlVQyz8sk4GZTy-

EZh4dI_8UiZOu7nKK6xjTapsLRfe7fYoKtpCcHOYo1m8DNl6hLoISw

JWS Compact Serialization ->eyJhbGciOiJFUzI1NiJ9.VVNBICMxIQ.Zi1ZJeptOMNJ7Yb-WjlVQyz8sk4GZTy-EZh4dI_8UiZOu7nKK6xjTapsLRfe7fYoKtpCcHOYo1m8DNl6hLoISw

Which you can think of sort of like:{"alg":"ES256"}.USA #1!.<SIGNATURE>


• JSON Web Encryption• Similar in motivation and design to JWS but for encrypting

content• A little more complicated

– Headers• “alg”: Algorithm (key wrap or agreement)• “enc”: Encryption Method (Authenticated Encryption only)• “zip”: Compression Algorithm• Etc.

• Five Parts

Header.EncryptedKey.InitializationVector.Ciphertext.AuthenticationTag

JWE


JWE Key Management Algorithms (“alg”)



JWE Content Encryption Algorithms (“enc”)


• Note that all of the encryption methods are AEAD algorithms


Payload/plaintext -> I actually really like Canada

Header -> {"alg":"ECDH-ES+A128KW","enc":"A128CBC-HS256","epk":{"kty":"EC","x":"Y9YfiejQGZW4o47zj4q7THlRRwhSpJPvtf5oF0sOMVA","y":"DnYzBhlR57cW4Y8_Ae2s9WRm1Ju0Pi81aLY0VkA2Gnk","crv":"P-256"}}

base64url encode header -> eyJhbGciOiJFQ0RILUVTK0ExMjhLVyIsImVuYyI6IkExMjhDQkMtSFMyNTYiLCJlcGsiOnsia3R5IjoiRUMiLCJ4IjoiWTlZZmllalFHWlc0bzQ3emo0cTdUSGxSUndoU3BKUHZ0ZjVvRjBzT01WQSIsInkiOiJEbll6QmhsUjU3Y1c0WThfQWUyczlXUm0xSnUwUGk4MWFMWTBWa0EyR25rIiwiY3J2IjoiUC0yNTYifX0

Encrypted Key: ECDH-ES key agreement used to AES Key wrap a 256 bit random key which is base64url encoded -> DhHq778-jzaFU8I9i4BQOGAPi0gBWp4L8hqlaSvuwq1-eHpruLwlNg

IV: base64url encoded 128 bit initialization vector -> wAnQy_IfyJd5cW3ZKYzzIg

Ciphertext: AES 128 CBC plaintext is base64url encoded -> teyZQzpS-BgEQtfLGduU9HlO0pZYo9ALnLHLIvPT0n8

Authentication Tag: base64url encoded left truncated SHA-256 HMAC of encoded header, IV and ciphertext -> Mlc19AsGhJBUA1J3-vojD

Header.EncryptedKey.InitializationVector.Ciphertext.AuthenticationTag

eyJhbGciOiJFQ0RILUVTK0ExMjhLVyIsImVuYyI6IkExMjhDQkMtSFMyNTYiLCJlcGsiOnsia3R5IjoiRUMiLCJ4IjoiWTlZZmllalFHWlc0bzQ3emo0cTdUSGxSUndoU3BKUHZ0ZjVvRjBzT01WQSIsInkiOiJEbll6QmhsUjU3Y1c0WThfQWUyczlXUm0xSnUwUGk4MWFMWTBWa0EyR25rIiwiY3J2IjoiUC0yNTYifX0.DhHq778-jzaFU8I9i4BQOGAPi0gBWp4L8hqlaSvuwq1-eHpruLwlNg.wAnQy_IfyJd5cW3ZKYzzIg.teyZQzpS-BgEQtfLGduU9HlO0pZYo9ALnLHLIvPT0n8.Mlc19AsGhJBUA1J3-vojD

JWE Example


• JSON Web Token• Suggested pronunciation: "jot”• Compact URL-safe means of representing claims to be

transferred between two parties• JWS and/or JWE with JSON claims as the payload• JWT Claim

– A piece of information asserted about a subject (or the JWT itself).– Represented name/value pairs, consisting of a Claim Name and a

Claim Value (which can be any JSON object).– Reserved Claim Names

• “iss”: Issuer • “sub”: Subject • “aud”: Audience• “exp”: Expiration Time • “nbf”: Not Before • “iat”: Issued At• “jti”: JWT ID

JWT


jot or not?

The JWTeyJraWQiOiI1IiwiYWxnIjoiRVMyNTYifQ.eyJpc3MiOiJodHRwczpcL1wvaWRwLmV4YW1wbGUuY29tIiwKImV4cCI6MTM1NzI1NTc4OCwKImF1ZCI6Imh0dHBzOlwvXC9zcC5leGFtcGxlLm9yZyIsCiJqdGkiOiJ0bVl2WVZVMng4THZONzJCNVFfRWFjSC5fNUEiLAoiYWNyIjoiMiIsCiJzdWIiOiJCcmlhbiJ9.SbPJIx_JSRM1wluioY0SvfykKWK_yK4LO0BKBiESHu0GUGwikgC8iPrv8qnVkIK1aljVMXcbgYnZixZJ5UOArg

The Header{"kid":"5","alg":"ES256"}

The Payload{"iss":"https:\/\/idp.example.com","exp":1357255788,"aud":"https:\/\/sp.example.org","jti":"tmYvYVU2x8LvN72B5Q_EacH._5A","acr":"2","sub":"Brian"}

The Signature[computery junk]


it’s not the size of your token…

eyJraWQiOiI1IiwiYWxnIjoiRVMyNTYifQ.eyJpc3MiOiJodHRwczpcL1wvaWRwLmV4YW1wbGUuY29tIiwKImV4cCI6MTM1NzI1NTc4OCwKImF1ZCI6Imh0dHBzOlwvXC9zcC5leGFtcGxlLm9yZyIsCiJqdGkiOiJ0bVl2WVZVMng4THZONzJCNVFfRWFjSC5fNUEiLAoiYWNyIjoiMiIsCiJzdWIiOiJCcmlhbiJ9.SbPJIx_JSRM1wluioY0SvfykKWK_yK4LO0BKBiESHu0GUGwikgC8iPrv8qnVkIK1aljVMXcbgYnZixZJ5UOArg

<Assertion Version="2.0" IssueInstant="2013-01-03T23:34:38.546Z” ID="oPm.DxOqT3ZZi83IwuVr3x83xlr" xmlns="urn:oasis:names:tc:SAML:2.0:assertion” xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <Issuer>https://idp.example.com</Issuer> <ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"/> <ds:Reference URI="#oPm.DxOqT3ZZi83IwuVr3x83xlr"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <ds:DigestValue>8JT03jjlsqBgXhStxmDhs2zlCPsgMkMTC1lIK9g7e0o=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>SAXf8eCmTjuhV742blyvLvVumZJ+TqiG3eMsRDUQU8RnNSspZzNJ8MOUwffkT6kvAR3BXeVzob5p08jsb99UJQ==</ds:SignatureValue> </ds:Signature> <Subject> <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">Brian</NameID> <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <SubjectConfirmationData NotOnOrAfter="2013-01-03T23:39:38.552Z" Recipient="https://sp.example.org"/> </SubjectConfirmation> </Subject> <Conditions NotOnOrAfter="2013-01-03T23:39:38.552Z" NotBefore="2013-01-03T23:29:38.552Z"> <AudienceRestriction> <Audience>https://sp.example.org</Audience> </AudienceRestriction> </Conditions> <AuthnStatement AuthnInstant="2013-01-03T23:34:38.483Z" SessionIndex="oPm.DxOqT3ZZi83IwuVr3x83xlr"> <AuthnContext> <AuthnContextClassRef>2</AuthnContextClassRef> </AuthnContext> </AuthnStatement></Assertion>

JWT

SAML


• Simpler = Better• Web safe encoding w/ no canonicalization

– Because canonicalization is a four letter word (especially when you spell it c14n)

• Improved Interoperability & (hopefully) More Secure • Eliminates entire classes of attacks

– XSLT Transform DOS, Remote Code Execution, and Bypass– C14N Hash Collision w/ & w/out comments– Entity Expansion Attacks– XPath Transform DOS and Bypass– External Reference DOS– Signature Wrapping Attacks*

…it’s how you use it

* This poor bastard was the ‘victim’ in my POC of a signature wrapping vulnerability in SAML SSO for Google Apps http://www.google.com/about/appsecurity/hall-of-fame/reward/

Brad Hill is wicked smaht and published some of the attacks listed here


• JSON data structure that represents cryptographic key(s) which can be– included in a JWS/JWE/JWT header– saved in a file– used in place of self signed certificates– published at an HTTPS endpoint and referenced

JSON Web Key (JWK)

JWT/JWS Header{"kid":"5","alg":"ES256"}

{"keys":[ {"kty":"EC", "kid":"4", "x":"LX-7aQn7RAx3jDDTioNssbODUfED_6XvZP8NsGzMlRo", "y":"dJbHEoeWzezPYuz6qjKJoRVLks7X8-BJXbewfyoJQ-A", "crv":"P-256"}, {"kty":"EC", "kid":"5", "x":"f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU", "y":"x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0", "crv":"P-256"}, {"kty":"EC", "kid":"6", "x":"J8z237wci2YJAzArSdWIj4OgrOCCfuZ18WI77jsiS00", "y":"5tTxvax8aRMMJ4unKdKsV0wcf3pOI3OG771gOa45wBU", "crv":"P-256"}]}


• Compossible, reusable and being used – OAuth– OpenID Connect– Mozilla Persona – W3C Web Cryptography API– And more…

• *Approaching* finalization as RFCs– http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-12– http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-17– http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-17– http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-17– http://tools.ietf.org/html/draft-ietf-jose-json-web-key-17

JW[STEAK] in Action

three nerds holding a blurry piece of paper they tell me is some kind of

award for OpenID Connect


• Java– https://bitbucket.org/b_c/jose4j

• Ruby– https://github.com/nov/json-jwt

• JavaScript – http://kjur.github.com/jsjws/– https://npmjs.org/package/jwt– https://npmjs.org/package/green-jwt– https://npmjs.org/package/jsjws

• Perl– https://metacpan.org/module/JSON::WebToken– https://github.com/kjur/jwsverify.pl– https://github.com/xaicron/p5-JSON-WebToken

• Python– https://pypi.python.org/pypi/jws/0.1.0– https://github.com/rohe/pyjwkest

• PHP– https://github.com/ritou/php-Akita_JOSE

• .NET– https://github.com/johnsheehan/jwt

• Note that inclusion here does not imply endorsement of any kind (except for jose4j) and is informational in nature and intended only to show that there is widespread support for the emerging new standards

JW[STEAK] Implementations


• Which is nice• The JWS and JWE examples in this presentation were created using jose4j and just a few lines of code

JW[STEAK] implies a simple programming interface

https://bitbucket.org/b_c/jose4j in case you missed the URL on the last slide

https://bitbucket.org/b_c/jose4j

https://bitbucket.org/b_c/jose4j


You’ve been Introduced to some JSON-Based Identity and Security

Protocols

Brian Campbell@__b_c

November 2013http://goo.gl/cQIQSf

SAMLAny Questions?

And thanks for putting up with me for the last hour.

An Introduction to the Emerging JSON-Based Identity and Security Protocols (OWASP Vancouver edition)

Technology

Transcript of An Introduction to the Emerging JSON-Based Identity and Security Protocols (OWASP Vancouver edition)