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

Summary of issues from RTP (second edition)

  I will update this list again on the 27th. I have taken the list, removed
the headers, signatures, and reworded some parts. Please let me know if I've
screwed up what you are saying.}

  1. ISAKMP SPI sizes. Some implementations get upset (i.e. crash) when
	  offered different sizes. (2 octets was required for the IPcomp people)

  2. ISAKMP payloads had to be in the order they are documented in the draft.
	Most ISAKMP payloads may be sent in any order. The exception is that
	there is a proscribed relationship between some payloads
	(i.e. proposal payloads, transform payloads, etc)

  3. IP address in CERTs. Some people expected strings, other expected
	4 octets in ipAddress. If string, then is it: CN vs Unstructured or
	subjectAltName. 

	One response:
	"It is never a string when encoded in subjectAltName."

	"I believe consensus was that if IP Addresses (or dns name or rfc822)
	were going to be added to an X.509 certificate then they should go into
	the subjectAltName extension (that is after all what it is for).  This
	is consistent with work done in the PKIX WG."

  4. Some implementations are sending a replay protection number of 0
	when manually keying. "I was under the impression sequence # 0 should
	NEVER go on the wire, but hey, what do I know?"

  5. (see #14)	

  6. Some vendors used old isakmp-08 certificate request format, but the data
	  attrbute used in the payload was incorrectly formatted (or missing).		 
	{ed note: isakmp-09 was not publically available for the interop}

  7. Some vendors did not like getting a key hash payload in rsa encryption
	  mode. 

  8. Some vendors were discarding entire ISAKMP packet when an unknown
	notify payload was received. Only the single payload should be
	discarded.
	
  9. Some vendors did not like receiving certificate request payloads when 
	using pre shared keys. (The isakmp draft says certificate requests
	payloads can exist in any message).

 10. Some vendors did not like receiving certificate request payloads at any
	time. 

 11. Some vendors did not like ISAKMP packet to be padded to a multiple of 4
	bytes.
	Q: Does the spec allow this?
	A: There was some argument about whether this is REQUIRED.
	{ed: It would seem to fall into the "be conservative in what
	you generate and liberal in what you accept" }

 12. Some vendors expected to see client ID's in phase 2. This caused
	quick mode to complete, but fail to install the SA properly.

 13. Some vendors were not prepared to receive INITIAL-CONTACT notifies. This
	caused premature termination of the negotiation. Speculation that
	some vendors may terminate on any unknown status-level information
	notifications. 

 14. Some vendors were not sending both the AH Transform type (e.g. AH_MD5)
	AND the Authentication Algorithm attribute (e.g. HMAC-MD5)
	Some vendors would not accept receiving both the the Transform type
	and the Authentication Algorithm attribute. To quote a better description:

	"1) some people were not sending the Auth(HMAC-*) attribute, and yet expecting
	   the resulting transform to be HMAC-*.

	2) some people would *reject* an AH transform with an Auth(HMAC) attribute!
	   This is clearly an error!"

 15. Some vendors do not accept a QuickMode ID type of IP4_ADDR_RANGE while
	they do accept IP4_ADDR and IP4_ADDR_SUBNET. 
	{ed: Clearly IP4_ADDR_RANGE of 192.168.34.0 -> 192.168.34.255 is equivalent
			to IP4_ADDR_SUBNET of 192.168.34.0/24.
	 ed: I'm confused. Where is this defined? Did ISAKMP 09 remove
	     		all but ADDR and ADDR_SUBNET???}

 16. Some vendors could not handle larger sized nonces (40 bytes) and
	would only allow 20 byte nonces.  The new IKE document does state: 

	   The length of nonce payload MUST be between 8 and 256 bytes
	   inclusive.

 {ed: I received nothing about any wire level transform level issues. This is
	probably good.}

   :!mcr!:            |  Sandelman Software Works Corporation, Ottawa, ON  
   Michael Richardson |	SSH IPsec: http://www.ssh.fi/. Secure, strong, international
 Personal: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.
 Corporate: <A HREF="http://www.sandelman.ottawa.on.ca/SSW/">sales@sandelman.ottawa.on.ca</A>.