• UseCases
• DistributedAuthenticationV1

UseCases :: UseCases/DistributedAuthenticationV1

Distributed Authentication using XRI

• obsolete: see UseCases/DistributedAuthenticationV1

• this is still here to preserve some data sharing concepts not in the Dist Auth use case

Goals

• User wants to join a community (SP)
• SP wants to authenticate User
  • and access some information about User (say, first and last name)
• eliminate requirement of clunky "shared secret" system, replacing it with XRI resolution based authentication

Notes

1. in this use case, the i-broker is serving two roles:
   1. i-name authentication
   2. XDI authorization and data access
2. passwords are encoded in the hashes sent between sites
   • this eliminates the need for, and has equivalent security to, shared secrets
   • the design lends itself to pluggable authentication mechanisms, such that (e.g.) a public key authentication provider could be used
   • when SP athenticates, SP must store the authentication token (sp_xsid) its i-broker returns it. The token must be passed to SP-ib with every request. This mechanism replaces the role of cookies in user authentication.
3. we expect all service providers the have i-names and passwords
   • thus service providers have an associated i-broker that provides them with their i-name
4. service providers don't want to be data hosts of XDI data, as then they will have to accept queries for that data from other sites
   • thus (in general) service providers will have local synchronized caches of XDI data
   • in either case, the service provider will use an XDI service to host authoritative or maintain cached XDI data
   • this XDI service (data hosting/cacheling) can be provided by the service provider's i-broker, or by a stripped down, local i-broker that is part of the service provider's "SPIT" client

Actors

• User - a user to be authenticated (with i-name '=user')

• User-ib - User's i-broker (with i-name '@user-ib')

• SP - service provider (with i-name '@sp' and password 'sp_password')

• SP-ib - SP's i-broker (with i-name '@sp-ib' and password 'spib_password)

Preconditions

1. User has an i-name (=user) and an account at User-ib
2. SP has an i-name (@sp) and an account at SP-ib

Steps

Notes

• these steps under serious construction

• there are too many complicated steps here - break this into several use cases...

• the numbering no longer matches the sequence diagram

1. User enters =user into create account form on SP
2. SP authenticates on SP-ib (only needs to happen once per time period/session)
   • args:

     • sp_time -- time in seconds (milliseconds?) to prevent replay attacks

     • sp_hash == sha1( sp_password, sp_time ) -- SP's encoded password

   • SP-ib uses sp_hash to authenticate SP directly
   • do we also need a random token for additional security?
3. SP-ib returns sp_xsid - a session id that authenticates the sender

   • is sp_xsid really necessary, as one could pass (@sp, time, sp_hash) every time?

   • SP stores for future authentications/sessions (until SP-ib times it out or it is otherwise invalidated)

   • for added security, in each subsequent call by SP, sp_xsid could itself be passed in a hash (sha1(time, sp_xsid)) to further prevent to possibility of replay attacks

4. SP asks SP-ib for information stored about @sp*members*(=user)
   • args:

     1. @sp*members*(=user) -- the address of the member account to look for

     2. @sp -- the i-name of the requesting service provider

     3. sp_time -- time in seconds (milliseconds?) to prevent replay attacks

     4. sp_hash == sha1( sp_xsid, sp_time ) -- SP's encoded session id

     5. contract == xri://@sp/($assoc)/=user*($link)*(=user/($contract)/private))*($get)*(=user/(+BizCard)/Basic)

        • a contract that SP is willing to sign that describes access to and TOS for the requested data (this example is probably mal-formed)
        • note that when asked, User (or User-ib) may counter with a contract of her own

     6. rtnURL -- when contract complete, User-ib will redirect User to rtnURL

   • if found (=user is already a member) see mike's step #4, below

     1. SP-ib returns ok( =user, sp_xsid) to SP

     2. SP re-directs to User-ib (web SAML profile) for User authentication

     3. jump to step 14

   • else...

5. SP-ib initiates request for User's data from User-ib
   • args:

     1. contract -- the contract covering the data (e.g., membership requirements) the SP-ib wants to get from User-ib

     2. @sp -- the goal is to authenticate SP to User-ib

     3. sp_time -- (passed through from above)

     4. sp_hash -- (passed through from above)

     5. rtnURL -- (passed through from above)

6. User-ib authenticates @sp (it has SP's password encoded in sp_hash)
7. SP-ib returns OK and a session id (spib_xsid)
8. User-ib verifies the session id
   • at this point, SP has been authenticated to User-ib
9. User-ib presents the contract to User
10. User accepts the contract
11. User-ib returns the now mutually signed contract to SP-ib
12. SP-ib does an XDI GET on the data referenced by the contract
13. User-ib returns the data for SP-ib to cache
14. SP-ib reports to SP that User is now a member
15. SP does and XDI GET on User's data
16. SP-ib returns the data
17. SP congratulates User on new membership

Security Consideration

1. this use case describes a password based system where the password is stored on the (XRI) client service provider
   1. any sysadmin with access to the code will also have access to this password
   2. the same holds true for the shared secret system previously implemented
2. a full security analysis needs to be done

See Also

• Mike and Fen's whiteboard notes

• ladder diagram

Steps v2 (from Mike)

1. User enters =user into create account form on SP
2. SP authenticates on SP-ib
   1. args:

      • @sp -- the goal is to authenticate SP to User-ib

      • sp_time -- time in seconds (milliseconds?) to prevent replay attacks

      • sp_hash == sha1( sp_password, sp_time ) -- SP's encoded password

        • SP-ib uses sp_hash to authenticate SP directly
        • do we also need a random token for additional security?
3. SP-ib returns sp_xsid which SP stores in a way that makes it accessible to throughout the User session
   • SP should store sp_xsid for life of the authentication and use it for User1, User2, User3 ...

4. SP asks SP-ib for information stored about @sp*members*(=user) (is there an explicit reference to a particular contract? I think so.)

   • if contract and data found, SP re-directs User to User-ib for user authentication. User interacts with SP (exit Steps).

   • if only contract, no data, found jump to [XDI_GET]

   • else SP requires a signed contract with User and initiates contract process:
     1. SP-ib returns unsigned contract to SP
     2. SP redirects User to User-ib with apply(contract). args:

        • @sp -- the goal is to authenticate SP to User-ib

        • sp_xsid -- it's authentication token (similar to the xri_xsid token users pass between SP's)

        • contract -- the contract covering the data the SP-ib wants to get from User-ib

        • rtnURL -- when contract complete, User-ib will redirect User to rtnURL

5. User-ib authenticates @sp
   1. User-ib resolves @sp to SP-ib
   2. User-ib sends sp_verify request to SP-ib with args:
      • @sp
      • sp_xsid
   3. SP-ib returns true if SP-ib has a valid sp_xsid for @sp
6. User-ib presents the contract to User
7. User accepts the contract
   • submits any missing information required or optional in contract
   • submits changes to existing data
8. User-ib returns the now mutually signed contract to SP
9. SP stores signed contract with SP-ib

10. SP asks SP-ib for information stored about @sp*members*(=user) regarding contract X (repeat of step prior to contract initiation)

11. [XDI_GET] SP-ib does XDI GET on the data referenced by the contract

12. User-ib returns the data for SP-ib to cache
13. SP-ib returns the data to SP
14. SP congratulates User on new membership