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

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

> PHB,
> ...
>
>
>> One major design limit in IPSEC and TLS is that both view the key
>> exchange as being integral to the security layer rather than a separate
>> service. I would like to separate out consideration of how chunks of data
>> passing over the net are tagged and bagged for encryption and
>> authentication from the question of key setup.
>>
> IKE is separate from ESP and AH. ESP and AH can be used independently of
> IKE, although manual keying
> is obviously not attractive in most cases. TLS is a different matter, in
> that the handshake that
> puts keys in place is integral to the data security protocol. However,
> DTLS is used with SRTP
> to secure VoIP, showing that the key exchange there can be used to support
> other protocols.
>
>
>> There is no logical reason why the key negotiation for TLS, IPSEC and
>> tcpcrypt cant be shared.
>>
> yes, it could be, despite the erroneous assertions above ;-)
>

Please do not confuse your misunderstanding of my post with my knowledge of
the circumstances.

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.


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.

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.

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