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

How to negotiate key length with ISAKMP?

With CAST (and RC5, and ARCFOUR...) we are going to want to negotiate key
length.  I think that we need another Attribute Class in the DOI document.
Looking at draft-ietf-ipsec-ipsec-doi-02, I think we'd need to add Attibute
Class 12, "Key Length".

Is this how this should be handled?  Is there a better way?  Comments?

Please assume for the moment the set of key lengths proposed in the CAST
and other documents are acceptable.  I don't mean to start a "how long
should my key be" debate.

>From: "Edward A. Russell" <erussell@ftp.com>
>To: "'Rodney Thayer'" <rodney@sabletech.com>
>Subject: Negotiation Key Length
>Date: Mon, 23 Jun 1997 11:17:04 -0400
>Evidence indicates that key length is specified by the transform draft.
>We would want an ISAKMP attribute associated with the transform which
>key length.  The attribute would be optional, and the transform draft
>MUST specify a default key length to be used when key length is
>not specified during ISAKMP negotiation.
>Excerpt From Resolution Document - Appendix B
>    When a service (such as an IPSEC  transform) utilizes ISAKMP to generate
>   keying material, all  encryption algorithm specific details (such as key
>   and IV generation,  padding, etc...) MUST be defined by that service. 
>   ISAKMP does not  purport to ever produce keys that are suitable for any
>   encryption algorithm.  ISAKMP produces the requested amount of keying 
>   material  from which the service MUST generate a suitable key.
Details, such
>   as weak key checks, are the responsibility of the service.
>Excerpt from ISAKMP draft - section 1.4.1 Security Associations and
>The SA attributes required and recommended for the IP Security (AH, ESP)
>are defined in [RFC-1825].  The attributes specified for an IP Security SA
>include, but are not limited to, authentication mechanism, cryptographic
>algorithm, algorithm mode, key length, and Initialization Vector (IV).
>Other protocols that provide algorithm and mechanism independent secu-
>rity MUST define their requirements for SA attributes.  The separation of
>ISAKMP from a specific SA definition is important to ensure ISAKMP can es-
>tablish SAs for all possible security protocols and applications.
>NOTE: See [IPDOI] for a discussion of SA attributes that should be consid-
>ered when defining a security protocol or application.
>Edward Russell