Subject: [anonsec] Bare RSA keys instead of self-signed certs

From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Wed Nov 24 09:32:31 2004

A different thought. We keep talking about self-signed certs, which 
takes us down many ratholes. However, it seems like there is no 
security or technical reason why we need a self-signed cert: a bare 
RSA key would suffice.

Using a bare RSA key has some distinct advantages:

- It causes Phase 1 to go faster because there is only one signature 
validation instead of two

- It allows systems that do not have the ASN.1 parsing code needed to 
dig into the cert to participate

- We can go with what is already in IKEv2 as-is (certificate encoding type 11)

- If we want to make this work with IKEv1, the extension is quite small

- There is no reason to even think about the PKI4IPSEC WG

We have already agreed that the identity in the self-signed cert is 
not useful for BTNS, and that the expiration date is only useful for 
leap-of-faith trust, which we are not considering.

So, are there any reasons we should be using self-signed certs? Do 
they outweigh the list above?

--Paul Hoffman, Director
--VPN Consortium

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed Nov 24 09:49:48 2004

For unauthenticated IPsec there is little difference between a bare
public key and self-signed certs.

This is true.

However, there is definitely more work to be done to allow for the use
of bare keys: we'll need not only a new ID type but also new CERT and
AUTH types, and we have to think and argue about RSA vs. DSA and so on.

I don't think it's that hard to extract the subjectPublicKeyInfo, and,
optionally, the validity fields from a cert -- that's all an
unauthenticated IPsec implementation would need from a cert.

Nico
--

---

From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Wed Nov 24 10:01:47 2004

>public key and self-signed certs.

Glad we agree here.

>AUTH types, and we have to think and argue about RSA vs. DSA and so on.

That is not true for IKEv2: it is already specified. For IKEv1, we 
would only need a new CERT type, because it is the same AUTH type, 
namely digital signature.

No one uses DSA keys; virtually no one ever did.

>unauthenticated IPsec implementation would need from a cert.

It's nice that you don't think it is that hard; others have found it 
daunting. Why require it if it is unneeded?

--Paul Hoffman, Director
--VPN Consortium

---

From: briank at briank.com (Brian Korver)
Date: Wed Nov 24 10:09:47 2004

Paul,

IKEv1 has auth with encrypt mode, so what extensions
do you have in mind for using "raw" RSA keys w/IKEv1?

-brian
[email-masked]

Paul Hoffman / VPNC wrote:
> takes us down many ratholes. However, it seems like there is no security 
> or technical reason why we need a self-signed cert: a bare RSA key would 
> suffice.
> 
> We have already agreed that the identity in the self-signed cert is not 
> useful for BTNS, and that the expiration date is only useful for 
> So, are there any reasons we should be using self-signed certs? Do they 
> outweigh the list above?
> 
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed Nov 24 10:16:54 2004

> >public key and self-signed certs.

Me too.

> namely digital signature.

If this is true, and if the IKEv1 changes are sufficiently minor
(implementation-wise too) then I'm fine with bare keys.

> No one uses DSA keys; virtually no one ever did.

Even so, we need to support multiple algorithms, or at least an upgrade
path.

> daunting. Why require it if it is unneeded?

My assumption is/was that for most existing IPsec implementations it
would be easier to adapt them to support unauthenticated IPsec w/ certs
than w/ bare keys.  Cert parsing may seem daunting to new implementors
who seek to implement only unauthenticated IPsec, but that is less of a
concern to me considering the number of existing independent
implementations, open source and otherwise (mind you, I don't know what
that number really is).

Nico
--

---

From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Wed Nov 24 10:35:46 2004

>do you have in mind for using "raw" RSA keys w/IKEv1?

A new cert type. We got that in IKEv2, but never agreed to it in IKEv1.

--Paul Hoffman, Director
--VPN Consortium

---

From: mcr at sandelman.ottawa.on.ca ([email-masked])
Date: Wed Nov 24 10:52:50 2004

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

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:
    Nicolas> However, there is definitely more work to be done to allow
    Nicolas> for the use of bare keys: we'll need not only a new ID type
    Nicolas> but also new CERT and AUTH types, and we have to think and
    Nicolas> argue about RSA vs. DSA and so on.

  Nonsense. 

  Linux FreeS/WAN and Openswan IPsec has been doing it for 6 years now.
The IKEv1 CERT type is already there, although we haven't written code
to use it. 

  We don't need ANY new AUTH types.
  This is proven by operational code.

  In fact, my backup box, which is a NetBSD box running KAME + racoon,
which only does pkix format RSA, communicatesd *REGULARLY* with other
machines that do raw-rsa key (in DNS). The racoon box thinks it has a
static tunnel. The Openswan Linux box thinks it is doing opportunistic
encryption. 
  Since the bits on the wire are the same, it doesn't matter how they
got their policy. 

  [note that racoon only safely did self-signed pre-exchanged certs
until somebody noticed a bug a couple of months ago. But that's okay, I
never did anything else.] 

  As for DSA... the only good argument for it was that it was
patent-free. That advantage disappeared 3 years ago ;-)
  Perhaps one will need another CERT type for raw DSA keys. I think that
CERT types are relatively cheap.

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

---

From: briank at briank.com (Brian Korver)
Date: Wed Nov 24 11:12:49 2004

I haven't been following BTNS, so I'm not sure what new feature it
needs that requires a new CERT type.  But for straight IKEv1, we've
had support for raw keys deployed for years now, and it seems to
work quite well.

-brian
[email-masked]

---

From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Wed Nov 24 11:17:47 2004

>(implementation-wise too) then I'm fine with bare keys.

Great! Let's see if that's true.

>Even so, we need to support multiple algorithms, or at least an upgrade

Not many people would call DSA an "upgrade" from RSA. :-)

>than w/ bare keys.

And my assumption is the opposite. I'm basing my assumption on what 
many of my members have told me about their PKIX code; one called it 
a "maze of little twisty passages". It seems to me that causing a 
completely new path would be easier than adding another fork to the 
current PKIX code ("if you're about to do the path processing, go 
over here and just trust it"). It also seems safer from a security 
standpoint to keep the paths completely separate.

>   Cert parsing may seem daunting to new implementors

True, for current IPsec implementers who are already doing PKIX 
handling. I would like this capability to be wider than that, given 
how many implementers don't do PKIX at all.

--Paul Hoffman, Director
--VPN Consortium

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed Nov 24 11:20:47 2004

>     Nicolas> argue about RSA vs. DSA and so on.

Michael, Paul already set me straight on this.  I'd be just as happy to
see unauthenticated IPsec use bare public keys as certs.

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed Nov 24 11:41:47 2004

> Great! Let's see if that's true.

Let's.

> Not many people would call DSA an "upgrade" from RSA. :-)

Well, yeah, Ok :)

I guess future new CERT/AUTH types are the upgrade mechanism, so scratch
this concern.

> standpoint to keep the paths completely separate.

See below.

> how many implementers don't do PKIX at all.

You're doing a good job of selling bare public keys.  As I've said, I'll
be just as happy with bare public keys as with certs; either way we get
a public key as the ID, so we eschew the re-key issues and get something
we can easily use for channel bindings.  And either way there would be
no "universally shared non-secret" :)

If we knew where to make a consensus call on this we'd probably be ready
for one, and we'd probably settle on bare public keys.  I'd still like
to hear from Bill about this though.

Cheers,

Nico
--

---

From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Wed Nov 24 11:42:59 2004

>had support for raw keys deployed for years now, and it seems to

OK, I guess I'm clueless then. RFC 2408 syas:

                           Certificate Type            Value
                   NONE                                   0
                   PKCS #7 wrapped X.509 certificate      1
                   PGP Certificate                        2
                   DNS Signed Key                         3
                   X.509 Certificate - Signature          4
                   X.509 Certificate - Key Exchange       5
                   Kerberos Tokens                        6
                   Certificate Revocation List (CRL)      7
                   Authority Revocation List (ARL)        8
                   SPKI Certificate                       9
                   X.509 Certificate - Attribute         10
                   RESERVED                           11 - 255

Which one are you using for raw keys?

--Paul Hoffman, Director
--VPN Consortium

---

From: briank at briank.com (Brian Korver)
Date: Wed Nov 24 15:10:46 2004

Paul,

Oh, I see.  BTNS is *sending* keys, not just using them?
If so, then right, not much needs to be done to IKE
besides adding a new CERT type.

-brian
[email-masked]

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed Nov 24 15:25:48 2004

"Is" is a strong word -- BTNS is still vapourware :)

But yes, because these keys are not pre-distributed we need to pass them
to the peer somehow.

That said, since we'll have a new ID type to indicate "asserting public
key of CERT as my ID" we could use it to double as CERT if using bare
keys...

Nico
--

---

From: pekka.nikander at nomadiclab.com (Pekka Nikander)
Date: Wed Nov 24 23:02:48 2004

> security or technical reason why we need a self-signed cert: a bare 

FWIW, I really like the idea of using bare public keys.  However, I'm 
afraid that I agree with Nico on one aspect: we need a key type 
somewhere.  While DSA may be dead, there may be other 
usable/popular/more secure public key algorithms but RSA in the future.

Now, I wish that we can get back to our regular charter bashing and 
home seeking.

--Pekka Nikander

---

From: kivinen at iki.fi (Tero Kivinen)
Date: Thu Nov 25 04:17:49 2004

> they outweigh the list above?

I consider bare RSA keys and self-signed certs about the same. I do
not really see any real difference in them. Self-signed certs are
already implemented in the IKEv1, which could offer us implementations
faster, but there are also implementations out there supporting bare
RSA keys.

The self-signed certificates do offer one advantage over bare RSA
keys: There is a clear incremental upgrade path towards using better
authentication.
-- 
[email-masked]

---

From: kivinen at iki.fi (Tero Kivinen)
Date: Thu Nov 25 04:25:50 2004

> AUTH types, and we have to think and argue about RSA vs. DSA and so on.

We do not need new ID type, we can say we use the ID type of KEY_ID,
and put there a SHA1 hash of the public key.

We do need new CERT type, but again there is no difference in the AUTH
types compared to the RSA-signatures using certificates. We can simply
use that.

I do not think we need to argue about RSA vs DSA keys.... nobody uses
DSA keys on the IKE anyways. 

> unauthenticated IPsec implementation would need from a cert.

True. We could make the document so it says that when we are doing
BTNS protocol, we are using certificates, but we only care about the
raw public key inside the certificate and ALL other fields are
ignored, including signature of the certificate, validity periods etc.

That could give us implementations faster than using raw keys. 
-- 
[email-masked]

---

From: kivinen at iki.fi (Tero Kivinen)
Date: Thu Nov 25 04:39:50 2004

> usable/popular/more secure public key algorithms but RSA in the future.

The IKEv1 have the authentication method negotiated inside the SA
payload. There is currently DSS signatures and RSA signatures defined
there already. It does not matter there whether the keys come from
certificates, or from bare keys, so no need to change anything there.

For the CERT payloads we probably need to define one CERT payload
format for raw RSA public keys, and if we are going to use another raw
key formats, then we need to add separate payload for them. The
contents of the payload needs to be specified anyways, as the public
key binary format is different for each key type. 

The IKEv2 have similar authentication method field inside the AUTH
payload, and it already have raw RSA key CERT format (there is no raw
DSS key CERT format there). 
-- 
[email-masked]

---

From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Thu Nov 25 09:22:23 2004

At 2:17 PM +0200 11/25/04, Tero Kivinen wrote:
>already implemented in the IKEv1,

Only in a few systems. Most systems that I have seen require a CERT 
payload to chain to a trust anchor.

>  which could offer us implementations

Again, I'll ask: how? What CERT payload number?

>keys: There is a clear incremental upgrade path towards using better

It is not so clear. The syntax for saying "I am going to use a 
self-signed cert" have never been standardized. What does the CERTREQ 
look like? Should there be a CERTREQ at all? How does the responding 
party say "yes, I'm willing to do this"? All of that can be answered, 
but none of it has been standardized. But...

>We could make the document so it says that when we are doing

I'm OK with this. Said another way, if message and and 2 have a 
BTNS-specific VendorID payload, that means that there will be no 
CERTREQ and that a PKIX cert received should only be parsed for its 
key and everything else in the key is ignored. That still means a bit 
more code for implementations that haven't done PKIX certs just to 
parse the cert, but that can be done by hand without an ASN.1 module. 
It's ugly, but it could work.

I would still prefer a new bare-key payload, but can understand why 
folks who already have done the PKIX work would want to just re-use 
it.

>types compared to the RSA-signatures using certificates. We can simply

Exactly. If someone wants to create a new self-signed cert or bare 
key in the future, they can define the new CERT type and AUTH type to 
go with them. IKEv1 was flexible on this.

--Paul Hoffman, Director
--VPN Consortium

---

From: kivinen at iki.fi (Tero Kivinen)
Date: Fri Nov 26 03:37:59 2004

> payload to chain to a trust anchor.

It is much easier to modify the existing implementation that it does
not care about the cert verification, than to add new support for bare
RSA key CERT payloads. 

> Again, I'll ask: how?

Out of band bare RSA key delivery. 

> What CERT payload number?

No defined format for that. 

> but none of it has been standardized. But...

Normally those implementations have been sending empty CERTREQ, i.e.
say, send me any certificate, I do not matter what it is, just send me
it, so I can get the public key out from there. At least SSH Sentinel
did that, and I think there were also other products out there to
support that kind of usage. 

> folks who already have done the PKIX work would want to just re-use 

I agree. Perhaps we could say that you could either use CERT payloads
with certificates, but if you support bare RSA key CERT formats, use
that too (i.e. send two CERT payloads if you support both of them). 
-- 
[email-masked]

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Sat Nov 27 13:45:02 2004

> not care about the cert verification, than to add new support for bare

This was my reason for favoring certs over bare keys, but it's really
shaping up as six of one or half a dozen of the other.

> Out of band bare RSA key delivery. 

That won't do for this protocol.  We'll need a CERT for this.  Not that
that is a big deal, mind you.

[...]
> that too (i.e. send two CERT payloads if you support both of them). 

That works for me.

Nico
--

---

From: mcr at sandelman.ottawa.on.ca ([email-masked])
Date: Sat Nov 27 17:44:28 2004

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

    >> > > which could offer us implementations > >faster, but there are
    >> also implementations out there supporting bare > >RSA keys.  >
    >> Again, I'll ask: how?
    >> 

    Nicolas> That won't do for this protocol.  We'll need a CERT for
    Nicolas> this.  Not that that is a big deal, mind you.

  When you write "CERT", do you mean an IKEvX CERT payload?
  Or a "certificate"?

- --

---

From: kent at bbn.com (Stephen Kent)
Date: Mon Nov 29 08:37:46 2004

>A new cert type. We got that in IKEv2, but never agreed to it in IKEv1.

A raw public key is not a cert, so it would be preferable to not 
carry it in a payload type the name of which suggests otherwise.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Mon Nov 29 08:37:50 2004

At 11:12 AM -0800 11/24/04, Paul Hoffman / VPNC wrote:
	<SNIP>
>standpoint to keep the paths completely separate.

I don't think processing for self-signed certs will necessarily 
entail a significant code change, based on the PAD design I'm working 
on now, but we'll have to see what implementors say when they see the 
text.

Also, as Tero noted, part of the argument that Joe made for BTNS was 
as a path to use of PKIs vs. pre-shared secrets. Use of self-signed 
certs is consistent with this argument; use of raw keys is not.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon Nov 29 09:23:50 2004

>   When you write "CERT", do you mean an IKEvX CERT payload?

CERT type and payload.

---

From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Mon Nov 29 09:47:43 2004

>carry it in a payload type the name of which suggests otherwise.

It's a bit late to be suggesting this. IKEv2 does exactly that, and 
it seems silly to do it differently in IKEv1, if we go that route.

--Paul Hoffman, Director
--VPN Consortium

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon Nov 29 10:11:47 2004

> it seems silly to do it differently in IKEv1, if we go that route.

That's my reading of IKEv2 as well.  Here's the list of CERT types:

           RESERVED                             0
           PKCS #7 wrapped X.509 certificate    1
           PGP Certificate                      2
           DNS Signed Key                       3
           X.509 Certificate - Signature        4
           Kerberos Token                       6
           Certificate Revocation List (CRL)    7
           Authority Revocation List (ARL)      8
           SPKI Certificate                     9
           X.509 Certificate - Attribute       10
           Raw RSA Key                         11
           Hash and URL of X.509 certificate   12
           Hash and URL of X.509 bundle        13
           RESERVED to IANA                  14 - 200
           PRIVATE USE                      201 - 255

Note "DNS Signed Key," "Raw RSA Key" and even "Kerberos Token."
Definitely not certificates.

Rather than invent a new payload we should admit that "CERT" and
"CERTREQ" have come to be misnomers :)

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Mon Nov 29 11:23:48 2004

>it seems silly to do it differently in IKEv1, if we go that route.

Whoops, I missed that misuse of nomenclature!

never mind.

Steve

---

From: kivinen at iki.fi (Tero Kivinen)
Date: Tue Nov 30 02:36:17 2004

> Whoops, I missed that misuse of nomenclature!

RFC 2408 says "The Certificate Payload provides a means to transport
certificates or other certificate-related information...".

I have always interpreted that text so that it does not really mean
certificates in the X.509 sense, but certificates as a blob giving
some kind of constant information which is needed to do the
authentication (i.e. constant in a sense that it is not specific to
this exchange or session).

The AUTH payload have the session specific authentication data, CERT
payload has the data needed to be able to authenticate the AUTH
payload (i.e. public keys, certificates, kerberos tokens etc). The ID
payload contains the identity of the other end and CERT payload should
bind that ID to the AUTH (with bare keys the ID will probably be
something like the hash of key etc, so that binds them together). 
-- 
[email-masked]

---

From: kent at bbn.com (Stephen Kent)
Date: Tue Nov 30 06:47:55 2004

>something like the hash of key etc, so that binds them together).

Yes, the generic wording in IKE v1 and now the broader set of data 
types under the term CERT in IKE v2 clearly encompass other, non-cert 
data.  It's a pity that these documents have chosen to use the term 
so loosely, as it only serves to confuse people in the long run. But, 
as Pal points out, it's a bit late in the process to fix this now.

The term AUTH is more appropriately used in IKE in that the data is 
in support of authentication.

Steve

---

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

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

>>>>> "VPNC" == VPNC  <Paul> writes:
    VPNC> Again, I'll ask: how? What CERT payload number?

  It would be best to have a new one, even for self-signed CERT situation.

    VPNC> It is not so clear. The syntax for saying "I am going to use a
    VPNC> self-signed cert" have never been standardized. What does the
    VPNC> CERTREQ look like? Should there be a CERTREQ at all? How does
    VPNC> the responding party say "yes, I'm willing to do this"? All of
    VPNC> that can be answered, but none of it has been

  Me... I'd want a new CERTREQ type. In it, I'd put the bare RSA public key
that I think *you* are. (i.e. the "you jane" part of Me-Tarzan-You-Jane).

    >> That could give us implementations faster than using raw keys.

    VPNC> I'm OK with this. Said another way, if message and and 2 have
    VPNC> a BTNS-specific VendorID payload, that means that there will
    VPNC> be no CERTREQ and that a PKIX cert received should only be
    VPNC> parsed for its key and everything else in the key is
    VPNC> ignored. That still means a bit more code for implementations
    VPNC> that haven't done PKIX certs just to parse the cert, but that
    VPNC> can be done by hand without an ASN.1 module. It's ugly, but it
    VPNC> could work.

  Do not forget SSH-style leap-of-faith, with storage of the key.

    VPNC> I would still prefer a new bare-key payload, but can
    VPNC> understand why folks who already have done the PKIX work would
    VPNC> want to just re-use it.

  I have both code.
  I prefer bare-key.
  I willing to compromise.

- --

---

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

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

  [just read 250 emails on anonsec... Slowly catching up after IETF]

>>>>> "Tero" == Tero Kivinen <[email-masked]> writes:
    >> So, are there any reasons we should be using self-signed certs? 
    >> Do they outweigh the list above?

    Tero> I consider bare RSA keys and self-signed certs about the
    Tero> same. I do not really see any real difference in
    Tero> them. Self-signed certs are already implemented in the IKEv1,
    Tero> which could offer us implementations faster, but there are
    Tero> also implementations out there supporting bare RSA keys.

  As the maintainer of one, I can tell you that pre-exchanged bare RSA
keys is a major godsend. In teaching students how to do this, they
rapidly realize how easy it is to set up systems this way.

    Tero> The self-signed certificates do offer one advantage over bare
    Tero> RSA keys: There is a clear incremental upgrade path towards
    Tero> using better authentication.  

  I partly agree.
  I partly disagree.
  
  For the gateway that already has the ASN.1 code, it is clearly an a
code savings. For the handheld (or smaller) device that is going to use
channel binding, or which just wants protection from RST attacks, it
(the PKIX certificate chain code) is code that I'd want to remove. 

  Paul Hoffman made the best argument: the certificate chaining code is
already complex. Adding a new path may be a mistake. 
  So I predict that smart implementers will implement the "BTNS" key
handling code seperately from their certificate chain code. That is a
good way to compartmentalize the complexity well.

  Incrementally upgrades are certainly important.
  One proposal is to send two things:
      a) a raw RSA key.
      b) a certificate (and/or chain) -or- reference to one.

  This could be as *TWO* CERT payloads.
  i.e. the raw RSA key is always there. The thing that tells you whether
or not to trust it is not always there. (b) is clearly PKI4IPSEC stuff.

- --

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue Nov 30 23:37:56 2004

> rapidly realize how easy it is to set up systems this way.

Does your implementation do this with IKEv1?

And if your implementation does this with IKEv2, does it use the "Raw
RSA Key" CERT, and is it really a requirement that the keys be
pre-exchanged or is that requirement dependent on what ID is asserted by
the peer using a raw RSA key?

I hadn't noticed the IKEv2 "Raw RSA Key" CERT type until recently.

For IKEv2 it may be that the combination of ID_KEY_ID and bare RSA keys
is enough that all we need to do for unauthenticated IPsec w/ IKEv2 is
describe how to use it.  Unfortunately the text in the IKEv2 I-D about
ID_KEY_ID is not very helpful.

For IKEv1 it may be that all we need to do is specify the missing bare
key CERT.

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue Nov 30 23:46:19 2004

>   It would be best to have a new one, even for self-signed CERT situation.

The question, IIRC, was about how your implementation *does* it
currently with IKEv1, not about how best to do it :)

> that I think *you* are. (i.e. the "you jane" part of Me-Tarzan-You-Jane).

This doesn't make sense for unauthenticated IPsec.

Nico
--

---

From: mcr at sandelman.ottawa.on.ca ([email-masked])
Date: Wed Dec 1 03:44:23 2004

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

  I partly agree.
  I partly disagree.

- --