Re: [Hipsec] The simplest password authentication for HIP

[Miika Komu <[e-mail]>]

On 13/05/10 17:11, Robert Moskowitz wrote:

Hi,

> The scenario is a client needs access to a server when it is not already
> in the server's ACL and the server will ONLY accept ACL listed clients,
> but has a password available. An example is a grid substation controller
> as the server and a field engineer's tester as the client. In this
> example, the engineer would be able to pull the password for the server
> as part of the service call (as an example).
>
> In I2, ECHO_REQUEST_SIGNED is encrypted using PKCS-5 and the password,
> then placed within the HIP ENCRYPT parameter.
>
> The advantages of this approach are:
>
> The server does not advertise in any manner that it accepts password
> authentication for clients. If a client is not in its ACL or does not
> provide the proper ENCRYPT parameter, the connection attempt is dropped.
>
> The password is never exposed to dictionary attack to silent listeners,
> as it is encrypted by the DH derived key.
>
> It is EXTREMELY lightweight, not expanding HIP exchange by more than a
> slightly larger ENCRYPT payload.
>
> The disadvantages of this approach are:
>
> The server has to go through most of the I2 processing to determine that
> this is a password-based authentication. Though perhaps if the client is
> NOT in its ACL it could process the ENCRYPT parameter before it checks
> HIP_MAC and HIP_SIGNATURE?
>
> New use for ECHO_REQUEST_SIGNED and content for ENCRYPT.
>
> I can't come up with much else on a down side :)

what about sending a hash of the password (and using a salt like in UNIX 
passwords)? This should offer some protection against tainted servers 
and password reuse...

Btw, Samu's related draft is available from here:

http://tools.ietf.org/html/draft-varjonen-hip-eap-00