openid & information card profiles for icam john bradley [email protected]
TRANSCRIPT
openID & Information openID & Information Card Card Profiles for ICAMProfiles for ICAMJohn BradleyJohn Bradley
http://thread-safe.net
http://test-id.org
Information Card (IMI)Information Card (IMI)
IMI 1.0 is an OASIS StandardIMI 1.0 is an OASIS Standard
Profile of WS-FederationProfile of WS-Federation
Requires a browser extensionRequires a browser extension
Profile for LoA 1 - 3Profile for LoA 1 - 3
http://www.idmanagement.gov/documents/http://www.idmanagement.gov/documents/ICAM_IMI_10_Profile.pdfICAM_IMI_10_Profile.pdf
openIDopenID
openID 2.0 is a openID Foindation (OIDF) specopenID 2.0 is a openID Foindation (OIDF) spec
openID discovery XRDS is a OASIS XRI-TC specopenID discovery XRDS is a OASIS XRI-TC spec
Profile for LoA 1Profile for LoA 1
http://www.idmanagement.gov/documents/http://www.idmanagement.gov/documents/ICAM_OpenID20Profile.pdfICAM_OpenID20Profile.pdf
Authentication Authentication ProcessProcess
Attacks/ThreatsAttacks/Threats
Threat Resistance Threat Resistance Requirements Requirements
Level Level 11
Level Level 22
Level Level 33
Level Level 44
Session hijackingSession hijacking NoNo YesYes YesYes YesYes
EavesdroppingEavesdropping NoNo YesYes YesYes YesYes
Phishing/pharming(verifier Phishing/pharming(verifier impersonation)impersonation) NoNo NoNo YesYes YesYes
Man in the middleMan in the middle NoNo WeakWeak WeakWeak StrongStrong
Denial of service/floodingDenial of service/flooding NoNo NoNo NoNo NoNo
Out of ScopeOut of Scope
Verification of assertion attributesVerification of assertion attributes
IMI ProfileIMI Profile
Token typeToken type
SAML 1.1 (SAML 2.0 and Zero Knowledge will be added later) 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 IdP issued tokens only. (Self issued p-card tokens will be a separate profile)profile)
Audience RestrictionAudience Restriction
RP must be a SSL protected endpointRP must be a SSL protected endpoint
The SAML token is audience restricted and encrypted with the The SAML token is audience restricted and encrypted with the public key of the RP by the issuer.public key of the RP by the issuer.
Private Personal IdentifierPrivate Personal Identifier
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifierprivatepersonalidentifier
LoA ClaimsLoA Claims
http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assuranclevel1http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assuranclevel1
http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assuranclevel2http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assuranclevel2
http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assuranclevel3http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assuranclevel3
Card AuthenticationCard Authentication
Username/PasswordUsername/Password
X.509X.509
Personal CardPersonal Card
Kerberos token Kerberos token
OpenID Profile OpenID Profile mitigationsmitigations
Assertion reuseAssertion reuse
Assertions include a timestamp and a nonce which is checked by Assertions include a timestamp and a nonce which is checked by the RP. The RP keeps track of assertions that were consumed the RP. The RP keeps track of assertions that were consumed
Assertion manufacture/modificationAssertion manufacture/modification
IdPs digitally sign assertion, or assertion is transmitted over TLS/SSL IdPs digitally sign assertion, or assertion is transmitted over TLS/SSL where the RP authenticates the IdP via a HMAC shared secret.where the RP authenticates the IdP via a HMAC shared secret.
Assertion redirectAssertion redirect
The signed assertion includes the identity (return_to) of the RP for The signed assertion includes the identity (return_to) of the RP for whom it was generated, and the RP verifies it.whom it was generated, and the RP verifies it.
IdentifiersIdentifiers
Must be Pair-wise Pseudonymous by RPMust be Pair-wise Pseudonymous by RP
The pseudonym is used to identify the user The pseudonym is used to identify the user to the RP in a way that protects the user's to the RP in a way that protects the user's privacy by preventing correlation among RPs. privacy by preventing correlation among RPs. The RP is identified by its realm. The RP is identified by its realm.
Must use Directed identity.Must use Directed identity.
AssociationsAssociations
Must be over SSLMust be over SSL
Should be HMAC-SHA256 Should be HMAC-SHA256
The IdP shall expire associations older than The IdP shall expire associations older than 24h24h
The IdP shall not reuse associations between The IdP shall not reuse associations between RPsRPs
The RP must key association handles by IdPThe RP must key association handles by IdP
OpenID Provider OpenID Provider Authentication Policy Authentication Policy (PAPE)(PAPE)
Authentication PoliciesAuthentication Policies
Used by RPs to request aspects of a profileUsed by RPs to request aspects of a profile
http://schemas.xmlsoap.org/ws/2005/05/http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifieridentity/claims/privatepersonalidentifier
Maximum Authentication AgeMaximum Authentication Age
Used to guarantee a fresh interactive login.Used to guarantee a fresh interactive login.
Relying Party DiscoveryRelying Party Discovery
The RP MUST publish an eXtensible Resource Descriptor The RP MUST publish an eXtensible Resource Descriptor Sequence (XRDS) discovery document for its realm per [OpenID Sequence (XRDS) discovery document for its realm per [OpenID 2.0] Section 13. 2.0] Section 13.
The XRDS MUST be published at the URL matching the realm.The XRDS MUST be published at the URL matching the realm.
The URI for the XRDS document that is discovered via Yadis The URI for the XRDS document that is discovered via Yadis MUST have an https: scheme.MUST have an https: scheme.
The IdP MUST perform RP discovery and return_to validation per The IdP MUST perform RP discovery and return_to validation per [OpenID 2.0] Section 9.2.1. [OpenID 2.0] Section 9.2.1.
If return_to validation fails, the IdP MUST return an error, or the IdP If return_to validation fails, the IdP MUST return an error, or the IdP MAY present an error message and discontinue the OpenID MAY present an error message and discontinue the OpenID authentication process.authentication process.
Assertion VerificationAssertion VerificationThe RP MUST verify that all of the following fields The RP MUST verify that all of the following fields (without the "openid." prefix prepended) are included in (without the "openid." prefix prepended) are included in the IdP signature: op_endpoint, return_to, the IdP signature: op_endpoint, return_to, response_nonce, assoc_handle, claimed_id, and identity. response_nonce, assoc_handle, claimed_id, and identity.
All OpenID extensions MUST be signed by the IdP.All OpenID extensions MUST be signed by the IdP.
The RP MUST check the openid.response_nonce to make The RP MUST check the openid.response_nonce to make sure that an assertion from the IdP with this nonce has sure that an assertion from the IdP with this nonce has not already been used. not already been used.
It is RECOMMENDED that the RP set a restriction on the It is RECOMMENDED that the RP set a restriction on the amount of elapsed time from the timestamp in the amount of elapsed time from the timestamp in the nonce until receipt.nonce until receipt.
The RP MUST check the return_to value in the assertion The RP MUST check the return_to value in the assertion to verify that the assertion was produced for the RP.to verify that the assertion was produced for the RP.
Assertion VerificationAssertion Verification
The openid.identity and openid.claimed_id The openid.identity and openid.claimed_id MUST be the same with the exception of a MUST be the same with the exception of a fragment that may be appended to the fragment that may be appended to the openid.claimed_id. openid.claimed_id.
The RP MAY use "Direct Verification" to validate The RP MAY use "Direct Verification" to validate the assertion when:the assertion when:
1.1.The IdP includes an openid.invalidate_handle The IdP includes an openid.invalidate_handle indicating that the association has expired.indicating that the association has expired.
2.2.The IdP sends an unsolicited assertion The IdP sends an unsolicited assertion
Security ConsiderationsSecurity ConsiderationsTLS/SSLv3 MUST be used at all endpoints, discovery TLS/SSLv3 MUST be used at all endpoints, discovery redirects, and the URI of the XRDS document.redirects, and the URI of the XRDS document.
The RP SHOULD negotiate a cipher suite that includes either The RP SHOULD negotiate a cipher suite that includes either Triple Data Encryption Standard (3DES) or Advanced Triple Data Encryption Standard (3DES) or Advanced Encryption Standard (AES) during the SSL/TSL handshake. Encryption Standard (AES) during the SSL/TSL handshake.
NIST encourages use of the faster and stronger AES algorithm.NIST encourages use of the faster and stronger AES algorithm.
The RP MUST verify that the IdP is authorized LOA 1 IdP The RP MUST verify that the IdP is authorized LOA 1 IdP through verification of URL endpoints and server certificates through verification of URL endpoints and server certificates during discovery and Direct Communication (see [OpenID during discovery and Direct Communication (see [OpenID 2.0] Section 5.1).2.0] Section 5.1).
During Direct Communication, the RP MUST check the During Direct Communication, the RP MUST check the revocation status of the IdP server certificate.revocation status of the IdP server certificate.
Security ConsiderationsSecurity Considerations
The RP and IdP SHOULD employ frame busting The RP and IdP SHOULD employ frame busting techniques to avoid possible eavesdropping by techniques to avoid possible eavesdropping by a third-party web site, and cross site request a third-party web site, and cross site request forgery.forgery.
The RP MUST reject any assertion where The RP MUST reject any assertion where openid.ns is other than openid.ns is other than http://specs.openid.net/auth/2.0http://specs.openid.net/auth/2.0. .
openID historyopenID history
May 2005 invented by Brad Fitzpatric at May 2005 invented by Brad Fitzpatric at SixApart (LiveJournal)SixApart (LiveJournal)
Oct 2005 XRDS Oct 2005 XRDS
March 2006 Simple Registration 1.0 (JainRain)March 2006 Simple Registration 1.0 (JainRain)
May 2006 openID 1.1May 2006 openID 1.1
Dec 2007 openID 2.0 and Atribute Exchange Dec 2007 openID 2.0 and Atribute Exchange 1.01.0
openID ProvidersopenID ProvidersGoogleGoogle
YahooYahoo
AOL AOL
MySpaceMySpace
PayPalPayPal
JanRainJanRain
Orange (France Telecom)Orange (France Telecom)
Facebook (soon)Facebook (soon)
openID Relying PartysopenID Relying Partys
FaceBookFaceBook
MapQuest (AOL)MapQuest (AOL)
PlaxoPlaxo
Blogger (Google)Blogger (Google)
TypePad (Six Apart)TypePad (Six Apart)