Subject: [anonsec] Why use self-signed certs at all?

From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Fri Nov 19 08:41:19 2004

Greetings. I wasn't at the BOF, but I have read the proposed charter 
and the last few weeks of the mailing list. The core of the proposed 
charter (that is, the problem statement) is "This proposed working 
group will develop extensions to existing IPsec protocol suite to 
support relaxed variants that reduce their need for pre-shared keys 
and/or key management infrastructure."

And yet now we're talking about moving this into PKI4IPSEC without 
even looking at other solutions that don't involve self-signed 
certificates. That seems completely crazy.

At this point, I believe that that charter can better served with 
shared secrets that aren't secret. It would be easier to fit into 
IKEv1 and/or IKEv2, would cause faster setup for SAs, and would not 
encumber all of the baggage that made the PKI4IPSEC WG required in 
the first place.

So, two issues here:

- Putting this in PKI4IPSEC presumes a solution that may be 
inappropriate for the stated problem

- The proposed solution (use of certs) has many known problems that 
may be avoided with other solutions

--Paul Hoffman, Director
--VPN Consortium

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri Nov 19 10:10:00 2004

Paul Hoffman / VPNC wrote:
> Greetings. I wasn't at the BOF, but I have read the proposed charter and 
> the last few weeks of the mailing list. The core of the proposed charter 
> (that is, the problem statement) is "This proposed working group will 
> develop extensions to existing IPsec protocol suite to support relaxed 
> variants that reduce their need for pre-shared keys and/or key 
> management infrastructure."
> 
> And yet now we're talking about moving this into PKI4IPSEC without even 
> looking at other solutions that don't involve self-signed certificates. 
> That seems completely crazy.
> 
> At this point, I believe that that charter can better served with shared 
> secrets that aren't secret. It would be easier to fit into IKEv1 and/or 
> IKEv2, would cause faster setup for SAs, and would not encumber all of 
> the baggage that made the PKI4IPSEC WG required in the first place.

FWIW, this is what I had originally assumed (e.g., "OPEN SECRET" as the 
shared secret). I've discussed the issue of self-signed certs, and it 
seems like it unnecessarily depends on additional mechanism (cert 
signing system) pre-installed and configured. It'd be useful to avoid as 
much of that sort of requirement/assumption as possible.

> - The proposed solution (use of certs) has many known problems that may 
> be avoided with other solutions
> 
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20041119/e48f0f94/signature.bin

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri Nov 19 10:14:20 2004

Subject: [anonsec] Why use self-signed certs at all?

Excellent question.

If you remember my presentation at IETF 58 at SAAG you might remember
that I did not propose the use of non-pre-shared self-signed certs then.

Yet I do now.

There's several reasons for this change in my approach to
unauthenticated IPsec, and I have to thank Bill Sommerfeld for bringing
these to my attention:

1)  Support existing (IKEv1, v2) and alternative (MOBIKE) KE protocols.

    My original proposal was very IKEv2 specific.  By using
    non-pre-shared self-signed certs we can make it easier to just
    profile existing and future KEs.

    My original proposal was also very dependent on IKEv2-style SA
    re-keying.  See (3) below.

2)  Robustness and support for use with non-connection oriented
    transports.

    My original proposal called for not doing an AUTH exchange for
    unauthenticated SAs, yet generating a channel ID from the SKEYSEED
    for use with channel binding.

    My original proposal was also rather specific to TCP as well and had
    robustness issues with regards to the TCP handshake and binding of
    the resulting TCP connection to an SA pair (and train of re-keyed
    SAs.

    Fall through to (3).

3)  Robustness with respect to re-keying.

    My original proposal required that SAs be re-keyed before they
    expire, which means that network partitions could kill a TCP
    connection by killing its SA pairs.

    By using [non-pre-shared self-signed] certs SAs can be reestablished
    as needed, as long as the IDs (the cert public keys, in this case)
    remain the same.

    And also, by using certs to avoid the need for timely SA re-keying
    this approach is made less IKEv2-specific.

> encumber all of the baggage that made the PKI4IPSEC WG required in 

The use of shared secrets that aren't secret destroys the value of
unauthenticated IPsec for use with channel binding (because if the
shared secrets aren't then MITM attacks are possible).  So, no!  :)

> may be avoided with other solutions

Can you expand on that second issue please?  Remember, there's no
certificate status, path validation or other such issues in this case --
if the peer asserts the public key of its cert as an ID then that and
the expiration on the self-signed cert should be all that the other peer
should care about (and, of course, policy w.r.t. use of unauthenticated
IPsec).

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri Nov 19 10:17:47 2004

> much of that sort of requirement/assumption as possible.

Most IKE implementations already have this component.

I cannot and will not support any unauthenticated IPsec proposal that
fails to provide support for use with channel binding.

As I recall a number of attendees stressed the importance of channel
bindings at the BoF.

Nico
--

---

From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Fri Nov 19 10:28:18 2004

At 10:07 AM -0800 11/19/04, Joe Touch wrote:
>FWIW, this is what I had originally assumed (e.g., "OPEN SECRET" as 
>the shared secret). I've discussed the issue of self-signed certs, 
>and it seems like it unnecessarily depends on additional mechanism 
>(cert signing system) pre-installed and configured. It'd be useful 
>to avoid as much of that sort of requirement/assumption as possible.

If that's true at all, then the discussion of moving this to 
PKI4IPSEC is very out of scope. If we later decide that we really are 
using self-signed certs, we can consider the move then.

--Paul Hoffman, Director
--VPN Consortium

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri Nov 19 10:44:23 2004

Paul Hoffman / VPNC wrote:
>> the shared secret). I've discussed the issue of self-signed certs, and 
>> it seems like it unnecessarily depends on additional mechanism (cert 
>> signing system) pre-installed and configured. It'd be useful to avoid 
>> as much of that sort of requirement/assumption as possible.
> 
> 
> If that's true at all, then the discussion of moving this to PKI4IPSEC 
> is very out of scope. If we later decide that we really are using 
> self-signed certs, we can consider the move then.

FWIW, others care about the use of a persistent ID, and assume that the 
self-signed cert is where that ID lives. I don't understand why that's 
required per se; it seems that we should be able to place or refer to 
IDs by something other than an X.509 cert.

I.e., IDs inside X.509 are some sort of names. If that's the case, then 
the use of the name ought not require X.509 per se. IMO, using "X.509 
cert" where we mean "the name the X.509 cert authenticates" is a 
mistake, and binds us to a level of complexity we don't always need.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20041119/d8f46940/signature-0001.bin

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri Nov 19 10:46:20 2004

> using self-signed certs, we can consider the move then.

Please see my replies to you and Joe on this.

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri Nov 19 10:53:24 2004

Hi, all,

FYI, I haven't noted when I have been speaking with my BOF chair hat 
"on" or "off" in my posts. In general, I have been speaking as an 
individual.

I'll be explicit when I'm speaking as BOF chair; otherwise, assume my 
posts are as an individual.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20041119/d012921c/signature.bin

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri Nov 19 10:55:19 2004

> IDs by something other than an X.509 cert.

Because it's a lot easier to define unauthenticated IPsec as profiles of
KE protocols in ways that are far less intrusive on the internals of
those KE protocols.

Again, I've been down the path you want us to go down and found it to be
a dead end.  See my replies on this thread today.

> mistake, and binds us to a level of complexity we don't always need.

Please read my e-mails.  I've not suggested using the names from the
certs -- only their public keys -- to "identify" peers.

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri Nov 19 11:00:21 2004

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20041119/9b77be48/signature.bin

---

From: lars.eggert at netlab.nec.de (Lars Eggert)
Date: Fri Nov 19 13:16:58 2004

Joe Touch wrote:
> <BOF-HAT-ON>
> 
> I'd like to solicit input with brief justification on the following 
> questions, so that this discussion can be motivated from the bottom-up 
> if possible. Please answer BOTH questions.
> 
>     1) should BTNS be stand alone or part of an existing WG?
> 
>     2) if (1) is 'part of existing', should BTNS be part of
>        PKI4IPsec?

1) BTNS should be stand-alone. It is a focused piece of work with a 
nice, restricted scope. It has interactions with some other WGs, but not 
more so than usual. I don't see how merging BTNS into an existing WG 
would let either of the two make better progress or produce better results.

2) thus does not apply

Lars
-- 
Lars Eggert                                     NEC Network Laboratories
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3360 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20041119/7ae9e61c/smime.bin

---

From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Fri Nov 19 13:40:21 2004

>1)  Support existing (IKEv1, v2) and alternative (MOBIKE) KE protocols.

Assuming you mean the protocols and not the implementations, using a 
universally-shared non-secret does that just fine. Assuming you mean 
common implementations, using a universally-shared non-secret does 
that just fine and using self-signed certificates does not.

>2)  Robustness and support for use with non-connection oriented

Using a universally-shared non-secret does that just fine.

>     this approach is made less IKEv2-specific.

Using a universally-shared non-secret does that just fine. As long as 
the Phase 1 is still up, you can create and rekey Phase 2s.

So, I don't see why you feel that any of these prevent the use of 
using a universally-shared non-secret to solve the problem at hand.

--Paul Hoffman, Director
--VPN Consortium

---

From: kent at bbn.com (Stephen Kent)
Date: Fri Nov 19 14:27:20 2004

Joe & Paul,

I don't mean to suggest that self-signed certs are the best solution, 
or the only solution. certainly one could use a fixed "secret" just 
like SMTP does (did?) for many years. that too can be accommodated in 
the PAD description I'm working on for pki4ipsec, because the PAD 
deals with ALL means of authenticating IKE peers.

Still, the issue of a new WG vs. a charter extension for pki4ipsec is 
more likely an issue that should hinge on the broader set of goals 
one wants to accomplish.  When we have a clear description of those 
goals before us, it may make the decision easier.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Fri Nov 19 14:27:21 2004

At 10:59 AM -0800 11/19/04, Joe Touch wrote:
>Content-Type: multipart/signed; micalg=pgp-sha1;
>	protocol="application/pgp-signature";
>	boundary="------------enig31933F72274C82A0F617B780"
>
><BOF-HAT-ON>
>Hi, all,
>
>questions, so that this discussion can be motivated from the 
>bottom-up if possible. Please answer BOTH questions.
>
>Thanks,
></BOF-HAT-ON>

Joe,

I think the question is premature, based on the many e-mail exchanges 
we've seen today.  First we need a concrete, proposed set of goals 
for the work, the sort of thing one would hope to see in a charter. 
Then, when we reach consensus on those goals, we can see where to 
pursue the work.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Fri Nov 19 14:27:33 2004

At 10:43 AM -0800 11/19/04, Joe Touch wrote:
>	boundary="------------enigD92331F6CB0D707DA865DF0A"
>
>
>
>>>FWIW, this is what I had originally assumed (e.g., "OPEN SECRET" 
>>>as the shared secret). I've discussed the issue of self-signed 
>>>certs, and it seems like it unnecessarily depends on additional 
>>>mechanism (cert signing system) pre-installed and configured. It'd 
>>>be useful to avoid as much of that sort of requirement/assumption 
>>>as possible.
>>
>>
>>PKI4IPSEC is very out of scope. If we later decide that we really 
>>are using self-signed certs, we can consider the move then.
>
>FWIW, others care about the use of a persistent ID, and assume that 
>the self-signed cert is where that ID lives. I don't understand why 
>that's required per se; it seems that we should be able to place or 
>refer to IDs by something other than an X.509 cert.
>
>I.e., IDs inside X.509 are some sort of names. If that's the case, 
>then the use of the name ought not require X.509 per se. IMO, using 
>"X.509 cert" where we mean "the name the X.509 cert authenticates" 
>is a mistake, and binds us to a level of complexity we don't always 
>need.
>
>Joe

There is no need to use the subject name of alt subject name from a 
cert as the ID for the IKE peer.  We're clarifying that separation of 
authentication credential vs. ID vs. authorization to assert a name 
or IP address for child SAs in the PAD text now.

Steve

---

From: shalunov at internet2.edu (stanislav shalunov)
Date: Fri Nov 19 15:11:18 2004

> 	1) should BTNS be stand alone or part of an existing WG?

BTNS should be a stand-alone effort.  Otherwise, the danger of
becoming entangled in ``why don't we just find a fix for PKI and a
cure for cancer'' discussion is too great.

> 	2) if (1) is 'part of existing', should BTNS be part of

Not applicable.

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

Sex is the mathematics urge sublimated.                 -- M. C. Reed.

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri Nov 19 15:44:21 2004

Paul,

One thing that this "universally-shared non-secret" doesn't do is allow
for channel bindings as a way to prevent MITMs in the IPsec channel.

Also, this prevents any leap-of-faith sharing of self-signed certs.

Nico
--

---

From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Fri Nov 19 17:30:31 2004

>for channel bindings as a way to prevent MITMs in the IPsec channel.

Unless I am misunderstanding channel bindings, I fully disagree. The 
higher-level protocol can use either the inputs to the DH, or the 
output of the DH (although Steve Kent has pointed out that this might 
not be good), to do the channel bindings in a way that prevents 
Mallory from getting anything in the higher-level protocol.

>Also, this prevents any leap-of-faith sharing of self-signed certs.

Sorry, I can't figure out what that means.

--Paul Hoffman, Director
--VPN Consortium

---

From: pekka.nikander at nomadiclab.com (Pekka Nikander)
Date: Sat Nov 20 00:24:25 2004

> 	1) should BTNS be stand alone or part of an existing WG?

Yes, BTNS should be a stand alone WG.

> 	2) if (1) is 'part of existing', should BTNS be part of

No, re-chartering pki4ipse that much most probably leads to much less 
focused work.

--Pekka Nikander

---

From: Julien.Laganier at Sun.COM (Julien Laganier)
Date: Thu Nov 25 01:48:58 2004

>  1) should BTNS be stand alone or part of an existing WG?

FWIW,I think BTNS should be its own WG. The main reason for that is 
that I can't find a sufficient overlapping between BTNS and any of 
the existing WGs.

>  2) if (1) is 'part of existing', should BTNS be part of

We are considering PKI-less solutions so I (still) don't see the point 
in having BTNS work as a part of PKI4IPSEC: I think that we not only 
need PKI4IPSEC to be rechartered, but also to be _renamed_, because 
the current name is far too restrictive and misleading if the WG 
includes BTNS work items...

Beside that, I don't buy the argument about reducing administrative 
overhead and meeting scheduling issues... it can be applied to a lot 
of other BoF/WGs, so perhaps we can just move back the whole IETF 
crowd into the NETWORK WORKING GROUP :-p

--julien

---

From: mcr at sandelman.ottawa.on.ca ([email-masked])
Date: Tue Nov 30 23:15:57 2004

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Joe" == Joe Touch <[email-masked]> writes:
    Joe> I'd like to solicit input with brief justification on the
    Joe> following questions, so that this discussion can be motivated
    Joe> from the bottom-up if possible. Please answer BOTH questions.

    Joe> 	1) should BTNS be stand alone or part of an existing WG?

    Joe> 	2) if (1) is 'part of existing', should BTNS be part of
    Joe> PKI4IPsec?

  It is hard for me to answer the question, because there are WGs that
are semi-dead.

  I think that it should be part of another WG. Alas, the WG that I
think it should be part of, is the non-MIB/PIB side of IPSP, which has
been stillborn.

  My opinion is that it isn't enough to get better-than-nothing
security. One has to also let the application know that it got that.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [