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

Re: Deafening Silence



-----BEGIN PGP SIGNED MESSAGE-----


In the following I included some comments to the current ISAKMP & Oakley draft.
I encountered the problems while I was struggling to implement a full
blown ISAKMP and Oakley key exchange engine. I might have mentioned some
of the comments to the authors before. So forgive me if I am repeating them
here. We schould also think about which part of ISAKMP and Oakley is required 
and which is optional.

ISAKMP draft 5
==============
2.2 

- - The XCHG field is to small. If each Oakley exchange gets it's own XCHG number
  8 Bit are not sufficient. 16 Bit seem OK to me.

- - What is the correspondence between the XCHG filed in the ISAKMP header and the
  key exchange identifier in the ISAKMP proposal? Is the XCHG field
  only used for ISAKMP negotiation and the key exchange identifier (KEI) for any
  other negotiation?

  I think the XCHG field should determine processing. The key exchange identifier should
  determine the key exchange algorithm only like RSA, DH... .

  However then the Oakley Mode is not negotiable.

2.3

- - I think the table in this section is extremely confusing.
  Why don't we always use  receiver SPI than sender SPI ? 

2.3.1

- - I would strongly recommend that an ENVELOPE payload has to be used always.
  Except for DELETE, NOTIFY and CERTIFICATE payloads.
  This allows easier parsing and multiple exchanges in one message.
  (Combine ISAKMP with IPSEC SA negotiation to reduce the number of roundtrips for example)

2.4.1

- - I would allow that if only one proposal is made in a SA payload the message can be 
  accompanied by other payloads .

  This allows for example to put a SA, ID, nonce and a key exchange payload in the same 
  message as long as the payloads match the proposal. Reducing the number of roundtrips.
  (Something similar is proposed in the Oakley draft.)  

2.4.2

- - Again I think Oakley is not a KEI it is a XCHG.

2.4.7

- - The phrase :

"  .......... If nonces
are used by a particular key exchange, it is expected the nonces will be
defined as part of the key exchange data and not transmitted as a separate
payload. "

is misleading. I would suggest that Oakley is using the nonce payload.


3.4 
- - Why ISAKMP exchanges? I think they are all unnecessary. The Oakley exchanges
  can be use instead.

- - The authentication only exchange is buggy. It does not protect against replay.

IP DOI:
- ----------

- - Define how the IPSEC SPI fits into the 8 Byte SPI field.
- - Complete the missing chapter.

Other: 

- - The TLV field has to be defined.

Oakley draft 1
==============

Hashing and Signing:
- --------------------

The current draft describes multiple examples of exchanges (aggressive, hidden identity, ...)

However I have problems generalizing from this examples to what has to be hashed or signed.

It would be extremely helpful if we could come up with a general simple rule what
should be signed and state it. It would be also extremely helpful if we could
come up with a rule from which state on a signature or hash payload has to be included.

For example you have to sign data structure x after the following data is received .... .
  

KEYID
- -----

The KEYID generation has to be rethought.
If a main mode ISAKMP exchange is performed within an ISAKMP SA the cookies for
the ISAKMP SA are already used as KEYID for the ISAKMP SA key.


Payloads
- --------

The payload formats should be updated to ISAKMP draft 5 or whatever comes next.

Oliver

- -----

Grad student and research associate 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

iQCVAwUBMl2FxznVPgUZ7uZJAQGy1QQAoUjFiagMCarip2NBpJUbUYcbOjvA4UHo
RbOLtxyhTgSoL+oL7xQgAj+os6+ASJmO1HC9toDzOx52mLt9WDP1twGCmvwHkYNN
/IjYSEzoIqI5fex7ecl65jnYFqL/PCUe633ecHuUtcOkkNk8hSx1F7w7owwEraA9
NkuJeMFojmU=
=DbbC
-----END PGP SIGNATURE-----


Date: Thu, 10 Oct 1996 17:36:04 -0400
Message-Id: <199610102136.RAA03403@MAILSERV-2HIGH.FTP.COM>
To: ipsec@TIS.COM
Subject: Re: Deafening Silence
From: Shawn Mamros <mamros@ftp.com>
Reply-To: mamros@ftp.com
Cc: rja@cisco.com, spatsch@cs.arizona.edu
Repository: mailserv-2high.ftp.com, [message accepted at Thu Oct 10 17:35:59

1996]
Originating-Client: cavedog.ftp.com
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

First, a disclaimer of sorts: I am a relative newcomer to the IPSEC
world (others here at FTP have been working in this area for quite
a while), so I may not have a complete understanding of some of the
issues here.  But, as an implementor working for a company which would
very much like to see ISAKMP/Oakley interoperability ASAP (and one
which Ran cited in his message), I do have some serious concerns about
the current state of the drafts and at least one reference implementation
out there w.r.t. interoperability.  If anyone could help clarify these
for me, I'd be grateful.

>>I also think that the drafts are not concrete enough so that 2
>>implementer would come up with interoperable implementations.
>
>        You make a strong bold claim.  However, there is an existence proof to
>the contrary since interoperability of independently-written implementations
>has ALREADY been shown.  For example, the DRA/Malvern implementation written
>against isakmp-04 talked fine with the cisco UNIX implementation written
>against isakmp-04.  There can be no doubt that the ISAKMP and ISAKMP-Oakley
>specifications are sufficiently concrete to implement.  All the details are
>there, including all of the magic numbers, in a clean easily-read format.

I don't doubt that this is true.  However, I can't find a copy of the
isakmp-04 draft anywhere.  The current draft is isakmp-05.  And, if I
look at that draft, and then look at the isakmp-oakley-00 draft and
the freely-distributable cisco UNIX implementation, I see a number of
very crucial differences which are causing a lot of confusion for me
as an implementor.  Just one example (but perhaps the most crucial one):

The isakmp-05 draft defines three exchange types which MUST be implemented,
and the respective values which are used for them in the XCHG field of the
ISAKMP header: Base (1), Identity Protection (2), and Authentication Only
(3).

The isakmp-oakley-00 draft makes no mention of the above three mandatory
exchange types.  Instead, it defines three of its own: Oakley Main Mode,
Oakley Aggressive Mode, and Oakley Quick Mode.  No values for the XCHG
field are defined for these exchange types in this draft.

The cisco UNIX implementation, which looks to be based largely on
isakmp-oakley-00, only implements Oakley Main Mode and Oakley Quick Mode.
Since Oakley Aggressive Mode is cited in the draft as a SHOULD but not
a MUST, it looks like it complies with the requirements of isakmp-oakley-00.
But, since it does not implement Base, Identity Protection, or
Authentication Only exchanges, it cannot be considered compliant with
the isakmp-05 draft, since those exchange types are MUSTs.  Furthermore,
the XCHG field values used in the implementation *directly conflict*
with those in isakmp-05!  (Oakley Main Mode is 1, Oakley Aggressive Mode
is 2, and the unused-except-for-debugging-output Oakley New Group Mode
is 3 - see the ikmpd/isakmp.h source file.)

Clearly, this conflict MUST be resolved one way or another before we
can ensure that implementations based on the current drafts are
interoperable.  From my (perhaps naive) analysis, Identity Protection
and Oakley Main Mode look enough like one another that a merger of
the two should be possible.  The Base exchange and Oakley Aggressive
Mode seem to be relatively close, in terms of the desired functionality,
but I can't say for certain.  Oakley Quick Mode, if it is needed (and
currently no other exchange type in either draft provides for the
exchange of IDui and IDur, so I believe it is) will almost certainly
need a separate exchange type.

Personally, I have neither the time nor the desire to get into wars
over "technical (or any other type of) religion" - I want to make
working code!  But, if other vendors are going to be working from
the cisco code as a base, I need to know that so that we can successfully
interoperate with them come January.  If, on the other hand, the
isakmp-05 draft should be taken as "the truth", then the cisco
implementation (and, for that matter, the isakmp-oakley-00 draft)
needs to be brought in line, and other vendors need to be aware that
that code is out of date BEFORE somebody decides to ship product
based on it.  (That sort of thing has happened before, countless
times...)

Let's not do battle over this - let's just make things work.  I am
more than willing to participate in discussion on these and other
related issues, right out here in the open on the list, so that
these conflicts can be resolved.  And, if I am mistaken in anything
I have said above, please enlighten me.

-Shawn Mamros
E-mail to: mamros@ftp.com




From: Ran Atkinson <rja@cisco.com>
Date: Thu, 10 Oct 1996 14:48:30 PDT
In-Reply-To: mamros@ftp.com (Shawn Mamros)
       "Re: Deafening Silence" (Oct 10,  5:36pm)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: mamros@ftp.com, ipsec@TIS.COM
Subject: Re: Deafening Silence
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID:  <9610110724.aa04588@neptune.TIS.COM>

Shawn,

  The cisco ikmpd(8) software currently online predates the ISAKMP-05 draft.

	As with many protocols in the IETF (specifically including the several
protocols within this working group), reference implementations tend to appear
online somewhat after the drafts appear online.

	I would guess that most ISAKMP/Oakley discussions are probably
occuring on the isakmp-oakley mailing list mentioned previously since the
IPsec list has historically had a poor signal/noise ratio.

Regards,

Ran
rja@cisco.com


-- 



Message-Id: <3.0b34.32.19961011102018.00a36ea8@pop3hub.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0b34 (32)
Date: Fri, 11 Oct 1996 11:00:35 -0400
To: John T O'Hara <johara@ftp.com>, ipsec@TIS.COM
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: RE: Deafening Silence
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

At 01:45 PM 10/10/96 -0400, John T O'Hara wrote:
>
>Without a more complete implementation draft I would venture to say that a
testathon would not be as productive. I would recommend that discussions of
the draft stay on this list for a while due to the wider audience.

Please yes.  Get going on this.  We need this done in short order.



Robert Moskowitz
Chrysler Corporation
(810) 758-8212




Message-Id: <3.0b34.32.19961011100736.00a36190@pop3hub.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0b34 (32)
Date: Fri, 11 Oct 1996 11:00:33 -0400
To: Stephen Kent <kent@bbn.com>, John Gilmore <gnu@toad.com>
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: Short keys  *  Options, combinations, and negotiations =>
        simplicity
Cc: ipsec@TIS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

At 08:05 PM 10/8/96 -0500, Stephen Kent wrote:
>
>Moreover, in selecting any safeguard, one
>must balance percieved threats against costs.   While you clearly precieve
>NSA as a threat, I don't find that most of my commercial clients share that
>view.  They are more concerned about hackers, criminals, and other
>adversaries for whom DES is a reasonable countermeasure.  

Our industry has already faced government backed industrial espionage.  Not
NSA backed, but their competitors....


Robert Moskowitz
Chrysler Corporation
(810) 758-8212




Message-Id: <3.0b34.32.19961011095534.00a197d8@pop3hub.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0b34 (32)
Date: Fri, 11 Oct 1996 11:00:29 -0400
To: "Jeffrey I. Schiller" <jis@mit.edu>, Ben Stoltz <stoltz@denwa.incog.com>
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: Deafening Silence
Cc: ipsec@TIS.COM, Hilarie Orman <ho@earth.hpc.org>, wu@csc.ncsu.edu
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

At 03:37 PM 10/8/96 -0400, Jeffrey I. Schiller wrote:
>Ben Stoltz wrote:
>> Please take a closer look at Schiller's note.
>> ISAKMP/OAKLEY is only mandatory for IPv6. ISAKMP/Oakley and SKIP are
>> on an equal footing for IPv4.

I got a real chuckle with this wordspinning...

>ISAKMP/Oakley is mandatory for IPv6 because only in IPv6 is IPSEC
>mandatory. It isn't completely clear what mandatory would mean in the
>IPv4 context (though I can think of some interpretations). However I
>think you go to far to say that ISAKMP/Oakley and SKIP are on equal
>footing. They are not. It is important that the working group complete
>the work on ISAKMP/Oakley so we have a deployable solution for IPv6 and
>for IPv4.

I want to see that new Oakley/ISAKMP draft this month!  We need that so
that we have Nov to go through it to finalize it for San Jose.



Robert Moskowitz
Chrysler Corporation
(810) 758-8212