[anonsec] prob-02

[Michael Richardson]

and Key IDs [10]. All require either CA-signed certificates or pre-
shared secrets to authenticate. These can be roughly categorized into
network layer identifiers and other identifiers.

...

2.1.2. Authentication Methods
As described earlier, CA-signed certificates and pre-shared secrets
are the only methods of authentications accepted by current IPsec and
IKE specifications. Pre-shared secrets require manual configuration

This is false.

There is nothing in IKEv1 or IKEv2 that says that you have to use a
CA-signed certificate to us RSASIG authentication.

As implementation proof, there is the Openswan/Freeswan/Strongswan, and
ncp.de (for windows) that provides raw rsa key usage with RSASIG.

Self-signed certificates are widely used as well, both by *swan, and
also by racoon, SSH/Safenet, and others.

The fact that these things need to be pre-exchanged is irrelevant, as so
do PSK.

The fact of the matter is that a multitude of IPsec vendors have made it
very hard to use RSASIG mode in any kind of small-scale deployment.
These systems simply do not scale: scaling is about working with 2
machines as well as with 2million.
Just working for 2 million nodes is not "scaling".

By stating the above you are propogating the myth that "PK is hard"
(Think of that in a "math-is-hard" Barbie voice). It isn't. It's the "I"
part that is hard, particularly if you wish to work without pre-deployed
infrastructure, which Joe does.

I can not suggest text, because I think worrying about how hard
certificates are to get is totally irrelevant. I would just say that
pre-arranging appropriate, mutually trusted authentication systems is
hard, particularly when the connection crosses organizationational
boundaries.

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

[Stephen Kent]

Post by Michael Richardson
...
Self-signed certificates are widely used as well, both by *swan, and
also by racoon, SSH/Safenet, and others.

technically, a self-signed, PKIX-compliant cert is a CA cert.

Steve

[Yu-Shun Wang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

and Key IDs [10]. All require either CA-signed certificates or pre-
shared secrets to authenticate. These can be roughly categorized into
network layer identifiers and other identifiers.

...

2.1.2. Authentication Methods
As described earlier, CA-signed certificates and pre-shared secrets
are the only methods of authentications accepted by current IPsec and
IKE specifications. Pre-shared secrets require manual configuration

This is false.
There is nothing in IKEv1 or IKEv2 that says that you have to use a
CA-signed certificate to us RSASIG authentication.

I should clarify. It's actually more about 4301, PAD and SPD
rather than IKE. This is from 4301:

4.4.3.2. IKE Peer Authentication Data

Once an entry is located based on an ordered search of the PAD based
on ID field matching, it is necessary to verify the asserted
identity, i.e., to authenticate the asserted ID. For each PAD entry,
there is an indication of the type of authentication to be performed.
This document requires support for two required authentication data
types:

- X.509 certificate
- pre-shared secret

For authentication based on an X.509 certificate, the PAD entry
contains a trust anchor via which the end entity (EE) certificate for
the peer must be verifiable, either directly or via a certificate
path. See RFC 3280 for the definition of a trust anchor. <snip>

And also based on my impression of the BTNS charter. I am not
familiar about IKE, but IMO it's more about the requirements
IPsec impose on the authentications used by IKE. Maybe we
should just remove IKE from the quote?

I am certain there are implementations that could do this, but
that's not the point. So I'll skip the comments below.

yushun

As implementation proof, there is the Openswan/Freeswan/Strongswan, and
ncp.de (for windows) that provides raw rsa key usage with RSASIG.
Self-signed certificates are widely used as well, both by *swan, and
also by racoon, SSH/Safenet, and others.
The fact that these things need to be pre-exchanged is irrelevant, as so
do PSK.
The fact of the matter is that a multitude of IPsec vendors have made it
very hard to use RSASIG mode in any kind of small-scale deployment.
These systems simply do not scale: scaling is about working with 2
machines as well as with 2million.
Just working for 2 million nodes is not "scaling".
By stating the above you are propogating the myth that "PK is hard"
(Think of that in a "math-is-hard" Barbie voice). It isn't. It's the "I"
part that is hard, particularly if you wish to work without pre-deployed
infrastructure, which Joe does.
I can not suggest text, because I think worrying about how hard
certificates are to get is totally irrelevant. I would just say that
pre-arranging appropriate, mutually trusted authentication systems is
hard, particularly when the connection crosses organizationational
boundaries.