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

Re: Comments on ISAKMP/Oakley

> From: Naganand Doraswamy <naganand@ftp.com>
> 
> These are mostly implemetation type comments:
> 
> 2.4.1. Security Association Payload
>    Is the "Payload Length" field *really* supposed to be specified in
>    four-octet units, or should it be in octets as all the other payloads
>    are?
> 

  I believe it should be in octets.  It seems unlikely that a SA payload
  will ever be large enough to require a length in 4-octet units.

> 
> A.6.1. Attribute Value Assigned Numbers, IPSEC ESP
>    TLV constructs: how long is "Type"?  How long is "Length"?  Is "Length"
>    in terms of octets, or some other unit?  Are the lengths of "Type" and
>    "Length" included in "Length" or not?

                             1                   2                   3
  TLV =  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        !         Tag/Type                !            Length           !
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ~                           Value/Data                          ~
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Where Length is the length of the Value/Data *only* in the TLV.

> 
>    Where is "Multiple Precision Integer" specified?
>

  It's defined in draft-ietf-ipsec-oakley-01.txt, Appendix D.

> 
> A.7.1 The basic proposal format does has the following fields defined in the
> header:
>    - Proposal #, Proposal Len, Protocol # and Attribute TLV's
>    However, the ESP, AH, and ISAKMP proposals have defined the 
>    Transforms ID's and a reserved field. Shouldnt the basic proposal 
>    format take care of this as well?

  Yes.  I guess we intended that the TLV could be used for the Transform
  ID. Granted, that would take 8 octets.  Are you suggesting adding a
  Transform ID field to the Proposal #, Proposal Len, and Protocol #
  fields?  If so, how do you think this should be done?  Reducing the
  size of the Protocol # field?  Your thoughts are appreciated.
> 
> A.7.4. Proposal Formats, ISAKMP: ???
> 

Section A.7.4. is intended to describe the confidentiality and authentication
mechanisms that are internal to ISAKMP and used to provide Phase I security.
Confidentiality will be provided by applying the IPsec ESP transform(s) to
ISAKMP messages. Authentication can also use IPsec AH transforms, only if
keys have been preplaced. This means we have to determine a public key
mechanism for authentication.  We're working on this.

  
> 
> A.8.1. Security Association Payload Format
>    Does the Situation field length need to be an integral multiple of
>    four octets, as the Proposal field needs to be?  Is the Situation Length
>    field (Figure 20) specified as octets, four-octet units, or ... ?
> 

  It should be specified as the size in octets.

> draft-ietf-ipsec-isakmp-oakley-00.txt

> Where are ISAKMP exchange numbers defined for the various Oakley modes?

  They currently aren't defined in the ISAKMP draft.  In the next version,
  I assume they will be assigned exchange numbers 4-7.

> What happens to the Base, Identity Protection, and Authentication Only
> exchanges defined in the ISAKMP draft?  How does one implemement the other
> exchanges (which are defined as MUSTs in the ISAKMP draft) if Oakley is
> the only supported key exchange and is there any need to implement the basic
> ISAKMP modes if one is supporting only key exchange for IPSEC?


  We see ISAKMP as a framework that permits negotiation of many security
  features, including the key exchange mechanism.  The exchange types
  defined by the ISAKMP/Oakley resolution draft all have a defined key
  exchange.  In this case the key exchange is not negotiable. To support
  negotiation of key exchange mechanisms, the three exchange types defined
  in ISAKMP are *required*.  If they didn't exist, then it would be  
  impossible to negotiatiate key exchange mechanisms.

  Actually, upon looking closer at the ISAKMP exchanges and Oakley exchanges,
  a generalization of the Oakley modes can be made in the ISAKMP draft. Since,
  as you note below, Oakley Main Mode is equivalent to ISAKMP's ID Protect
  exchange, then it seems that Oakley Aggressive, Quick, and New Group
  modes (maybe) can be generalized to ISAKMP Aggressive, Quick, and SA Only
  exchanges. The proposal could then include Oakley as the key exchange
  mechanism along with the specific Oakley group that should be used. 
  Thoughts on this??


> 5.1 Oakley Main Mode

>    Oakley Main Mode looks a lot like the Identity Protection exchange from
>    the ISAKMP draft, except that the Envelope is missing in all transactions,
>    a Nonce is added to the third and fourth messages, and the placement of
>    the optional Certificate relative to the Signature in the fifth and sixth
>    messages is reversed.  Can these two exchanges be merged somehow?

  Actually, I think the two should look identical. ISAKMP is missing nonces
  for "freshness".  We also feel the envelope payload should be standardized
  in all messages: i.e. always used for consistency purposes. They can't
  be merged as the Oakley key exchange is required in Oakley Main Mode and
  not required in ISAKMP's ID Protect Mode.


> Thanks,

> -- Shawn Mamros and Naganand Doraswamy


Regards,
Mark Schneider
Follow-Ups: