COMMAND

    IE

SYSTEMS AFFECTED

    IE 5.x

PROBLEM

    Dave  Zwieback  found  following.   A  combination of expired HTTP
    password (for instance an expired SecurID token code) and the  302
    HTTP status code (Moved Temporarily) breaks the IE  authentication
    mechanism.   After  the  password  expires  and  the user tries to
    retrieve  a  page,  IE  prompts  the  user  for  the new password.
    However, if IE receives a 302  Status Code instead of a 200  after
    a  successful  HTTP  authentication,  it  attempts to retrieve the
    moved page with the OLD (cached and expired) password.  When  this
    fails, IE prompts  the user for  the new password,  retrieves this
    page successfully, but then goes on to retrieve the next page  (or
    page  element)  with  the  old  password. This behavior repeats ad
    infinitum,  or  until  the  SecurID  token  is  locked because ACE
    detects a replay or simultaneous authentication attack.

    This was tested with IE 5.5, but is anecdotally known to break all
    MS version 5 browsers.

    Here's what happens:
    0) User authenticates and accesses  the site normally.  User  then
       stops using the application for a period of time and the user's
       password times out.
    1) User goes back to using the site after the timeout period,  and
       at first IE  attempts to retrieve  a page using  her old cached
       one-time  HTTP   password  (test/0000111111).    Because   this
       password  is   no  longer   valid,  user   receives  HTTP   401
       Unauthorized:

        Authorization: Basic dGVzdDowMDAwMTExMTEx
        GET /application.html HTTP/1.1
        ...
        HTTP/1.0 401 Unauthorized

    2) User  is  prompted  and  puts  in  her new and valid  (SecurID)
       password  (test/0000222222).   User  receives   a  302    Moved
       Temporarily:

        Authorization: Basic dGVzdDowMDAwMjIyMjIy
        GET /page.html HTTP/1.1
        ...
        HTTP/1.1 302 Moved Temporarily
        Location: /timeout.html

    3) BUG:  For some  reason, IE  attempts to  retrieve the page that
       the user is  redirected to (/timeout.html)  using the OLD  HTTP
       password  (test/0000111111).   As   expected,  user  gets   401
       Unauthorized.

        Authorization: Basic dGVzdDowMDAwMTExMTEx
        GET /timeout.html HTTP/1.1
        ...
        401 Unauthorized

    4) Once  again, user  is prompted  and puts  in her (next SecurID)
       HTTP password (test/0000333333).  User receives a 304 Use local
       copy (which is OK since the page has been cached at some  point
       before).

        Authorization: Basic dGVzdDowMDAwMzMzMzMz
        GET /timeout.html HTTP/1.1
        ...
        HTTP/1.1 304 Use local copy

    5) The /timeout.html  page contains a  gif file (spacer.gif)  that
       the IE browser  attempts to retrieve  it (or rather,  IE checks
       to see if it  needs to retrieve it  or it's already in  cache).
       Once again,  IE incorrectly  attempts to  retrieve this element
       using  the  OLD  password  (test/0000111111) and understandably
       gets a 401 Unauthorized error:

        Authorization: Basic dGVzdDowMDAwMTExMTEx
        GET /spacer.gif HTTP/1.1
        ...
        401 Unauthorized

    6) User is prompted and  puts in her (next SecurID)  HTTP password
       (test/0000444444).  User receives  a 304 Use local  copy (which
       is OK since the gif file has been cached).

        Authorization: Basic dGVzdDowMDAwNDQ0NDQ0
        GET /spacer.gif HTTP/1.1
        ...
        HTTP/1.1 304 Use local copy

    At this point, the user goes back to the site, but once again,  IE
    tries   to   retrieve   the   page   using   the   OLD    password
    (test/0000111111)  and  gets  a  401  Unauthorized  error.    This
    continues on  and on  and on  and on  for every  element of  every
    page.  This does not happen in any Netscape browser.

SOLUTION

    This bug has been submitted to Microsoft.