[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: