[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Agenda stuff
Dan:
> On Fri, 27 Nov 1998 15:23:15 EST Robert Moskowitz wrote
> >
> > (I know there is more here than we can cover in 2 hours. If some of this
> > is straightforward we can handle it on the list. I would like to see if we
> > have a pending set of documents ready for last call and to define what is
> > important to everyone for 'IPsec ond').
> >
> > Outstanding Items:
> >
> > Revs for IKE D. Harkins
>
> Perhaps the "Revs for IKE" is straightforward enough that we can handle it
> on the list. Let's try.
>
> The IKE/DOI errata are at http://www.lounge.org/ike_doi_errata.html.
> Most of these issues have obvious solutions which are mentioned along with
> the issue (like "add group 5"). Some don't. Here's suggestions for those
> that don't. These are not intended on being THE WAY but only to encourage
> discussion on these matters since no one seems to be discussion them on
> this list.
>
> 1. What type of cert encoding is used in a cert request payload
> if you wish to obtain the peer's encryption certificate (assuming
> the peer has one signature only and one for encipherment only)?
>
> ISAKMP mentions "X.509 Certificate - Signature" and "X.509 Certificate -
> Key Exchange". Signature should be out of the question because if you have
> a cert restricted to signatures only that's not the one to request to
> do encryption with. So is it "Key Exchange"? Is this merely a semantic
> problem in that that doesn't sound too informative?
>
> 2. Addition of new elliptic curve groups. Possibly add groups over F2^p,
> where p is prime. Open item is whether this goes in IKE or becomes a
> standalone BCP-type RFC.
>
> Perhaps those who want new groups can suggest a resolution to this.
>
> 3. There are issues surrounding the rekeying of both phase1 (IKE) and
> phase2 (IPSec) SAs. "IPSec Re-keying Issues" [Tim Jenkin's document]
> discusses these.
>
> Since Tim is presenting his document next week we can punt this one.
>
> 4. Clarification on what SPI to use during transactional exchanges like
> new group mode or configuration mode.
>
> How about none?
>
> 5. Some verbage needed to specify when to start using the IKE SA to
> protect notification exchanges. As soon as "crypto active" which could
> screw up the running IV or after the phase 1 exchange which could
> leave some notifies unprotected?
>
> This is an issue if you want to send a notify after the Diffie-Hellman
> exchange has completed but before the SA has been authenticated. IKE says
> "If the ISAKMP security association has not yet been established at the
> time of the Informational Exchange, the exchange is done in the clear
> without an accompanying HASH payload." So I guess that means it goes in
> the clear but then that can open us up to attack. So should we say that
> the IV used to encrypt the message (in the unauthenticated key by the way)
> is generated the same way in this case as it is for the post-established SA
> case? In other words, a hash of the last phase 1 CBC output block and the
> message ID of the notify. And since the last phase 1 CBC output block has
> not be determined yet the IV would be a hash of the message ID.
>
> 6. A rewrite of the wording in section 3.5 in the ISAKMP document that
> seems to mandate a covert channel.
>
> Kivinen has suggested the following text:
>
> "During phase 1 negotiations, the initiator and responder cookies
> determine the ISAKMP SA. Therefore, the SPI field in the Proposal
> payload is redundant and its size MUST be set to 0."
>
> as a replacement for:
>
> "In the case of ISAKMP, the Initiator and Responder cookie pair
> from the ISAKMP Header is the ISAKMP SPI, therefore, the SPI
> Size is irrelevant and MAY be from zero (0) to sixteen (16). If
> the SPI Size is non-zero, the content of the SPI field MUST be
> ignored."
>
> which just seems broken. That sounds good. Doug (Maughan) do you have any
> input here?
>
> There are 3 issues that effect interoperability that need to be addressed
> in son-of-IPSec so we can leave those for later. But it would be nice if
> we could come to some resolution on these other issues. Also, check out
> the web page. If any of those issues I didn't mention don't seem to have
> a straightforward solution please point that out and suggest one.
>
> Dan.
An item that has arisen before but is covered neither by the errata nor
the above discussion is whether the kilobytes lifetype may be used for
phase 1. More generally, it would be useful to indicate definitively
which SA proposal attributes MUST be negotiated in a phase 1 proposal,
which in a phase 2 proposal, which are optional, and which, if any, are
expressly forbidden in one of the two phases.
--
Jesse Walker
Consulting Engineer
Shiva Corporation
28 Crosby Drive
Bedford, MA 01730-1437
voice: 781-687-1719
fax: 781-687-1437
e-mail: jwalker@shiva.com
References: