An assertion or three about Assertions

1. An assertion or three about Assertions • John Bradley • jbradley@mac.com • http://thread-safe.net • http://test-id.org

2. ICAM Approved Schemes • One Old Favourite • SAML 2.0 • Two New options • IMI 1.0 (Information Cards) • openID 2.0

3. Information Card (IMI) • IMI 1.0 is an OASIS Standard • Profile of WS-Federation • Requires a browser extension • Profile for LoA 1 - 3 • http://www.idmanagement.gov/documents/ICAM_IMI_10_Profile.pdf

4. IMI Profile • Token type • SAML 1.1 (SAML 2.0 and Zero Knowledge will be added later) • IdP issued tokens only. (Self issued p-card tokens will be a separate profile) • Card Authentication • Username/Password • X.509 (Includes PIV and CAC Cards) • Personal Card • Kerberos token

5. Private Personal Identifier • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier • LoA Claims • http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assuranclevel1 • http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assuranclevel2 • http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assuranclevel3 • Audience Restriction • RP must be a SSL protected endpoint • The SAML token is audience restricted and encrypted with the public key of the RP by the issuer.

7. The IMI logon process Service Provider Requests Identity CardSpace Identity Selector pops up Token is built by Identity Selector(with Identity Provider) Token sent to client Output sent to client

8. User Experience • No WAYF • The RP expresses a Authorization Policy in the page markup • A smart client matches the policy against available credentials • The Client remembers what credentials the user has presented in the past.

9. openID • openID 2.0 is a openID Foindation (OIDF) spec • openID discovery XRDS is a OASIS XRI-TC spec • Profile for LoA 1 • http://www.idmanagement.gov/documents/ICAM_OpenID20Profile.pdf

10. The OpenID login process

11. OpenID Profile mitigations • Assertion reuse • Assertions include a timestamp and a nonce which is checked by the RP. The RP keeps track of assertions that were consumed • Assertion manufacture/modification • IdPs digitally sign assertion, or assertion is transmitted over TLS/SSL where the RP authenticates the IdP via a HMAC shared secret. • Assertion redirect • The signed assertion includes the identity (return_to) of the RP for whom it was generated, and the RP verifies it.

12. Identifiers • Must be Pair-wise Pseudonymous by RP • The pseudonym is used to identify the user to the RP in a way that protects the user's privacy by preventing correlation among RPs. The RP is identified by its realm. • Must use Directed identity.

13. Associations • Must be over SSL • Should be HMAC-SHA256 • The IdP shall expire associations older than 24h • The IdP shall not reuse associations between RPs • The RP must key association handles by IdP

14. OpenID Provider Authentication Policy (PAPE) • Authentication Policies • Used by RPs to request aspects of a profile • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier • Maximum Authentication Age • Used to guarantee a fresh interactive login.

15. Relying Party Discovery • The RP MUST publish an eXtensible Resource Descriptor Sequence (XRDS) discovery document for its realm per [OpenID 2.0] Section 13. • The XRDS MUST be published at the URL matching the realm. • The URI for the XRDS document that is discovered via Yadis MUST have an https: scheme. • The IdP MUST perform RP discovery and return_to validation per [OpenID 2.0] Section 9.2.1. • If return_to validation fails, the IdP MUST return an error, or the IdP MAY present an error message and discontinue the OpenID authentication process.

16. Assertion Verification • The RP MUST verify that all of the following fields (without the "openid." prefix prepended) are included in the IdP signature: op_endpoint, return_to, response_nonce, assoc_handle, claimed_id, and identity. • All OpenID extensions MUST be signed by the IdP. • The RP MUST check the openid.response_nonce to make sure that an assertion from the IdP with this nonce has not already been used. • It is RECOMMENDED that the RP set a restriction on the amount of elapsed time from the timestamp in the nonce until receipt. • The RP MUST check the return_to value in the assertion to verify that the assertion was produced for the RP.

17. Assertion Verification • The openid.identity and openid.claimed_id MUST be the same with the exception of a fragment that may be appended to the openid.claimed_id. • The RP MAY use "Direct Verification" to validate the assertion when: • The IdP includes an openid.invalidate_handle indicating that the association has expired. • The IdP sends an unsolicited assertion

18. Security Considerations • TLS/SSLv3 MUST be used at all endpoints, discovery redirects, and the URI of the XRDS document. • The RP SHOULD negotiate a cipher suite that includes either Triple Data Encryption Standard (3DES) or Advanced Encryption Standard (AES) during the SSL/TSL handshake. • NIST encourages use of the faster and stronger AES algorithm. • The RP MUST verify that the IdP is authorized LOA 1 IdP through verification of URL endpoints and server certificates during discovery and Direct Communication (see [OpenID 2.0] Section 5.1). • During Direct Communication, the RP MUST check the revocation status of the IdP server certificate.

19. Security Considerations • The RP and IdP SHOULD employ frame busting techniques to avoid possible eavesdropping by a third-party web site, and cross site request forgery. • The RP MUST reject any assertion where openid.ns is other than http://specs.openid.net/auth/2.0.

20. Questions? jbradley@mac.com