[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Concerns
Date: Mon, 16 Sep 1996 16:59:53 -0700
From: John Lawler <jlawler@vpnet.com>
It is rather clear from the recent traffic and from the votes in Montreal
that people are split down the middle over SKIP vs ISAKMP. At this point I
believe pretty much everyone is talking past each other. Based on this
rather deeply entrenched split, I honestly do not believe this issue is
going to be resolved now or even in San Jose.
Well, at the IPSEC wg, what I saw was a small group of people who wanted
SKIP, a small group of people who wanted ISAKMP (and I won't try to
characterize which of the two small groups were bigger, more technically
comptentent, or has better-substantiated paternity), but the vast
majority of the room were from vendor-types who said, "we don't care
which one you choose; we're not competent to make that choice. But we
don't have to implement two solutions. Pick one."
So, I think we have to do that; granted, the wg consensus process isn't
well suited for that. But that's why we have an Area Director, an IESG,
and an IAB. If you recall, the chartering of a design team to try to
come to one solution had a fallback solution if that design team did not
come to consensus.
- Ted
Date: Mon, 16 Sep 1996 18:17:53 -0400
From: Hilarie Orman <ho@earth.hpc.org>
Message-Id: <199609162217.SAA19385@earth.hpc.org>
To: jlawler@vpnet.com
Cc: ipsec@TIS.COM
In-Reply-To: Yourmessage <199609162133.OAA19723@baskerville.CS.Arizona.EDU>
Subject: Re: Concerns
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
There has been consensus on PFS for over a year, at least. There has
been general agreement on out-of-band keying for longer than that. This
doesn't preclude expanding the points of consensus, of course.
> In seems very clear to me that
> pretty much everyone has settled into one camp or another--
There's a contingent that would like to see an inclusive solution -- a
contingent that believes it's easier to code than argue, that we can
have it all for little additional cost.
Message-Id: <199609162302.TAA23968@jekyll.piermont.com>
To: John Lawler <jlawler@vpnet.com>
Cc: ipsec@TIS.COM
Subject: Re: Concerns
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Mon, 16 Sep 1996 19:02:05 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
John Lawler writes:
> 2) Paul, you made a comment (uncalled for, I believe) about Sun's
> intransigence over SKIP. I must say thay I have not found the ISAKMP
> supporters to be any less intransigent.
I believe that what you call the ISAKMP camp is not a camp and in fact
didn't support ISAKMP before recently when it emerged as a result of
consensus. People in this "camp" are equally happy with any of a
variety of negotiation protocol solutions -- Photuris, Oakley,
etc.
Generally, what is desired is a protocol that plays well with the
IPSec model. I'm still not entirely happy with what we have. I'm just
pretty sure SKIP isn't as close as things following the general model
of Photuris and Oakley.
> Therefore, I will make the same proposal I made in Montreal: Let
> *BOTH* SKIP and ISAKMP move ahead in the standards process, and let
> the marketplace decide which is better. If the IETF does not get
> something out NOW, then the market will come up with something of
> their own and all of your debating will be moot.
I would suggest that they both go forward as experimental, but, thats
a matter of taste. I agree we should be developing and deploying
without delay.
Perry
From: Dan McDonald <danmcd@pacific-86.eng.sun.com>
Message-Id: <199609170303.UAA25153@kebe.eng.sun.com>
Subject: Re: Using SKIP as inspiration, not a
To: oz@border.com, ipsec@TIS.COM
Date: Mon, 16 Sep 1996 20:03:51 -0800 (PDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
For reasons very similar to Rich Skrenta's earlier note about mail not
reaching various places, I didn't get a chance to get this note out until
now. Hopefully it will clear up some things. -- Dan McD.
----
> > Some of us don't like the fact that SKIP does not play nicely with the
> > IPSec model.
>
> i have no idea what this means. i am a relative newcomer to the IPSec
> forum, so perhaps you could clarify...
I _think_ (and I don't claim to speak for Perry here) that what he means by,
"not playing nice with the IPsec model," is something like the following
example.
According to RFC 1825 (IP Security Architecture):
> 4. KEY MANAGEMENT
>
> The Key Management protocol that will be used with IP layer security
> is not specified in this document. However, because the key
> management protocol is coupled to AH and ESP only via the Security
> Parameters Index (SPI), we can meaningfully define AH and ESP without
> having to fully specify how key management is performed.
As this implementor reads it, the way I tell what key(s) to use is to look at
the SPI, and parse the rest of the packet accordingly. This would mean
packets look like:
<--- cleartext ---><--- Possibly encrypted text, depending --->
+-------+---------+============================================
| IP or | ESP | Encrypted data (maybe in-line keys, too)
| IPv6 | SPI = n | which I can parse by using SPI value n to
| | | lookup in my table what this data is.
+-------+---------+============================================
>From what I understand about SKIP, SKIP does not include its in-line keys,
etc. after the ESP header. Rather, it _prepends_ this data in its own
header. Packets then look like:
<--- mostly cleartext -----><--- ciphertext ---------------->
(save the SKIP sess. key)
+-------+---------+---------+==================================
| IP or | SKIP | ESP | Encrypted data.
| IPv6 | header | SPI = 1 |
| | w/sec. | |
| | parms. | |
+-------+---------+---------+==================================
Some people (including Perry, I'd imagine :) consider this a violation of RFC
1825.
Other people have wondered if a header that looked like this could happen:
<--- mostly cleartext -----><--- ciphertext ---------------->
(save the SKIP sess. key)
+-------+---------+---------+==================================
| IP or | ESP | SKIP as | Encrypted data.
| IPv6 | SPI = 1 | an ESP |
| | or some | x-form |
| | range. | data |
+-------+---------+---------+==================================
These people argue that it accomodates SKIP's in-line keying advantages,
while not violating RFC 1825.
If I'm missing any relevant data, please feel free to fill in the blanks,
folks.
--
Daniel L. McDonald | Mail: danmcd@eng.sun.com Phone: (415) 786-6815 +
Software Engineer | *** My opinions aren't necessarily Sun's opinions! *** |
SunSoft Internet | "rising falling at force ten |
Engineering| we twist the world and ride the wind" - Rush +
Date: Tue, 17 Sep 1996 09:47:13 -0400
From: Hilarie Orman <ho@earth.hpc.org>
Message-Id: <199609171347.JAA13751@earth.hpc.org>
To: danmcd@pacific-86.eng.sun.com
Cc: ipsec@TIS.COM
In-Reply-To: Yourmessage <199609171254.FAA01320@baskerville.CS.Arizona.EDU>
Subject: Re: Using SKIP as inspiration, not a
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Is there then consensus for including in-line keys with a non-PFS key
determination mode as a required component of a key distribution
protocol?