Subject: Re: Moving forward with IKE V2: A proposal for final edits to ikev2-04

From: [email-masked]
Date: Sat, 1 Feb 2003 22:35:20 -0500

"Theodore Ts'o" <[email-masked]> wrote:
> Hugo has suggested that for EAP mechanisms that generate a shared key,
> the responder should send an AUTH message based on the shared key in the
> message containing the EAP(success) message, as backup in case for some
> reason the CERT based exchange might have gotten spoofed somehow.  This
> seems to me to be a case of gilding the lilly, and is probably not be
> worth the extra complexity, but I encourage comment on the working group
> about whether or not this additional twist should be included.

I agree with Hugo on this one. We've been assuming that legacy auth is
always going to have the responder first authenticating to the
initiator with certificates the initiator will know how to process.
But I can imagine cases where legacy auth is mutual and the cert
based authentication is only a formality (or perhaps skipped). For
example, a legacy auth scheme based on EKE, SPEKE, SRP, or PDM
might have this property. What do others think?

Hugo Krawczyk <[email-masked]>  wrote:
> The one thing that I definitely dislike in the appended proposal is that
> it opens IDi (sent in message 3) to active attacks.  If there is one
> application where identity protection really makes sense is in hiding
> identities and locations of mobile users, which will be among the main
> users of SLA. I suggest to make IDi optional in message 3, and make it
> clear that implementations should NOT assume that this IDi value is
> available, certainly not in a way that compromises the user's identity.

I am genuinely conflicted about this one - like the donkey between the
two bales of hay. I see equally good arguments on both sides, and I don't
think it matters much. But it does matter that we decide.

If IDi is included in message 3, it is exposed to active attacks.
(Someone impersonating the gateway can learn the claimed name of the
initiator and subsequently break the connection). We decided we
could live with that for cert based authentication, but if the
case for preventing it is a little stronger here. If it is not
included in message 3, then the gateway may not be able to
produce the challenge it needs for message 4 and the protocol could
require an extra round trip. If we make it optional in message
3, the spec has to say (and the implementations have to code
and test) all of the options.

I put a stake in the ground in ikev2-04 and said it was required
in message 3. Do people want it to say something else? Should it
be legacy authentication mechanism specific?

Hugo Krawczyk <[email-masked]>  wrote:
> I have no practical (or other) experience with such key-providing
> legacy authentication methods. However, since these are LEGACY methods
> then I assume that if they generate a shared key then this key may be
> intended for other uses. Can we be sure that this key (call it LK for
> "legacy key"), if used by SLA, will be used ONLY by SLA?  Otherwise we
may
> end having one key LK which is used in two different settings.  In
> particular, one may end using one key LK for two different cryptographic
> algorithms. Are you sure that this is NOT possible?

When an authentication mechanism generates a shared
key as a side effect, it is generally for the purpose of
protecting subsequent data exchanges with that key. When
used in IPsec, it is likely that the subsequent data
exchanges will be protected with IPsec, so the key will
have no uses other than generating AUTH.

That said, who knows what someone might do in the future.
We could specify that using the key for anything else is
forbidden. We could instead of using the key directly
hash it with an IKE-related constant and use the result
as the key. I'd be happy with either of these, though
I believe that both are overkill.

Do you have a concrete proposal for addressing this?

Hugo Krawczyk <[email-masked]>  wrote:
> One other question raised in the appended note is when should the AUTH
> field be sent. Seems to me that the simplest specification is to send it
> in the last client's message in SLA.  Even if this key (LK) is available
> earlier, it does not buy you much to compute AUTH earlier (and you can
> always keep the key for authentication at the end).  An early
> authentication using LK can only help against a DoS attack mounted by a
> MitM attacker; however I doubt that anyone will choose this costly (for
> the attacker) way to to mount a DoS attack.

I didn't say the client's last message because for some legacy auth
methods the exchange is variable length and the client doesn't know
which of his messages will be the last until the server accepts it.

          --Charlie

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Francis Dupont <[email-masked]>
Date: Mon, 03 Feb 2003 16:18:57 +0100

In your previous mail you wrote:

   For this reason, what we propose is that we pick an approach, and be
   done with it.  The question then before the working group is whether or
   not there is another way to accomplish the task, but whether there are
   either (a) fatal flaws in the proposal presented, (b) clear,
   overwhelming advantages to do things a different way (and no handwaving;
   it must be a complete proposal), or (c) minor enhancements that all can
   agree are worthwhile to include in the protocol and worthwhile to
   implement.  Otherwise we will be arguing until the cows come home
   (and/or when the IESG shuts us down, or the mob from problem-statement
   mailing list show up with the pitchforks, tar, and feathers :-).
   
   (SEMI-)CLOSED ISSUES
   =====================
   
   The following issues have been burbling on the list, although in the
   opinion of the IPSEC Working group chairs, there isn't consensus in the
   IPSEC working group to act on them.
   
   If you feel otherwise, please speak now.
   
   A)  Revised identity 
   --------------------
   
=> I am afraid that either we have to include a large part of
draft-ietf-ipsec-pki-profile-xx.txt draft, or to adopt this
revised identity proposal. IMHO this is between (a) and (b).

   B) DHCP-based vs. MODECFG style remote access configuration
   -----------------------------------------------------------
   
=> IMHO IKE should not be involved directly into address
allocation... I propose to ask the IPSRA WG to remove if they'd like
any relevant part from IKEv2 (they should already have strong opinions
and they should like the idea to remove something from an IPsec WG
proposal :-). This is between (b) and (c).

   If there are those who feel otherwise, or who see fatal problems with
   the current approach, please speak now.
   
=> the NAT-DETECTION-*-IP notifications were cut&paste from a draft
for IKEv1 and should be fixed. Fortunately this is easy and we can
extend the fix to a proper address management in IKEv2.
I'd like that the proposal of draft-dupont-ikev2-addrmgmt-00.txt is
included in the next IKEv2: all the section 3 at the exception of
the subsection 3.5 which is a real change and perhaps needs more
discussion.
BTW I have a minor point: my proposed "peer address update" notification
relies on a strong sequencing of IKE messages. The current draft has
only a weak sequencing (weak because the message ID, aka the sequence
number, is not protected), I don't know if this is a global problem,
i.e., if the replay of old messages with a fresh message ID can be
used for real attacks...

Regards

[email-masked]

---

From: "Scott G. Kelly" <[email-masked]>
Date: Mon, 03 Feb 2003 14:29:18 -0800

Yeah - what Cheryl said.

Scott

Cheryl Madson wrote:
> 
> At 10:17 AM 1/31/2003, Paul Hoffman / VPNC wrote:
> 
> >This paragraph means that the many years of on-and-off discussion about
> >the lack of clarity of IKEv1 with respect to what does an ID payload mean
> >when using certificates is now ignored. The fact that there is vastly less
> >interoperability for certificate authentication than for preshared secret
> >authentication (or even XAUTH authentication!) is now irrelevant.
> >
> >According to the WG chairs, IKEv2 should use the same under-specified and
> >non-specified rules for certificate processing as IKEv1.
> >
> >Is this what the working group wants?
> 
> I've gone through *numerous* bakeoffs where vendors have implemented
> different behaviors for various things related to certs. We've had several
> meetings during bakeoffs to discuss this particular issue. Even if the
> vendors are able to come to some sort of consensus during the bakeoff,
> the WG has been extremely apathetic about any attempts to clarify things.
> 
> I argued that one of the requirements should be that any authentication
> mechanism be fully specified in the context of SOI, or not be a candidate
> mechanism. A series of random specs that someone has to figure out
> how to piece together isn't an answer. [I also argued that the protocol
> specification be flexible enough to allow future mechanisms.]
> 
> And I for one would sure hate to see certs excluded as a mechanism;
> I do think it is an extremely useful mechanism.
> 
> But I'm also really tired of having to revisit the same issues years later
> because we can't take the time to figure out in some detail what needs
> to happen and to adequately specify things.
> 
> thx - C
> 
> ====================================
> Cheryl Madson
> Core IP Engineering; Security and Services
> Cisco Systems, Inc.
> [email-masked]

---

From: Hugo Krawczyk <[email-masked]>
Date: Wed, 5 Feb 2003 02:52:47 +0200 (IST)

A few responses below.

> be legacy authentication mechanism specific?

All this business of identity protection was in ipsec from day one since
Phil Karn thought it was essential. Except for a short period of
agreement with this view, this need or no-need for anonymity in ipsec's
key exchange protocol was always a source of debate.
In particular, all past proposals started with mandatory identity
protection and then relaxed it to optional (including Karn's
Photuris). The whole cryptography of the IKE (v1 and v2) protocol
is directed to support identity protection (there are more
straightforward protocols if you do not require id protection).

Was all this mess worth it? I do not know.
But if there is ONE place where identity protection makes sense is in
the remote access environment. ANd then here we are going to give it up?
Either leave it optional in msg 3, or forbid it msg 3, or define it to be
legacy method specific, but do not force its disclosure to trivial active
attacks.

> Do you have a concrete proposal for addressing this?

I am not proposing to do any of the "overkill" (and ineffective) tricks
mentioned above. I was mainly raising the concern hoping someone can shed 
light on how these keys are used.
At this point I believe that the only thing that can be done is to
have a "MUST NOT use this key for any other purpose (in IKE or elsewhere)"
kind of directive in the draft.

> which of his messages will be the last until the server accepts it.

OK.

Hugo

---

From: "Geoffrey Huang" <[email-masked]>
Date: Wed, 5 Feb 2003 10:24:41 -0800

<snip>
> 3) For the Cipher Suite issue, that we use Paul Hoffman's proposed set
>    of Cipher suites.  There is less consensus on this issue on the
>    mailing list, but most people don't seem to have strong feelings,
>    so we believe we just pick something:
> 
> Suite-ID  Meaning
> --------  -------
> 0         Covers: IKE				(MUST)
>           168-bit 3DES CBC encryption
>           Diffie-Hellman group 2 (1024-bit)
>           HMAC-SHA1 integrity and prf
> 
> 1         Covers: ESP				(MUST)
>           3DES encryption with three keys
>           HMAC-SHA1 integrity
> 
> 2         Covers: AH				(SHOULD)
>           HMAC-SHA1 integrity
> 
> 3         Covers: IKE				(MUST)
>           168-bit 3DES CBC encryption
>           Diffie-Hellman group 5 (1536-bit)
>           HMAC-SHA1 integrity and prf
> 
> 4         Covers: IKE				(MUST)
>           AES encryption in CBC mode with 128-bit keys
>           Diffie-Hellman group 5 (1536-bit)
>           HMAC-SHA1 integrity and prf
> 
> 5         Covers: IKE				(MUST)
>           AES encryption in CBC mode with 128-bit keys
>           Diffie-Hellman group 14 (2048-bit)
>           HMAC-SHA1 integrity and prf
> 
> 6         Covers: ESP				(MUST)
>           AES encryption in CBC mode with 128-bit keys
>           HMAC-SHA1 integrity
> 
> 7         Covers: IKE				(SHOULD)
>           AES encryption in CTR mode with 128-bit keys
>           Diffie-Hellman group 14 (2048-bit)
>           AES-CBC MAC + XCBC integrity and prf
> 
> 8         Covers: ESP				(SHOULD)
>           AES encryption in CTR mode with 128-bit keys
>           AES-CBC MAC + XCBC integrity
> 
> I have adjusted the MUST/SHOULD from Paul's message since I 
> believe that
> for implementations that will be moving to implement IKEv2, it is
> reasonable to require the implementation of AES, as it as so many
> advantages over 3DES.  If it weren't for the existing chips that only
> support AES-CBC, I'd argue for making AES-CTR mandatory instead, but
> given where we are, this set of MUST/SHOULD seems to me to be the most
> reasonable set of ciphers.
> 
> Question: Should AES Counter mode be made mandatory to ensure
> compatibility in the future?  Existing chips only support AES-CBC, so
> this might make things harder for people as they transition 
> to IKEV2.  On
> the other hand, by the time we see start seeing IKEv2 
> products, it might
> be reasonable to require the presence of AES-CTR support.

As far as SHOULD vs. MUST goes w.r.t. cipher algorithms - I think
leaving it
at SHOULD would suffice.  Experience with 3DES showed that even though
it
was a "SHOULD" most people ended up implementing it.  To this end, I
guess
support for such algorithms is very demand-based.

> -----------------------------------
> 
> (SEMI-)CLOSED ISSUES
> =====================
> 
> 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....

I'm all for clearing up the vagaries of the ID payload - especially when
using certificates.  But the proposed change seems to weigh heavily on
certificate ID types - despite the fact that authentication by preshared
key seems to be the preferred method.  I admit that the hesitance to
adopt certificates could arise from the ID confusion; still I feel more
comfortable with the familiar ID types we currently have when using
preshared key.  Given this, couldn't we just be more explicit about what
goes in an ID payload when certs are used?...and perhaps take the
hash-and-url option from Paul's proposal?

> 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.
> 

I never thought I'd be a defender of mode config, but here I'm about to
defend it.  I prefer mode config to dhcp-ipsec for several reasons:

- as implementors, we understand it.  We have experience implementing
it, we're comfortable with its extensibility.

- Mode config allows us to use various data stores for housing policy -
be it the security gateway itself, RADIUS, etc.  Note that using mode
config shouldn't preclude us from getting address pools from a dhcp
server, even.

- Mode config allows us to decide on address pools based on the identity
of the peer.

One argument in favor of DHCP that I've read on this list is that it's
an existing protocol with many configuration parameters already defined.
I can certainly see the benefit of this (no point in reinventing the
wheel), but I think it's worth noting that, since mode config is part of
the IKE realm, IKE implementors control its extensibility.  It might be
too restrictive to depend on DHCP to come up with parameters that might
be IKE-centric (if we were ever to need to extend configuration
options).

-g

> 					Ted and Barabara
> 					IPSEC wg chairs

---

From: Derrell Piper <[email-masked]>
Date: Wed, 5 Feb 2003 15:46:24 -0800

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:

> 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
> 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
> (Barbara and Ted) hereby ask that those who believe we should pursue 
> the
> revised-identies draft.  For example, we could add the Hash-and-URL 
> type
> IKEv2 has to be what is currently in ikev2-04.  So those who believe we
> involves using tunneled DHCP requests.  The latter approach is about to
> packet forwarding tables.  Modecfg proponents also argue that it is 
> also
> possible to transform modecfg requests into DHCP requests, so there are
> Either approach seems to be workable.  It is certainly true that most 
> of
> favor of an approach similar to draft-ietf-ipsec-dhcp-13, including Van
> Given that we have a fully specified solution in the ikev2-04 draft, 
> and

---

From: "Victor Volpe" <[email-masked]>
Date: Wed, 5 Feb 2003 23:34:19 -0500

Here are my thoughts on the 2 issues:

1. On the modecfg vs DHCP - I prefer modecfg.  We have used it for years
without issue.  It is easy to implement and understand, it is
self-contained,
it does not require additional SAs and is easily extensible.  Not only have
we
added many modecfg attributes to solve customer issues in the past but we
have
been able to easily coordinate the new attributes with RADIUS via vendor
specific
attributes for a complete solution.  Adding LDAP to this proxy scheme has
also been
very easy.

How easy would it be to implement a "complete" solution via DHCP.  It seems
to me that
we would have 2 options with DHCP.  We either pass DHCP through to a DHCP
server and make
it transparent to IKE/IPsec, or we intercept the DHCP request and proxy it
to RADIUS or
LDAP.  In my opinion, the former option is not really an option.  We can not
use DHCP servers
for anything other than IP address assignment.  If we told our customers
that they need to
set up user-based configuration attributes on their DHCP server, they would
quickly throw
us out.  The latter option (proxy) would work but is more difficult to
implement than modecfg.
The difficulty comes with the loose coupling to user tunnels and the
additional SA.

2. I find Paul's naming convention very confusing (maybe it is because I am
not up on the latest PKIX requirements).  I like the old naming convention
because they are core names and not abstractions of names.  By this I mean
that a core name can be used in several different scenarios (if all the
scenarios have the same ID requirement) as long as the core ID requirement
is well
documented.  The abstractions, at least to me, may be more intuitive, but
could cause an ID explosion as more and more abstractions are introduced.
The worst case is that many abstract IDs really map to the same core ID.
What I would really like to see is a decrease in the number of IDS.  It
would be nice to cover all the bases with 2 or 3 IDs and properly document
the
use of the IDs.

Victor

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Derrell Piper
> Sent: Wednesday, February 05, 2003 6:46 PM
> To: Theodore Ts'o
> Cc: [email-masked]
> Subject: Re: Moving forward with IKE V2: A proposal for final edits to
> ikev2-04
>
>
> > Paul Hoffman has a proposal,
> draft-ietf-ipsec-revised-identity-00.txt,
> that most