Subject: [Hipsec] The simplest password authentication for HIP

From: Robert Moskowitz <[email-masked]>
Date: Thu, 13 May 2010 10:11:05 -0400

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  :)

---

From: Miika Komu <[email-masked]>
Date: Thu, 13 May 2010 17:25:15 +0300

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

Hi,

> 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).
>
> 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?
>

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

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 13 May 2010 11:41:48 -0400

On 05/13/2010 10:25 AM, Miika Komu wrote:
> 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...

I wanted something a little bit more, plus protected from dictionary attack.

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

Yes, I have read it, but this less intrusive; better for small devices.

---

From: Miika Komu <[email-masked]>
Date: Thu, 13 May 2010 19:26:26 +0300

On 13/05/10 18:41, Robert Moskowitz wrote:

Hi Bob,

> I wanted something a little bit more, plus protected from dictionary

to be sure that we did not misunderstand each other, I basically agree 
with your idea but wanted to add something to it. Instead of having a 
plaintext password inside the encrypted parameter, I suggested hashing 
the password inside the encrypted parameter.

A lot of people reuse the same password on different services. This way, 
an attacker that has successfully compromised one service cannot use the 
password to exploit other services.

> Yes, I have read it, but this less intrusive; better for small devices.

Your idea seems nice but should be an extension to RFC5201, right?

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 13 May 2010 13:13:51 -0400

On 05/13/2010 12:26 PM, Miika Komu wrote:
>>>> controller
> A lot of people reuse the same password on different services. This 
> way, an attacker that has successfully compromised one service cannot 
> use the password to exploit other services.

Yes we ARE misunderstanding each other! The password is NOT in the 
encrypted parameter. Rather the password is used in PKCS-5 to encyrpt 
the opaque data in ECHO_REQUEST_SIGNED. This makes it a 
challenge/response protocol without extending BEX.

> Your idea seems nice but should be an extension to RFC5201, right?

It will actually be a part of DIET HIP with notation that it can be used 
in HIP BEX as well. It makes for a great ACL table bootstrap mechanism 
for sensors in a backwards manner:

The sensor has a factory installed password. This password is loaded 
into a installation server. This installation server makes a HIP 
password authenticated connection to the sensor, overwrites the factory 
password with an owner password and adds the sensor the the owner's 
sensor ACL. This makes it easy to field install a new meter and add it 
to the utility's meter ACL.