Re: [perpass] tcpcrypt applicability (Was: Re: Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt)

[Phillip Hallam-Baker <[e-mail]>]

Steve

If you are going to state that someone got their post wrong then all that
actually matters is what they said because that is the case you are arguing
against. You can't redefine my motion and then complain that I didn't
understand it.

If you are going to say I got things wrong and then followup with a
completely unrelated post then you are a confused bunny.

And I split the key agreement out of Omnibroker into WSConnect, oh, six
months ago. Precisely because it is a feature that we now need at the Web
Service layer. So hardly a 'hidden agenda'.

While we are at it we could reinstate photuris.




On Tue, Jan 21, 2014 at 11:30 AM, Stephen Kent <[e-mail]> wrote:

>  PHB,
>
> ...
>
>   Please do not confuse your misunderstanding of my post with my
> knowledge of the circumstances.
>
> read what I wrote, as opposed to your misunderstanding ...
>
>
>   IKE is certainly not currently packaged up for use an independent
> service. Saying that this could be done is not the same as it having been
> done.
>
>  The current IKE document begins as follows:
>
>  Kaufman, et al.              Standards Track                    [Page 4]
>
>   <http://tools.ietf.org/html/rfc5996#page-5>RFC 5996 <http://tools.ietf.org/html/rfc5996>                        IKEv2bis                  September 2010
>
> 1 <http://tools.ietf.org/html/rfc5996#section-1>.  Introduction
>
>    IP Security (IPsec) provides confidentiality, data integrity, access
>    control, and data source authentication to IP datagrams.
>
>   I said that IKE is *separate* from ESP and AH and that *AH and ESP can
> be used without IKE*.
>
> It is true that IKE is a version of ISAKMP that has been tailored to
> support IPsec, but it
> is still independent of ESP and AH; IKE uses its own mechanisms to protect
> its SAs, not ESP.
>
>  That is not how I expect a document describing an independent crypto
> protocol designed for use in other schemes to begin.
>
>  Suggesting that the IETF adopt a practice of requiring re-use of such
> schemes in the security area is actually suggesting quite a major change in
> our approach. i.e. instead of having PGP and S/MIME sit in separate rooms
> defining two different message formats for secure email, require them to
> agree on one message format that can be used with both trust
> infrastructures.
>
> (O)PGP and S/MIME are different in more ways than the assumed "trust
> infrastructure."
>
> I think no one is requiring re-use of IKE in contexts where it is not
> appropriate. However, given
> the complexity of developing good key management protocols, Security ADs
> usually advise against
> creating a new one unless it is necessary.
>
>   The idea that key exchange can be implemented as an independent Web
> Service is not something I expect to see in the IPSEC docs since the
> originals were written several years before the term was coined.
>
> Ah, so your (previously hidden) agenda is a push for a Web Service for key
> management. Well, at least that's
> on the table now, sitting next to OmniBroker.
>
> Steve
>



-- 
Website: http://hallambaker.com/