Slide 1

Payment in Identity Federations David J. Lutz Universitaet Stuttgart Slide 2 Outline Problem Statement Enhanced Federation Architecture Security Issues Protocol Elements Conclusion Slide 3 Roaming Student Slide 4 Solution for Services: Federation Slide 5 Problem: Payment Slide 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 Slide 7 Traditional Federation Architecture User Wishes Access to restricted SP Resources Has Identity Information stored at IdP Identity Provider Authenticates User Sends Users ID Information to SPs Service Provider Offers restricted Services to authorized Users Request Users ID Information at IdP Slide 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 Consumers ID Information to SPs Service Provider Offers restricted Services to authorized Consumers Request Consumers ID Information at IdP Accepts Payment Statements from PP Payment Provider Hosts Consumers Payment Accout Issues, Validates and Reimburses Payment Statements Slide 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 Slide 10 Payment Provider Slide 11 Payment Statement Issuing Slide 12 Payment Slide 13 Payment Statement Reimbursement Slide 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. Slide 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 Slide 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 Slide 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 Statements 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 Payers ID: Consumer must be identified for Account charging or when he/she acts maliciously. Payers Signature: Non-Repudiation when the paying Consumers 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 Statements Validity. Slide 18 Protocol Enhancements SAML Elements Request Response Assertions Statements Slide 19 Example Response 1 10 https://payment.provider.com/assertions 11 12 Payment Provider Signature 14 15 16 17 Slide 2032 33 34 2.58 35 36 37 38 EUR 39 40 41 42 43"> 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 Slide 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 Slide 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 Slide 23 Questions? lutz@rus.uni-stuttgart.de Any Questions Thank You!