[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



splitting this thread into two subject-specific threads for easier
following...

On revised Identities...

Having spent many many months trying to pull together all the PKI vendors
and all the IPsec vendors to figure out how to better handle and deploy
certificates for IPsec VPNs (Project Dploy, www.projectdploy.com), I can
offer these points:
(1) I'm being very generous if I say that only 10% or less of IPsec
deployments use Certs. 90% or more use Pre-Share Secrets. And cert
(2) The PKI vendors have mostly given up on the VPN application space. They
are not doing new development, nor heavy marketing focus, to make the VPN
application work better. And they will not.
(3) If we want to make IPsec with Certificates easier, we have to do it
within the IPsec space. 
(4) We need to make sure that whatever we do, preshare secrets are really
easy to use, since most all the deployments use them.

Identity was very troublesome in v1. It would seem a shame to miss an
opportunity to simplify it.

The current text is a move in the right direction. Perhaps it lacks enough
explicit justification/explanation text in its current form to be fully
usable. I would definitely want to see it beefed up to remove ambiguities
that arose for me when I first read it. But it is a definite simplication
for the part that affects over 90% of the market, those using pre-share
keys.

With these points in mind, here is my input on the current Revised
Identities text:
- Making the IDforSharedSecret a pure string is a great solution. Using four
methods (IP, 822-name, FQDN, DN) in v1 was a fiasco. Regardless of what the
RFCs said, some vendors checked the receiving packet/cert for a match of the
ID type to the ID presented in the ID payload, and some did not. This caused
a lot of problems. Decoupling the ID string from these 4 elements will help.
Not that you can't still use any of these things as a sting, just that now
we all agree to read it as a string in this one place alone. And that's it.
Easy!! This will help both implementors and users a ton.

WRT certs (which only pertains to <10% of the installations)...
- the mechanism for using/sending/finding certs and chains makes it
extrememly explicit which cert to use, and how get it.

- the mechanisms provided will allow certs to be used for many different
applications, bandwidths, memory capabilities, etc. wrt the platforms in use
and their connectivity (think hand-helds, consumer electronics, etc).

- the responsibility is now 100% on the part of the recipient to determine
what elements within the certificate she wants to use to match identity.
Interoperability issues regarding *determining* the identity will
essentially go away, from an ipsec implementor perspective. Issues wrt what
fields in the cert should be used and how should likewise go away. As long
as the implementation can parse the cert, and provide the user with a UI
that allows them to select various fields to check and enter the strings to
check for, it will work. Responsibility will move to the operator of the
IPsec to determine what contents in the certs (that they are creating) they
want to use as identity. The implementor will need only to make sure that in
the UI the user can specify any of the possible cert fields to match.

- The cert itself is the identity wholly and completely. The implementation,
based on configuration by the user, will check whatever fields, combination
of fields, or all, of the cert in order to perform the lookup in its local
db for a match on identity. It's up to the user now, not the
implementation's interpretation of the RFC. It's explicit!

In summary:
* Let's take the opportunity now, while we can, to dramatically simplify
identity proposal. This is especially true for IDforSharedSecret, which is
90%+ of the installations going out. 

* Let's try to add some justification/explanation text to what's there today
so that people understand it better. This would especially be true for HOW
TO USE the cert-included elements (options 1-5).

Gregory.




> -----Original Message-----
> From: Derrell Piper [mailto:ddp@electric-loft.org]
> Sent: Wednesday, February 05, 2003 3:46 PM
> To: Theodore Ts'o
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Moving forward with IKE V2: A proposal for final edits to
> ikev2-04
> 
> 
> For purposes of consensus, here's my take on the two topics that Ted 
> and Barbara have asked for comments on.  A friend once 
> remarked to me, 
> "Go not to the elves for advice for they will say both 'yes' and 
> 'no'..."
> 
> RE: revised identity
> 
> First, I sympathize with Cheryl and Scott in that we've been avoiding 
> the larger problem from the start and it has continued to 
> plague us at 
> interoperability workshops.  The lack of consideration for proper PKI 
> integration is one of IKEv1's biggest omissions, that's 
> clear.  And yet 
> here we are several years down the road and we still haven't 
> been able 
> to do anything about it.  So, is now the right time and place to deal 
> with it?  Perhaps, but only if there were very strong 
> consensus amongst 
> existing vendors.
> 
> I think revisions to the IKE ID specifications will be needed at some 
> time in the future.  The existing ID definitions are vague and ad hoc 
> and yet we've still managed to garner a fair amount of 
> interoperability 
> despite it all.  It hasn't necessarily been pleasant or easy, 
> but over 
> time most IKE implementations now do interoperate.
> 
> Would the proposed identity revisions make things so much better that 
> it would clear up some large majority of PKI interoperability 
> problems? 
>   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.
> 
> 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.
> 
>  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.  Anyone who lived through those early bake-off's would not 
> want to go back there.  Well, except for Big Al's BBQ Shack, 
> perhaps.  
> :-)
> 
> Finally, if we're taking our deadline seriously, I don't think we're 
> anywhere near consensus on what a revised identity proposal entails.  
> Given the traffic just this week, there are many suggestions beyond 
> what was originally discussed on the list last fall.  Are 
> there simple 
> PKIX mappings?  Are there simpler alternatives?  IMHO, it's unlikely 
> we're going to agree on such fundamental changes to identity 
> representation in the next week.  I think we should keep working on 
> this as we should keep working on the PKI profile.  But these 
> items can 
> occur orthogonally to IKEv2.
> 
> In summary, our strategy of ignoring this has worked so well in the 
> past that I recommend we continue it a while longer.
> 
> RE: configuration mode vs. dhcp relay
> 
> I'm on the fence with this one.  I see good arguments for both 
> approaches: there are simplicity arguments for MODECFG and there are 
> richness arguments for DHCP.  FWIW, the implementation I previously 
> worked on was much closer to MODECFG.
> 
> I'd welcome proposed text that explicitly shows the IKEv2 changes to 
> support RFC3456.  If we had that we could make a reasonable choice 
> between the two.  But absent that, I think we should pursue 
> what we've 
> got now and be willing to revisit this issue in the future.
> 
> It's not an option to do nothing.  IKEv2 needs a defined mechanism to 
> dole out internal addresses to remote clients and MODECFG has been 
> written up for IKEv2 and shown to work in IKEv1.  IKEv2 is not viable 
> without remote client support.
> 
> Regards,
> 
> Derrell
> 
> On Thursday, January 30, 2003, at 02:57  PM, Theodore Ts'o wrote:
> 
> > If you feel otherwise, please speak now.
> >
> > A)  Revised identity
> > --------------------
> >
> > Paul Hoffman has a proposal, 
> draft-ietf-ipsec-revised-identity-00.txt,
> > which radically changes how identities are handled.   
> Specifically, it
> > would eliminate the ID payload with the following types:
> >
> >       ID_IPV4_ADDR                        1
> >       ID_FQDN                             2
> >       ID_RFC822_ADDR                      3
> >       ID_IPV6_ADDR                        5
> >       ID_DER_ASN1_DN                      9
> >       ID_DER_ASN1_GN                      10
> >       ID_KEY_ID                           11
> >
> > et.al, and replaces it with a FullID payload with the 
> following types:
> >
> > 	1  PKIX certificate
> > 	2  Certificate bundle
> > 	3  Hash-and-URL of PKIX certificate
> > 	4  URL to a PKIX certificate bundle
> > 	5  PKIX keyIdentifier
> > 	6  IDForSharedSecret
> >
> > This would be fundamental change in the management and 
> administraton of
> > IPSEC and IKE, so is not something to adopt lightly, and without a 
> > clear
> > consensus of the working group.  This was discussed in two 
> threads on
> > the IPSEC mailing list: one starting on November 5th (subject Adding
> > revised identities to IKEv2), and one starting on December 8th 
> > (subject:
> > Summary of revised identity changes).  People who spoke in 
> favor on the
> > mailing list included Francis Dupont and Bill Sommerfeld, with 
> > qualified
> > support from Michael Richardson (if support for bare keys 
> is added) and
> > Tero Kivinen (who is concerned about the complexity of the 
> proposal).
> >
> > This proposal was discussed in Atlanta, but Charlie, 
> Barbara, and Ted
> > were left with the impression that there was not consensus 
> among those
> > who met to discuss legacy authentication after the IPSEC wg 
> meeting to
> > pursue adoption of Paul's proposed change.  Paul believes otherwise.
> > Since it is the job of working group chairs to determine 
> consensus, we
> > (Barbara and Ted) hereby ask that those who believe we 
> should pursue 
> > the
> > revised identity proposal to please speak up.
> >
> > It should be noted that there are some intermediate positions beyond
> > what is currently in draft-ietf-ipsec-ikev2-04.txt and the
> > revised-identies draft.  For example, we could add the Hash-and-URL 
> > type
> > to the Certificate payload, if the goal is shrink the size of IKE
> > messages (with the tradeoff of increasing complexity in IKE
> > implementations).   We could also add a CERT hash type to the ID
> > payload, without nuking the traditional FQDN or IPv4/6 addresses
> > identity mechanisms (although again, by adding new types, 
> we would be
> > increasing the complexity of the specification and implementations).
> >
> > Due the relatively small number of people who have spoken 
> in favor of
> > this proposal or its less-radical alternates, the default choice for
> > IKEv2 has to be what is currently in ikev2-04.  So those 
> who believe we
> > should make this change (or those who strongly believe we 
> should not)
> > are requested to speak up now, or forever hold your peace....
> >
> >
> > B) DHCP-based vs. MODECFG style remote access configuration
> > -----------------------------------------------------------
> >
> > Currently, draft-ietf-ipsec-ikev2-04.txt handles remote access via a
> > Configuration payload with defined attributes.  An 
> alternate mechanism
> > involves using tunneled DHCP requests.  The latter approach 
> is about to
> > be published as an RFC by the IPSRA working group.  
> Proponents of this
> > method argue that it is more powerful than modecfg (because of the
> > extensibility and large number of options already specified 
> for DHCP;
> > for example, being able to specify DNS, time, print, or 
> WINS servers,
> > and so on.)  It is also argued that it requires less code on the
> > server/firewall, since an existing DHCP server can be used.
> >
> > Proponents of the modecfg approach argue that many implementation
> > already have support for modecfg, and that setting up sort-lived
> > specialized tunnels to allow the DHCP packets to flow through the
> > gateway is kludgy, and requires multiple special case entries into
> > packet forwarding tables.  Modecfg proponents also argue that it is 
> > also
> > possible to transform modecfg requests into DHCP requests, 
> so there are
> > implementation choices that do not require reimplementation of the
> > DHCP's address assignment function.  They also point out that it
> > certainly is possible --- and in some ways easier --- to obtain the
> > time, print, WINS server information by using DHCP (via the 
> DHCPINFORM
> > request) after the IPSEC tunnel is setup and the client address is
> > assigned.
> >
> > Either approach seems to be workable.  It is certainly true 
> that most 
> > of
> > the people in Atlanta were implementors who were already 
> familiar with
> > modecfg, representing a large implementation community.  That being
> > said, there is also some number of working group members that are in
> > favor of an approach similar to draft-ietf-ipsec-dhcp-13, 
> including Van
> > Aken Dirk, Michael Richardson, and Scott G. Kelley.   One way or
> > another, however we need to make a choice and move forward.
> >
> > Given that we have a fully specified solution in the 
> ikev2-04 draft, 
> > and
> > it would seem that while there is a sizeable minority in 
> favor of the
> > ipsec-dhcp-13 approach, the majority are comfortable with 
> the modecfg
> > based approach.  So at this point, we, as working group 
> chairs, judge
> > that the consensus is with the current approach.
> >
> > If there are those who feel otherwise, or who see fatal 
> problems with
> > the current approach, please speak now.
>