[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: FW: Shibb Artifact: some specifics
I have scheduled a discussion of the Shib browser profile for our con-call on Thursday, August 9. Here are some notes from Marlena. -----Original Message----- From: Marlena Erdos [mailto:marlena@us.ibm.com] Sent: Tuesday, July 17, 2001 10:38 PM To: security-services@lists.oasis-open.org Cc: cantor.2@osu.edu Subject: Shibb Artifact: some specifics As promised here is is the an example of the handle package (aka "artifact") we use in Shibboleth. You might want to read my initial mail on the subject of "Artifacts..." before reading this. I'll follow the example with an explanation of the parameters. The Shibb Architecture doc has a much fuller discussion. Its URL is: http://middleware.internet2.edu/shibboleth/docs/draft-erdos-shibboleth-archi tecture-01.pdf Section 5.2.1.2 has the discussion of our "artifact" (though it may be a bit difficult to read without reading some of the "High Level Architecture" earlier in the doc.) The example and discussion are taken from the arch doc and modified to attempt to remove Shibb specific references. Apologies for the Shibb stuff that might be leaking through ... In the example below, the user is trying to reach "www.CoolResource.com/coolStuff.htm . The contents of the handle package follow as parameters. This URL plus params have been redirected from the user's home organization through the user's browser to the destination: http://www.CoolResource.com/coolStuff.htm? handle=<opaque handle>& ip=9.3.199.2& time=<issue time>& dest_id=rp.coolResource.com& AA_Binding=https%3a//aa.rutgers.edu%3a8888& hs=handle_service.rutgers.org& sig=<base 64 encoding of signature> Parameters Explained/ "handle" is what will be used as the "subject" of a request for an attribute assertion. "ip" is the ip address of the browser. "time" is the time when the handle package was issued. "dest_id" is the PKI name of the relying party. "AA_Binding" is information on how to contact the attribute authority to get an attribute assertion about this user. "hs" is the name of the service (called a "handle service") that issued this handle package. "sig" is the signature of the handle service. Impersonation Countermeasures/ The fields are constructed so that the RP can reduce or eliminate the liklihood of the following impersonation attacks: Stolen handle presentation (user version): If a malicious user (MAL) can find out the real user's handle and associated fields, then MAL could construct a URL with the real user's handle presentation to RP and thus be associated with the original user's handle. Counter-Measure: The fields includes both the user's ip address and the issue time of the handle presentation. The RP should make sure that the issue time field is very close to "now" to reduce the window of opportuity for this attack. And it can make sure that the IP address of the presenting user matches the IP address in the client address field. (While IP addresses can be modified, having to have the right IP address is another barrier for an attacker.) These measures make this attack more difficult. Stolen handle presentation (RP version): Since the RP obtain handle presentations from users, a malicious RP could pass on an handle presentation it got from a user to another RP. The second RP would believe the malicious RP to be the user. Counter-Measure: The 'dest_id' field contains the name of the RP that is supposed to receive the handle. An RP receiving a handle presentation should make sure that the 'dest_id' field value matches its own name. This defeats this attack. Forged handle presentation: A malicious entity knowing the handle for a user (perhaps extracted from a handle package), could create a new handle packate and then "be" that user when it contacts a destination. Counter-Measure: The RP should verify that the signer of the handle package is a "legitimate" Handle Server for a known origin institution. It does this by checking the signature on the handle package. The signature check inherently combines an authentication and integrity check. If the initial signature check passes, the RP may at its discretion check for validity of the certificate used in the signature check. (In Shibboleth we'll distribute PKI information about handle services and home organizations to participating sites.) Other/ "Doesn't the signature make it too big?" Answer: Apparently not. Scott Cantor researched the signature aspect of our artifact "package" and presented a good case for why we would be well under typical size limitation (assuming the base URL wasn't especially large). I'll ask Scott to send that info to Bob Morgan (who can send it to the list) as I am just about to leave for vacation. (Scott?) Somewhat hurriedly, Marlena (who still needs to pack) ------------------------------------------------------------------ To unsubscribe from this elist send a message with the single word "unsubscribe" in the body to: security-services-request@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC