Re: SOI QUESTIONS: 2.3 Authentication styles

[Paul Hoffman / VPNC <paul.hoffman@vpnc.org>]

At 8:14 PM -0400 6/18/02, Theodore Ts'o wrote:
>The fact that there is an IPSRA working group is a fairly strong
>argument that remote-access specific functionality should be handled by
>another protocol.

As the co-chair of that WG, I strongly disagree with that statement. 
The IPSRA WG was created because of mandate from the Security Area 
Directors to deal with the remote access problem for IKEv1 without 
touching IKEv1. The current discussion about SOI would only be 
related to the IPSRA work if people felt that the protocol that came 
out of IPSRA (namely PIC) was efficient, robust, and useful in SOI. 
Few, if any, people have said that.

>   This would also have the advantage of keeping the
>core key management protocol small, such that applications which were
>not specifically about remote access (i.e., iSCSI, secure telephony,
>pure VPN applications, end-to-end authentication using IPSEC, etc.)
>would not have to their implementations bloated by functionality that
>they don't need.

That would be a real consideration if dealing with remote access 
added much complexity or bloat. For example, if people said "we must 
add an XAUTH-like Phase 1.5", then it would be a real concern. 
However, there are proposals that allow reasonably-flexible remote 
access (with or without legacy authentication, which people often 
feel is an important part of remote access) that do not add 
significant complexity.

>On the other hand, there seems to be a very strong remote access
>contingent in this working group who seems to be very concerned about
>the protocol overhead inherent in separating remote access functionality
>from the core key management protocol.

For those of us who believe that remote access is inherently part of 
the VPN scenario for IPsec because our customers tell us it is, yes.

>2.3.A.)  Does SOI need to natively support "legacy authentication
>systems"?

As draft-ietf-ipsec-revised-identity points out, if SOI supports 
preshared secrets that are not tied to IP addresses (that is, where 
each party says what ID is associated with the preshared secret it is 
using), legacy authentication comes for free. The only requirement on 
the legacy authentication system is that it returns authentication 
proof that is large enough to be broken into an ID and a preshared 
secret, and that the preshared secret part is not susceptible to a 
dictionary attack.

>2.3.B.)  Does SOI need to natively support some kind of "shared
>secret" scheme?  (Or just certificates-only?)

Cryptographically: no. Practically: yes.

"Certificates-only" implies one of three scenarios:
- an actual PKI with a trust anchor
- self-signed certificates
- a mixture of both

We all know that expecting IPsec administrators to understand even 
the minimum required set of intricacies of PKIX is silly. Quite 
frankly, many of the messages on this mailing list from a few years 
ago when we were trying to come up with a PKIX profile for IPsec 
shows that many of the implementers here don't understand PKIX all 
that well.

Passing around keys for self-signed certificates has all of the 
scaling problems of preshared secrets, but the keys are probably much 
longer and easier to type in wrong. Self-signed certificates have a 
definite advantage over preshared keys: it is much less likely that 
the owner of the private key would lose it or even know how to tell 
someone what it was. However, they have the disadvantage that they 
are significantly harder to use when a WAN administrator purposely 
wants to set up a small network with all nodes having the same key.

Going to one method of identity is cleaner than having two, but both 
JFK and IKEv2 show that the complexity can be much less than it was 
in IKEv1. Even though JFK doesn't have a pre-shared secret mode, it 
would be trivial to add one in (use an HMAC instead of a signature on 
the identity-protected information in messages 3 and 4).

In summary, it would not serve us well to turn our back on many of 
today's VPN users simply to make an argument of purity. Doing so 
would almost certainly assure that many users would not want to adopt 
SOI: why would they want to if it made their life harder? Further, we 
can use shared secrets to include legacy authentication for free with 
no additional protocol overhead.

--Paul Hoffman, Director
--VPN Consortium