1 / 28

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

klaus
Download Presentation

Core Assertions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Core Assertions Phill Hallam-Baker

  2. 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

  3. 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

  4. Data Structures Identified Thus Far • Assertion • Authenticated statement • Ticket / Assertion Token • Compact reference to an assertion • Strong cryptographic binding

  5. ‘Distributor’ ‘Enforcer’ ‘64 byte boundary’  May not supportAssertions / SAML Parties Relying Issuer Client

  6. Relying Issuer    Client Pull Model

  7. Relying Issuer    Client V Model

  8. Proxy Model  Relying Issuer  Client

  9. “Must be a Plumber” “Alice is a Plumber” Issuer Issuer Amalgamated Plumber’s Union Multiple Issuer Model Relying Client

  10. 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]

  11. 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> …

  12. 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’

  13. 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

  14. 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

  15. 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

  16. Discrete Increase In Complexity Session Management Support “Forced Log Out”

  17. 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

  18. Revoke AliceAuthorizations Problem, what if Message does not get through? Alice is Fired Push Relying Issuer Relying Relying

  19. Alice OK? Fired Alice is Fired Pull Relying Issuer Relying Problem – Efficiency Can we cache response? Can we aggregate? Relying

  20. 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

  21. http://abc.test/0412 Valid http://abc.test/0134 http://abc.test/0634 Valid False http://abc.test/0012 Valid True Invalid True http://abc.test/0145 http://abc.test/0424 Invalid True http://abc.test/0612 Invalid True http://xyz.test/2832 http://xyz.test/9283 Valid True X-TASS Meta Assertion Status List Indeterminate Is also an assertion: Specify validity interval Specify re-issue schedule

  22. 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

  23. 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

  24. Typical Ticket Data Items • Hash of Assertion ID 20 bytes • Need to resolve somehow • Locator (URL) of Assertion 3264 bytes • Need some compression mechanism • Account ID 816 bytes • Flag as authenticated / not authenticated • Validity Interval 10 bytes • Any Assertion Field ??? bytes • Authentication Field 20 bytes

  25. 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

  26. Possible scheme • Data Item Encoding • Tag Length Value • Structure Encoding [if required] • Tag Data End T Structure E T L Data T L Data T L Data

  27. 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

  28. Conclusions • Have mechanism to meet requirements raised thus far

More Related