1Appendix: 2 3It's summary report of IPsec Interoperability Workshop Aug 31st- Sept 3 1998. 4To be consider each following items.. ;-( 5 6Location: Microsoft Campus, Redmond WA 7Attending: 60 people, 19 companies. 8 Axent/Raptor, Cisco IOS, Checkpoint, Intel, HiFn, Interlink, 9IRE, Microsoft NT5, Netscreen, Redcreek, SSH, Timestep, Worldcom/ANS, IRE, 10Free SWAN 11 Verisign, Entrust, Worldcom Advanced Networks - James 12Matheke, Digital Signature Trust Company, Microsoft PKI & Directory reps 13 L2TP/IPsec: Microsoft NT5 and Cisco IOS 14 15Handouts: 16(I will get these on a public web site ASAP. Stay tuned for pointer) 17 18Network Configuration Tear Sheet - network topology explanation & diagram 19Testing Matrix: had 43 options * (transport + tunnel) * (initial + rekey) = 20172 tests. 21Rodney Thayer's draft IPsec certificate profile 22IPsec Rekeying Issues powerpoint slides, by Tim Jenkins of Timestep 23Working copy of Draft-ietf-ipsec-ldap-schema.txt 24Powerpoint slides presented at IETF Policy BOF explaining 25draft-ietf-ipsec-ldap-schema.txt 26Microsoft Directory Enabled Networking Powerpoint slides by Steve Judd 27Microsoft Public Key Infrastructure Powerpoint slides by Rick Johnson 28Windows NT5.0 Beta2 walkthrough guide for creating IPsec policy 29 30 31Debriefing Survey 32================= 33On Wed and Thursday, I surveyed 8 companies with the following questions, 34saying that I would compile a list of responses without indicating vendors 35and post the compiled report to the IETF IPsec mailing list. Here are the 36results. I have attempted to reduce duplication by indicating in 37parentheses how many of the respondants indicated a similar response, eg (4) 38means 4 out of 8 vendors. There is no priority or ordering on these 39listings, other than popular reponses appear first. 40 41What did you fix? 42=========================================================== 43Policy mgmt bugs. Modification on end-to-end policy configuration (3) 44Fragmentation on large packet (2) 45Vendor id payload support 463DES key generation 47Multiple MM proposals are not draft compliant 48Initial contact handling 49Additional padding that expands payload in IKE MM 50Construction of id payload of type ID FQDN and ID USER NAME during RSA 51Signatures 52Fixed the parsing of pulling out the SubjectAltName out of the cert. 53Problems handling multiple proposals 54Problems handling the payload when 2 lifetypes were being sent, for example 55seconds and bytes. 56Better understanding of what is in main mode 57Circular cert chain signature handling 58Draft change to support initial contact 59Make sure that if peer sends back invalid ids, that they do not overwrite 60the initiators ids 61Ignore empty cert request payload 62Wrong checksum in inner payload header. Other implementations were not 63checking 64Empty payload of cert caused AV 65Cert signed circular chain handling 66ISAKMP config mode- hashing incorrectly 67RSA encryption mode- not encrypting all that we should 68AH + ESP negotiated for tunnel mode 69Nothing 70If we didn't receive proxy IDs during QM when negotiating transport mode, we 71would fail. Most vendors don't send these. IOS and NT do this to support 72protocol and port based filters. We need to add a test case to do this 73regularly. 74If we did not receive the encapsulation attribute, we would send it back. 75Wrongly padding the Oakley header length to 4 byte boundaries 76Bug found in test tools 77Where and HOW to encode v3 extensions in PKCS10 requests. Mostly due to how 78old BCERT toolkits used to do it which is not what RSA actually spec'd. 79 80What did you not fix - what still needs to be worked on? 81========================================================= 82PKI usage: Cert subject altname comparison with MM id payload, Certificate 83chain processing, CRL support, Cross-certification, DN in certs, Every (CA?) 84vendor had different cert request format (5) 85Using DSS/DSA - only supported by HiFn, CA vendors MS & Entrust & GTE (2) 86Fragmented TCP packets failing auth checks 87Need to send deletes for all of the SPIs when doing an AND proposal 88Initiating SAs 89Commit bit handling 90Rekey issues: Initiator switching to responder because original responder 91hit lifetime timeout first and visa-versa. 92Responder changing attributes in transform. 93The PKCS10 requests with v3 extensions. Currently MS puts then in a 94proprietary attribute (said they would change), the 'standard' attribute to 95put them in is the rsaExtensionsAttribute, however RSA BCERT and TIPEM 96toolkits add an extra level of encoding and encode the sequence of extension 97as a T61String which is NOT the documented format. The cure is to have CA 98vendors try to decode from both and have all new clients only do 99rsaExtensionsAttribute as Seq of Ext. 100 101What are the open IPsec design issues? 102======================================================== 103PKI usage, cert formats, CA enrollment, deployment model for cert-based 104trust, supporting CRLs, supporting cert request payload (5) 105Peer Recovery, stale/Inactive SAs which linger when peer has lost state. 106Orphaned phase2 SA. This can be due to a missed delete (since deletes are 107not reliable) or a system crash of a peer (4) 108ISAKMP header not authenticated. Initial contact & all notifications are not 109authenticated (4) 110Commit bit. Since it is unauthenticated if it is present in the IKE header. 111Is it still a MUST? (2) 112Version#s not authenticated in IKE header 113Common policy configuration & distribution for multiple vendor devices that 114a single manager can use. 115Mobile clients - preshared key per user? Lose identity protection with 116aggressive mode 117Rekey mechanism that doesn't lose traffic by design 118When tunneling traffic, do you reassemble packet first, then filter, then 119forward to tunnel? 120Configuration problems, ISAKMP config needs further work 121Support in drafts for authentication method per selector conflicts with 122using MM with QM. Applications can't use their own trust system for their 123traffic - must be manually configured out-of-band between machines (IP 124addresses). This is why MM with QM protection is abandoned by vendors in 125favor of aggressive mode, so that QM parameters, and also identities, can be 126known first to succeed with authentication. 127Race conditions when have multiple SAs to same box from one source, rekeying 128MM over multiple QM 129Multiple QM proposals 130How to get tunnels set up 131Mismatch filters in policy. When initiator should propose both the full 132filter breadth, as well as the specific packet protocol type/ports to the 133responder, so the responder can pick the widest clean match. 134Need some kind of model for using SNMP MIB for reporting and management of 135IPsec enabled devices. 136Think IKE is open to denial of service attack because anyone can provoke DH 137computation in MM. Should only create state when get cookie back to reduce 138denial of service. 139IKE over non-IP 140Disagreement on how AH with ESP in transport or tunnel mode should be 141expressed in policy, negotiated, or have their separate SAs managed 142Need full client-side configuration to support simultaneous tunnels from one 143client to different gateways 144Need "Credential Request Payload" more general than just certificate request 145payload, to support retry for authentication when both systems participate 146in multiple trust models. 147 148What are the open IPsec interop issues? If products shipped today, what 149problems would customers encounter with multiple IPsec products? 150================================================================ 151Policy expression, configuration for interop (5) 152Peer recovery of SAs, with mobile users, between two gateways (2) 153US export IPsec interop- no support at all in drafts for what products have 154to implement for ESP. Custom DH group for export not supported in drafts (2) 155Understanding why proposals failed- Error messages to detail why proposal 156not chosen (Michael Richardson going to collect error codes & messages from 157vendors) 158Multiple proposals for export not supported 159Policy distribution 160Client interop because clients haven't been tested much, mostly GW/FW 161Real world application usage/admin, where systems are taken up/down, address 162changes, etc. 163Biggest challenge is to cover all aspects/combinations 164Hard to balance tolerance of variance among IPsec implementations which is 165necessary for interop with strictness of checks to fulfill security and 166draft requirements. 167Scalability 168Some/many vendors not installing SA parameters which were negotiated, using 169what filter policy specified. 170Cert encoding for CRP, most people understand X.509 171Key usage flags in cert, what you expect to get back for generic or specific 172for data encryperment. Maybe define another type of cert field encoding, 173have 1-9, need 10. 174How to process Subject Altname 175Nobody else is doing encrypted nonces 176Enforcing check that traffic sent through IPsec format matches filter which 177was negotiated. This must be agreed upon by other vendors. Not covering 178this in bakeoff testing because people mostly ping and ftp test, not 179multi-protocol or multi-port through same SA. 180Having certificate storage and key signing operations on smartcards, where 181they don't provide a signature without the OID 182What was good about the bakeoff? 183========================================================= 184Small size, good working time (4) 185Organized well (2) 186Providing PCs, cables (2) 187Beer (2) 188Having a preplanned test matrix 189Having several CA vendors, ability to discuss and try CRLs, different certs 190Plenty of space, good friendly atmosphere. Microsoft people being very 191helpful 192Timing was good 193The network was setup when we got there. 194More than one network allocated for each vendor to allow gateway testing 195 196What wasn't so good about bakeoff? 197======================================================== 198Had to reconfigure because test net was not on Internet which for many 199caused a reboot. Only really need 4-5 class C addresses with preplanned 200private net space. Should have DHCP on external net. NAT from private to 201public wouldn't work using IPsec, of course, because using IPsec to get back 202home to company net. (3) 203Power failure Monday morning (2) 204Internet access via ISDN 128Kb was very slow (2) 205Didn't seem that anyone could cover the test matrix with another vendor even 20650%. 207Everyone still ping testing, not real traffic, limited ftp transfers for 208those who tried rekeying 209No T-shirts 210Clients were not really tested, mostly vendor's gateway/Firewall products. 211Not testing CRLs, not testing cert expirations 212Hard to understand why two systems would not interoperate 213Need phones at each station 214Network addressing plan was hard to read and understand what is needed. 215Need picture of topology. 216Impossible to design comprehensive test matrix, don't have time in a bakeoff 217to test all of these 218No time to get into real situation test 219Test matrix too confusing. Rather see list of topologies with spec of "to 220reach my network do this MM proposal and these different policies for telnet 221and http" 222 223For next bakeoff at IBM, what should be done? 224======================================================== 225Test rekey in each direction under stress (4). Use FTP for this. 226Huge payload to test fragmentation & reassembly in IPsec ESP, AH under load 227(2) 228Seat vendors together who more advanced in their IPSEC/IKE implementations. 229Otherwise it will be n-X-n testing matrix which is impossible with 60 230vendors present. 231Post test matrix to the IPsec list before the event to get comments on it's 232completeness 233Make sure real world topology is tested: static IP client -> GW -- internal 234net -- servers on PCs 235ICSA should say more about rekeying issues, or allow vendors out of their 236NDA signed during certification testing to discuss rekeying issues 237Not relying on non-mandatory messages 238Peer recovery testing 239Negotiating and maintaining many SAs 240Need next NT5.0 post-beta2 release to test with 241Need denial of service and IPsec knowlegable attack tests 242Need a complete implementation of all IPsec capabilities to test against, 243Need an attacker box to test against 244All CA vendors should support Subject Altname 245Need telephone at desk 246Need vendors capabilities listed and what they want to test in advance 247Test nested tunnels 248Test transport over tunnel mode 249Test random IP addresses to simulate mobility 250Have bakeoff at the same place where you stay, in hotel 251Attack testing 252 253End of Report 254 255 256