Fwd: Re: Adding revised identities to IKEv2

[Stuart Jacobs <stu.jacobs@labs.gte.com>]

>Date: Wed, 13 Nov 2002 10:07:22 -0500
>From: Uri Blumenthal <uri@lucent.com>
>Organization: Lucent Technologies
>X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5  (Windows NT 5.0; U)
>X-Accept-Language: en,pdf
>To: Stuart Jacobs <stu.jacobs@labs.gte.com>
>Subject: Re: Adding revised identities to IKEv2
>
>Stuart,
>
>Your e-mail went only to me. So if you want it to
>be seen by the IPsec mailing list - you'd have to
>forward it there.
>
>Thanks!
>
>Stuart Jacobs wrote:
> >
> > I like what Uri is suggesting, namely:
> > "And I want a relaxed identification - something like "as long as
> > >I can associate a key with the identity, the identity is OK"."
> >
> > This approach could allow ESP protected packets to easily traverse NAT
> > since the Destination IP address in the responder's SA table is only used
> > as an address for sending packets back to the initiator and would be the
> > NAT public IP address and NAT assigned port number that the NAT will map
> > back to the actual private IP address of the recipient.  What this would
> > necessitate is that during IKE, once the identity of the initiator is
> > authenticated, the source IP address and port number of the responder
> > received packet is stored and used when the responder wants to send a
> > packet to the initiator.
> >
> > At 11/12/02 05:02 PM, you wrote:
> > >Stephen Kent wrote:
> > > >
> > > > As many of you know, I try to avoid the T-word (trust) in almost all
> > > > security technology discussions. I'd like to suggest that it is
> > > > inappropriate in this discussion as well.
> > >
> > >Fully agree. Trust is about authorization, which is not IPsec's
> > >domain (IMHO).
> > >
> > > > - two IPsec peers do not necessarily trust one another. they
> > > > need to communicate securely, but that does not equate to
> > > > trust in a broader sense.
> > >
> > >Agreed.
> > >
> > > > - with regard to identities, IPsec supports two basic types
> > > > of identities: addresses and symbolic names.
> > >
> > >And symbolic names IMHO is the only way to establish/authenticate
> > >a secure connection in a dynamic environment.
> > >
> > > > - when names are used as identities, we need to be able to
> > > > map the name to a current address (during SA establishment) so that
> > > > we can make later decisions on a per-packet basis using the current
> > > > address.
> > >
> > >Absolutely. But start from symbolic names, and map them to IP address
> > >for Phase 2. Seems easy/trivial to implement.
> > >
> > > > - we don't have to trust an IPsec peer to assert the right
> > > > name for itself or an entity behind it. we need to have an
> > > > authentication mechanism that allows us to verify that the asserted
> > > > name is valid relative to some framework for names.
> > >
> > >Oh sure. If I say the entity name is "Uri Blumenthal" - then there
> > >has to be a key/cert associated with that name. As it only matters
> > >for signing the Phase 1 exchange to validate IP address from which
> > >the traffic is originating, for subsequent Phase 2 things.
> > >
> > > > I suggest that we better document these notions, and offer as
> > > > examples, the sort of identification and authentication processes
> > > > I note above as we go forward with IKE v2.
> > > > Comments?
> > >
> > >I strongly support.
> > >
> > >And I want a relaxed identification - something like "as long as
> > >I can associate a key with the identity, the identity is OK".
> >
> > ==========================
> > Stuart Jacobs CISSP
> > PMTS - Sr. Technologist
> > Verizon Laboratories
> > 40 Sylvan Road Waltham, MA 02451-1128     USA
> > telephone: (781) 466-3076   fax: (781) 466-2838
> > stu.jacobs@labs.gte.com sjj0@labs.gte.com  stu.jacobs@verizon.com
> > ==========================

==========================
Stuart Jacobs CISSP
PMTS - Sr. Technologist
Verizon Laboratories
40 Sylvan Road Waltham, MA 02451-1128     USA
telephone: (781) 466-3076   fax: (781) 466-2838
stu.jacobs@labs.gte.com sjj0@labs.gte.com  stu.jacobs@verizon.com
==========================