1. Payment in Identity Federations David J. Lutz Universitaet Stuttgart

2. Outline Problem Statement Enhanced Federation Architecture Security Issues Protocol Elements Conclusion

3. Roaming Student

4. Solution for Services: Federation

5. Problem: Payment

6. Solution for Payment Local Payment Account –Easy to handle –Administration Overhead at Universities –Administration Overhead for roaming Students Global Solution –Paypal –Credit Cards –Easy to use –Administration overhead at Universities Federation Based Payment –Payment Solution integrated into Federation –Does not exist

7. Traditional Federation Architecture User –Wishes Access to restricted SP Resources –Has Identity Information stored at IdP Identity Provider –Authenticates User –Sends User‘s ID Information to SPs Service Provider –Offers restricted Services to authorized Users –Request User‘s ID Information at IdP

8. Payment Federation Archtiecture User/Consumer –Wishes Access to restricted SP Resources –Has ID Information stored at IdP –Has Payment Accout at PP Identity Provider –Authenticates Consumer –Sends Consumer‘s ID Information to SPs Service Provider –Offers restricted Services to authorized Consumers –Request Consumer‘s ID Information at IdP –Accepts Payment Statements from PP Payment Provider –Hosts Consumer‘s Payment Accout –Issues, Validates and Reimburses Payment Statements

9. Payment Provider Tasks –Payment Statement Generation –Payment Statement Validation –Payment Statement Reimbursement Connections –Consumer: Statement Generation –Identity Provider: Consumer AA –Service Provider: Statement Validation –Service Provider: Statement Reimbursement

10. Payment Provider

11. Payment Statement Issuing

12. Payment

13. Payment Statement Reimbursement

14. Security Issues Lots of „General Attacks“ –Attacks against Infrastructure and Communication Types: MitM, DOS, Eavesdropping, etc. –Attacks against SAML See: [1] Overspending –Statement must not be used for Payment more than once Data-Tampering –Statement must not be changed, e.g., larger Amount, etc. [1]: F. Hirsch, R. Philpott, and E. Maler: “Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0”. March 2005. Document ID saml-sec-consider-2.0-os. http://docs.oasis-open.org/ security/saml/v2.0/, last visited 14.04.2009.

15. Hardware based Solutions Each Participant has secured Hardware –Non-modifiable Private Key –Signes Statement –Secures Application: The Payment Application cannot be modified without Detection –Controls Data: All Payment Statements are controlled by the Hardware; no Statement Modification without Detection Avoidance of Overspending –Statement Lifetime and ID are stored –Application sends Payment Statement only if Data was not sent before Avoidance of Tampering –Payment Statements are controlled by Hardware –Tampering is detected

16. Software based Solution PP stores Payment Statement Information during Generation Consumer pays using Payment Statements SP requests Payment Statement Validation at PP –SP or PP checks PP Signature –PP checks if Payment Statement has not been used before –PP marks Payment Statement as being spent –PP informs SP about the Validation Result Reimbursement: –SP requests Reimbursement at PP –PP validates Payment Statement –PP reimburses Payment Statement and informs SP Weak Software Solution: –SP requests no Validation –SP requests Reimbursement –High level of trust between SP and Consumer

17. Required Information Hardware based Solution –Amount: PP, SP, C must know the Amount conveyed –Currency: PP, SP, C must know the Currency conveyed –PP ID: SP must know where to reimburse the Statement –Secured Hardware Signature: Hardware Signature provides Assuredness that the Payment Statement was never modified or maliciously misused. –Payment Data ID: Needed by the securing Hardware to detect misuse. –Payment Data Lifetime: Needed to control the Statement‘s validity. Software based Solution –Amount: PP, SP, C must know the Amount conveyed –Currency: PP, SP, C must know the Currency conveyed –Payment Provider ID: SP must know where to reimburse and validate the Statement –Payment Provider Signature: Non-Repudiation about the issuing PP –Payer’s ID: Consumer must be identified for Account charging or when he/she acts maliciously. –Payer’s Signature: Non-Repudiation when the paying Consumer’s Account is debited or when he/she acts maliciously. –Payment Data ID: Needed by the Payment Provider to detect Misuse. –Payment Data Lifetime: Needed to control the Statement‘s Validity.

18. Protocol Enhancements SAML Elements –Request –Response Assertions –Statements

19. Example Response 1 10 https://payment.provider.com/assertions 11 12 Payment Provider Signature 14 15 16 17

20. Example Response (cont.) 18 19 23 https://payment.provider.com/ 24 25 Payment Provider Signature 27 28 29 NotBefore="2008-09-15T20:03:25.32Z“ 30 NotOnOrAfter="2009-09-15T20:03:25.33Z“ 31 /> 32 33 34 2.58 35 36 37 38 EUR 39 40 41 42 43

21. Information Overview HardwareSoftwareExample Amount 33 – 36 Currency 37 – 40 PP ID 23 HW Signature12 – 14; 25 – 27 PP Signature25 – 27 Sender Signature12 – 14 Payment Data ID 21 Payment Data Lifetime 28 – 31

22. Conclusion Missing integrated Payment Solution for Identity Federations –Micropayment Problem –Little attractive for commercial Service Providers Especially small SPs Solution: Payment using SAML –Usage of already established Language –Not only transmission of Payment Information –Up to High Security Hardware; Strong Software; Weak Software –Few Modification needed

23. Questions? lutz@rus.uni-stuttgart.de Any Questions Thank You!