RE: Experimental implementation of SimpleMD5

>This implementation has two interesting features which are not
>part of the specification but are made possible by the flexibility of
>the proposed method.
>
>1. Timestamps:  The maintainer can set the time period for which
>   authentication granted the client is valid.  After this time period
>   the client will have to re-authenticate.   The time period can be
>   set to any number of seconds (or be unlimited) and is accurate to
>   within 1% of the specified value.  The timestamp is encoded in the
>  "opaque" header field (see the specification).

The Shen/S-HTTP system also uses timestamps. These have the difficulty
of clock synchronisation but remove the problem of keeping track of challenge
/response pairs which is a problem if the connection cannot be kept open.
This is especially a problem through gateways.

>2. IP address stamps:  The IP address (or the IP address of the
>   client's proxy) is encoded in the "opaque" header field.  This means
>   that a replay attack would have to spoof the server with a false
>   IP address.

How is the IP address of the proxy known?

Using the IP address is very unsatisfactory since it adds little real 
security but a lot of inconvenience.


Also I really don't like having a system that only authenticates the fact
that a transaction has been authorised but does not authenticate which
particular transaction is authorised.

Extension of the system to perform a digest of the message header itself is very 
simple. It protects against man-in-the-middle attacks which is very important
when using proxies. This extension can be achieved in a manner that is very
simple and compatible with the S-http scheme. Thus implementors only have one 
scheme to worry about.


I'm also very against discussing this in the http forum and not the security
one. A lot of work has gone into unifying the security schemes proposed last
year. It has always been my beief that they are part of the main HTTP spec.
In this respect the name S-HTTP is probably misleading. Considering the 
potential problems with turf wars vis a vis various IETF parties we should be 
very clear that we ensure that security matters are raised on 
www-security-request@ns1.rutgers.edu. They might also be sent to other lists
but they MUST definitely be seen in the security list. I get over 200 messages
a day. I don't read all of them. The security list is one I do read, as do those
doing security work.


The bottom line is that with the minimal Digest scheme proposed a secure 
communication can be set up between a browser and a security enhancment proxy. 
I do not bleive that the simpleMD5 scheme offers this level of security unless
the actual transaction itself is authenticated. Doing this makes the SimpleMD5
scheme effectively the same as the digest scheme.

In other words the SimpleMD5 scheme is not a security `enhancement', it is a 
weakening of a scheme already proposed and implemented. :-( Moreover this is
precisely the point Alan and myself raised against the original SSL scheme
at the W3C security meeting.


One other point, before the unification of Shen/S-HTTP proposals started Shen
used the actual header itself for the authentication. This was discovered not
to work with some proxies that reorganised the header lines :-( so I adopted 
the S-HTTP approach of having an encapsulated header, MIME style. Note however
that full S-HTTP mucking arroung with ASN.1 encapsulation is not required! 



The digest scheme specs are avaliable from:-

http://info.cern.ch/hypertext/WWW/Protocols/HTTP/digest_specification.html


	Phill Hallam-Baker

Received on Saturday, 21 January 1995 17:18:22 UTC