open ID Information Card Profiles for ICAM

open. ID & Information Card Profiles for ICAM John Bradley jbradley@mac. com http: //thread-safe. net http: //test-id. org

Information Card (IMI) IMI 1. 0 is an OASIS Standard Profile of WS-Federation Requires a browser extension Profile for Lo. A 1 - 3 http: //www. idmanagement. gov/documents/ICAM_IMI _10_Profile. pdf

open. ID 2. 0 is a open. ID Foindation (OIDF) spec open. ID discovery XRDS is a OASIS XRI-TC spec Profile for Lo. A 1 http: //www. idmanagement. gov/documents/ICAM_Ope n. ID 20 Profile. pdf

Authentication Process Attacks/Threats Threat Resistance Requirements Level 1 Level 2 Level 4 3 Session hijacking No Yes Yes Eavesdropping No Yes Yes Phishing/pharming(verifier impersonation) No No Yes Man in the middle No Denial of service/flooding No Weak Strong No No No

Out of Scope Verification of assertion attributes

IMI Profile Token type SAML 1. 1 (SAML 2. 0 and Zero Knowledge will be added later) Id. P issued tokens only. (Self issued p-card tokens will be a separate profile) 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.

Private Personal Identifier http: //schemas. xmlsoap. org/ws/2005/05/identity/claims/privatepersonalidentifi er Lo. A Claims http: //idmanagement. gov/icam/2009/09/imi_1. 0_profile#assuranclevel 1 http: //idmanagement. gov/icam/2009/09/imi_1. 0_profile#assuranclevel 2 http: //idmanagement. gov/icam/2009/09/imi_1. 0_profile#assuranclevel 3 Card Authentication Username/Password X. 509 Personal Card Kerberos token

Open. ID 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 Id. Ps digitally sign assertion, or assertion is transmitted over TLS/SSL where the RP authenticates the Id. P 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.

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.

Associations Must be over SSL Should be HMAC-SHA 256 The Id. P shall expire associations older than 24 h The Id. P shall not reuse associations between RPs The RP must key association handles by Id. P

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

Relying Party Discovery The RP MUST publish an e. Xtensible Resource Descriptor Sequence (XRDS) discovery document for its realm per [Open. ID 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 Id. P MUST perform RP discovery and return_to validation per [Open. ID 2. 0] Section 9. 2. 1. If return_to validation fails, the Id. P MUST return an error, or the Id. P MAY present an error message and discontinue the Open. ID authentication process.

Assertion Verification The RP MUST verify that all of the following fields (without the "openid. " prefix prepended) are included in the Id. P signature: op_endpoint, return_to, response_nonce, assoc_handle, claimed_id, and identity. All Open. ID extensions MUST be signed by the Id. P. The RP MUST check the openid. response_nonce to make sure that an assertion from the Id. P 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.

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: 1. The Id. P includes an openid. invalidate_handle indicating that the association has expired. 2. The Id. P sends an unsolicited assertion

Security Considerations TLS/SSLv 3 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 (3 DES) 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 Id. P is authorized LOA 1 Id. P through verification of URL endpoints and server certificates during discovery and Direct Communication (see [Open. ID 2. 0] Section 5. 1). During Direct Communication, the RP MUST check the revocation status of the Id. P server certificate.

Security Considerations The RP and Id. P 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.

Questions? jbradley@mac. com

open. ID history May 2005 invented by Brad Fitzpatric at Six. Apart (Live. Journal) Oct 2005 XRDS March 2006 Simple Registration 1. 0 (Jain. Rain) May 2006 open. ID 1. 1 Dec 2007 open. ID 2. 0 and Atribute Exchange 1. 0

open. ID Providers Google Yahoo AOL My. Space Pay. Pal Jan. Rain Orange (France Telecom) Facebook (soon)

open. ID Relying Partys Face. Book Map. Quest (AOL) Plaxo Blogger (Google) Type. Pad (Six Apart)