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

Re: Agenda stuff



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.



Follow-Ups: