RE: Logout

A stupid mistake made in the previous mail...

Hashing and signing the hash is always required, because it is an
intergral part of the orgin authentication (and data integrity)
validation. Corrected in this mail (I really hope)...

==============================

The obvious thing that is still bad is:
* lack of data integrity validation
* possibility to use a 'ticket' for a (limited) time

The all-in-one solution for this problem is this (maybe can be proposed
as a security extension to HTTP):
[Have a good time reading - 20 kB mail message]


===
Hope I didn't make too much typo errors. and the goal/purpose is
clear...
If you find the word "of" and you think it should not appear here, try
whether "or" fits better. The Dutch "of" is the English "or". I tend to
mix these up sometimes (why I don't know).
===


It relies fully on public-key encryption and looks simuliar to S/MIME.
Note that also proxies should be aware of the use of this feature. Maybe
they can be told using cache-control directive not to manipulate the
message?
I suppose "Cache-control: no-transform" can do the job, but fearing many
proxies will not obey to the directive.

In the case that data confidence is required, using HTTPS is required.

*** REQUIREMENTS
SERVER
* Valid certificate to ensure data integrity and orgin authentication.
* Optional: Hardware hashing and hash signing support, to improve
performance dramatically.
CLIENT
/ None
PROXY/GATEWAY
/ None


*** PART ONE: LOGON
The client should generate a key-pair: private key with according public
key. Next the client should be aware of the user's authentication
credentials (user/pass), and should not save these (without explicitly
asking the user). A HTTP connection can be used to ask the sever for a
SessionID, and at the same time send the user's authentication
credentials and the public key. The client can purpose a lifetime of the
session and for the key. Also the algorithms used must be agreed on by
the client and server. Next the message must be signed, as it provides a
integral part of the orgin authentication and data integrity check.
On a secure channel, in a logon message ONLY, it's not a direct
requirement that the message is signed

In case of the correct credentials are used, and the server agrees on
the methods/protocols used, the server sends his certificate (with
public key) and a session ID.

In reality this can be done over HTTPS, using Digest authentication by
preference.
The client connects to a HTTPS server. Next it sends it's authentication
credentials, with the password hashed (standard digest authentication),
but also includes the public key. No need to sign the message (already
secure channel, note that this is for a logon message only).
Assuming the correct ID and server accepts methods used...
The server responds with a a SessionID, and a certificate. Also the
server specifies where the SessionID should/can be used and gives
servernames with the according certificates, or a group that uses the
same certificate. Also expiration of the sessionID and maybe the key is
included (when using 1024-bit or larger keys, this is not required).
Messsage doesn't need be signed, because the connection is secure.


If the user has a certificate already, this can be used, instead of the
custom-generated key-pair. The entire certificate should be send in this
case, instead of only the public key.
With the appropiate methods, HTTPS will not be needed. This sample used
the old authentication methods in combination with the new features
provided by this security extension.

It is possible to use certificate authentication together with the
user/password authentication, but allowing a higher level of access when
using certificate authentication.

The server must send the certificate to identify itself, as it has no
user/password authentication possibility, but the certificate alone will
be enough for the job.

Note that the rule (for certificates) is that the private key NEVER
leaves the local computer, but only the public key. When I say, send the
certificate, only the certificate with the public key and withOUT the
private key. This applies through all this specification. No confusion
on this...


*** PART TWO: HTTP MESSAGE SIGNING

On unsecure and SECURE channels, we sign the HTTP(S) message.
We need to sign data that can be affected by an adversery in a way that
it will provide a security hole, this includes the Request/Reponse line
and non-modifiable headers. The headers that can be signed are outlined
in section 13.5.2 (Non-modifiable Headers). Also the header including
the sessionID should be signed.

We need a hash of the request/response line, headers and, of course, the
content (data). Next the hash should be signed with the private key. The
public key cannot be used for signing, because the adversery also knows
the public key.

This means the remote side can check the data intigrity. The SessionID
will be used to check the user credentials.

Note that signing is an important operation, as it provides orgin
authentication and data integrity.


*** PART THREE: LOGOFF
Logoff occurs quire simply by expiration of the SessionID or sending an
instruction to the server to logoff. The server can also instruct the
client to logoff.
Logoff includes the expiration of the SessionID and erasing the key-pair
on the client. Most important is the expiration of the SessionID to
succeed on the server-side.
This means LOGOFF IS REQUIRED using either expiration or user-actived
logoff!!!
Logoff messages must be signed.


*** PART FOUR: EXTENDING SESSION LIFETIME
Resons for ending a session without intension of the user is expiration
of the SessionID. Before extending the session, the user should be aware
of it, by asking him/her/it first. Closing the browser should retire the
SessionID and key-pairs and preferably, the server should send a message
to retire the session.

A signed message with this request can be issued to the (original)
authentication server in order to extend the session for a specific time
(maximum limit by the server). The server may refuse. Adding user
credentials again is not needed but may be requested by the server. Also
key rotation or sessionID rotation may be requested/done by the server.


*** PART FIVE: WEAKNESSES/DISADVANTAGES OF THE PROTOCOL
The protocol requires on the strength of the security protocols used.
Known-plaintext attacks are possible, and security protocols used should
be designed to be properly (heavily) protected against this type of
attack. Such attacks can result fast into many known-plaintexts with
there accompanying ciphertext.

Servers require significanly more performance to do the job.

Key- and session-management is required and probably will get more
complex.

Requires browser and server support.

Expire-times should be relatively short (couple minutes), to improve
security. Long expire-times give the adversery a good chance to do
damage. This is because delivery is still not ensured, and thus
retirement of sessions by the user is not garanteed to happen (you can
easily filter such messages out).


*** PART SIX: FEATURES OF THE PROTOCOL
Provides orgin authentication

Provides data integrity

Extended security over existing methods, by eliminating some severe
weaknesses that exist in the cookies-implementation.

Long sessionkeys (256-bits would probably allow you to have almost
certainly unique IDs)

A (e.g. authentication) server can have a different certificate that the
other servers.


*** PART SEVEN: WORK TO DO
- How on chunked transfers
- How to sign headers and the request/response line.
  These probably change due to proxies, gateways, firewalls and such
things.
- .....


*** PART EIGTH: HACKING ATTEMPTS
If a false message was detected that was incorrectly signed, the server
should notify the actual owner of the session of this attempt. It's
recommended to retire the session. On the other hand, the session can
probably continue to exist, because this security is more difficult to
break, than with the cookies.



That was the mail for today...
Hope you like it.

If you have some other suggestions, send them...
maybe some protocol errors, but it probably needs to be reviewed, when
we want to implement such functionality.
Maybe I forget thinks where, I did or didn't think about...



- Joris