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

RE: Summary of issues from RTP

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

>-----Original Message-----
>From:	Michael C. Richardson [SMTP:mcr@sandelman.ottawa.on.ca]
>Sent:	Tuesday, March 17, 1998 11:02 PM
>To:	ipsec@tis.com
>Subject:	Summary of issues from RTP
>
>-----BEGIN PGP SIGNED MESSAGE-----
>
>
>  {Don't ask me to present this in LA, I won't be there. The agenda doesn't
>say whether or not it will be in an MBONE room. If so, I'll be listening,
>DVMRP tunnel setup permitting. Email me if you can give me a tunnel!!!.
>
>  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. 
>
>  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. Some vendors are not yet supporting DOI-07 wrt the AH transform type,
>	and the AUTH attribute.
>	{ed note: I wanted to give an example, but I can't seem to.
>	I read as far back as DOI-04, but didn't see any changes... unless
>	the issus is that the Auth(HMAC-MD5) wasn't being sent???}
>
>  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.
>
> 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. (Relating to #5, and perhaps answering my question)
>	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.
> {ed: I must say that I'm not clear why we have two definitions here, and
>	I didn't find anything obvious by grepping my archives. If someone
>	tells me what month to look in...}
>
> {ed: I received nothing about any wire level transform level issues. This is
>	probably good.}
>
>   :!mcr!:            |  Sandelman Software Works Corporation, Ottawa, ON  
>   Michael Richardson |Network and security consulting and contract
>programming
> Personal: <A
>HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">m
>cr@sandelman.ottawa.on.ca</A>. PGP key available.
> Corporate: <A
>HREF="http://www.sandelman.ottawa.on.ca/SSW/">sales@sandelman.ottawa.on.ca</A
>>. 
>
>
>
>	
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.3ia
>Charset: latin1
>Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
>
>iQB1AwUBNQ9HH9iXVu0RiA21AQF+KAL+PWlBkRYOCwoXtbm1nW73nbKP+fTS813e
>k8JG6Hyhe9tgmI6gU57m1PiPL5GZAdZzyC1PCGFSfdsbnAT93kkuBgo8eBgD8ZcP
>cnJhJtHdRexpCZXsL5cYQ5bwqc464dOT
>=0OuF
>-----END PGP SIGNATURE-----