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

Re: Agenda stuff



Daniel Harkins writes:
>    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?

I think we should at least change the name from Key Exchange to
something else (Key Encipherment?). The PKIX defines Diffie-Hellman
Key Exchange Key (draft-ietf-pkix-ipki-part1-11.txt: 7.3.2), and I
don't know whether the rfc 2408 (isakmp) "X.509 Certificate - Key
exchange" means that or the encryption capable RSA key.

>    4. Clarification on what SPI to use during transactional exchanges like 
>       new group mode or configuration mode.
> 
> How about none?

There are two issues.

	1) What spi use inside the SA payload in the negotiation.

	   For transactional mode this is easy, because there is no
	   SA payload, so it cannot have any SPIs.

	   For new group mode there is no real meaningfull information
	   to put in the SPI field, so it can be left empty (zero
	   length).

	2) What to put in to the error notification payloads SPI
	   field, when you want to send back error message for new
	   group mode or transactional mode.

The notification payload has a SPI field that can be used to find out
the correct exchange. Now if we have multiple new group mode exchanges
going on, and the other end sends us a error notification we do not
know which of the new group modes failed.

I wrote earlier, that we should define generic method of putting the
message id of the negotiation inside the notification payload. The
message id is the only way to uniquely identify the new group mode or
transactional exchange:

----------------------------------------------------------------------
Generic error/status notification to any phase II negotiation using
message ID to identify the negotiation:

	o  Payload Length - set to length of payload + size of data (var)
	o  DOI - set to IPSEC DOI (1)
	o  Protocol ID - set to PROTO_ISAKMP (1)
	o  SPI Size - set to four (4) bytes (if it is sixteen (16),
	   then SPI is two eight-octet ISAKMP cookies, and the error
	   message is for the Phase I negotiation)
	o  Notify Message Type - set to error code
	o  SPI - set to the message ID (4 bytes) of the negotiation
	o  Notification Data - fill in as normally.
----------------------------------------------------------------------

This method could be used to send notification to either to all phase
II exchanges, or only to all other phase II exchanges except Quick
Mode.

In the quick mode we still have some problems, that the sender can
select any of the protocols, and spis inside the SA proposal the other
end offered, so we have to loop through all quick mode exchanges we
have, and compare each protocol and spi inside each proposal to find
the matching spi.

I would rather use that above mentioned simplified method for them
too, but we might just want to keep that old method for quick mode, so
we do not change anything at this stage, we just allow new way of
sending error codes for exchanges where it is not yet defined. 

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

It doesn't really matter. If you accept any informational exchanges in
clear, then it always opens denial of service attack. Attacker can
always answer to your first SA proposal with a informational exchange
saying proposal not chosen...

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

I don't think so. I think we should say that all informational
exchanges done before the Phase I is finishes, is done in clear unless
we have previous Phase I exchange still available (rekeying 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.

I don't think that would gain as anything, because the keys are not
yet authenticated. The Diffie-Hellman is only authenticated after the
signature/hash payloads have been verified by the both ends, so we
cannot really trust keys before that. Sending exchanges authenticated
would just give out false sense of security.

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

Note, that there are two places that contains the same text, both must
be fixed. The other place is:

  "During phase 1 negotiations, the initiator and responder cookies
   determine the ISAKMP SA. Therefore, the SPI field in the Proposal
   payload is redundant and MAY be set to 0 or it MAY contain the
   transmitting entity's cookie."
-- 
kivinen@iki.fi                               Work : +358-9-4354 3218
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/


Follow-Ups: References: