Subject: [anonsec] prob-02

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Mon, 20 Mar 2006 13:18:25 -0600

>   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"); [

---

From: kent at bbn.com (Stephen Kent)
Date: Mon, 20 Mar 2006 16:26:31 -0500

>also by racoon, SSH/Safenet, and others.

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

Steve

---

From: yushunwa at ISI.EDU (Yu-Shun Wang)
Date: Mon, 20 Mar 2006 15:56:48 -0600

Michael Richardson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

> 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