RE: Shibb Artifact: some specifics (long message)

["Mishra, Prateek" <pmishra@netegrity.com>]

Marlena,

I spent some time reviewing the Shib Architecture 
(draft-erdos-shibboleth-architecture-01), your e-mail
on this thread and the current and (proposed) SAML
web browser profiles. My comments on SAML reflect
the text and schema in core-12. Here are a few comments on
the similarities and differences of the two approaches.

---------------------------------------------------------------
(1) AuthenticationAssertion and AQHP

In SAML, successful authentication is expressed in the 
form of a AuthenticationAssertion. An AuthenticationAssertion
captures information such as authentication technique
used, issuer name and issue time instant, 
IP address of the authenticating entity (authenticatee?),
audience to which the assertion is directed, validity period
of the assertion etc. 

Note that a single authentication act between a
user and a security engine may be mapped to
many different SAML AuthenticationAssertions by a security
engine at different times. 
It is important not to identify a SAML assertion with a
user's session or with some other pre-defined notion of lifetime.

The corresponding notion in Shib is the AQHP. The AQHP
does not directly model successful authentication, 
instead it represents availability of "other" attribute
information concerning an authenticated subject. It provides
sufficient structure so as to deter certain attacks, while
at the same time providing an opaque handle for access to 
subject attributes. Some of the information contained in 
the AQHP include:

(1) AQHP_hs (issuing handle service -- something like SAML issuer)
(2) AQHP_ip (ip address of browser process)
(3) AQHP_time (response issue time --- similar to SAML issue instant)
(4) AQHP_sig (digital signature --- SAML will support signing of assertions)


(2) In Shib, the AQHP is conveyed from AP to RP on the URL line;
in SAML, the web browser profiles describe the conveyance of
assertions from RP to AP.

Two profiles are developed:
  (1) Profile1: SAML Artifact conveyed on URL-line: 
      (4-byte partner id ; 8 byte opaque assertion handle)
      The AP "pulls" the assertion from the RP; this step
      MUST be mutually authenticated (SSL or digital signing).

  (2) Profile2: SAML assertion packaged in POST body 
           When used in this context, the assertion must be signed.



(3) One significant piece of your e-mail was a security analysis of the 
Shib handle presentation. I will now attempt to apply this analsis
to the corresponding SAML structures. In some cases, I will need
to respin the attack to correspond more closely to the 
SAML case.

>>
>>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.

COMMENT: exactly the same counter-measure is available in the 
SAML Profile1 and Profile2. AuthenticationAssertions include the 
authenticatee IP address, issue instant, and validity period. 
There is an assumption in both frameworks that the AP and RP
clocks are somewhat synchronized: the RP checks to see that the
current time lies within the validity period of the 
AuthenticationAssertion. The RP should also check the IP address
of the authenticatee and compare to the IP address contained
in the assertion. 

A further counter-measure is described in Profile1 and Profile2;
a one-use policy is mandated and must be implemented (by the
AP for Profile1, by the RP for Profile2). This addresses 
statefulness within the browser (AQHP, SAML Artifact, POST body
are all contained within browser state for indefinite
time periods) and the fact that an
individual browser from a fixed IP address may get "re-used"
after a short period of time. 


>>
>>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.
>>

COMMENT: The SAML <AudienceRestrictionConditionType>  
addresses this issue. An element of this type is used
to direct the assertion to one or more targets.

One ommission in bindings 0.4 is that it does
clearly explain that AuthenticationAssertions delivered thru
the web browser profile need to be directed unambiguously to
an audience consisting precisely of the RP. 
Otherwise, we will have the vulnerability described above.


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

I am not sure what the analog of this attack in the SAML case. 
Essentially, this attack refers to the situation where an entire
AQHP is being forged. The only equivalent in SAML is forging an
entire assertion. This is prevented in SAML by use of (I) mutual
authentication (Profile1) (II) use of digital signing (Profile2).
The RP must check the authentication ``context'' of the assertion
and ensure that it matches the issuer information.


(4) The question of the size of AQHP is an issue that I think
remains open. Maybe it will not be an issue in practice but
I would need more information to be comfortable with it.

Assume that we are using a 1024-bit modulus(128-byte)
for the signature.
In other words, the computed signature has size bounded by
128 bytes. This needs to be base-64 encoded giving us 172 bytes.
To this we add the additional fields of the AQHP (I dont have an
exact figure from the shib draft) but my guess is that there is
another 50 bytes there (handle, time, AQHP_hs) which must also
be base-64 encoded which gives us 66 bytes. So we are upto approx.
250 bytes for the AQHP. Upper limit on URL's is 2K of which good sized
portions
are used up by query string and path components, especially when
utilizing widely used page generation systems (JSP, ASP etc). 

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


- prateek