Core Assertions

Core Assertions

Phill Hallam-Baker

Status

• Waiting for use cases to specify problem• Can give a price of specific use case features

– Auth-XML / S2ML / X-TASS / ITML …• Whose method is best is not the issue at this point

– Number of communications absolutely necessary• Fewer is better

– Data flow Communication Graph

– Re-use of data structures

Decision Process(Coh-Ad Model)

Divide Decisions into 3 types:1) Nobody cares (very much)

• Tag names, structure nesting etc.

• Everyone has to burn their code anyway

2) Objective design issues• Protocol efficiency etc.

• Discuss

3) Subjective design tradeoff decisions• Identify costs / benefits of alternate approaches

• Send to full group

Data Structures Identified Thus Far

• Assertion– Authenticated statement

• Ticket / Assertion Token– Compact reference to an assertion– Strong cryptographic binding

Parties

Issuer

Client

Relying

May not supportAssertions / SAML

‘64 byte boundary’

‘Distributor’ ‘Enforcer’

Pull Model

Issuer

Client

Relying

V Model

Issuer

Client

Relying

Proxy Model

Issuer

Client

Relying

“Must be a Plumber”

Amalgamated Plumber’s Union

“Alice is a Plumber”

Multiple Issuer Model

Client

RelyingIssuer Issuer

Assertion Data Structure

• Assertion Identifier - URI

• Status– Valid | Invalid | Indeterminate

• Authorization(s)

• Subject Identifier– Authentication Data

• Conditions– Validity Interval

– Other Essential Conditions

• When / how to get an update [Optional]

Authorizations

• Option 1: Shared Vocabulary of Terms– URI – the Web way to do this

• URL – Can identify the actual resource [I.e. AuthZ Decision]– OK to access http://xyz.test/dead_secret.html

• URN – Can encode rights [I.e. Constrained AuthZ Attribute]– Need mechanism to map rights to resources– SAML need not define this [Decoupled]

• Option 2: Private Extension Schema– For data more structured than URN allows

• [I.e. Unconstrained AuthZ Attributes]• <a:AuthData xmlns=“…”> <a:Title>Fat Controller</Title> …

Subject / Authentication Data Identification

• Essential– Bind assertion to authentication data

• ‘Holder of this ticket has these authorizations’• ‘Holder of this public key has these authorizations’• ‘Holder of this account (i.e. reference to password)

has these authorizations’

• Useful (in some circumstances)– Bind assertion to identity

• ‘Alice has these authorizations’

Note on Multiple Issuer Case

• Deliberately avoid committing Assertion structure to particular level of granularity– Leave this to implementation– Does not introduce ambiguity– Reduces number of data structures required– Allows great flexibility

Conditions

Validity Interval– | notBefore notOnOrAfter ]

Audience– Assertion statement may be directed to specific audience– Address the legal issue of relying party problem & good hygiene

Verification Requirement– MUST get positive affirmation per use

Unsupported Condition [Privately defined]– MUST consider assertion status to be Indeterminate– Ensure that applications do not rely on private conditions

Reissue [Optional]

• Specify reissue time & locations– | Earliest Latest ]– Locations

• Used for pull / polling model

• Optional– Issuer does not need to generate– Relying that does not support can ignore

Discrete Increase In Complexity

Session Management Support

“Forced Log Out”

Session Management

• What does it mean for assertion?– Assertion status becomes invalid before expiry

• Why is this a challenging problem?– How to notify parties relying on on assertion

• Efficiency• Robustness• Push or Pull model???

• It is a solved problem however (sort of)– PKIX CRLs / Delta CRLs / Scoped CRLs / OCSP– Don’t invent new mechanism – its probably patented

Push

Issuer Relying

Relying

Relying

Alice is Fired

Revoke AliceAuthorizations

Problem, what ifMessage does notget through?

Pull

Issuer Relying

Relying

Relying

Alice is Fired

Alice OK?

Fired Problem – EfficiencyCan we cache response?Can we aggregate?

X-TASS Meta Assertions

• Identify assertion by URI– Define lexical ordering on URIs

• Meta assertion may specify status of one assertion or a group of assertions– Combine OCSP token and CRL concept– Scope of meta assertion is entirely arbitrary

• Chosen at time meta assertion is generated• C.f. CRL length increases with certificate population

X-TASS Meta Assertion Status List

IndeterminateValidhttp://abc.test/0412

http://abc.test/0134 http://abc.test/0634

http://abc.test/0012

http://abc.test/0145

http://abc.test/0424

http://abc.test/0612

Valid False

Valid

Invalid

Invalid

Invalid

True

True

True

True

http://xyz.test/2832 http://xyz.test/9283 Valid True

Is also an assertion:Specify validity intervalSpecify re-issue schedule

XTASS Status

• Not currently in standards group process– Willing to relinquish change control

– Dependency issues – other specifications will use XTASS framework

• SAML uses 85% of X-TASS feature set– Remaining feature is management of embedded root keys

• Trust root embedded in device is PA

– Secret key SA lives in safe

• Once a year, an online key PB is established

– Delegation Assertion authorizing SB is created

• This feature could be specified in separate group

Ticket

• Means of referencing assertion– Opaque to clients

– Must be capable of embedding in URL, Cookie• 64 bytes 256 bytes with base64 encoding

• Authentication token– The token itself [if always passed over encrypted

channel]

– Data encrypted in token

Typical Ticket Data Items

• Hash of Assertion ID 20 bytes– Need to resolve somehow

• Locator (URL) of Assertion 3264 bytes– Need some compression mechanism

• Account ID 816 bytes– Flag as authenticated / not authenticated

• Validity Interval 10 bytes• Any Assertion Field ??? bytes• Authentication Field 20 bytes

Ticket Encoding Scheme

• Should have one– Probably needs to be flexible

– Must have minimal overhead

• Use ASN.1?– Complex, verbose, Mad, Bad, Dangerous to know

• Binary XML encoding?– Define tag dictionary

– MUST be encoded / decoded using one pass decoder

Possible scheme

• Data Item Encoding– Tag Length Value

• Structure Encoding [if required]– Tag Data End

T EStructure

LT Data LT Data LT Data

Encoding of Tags, Length Values

• Most tags, values encoded in one byte– Unlikely to have > 128 Tags– Unlikely to have data length > 128– But corner cases may require this

• Use MSB to indicate extension status, little-endian– 80 = 0 = 0H

– 81 = 1 = 0H

– FF = 127 = 7FH

– 00 81 = 128 = 00H + 01H•80H

– 7F FF = 16382 = 7FH + 7FH•80H

– Etc. as required

Conclusions

• Have mechanism to meet requirements raised thus far