OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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-architecture-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)



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC