Payment in Identity Federations David J. Lutz Universitaet Stuttgart

Outline Problem Statement Enhanced Federation Architecture Security Issues Protocol Elements Conclusion

Roaming Student

Solution for Services: Federation

Problem: Payment

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

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

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

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

Payment Provider

Payment Statement Issuing

Payment

Payment Statement Reimbursement

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 Document ID saml-sec-consider-2.0-os. security/saml/v2.0/, last visited

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

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

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.

Protocol Enhancements SAML Elements –Request –Response Assertions –Statements

Example Response Payment Provider Signature

Example Response (cont.) Payment Provider Signature NotBefore=" T20:03:25.32Z“ 30 NotOnOrAfter=" T20:03:25.33Z“ 31 /> EUR

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

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

Questions? Any Questions Thank You!