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

[Stephen Kent <[e-mail]>]

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