[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: KEI visa XCHG (ISAKMP & OAKLEY)



Oliver, how about treating OAKLEY as a "security" protocol" under ISAKMP
(like ESP is a "security protocol" for IP.) and treating differnet modes
of OAKLEY as the attributes of OAKLEY.

In othwer words, we can construct OAKLEY, or any other KEP,
and its mode(s) as a ISAKMP proposal. Theefore a KEP can be negotiated
just like ESP and its transform.


Regards, Pau-Chen



> From ipsec-request@neptune.hq.tis.com Fri Aug 16 15:56:26 1996
> X-Authentication-Warning: P-spatsch.cs.arizona.edu: spatsch owned process doing -bs
> Date: Fri, 16 Aug 1996 10:01:56 -0700 (MST)
> From: Oliver Spatscheck <spatsch@cs.arizona.edu>
> Reply-To: Oliver Spatscheck <spatsch@cs.arizona.edu>
> To: ipsec@TIS.COM
> Subject: KEI visa XCHG (ISAKMP & OAKLEY)
> Message-Id: <Pine.LNX.3.94.960816095936.1186A-100000@P-spatsch.cs.arizona.edu>
> Mime-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> Sender: ipsec-approval@neptune.hq.tis.com
> Precedence: bulk
> Content-Length: 2120
> Status: RO
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> 
> I am just implementing the ISAKMP header and realized that the xchg
> field has only 4 bit. This seems to small. The Oakley modes has to be
> handled as different exchange types as already mentioned by Mark.
> 
> However counting the 4 reserved exchange types and the 4 Oakley
> exchange types there are only 8 other exchange types left. Considering
> that we are currently designing a multicast key exchange protocol
> using the ISAKMP framework I would strongly recommend to use 16 Bit in
> the xchg field of the header.
> 
> Realizing this problem I was thinking about the Oakley KEI and
> I don't think Oakley needs it's own KEI. Oakley main mode uses regular
> DH key exchange or RSA encryption and the other Oakley modes don't use
> key exchange payload at all.
> 
> Therefore a general KEI for DH, RSA encryption and a KEI for no key
> exchange payload should be added.
> 
> The ISAKMP draft mentions Oakley multiple times as a key exchange
> technique identified by a KEI. This is not true Oakley is a full size
> exchange using sa, nonce, id, key exchange, signature and hash
> payloads. The combination of selected attributes and used Oakley
> mode defines the contents and presence of the hash, id, nonce and
> signature payloads. There is no such thing as ONE Oakley KEI.
> 
> I forgot to mention in my last email that I am only implementing the
> Oakley exchanges at this point. I am establishing the Phase 1 ISAKMP
> SA using Oakley as I am using Oakley to establish the IPSEC SA.
> 
> It would be easy for me to add the ISAKMP exchanges or CISCO exchange.
> However they all are less flexible than Oakley.
> 
> Oliver
> 
> - -----
> 
> Grad student and research assistant in computer science at the University of Arizona, Tucson, USA
> For my PGP public key please check my homepage URL: http://www.cs.arizona.edu/people/spatsch
> 
> 
> 
> 
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3i
> Charset: noconv
> 
> iQCVAwUBMhSphznVPgUZ7uZJAQEywQQAiE+WqkNsyPzLI4PNpIA8wb6kuKpsBqoZ
> 7SNvv9AdBrKdBMVhCYScN03xnZheziU/765u+CD9nZxmBCBaseRA4wGT9sPHLku/
> tE4EVIlTqmQDkrGcn/+w8K0BuJ5iroRWSiiODU+1bkXoRJtwd5m4WAeX2l/uAgMf
> ZqBEn4zvfK4=
> =a85z
> -----END PGP SIGNATURE-----
> 
> 


Follow-Ups: