Subject: [Hipsec] FW: WG Review: Better-Than-Nothing Security (btns)

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Wed, 9 Mar 2005 09:14:24 -0800

I wonder if opportunistic HIP could help out here. Originally, I think
that Bob positioned HIP as a lightweight complement to IKE
(draft-moskowitz-hip-00 section 3).

-----Original Message-----
From: IESG Secretary [mailto:[email-masked]] 
Sent: Tuesday, March 08, 2005 11:15 AM
To: IETF Announcement list
Subject: WG Review: Better-Than-Nothing Security (btns) 

A new IETF working group has been proposed in the Security Area.
The IESG has not made any determination as yet. The following 
description was submitted, and is provided for informational purposes
only.
Please send your comments to the IESG mailing list ([email-masked]) by 
March 16. 

+++

Better-Than-Nothing Security (btns)
===================================

Current Status: Proposed Working Group

DESCRIPTION:

Current Internet Protocol security protocol (IPsec) and Internet Key
Exchange protocol (IKE) present somewhat of an all-or-nothing
alternative; these protocols provide protection from a wide array of
possible threats, but are sometimes not deployed because of the need
for pre-existing credentials. There is significant interest in providing
anonymous keying for IPsec
between two parties who do not have credentials suitable for the
current profile of IKE. This mode would protect against passive
attacks but would be vulnerable to active attacks.
The primary purpose of this working group is to specify
extensions to or profiles of IKE to enable this mode of IPsec.
The goal of this relaxed varient of IPsec is to enable and encourage the
use of
network
security where it has been difficult to deploy - notably, to enable
simpler, more rapid deployment.

Two related problems emerged during the discussion of this problem.
First, there is a desire in the KITTEN, RDDP, NFSv4 and potentially
otherc
working groups to perform anonymous authentication at the IPsec layer
and later cryptographically bind the IPsec association to application
authentication. The specification of how this binding is performed
for IPsec and the specification of how the binding interact with
application authentication protocols are out of scope for this working
group. However, the interactions between this cryptographic channel
binding and the IPsec PAD will be similar to those for the anonymous
mode with no binding. This working group needs to consider the
channel bindings use case when developing extensions to the PAD and
SPD.

Secondly, BTNS and the channel bindings work both encourage IPsec to
be used to secure higher layer protocols. AS such we need to consider
what information these higher layer protocols need from IPsec.

Two proposals are under discussion for providing anonymous keing for
IPsec: bare RSA keys transported by IKE and self-signed certificates
transported by IKE.

The WG has the following specific goals over three IETF meetings:

a) develop a framework document to describe the motivation and
goals of these infrastructure-free variants of security protocols
in general, and IPsec and IKE in specific

b) develop an applicability statement, characterizing a reasonable
set of threat models with relaxed assumptions suitable for
infrastructure-free use, and describing the limits and conditions
of appropriate use of infrastructure-free variants

c) develop standards-track IKE extensions and/or profiles that
support one or both of the bare RSA keys or self-signed certificates

d) Specify standards-track extensions to the SPD and PAD to
support anonymous keying for IPsec and cryptographic channel bindings
for IPsec

e) Develop an informational document giving advice to IPsec
implementers and higher-level protocol designers on the use of
IPsec in securing higher-level protocols

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 9 Mar 2005 14:36:10 -0600

> (draft-moskowitz-hip-00 section 3).

As a quick response: yes, from a functional point of view.

However, many of the security folks do not want to consider HIP,
they want to use IKEv2.  I think the attitude is very rational
from their point of view.  In general, people are much more
confident that IKEv2 is secure vs. whether HIP is secure or not.

--Pekka

---

From: Yushun Wang <[email-masked]>
Date: Wed, 09 Mar 2005 14:06:53 -0800

> confident that IKEv2 is secure vs. whether HIP is secure or not.

My view is slightly different. To me the question is
whether the concept of btns or anonsec applies to
HIP or not, and whether HIP protocol specs _prevent_
the use of anonymous mode or other "less secure"
modes.

I am sure most would agree the answer is "yes" for the
first question, though I am not familiar with HIP enough
to offer definitive answers.

As for IKE vs. HIP, the current focus of wg-to-be's effort
is on IPsec, but it is entirely possible to have a doc on
how to provide similar services in HIP. Of course I could
only speak for myself on this matter.

IMO this is another example to Tom's generalization draft.
Apologize if I misunderstood Tom's draft, should've read it
first. :-) I would really like to support Tom's effort to
going through the HIP arch/spec and maybe relaxes certain
MUSTs or MUST-NOTs in a manner that would not cause huge
pain for inter-op tests for implementers, but would open
the possibilities to support wider range of arch/services/
apps/etc.

yushun

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 9 Mar 2005 16:27:59 -0600

> the use of anonymous mode or other "less secure"

Well, as far as I can see, HIP-as-is does not specify
anything else but a btns-like mode.  HIP does have the
CER packet type for carrying certificates, but how to
use certificates is out of scope.  Hence, base HIP only
defines a protocol that provides the application assurance
that the peer has access to the private key corresponding
to the host identity, i.e., the public key.  How the
application gets the public key (or the corresponding HIT)
is out of scope.

So, I can't see how the HIP specs would prevent one from
using "anonymous" or "less secure" mode.  It even allows
you to use very short public and Diffie-Hellman keys.

> only speak for myself on this matter.

Well, what I am hoping from the anonsec effort is to get
a standard interface to the SPD and PAD that would allow
the KMP to push a hash of a public key down the stack and
associate that with an SA.  That would most probably make
any HIP implementation easier, perhaps to the point that
one could implement HIP on the "top" of existing IPsec
without requiring any changes to the kernel.  If that happens,
we don't need any document on how to provide similar services
with HIP, as they *are* already there.

Taking two steps back, I really think that we should gradually
inch ourselves towards a model where the application level
identifiers have build-in channel bindings.  HIP, when used
with a HIT-based API, provides that.  I think it would be good
if IPsec supported that, too.

--Pekka

---

From: Yushun Wang <[email-masked]>
Date: Wed, 09 Mar 2005 15:04:47 -0800

> you to use very short public and Diffie-Hellman keys.

Thanks for the authoritative answers. :-) I stand corrected.

> with HIP, as they *are* already there.

Agree on this. Let's keep our fingers crossed...

yushun