Avoiding PAM checks

Karl, Jan,
I have discussed the issue with a number of folks, and that helped me to
better understand how Jan's proposal works.

I'd like to make the following comments, before I leave for vacation (back
at home from 8/16 on, back in the office from 8/25 on):

Just to recap the overall approach: Upon successful authentication of a CIM
request, if the server supports the new feature, it invents a session ID
and sends that back with the CIM response. If the client supports the new
feature, it uses that session ID on subsequent CIM requests. Upon receipt
of a CIM request with such a session ID, the server can decide whether it
trusts the session ID sufficiently at that moment to bypass the
authentication check.

I'm fine with that overall approach, but I kept the description
deliberately high level, because there are some considerations and
requirements:

- It depends very much on the data that makes up the session ID. A
   suggestion from one of our security folks was that the session ID be a
   hash of (userid, timestamp, randon number, underlying SSL session ID).
   It is definitely a requirement that the session ID cannot be calculated
   by an intruder. For example, just using timestamp and userid would
   probably be not sufficient. Keep in mind that the code is open source,
   so the algorithm how exactly the hash is calculated will be known, and
   the secret must be in the data, not in the algorithm. Using the
   underlying SSL session ID for example ensures that the same SSL session
   is still in place. Maybe that is too much of a requirement, but it is
   something that needs to be carefully considered.

- The server must be able to determine the lifetime of the session ID. The
   proposed cookie based approach would probably use the cookie lifetime
   for that, but that could also be done otherwise. Can cookie lifetimes be
   modified by a client? That would be bad. I would have a better feeling
   if the lifetime was encoded in the session ID instead of being a
   separate piece of clear data. Even if the session ID is a hash (which
   cannot be unpacked), the server could remember (in memory) which session
   IDs it has handed out at any point in time, and match the session ID
   with an internal record of it that shows the lifetime.

- The server must be allowed to decide at any point that a normally valid
   session ID is nevertheless dismissed, and that a new session ID is
   created. The server can make that determination based upon nearly
   everything, including suspicuous client behavior with otherwise valid
   requests. If the server dismisses an incoming session ID, it performs
   the normal authentication as if no session ID had been provided by the
   client, and returns a new session ID.

- As a result, the client must always use the session ID returned by the
last response, because the server could have recalculated it.

- how the session ID is transported between client and server, has a number
   of options. It would certainly be some HTTP header. I have seen
   extension headers used for that purpose, it does not necessarily have to
   be a cookie. I find cookies generally suspicious, and don't fully
   understand to what extent HTTP infrastructure (e.g. proxies) can have a
   policy to not allow them, in which case a cookie based approach would be
   limiting in such environments.

- Obviously, it must be optional to support for both client and server.
Just to have it mentioned.

- One important consideration is whether we want it to work with both HTTP
   and HTTPS, and with all HTTP authentication mechanisms. Someone needs to
   draw the matrix of HTTP/HTTPS with supported authentication mechanisms,
   and state for which ones the session ID approach would be supported.
   That may shape the design significantly. For example, if we supported it
   only for HTTPS, the session ID would not need to be encrypted. If we
   also wanted to support it for HTTP, we maybe want to see it encrypted.

- There are sufficient screws and decisions in that whole approach, so that
   we cannot assume this is just an OpenPegasus addition. DSP0200 documents
   all standard HTTP headers that play a role in CIM-XML, and it would need
   to describe this new ability as well. Karl and I are in the CIM-XML WG,
   and it should not take very long, once we have agreed upon the details
   on how to do it.

To me, the open points are:
- how to calculate the session ID. This could be a recommendation for
servers to keep them secure, because it is opaque for clients.
- which mechanism to use to transport the session ID between client and
server.

Andy

Andreas Maier
IBM Senior Technical Staff Member, Systems Management Architecture & Design
IBM Research & Development Laboratory Boeblingen, Germany
[email protected], +49-7031-16-3654
________________________________________________________________________
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294