Subject: RE: On revised identity (was "Moving forward...final edits...)

From: Michael Choung Shieh <[email-masked]>
Date: Thu, 6 Feb 2003 20:03:43 -0800

I have different view on this.  The purpose of revised identity draft is to
address the issues when using certificate.  However, I think most of the
confuse comes from lack of clarification on how to deal with identity
payload (similar to what draft-ietf-ipsec-pki-profile-01.txt does).  Replace
it with new set of identity won't get any better without clear and detailed
clarification of the usages.

my comments on FullID payload:
1. For type 1 (standalone certificate), why it's better than ID_DER_ASN1_DN?

2. FOR type 3 (hash and URL), is it dangerous that the gateway will try to
do http with innocent party with instruction of unauthenticated peer?

3. For type 6 (IDForShareSecret), if both sides know the ip address of the
peer and try to convert their ip address into ascii string, they may have
different translation (eg. "::3:1" vs "00::03:01" in IPv6).  

=======================
Michael Shieh

-----Original Message-----
From: Gregory Lebovitz [mailto:[email-masked]]
Sent: Thursday, February 06, 2003 11:03 AM
To: 'Derrell Piper'; Theodore Ts'o; [email-masked]
Subject: RE: On revised identity (was "Moving forward...final edits...)

Derrell, thanks for taking the lead to summarize this for us.

Comments on your summary within...

> -----Original Message-----
> From: Derrell Piper [mailto:[email-masked]]
> Sent: Wednesday, February 05, 2003 3:46 PM
> To: Theodore Ts'o
> Cc: [email-masked]
> Subject: Re: Moving forward with IKE V2: A proposal for final edits to
> ikev2-04
--SNIP-- 
> 
> Would the proposed identity revisions make things so much better that 
> it would clear up some large majority of PKI interoperability 
> problems? 

It would make the IDforSharedSecret completely straightforward, which
addresses 90%+ of the deployments going out.

For those very few deployments that use certs, it makes using certs more
efficient (don't have to send the cert every IKE exchange). It also removes
the issue of how to configure and what to configure in the various cert
fields a non-issue for the protocol. The user can specify whatever they want
wherever they want in the cert, and as long as the implementation allows
them to, via UI, select and match those fields' contents, it will work.

>   I don't think so.  I think most of the problems are due somewhat to 
> the inherent complexity of certificate-based PKI 
> interoperability and, 
> moreover, to the lack of a defined PKI profile for IKE.  I happen to 
> think there's more value in defining a PKI profile, such as the one 
> described in, draft-ietf-ipsec-pki-profile-01.txt.  We don't need 
> revised identities to do that.  It seems similarly clear that revised 
> identities would bring with them a new and entirely different set of 
> interoperability issues.

Regardless of revised identities, we definitely need a cert profile, but the
total amount of things we need to specify in the cert profile for v2 will be
much less than the equivalent document for v1.

> I have concerns that the management paradigm for many vendors is very 
> closely tied to the existing IKE identity types, so wholesale 
> revision 
> in this area might well represent a serious headache for many 
> vendors.  
> The impact of the protocol changes is largely transparent and 
> the other 
> revisions ought to mostly present themselves as elimination of 
> unnecessary configuration options.  Deleting things is 
> relative easy.  
> But I can see how wholesale identity revision might seriously impact 
> much of the existing management software, end-user documentation, and 
> vendor regression testing.  I think we do need to be concerned about 
> fielded implementations.

This is a great point. Must of us have already developed extensive and
complicated management stuff to get around the perplexity of the v1 protocol
wrt identity and certs. I agree, we would have new work to do, mostly
because the new way would be so much easier. 

Also, the UI's would become cluttered, as now we would have to have 2UI's,
one for v1 support and one for v2 support.

>  From an implementation standpoint, I also worry about combining 
> something like identity revision with all the other IKEv2 changes.  
> You'd essentially be starting from scratch at the next bake-off.  Now 
> I'm not going to claim lots and lots of code reuse between IKEv1 and 
> IKEv2, yet there is some overlap.  But if you completely rototill the 
> identity processing on top of this, you're very close to 
> starting from 
> scratch.  

another good point. The only consolation is that what we'd be starting from
would appear to be MUCH more direct. We would only need to focus on interop
for the format of how we send options 0-5, and not so much the content of
the certs themselves, as that would be an UI matching issue.

> In summary, our strategy of ignoring this has worked so well in the 
> past that I recommend we continue it a while longer.

agreed that we possibly cannot get full consensus, or fully completed text
on this in one week. But I do think we should forgoe the re-work agreed to
above, and fix the protocol know while we still can.

Gregory. 

!! NETSCREEN IS MOVING !! 
New Contact Info starting 2/10:
805 11th Ave, Bldg 3
Sunnyvale, CA  94089
408.543.8002 

+*******************++********************+
Gregory M. Lebovitz
Staff Architect, CTO Office
NetScreen Technologies, Inc.
Ph:   408.730.6002
E:     [email-masked]
Pg:   [email-masked]
NASDAQ:  NSCN
+*******************++********************+

---

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 7 Feb 2003 11:26:45 -0500

> do http with innocent party with instruction of unauthenticated peer?

Well, the server can have an access list of what web servers it will
allow itself to contact on the instruction of an unauthenticated peer,
but it does add additional complexity to the implementation and the
configuration load of the IPSEC product.  In addition, if vendors
leave the default ACL such that any arbitrary URL will be visited by
the server, yes, that could lead to some very entertaining
opportunities from the point of view of potential attackers.

However, it's actually worse than that from the client's perspective.
In some cases, the client will not have access to the internet
beforehand.  For example, the VPN solution in use by my company,
AT&T's Managed Tunnel Service, has two modes.  In one mode, an
existing Internet connection is used to connect to the MTS server, and
the client does have the capability to make arbitrary HTTP requests
before the VPN connection is made.  In the other mode, the client is
calling (over the POTS network) a modem bank, and is not permitted,
for obvious reasons, to have general internet access before completing
the initial setup with the VPN.

So in this case, it cannot possibly work from the perspective of the
client, since in this case the client doesn't have even an IP address
(because DHCP or the Configuration payload negotation hasn't happened
yet).  In the case of AT&T Managed Tunnel Services, the VPN gateway
could chose to use different ID types based on how the initial
connection was made, but that would add complexity to its
architecture/implementation --- and so I wonder if an implementor
might simply chose not to use hash/URL at all, and just simply send
the entire certificate chain each time.

(In other cases, some company's security organizations have
regulations that say that a laptop is may not make -- and must be
configured to not allow --- arbitrary connections over internet while
it is connected to the VPN.  Whether or not the I/T security folks
would be happy with the Road Warrior's laptop making unsecured
connections to the Internet *just* *before* connecting through the VPN
is a different questions.  I suspect some might get heartburn over
this issue, customers will probably demand that whether or not
hash/URL scheme can be allowed at all must be a site configurable
option.)

Basically, a hash/URL scheme can be made to work (and could be added
to either the existing ikev1/ikev2-04 framework, or in the revised
identity draft. ).  It is essentially a trade-off between complexity
(in terms of needing an http client engine in an ipsec implementation
plus some specialized rules about when it is and isn't OK to use it,
and what URL's are OK to contact) and the benefit of decreasing the
size of the IKE messages.

Comments about whether this particular engineering trade-off is worth
it is welcome.

						- Ted

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Feb 2003 14:16:24 -0500

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

>>>>> "Theodore" == Theodore Ts'o <[email-masked]> writes:
    Theodore> Tunnel Services, the VPN gateway could chose to use different
    Theodore> ID types based on how the initial connection was made, but that
    Theodore> would add complexity to its architecture/implementation --- and
    Theodore> so I wonder if an implementor might simply chose not to use
    Theodore> hash/URL at all, and just simply send the entire certificate
    Theodore> chain each time.

  yes, I'm sure that this will be the case. So what?
  You've just argued for why we need to be able to do things inline for 
intra-enterprise use.

  Frankly, I don't know why this situation is even mentioned. The laptops
have to be configured with a trusted root, and you need configure only one of
these. For the static situation where you only talk to one gateway, this is
trivial.

  For the more complicated situation where you need to be connected to the
mothercorp's gateway, and the gateway of the people you've been assigned to
help that week, you already have a significantly more complicated policy than
you described.

  The ability of the laptop to refer to their certificate *chain* indirectly
is of great use to the gateway, because the chain can be as sophisticated as
you like. 

  The hash/URL scheme is very useful for larger *VPN*s of equals -
particularly for cross-enteprises systems.

    Theodore> Basically, a hash/URL scheme can be made to work (and could be
    Theodore> added to either the existing ikev1/ikev2-04 framework, or in
    Theodore> the revised identity draft. ).  It is essentially a trade-off
    Theodore> between complexity (in terms of needing an http client engine
    Theodore> in an ipsec implementation plus some specialized rules about

  Btw, who said anything about needing the http client in the IKE?
  For all you know, the whole thing is passed on to a policy server that may
be an order of magnitude more complex.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [