openID

1
openID Information Card Profiles for ICAM

• John Bradley
• jbradley_at_mac.com
• http//thread-safe.net
• http//test-id.org

2
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

3
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_OpenID2
  0Profile.pdf

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

• Verification of assertion attributes

6
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)
• 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

• Private Personal Identifier
• http//schemas.xmlsoap.org/ws/2005/05/identity/cla
  ims/privatepersonalidentifier
• LoA Claims
• http//idmanagement.gov/icam/2009/09/imi_1.0_profi
  leassuranclevel1
• http//idmanagement.gov/icam/2009/09/imi_1.0_profi
  leassuranclevel2
• http//idmanagement.gov/icam/2009/09/imi_1.0_profi
  leassuranclevel3
• Card Authentication
• Username/Password
• X.509
• Personal Card
• Kerberos token

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

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

10
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

11
OpenID Provider Authentication Policy (PAPE)

• Authentication Policies
• Used by RPs to request aspects of a profile
• http//schemas.xmlsoap.org/ws/2005/05/identity/cla
  ims/privatepersonalidentifier
• Maximum Authentication Age
• Used to guarantee a fresh interactive login.

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

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

14
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

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

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

17
Questions?
jbradley_at_mac.com
18
openID history

• May 2005 invented by Brad Fitzpatric at SixApart
  (LiveJournal)
• Oct 2005 XRDS
• March 2006 Simple Registration 1.0 (JainRain)
• May 2006 openID 1.1
• Dec 2007 openID 2.0 and Atribute Exchange 1.0

19
openID Providers

• Google
• Yahoo
• AOL
• MySpace
• PayPal
• JanRain
• Orange (France Telecom)
• Facebook (soon)

20
openID Relying Partys

• FaceBook
• MapQuest (AOL)
• Plaxo
• Blogger (Google)
• TypePad (Six Apart)