Subject: Re: [NSIS] Key management

From: Bob Braden <[email-masked]>
Date: Thu, 7 Nov 2002 18:38:09 GMT

*> 
  *> I think we're arguing the same thing, but it still comes
  *> back to decisions that are made in the framework.  For
  *> example, if the transport layer is keying hop-by-hop but you
  *> want NSIS applications (say, NAT communication) to be able
  *> to do bidirectional authentication, you face the problem of
  *> getting keys between the NAT, which may be more than one hop
  *> away from the NSIS initiator, and the NSIS initiator
  *> itself.  
  *> 

Melinda,

Hmmm.  Isn't this just another NAT breakage?  Is there a solution to
the problem of authentication through NATs?  Is the problem of
NAT interaction with hop/hop security of signaling fundamentally
different from NAT interaction with, say, IPsec?  I ask because I
really don't understand the problem space here.

Thanks,

Bob
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Melinda Shore <[email-masked]>
Date: Thu, 07 Nov 2002 13:59:26 -0500

> really don't understand the problem space here.

There are several NAT-related problems with IPSec, and I
don't think they necessarily relate here.  One is the
well-known AH problem.  One that's more closely-related and
maybe could be used as an object lesson in what not to do is
that NAT breaks IKE phase 2 - the addresses being used as
in the ID payload are the inside-of-the NAT addresses.  To
be honest I haven't been following how this is being
fixed by the ipsec working group - I need to check it out.

For identity authentication we're going to match who they
say they are (probably a string of some sort) with the key
that they're using, so we don't depend on addresses at all.
We may even end up relying on certs.  Some of this is going
to depend on how discovery and routing are handled.  I
continue to think that this is something that RSVP got
right, or at least I think it will work for our purposes as
I outlined in the couple of drafts I've written on the
topic.  

Aside from the question of what we use as the basis for
identity I think that we're far, far more likely to be able
to work with NATs if the NATs participate - that is to say,
we can talk to them, authenticate them, and ask them what
our external address will be (for the purposes of embedding
in the payload and calculating whatever checksums or HMACs
are needed).

Melinda

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 8 Nov 2002 09:51:40 +0100

hi melinda!

i agree with you that there are problems with nat and ipsec. for a nsis
signaling protocol nat is generally a problem - not only for ipsec. even if
you get a proper security protection (which is possible) then you still have
the problem that you make a reservation for the wrong data traffic. i should
also be pointed out that tunneling solutions to fix this problem have been
proposed. furthermore it should be noted that the problem depends how you
deploy a nsis protocol and nats. if the nat is nsis aware then there does
not seem to be a problem.

your remark regarding rsvp was not clear to me. in rsvp you select your key
for the integrity object based on an ip address.

ciao
hannes

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Melinda Shore
> Sent: Thursday, November 07, 2002 7:59 PM
> To: Bob Braden
> Cc: [email-masked]
> Subject: Re: [NSIS] Key management
>
>

---

From: Melinda Shore <[email-masked]>
Date: Fri, 08 Nov 2002 08:28:23 -0500

> for the integrity object based on an ip address.

That's what RSVP does but it needn't be what NSIS does.
And again, we'd need to separate out what's done in the
application vs. what's done in the transport, but I think
it's pretty clear that for an application that expects that
it may have a NAT in its path it's undesirable to use an IP
address as the basis for identity.

Melinda

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 8 Nov 2002 17:37:04 +0100

hi melinda!

> That's what RSVP does but it needn't be what NSIS does.
this is certainly a good point. 

> address as the basis for identity.
true. whenever possible one should avoid using ip addresses as identities. 

ciao
hannes