[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
specifies
>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
Registration
>
>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
>erussell@ftp.com
>
>
>
Follow-Ups: