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

Re: Comments on ISAKMP/Oakley

> From ipsec-request@neptune.hq.tis.com Mon Aug 12 10:46:16 1996
> Date: Mon, 12 Aug 96 07:39:40 EDT
> From: "Mark S. Schneider" <mss@tycho.ncsc.mil>
> Message-Id: <9608121139.AA07014@tarius.tycho.ncsc.mil>
> To: naganand@ftp.com
> Subject: Re: Comments on ISAKMP/Oakley
> Cc: ipsec@TIS.COM, mss@tycho.ncsc.mil, wdm@tycho.ncsc.mil, sjt@tycho.ncsc.mil,
        mjs@terisa.com
> Sender: ipsec-approval@neptune.hq.tis.com
> Precedence: bulk
> Content-Length: 5367
> Status: RO

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

Mark, are the values of "tag" and their associate data defined any where ?

   ........................

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


   Mark, I am confused by your answer. If Key Exchange Protocol is meant to
   be nogotiated (which I think is a good idea), why not put Oakley in the
   proposal part of a ISAKMP base exchange ? I mean, is there a need to 
   define exhcnage numbers for Oakley ? There are only twelve unused values
   for the 4-bit "exchane" field. I think the values should be reserved for
   some very different flows of messages.
   
   Also, I don't see draft 5 mentioning ISAKMP Aggressive, Quick, and SA Only
   exchanges. Am I missing something ?
> 

    .....................

> 
> 
> Regards,
> Mark Schneider
> 
 

Thank you.


Regards, Pau-Chen