Core Assertions
description
Transcript of Core Assertions
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’
“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
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