From owner-ipsec Mon Nov 2 10:21:18 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA12734 for ipsec-outgoing; Mon, 2 Nov 1998 10:07:37 -0500 (EST) Message-Id: <3.0.1.32.19981102201359.006e22d0@172.16.1.10> X-Sender: rohit@172.16.1.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 02 Nov 1998 20:13:59 +0500 To: kent@bbn.com From: rohit Subject: PropSelection Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi All, I wanted some clearification in the following scanerio of IPSec+IKE implementation. If we have SG1, SG2 and IPSec capable host H2 in the following scanerio, |--------ESPtunnel---- | | | SG1 ----------------- SG2 ----------- H2 | | |------------------AH Tunnel-----------| and the security policies are as follows. At SG1 OutBound Policy is Proposal #1: For SG2 : ESP with 3DES For H2 : AH with SHA1 Proposal #2: For SG2 : ESP with DES For H2 : AH with MD5 At SG2 we have the Inbound Policy as Proposal # 1 : ESP with DES H2 has the inbound policy as Proposal # 1: AH with SHA1 During IKE negotiation, SG1 sends out the SAPayload(with two proposals it has) to SG2 and H2. SG2 will select Proposal #2 of SG1 and H2 will select Proposal # 1 of SG1. The Question is how we can form a SABundle from the selected Proposals at SG1? Should we have to reject the responses as both SG2 and H2 have selected two different proposals ? Any suggestions will be appreciated. -Thanks a lot Rohit ************************************************************************* -: Bridging The Gap Between Software And Hardware :- Rohit Aradhya Ph : (040)7742606 Rendzevous Onchip Pvt Ltd. Em : rohit@trinc.com First Floor, Plot No 14 New Vasavi Nagar, Karkhana Secunderbad -500019. India ************************************************************************** From owner-ipsec Mon Nov 2 16:41:03 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA21071 for ipsec-outgoing; Mon, 2 Nov 1998 16:37:46 -0500 (EST) Date: Mon, 2 Nov 1998 16:55:47 -0500 Message-Id: <199811022155.QAA12479@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ipsec@tis.com Subject: marketing misuse of IPSECond efforts X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk Earlier there was a discussion on the list about misquotations in trade press articles about IPSECond. It's going downhill... now there is a company promoting a totally proprietary security architecture with the arguments that IPSEC is insecure, not suitable for high performance networks, and "back on the drawing board". See http://www.fortresstech.com/stories/story_130.html for the full text. Egads... paul From owner-ipsec Tue Nov 3 09:15:52 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA21619 for ipsec-outgoing; Tue, 3 Nov 1998 09:11:46 -0500 (EST) Message-Id: <3.0.1.32.19981103173528.0074e680@172.16.1.10> X-Sender: rohit@172.16.1.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 03 Nov 1998 17:35:28 +0500 To: kent@bbn.com From: rohit Subject: Selection of proposals Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi All, The scenario I sent in yesterday didnt give all the details and I am modifying it to give the exact scenario... If we have SG1, SG2 and IPSec capable host H2 in the following scenario, |--------ESPtunnel---- | | | SG1 ----------------- SG2 ----------- H2 | | |------------------AH Tunnel-----------| and the security policies are as follows. At SG1 OutBound Policy is Proposal #1: For SG2 : ESP with 3DES or ESP with DES For H2 : AH with SHA1 or AH with MD5 At SG2 we have the Inbound Policy as Proposal # 1 : ESP with 3DES or ESP with DES H2 has the inbound policy as Proposal # 1: AH with MD5 During IKE negotiation, SG1 sends out the SAPayload(with the two transforms it has) to SG2 and H2. SG2 will select Transform #1 of SG1 and H2 will select Transform # 2 of SG1. Because of this, an SA bundle that perfectly matches the proposal cannot be formed by SG1. However, SG2 is capable of processing with DES and had SG2 selected this, it could have formed an SA bundle at SG1. Do we just reject the proposal at this stage or is it permitted to send the two transforms as different proposal payloads in independent SA payloads and try to see if a match can be found amongst all available proposals? The problem here is, of course, the fact that H2 and SG2 look at the individual and independent SPDs while SG1 looks at the combined SA bundle. Any suggestions will be appreciated. -Thanks a lot Rohit From owner-ipsec Tue Nov 3 11:40:20 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA23549 for ipsec-outgoing; Tue, 3 Nov 1998 11:31:48 -0500 (EST) Message-ID: <70C20C1647EBD11183F800805FA67B4333C4CB@vpnet.com> From: Sumit Vakil To: ipsec@tis.com Subject: RE: Selection of proposals Date: Tue, 3 Nov 1998 08:49:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk > -----Original Message----- > From: rohit [mailto:rohit@trinc.com] > Sent: Tuesday, November 03, 1998 4:35 AM > To: kent@bbn.com > Cc: ipsec@tis.com > Subject: Selection of proposals > > > Hi All, > > The scenario I sent in yesterday didnt give all the details and I am > modifying it to give the exact scenario... > > If we have SG1, SG2 and IPSec capable host H2 in the following > scenario, > > > |--------ESPtunnel---- | > | | > SG1 ----------------- SG2 ----------- H2 > | | > |------------------AH Tunnel-----------| > > > and the security policies are as follows. > > At SG1 OutBound Policy is > > Proposal #1: > For SG2 : ESP with 3DES > or ESP with DES > For H2 : AH with SHA1 > or AH with MD5 > > At SG2 we have the Inbound Policy as > > Proposal # 1 : > ESP with 3DES > or ESP with DES > > H2 has the inbound policy as > > Proposal # 1: > AH with MD5 > > > During IKE negotiation, SG1 sends out the SAPayload(with the two > transforms it has) to SG2 and H2. SG2 will select Transform > #1 of SG1 and > H2 will select Transform # 2 of SG1. Because of this, an SA > bundle that > perfectly matches the proposal cannot be formed by SG1. > However, SG2 is > capable of processing with DES and had SG2 selected this, it > could have > formed an SA bundle at SG1. > SG1 will run two separate IKE exchanges - one with SG2 and the other with H2. If it proposes [ESP (3DES or DES) and AH (SHA1 or MD5)] to SG1, obviously the exchange is going to fail because SG2 is not configured for AH. If it proposes just the ESP transforms, SG2 will pick one, and a set of inbound and outbound ESP SAs will be created between SG1 and SG2. Similarly, a set of AH SAs will be created between SG1 and H2. These two sets of SAs are independent of each other. What SG2 picks during IKE has nothing to do with what H2 picks. If you want to logically link the two sets of SAs on SG1 together, that's fine. On SG1, you'd really have: For SG2: Proposal #1: ESP with 3DES or ESP with DES For H2: Proposal #1: AH with SHA1 or AH with MD5 Sumit A. Vakil VPNet Technologies, Inc. From owner-ipsec Tue Nov 3 15:26:37 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA26757 for ipsec-outgoing; Tue, 3 Nov 1998 15:24:47 -0500 (EST) Date: Tue, 3 Nov 1998 15:24:47 -0500 (EST) From: owner-ipsec@ex.tis.com Message-Id: <199811032024.PAA26757@portal.ex.tis.com> [192.94.214.100]) by portal.ex.tis.com (8.9.1/8.9.1) with ESMTP id MAA24704 for ; Tue, 3 Nov 1998 12:56:44 -0500 (EST) (4.1) id xma006520; Tue, 3 Nov 98 13:20:19 -0500 (dhcp200.local.windrose.omaha.ne.us [10.9.200.200]) by privateer.windrose.omaha.ne.us (8.8.7/8.8.7) with SMTP id MAA26702; Tue, 3 Nov 1998 12:17:05 -0600 (CST) From: "Ryan Moats" To: Cc: , , , , Subject: Comments on draft-ietf-ipsec-vpn-policy-schema-00 Date: Tue, 3 Nov 1998 12:14:09 -0600 Message-ID: <001201be0755$c050fbe0$c8c8090a@sloop.local.windrose.omaha.ne.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk In reading draft-ietf-ipsec-vpn-policy-schema-00, several questions for clarification need to be asked. While most of these are editorial in nature, one is technical. In RFC 2247, the "dc" component is introduced as a potential RDN. In RFC 2377, this concept is extended by introducing the "uid" component as a potential RDN. By requiring [MUST] "CommonName" as the RDN for all objects in this schema, you preclude anyone from building a naming plan based on "dc" and "uid". Rather, CommonName, DomainComponent, and UniqueIdentifier should all be optional [MAY]. This allows directory implementors more flexibility in setting up their naming plans. In addition to this, it would also be useful if PolicyContainmentAuxClass also included the Domain class in the list of potential parents. Now for the editorial comments: While implicitly stated, an explicit statement that the PoliciesContainedRef attribute of the PolicyContainmentAuxClass points to Policy class objects would be more clear. In class IPPolicyCondition, is the attribute name HostUserIDRef (page x) or UserIDConditionRef (page xiii)? On page xxvii, does the PrivateDiffieHellmanGroupRef point to a DiffieHellmanGroup object or a PrivateDiffieHellmanGroup object? It is not clear. On page xxix, "private DiffieHellmanGroup" should be "PrivateDiffieHellmanGroup". The classes ISAKMPProposal, IPSecProposal, IPSecTransform, and PrivateDiffieHellmanGroup don't have explicit type definitions. Therefore, according to RFC 2252, they default to STRUCTURAL. Is this the your intent? (Clarification) Finally, the draft's designation (draft-...) changes throughout the document. From owner-ipsec Tue Nov 3 20:19:15 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA04515 for ipsec-outgoing; Tue, 3 Nov 1998 20:17:09 -0500 (EST) Message-ID: <363FAF71.10C97F5D@redcreek.com> Date: Tue, 03 Nov 1998 17:35:45 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@tis.com Subject: minor inconsistency in arch doc (maybe) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Just running back through the arch doc when I became a bit confused about something - maybe someone can help me out here. In section 4.4.2 (selectors), it says in part, '- Transport Layer Protocol: Obtained from the IPv4 "Protocol" or the IPv6 "Next Header" fields. This may be an individual protocol number. These packet fields may not contain the Transport Protocol due to the presence of IP extension headers, e.g., a Routing Header, AH, ESP, Fragmentation Header, Destination Options, Hop-by-Hop options, etc. Note that the Transport Protocol may not be available in the case of receipt of a packet with an ESP header, thus a value of "OPAQUE" SHOULD be supported.' I've always been under the impression that it is reasonable to use ESP/AH in this field, and in fact, this permits configuration of nested SAs, perhaps with different endpoints. The text seems to imply that this is inappropriate, but I don't think that's what is really meant. Earlier (section 4.4.1, last paragraph), explicit reference is made to using ESP as a selector for a discard action: 'Note that a security gateway could prohibit traversal of encrypted packets in various ways, e.g., having a DISCARD entry int he SPD for ESP packets or providing proxy key exchange.' Is the confusion here due to IPv4 vs IPv6 differences, or what? From owner-ipsec Wed Nov 4 10:07:57 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA00208 for ipsec-outgoing; Wed, 4 Nov 1998 10:04:19 -0500 (EST) Message-Id: <199811041528.KAA10883@relay.hq.tis.com> Date: Wed, 4 Nov 98 10:16:13 EST From: Charles Lynn To: "Scott G. Kelly" cc: ipsec@tis.com Subject: Re: minor inconsistency in arch doc (maybe) Sender: owner-ipsec@ex.tis.com Precedence: bulk Scott, > I've always been under the impression that it is reasonable to use > ESP/AH in this field, and in fact, this permits configuration of nested > SAs, perhaps with different endpoints. Yes, I agree with that, too. I think that the "problem" arises from the ambiguity of the term "Transport Layer Protocol". In a sense, ESP is a transport layer protocol (to the closest preceeding IP header), but AH isn't. As the concepts become more complex, the simple terminology that was previously clear may not keep up with our more refined concepts. (For example, is a security gateway a "Host" or a "Router"? If a "Host", it MUST NOT forward packets not addressed to itself. If a "Router", it MUST run routing protocols and conform to Router Requirements. I think a SG or firewall may be neither.) > Is the confusion here due to IPv4 vs IPv6 differences, or what? I do not think so. When I read the text you cited, from an implementor's perspective, what I see is a warning. The field in a packet corredsponding to "Transport Layer Protocol" is no longer a simple object to find. It may be in the IPv? header, or it may be in one of possibly several extension headers (note both that anything the implementation does not "understand" becomes a transport protocol, and that some folks are using "extension headers" in IPv4, and not just AH). So when the code to find the field is written, it may have to be called several times to check successive places in a packet (returning "OPAQUE" when it cannot find any more), or the function may return a list of values, depending on how one implements things. At one point (if I remember correctly :-), there was another selector that tried to distinguish between "Transport Layer Protocol" and extension headers. It was removed, maybe because it made things "too complex". The complexity does not go away, it just permutes into a different form. Does this correspond to your understanding of what is needed to support the types of policies we need? Do you have any suggestions for clearer text? Charlie From owner-ipsec Wed Nov 4 11:43:58 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA01565 for ipsec-outgoing; Wed, 4 Nov 1998 11:39:23 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF4F7C55@exchange> From: Roy Pereira To: "IPSEC Mailing List (E-mail)" Subject: IBM VPN Bakeoff Issues Date: Wed, 4 Nov 1998 11:58:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE0814.55375440" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE0814.55375440 Content-Type: text/plain; charset="iso-8859-1" There are IPSec issues that were brought up at last week's IPSec bakeoff: 1. All vendors must support the "Vendor ID" payload. Ignore it if you want, but don't crash. 2. Some vendors don't handle tunnel mode with the same inner and outer addresses. This is a valid configuration and should be supported. 3. It is invalid to send a key length attribute with a fixed-length cipher algorithm. 4. The size of SPIs in NOTIFY messages is ambiguous. Some vendors send zero bytes while others send 16 bytes. We need to clarify the wording in the documents. 5. Some vendors require that the insignificant portion of an address part of a subnet address be zeroed (ie. 10.1.1.0/255.255.255.0 instead of 10.1.1.23/255.255.255.0). 6. What SPI should be sent in a DELETE message? Some vendors send zero sized SPI, some send 16 bytes of SPI. 7. Attributes other than life-duration and life-type must not be duplicated in the same transform. Those two attributes must only be included a maximum of twice and the life-type attribute must have different values. (ie. seconds and kilobytes) 8. DH Group 5 needs to be documented. A lot of vendors support this group. 9. Should the order of protocols dictate the order of security association or should AH, ESP, IPComp always be processed in a certain order? Most vendors agreed with the latter. 10. Some vendors were changing the order of the ID payloads when they were responders. Some other responders were also changing ports. This is incorrect behaviour. 11. Key length is not defined for phase 1 negotiations. Actually it is defined in IKE v.8 as attribute #14. 12. Does ESP-NULL require padding (the ESP doc says 4-byte alignment, ESP-NULL doc says 1-byte alignment). The consensus was that ESP is 4-byte aligned. 13. Microsoft's export DH group is not documented. Not sure if it needs to be. 14. Is proposing "RC5 with 128 bit key length" the same as proposing "RC5" since 128 bits is the default key size? Should vendor's be aware of the default key size and equate comparable cipher/key sizes? 15. We still have confusion around the commit bit. 16. If an initiator requests an SA with only a single IP address as the destination, but the responder has a local policy of a subnet (instead of a single IP address), should it fail the negotiation? Some vendors were doing this. 17. The HASH payload must be the first payload in a info/new group exchange. This isn't clear in the documents. 18. Some interest in the Meta ID type. 19. Phase 2 ID payloads are optional and may be absent when negotiating transport mode. Some vendors required these payloads to be present. 20. It would be nice if Delete messages supported multiple protocols instead of just one protocol. This is handy for deleting SA bundles. 21. The phase 1 IKE SA cannot expire while its phase 2 negotiation is in progress. 22. We need further clarification on when Notify messages start becoming encrypted. Some vendors start encrypting after message 4 of MainMode, some wait until phase 1 complete. 23. We need further clarification concerning the authentication algorithm's use when negotiating AH. 24. Someone pointed out that the same DH group has to be used for all proposals when using Aggressive Mode and Quick Mode. 25. Someone pointed out that the ID payload is redundant if we are doing RSA_SIG authentication, since the certificate already has the identity. 26. We need clarification on the SPI usage in phase 1's SA payload. The documents state it can have 0-16 bytes. 27. Vendors should be aware of different IKE version numbers. Currently v0.1 and v1.0 are defined. The text needs to be clearer on version numbers. 28. Vendors should report errors according to the ISAKMP document, section 5. "Invalid Cookie" doesn't cut it. 29. The notify messages need to be explained. There's currently no description of what any of the NOTIFY codes mean. 30. There seams to be a lot of overlap between ISAKMP and IKE & IPSec-DOI. This is confusing for IPSec new-comers. 31. Do we allow CertReq payloads in shared-secret mode? Yup, but you probably don't want to reply back with a certificate. 32. Should proposal rank number start with 1 or zero and should they increase by 1 ? 33. Vendors must support the third AggressiveMode message being encrypted. 34. What should the maximum number of proposals be? Some vendors only handled a limited number of proposals. 35. What does an empty CertReq mean? Currently no documentation on this issue. 36. X.500 DN is a valid ID type when doing shared-secret authentication. Roy Pereira Senior Product Manager, TimeStep Corporation (613) 599-3610 x4808 http://www.timestep.com ------_=_NextPart_001_01BE0814.55375440 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IBM VPN Bakeoff Issues

There are IPSec issues that were = brought up at last week's IPSec bakeoff:

1. All vendors must support the = "Vendor ID" payload. Ignore it if you want, but don't = crash.

2. Some vendors don't handle tunnel = mode with the same inner and outer addresses.  This is a valid = configuration and should be supported.

3. It is invalid to send a key length = attribute with a fixed-length cipher algorithm.

4. The size of SPIs in NOTIFY messages = is ambiguous.  Some vendors send zero bytes while others send 16 = bytes.  We need to clarify the wording in the = documents.

5. Some vendors require that the = insignificant portion of an address part of a subnet address be zeroed = (ie. 10.1.1.0/255.255.255.0 instead of = 10.1.1.23/255.255.255.0).

6. What SPI should be sent in a DELETE = message?  Some vendors send zero sized SPI, some send 16 bytes of = SPI.

7. Attributes other than life-duration = and life-type must not be duplicated in the same transform.  Those = two attributes must only be included a maximum of twice and the = life-type attribute must have different values. (ie. seconds and = kilobytes)

8. DH Group 5 needs to be = documented.  A lot of vendors support this group.

9. Should the order of protocols = dictate the order of security association or should AH, ESP, IPComp = always be processed in a certain order?  Most vendors agreed with = the latter.

10. Some vendors were changing the = order of the ID payloads when they were responders.  Some other = responders were also changing ports. This is incorrect = behaviour.

11. Key length is not defined for = phase 1 negotiations.  Actually it is defined in IKE v.8 as = attribute #14.

12. Does ESP-NULL require padding (the = ESP doc says 4-byte alignment, ESP-NULL doc says 1-byte = alignment).  The consensus was that ESP is 4-byte = aligned.

13. Microsoft's export DH group is not = documented.  Not sure if it needs to be.

14. Is proposing "RC5 with 128 = bit key length" the same as proposing "RC5" since 128 = bits is the default key size?  Should vendor's be aware of the = default key size and equate comparable cipher/key sizes?

15. We still have confusion around the = commit bit.

16. If an initiator requests an SA = with only a single IP address as the destination, but the responder has = a local policy of a subnet (instead of a single IP address), should it = fail the negotiation?  Some vendors were doing this.

17. The HASH payload must be the first = payload in a info/new group exchange.  This isn't clear in the = documents.

18.  Some interest in the Meta ID = type.

19. Phase 2 ID payloads are optional = and may be absent when negotiating transport mode.  Some vendors = required these payloads to be present.

20. It would be nice if Delete = messages supported multiple protocols instead of just one = protocol.  This is handy for deleting SA bundles.

21. The phase 1 IKE SA  cannot = expire while its phase 2 negotiation is in progress.

22. We need further clarification on = when Notify messages start becoming encrypted.  Some vendors start = encrypting after message 4 of MainMode, some wait until phase 1 = complete.

23. We need further clarification = concerning the authentication algorithm's use when negotiating = AH.

24. Someone pointed out that the same = DH group has to be used for all proposals when using Aggressive Mode = and Quick Mode.

25. Someone pointed out that the ID = payload is redundant if we are doing RSA_SIG authentication, since the = certificate already has the identity.

26. We need clarification on the SPI = usage in phase 1's SA payload.  The documents state it can have = 0-16 bytes.

27. Vendors should be aware of = different IKE version numbers.  Currently v0.1 and v1.0 are = defined.  The text needs to be clearer on version = numbers.

28. Vendors should report errors = according to the ISAKMP document, section 5.  "Invalid = Cookie" doesn't cut it.

29. The notify messages need to be = explained.  There's currently no description of what any of the = NOTIFY codes mean.

30. There seams to be a lot of overlap = between ISAKMP and IKE & IPSec-DOI.  This is confusing for = IPSec new-comers.

31. Do we allow CertReq payloads in = shared-secret mode?  Yup, but you probably don't want to reply = back with a certificate.

32. Should proposal rank number start = with 1 or zero and should they increase by 1 ?

33. Vendors must support the third = AggressiveMode message being encrypted.

34. What should the maximum number of = proposals be?  Some vendors only handled a limited number of = proposals.

35. What does an empty CertReq = mean?  Currently no documentation on this issue.

36. X.500 DN is a valid ID type when = doing shared-secret authentication.




Roy Pereira
Senior Product Manager, TimeStep = Corporation
(613) 599-3610 x4808
http://www.timestep.com

------_=_NextPart_001_01BE0814.55375440-- From owner-ipsec Wed Nov 4 11:44:03 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA01566 for ipsec-outgoing; Wed, 4 Nov 1998 11:39:23 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF4F7C57@exchange> From: Roy Pereira To: "IPSEC Mailing List (E-mail)" Subject: IBM VPN Bakeoff Issues Date: Wed, 4 Nov 1998 11:58:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE0814.644E4E40" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE0814.644E4E40 Content-Type: text/plain; charset="iso-8859-1" There are IPSec issues that were brought up at last week's IPSec bakeoff: 1. All vendors must support the "Vendor ID" payload. Ignore it if you want, but don't crash. 2. Some vendors don't handle tunnel mode with the same inner and outer addresses. This is a valid configuration and should be supported. 3. It is invalid to send a key length attribute with a fixed-length cipher algorithm. 4. The size of SPIs in NOTIFY messages is ambiguous. Some vendors send zero bytes while others send 16 bytes. We need to clarify the wording in the documents. 5. Some vendors require that the insignificant portion of an address part of a subnet address be zeroed (ie. 10.1.1.0/255.255.255.0 instead of 10.1.1.23/255.255.255.0). 6. What SPI should be sent in a DELETE message? Some vendors send zero sized SPI, some send 16 bytes of SPI. 7. Attributes other than life-duration and life-type must not be duplicated in the same transform. Those two attributes must only be included a maximum of twice and the life-type attribute must have different values. (ie. seconds and kilobytes) 8. DH Group 5 needs to be documented. A lot of vendors support this group. 9. Should the order of protocols dictate the order of security association or should AH, ESP, IPComp always be processed in a certain order? Most vendors agreed with the latter. 10. Some vendors were changing the order of the ID payloads when they were responders. Some other responders were also changing ports. This is incorrect behaviour. 11. Key length is not defined for phase 1 negotiations. Actually it is defined in IKE v.8 as attribute #14. 12. Does ESP-NULL require padding (the ESP doc says 4-byte alignment, ESP-NULL doc says 1-byte alignment). The consensus was that ESP is 4-byte aligned. 13. Microsoft's export DH group is not documented. Not sure if it needs to be. 14. Is proposing "RC5 with 128 bit key length" the same as proposing "RC5" since 128 bits is the default key size? Should vendor's be aware of the default key size and equate comparable cipher/key sizes? 15. We still have confusion around the commit bit. 16. If an initiator requests an SA with only a single IP address as the destination, but the responder has a local policy of a subnet (instead of a single IP address), should it fail the negotiation? Some vendors were doing this. 17. The HASH payload must be the first payload in a info/new group exchange. This isn't clear in the documents. 18. Some interest in the Meta ID type. 19. Phase 2 ID payloads are optional and may be absent when negotiating transport mode. Some vendors required these payloads to be present. 20. It would be nice if Delete messages supported multiple protocols instead of just one protocol. This is handy for deleting SA bundles. 21. The phase 1 IKE SA cannot expire while its phase 2 negotiation is in progress. 22. We need further clarification on when Notify messages start becoming encrypted. Some vendors start encrypting after message 4 of MainMode, some wait until phase 1 complete. 23. We need further clarification concerning the authentication algorithm's use when negotiating AH. 24. Someone pointed out that the same DH group has to be used for all proposals when using Aggressive Mode and Quick Mode. 25. Someone pointed out that the ID payload is redundant if we are doing RSA_SIG authentication, since the certificate already has the identity. 26. We need clarification on the SPI usage in phase 1's SA payload. The documents state it can have 0-16 bytes. 27. Vendors should be aware of different IKE version numbers. Currently v0.1 and v1.0 are defined. The text needs to be clearer on version numbers. 28. Vendors should report errors according to the ISAKMP document, section 5. "Invalid Cookie" doesn't cut it. 29. The notify messages need to be explained. There's currently no description of what any of the NOTIFY codes mean. 30. There seams to be a lot of overlap between ISAKMP and IKE & IPSec-DOI. This is confusing for IPSec newcomers. 31. Do we allow CertReq payloads in shared-secret mode? Yup, but you probably don't want to reply back with a certificate. 32. Should proposal rank number start with 1 or zero and should they increase by 1 ? 33. Vendors must support the third AggressiveMode message being encrypted. 34. What should the maximum number of proposals be? Some vendors only handled a limited number of proposals. 35. What does an empty CertReq mean? Currently no documentation on this issue. 36. X.500 DN is a valid ID type when doing shared-secret authentication. Roy Pereira Senior Product Manager, TimeStep Corporation (613) 599-3610 x4808 http://www.timestep.com ------_=_NextPart_001_01BE0814.644E4E40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IBM VPN Bakeoff Issues

There are IPSec issues that were = brought up at last week's IPSec bakeoff:

1. All vendors must support the = "Vendor ID" payload. Ignore it if you want, but don't = crash.

2. Some vendors don't handle tunnel = mode with the same inner and outer addresses.  This is a valid = configuration and should be supported.

3. It is invalid to send a key length = attribute with a fixed-length cipher algorithm.

4. The size of SPIs in NOTIFY messages = is ambiguous.  Some vendors send zero bytes while others send 16 = bytes.  We need to clarify the wording in the = documents.

5. Some vendors require that the = insignificant portion of an address part of a subnet address be zeroed = (ie. 10.1.1.0/255.255.255.0 instead of = 10.1.1.23/255.255.255.0).

6. What SPI should be sent in a DELETE = message?  Some vendors send zero sized SPI, some send 16 bytes of = SPI.

7. Attributes other than life-duration = and life-type must not be duplicated in the same transform.  Those = two attributes must only be included a maximum of twice and the = life-type attribute must have different values. (ie. seconds and = kilobytes)

8. DH Group 5 needs to be = documented.  A lot of vendors support this group.

9. Should the order of protocols = dictate the order of security association or should AH, ESP, IPComp = always be processed in a certain order?  Most vendors agreed with = the latter.

10. Some vendors were changing the = order of the ID payloads when they were responders.  Some other = responders were also changing ports. This is incorrect = behaviour.

11. Key length is not defined for = phase 1 negotiations.  Actually it is defined in IKE v.8 as = attribute #14.

12. Does ESP-NULL require padding (the = ESP doc says 4-byte alignment, ESP-NULL doc says 1-byte = alignment).  The consensus was that ESP is 4-byte = aligned.

13. Microsoft's export DH group is not = documented.  Not sure if it needs to be.

14. Is proposing "RC5 with 128 = bit key length" the same as proposing "RC5" since 128 = bits is the default key size?  Should vendor's be aware of the = default key size and equate comparable cipher/key sizes?

15. We still have confusion around the = commit bit.

16. If an initiator requests an SA = with only a single IP address as the destination, but the responder has = a local policy of a subnet (instead of a single IP address), should it = fail the negotiation?  Some vendors were doing this.

17. The HASH payload must be the first = payload in a info/new group exchange.  This isn't clear in the = documents.

18.  Some interest in the Meta ID = type.

19. Phase 2 ID payloads are optional = and may be absent when negotiating transport mode.  Some vendors = required these payloads to be present.

20. It would be nice if Delete = messages supported multiple protocols instead of just one = protocol.  This is handy for deleting SA bundles.

21. The phase 1 IKE SA  cannot = expire while its phase 2 negotiation is in progress.

22. We need further clarification on = when Notify messages start becoming encrypted.  Some vendors start = encrypting after message 4 of MainMode, some wait until phase 1 = complete.

23. We need further clarification = concerning the authentication algorithm's use when negotiating = AH.

24. Someone pointed out that the same = DH group has to be used for all proposals when using Aggressive Mode = and Quick Mode.

25. Someone pointed out that the ID = payload is redundant if we are doing RSA_SIG authentication, since the = certificate already has the identity.

26. We need clarification on the SPI = usage in phase 1's SA payload.  The documents state it can have = 0-16 bytes.

27. Vendors should be aware of = different IKE version numbers.  Currently v0.1 and v1.0 are = defined.  The text needs to be clearer on version = numbers.

28. Vendors should report errors = according to the ISAKMP document, section 5.  "Invalid = Cookie" doesn't cut it.

29. The notify messages need to be = explained.  There's currently no description of what any of the = NOTIFY codes mean.

30. There seams to be a lot of overlap = between ISAKMP and IKE & IPSec-DOI.  This is confusing for = IPSec newcomers.

31. Do we allow CertReq payloads in = shared-secret mode?  Yup, but you probably don't want to reply = back with a certificate.

32. Should proposal rank number start = with 1 or zero and should they increase by 1 ?

33. Vendors must support the third = AggressiveMode message being encrypted.

34. What should the maximum number of = proposals be?  Some vendors only handled a limited number of = proposals.

35. What does an empty CertReq = mean?  Currently no documentation on this issue.

36. X.500 DN is a valid ID type when = doing shared-secret authentication.




Roy Pereira
Senior Product Manager, TimeStep = Corporation
(613) 599-3610 x4808
http://www.timestep.com

------_=_NextPart_001_01BE0814.644E4E40-- From owner-ipsec Wed Nov 4 12:40:10 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA02748 for ipsec-outgoing; Wed, 4 Nov 1998 12:39:23 -0500 (EST) Message-ID: <36409585.54184A6A@redcreek.com> Date: Wed, 04 Nov 1998 09:57:25 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Charles Lynn CC: ipsec@tis.com Subject: Re: minor inconsistency in arch doc (maybe) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Charles Lynn wrote: > I think that the "problem" arises from the > ambiguity of the term "Transport Layer Protocol". In a sense, ESP is a > transport layer protocol (to the closest preceeding IP header), but AH > isn't. As the concepts become more complex, the simple terminology that > was previously clear may not keep up with our more refined concepts. Yes, this seems to capture it succinctly. More below. > > Is the confusion here due to IPv4 vs IPv6 differences, or what? > I do not think so. > > When I read the text you cited, from an implementor's perspective, what I > see is a warning. The field in a packet corredsponding to "Transport Layer > Protocol" is no longer a simple object to find. It may be in the IPv? > header, or it may be in one of possibly several extension headers (note > both that anything the implementation does not "understand" becomes a > transport protocol, and that some folks are using "extension headers" in > IPv4, and not just AH). So when the code to find the field is written, it > may have to be called several times to check successive places in a packet > (returning "OPAQUE" when it cannot find any more), or the function may > return a list of values, depending on how one implements things. > > At one point (if I remember correctly :-), there was another selector that > tried to distinguish between "Transport Layer Protocol" and extension > headers. It was removed, maybe because it made things "too complex". > The complexity does not go away, it just permutes into a different form. > > Does this correspond to your understanding of what is needed to support the > types of policies we need? Do you have any suggestions for clearer text? I think the confusion centers on the term 'Transport', and relates to the ambiguity of that term with respect to such protocols as ESP or AH, as you said. The text seems to imply that you should search forward in the packet to find the 'transport' protocol if the 'next protocol' value in the IP header is ESP/AH. This confuses me a bit. If it's okay to use *whatever* protocol is in this field as a selector, then perhaps we should consider omitting 'transport' in this context. I should add that if we are talking about 'IP security' as opposed to 'transport layer security', it may be argued that it would be inappropriate to select based upon something in the packet *other* than the IP header fields (and IP options, which are arguably an extension of the IP header). However, I admit that I haven't given this a lot of thought. Scott From owner-ipsec Wed Nov 4 17:50:42 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA11074 for ipsec-outgoing; Wed, 4 Nov 1998 17:49:11 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF4F7D00@exchange> From: Tim Jenkins To: "IPSEC Mailing List (E-mail)" Subject: Re: IBM VPN Bakeoff Issues Date: Wed, 4 Nov 1998 14:07:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE0826.68A48430" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE0826.68A48430 Content-Type: text/plain; charset="iso-8859-1" In response to some of the list of issues and questions raised at the IBM VPN interoperability workshop: > 9. Should the order of protocols dictate the order of security > association or should AH, ESP, IPComp always be processed in a > certain order? Most vendors agreed with the latter If we consider that a fixed order is assumed, and that we will never support ESP and ESP, there are only 4 kinds of bundles possible: IPCOMP+ESP, IPCOMP+AH, ESP+AH, and IPCOMP+ESP+AH. We should conceptually think of bundles as a single SA that provides multiple services. This means that all three services expire at the same time and are re-keyed at the same time. Further, when being negotiated, they all functionally use the same encapsulation (even though implementations may consider the outer headers as always being in transport mode). This means that a gateway always offers tunnel mode for all three services, since the bundle as a whole is in tunnel mode. Therefore, for the current version version of IPSec, make the following statements: 1) The order of application of services, from inner header to outer, MUST be IPCOMP, ESP and AH when more than one service is present. 2) The encapsulation mode of all services offered MUST match that encapsulation mode of the bundle as a whole. 3) The order of the services in the ANDed offer is not required to be any particular order. Responders may change the order when selecting the bundle. 4) The entire bundle expires when any one of the services within the bundle expires. For IPSecond: In order to reduce any ambiguity of implementation, I would suggest that we consider picturing these four combinations as their own protocols, with a single header that contains only the necessary information: 1 SPI, one sequence number, one next header field and one payload length field, each formatted based on the services it provides. A closer examination suggests that this 'super' header could be identical to the AH protocol header, since it already is a superset of the header information of all other headers. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Payload Len | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication Data (variable, 0 for IPCOMP+ESP) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The advantages of the use of this header are: 1) reduced ambiguity about application and negotiation of services. 2) reduced network bandwidth. 3) possible reduction in packet servicing time. All that remains is the specification of how authentication services are negotiated if ESP with authentication is allowed when used with AH. And it's pretty easy to argue that this could be disallowed. > 12. Does ESP-NULL require padding (the ESP doc says 4-byte alignment, > ESP-NULL doc says 1-byte alignment). The consensus was that ESP is > 4-byte aligned. There is no ambiguity. ESP in general requires 4 byte padding or a multiple of 4. ESP-NULL has a block length of 1. Since the padding used for a particular combination of ESP and an encryption algorithm is the lowest common multiple of 4 (from ESP) and the block length of the cipher, the result is that ESP with the NULL cipher uses a padding of 4 (or 8, or 12, ...) An example given at the workshop was for a cipher of block length 6. This would result in padding of 12 (or 24, or 36, ... ) bytes. > 16. If an initiator requests an SA with only a single IP address as > the destination, but the responder has a local policy of a subnet > (instead of a single IP address), should it fail the negotiation? > Some vendors were doing this. Yes, it should fail. Because then the initiator could then request another SA for the next IP address in the range the responder wanted to use in the first place. And then the next one. So you end up with a whole bunch of SAs that you don't need, and you may end up with a management issue that you didn't want. If your system is configured for a subnet, than that's probably what the administrator wants. > 25. Someone pointed out that the ID payload is redundant if we are > doing RSA_SIG authentication, since the certificate already has the > identity. I wouldn't necessarily agree with this. The certificate may contain alternate names, of which the one used in phase 1 negotiation should be one, yes? The name used in phase 1 negotiation is for policy, meaning what the person is allowed to do. The certificate is used for authentication, meaning: is the person really the person they say they are? --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 ------_=_NextPart_001_01BE0826.68A48430 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: IBM VPN Bakeoff Issues

In response to some of the list of issues and = questions raised at the IBM VPN interoperability workshop:

> 9. Should the order of protocols dictate the = order of security
> association or should AH, ESP, IPComp always be = processed in a
> certain order?  Most vendors agreed with = the latter

If we consider that a fixed order is assumed, and = that we will never support ESP and ESP, there are only 4 kinds of = bundles possible: IPCOMP+ESP, IPCOMP+AH, ESP+AH, and = IPCOMP+ESP+AH.

We should conceptually think of bundles as a single = SA that provides multiple services. This means that all three services = expire at the same time and are re-keyed at the same time. Further, = when being negotiated, they all functionally use the same encapsulation = (even though implementations may consider the outer headers as always = being in transport mode). This means that a gateway always offers = tunnel mode for all three services, since the bundle as a whole is in = tunnel mode.

Therefore, for the current version version of IPSec, = make the following statements:

1) The order of application of services, from inner = header to outer, MUST be IPCOMP, ESP and AH when more than one service = is present.

2) The encapsulation mode of all services offered = MUST match that encapsulation mode of the bundle as a whole.
3) The order of the services in the ANDed offer is = not required to be any particular order. Responders may change the = order when selecting the bundle.

4) The entire bundle expires when any one of the = services within the bundle expires.

For IPSecond:

In order to reduce any ambiguity of implementation, I = would suggest that we consider picturing these four combinations as = their own protocols, with a single header that contains only the = necessary information: 1 SPI, one sequence number, one next header = field and one payload length field, each formatted based on the = services it provides.

A closer examination suggests that this 'super' = header could be identical to the AH protocol header, since it already = is a superset of the header information of all other = headers.

    = 0            = ;       = 1            = ;       = 2            = ;       3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
   | Next Header   |  = Payload Len  = |          = RESERVED          &nbs= p;  |
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
   = |            = ;     Security Parameters Index (SPI)  &nb= sp;            = |
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
   = |            = ;        Sequence Number = Field           &= nbsp;          |
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
   = |            = ;            = ;            = ;            = ;            = ;   |
   +    Authentication Data = (variable, 0 for = IPCOMP+ESP)           = |
   = |            = ;            = ;            = ;            = ;            = ;   |
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

The advantages of the use of this header are:
 1) reduced ambiguity about application and = negotiation of services.
 2) reduced network bandwidth.
 3) possible reduction in packet servicing = time.

All that remains is the specification of how = authentication services are negotiated if ESP with authentication is = allowed when used with AH. And it's pretty easy to argue that this = could be disallowed.

> 12. Does ESP-NULL require padding (the ESP doc = says 4-byte alignment,
> ESP-NULL doc says 1-byte alignment).  The = consensus was that ESP is
> 4-byte aligned.

There is no ambiguity. ESP in general requires 4 byte = padding or a multiple of 4. ESP-NULL has a block length of 1. Since the = padding used for a particular combination of ESP and an encryption = algorithm is the lowest common multiple of 4 (from ESP) and the block = length of the cipher, the result is that ESP with the NULL cipher uses = a padding of 4 (or 8, or 12, ...)

An example given at the workshop was for a cipher of = block length 6. This would result in padding of 12 (or 24, or 36, ... ) = bytes.

> 16. If an initiator requests an SA with only a = single IP address as
> the destination, but the responder has a local = policy of a subnet
> (instead of a single IP address), should it = fail the negotiation?
>  Some vendors were doing this.

Yes, it should fail. Because then the initiator could = then request another SA for the next IP address in the range the = responder wanted to use in the first place. And then the next one. So = you end up with a whole bunch of SAs that you don't need, and you may = end up with a management issue that you didn't want. If your system is = configured for a subnet, than that's probably what the administrator = wants.

> 25. Someone pointed out that the ID payload is = redundant if we are
> doing RSA_SIG authentication, since the = certificate already has the
> identity.

I wouldn't necessarily agree with this. The = certificate may contain alternate names, of which the one used in phase = 1 negotiation should be one, yes? The name used in phase 1 negotiation = is for policy, meaning what the person is allowed to do. The = certificate is used for authentication, meaning: is the person really = the person they say they are?


---
Tim = Jenkins           = ;            = TimeStep Corporation
tjenkins@timestep.com       =    http://www.timestep.com
(613) 599-3610 = x4304           &= nbsp;   Fax: (613) 599-3617

------_=_NextPart_001_01BE0826.68A48430-- From owner-ipsec Wed Nov 4 17:50:45 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA11043 for ipsec-outgoing; Wed, 4 Nov 1998 17:48:59 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF4F7D14@exchange> From: Roy Pereira To: "IPSEC Mailing List (E-mail)" Cc: "Mason, David" Subject: RE: IBM VPN Bakeoff Issues Date: Wed, 4 Nov 1998 14:25:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE0828.E3C2E090" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE0828.E3C2E090 Content-Type: text/plain; charset="iso-8859-1" Just to make things clear; I only took notes of the issues. These issues aren't mine personally, but merely a collection of all of the attendees' issues with the current IPSec documents and vendor's IPSec implementations. The original email was intended to foster public discussion on the mailing list, so please send all replies back to the mailing list. ------_=_NextPart_001_01BE0828.E3C2E090 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: IBM VPN Bakeoff Issues

Just to make things clear; I only took notes of the = issues. 

These issues aren't mine personally, but merely a = collection of all of the attendees' issues with the current IPSec = documents and vendor's IPSec implementations.

The original email was intended to foster public = discussion on the mailing list, so please send all replies back to the = mailing list.

 

------_=_NextPart_001_01BE0828.E3C2E090-- From owner-ipsec Wed Nov 4 19:56:33 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id TAA14327 for ipsec-outgoing; Wed, 4 Nov 1998 19:55:16 -0500 (EST) Message-Id: <199811050113.RAA24259@chip.cisco.com> To: Tim Jenkins cc: "IPSEC Mailing List (E-mail)" Subject: Re: IBM VPN Bakeoff Issues In-reply-to: Your message of "Wed, 04 Nov 1998 14:07:46 EST." <319A1C5F94C8D11192DE00805FBBADDF4F7D00@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24256.910228422.1@cisco.com> Date: Wed, 04 Nov 1998 17:13:42 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk On Wed, 04 Nov 1998 14:07:46 EST you wrote > > > 16. If an initiator requests an SA with only a single IP address as > > the destination, but the responder has a local policy of a subnet > > (instead of a single IP address), should it fail the negotiation? > > Some vendors were doing this. > > Yes, it should fail. Because then the initiator could then request another > SA for the next IP address in the range the responder wanted to use in the > first place. And then the next one. So you end up with a whole bunch of SAs > that you don't need, and you may end up with a management issue that you > didn't want. If your system is configured for a subnet, than that's probably > what the administrator wants. Whoa! I can deal with that management issue so I accept that offer. Provided the offer is wholly contained in my policy I'll accept it. If my policy says "anybody to 132.239.4.0/255.255.255.0" and someone offers "199.54.6.33 to 132.239.4.18" that's what I'll add onto my SAs when I instantiate them. Then if 199.54.6.33 tries to send something to 132.239.4.50 on that SA I'll drop it (since it doesn't match the SA constraints we negotiated) even though it technically satisfies my policy. I'm being liberal in what I accept, provided it satisfies my configured policy that is. Yes, in certain situations I could end up with a whole slew of SAs when a single one would suffice. Oh well. That's the way it goes. I don't think we should dictate the behavior of an implementation in this fashion. Dan. From owner-ipsec Wed Nov 4 21:45:21 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id VAA17800 for ipsec-outgoing; Wed, 4 Nov 1998 21:44:16 -0500 (EST) Message-Id: <199811050308.WAA06765@relay.hq.tis.com> Date: Wed, 4 Nov 98 21:52:45 EST From: Charles Lynn To: Tim Jenkins cc: IPSEC Mailing List (E-mail) Subject: Re: IBM VPN Bakeoff Issues Sender: owner-ipsec@ex.tis.com Precedence: bulk Tim, > If we consider that a fixed order is assumed, and that we will never > support ESP and ESP, there are only 4 kinds of bundles possible: > IPCOMP+ESP, IPCOMP+AH, ESP+AH, and IPCOMP+ESP+AH. I do not agree with this; maybe its just mixed terminology again. I thought that a "bundle" was a set of SAs that were all applied to a packet in a single security gateway, originating (or terminating). If that definition is correct, it does not say anything about the other end of those SAs having to terminate (or originate) at a single security gateway. Thus one can certainly have an ESP + ESP "bundle", etc. (both originating at SG1 and one terminating at SG2 and the other at SG3). Your example is only for SAs that all begin at one SG (SG1) and all end at a second SG (SG2), correct? I.e., for AH/ESP/IPCOMP between a pair of IP headers, or between an IP header and the Upper Layer Protocol. > We should conceptually think of bundles as a single SA that provides > multiple services. Ok. > This means that all three services expire at the same time and are > re-keyed at the same time. In the reverse of the split case mentioned above, I suspect that it would be hard to get SG1 to agree on a single time when the separate SAs established by SG2 and SG3 are created. If SG3 initiates, SG2 may hold the ISAKMP until it negotiates an SA with SG1, then pass the SG3 ISAKMP through the SG2-SG1 SA to create the SG3-SG1 SA. > This means that a gateway always offers tunnel mode for all three > services, since the bundle as a whole is in tunnel mode. (Except when the gateway is an endpoint of a communication.) Thus I'm not sure that limiting the cases as you suggest will actually make the implementations very much simpler. > For IPSecond: > In order to reduce any ambiguity of implementation, I would suggest that > we consider picturing these four combinations as their own protocols, > with a single header that contains only the necessary information: ... > A closer examination suggests that this 'super' header could be > identical to the AH protocol header, But it uses a new, distinct extension header (protocol) number, right? BTW, how would the next/Upper Layer Protocol be processed? The strong ESP folk would not want it exposed in the header shown, even though the firewall/diff serv folks may welcome the ability to expose it. One could say if it is zero in the header, then it is the usual ESP location, and if not zero, its the next extension/Upper Layer Protocol number. MUST one verify the header value is identical to the ESP location one? Charlie From owner-ipsec Wed Nov 4 23:55:44 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id XAA23270 for ipsec-outgoing; Wed, 4 Nov 1998 23:54:16 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <3.0.1.32.19981103173528.0074e680@172.16.1.10> Date: Wed, 4 Nov 1998 22:46:06 -0500 To: rohit From: Stephen Kent Subject: Re: Selection of proposals Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm a bit confused by your example. You say that "During IKE negotiation, SG1 sends out the SAPayload(with the two transforms it has) to SG2 and H2." There are two separate IKE SAs here, SG1 to SG2 and SG1 to H2, so neither to these responders sees the other's negotation. It is up to SG2 to negotiate appropriate SAs for both of these endpoints. Also, we do not require support for the specific example you cited, because you have two nested tunnels with a common endpoint. This is not a required combination according to the arch doc, a simplification made at the request of other implementors last year. Steve From owner-ipsec Wed Nov 4 23:57:21 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id XAA23386 for ipsec-outgoing; Wed, 4 Nov 1998 23:57:15 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199810281430.GAA15867@kc.livingston.com> Date: Wed, 4 Nov 1998 18:46:26 -0500 To: suresh@livingston.com (Pyda Srisuresh) From: Stephen Kent Subject: Re: Comments on draft-ietf-ipsec-pki-req-01.txt Cc: rodney@unitran.com, ipsec@tis.com, suresh@livingston.com (Pyda Srisuresh) Sender: owner-ipsec@ex.tis.com Precedence: bulk Pyda , > >1. Certificate verification storage requirements > > In section 2.2, you say the IPsec device MUST support at least 8 > signing certificates. Is the requirement necessary? Either you > know to verify the signature or you dont. How does the number 8 > help? It's not that simple. This aspect of the proposal focuses on how many root CAs are supported. One might reduce this to one with appropriate use of locally generated cross certs, but for now this represents an easy way for folks to think about how to support multiple top level CAs. > Also, I believe, you neednt make the assumption that the IPSec > device (that supports IKE) MUST do the signature verification by > itself. It might take recourse of a CA to do the signature > verification. Then, it becomes the head-ache of the CA to verify > the entire certificate chain. I disagree. Adding another component to the system creates another failure point. IPsec is a realtime communication security technology that ought to minimize its dependence on additional servers, etc., so as to reduce the likelihood that a DoS attack on these servers can deny service for the users of IPsec. This is one of the motivations for IKE to support exchange of certs and CRLs. >2. EKU field requirement > > In section 3.1.1, you state that an EKU entry MUST be set to > IKEEnd or IKEIntermidate. Later on, in section 3.4.3, you say > this field should be validated, if present. Likewise, in section > 4.3 you make requirement for this field, a SHOULD. Clearly, these > seem like inconsistencies in the draft. > > Personally, I dont see a reason for requiring this. > Why should you have to create a cert just for IPsec? Are you > saying that a certificate created otherwise (for use originally > in non-IPsec applications) may not be valid for use by IPsec in > some circumstances? How so? Certs for use with IPsec ought to match the name spaces in which we perform access control, since the primary use of authentication here is as an input to access control. Thus certs with IP addresses, DNS names, and RFC 822 names are especially appropriate. This may well mean that certs are specific to an application like IPsec, though that is not necessarily true. Also, certs in IKE are used only for auth, not key exchange, non-repudiation, etc., which may mean that the key usage fields would be inconsistent with other apps. >3. SubjectAltName field requirement. > > In section 3.1.1, you say this is a MUST. Section 3.4.3 states this > as a MAY. Section 4.0 (first paragraph) states this field as a > required field for IPsec. Section 4.2 states that a Certificate > request SHOULD contain this field. Once again, inconsistencies in > the requirement terminology. > > Personally, I think, this is a SHOULD requirement, not a MUST. > Here's why. > > An IKE initiator should be able to obtain peer's IP address from the > certificate, in order to initiate a session. Clealry, SubjectAltName > field in the cert (with an IP address value) is a requirement here. Sometimes ID forms other than an Ip address are appropriate, depending on context. For example, an IP address may not be very useful as a means to identify a mobile user who has been assigned a temporary address. > On the other hand, IKE responder needs to verify its peers's ID > by retrieving a certificate of the peer and validating its authenticity. > This time, however, the requirement is simply for a certificate that > mateches the peer's ID. If the peer's ID happened to be an X.500 DN, > which is the SubjectNAme of Certificate, thats all that is needed. > Nothing else is required in SubjectAltName field. Both peers want to verify the others' ID. Not sure why you state this in an aysmmetric fashion. IPsec is not a client/server protocol, like SSL. > In other words, IKE initiator requires the peer's Cert to contain > SubjctAltName (peer's IP address, really), whereas the responder > does not require this always. > >5. SubjectAltName values > > In Section 4.1.2, you state that this field should contain exactly > one of IP address or DNS-Name or RFC-822 name. What is the problem > in assigning multiple of these values? You will need to assign > multiple values, many times. Example: a FQDN-name and an IP address, > possibly multiple IP addresses. It becomes confusing when we have multiple altnames in a cert, e.g., when dealing with name constraints. why would we need to assign multiple IP addresses in a single cert? a router has multiple addresses, but it can have one cert per interface; certs can be cheap in this context. if we can keep this simple for now, let's do it. > Also, you state that the DNS-name and RFC-822 names must be checked > for their validity. Who should do this? Is this the PKI service > provider who is issuing the Certificate? If so, are you suggesting > that a secure-DNS and/or Spam-detection techniques are requirements > for the CA? It is always the responsibility of a CA to verify ANY name form it puts in certificate. But, is that the context of this requirement? I don't have the doc in front of me right now. >6. Retrieval of a Certificate from PKI service provider > (Section 3.2) > > There is no recommendation of a protocol or an automated > means to retrieve certificates from CA. Also, Is there is a way to > request a CA to validate a certificate signature chain? CA's do not normally perform this service; it is not part of the definition of a CA. However, I would suggest that retrieval should specifiy the use of PKIX cert management protocols, if we can wait for these to be finalized. >7. Definition of "IPsec Usage Certificate" > > In section 4.3, your definition of "IPsec Usage certificate" mandates > a public key component in a certificate. Are you saying certificates > are not an appropriate infrastructure for PSK based IKE authentication? > In a PSK based authentication, IKE responder might try to authenticate > initiator's ID, by contacting a CA to obtain initiator's certificate. > However, only a pre-shared key (not a public key) is required in the > certificate. What? I was assuming that we were talking about X.509 certs here, since this is an IETF standards activity and for now, the only cert types being standardized by the IETF are X.509 (SPKI having passed on). X.509 certs contain public keys, if they contain keys at all (X.509 attribute certs are linked to public key certs and the former do not contain keys). Steve From owner-ipsec Thu Nov 5 01:18:16 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id BAA26261 for ipsec-outgoing; Thu, 5 Nov 1998 01:16:16 -0500 (EST) Message-Id: <199811050634.WAA24984@honeybee.cisco.com> X-Sender: shacham@honeybee.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 04 Nov 1998 22:32:48 -0800 To: Roy Pereira , "IPSEC Mailing List (E-mail)" From: Avram Shacham Subject: Re: IBM VPN Bakeoff Issues Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:58 AM 11/4/98 -0500, Roy Pereira wrote: >9. Should the order of protocols dictate the order of security association or should >AH, ESP, IPComp always be processed in a certain order? Most vendors agreed >with the latter. Risking repeating the obvious, the order is dictated by the reality that compression must precede encryption, as stated in the IPComp draft: Encrypting the IP datagram causes the data to be random in nature, rendering compression at lower protocol layers (e.g., PPP Compression Control Protocol [RFC-1962]) ineffective. If both compression and encryption are required, compression MUST be applied before encryption. avram From owner-ipsec Thu Nov 5 01:51:26 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id BAA26852 for ipsec-outgoing; Thu, 5 Nov 1998 01:51:15 -0500 (EST) Date: Thu, 5 Nov 1998 02:09:47 -0500 Message-Id: <199811050709.CAA26826@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: IPSEC Agenda request Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Gentlefolks, The Orlando IETF meeting is fast approaching, believe it or not. (Internet-Draft submissions must be in by November 18th, less than two weeks away at this point!) Therefore, Bob and I are soliciting agenda topics for the upcoming meeting. Please send any agenda requests (including description, time required, etc.) to Bob and I in the near future, so we can start planning the Agenda for the Orlando meeting. Thanks!! - Ted From owner-ipsec Thu Nov 5 03:52:47 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id DAA28845 for ipsec-outgoing; Thu, 5 Nov 1998 03:51:16 -0500 (EST) Date: Thu, 5 Nov 1998 11:08:51 +0200 (EET) From: Markku Savela Message-Id: <199811050908.LAA02908@anise.tte.vtt.fi> To: tjenkins@TimeStep.com CC: ipsec@tis.com In-reply-to: <319A1C5F94C8D11192DE00805FBBADDF4F7D00@exchange> (message from Tim Jenkins on Wed, 4 Nov 1998 14:07:46 -0500) Subject: Re: IBM VPN Bakeoff Issues Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Tim Jenkins > > In response to some of the list of issues and questions raised at the IBM > VPN interoperability workshop: > > > 9. Should the order of protocols dictate the order of security > > association or should AH, ESP, IPComp always be processed in a > > certain order? Most vendors agreed with the latter > > If we consider that a fixed order is assumed, and that we will never support > ESP and ESP, there are only 4 kinds of bundles possible: IPCOMP+ESP, > IPCOMP+AH, ESP+AH, and IPCOMP+ESP+AH. Looking at this from the pont of view of implemenor of a basic IPSEC + PFKEY in the kernel, I am perhaps a bit confused again: my understanding of the IPSEC architecture was for outgoing from policy selector -> SA bundle (list of SA's), apply them in whatever order the bundle lists. for incoming, apply SA's from the packet, remember the order, and after all done find the matching policy entry and check that the order applied matches the order in bundle. The order is an immutable policy decision between communicating partners, at least by reading the current IPSEC drafts. What is the problem? Can't IKE should just negotiate SAs? It looks once again that IKE/ISAMKP are trying to negotiate things that need to modify the policy. It may be that the current IPSEC is deficient in this respect for real use, and some negotiation of the policy aspects is also required. But I wold prefer to see a some separation of those parts that negotiate individual SA and those that negotiate policy affecting things (order of SAs). And, we might need a PF_KEY like interface to communicate the policy changes to the kernel? Perhaps, a solution is that the Key management daemon reads the same policy configuration as the kernel IPSEC is using? Then, the key management at least knows what order is configured in? -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec Thu Nov 5 05:14:15 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id FAA29923 for ipsec-outgoing; Thu, 5 Nov 1998 05:13:15 -0500 (EST) Message-Id: <3.0.1.32.19981105125211.00714fe4@172.16.1.10> X-Sender: rohit@172.16.1.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 05 Nov 1998 12:52:11 +0500 To: Stephen Kent From: rohit Subject: Re: Selection of proposals Cc: ipsec@tis.com In-Reply-To: References: <3.0.1.32.19981103173528.0074e680@172.16.1.10> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:46 PM 11/4/98 -0500, you wrote: >I'm a bit confused by your example. > >You say that "During IKE negotiation, SG1 sends out the SAPayload(with the two >transforms it has) to SG2 and H2." There are two separate IKE SAs here, SG1 >to SG2 and SG1 to H2, so neither to these responders sees the other's >negotation. rohit>> Yes! thats right, what i wanted to tell was SG1 (in quick mode) will form a seperate SAPayload (SAPayload1) to SG2 with two transforms. First one ESP with 3DES and second one ESP with DES. It also sends out another SAPayload (SAPayload2) to H2 with two transforms in it, first AH with SHA1 and secondly AH with MD5. SG2 will select the first transform in SAPayload1 as ESP with 3DES will match the first transform available with it. H2 will select the 2nd transform AH with MD5 in SAPayload2. Now SG1 finds that SG2 has selected the first proposal and H2 has selected the 2nd proposal, now what SG1 should do ? Because of this, an SA bundle that perfectly matches the proposal cannot be formed by SG1. However, SG2 is capable of processing with DES and had SG2 selected this, it could have formed an SA bundle at SG1. >It is up to SG2 to negotiate appropriate SAs for both of these >endpoints. >Also, we do not require support for the specific example you >cited, because you have two nested tunnels with a common endpoint. This is >not a required combination according to the arch doc, a simplification made >at the request of other implementors last year. rohit>> But the "draft-ietf-ipsec-arch-sec-06.txt" has the following paragraph on page 13, here also two tunnels are ending at a common endpoint i suppose.. 2. one endpoint of the SAs is the same -- The inner and outer tunnels could each be either AH or ESP. Host 1 --- Security ---- Internet -- Security --- Host 2 | | Gwy 1 Gwy 2 | | | | | | ----Security Association 1 (tunnel)---- | | | ---------Security Association 2 (tunnel)------------- ***************** I am giving here the scenerio from last mail for easy reference ..... >> If we have SG1, SG2 and IPSec capable host H2 in the following >>scenario, |--------ESPtunnel---- | | | SG1 ----------------- SG2 ----------- H2 | | |------------------AH Tunnel-----------| >>and the security policies are as follows. >>At SG1 OutBound Policy is >> Proposal #1: For SG2 : ESP with 3DES or ESP with DES For H2 : AH with SHA1 or AH with MD5 >>At SG2 we have the Inbound Policy as Proposal # 1 : ESP with 3DES or ESP with DES >>H2 has the inbound policy as Proposal # 1: AH with MD5 >>During IKE negotiation, SG1 sends out the SAPayload(with the two >>ansforms it has) to SG2 and H2. SG2 will select Transform #1 of SG1 and >> will select Transform # 2 of SG1. Because of this, an SA bundle that >>perfectly matches the proposal cannot be formed by SG1. However, SG2 is >>capable of processing with DES and had SG2 selected this, it could have >>formed an SA bundle at SG1. >>Do we just reject the proposal at this stage or is it permitted to send the >>two transforms as different proposal payloads in independent SA payloads >>and try to see if a match can be found amongst all available proposals? The >>problem here is, of course, the fact that H2 and SG2 look at the individual >>and independent SPDs while SG1 looks at the combined SA bundle. ************************************************************************* -: Bridging The Gap Between Software And Hardware :- Rohit Aradhya Ph : (040)7742606 Rendzevous Onchip Pvt Ltd. Em : rohit@trinc.com First Floor, Plot No 14 New Vasavi Nagar, Karkhana Secunderbad -500019. India ************************************************************************** From owner-ipsec Thu Nov 5 05:14:25 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id FAA29942 for ipsec-outgoing; Thu, 5 Nov 1998 05:14:17 -0500 (EST) X-Authentication-Warning: brahma.roc.com: ramana owned process doing -bs Date: Thu, 5 Nov 1998 12:54:32 +0530 (IST) From: Ramana Yarlagadda X-Sender: ramana@brahma.roc.com To: Stephen Kent cc: rohit , ipsec@tis.com Subject: Re: Selection of proposals In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > I'm a bit confused by your example. > > endpoints. Also, we do not require support for the specific example you > cited, because you have two nested tunnels with a common endpoint. This is > not a required combination according to the arch doc, a simplification made > at the request of other implementors last year. > In Sec4.3 Combining Security Associations(page 12) describes how we can bundle SAs. 1)Transport adjacency 2)Iterated tunneling And this example matches case2 (in Page 13). so now can I say that this is a valid cinfiguration with reference to draft. otherwise, what's wrong with that configuration. Can we know why the implementors requested it that way? -thanks -ramana From owner-ipsec Thu Nov 5 06:45:26 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id GAA00878 for ipsec-outgoing; Thu, 5 Nov 1998 06:44:16 -0500 (EST) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01EB5A85@wade.reo.dec.com> From: Stephen Waters To: Tim Jenkins Cc: ipsec@tis.com Subject: RE: IBM VPN Bakeoff Issues Date: Thu, 5 Nov 1998 12:01:26 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk > We should conceptually think of bundles as a single SA that provides multiple services. This means that all three services > expire at the same time and are re-keyed at the same time. Further, when being negotiated, they all functionally use the same > encapsulation (even though implementations may consider the outer headers as always being in transport mode). This means that > a gateway always offers tunnel mode for all three services, since the bundle as a whole is in tunnel mode. Yes, a point that was not raised at the workshop. We did a test with AH+ESP in tunnel mode. We took this to mean AH+ESP adjacent with a shared tunnel header. The other vendor took this to mean IP1+AH+IP2+ESP+IP3. There was some agreement that a proposal that offered AH-tunnel AND ESP-tunnel should mean a shared tunnel-header, but maybe we need more text somewhere. We have made our code more flexible so that it will cope with this case in future provided IP1 and IP2 are the same (and AH and ESP are both present), we will process this other variant the same way. > Therefore, for the current version version of IPSec, make the following statements: > 1) The order of application of services, from inner header to outer, MUST be IPCOMP, ESP and AH when more than one > service is present. > 2) The encapsulation mode of all services offered MUST match that encapsulation mode of the bundle as a whole. > 3) The order of the services in the ANDed offer is not required to be any particular order. Responders may change the >order when selecting the bundle. > 4) The entire bundle expires when any one of the services within the bundle expires. [[SW]] and IPCOMP MUST be accompanied by a security protocol. From owner-ipsec Thu Nov 5 07:45:48 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id HAA01509 for ipsec-outgoing; Thu, 5 Nov 1998 07:45:17 -0500 (EST) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01EB5A86@wade.reo.dec.com> From: Stephen Waters To: Charles Lynn Cc: ipsec@tis.com Subject: RE: IBM VPN Bakeoff Issues Date: Thu, 5 Nov 1998 13:02:20 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk >> If we consider that a fixed order is assumed, and that we will never >> support ESP and ESP, there are only 4 kinds of bundles possible: >> IPCOMP+ESP, IPCOMP+AH, ESP+AH, and IPCOMP+ESP+AH. >I do not agree with this; maybe its just mixed terminology again. >I thought that a "bundle" was a set of SAs that were all applied to >a packet in a single security gateway, originating (or terminating). >If that definition is correct, it does not say anything about the >other end of those SAs having to terminate (or originate) at a >single security gateway. Thus one can certainly have an ESP + ESP >"bundle", etc. (both originating at SG1 and one terminating at SG2 >and the other at SG3). I think we are talking about 'adjacencies' here, and adjacent headers are always stripped by the same source/dest pair. You can have ESP+ESP, but not as adjacent headers. If SG1 wants to send ESP to SG2 and SG3, it would need: [IP1-SG2][ESP1][IP2-SG3][ESP2][the rest]. How else could SG2 strip ESP1 and then forward the packet to SG3 to do the same? The architecture only talks about adjacencies for transport mode - although I don't see the need to restrict it to transport mode, this is a useful example: if the protocols are adjacent, they must be added/stripped by the same pair since the encapsulating IP header applies to them all. Steve. From owner-ipsec Thu Nov 5 08:12:31 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA01797 for ipsec-outgoing; Thu, 5 Nov 1998 08:12:15 -0500 (EST) Message-Id: <3.0.5.32.19981105083503.0094adb0@catskill.net> X-Sender: dfowler@catskill.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 05 Nov 1998 08:35:03 -0500 To: ipsec@tis.com From: Dennis Fowler Subject: IKE vs ISAKMP/Oakley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Pardon me for intruding. I am putting the finishing touches on a book about VPNs for Morgan Kaufmann Publishers. Can someone explain to me the difference between IKE and ISAKMP/Oakley? I was under the impression they performed essentially the same tasks. Thanks in advance. Dennis Fowler P. O. Box 70 Mill Creek Rd. Fire #315 Otego, NY 13825 (607) 432-2012 dfowler@catskill.net From owner-ipsec Thu Nov 5 08:25:32 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA01997 for ipsec-outgoing; Thu, 5 Nov 1998 08:25:18 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF4F7E77@exchange> From: Tim Jenkins To: Charles Lynn Cc: IPSEC Mailing List Subject: RE: IBM VPN Bakeoff Issues Date: Thu, 5 Nov 1998 08:43:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE08C2.4EB40BE0" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE08C2.4EB40BE0 Content-Type: text/plain; charset="iso-8859-1" --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Charles Lynn [mailto:clynn@BBN.COM] > Sent: Wednesday, November 04, 1998 9:53 PM > To: Tim Jenkins > Cc: IPSEC Mailing List > Subject: Re: IBM VPN Bakeoff Issues > > > Tim, > > > If we consider that a fixed order is assumed, and that we will never > > support ESP and ESP, there are only 4 kinds of bundles possible: > > IPCOMP+ESP, IPCOMP+AH, ESP+AH, and IPCOMP+ESP+AH. > > I do not agree with this; maybe its just mixed terminology again. > I thought that a "bundle" was a set of SAs that were all applied to > a packet in a single security gateway, originating (or terminating). > If that definition is correct, it does not say anything about the > other end of those SAs having to terminate (or originate) at a > single security gateway. Thus one can certainly have an ESP + ESP > "bundle", etc. (both originating at SG1 and one terminating at SG2 > and the other at SG3). > > Your example is only for SAs that all begin at one SG (SG1) and all > end at a second SG (SG2), correct? I.e., for AH/ESP/IPCOMP between a > pair of IP headers, or between an IP header and the Upper > Layer Protocol. Yes, that's right. More specifically, it relates to the interpretation of proposals offered in the same SA payload that have the same proposal number. > > > We should conceptually think of bundles as a single SA that provides > > multiple services. > > Ok. > > > This means that all three services expire at the same time and are > > re-keyed at the same time. > > In the reverse of the split case mentioned above, I suspect that it > would be hard to get SG1 to agree on a single time when the separate > SAs established by SG2 and SG3 are created. If SG3 initiates, SG2 > may hold the ISAKMP until it negotiates an SA with SG1, then pass > the SG3 ISAKMP through the SG2-SG1 SA to create the SG3-SG1 SA. This is a different. Here, IMHO, the SAs between SG2 and SG3 by SG1 are independent. If we use the case where a host behind SG1 is attempting to communicate securely with a host behind SG3, SG1's policy probably says that an SA is needed with SG3 to get to the second host. Then, its policy says that it needs an SA with SG2 to talk to SG3. The are negotiated independently: in completely separate SAs. > > > This means that a gateway always offers tunnel mode for all three > > services, since the bundle as a whole is in tunnel mode. > > (Except when the gateway is an endpoint of a communication.) > Thus I'm not sure that limiting the cases as you suggest will actually > make the implementations very much simpler. > > > For IPSecond: > > In order to reduce any ambiguity of implementation, I would > suggest that > > we consider picturing these four combinations as their own > protocols, > > with a single header that contains only the necessary information: > ... > > A closer examination suggests that this 'super' header could be > > identical to the AH protocol header, > > But it uses a new, distinct extension header (protocol) number, right? If this was done, there would have to be 4 new protocol numbers. > BTW, how would the next/Upper Layer Protocol be processed? The strong > ESP folk would not want it exposed in the header shown, even > though the > firewall/diff serv folks may welcome the ability to expose it. One > could say if it is zero in the header, then it is the usual > ESP location, > and if not zero, its the next extension/Upper Layer Protocol number. > MUST one verify the header value is identical to the ESP location one? These are all good points. But it's possible that this proposal has been raised before. Partly, I wanted to get people thinking conceptually this way, in order to help solidify the rules for SA bundles negotiated as part of the same SA proposal. > > Charlie > ------_=_NextPart_001_01BE08C2.4EB40BE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: IBM VPN Bakeoff Issues

---
Tim = Jenkins           = ;            = TimeStep Corporation
tjenkins@timestep.com       =    http://www.timestep.com
(613) 599-3610 = x4304           &= nbsp;   Fax: (613) 599-3617


> -----Original Message-----
> From: Charles Lynn [mailto:clynn@BBN.COM]
> Sent: Wednesday, November 04, 1998 9:53 = PM
> To: Tim Jenkins
> Cc: IPSEC Mailing List
> Subject: Re: IBM VPN Bakeoff Issues
>
>
> Tim,
>
> > If we consider that a fixed order is = assumed, and that we will never
> > support ESP and ESP, there are only 4 = kinds of bundles possible:
> > IPCOMP+ESP, IPCOMP+AH, ESP+AH, and = IPCOMP+ESP+AH.
>
> I do not agree with this; maybe its just mixed = terminology again.
> I thought that a "bundle" was a set = of SAs that were all applied to
> a packet in a single security gateway, = originating (or terminating).
> If that definition is correct, it does not say = anything about the
> other end of those SAs having to terminate (or = originate) at a
> single security gateway.  Thus one can = certainly have an ESP + ESP
> "bundle", etc. (both originating at = SG1 and one terminating at SG2
> and the other at SG3).
>
> Your example is only for SAs that all begin at = one SG (SG1) and all
> end at a second SG (SG2), correct?  I.e., = for AH/ESP/IPCOMP between a
> pair of IP headers, or between an IP header and = the Upper
> Layer Protocol.

Yes, that's right. More specifically, it relates to = the interpretation of proposals offered in the same SA payload that = have the same proposal number.

>
> > We should conceptually think of bundles as = a single SA that provides
> > multiple services.
>
> Ok.
>
> > This means that all three services expire = at the same time and are
> > re-keyed at the same time.
>
> In the reverse of the split case mentioned = above, I suspect that it
> would be hard to get SG1 to agree on a single = time when the separate
> SAs established by SG2 and SG3 are = created.  If SG3 initiates, SG2
> may hold the ISAKMP until it negotiates an SA = with SG1, then pass
> the SG3 ISAKMP through the SG2-SG1 SA to create = the SG3-SG1 SA.

This is a different. Here, IMHO, the SAs between SG2 = and SG3 by SG1 are independent. If we use the case where a host behind = SG1 is attempting to communicate securely with a host behind SG3, SG1's = policy probably says that an SA is needed with SG3 to get to the second = host. Then, its policy says that it needs an SA with SG2 to talk to = SG3. The are negotiated independently: in completely separate = SAs.

>
> > This means that a gateway always offers = tunnel mode for all three
> > services, since the bundle as a whole is = in tunnel mode.
>
> (Except when the gateway is an endpoint of a = communication.)
> Thus I'm not sure that limiting the cases as = you suggest will actually
> make the implementations very much = simpler.
>
> > For IPSecond:
> > In order to reduce any ambiguity of = implementation, I would
> suggest that
> > we consider picturing these four = combinations as their own
> protocols,
> > with a single header that contains only = the necessary information:
> ...
> > A closer examination suggests that this = 'super' header could be
> > identical to the AH protocol = header,
>
> But it uses a new, distinct extension header = (protocol) number, right?

If this was done, there would have to be 4 new = protocol numbers.

> BTW, how would the next/Upper Layer Protocol be = processed?  The strong
> ESP folk would not want it exposed in the = header shown, even
> though the
> firewall/diff serv folks may welcome the = ability to expose it.  One
> could say if it is zero in the header, then it = is the usual
> ESP location,
> and if not zero, its the next extension/Upper = Layer Protocol number.
> MUST one verify the header value is identical = to the ESP location one?

These are all good points. But it's possible that = this proposal has been raised before. Partly, I wanted to get people = thinking conceptually this way, in order to help solidify the rules for = SA bundles negotiated as part of the same SA proposal.

>
> Charlie
>

------_=_NextPart_001_01BE08C2.4EB40BE0-- From owner-ipsec Thu Nov 5 08:29:27 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA02091 for ipsec-outgoing; Thu, 5 Nov 1998 08:29:18 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF4F7E80@exchange> From: Tim Jenkins To: msa@hemuli.tte.vtt.fi Cc: ipsec@tis.com Subject: RE: IBM VPN Bakeoff Issues Date: Thu, 5 Nov 1998 08:48:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE08C3.07D3CD00" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE08C3.07D3CD00 Content-Type: text/plain; charset="iso-8859-1" --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Markku Savela [mailto:msa@anise.tte.vtt.fi] > Sent: Thursday, November 05, 1998 4:09 AM > To: tjenkins@TimeStep.com > Cc: ipsec@tis.com > Subject: Re: IBM VPN Bakeoff Issues > > > > From: Tim Jenkins > > > > In response to some of the list of issues and questions > raised at the IBM > > VPN interoperability workshop: > > > > > 9. Should the order of protocols dictate the order of security > > > association or should AH, ESP, IPComp always be processed in a > > > certain order? Most vendors agreed with the latter > > > > If we consider that a fixed order is assumed, and that we > will never support > > ESP and ESP, there are only 4 kinds of bundles possible: IPCOMP+ESP, > > IPCOMP+AH, ESP+AH, and IPCOMP+ESP+AH. > > Looking at this from the pont of view of implemenor of a basic IPSEC + > PFKEY in the kernel, I am perhaps a bit confused again: my > understanding of the IPSEC architecture was > > for outgoing > from policy selector -> SA bundle (list of SA's), apply them > in whatever order the bundle lists. I wish it was that simple. However, we have documents that state that IPCOMP must come first. Further, what is the order? From the interoperability workshop, we know that SSH and TimeStep used ordered proposals, but had them in opposite directions. We also had implementations that jumbled the order when they accepted. They're logic is that it doesn't matter, since order is dictated anyway. > > for incoming, > apply SA's from the packet, remember the order, and after all > done find the matching policy entry and check that the order > applied matches the order in bundle. > > The order is an immutable policy decision between communicating > partners, at least by reading the current IPSEC drafts. What is the > problem? Can't IKE should just negotiate SAs? > > It looks once again that IKE/ISAMKP are trying to negotiate things > that need to modify the policy. It may be that the current IPSEC is > deficient in this respect for real use, and some negotiation of the > policy aspects is also required. But I wold prefer to see a some > separation of those parts that negotiate individual SA and those that > negotiate policy affecting things (order of SAs). And, we might need a > PF_KEY like interface to communicate the policy changes to the kernel? > > Perhaps, a solution is that the Key management daemon reads the same > policy configuration as the kernel IPSEC is using? Then, the key > management at least knows what order is configured in? I don't understand where you're coming from here. Where is the policy modification occurring? All we're trying to do is nail down the usage of proposals with the same proposal number that appear in an SA payload. > > -- > Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research > Centre of Finland > Multimedia Systems, P.O.Box 1203,FIN-02044 > VTT,http://www.vtt.fi/tte/staff/msa/ > ------_=_NextPart_001_01BE08C3.07D3CD00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: IBM VPN Bakeoff Issues

---
Tim = Jenkins           = ;            = TimeStep Corporation
tjenkins@timestep.com       =    http://www.timestep.com
(613) 599-3610 = x4304           &= nbsp;   Fax: (613) 599-3617


> -----Original Message-----
> From: Markku Savela [mailto:msa@anise.tte.vtt.fi]
> Sent: Thursday, November 05, 1998 4:09 = AM
> To: tjenkins@TimeStep.com
> Cc: ipsec@tis.com
> Subject: Re: IBM VPN Bakeoff Issues
>
>
> > From: Tim Jenkins = <tjenkins@TimeStep.com>
> >
> > In response to some of the list of issues = and questions
> raised at the IBM
> > VPN interoperability workshop:
> >
> > > 9. Should the order of protocols = dictate the order of security
> > > association or should AH, ESP, IPComp = always be processed in a
> > > certain order?  Most vendors = agreed with the latter
> >
> > If we consider that a fixed order is = assumed, and that we
> will never support
> > ESP and ESP, there are only 4 kinds of = bundles possible: IPCOMP+ESP,
> > IPCOMP+AH, ESP+AH, and = IPCOMP+ESP+AH.
>
> Looking at this from the pont of view of = implemenor of a basic IPSEC +
> PFKEY in the kernel, I am perhaps a bit = confused again: my
> understanding of the IPSEC architecture = was
>
>  for outgoing
>       from policy = selector -> SA bundle (list of SA's), apply them
>       in whatever = order the bundle lists.

I wish it was that simple. However, we have documents = that state that IPCOMP must come first. Further, what is the order? = >From the interoperability workshop, we know that SSH and TimeStep used = ordered proposals, but had them in opposite directions.

We also had implementations that jumbled the order = when they accepted. They're logic is that it doesn't matter, since = order is dictated anyway.

>
>  for incoming,
>       apply SA's from = the packet, remember the order, and after all
>       done find the = matching policy entry and check that the order
>       applied matches = the order in bundle.
>
> The order is an immutable policy decision = between communicating
> partners, at least by reading the current IPSEC = drafts. What is the
> problem? Can't IKE should just negotiate = SAs?
>
> It looks once again that IKE/ISAMKP are trying = to negotiate things
> that need to modify the policy. It may be that = the current IPSEC is
> deficient in this respect for real use, and = some negotiation of the
> policy aspects is also required. But I wold = prefer to see a some
> separation of those parts that negotiate = individual SA and those that
> negotiate policy affecting things (order of = SAs). And, we might need a
> PF_KEY like interface to communicate the policy = changes to the kernel?
>
> Perhaps, a solution is that the Key management = daemon reads the same
> policy configuration as the kernel IPSEC is = using? Then, the key
> management at least knows what order is = configured in?

I don't understand where you're coming from here. = Where is the policy modification occurring? All we're trying to do is = nail down the usage of proposals with the same proposal number that = appear in an SA payload.

>
> --
> Markku Savela (msa@hemuli.tte.vtt.fi), = Technical Research
> Centre of Finland
> Multimedia Systems, P.O.Box 1203,FIN-02044 =
> VTT,http://www.vtt.fi/tte/staff/msa/
>

------_=_NextPart_001_01BE08C3.07D3CD00-- From owner-ipsec Thu Nov 5 08:46:05 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA02312 for ipsec-outgoing; Thu, 5 Nov 1998 08:45:18 -0500 (EST) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01EB5A87@wade.reo.dec.com> From: Stephen Waters To: Tim Jenkins Cc: ipsec@tis.com Subject: RE: IBM VPN Bakeoff Issues Date: Thu, 5 Nov 1998 14:02:07 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk > 12. Does ESP-NULL require padding (the ESP doc says 4-byte alignment, > ESP-NULL doc says 1-byte alignment). The consensus was that ESP is > 4-byte aligned. There is no ambiguity. ESP in general requires 4 byte padding or a multiple of 4. ESP-NULL has a block length of 1. Since the padding used for a particular combination of ESP and an encryption algorithm is the lowest common multiple of 4 (from ESP) and the block length of the cipher, the result is that ESP with the NULL cipher uses a padding of 4 (or 8, or 12, ...) [[SW]] There may not be any ambiguity, but there is contradiction and confusion :) We're not talking about 'ESP in general' though, right, this is NULL-ESP, and I don't understand why NULL-ESP should have any padding, let alone 4 bytes. NULL-ESP actually means ESP-Authentication, and the mandatory authentication algorithms don't need padding. One problem is where folk want to pad for other reasons - then your left with the dilemma of not knowing if it was applied or not. With PPP ECP, if there is no need to pad, but the last octet of data could be taken for a pad length, then explicit padding is added. Since the pad length can be 0-255, I guess that means a pad length is mandatory, but why can't I just add a single byte with value 0 if I'm not interested in padding? > 16. If an initiator requests an SA with only a single IP address as > the destination, but the responder has a local policy of a subnet > (instead of a single IP address), should it fail the negotiation? > Some vendors were doing this. Yes, it should fail. Because then the initiator could then request another SA for the next IP address in the range the responder wanted to use in the first place. And then the next one. So you end up with a whole bunch of SAs that you don't need, and you may end up with a management issue that you didn't want. If your system is configured for a subnet, than that's probably what the administrator wants. [[SW]] The architecture does discuss how policies can cause the creation of SA where the selector values are taken from the packet (or the ISAKMP ID payloads I guess), so this sounds like a management issue where the response will be determined by the options set on the policy. From owner-ipsec Thu Nov 5 08:54:36 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA02413 for ipsec-outgoing; Thu, 5 Nov 1998 08:54:18 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF4F7EAC@exchange> From: Tim Jenkins To: Stephen Waters Cc: ipsec@tis.com Subject: RE: IBM VPN Bakeoff Issues Date: Thu, 5 Nov 1998 09:13:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE08C6.74FDA680" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE08C6.74FDA680 Content-Type: text/plain; charset="iso-8859-1" --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Stephen Waters [mailto:Stephen.Waters@digital.com] > Sent: Thursday, November 05, 1998 9:02 AM > To: Tim Jenkins > Cc: ipsec@tis.com > Subject: RE: IBM VPN Bakeoff Issues > > > > > > 12. Does ESP-NULL require padding (the ESP doc says 4-byte > alignment, > > ESP-NULL doc says 1-byte alignment). The consensus was that ESP is > > 4-byte aligned. > > There is no ambiguity. ESP in general requires 4 byte padding > or a multiple > of 4. ESP-NULL has a block length of 1. Since the padding used for a > particular combination of ESP and an encryption algorithm is > the lowest > common multiple of 4 (from ESP) and the block length of the > cipher, the > result is that ESP with the NULL cipher uses a padding of 4 > (or 8, or 12, > ...) > [[SW]] There may not be any ambiguity, but there is contradiction and > confusion :) We're not talking about 'ESP in general' though, > right, this is > NULL-ESP, and I don't understand why NULL-ESP should have any > padding, let > alone 4 bytes. NULL-ESP actually means ESP-Authentication, > and the mandatory > authentication algorithms don't need padding. One problem is > where folk > want to pad for other reasons - then your left with the dilemma of not > knowing if it was applied or not. With PPP ECP, if there is > no need to pad, > but the last octet of data could be taken for a pad length, > then explicit > padding is added. Since the pad length can be 0-255, I guess > that means a > pad length is mandatory, but why can't I just add a single > byte with value 0 > if I'm not interested in padding? The ESP document specifically says you must effectively have 4-byte padding requirements (including the Pad Length and Next Header fields). Start Quote: o Padding also may be required, irrespective of encryption algorithm requirements, to ensure that the resulting ciphertext terminates on a 4-byte boundary. Specifically, the Pad Length and Next Header fields must be right aligned within a 4-byte word, as illustrated in the ESP packet format figure above, to ensure that the Authentication Data field (if present) is aligned on a 4-byte boundary. End Quote > > > 16. If an initiator requests an SA with only a single IP address as > > the destination, but the responder has a local policy of a subnet > > (instead of a single IP address), should it fail the negotiation? > > Some vendors were doing this. > > Yes, it should fail. Because then the initiator could then > request another > SA for the next IP address in the range the responder wanted > to use in the > first place. And then the next one. So you end up with a > whole bunch of SAs > that you don't need, and you may end up with a management > issue that you > didn't want. If your system is configured for a subnet, than > that's probably > what the administrator wants. > [[SW]] The architecture does discuss how policies can cause > the creation of > SA where the selector values are taken from the packet (or > the ISAKMP ID > payloads I guess), so this sounds like a management issue > where the response > will be determined by the options set on the policy. > > > I'll reverse my position on this one. Both you and Dan H. have pointed out that this should be a local implementation decision, not a standards decision. ------_=_NextPart_001_01BE08C6.74FDA680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: IBM VPN Bakeoff Issues

---
Tim = Jenkins           = ;            = TimeStep Corporation
tjenkins@timestep.com       =    http://www.timestep.com
(613) 599-3610 = x4304           &= nbsp;   Fax: (613) 599-3617


> -----Original Message-----
> From: Stephen Waters [mailto:Stephen.Waters@digital= .com]
> Sent: Thursday, November 05, 1998 9:02 = AM
> To: Tim Jenkins
> Cc: ipsec@tis.com
> Subject: RE: IBM VPN Bakeoff Issues
>
>
> 
>
> > 12. Does ESP-NULL require padding (the ESP = doc says 4-byte
> alignment,
> > ESP-NULL doc says 1-byte alignment).  = The consensus was that ESP is
> > 4-byte aligned.
>
> There is no ambiguity. ESP in general requires = 4 byte padding
> or a multiple
> of 4. ESP-NULL has a block length of 1. Since = the padding used for a
> particular combination of ESP and an encryption = algorithm is
> the lowest
> common multiple of 4 (from ESP) and the block = length of the
> cipher, the
> result is that ESP with the NULL cipher uses a = padding of 4
> (or 8, or 12,
> ...)
> [[SW]] There may not be any ambiguity, but = there is contradiction and
> confusion :) We're not talking about 'ESP in = general' though,
> right, this is
> NULL-ESP, and I don't understand why NULL-ESP = should have any
> padding, let
> alone 4 bytes. NULL-ESP actually means = ESP-Authentication,
> and the mandatory
> authentication algorithms don't need = padding.  One problem is
> where folk
> want to pad for other reasons - then your left = with the dilemma of not
> knowing if it was applied or not. With PPP ECP, = if there is
> no need to pad,
> but the last octet of data could be taken for a = pad length,
> then explicit
> padding is added. Since the pad length can be = 0-255, I guess
> that means a
> pad length is mandatory, but why can't I just = add a single
> byte with value 0
> if I'm not interested in padding?

The ESP document specifically says you must = effectively have 4-byte padding requirements (including the Pad Length = and Next Header fields).

Start Quote:

           o = Padding also may be required, irrespective of encryption
          &nb= sp;  algorithm requirements, to ensure that the resulting
          &nb= sp;  ciphertext terminates on a 4-byte boundary. Specifically, = the
          &nb= sp;  Pad Length and Next Header fields must be right aligned = within
          &nb= sp;  a 4-byte word, as illustrated in the ESP packet format = figure
          &nb= sp;  above, to ensure that the Authentication Data field = (if
          &nb= sp;  present) is aligned on a 4-byte boundary.

End Quote


>
> > 16. If an initiator requests an SA with = only a single IP address as
> > the destination, but the responder has a = local policy of a subnet
> > (instead of a single IP address), should = it fail the negotiation?
> >  Some vendors were doing this. =
>
> Yes, it should fail. Because then the initiator = could then
> request another
> SA for the next IP address in the range the = responder wanted
> to use in the
> first place. And then the next one. So you end = up with a
> whole bunch of SAs
> that you don't need, and you may end up with a = management
> issue that you
> didn't want. If your system is configured for a = subnet, than
> that's probably
> what the administrator wants.
> [[SW]] The architecture does discuss how = policies can cause
> the creation of
> SA where the selector values are taken from the = packet (or
> the ISAKMP ID
> payloads I guess), so this sounds like a = management issue
> where the response
> will be determined by the options set on the = policy.
>
> 
>

I'll reverse my position on this one. Both you and = Dan H. have pointed out that this should be a local implementation = decision, not a standards decision.

------_=_NextPart_001_01BE08C6.74FDA680-- From owner-ipsec Thu Nov 5 08:56:25 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA02475 for ipsec-outgoing; Thu, 5 Nov 1998 08:56:17 -0500 (EST) Date: Thu, 5 Nov 1998 08:56:17 -0500 (EST) From: owner-ipsec@ex.tis.com Message-Id: <199811051356.IAA02475@portal.ex.tis.com> [192.94.214.100]) by portal.ex.tis.com (8.9.1/8.9.1) with ESMTP id RAA10907 for ; Wed, 4 Nov 1998 17:46:26 -0500 (EST) (4.1) id xma003607; Wed, 4 Nov 98 12:56:27 -0500 From: Charles Kunzinger To: Subject: Issues raised at VPN Interoperability Workshop Message-ID: <5040300022235103000002L032*@MHS> Date: Wed, 4 Nov 1998 16:50:41 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk This note supplements Roy Periera's earlier posting, listing those issues which I collected on my summary foils during last week's interoperability workshop: 1. Is it mandatory to check the contents of the ID payload against the subjAltName in the associated certificate? Is their a mandatory action on mismatch? The Domain of Interpretation, section 4.6.2.1, states that "When an IKE exchange is authenticated using certificates..., any IDs used for input to local policy decisions SHOULD be contained in the certificate used in the authentication of the exchange." I didn't see any text saying what to do if there's a mismatch. 2. Is there a recommended way to deleta an SA and establish a new one without losing traffic? Suggestion from the floor was to use "draft-jenkins-ipsec-rekeying-00.txt" as a starting point and then discuss on the list. 3. Is the action for NOTIFICATION-inital contact defined? See section 4.6.3.3 of "Domain of Interpretation" for details. 4. What action shold be taken if "Vendor ID Payload" is received by a system that does not use it? Consensus was you can ignore it if you wish, but you can not allow your system to crash when it's received. 5. Are there limits on sizes of nonces used in IKE? Nonces must be between 8 and 256 bytes in length as noted in "IKE" spec, section 5. 6. Can Vendor ID Payload be carried in Phase 2 IKE exchanges? If used, it MUST be present in Phase 1 flows; it's also not an error to include it elsewhere in addition. 7. What are details for handling "opitons"? This is too general a question. Any specific issues should be raised for discussion on the mailing list. 8. Is the use of IKE by IPPCP defined? See the relevant IPPCP drafts. 9. Many venodrs use different GUIs for configuration. Will there be any attempt by the working group to develop a common approach? No, GUIs are an implementation option that vendors will use to differentiate their products. However, the working group will develop a common LDAP Schema for configuring and administering VPNs. See "draft-ietf-ipsec-policy-schema-00.txt", and discuss as needed on the mailing list. 10. Miscellaneous Lifetime/lifesize issues: New text to cover handling during Phase 1 is being developed. Once avaailable, we can discuss on the mailing list. Also, "Domain of Interpretation" document, section 5.4, discusses lifetime/lifesize, but text does not mention default values. If a system receives a lifesize and lifetime attribute but supports only one of them, the text in +Domain of Interpetation", section 5.4, indicates that " ...if an implementation receives a defined IPSec DOI attribute...which it does not support, an ATTRIBUTES-NOT-SUPPORT SHOULD be sent and the security association setup MUST be aborted, unless the attribute is in the reserved range. 11. If L2TP and IPSec are used in conjuc=nction, and there is no ID payload in the IKE Phase 2 exchanges, should the default be to a)apply IPSec protection to all IP packets, b) apply IPSec protection only to packets going through the L2TP tunnel, or c) reject the SA proposal? Consensus appeared to be that only the "tunneled" traffic should get IPSec protection. 12. If "Next Payload" points to a private payload, should this payload be ignored in the absence of a Vendor ID Payload? Consensus was to discuss this on the mailing list. 13. For Phase 1 ID payloads, is it OK to not check that protocol/port have been set to 0/0 or UDP/500? This issue has been raised on the mailing list, but has not gotten any response as yet. Discuss as needed on the list. ` ____________________________ Charles A Kunzinger (kunzinge@us.ibm.com) TCP/IP Technology Management, JDGA/501, RTP Phone: Tie 8-444-4142 , External 1-919-254-4142 Fax: Tie 8-444-6243, External 1-919-254-6243 VM: IBMUSM27(KUNZINGE) From owner-ipsec Thu Nov 5 09:25:47 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA03059 for ipsec-outgoing; Thu, 5 Nov 1998 09:25:19 -0500 (EST) Date: Thu, 5 Nov 1998 16:43:16 +0200 (EET) From: Markku Savela Message-Id: <199811051443.QAA03195@anise.tte.vtt.fi> To: tjenkins@TimeStep.com CC: ipsec@tis.com In-reply-to: <319A1C5F94C8D11192DE00805FBBADDF4F7E80@exchange> (message from Tim Jenkins on Thu, 5 Nov 1998 08:48:51 -0500) Subject: RE: IBM VPN Bakeoff Issues Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@ex.tis.com Precedence: bulk > We also had implementations that jumbled the order when they accepted. > They're logic is that it doesn't matter, since order is dictated anyway. To me this logic appears right, as per IPSEC architecture. I guess the point culminates on something I don't know (I am not familiar with IKE/ISAMKP details), the question: Why does IKE/ISKAMP need to know the ordering of negotiated SAs? > I don't understand where you're coming from here. Where is the policy > modification occurring? All we're trying to do is nail down the usage of > proposals with the same proposal number that appear in an SA payload. I'm not quite sure... my thoughts went somehow.. why do you need to care about the ordering if it is already fixed by policy? And it seemed indicate that the ordering was something that ISAKMP/IKE could decide on (which is false). -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ ps. Do you really want to include this HTML version of the text in each of your messages, perhaps tick the "send text only" on? From owner-ipsec Thu Nov 5 09:37:44 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA03181 for ipsec-outgoing; Thu, 5 Nov 1998 09:37:18 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF4F7EFE@exchange> From: Tim Jenkins To: msa@hemuli.tte.vtt.fi Cc: ipsec@tis.com Subject: RE: IBM VPN Bakeoff Issues Date: Thu, 5 Nov 1998 09:57:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE08CC.96331F90" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE08CC.96331F90 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Markku Savela [mailto:msa@anise.tte.vtt.fi] > Sent: Thursday, November 05, 1998 9:43 AM > To: tjenkins@TimeStep.com > Cc: ipsec@tis.com > Subject: RE: IBM VPN Bakeoff Issues > > > > > We also had implementations that jumbled the order when > they accepted. > > They're logic is that it doesn't matter, since order is > dictated anyway. > > To me this logic appears right, as per IPSEC architecture. > > I guess the point culminates on something I don't know (I am not > familiar with IKE/ISAMKP details), the question: > > Why does IKE/ISKAMP need to know the ordering of negotiated SAs? > Maybe IKE itself doesn't. But somewhere in the implementation, the proper order of transforms must be created as a result of the negotiation. As we discovered at the interoperability test, it's not well enough defined. > > I don't understand where you're coming from here. Where is > the policy > > modification occurring? All we're trying to do is nail down > the usage of > > proposals with the same proposal number that appear in an > SA payload. > > I'm not quite sure... my thoughts went somehow.. why do you need to > care about the ordering if it is already fixed by policy? And it > seemed indicate that the ordering was something that ISAKMP/IKE could > decide on (which is false). I think I see where you're coming from here. However, the order isn't fixed by policy; it's fixed by the documents. We MUST put IPCOMP before ESP. I think it also says that we MUST put ESP before AH (this makes sense, anyway). So if we also disallow ESP+ESP in the same SA payload, it makes the order very determinable, regardless of the order the proposals appear in inside the SA payload. So even though IKE can negotiate AH over ESP over IPCOMP, that's not what should be implemented. So we need to determine what should be implemented when IKE does negotiate AH over ESP over IPCOMP, so that interoperability is more reasonably assured. > > -- > Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research > Centre of Finland > Multimedia Systems, P.O.Box 1203,FIN-02044 > VTT,http://www.vtt.fi/tte/staff/msa/ > > ps. Do you really want to include this HTML version of the text in > each of your messages, perhaps tick the "send text only" on? > > > > > I didn't know I was. I thought I had the equivalent of "send text only" turned on. ------_=_NextPart_001_01BE08CC.96331F90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: IBM VPN Bakeoff Issues

> -----Original Message-----
> From: Markku Savela [mailto:msa@anise.tte.vtt.fi]
> Sent: Thursday, November 05, 1998 9:43 = AM
> To: tjenkins@TimeStep.com
> Cc: ipsec@tis.com
> Subject: RE: IBM VPN Bakeoff Issues
>
>
>
> > We also had implementations that jumbled = the order when
> they accepted.
> > They're logic is that it doesn't matter, = since order is
> dictated anyway.
>
> To me this logic appears right, as per IPSEC = architecture.
>
> I guess the point culminates on something I = don't know (I am not
> familiar with IKE/ISAMKP details), the = question:
>
>   Why does IKE/ISKAMP need to know = the ordering of negotiated SAs?
>

Maybe IKE itself doesn't. But somewhere in the = implementation, the proper order of transforms must be created as a = result of the negotiation. As we discovered at the interoperability = test, it's not well enough defined.

> > I don't understand where you're coming from = here. Where is
> the policy
> > modification occurring? All we're trying = to do is nail down
> the usage of
> > proposals with the same proposal number = that appear in an
> SA payload.
>
> I'm not quite sure... my thoughts went = somehow.. why do you need to
> care about the ordering if it is already fixed = by policy? And it
> seemed indicate that the ordering was something = that ISAKMP/IKE could
> decide on (which is false).

I think I see where you're coming from here. However, = the order isn't fixed by policy; it's fixed by the documents. We MUST = put IPCOMP before ESP. I think it also says that we MUST put ESP before = AH (this makes sense, anyway). So if we also disallow ESP+ESP in the = same SA payload, it makes the order very determinable, regardless of = the order the proposals appear in inside the SA payload.

So even though IKE can negotiate AH over ESP over = IPCOMP, that's not what should be implemented. So we need to determine = what should be implemented when IKE does negotiate AH over ESP over = IPCOMP, so that interoperability is more reasonably assured.

>
> --
> Markku Savela (msa@hemuli.tte.vtt.fi), = Technical Research
> Centre of Finland
> Multimedia Systems, P.O.Box 1203,FIN-02044 =
> VTT,http://www.vtt.fi/tte/staff/msa/
>
> ps. Do you really want to include this HTML = version of the text in
>     each of your messages, = perhaps tick the "send text only" on?
>
>       <!DOCTYPE = HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
>       = <HTML>
>       = <HEAD>
>

I didn't know I was. I thought I had the equivalent = of "send text only" turned on.

------_=_NextPart_001_01BE08CC.96331F90-- From owner-ipsec Thu Nov 5 09:44:34 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA03291 for ipsec-outgoing; Thu, 5 Nov 1998 09:44:22 -0500 (EST) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01EB5A88@wade.reo.dec.com> From: Stephen Waters To: Avram Shacham Cc: ipsec@tis.com Subject: RE: IBM VPN Bakeoff Issues Date: Thu, 5 Nov 1998 15:01:15 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk ...and since ESP gets involved in adding trailer, it must go before AH since AH want's to know (authenticate) the final packet length. -----Original Message----- From: Avram Shacham [mailto:shacham@cisco.com] Sent: Thursday, November 05, 1998 6:33 AM To: Roy Pereira; IPSEC Mailing List (E-mail) Subject: Re: IBM VPN Bakeoff Issues At 11:58 AM 11/4/98 -0500, Roy Pereira wrote: >9. Should the order of protocols dictate the order of security association or should >AH, ESP, IPComp always be processed in a certain order? Most vendors agreed >with the latter. Risking repeating the obvious, the order is dictated by the reality that compression must precede encryption, as stated in the IPComp draft: Encrypting the IP datagram causes the data to be random in nature, rendering compression at lower protocol layers (e.g., PPP Compression Control Protocol [RFC-1962]) ineffective. If both compression and encryption are required, compression MUST be applied before encryption. avram From owner-ipsec Thu Nov 5 09:44:36 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA03292 for ipsec-outgoing; Thu, 5 Nov 1998 09:44:22 -0500 (EST) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01EB5A8B@wade.reo.dec.com> From: Stephen Waters To: msa@hemuli.tte.vtt.fi Cc: ipsec@tis.com Subject: RE: IBM VPN Bakeoff Issues Date: Thu, 5 Nov 1998 15:01:19 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk >> From: Tim Jenkins >> >> In response to some of the list of issues and questions raised at the IBM >> VPN interoperability workshop: >> >> > 9. Should the order of protocols dictate the order of security >> > association or should AH, ESP, IPComp always be processed in a >> > certain order? Most vendors agreed with the latter >> >> If we consider that a fixed order is assumed, and that we will never support >> ESP and ESP, there are only 4 kinds of bundles possible: IPCOMP+ESP, >> IPCOMP+AH, ESP+AH, and IPCOMP+ESP+AH. > >Looking at this from the pont of view of implemenor of a basic IPSEC + >PFKEY in the kernel, I am perhaps a bit confused again: my >understanding of the IPSEC architecture was > > for outgoing > from policy selector -> SA bundle (list of SA's), apply them > in whatever order the bundle lists. > > for incoming, > apply SA's from the packet, remember the order, and after all > done find the matching policy entry and check that the order > applied matches the order in bundle. SW - I think there are different type of bundle here. Say a policy calls from AH+ESP protection, then that is an 'adjacent-SA-bundle'. Given the definition for an SPD, the other type of bundle is an (adjacent-SA-bundle)-bundle! In our implementation, this second type of bundle is actually a policy-bundle. Maybe more definition is needed: adjacent-SA-bundle := AH AND/OR ESP adjacent and all terminate at the same host (since IPCOMP does not have an SA, as such, and is optional per packet, I guess it doesn't need mentioning as an 'SA', but as 'option' mentioned in the AH and/or ESP SA. These can be tunnel or transport mode. policy-bundle (or some other name) := a combination of ajacent-SA-bundles where two consequtive transport-mode adjacent-SA-bundles are pointless (and illegal?). Steve. From owner-ipsec Thu Nov 5 10:01:48 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA03501 for ipsec-outgoing; Thu, 5 Nov 1998 10:00:19 -0500 (EST) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01EB5A8D@wade.reo.dec.com> From: Stephen Waters To: Tim Jenkins Cc: ipsec@tis.com Subject: RE: IBM VPN Bakeoff Issues Date: Thu, 5 Nov 1998 15:17:35 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk Yes, I know what it says - I was wondering why it said it. Can you clarify? Steve. -----Original Message----- From: Tim Jenkins [mailto:tjenkins@TimeStep.com] Sent: Thursday, November 05, 1998 2:13 PM To: Stephen Waters Cc: ipsec@tis.com Subject: RE: IBM VPN Bakeoff Issues --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Stephen Waters [ mailto:Stephen.Waters@digital.com ] > Sent: Thursday, November 05, 1998 9:02 AM > To: Tim Jenkins > Cc: ipsec@tis.com > Subject: RE: IBM VPN Bakeoff Issues > > > > > > 12. Does ESP-NULL require padding (the ESP doc says 4-byte > alignment, > > ESP-NULL doc says 1-byte alignment). The consensus was that ESP is > > 4-byte aligned. > > There is no ambiguity. ESP in general requires 4 byte padding > or a multiple > of 4. ESP-NULL has a block length of 1. Since the padding used for a > particular combination of ESP and an encryption algorithm is > the lowest > common multiple of 4 (from ESP) and the block length of the > cipher, the > result is that ESP with the NULL cipher uses a padding of 4 > (or 8, or 12, > ...) > [[SW]] There may not be any ambiguity, but there is contradiction and > confusion :) We're not talking about 'ESP in general' though, > right, this is > NULL-ESP, and I don't understand why NULL-ESP should have any > padding, let > alone 4 bytes. NULL-ESP actually means ESP-Authentication, > and the mandatory > authentication algorithms don't need padding. One problem is > where folk > want to pad for other reasons - then your left with the dilemma of not > knowing if it was applied or not. With PPP ECP, if there is > no need to pad, > but the last octet of data could be taken for a pad length, > then explicit > padding is added. Since the pad length can be 0-255, I guess > that means a > pad length is mandatory, but why can't I just add a single > byte with value 0 > if I'm not interested in padding? The ESP document specifically says you must effectively have 4-byte padding requirements (including the Pad Length and Next Header fields). Start Quote: o Padding also may be required, irrespective of encryption algorithm requirements, to ensure that the resulting ciphertext terminates on a 4-byte boundary. Specifically, the Pad Length and Next Header fields must be right aligned within a 4-byte word, as illustrated in the ESP packet format figure above, to ensure that the Authentication Data field (if present) is aligned on a 4-byte boundary. End Quote > > > 16. If an initiator requests an SA with only a single IP address as > > the destination, but the responder has a local policy of a subnet > > (instead of a single IP address), should it fail the negotiation? > > Some vendors were doing this. > > Yes, it should fail. Because then the initiator could then > request another > SA for the next IP address in the range the responder wanted > to use in the > first place. And then the next one. So you end up with a > whole bunch of SAs > that you don't need, and you may end up with a management > issue that you > didn't want. If your system is configured for a subnet, than > that's probably > what the administrator wants. > [[SW]] The architecture does discuss how policies can cause > the creation of > SA where the selector values are taken from the packet (or > the ISAKMP ID > payloads I guess), so this sounds like a management issue > where the response > will be determined by the options set on the policy. > > > I'll reverse my position on this one. Both you and Dan H. have pointed out that this should be a local implementation decision, not a standards decision. From owner-ipsec Thu Nov 5 10:21:07 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA03675 for ipsec-outgoing; Thu, 5 Nov 1998 10:20:20 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF4F7F44@exchange> From: Tim Jenkins To: Stephen Waters Cc: ipsec@tis.com Subject: RE: IBM VPN Bakeoff Issues Date: Thu, 5 Nov 1998 10:40:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE08D2.A0A48380" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE08D2.A0A48380 Content-Type: text/plain; charset="iso-8859-1" Wild guess here: it was done to allow hardware authentication to be more easily implemented? Somebody out there must know the reason. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Stephen Waters [mailto:Stephen.Waters@digital.com] > Sent: Thursday, November 05, 1998 10:18 AM > To: Tim Jenkins > Cc: ipsec@tis.com > Subject: RE: IBM VPN Bakeoff Issues > > > Yes, I know what it says - I was wondering why it said it. > Can you clarify? > Steve. > > -----Original Message----- > From: Tim Jenkins [mailto:tjenkins@TimeStep.com] > Sent: Thursday, November 05, 1998 2:13 PM > To: Stephen Waters > Cc: ipsec@tis.com > Subject: RE: IBM VPN Bakeoff Issues > > > > > > --- > Tim Jenkins TimeStep Corporation > tjenkins@timestep.com http://www.timestep.com > > (613) 599-3610 x4304 Fax: (613) 599-3617 > > > > -----Original Message----- > > From: Stephen Waters [ mailto:Stephen.Waters@digital.com > ] > > Sent: Thursday, November 05, 1998 9:02 AM > > To: Tim Jenkins > > Cc: ipsec@tis.com > > Subject: RE: IBM VPN Bakeoff Issues > > > > > > > > > > > 12. Does ESP-NULL require padding (the ESP doc says 4-byte > > alignment, > > > ESP-NULL doc says 1-byte alignment). The consensus was > that ESP is > > > 4-byte aligned. > > > > There is no ambiguity. ESP in general requires 4 byte padding > > or a multiple > > of 4. ESP-NULL has a block length of 1. Since the padding > used for a > > particular combination of ESP and an encryption algorithm is > > the lowest > > common multiple of 4 (from ESP) and the block length of the > > cipher, the > > result is that ESP with the NULL cipher uses a padding of 4 > > (or 8, or 12, > > ...) > > [[SW]] There may not be any ambiguity, but there is > contradiction and > > confusion :) We're not talking about 'ESP in general' though, > > right, this is > > NULL-ESP, and I don't understand why NULL-ESP should have any > > padding, let > > alone 4 bytes. NULL-ESP actually means ESP-Authentication, > > and the mandatory > > authentication algorithms don't need padding. One problem is > > where folk > > want to pad for other reasons - then your left with the > dilemma of not > > knowing if it was applied or not. With PPP ECP, if there is > > no need to pad, > > but the last octet of data could be taken for a pad length, > > then explicit > > padding is added. Since the pad length can be 0-255, I guess > > that means a > > pad length is mandatory, but why can't I just add a single > > byte with value 0 > > if I'm not interested in padding? > > The ESP document specifically says you must effectively have > 4-byte padding > requirements (including the Pad Length and Next Header fields). > > Start Quote: > > o Padding also may be required, irrespective of encryption > algorithm requirements, to ensure that the resulting > ciphertext terminates on a 4-byte boundary. > Specifically, the > Pad Length and Next Header fields must be right > aligned within > a 4-byte word, as illustrated in the ESP packet > format figure > above, to ensure that the Authentication Data field (if > present) is aligned on a 4-byte boundary. > > End Quote > > > > > > > 16. If an initiator requests an SA with only a single IP > address as > > > the destination, but the responder has a local policy of a subnet > > > (instead of a single IP address), should it fail the negotiation? > > > Some vendors were doing this. > > > > Yes, it should fail. Because then the initiator could then > > request another > > SA for the next IP address in the range the responder wanted > > to use in the > > first place. And then the next one. So you end up with a > > whole bunch of SAs > > that you don't need, and you may end up with a management > > issue that you > > didn't want. If your system is configured for a subnet, than > > that's probably > > what the administrator wants. > > [[SW]] The architecture does discuss how policies can cause > > the creation of > > SA where the selector values are taken from the packet (or > > the ISAKMP ID > > payloads I guess), so this sounds like a management issue > > where the response > > will be determined by the options set on the policy. > > > > > > > > I'll reverse my position on this one. Both you and Dan H. > have pointed out > that this should be a local implementation decision, not a standards > decision. > ------_=_NextPart_001_01BE08D2.A0A48380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: IBM VPN Bakeoff Issues

Wild guess here: it was done to allow hardware = authentication to be more easily implemented?

Somebody out there must know the reason.

---
Tim = Jenkins           = ;            = TimeStep Corporation
tjenkins@timestep.com       =    http://www.timestep.com
(613) 599-3610 = x4304           &= nbsp;   Fax: (613) 599-3617


> -----Original Message-----
> From: Stephen Waters [mailto:Stephen.Waters@digital= .com]
> Sent: Thursday, November 05, 1998 10:18 = AM
> To: Tim Jenkins
> Cc: ipsec@tis.com
> Subject: RE: IBM VPN Bakeoff Issues
>
>
> Yes, I know what it says - I was wondering why = it said it.
> Can you clarify?
> Steve.
>
> -----Original Message-----
> From: Tim Jenkins [mailto:tjenkins@TimeStep.com]<= /FONT>
> Sent: Thursday, November 05, 1998 2:13 = PM
> To: Stephen Waters
> Cc: ipsec@tis.com
> Subject: RE: IBM VPN Bakeoff Issues
>
>
>
>
>
> ---
> Tim = Jenkins           = ;            = TimeStep Corporation
> = tjenkins@timestep.com        &nb= sp; http://www.timestep.com
> <http://www.timestep.com> 
> (613) 599-3610 = x4304           &= nbsp;   Fax: (613) 599-3617
>
>
> > -----Original Message-----
> > From: Stephen Waters [ mailto:Stephen.Waters@digital= .com
> <mailto:Stephen.Waters@digital= .com> ]
> > Sent: Thursday, November 05, 1998 9:02 AM =
> > To: Tim Jenkins
> > Cc: ipsec@tis.com
> > Subject: RE: IBM VPN Bakeoff Issues =
> >
> >
> > 
> >
> > > 12. Does ESP-NULL require padding = (the ESP doc says 4-byte
> > alignment,
> > > ESP-NULL doc says 1-byte = alignment).  The consensus was
> that ESP is
> > > 4-byte aligned.
> >
> > There is no ambiguity. ESP in general = requires 4 byte padding
> > or a multiple
> > of 4. ESP-NULL has a block length of 1. = Since the padding
> used for a
> > particular combination of ESP and an = encryption algorithm is
> > the lowest
> > common multiple of 4 (from ESP) and the = block length of the
> > cipher, the
> > result is that ESP with the NULL cipher = uses a padding of 4
> > (or 8, or 12,
> > ...)
> > [[SW]] There may not be any ambiguity, but = there is
> contradiction and
> > confusion :) We're not talking about 'ESP = in general' though,
> > right, this is
> > NULL-ESP, and I don't understand why = NULL-ESP should have any
> > padding, let
> > alone 4 bytes. NULL-ESP actually means = ESP-Authentication,
> > and the mandatory
> > authentication algorithms don't need = padding.  One problem is
> > where folk
> > want to pad for other reasons - then your = left with the
> dilemma of not
> > knowing if it was applied or not. With PPP = ECP, if there is
> > no need to pad,
> > but the last octet of data could be taken = for a pad length,
> > then explicit
> > padding is added. Since the pad length can = be 0-255, I guess
> > that means a
> > pad length is mandatory, but why can't I = just add a single
> > byte with value 0
> > if I'm not interested in padding?
>
> The ESP document specifically says you must = effectively have
> 4-byte padding
> requirements (including the Pad Length and Next = Header fields).
>
> Start Quote:
>
>          = ;  o Padding also may be required, irrespective of encryption =
>          = ;    algorithm requirements, to ensure that the = resulting
>          = ;    ciphertext terminates on a 4-byte boundary.
> Specifically, the
>          = ;    Pad Length and Next Header fields must be right =
> aligned within
>          = ;    a 4-byte word, as illustrated in the ESP packet =
> format figure
>          = ;    above, to ensure that the Authentication Data field = (if
>          = ;    present) is aligned on a 4-byte boundary.
>
> End Quote
>
>
> >
> > > 16. If an initiator requests an SA = with only a single IP
> address as
> > > the destination, but the responder = has a local policy of a subnet
> > > (instead of a single IP address), = should it fail the negotiation?
> > >  Some vendors were doing this. =
> >
> > Yes, it should fail. Because then the = initiator could then
> > request another
> > SA for the next IP address in the range = the responder wanted
> > to use in the
> > first place. And then the next one. So you = end up with a
> > whole bunch of SAs
> > that you don't need, and you may end up = with a management
> > issue that you
> > didn't want. If your system is configured = for a subnet, than
> > that's probably
> > what the administrator wants.
> > [[SW]] The architecture does discuss how = policies can cause
> > the creation of
> > SA where the selector values are taken = from the packet (or
> > the ISAKMP ID
> > payloads I guess), so this sounds like a = management issue
> > where the response
> > will be determined by the options set on = the policy.
> >
> > 
> >
>
> I'll reverse my position on this one. Both you = and Dan H.
> have pointed out
> that this should be a local implementation = decision, not a standards
> decision.
>

------_=_NextPart_001_01BE08D2.A0A48380-- From owner-ipsec Thu Nov 5 10:43:53 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA04004 for ipsec-outgoing; Thu, 5 Nov 1998 10:43:23 -0500 (EST) Date: Thu, 5 Nov 1998 11:01:37 -0500 Message-Id: <199811051601.LAA25610@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Stephen.Waters@digital.com Cc: ipsec@tis.com Subject: RE: IBM VPN Bakeoff Issues References: <250F9C8DEB9ED011A14D08002BE4F64C01EB5A87@wade.reo.dec.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Stephen" == Stephen Waters writes: >> 12. Does ESP-NULL require padding (the ESP doc says 4-byte >> alignment, ESP-NULL doc says 1-byte alignment). The consensus was >> that ESP is 4-byte aligned. > There is no ambiguity. ESP in general requires 4 byte padding or a multiple > of 4. ESP-NULL has a block length of 1. Since the padding used for a > particular combination of ESP and an encryption algorithm is the lowest > common multiple of 4 (from ESP) and the block length of the cipher, the > result is that ESP with the NULL cipher uses a padding of 4 (or 8, or 12, > ...) > [[SW]] There may not be any ambiguity, but there is contradiction and > confusion :) We're not talking about 'ESP in general' though, right, this is > NULL-ESP, and I don't understand why NULL-ESP should have any padding, let > alone 4 bytes. NULL-ESP actually means ESP-Authentication, and the mandatory > authentication algorithms don't need padding. One problem is where folk > want to pad for other reasons - then your left with the dilemma of not > knowing if it was applied or not. With PPP ECP, if there is no need to pad, > but the last octet of data could be taken for a pad length, then explicit > padding is added. Since the pad length can be 0-255, I guess that means a > pad length is mandatory, but why can't I just add a single byte with value 0 > if I'm not interested in padding? The ESP spec is, as far I can see, perfectly clear on this. I see no contradiction in it. It describes three reasons for padding: 1. encryption transform requires blocks of size n > 1. 2. authentication data should start on 4-byte aligned boundary. 3. sender may want to obfuscate the packet size. It seems pretty clear that (2) is required independent of (1) and (3). As Tim said, the net result is that you must pad to an LCM(blocksize,4) multiple. For DES and the like, that means 8; for RC4 and Null, it means 4. paul From owner-ipsec Thu Nov 5 10:45:38 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA04035 for ipsec-outgoing; Thu, 5 Nov 1998 10:45:26 -0500 (EST) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C01EB5A91@wade.reo.dec.com> From: Stephen Waters To: Tim Jenkins Cc: ipsec@tis.com Subject: RE: IBM VPN Bakeoff Issues Date: Thu, 5 Nov 1998 16:02:13 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk O.K. - there may be a reason somewhere for wanting to add pad, but that sounds like an implementation issue - why make it a MUST to be four-byte alligned? It should be a MUST to send and process-on-receive whatever padding is required/added, but the software/hardware-encryption I'm using doesn't need it, so I want to use a pad-length of zero on all my Tx ESP-Authentication packets. Cheers, Steve. -----Original Message----- From: Tim Jenkins [mailto:tjenkins@TimeStep.com] Sent: Thursday, November 05, 1998 3:40 PM To: Stephen Waters Cc: ipsec@tis.com Subject: RE: IBM VPN Bakeoff Issues Wild guess here: it was done to allow hardware authentication to be more easily implemented? Somebody out there must know the reason. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Stephen Waters [ mailto:Stephen.Waters@digital.com ] > Sent: Thursday, November 05, 1998 10:18 AM > To: Tim Jenkins > Cc: ipsec@tis.com > Subject: RE: IBM VPN Bakeoff Issues > > > Yes, I know what it says - I was wondering why it said it. > Can you clarify? > Steve. > > -----Original Message----- > From: Tim Jenkins [ mailto:tjenkins@TimeStep.com ] > Sent: Thursday, November 05, 1998 2:13 PM > To: Stephen Waters > Cc: ipsec@tis.com > Subject: RE: IBM VPN Bakeoff Issues > > > > > > --- > Tim Jenkins TimeStep Corporation > tjenkins@timestep.com http://www.timestep.com > < http://www.timestep.com > > (613) 599-3610 x4304 Fax: (613) 599-3617 > > > > -----Original Message----- > > From: Stephen Waters [ mailto:Stephen.Waters@digital.com > < mailto:Stephen.Waters@digital.com > ] > > Sent: Thursday, November 05, 1998 9:02 AM > > To: Tim Jenkins > > Cc: ipsec@tis.com > > Subject: RE: IBM VPN Bakeoff Issues > > > > > > > > > > > 12. Does ESP-NULL require padding (the ESP doc says 4-byte > > alignment, > > > ESP-NULL doc says 1-byte alignment). The consensus was > that ESP is > > > 4-byte aligned. > > > > There is no ambiguity. ESP in general requires 4 byte padding > > or a multiple > > of 4. ESP-NULL has a block length of 1. Since the padding > used for a > > particular combination of ESP and an encryption algorithm is > > the lowest > > common multiple of 4 (from ESP) and the block length of the > > cipher, the > > result is that ESP with the NULL cipher uses a padding of 4 > > (or 8, or 12, > > ...) > > [[SW]] There may not be any ambiguity, but there is > contradiction and > > confusion :) We're not talking about 'ESP in general' though, > > right, this is > > NULL-ESP, and I don't understand why NULL-ESP should have any > > padding, let > > alone 4 bytes. NULL-ESP actually means ESP-Authentication, > > and the mandatory > > authentication algorithms don't need padding. One problem is > > where folk > > want to pad for other reasons - then your left with the > dilemma of not > > knowing if it was applied or not. With PPP ECP, if there is > > no need to pad, > > but the last octet of data could be taken for a pad length, > > then explicit > > padding is added. Since the pad length can be 0-255, I guess > > that means a > > pad length is mandatory, but why can't I just add a single > > byte with value 0 > > if I'm not interested in padding? > > The ESP document specifically says you must effectively have > 4-byte padding > requirements (including the Pad Length and Next Header fields). > > Start Quote: > > o Padding also may be required, irrespective of encryption > algorithm requirements, to ensure that the resulting > ciphertext terminates on a 4-byte boundary. > Specifically, the > Pad Length and Next Header fields must be right > aligned within > a 4-byte word, as illustrated in the ESP packet > format figure > above, to ensure that the Authentication Data field (if > present) is aligned on a 4-byte boundary. > > End Quote > > > > > > > 16. If an initiator requests an SA with only a single IP > address as > > > the destination, but the responder has a local policy of a subnet > > > (instead of a single IP address), should it fail the negotiation? > > > Some vendors were doing this. > > > > Yes, it should fail. Because then the initiator could then > > request another > > SA for the next IP address in the range the responder wanted > > to use in the > > first place. And then the next one. So you end up with a > > whole bunch of SAs > > that you don't need, and you may end up with a management > > issue that you > > didn't want. If your system is configured for a subnet, than > > that's probably > > what the administrator wants. > > [[SW]] The architecture does discuss how policies can cause > > the creation of > > SA where the selector values are taken from the packet (or > > the ISAKMP ID > > payloads I guess), so this sounds like a management issue > > where the response > > will be determined by the options set on the policy. > > > > > > > > I'll reverse my position on this one. Both you and Dan H. > have pointed out > that this should be a local implementation decision, not a standards > decision. > From owner-ipsec Thu Nov 5 11:10:59 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA04427 for ipsec-outgoing; Thu, 5 Nov 1998 11:09:23 -0500 (EST) Message-Id: <3.0.5.32.19981105113157.00955b40@catskill.net> X-Sender: dfowler@catskill.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 05 Nov 1998 11:31:57 -0500 To: ipsec@tis.com From: Dennis Fowler Subject: RE: IKE vs ISAKMP/Oakley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk IKE = ISAKMP/Oakley My thanks to all for the clarification. Dennis Fowler P. O. Box 70 Mill Creek Rd. Fire #315 Otego, NY 13825 (607) 432-2012 dfowler@catskill.net From owner-ipsec Thu Nov 5 11:35:44 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA05003 for ipsec-outgoing; Thu, 5 Nov 1998 11:35:24 -0500 (EST) Message-Id: <199811051653.IAA15276@chip.cisco.com> To: Charles Kunzinger cc: ipsec@tis.com In-reply-to: Your message of "Thu, 05 Nov 1998 08:56:17 EST." <199811051356.IAA02475@portal.ex.tis.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15273.910284826.1@cisco.com> Date: Thu, 05 Nov 1998 08:53:46 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk On Thu, 05 Nov 1998 08:56:17 EST you wrote > > 11. If L2TP and IPSec are used in conjuc=nction, and there is no ID payload >in > the > IKE Phase 2 exchanges, should the default be to a)apply IPSec protection to a >ll > IP > packets, b) apply IPSec protection only to packets going through the L2TP > tunnel, > or c) reject the SA proposal? > Consensus appeared to be that only the "tunneled" traffic should get > IPSec > protection. I'm sorry to go against consensus but the draft (when can I start saying RFC?) is specific about this behavior. I originally had some tangled verbage on what it meant without client IDs in Quick Mode. Due to WG input it was rewritten to state the following (this in section 5.5 of IKE): The identities of the SAs negotiated in Quick Mode are implicitly assumed to be the IP addresses of the ISAKMP peers, without any implied constraints on the protocol or port numbers allowed, unless client identifiers are specified in Quick Mode. This is then overridden by any information in the client identities. So if there are no client identities the SA is for the whole IP address of the peer with no constraining port/protocol information. It doesn't matter if you're doing L2TP or not. In fact, if you're not passing client IDs how can the peer know your intent is to do L2TP and decide to accept cleartext packets for everything except UDP port 1701? Dan. From owner-ipsec Thu Nov 5 12:27:51 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA05803 for ipsec-outgoing; Thu, 5 Nov 1998 12:21:26 -0500 (EST) Date: Thu, 5 Nov 1998 12:39:38 -0500 Message-Id: <199811051739.MAA27948@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Stephen.Waters@digital.com Cc: tjenkins@TimeStep.com, ipsec@tis.com Subject: RE: IBM VPN Bakeoff Issues References: <250F9C8DEB9ED011A14D08002BE4F64C01EB5A91@wade.reo.dec.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk The rule that you MUST pad allows alignment optimization to be made not just on encrypt but on decrypt as well. Unfortunately, since not everyone does it right, you still need to be able to cope with misaligned packets inbound -- unless you're willing to fail interoperation with anyone who doesn't obey the alignment rule. paul From owner-ipsec Thu Nov 5 12:49:08 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA06273 for ipsec-outgoing; Thu, 5 Nov 1998 12:47:26 -0500 (EST) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF815FF@RED-MSG-50> From: Richard Draves To: "'Tim Jenkins'" , msa@hemuli.tte.vtt.fi Cc: ipsec@tis.com Subject: RE: IBM VPN Bakeoff Issues Date: Thu, 5 Nov 1998 10:05:40 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk A compliant implementation would only propose bundles that put IPCOMP before ESP. On the other hand, if you are talking to another implementation (perhaps misconfigured or broken) that proposes ESP before IPCOMP, as a liberal receiver I think the best choice is to accept the other implementation's proposal. A second valid choice would be to refuse the proposal. Accepting the proposal but silently reordering it to put IPCOMP before ESP seems totally strange & wrong.   The key thing is that the ordering in the proposals be well-defined. If one implementation thinks left-to-right and another thinks right-to-left, there will be problems. I think I see where you're coming from here. However, the order isn't fixed by policy; it's fixed by the documents. We MUST put IPCOMP before ESP. I think it also says that we MUST put ESP before AH (this makes sense, anyway). So if we also disallow ESP+ESP in the same SA payload, it makes the order very determinable, regardless of the order the proposals appear in inside the SA payload. So even though IKE can negotiate AH over ESP over IPCOMP, that's not what should be implemented. So we need to determine what should be implemented when IKE does negotiate AH over ESP over IPCOMP, so that interoperability is more reasonably assured.   From owner-ipsec Thu Nov 5 13:08:26 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA06763 for ipsec-outgoing; Thu, 5 Nov 1998 13:06:28 -0500 (EST) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81600@RED-MSG-50> From: Richard Draves To: "'Stephen Waters'" , Tim Jenkins Cc: ipsec@tis.com Subject: RE: IBM VPN Bakeoff Issues Date: Thu, 5 Nov 1998 10:24:49 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk > Yes, a point that was not raised at the workshop. We did a > test with AH+ESP > in tunnel mode. We took this to mean AH+ESP adjacent with a > shared tunnel > header. The other vendor took this to mean > IP1+AH+IP2+ESP+IP3. There was > some agreement that a proposal that offered AH-tunnel AND > ESP-tunnel should > mean a shared tunnel-header, but maybe we need more text somewhere. Maybe I'm not understanding this. Looking at the four possible combinations, this is my understanding of how transport & tunnel mode combine: AH-transport + ESP-transport: IP1 AH ESP transport AH-transport + ESP-tunnel: IP1 AH ESP IP2 transport AH-tunnel + ESP-transport: IP1 AH IP2 ESP transport AH-tunnel + ESP-tunnel: IP1 AH IP2 ESP IP3 transport Rich From owner-ipsec Thu Nov 5 13:22:06 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA07370 for ipsec-outgoing; Thu, 5 Nov 1998 13:20:33 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF4F808B@exchange> From: Tim Jenkins To: Richard Draves , 'Stephen@kanata-mh1.ca.newbridge.com, Waters'@kanata-mh1.ca.newbridge.com, Cc: ipsec@tis.com Subject: RE: IBM VPN Bakeoff Issues Date: Thu, 5 Nov 1998 13:39:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE08EB.9DAECDA0" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE08EB.9DAECDA0 Content-Type: text/plain; charset="iso-8859-1" --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Richard Draves [mailto:richdr@microsoft.com] > Sent: Thursday, November 05, 1998 1:25 PM > To: 'Stephen Waters'; Tim Jenkins > Cc: ipsec@tis.com > Subject: RE: IBM VPN Bakeoff Issues > > > > Yes, a point that was not raised at the workshop. We did a > > test with AH+ESP > > in tunnel mode. We took this to mean AH+ESP adjacent with a > > shared tunnel > > header. The other vendor took this to mean > > IP1+AH+IP2+ESP+IP3. There was > > some agreement that a proposal that offered AH-tunnel AND > > ESP-tunnel should > > mean a shared tunnel-header, but maybe we need more text somewhere. > > Maybe I'm not understanding this. Looking at the four > possible combinations, > this is my understanding of how transport & tunnel mode combine: > > AH-transport + ESP-transport: > IP1 AH ESP transport > AH-transport + ESP-tunnel: > IP1 AH ESP IP2 transport > AH-tunnel + ESP-transport: > IP1 AH IP2 ESP transport > AH-tunnel + ESP-tunnel: > IP1 AH IP2 ESP IP3 transport > > Rich > You are correct in how they combine if that's what you explicitly negotiate. But why would you negotiate the third and fourth examples within a single SA payload? I think we should allow only the first and the second of the two above. Further, since I'm clinging to the concept of multiple services in a single SA, I want to specify all the transforms in the proposals as tunnel and get example 2 above, and if I use transport, get example 1 above. If we decide that proposed order within an SA payload is meaningless, we have to do the same for the encapsulation as well, since the encapsulation attribute is tied to the proposal or transform, rather than the SA payload. ------_=_NextPart_001_01BE08EB.9DAECDA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: IBM VPN Bakeoff Issues

---
Tim = Jenkins           = ;            = TimeStep Corporation
tjenkins@timestep.com       =    http://www.timestep.com
(613) 599-3610 = x4304           &= nbsp;   Fax: (613) 599-3617


> -----Original Message-----
> From: Richard Draves [mailto:richdr@microsoft.com]
> Sent: Thursday, November 05, 1998 1:25 = PM
> To: 'Stephen Waters'; Tim Jenkins
> Cc: ipsec@tis.com
> Subject: RE: IBM VPN Bakeoff Issues
>
>
> > Yes, a point that was not raised at the = workshop.  We did a
> > test with AH+ESP
> > in tunnel mode. We took this to mean = AH+ESP adjacent with a
> > shared tunnel
> > header.  The other vendor took this = to mean
> > IP1+AH+IP2+ESP+IP3.  There was
> > some agreement that a proposal that = offered AH-tunnel AND
> > ESP-tunnel should
> > mean a shared tunnel-header, but maybe we = need more text somewhere.
>
> Maybe I'm not understanding this. Looking at = the four
> possible combinations,
> this is my understanding of how transport & = tunnel mode combine:
>
> AH-transport + ESP-transport:
>       IP1 AH ESP = transport
> AH-transport + ESP-tunnel:
>       IP1 AH ESP IP2 = transport
> AH-tunnel + ESP-transport:
>       IP1 AH IP2 ESP = transport
> AH-tunnel + ESP-tunnel:
>       IP1 AH IP2 ESP = IP3 transport
>
> Rich
>

You are correct in how they combine if that's what = you explicitly negotiate. But why would you negotiate the third and = fourth examples within a single SA payload?

I think we should allow only the first and the second = of the two above. Further, since I'm clinging to the concept of = multiple services in a single SA, I want to specify all the transforms = in the proposals as tunnel and get example 2 above, and if I use = transport, get example 1 above.

If we decide that proposed order within an SA payload = is meaningless, we have to do the same for the encapsulation as well, = since the encapsulation attribute is tied to the proposal or transform, = rather than the SA payload.

------_=_NextPart_001_01BE08EB.9DAECDA0-- From owner-ipsec Thu Nov 5 15:00:32 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA11983 for ipsec-outgoing; Thu, 5 Nov 1998 14:59:32 -0500 (EST) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81602@RED-MSG-50> From: Richard Draves To: "'Tim Jenkins'" , msa@hemuli.tte.vtt.fi Cc: ipsec@tis.com Subject: RE: IBM VPN Bakeoff Issues Date: Thu, 5 Nov 1998 12:17:50 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk [Resending - my mailer screwed up the quoting when I replied to the HTML original so my first version was incomprehensible.] A compliant implementation would only propose bundles that put IPCOMP before ESP. On the other hand, if you are talking to another implementation (perhaps misconfigured or broken) that proposes ESP before IPCOMP, as a liberal receiver I think the best choice is to accept the other implementation's proposal. A second valid choice would be to refuse the proposal. Accepting the proposal but silently reordering it to put IPCOMP before ESP seems totally strange & wrong.   The key thing is that the ordering in the proposals be well-defined. If one implementation thinks it means left-to-right and another thinks right-to-left, there will be problems. > I think I see where you're coming from here. However, the > order isn't fixed > by policy; it's fixed by the documents. We MUST put IPCOMP > before ESP. I > think it also says that we MUST put ESP before AH (this makes sense, > anyway). So if we also disallow ESP+ESP in the same SA > payload, it makes the > order very determinable, regardless of the order the > proposals appear in > inside the SA payload. > > So even though IKE can negotiate AH over ESP over IPCOMP, > that's not what > should be implemented. So we need to determine what should be > implemented > when IKE does negotiate AH over ESP over IPCOMP, so that > interoperability is > more reasonably assured. From owner-ipsec Thu Nov 5 15:48:07 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA14503 for ipsec-outgoing; Thu, 5 Nov 1998 15:47:30 -0500 (EST) Date: Thu, 5 Nov 1998 16:05:42 -0500 Message-Id: <199811052105.QAA00704@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ipsec@tis.com Subject: RE: IBM VPN Bakeoff Issues References: <319A1C5F94C8D11192DE00805FBBADDF4F808B@exchange> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk I agree with Tim Jenkins. The set of sensible transform combinations (between any given pair of endpoints) is quite small. It is dubious at best whether it is even legal to do ESP inside IPCOMP; there is no question at all that doing so is silly. Certainly I have no intent of ever implementing it. So what about the "be lenient on receive" rule? It doesn't mean you can ask for things that make no sense. It means only that two different encodings that could reasonably be interpreted to mean the same thing should both be accepted as asking for that thing. This means to me that the proposal order should not matter but no matter what the proposal order, the transform order is always the one required by the current specs. The alternative would be to insist on an order matching the transform application order and rejecting all others, since most of us are clearly not going to implement any others. paul From owner-ipsec Thu Nov 5 16:02:48 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA15243 for ipsec-outgoing; Thu, 5 Nov 1998 16:01:31 -0500 (EST) Message-Id: <199811052120.QAA06085@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: IBM VPN Bakeoff Issues In-Reply-To: Your message of "Thu, 05 Nov 1998 16:05:42 EST." <199811052105.QAA00704@tonga.xedia.com> Date: Thu, 05 Nov 1998 16:20:21 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- [WRT: Tim comments and Paul's response, no specific quote] While I think that a definitive order is good, because it makes analysis easier (fewer combinations == less work), I am concerned about Tim's proposal about amalgamating headers. Before you comment on that: read the archives. I am further concerned that the needs of the host, and the host+gateway^n+host are not clear enough to start putting restrictions in the *spec*. If ISCA wants to certify a portion, or certain options, that is fine (and should be encouraged), but I don't think we should change things. Except for buggy code, why would an implementation that wants to do: IP|ESP|IPCOMP|IP or IP|AH|IP|ESP|IP|IPCOMP specifiy anything other than the order listed in an IKE proposal? :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNkIWk9iXVu0RiA21AQGAjgL/X8dgQUV57xhsJAq4+T/ttXcLSqxIQ1W2 Yez3G7Z3UGFRN2bcnDwTaHzeoFEaTVmFPLp2SC9KGw22EbSeMP4VIC0HfcfeS5Gn SzNZfz9LQnhtKjcj0ExQ6SlWKxBI3oVe =IvZN -----END PGP SIGNATURE----- From owner-ipsec Thu Nov 5 20:44:26 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA02398 for ipsec-outgoing; Thu, 5 Nov 1998 20:42:43 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <363FAF71.10C97F5D@redcreek.com> Date: Thu, 5 Nov 1998 17:35:36 -0500 To: "Scott G. Kelly" From: Stephen Kent Subject: Re: minor inconsistency in arch doc (maybe) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Scott, >'- Transport Layer Protocol: Obtained from the IPv4 "Protocol" or the >IPv6 "Next Header" fields. This may be an individual protocol number. >These packet fields may not contain the Transport Protocol due to the >presence of IP extension headers, e.g., a Routing Header, AH, ESP, >Fragmentation Header, Destination Options, Hop-by-Hop options, etc. Note >that the Transport Protocol may not be available in the case of receipt >of a packet with an ESP header, thus a value of "OPAQUE" SHOULD be >supported.' > >I've always been under the impression that it is reasonable to use >ESP/AH in this field, and in fact, this permits configuration of nested >SAs, perhaps with different endpoints. The text seems to imply that this >is inappropriate, but I don't think that's what is really meant. Earlier >(section 4.4.1, last paragraph), explicit reference is made to using ESP >as a selector for a discard action: The only time two IPsec headers appear back-to-back is when AH and ESP are used in transport mode. It was felt that there was not need to use both AH and ESP together in tunnel mode and iterated tunnels always have IP headers in between. As Charlie noted, we once had another selector value, that distinguished between transport protocols and whatever protocol was next, in support of arbitrary nesting. However, because of the precieved complexity of supporting such nesting, and because it did not seem that such nesting really offered useful added security, this facility was dropped. Steve From owner-ipsec Thu Nov 5 20:44:27 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA02392 for ipsec-outgoing; Thu, 5 Nov 1998 20:42:42 -0500 (EST) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="============_-1301804783==_ma============" X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF4F7D00@exchange> Date: Thu, 5 Nov 1998 17:15:05 -0500 To: Tim Jenkins From: Stephen Kent Subject: Re: IBM VPN Bakeoff Issues Cc: "IPSEC Mailing List (E-mail)" Sender: owner-ipsec@ex.tis.com Precedence: bulk --============_-1301804783==_ma============ Content-Type: text/plain; charset="us-ascii" Tim, >In response to some of the list of issues and questions raised at the IBM >VPN interoperability workshop: > >> 9. Should the order of protocols dictate the order of security >> association or should AH, ESP, IPComp always be processed in a >> certain order? Most vendors agreed with the latter > >If we consider that a fixed order is assumed, and that we will never >support ESP and ESP, there are only 4 kinds of bundles possible: >IPCOMP+ESP, IPCOMP+AH, ESP+AH, and IPCOMP+ESP+AH. > The arch doc limits the combinations of protocols that MUST be supported, and specifies explicit ordering for the transport mode combination of AH+ESP. (ICOMP must be applied first, as Roy noted, and it's not intrinsic to IPsec, so it is not called out explicitly.) Nested transport or iterated tunnel mode options are not supported, except as explicitly defined in section 4.5, because implementors complained about the complexity of supporting such combinations and because nobody felt there was a legitimate requirement for them. > >We should conceptually think of bundles as a single SA that provides >multiple services. This means that all three services expire at the same >time and are re-keyed at the same time. Further, when being negotiated, >they all functionally use the same encapsulation (even though >implementations may consider the outer headers as always being in >transport mode). This means that a gateway always offers tunnel mode for >all three services, since the bundle as a whole is in tunnel mode. >The SAs that make up a bundle are intended to provide a unified set of >services for the traffic associated with the bundle, so I agree that one >ought to terminate the whole bundle at the same time. In practice, it may >be best to do this via purely local mechanisms. >Therefore, for the current version version of IPSec, make the following >statements: > >1) The order of application of services, from inner header to outer, MUST >be IPCOMP, ESP and AH when more than one service is present. This certainly applies for transport mode. For tunnel mode, use of both AH and ESP is not currently supported in SAs with the same endpoints. One can have tunnels terminating at different endpoints, but then the ordering is determined by the termination points for the SAs. >2) The encapsulation mode of all services offered MUST match that >encapsulation mode of the bundle as a whole. As noted above, this is currently required for transport, and not applicable to tunnel mode, but future inclusion of iterated tunnels (with common endpoints) could benefit from a convention of this sort, if no further IKE enhancements arise to clarify the ordering. However, we should still ask what benefit arises from these configurations. > >3) The order of the services in the ANDed offer is not required to be any >particular order. Responders may change the order when selecting the >bundle. > >4) The entire bundle expires when any one of the services within the >bundle expires. > >For IPSecond: > >In order to reduce any ambiguity of implementation, I would suggest that >we consider picturing these four combinations as their own protocols, with >a single header that contains only the necessary information: 1 SPI, one >sequence number, one next header field and one payload length field, each >formatted based on the services it provides. Whoa! This is a major architectural change. Remember that we elected not to call for support of arbitrary combinations and nesting because nobody had good reasons to construct such combinations. Unless the thinking on this has evolved, along with good exaples of why this is needed, why are we proposing such a radical change? > > >A closer examination suggests that this 'super' header could be identical >to the AH protocol header, since it already is a superset of the header >information of all other headers. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Next Header | Payload Len | RESERVED | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Security Parameters Index (SPI) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number Field | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + Authentication Data (variable, 0 for IPCOMP+ESP) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >The advantages of the use of this header are: > 1) reduced ambiguity about application and negotiation of services. > 2) reduced network bandwidth. > 3) possible reduction in packet servicing time. This header structure has a disadvantage too, i.e., by placing the auth data up front, streaming doesn't work. Given the likely pressure for increased performance in IPsec gateways, I'd be very reluctant to make such a change. Also, this header exposes the next protocol data, which ESP does not. For AH this is not an issue, but it may be for some ESP users. Also, this header is not quite accurate, in that it omits the trailer data needed for padding, including the pad length field. Steve --============_-1301804783==_ma============ Content-Type: text/enriched; charset="us-ascii" Tim, In response to some of the list of issues and questions raised at the IBM VPN interoperability workshop: > 9. Should the order of protocols dictate the order of security > association or should AH, ESP, IPComp always be processed in a > certain order? Most vendors agreed with the latter If we consider that a fixed order is assumed, and that we will never support ESP and ESP, there are only 4 kinds of bundles possible: IPCOMP+ESP, IPCOMP+AH, ESP+AH, and IPCOMP+ESP+AH. The arch doc limits the combinations of protocols that MUST be supported, and specifies explicit ordering for the transport mode combination of AH+ESP. (ICOMP must be applied first, as Roy noted, and it's not intrinsic to IPsec, so it is not called out explicitly.) Nested transport or iterated tunnel mode options are not supported, except as explicitly defined in section 4.5, because implementors complained about the complexity of supporting such combinations and because nobody felt there was a legitimate requirement for them. We should conceptually think of bundles as a single SA that provides multiple services. This means that all three services expire at the same time and are re-keyed at the same time. Further, when being negotiated, they all functionally use the same encapsulation (even though implementations may consider the outer headers as always being in transport mode). This means that a gateway always offers tunnel mode for all three services, since the bundle as a whole is in tunnel mode. The SAs that make up a bundle are intended to provide a unified set of services for the traffic associated with the bundle, so I agree that one ought to terminate the whole bundle at the same time. In practice, it may be best to do this via purely local mechanisms. Therefore, for the current version version of IPSec, make the following statements: 1) The order of application of services, from inner header to outer, MUST be IPCOMP, ESP and AH when more than one service is present. This certainly applies for transport mode. For tunnel mode, use of both AH and ESP is not currently supported in SAs with the same endpoints. One can have tunnels terminating at different endpoints, but then the ordering is determined by the termination points for the SAs. 2) The encapsulation mode of all services offered MUST match that encapsulation mode of the bundle as a whole. As noted above, this is currently required for transport, and not applicable to tunnel mode, but future inclusion of iterated tunnels (with common endpoints) could benefit from a convention of this sort, if no further IKE enhancements arise to clarify the ordering. However, we should still ask what benefit arises from these configurations. 3) The order of the services in the ANDed offer is not required to be any particular order. Responders may change the order when selecting the bundle. 4) The entire bundle expires when any one of the services within the bundle expires. For IPSecond: In order to reduce any ambiguity of implementation, I would suggest that we consider picturing these four combinations as their own protocols, with a single header that contains only the necessary information: 1 SPI, one sequence number, one next header field and one payload length field, each formatted based on the services it provides. Whoa! This is a major architectural change. Remember that we elected not to call for support of arbitrary combinations and nesting because nobody had good reasons to construct such combinations. Unless the thinking on this has evolved, along with good exaples of why this is needed, why are we proposing such a radical change? A closer examination suggests that this 'super' header could be identical to the AH protocol header, since it already is a superset of the header information of all other headers. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Payload Len | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication Data (variable, 0 for IPCOMP+ESP) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The advantages of the use of this header are: 1) reduced ambiguity about application and negotiation of services. 2) reduced network bandwidth. 3) possible reduction in packet servicing time. This header structure has a disadvantage too, i.e., by placing the auth data up front, streaming doesn't work. Given the likely pressure for increased performance in IPsec gateways, I'd be very reluctant to make such a change. Also, this header exposes the next protocol data, which ESP does not. For AH this is not an issue, but it may be for some ESP users. Also, this header is not quite accurate, in that it omits the trailer data needed for padding, including the pad length field. Steve --============_-1301804783==_ma============-- From owner-ipsec Thu Nov 5 20:44:26 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA02378 for ipsec-outgoing; Thu, 5 Nov 1998 20:42:37 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: References: Date: Thu, 5 Nov 1998 17:18:03 -0500 To: Ramana Yarlagadda From: Stephen Kent Subject: Re: Selection of proposals Cc: rohit , ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Ramana, >In Sec4.3 Combining Security Associations(page 12) describes >how we can bundle SAs. > 1)Transport adjacency > 2)Iterated tunneling > >And this example matches case2 (in Page 13). so now can I >say that this is a valid cinfiguration with reference to >draft. Example 2 in 4.3 shows a host with two iterated tunnels, one to a gateway, and the other to a host. The example that triggered this message exchange shows a gateway as the common endpoint for the two tunnels. So the two are not exactly the same. However, I agree that the general case described in 4.3 should encompass Rohit's example, as it is one in which one of the two tunnel endpoints is the same. However, Section 4.5 is the authoritative section describing what one MUST support. Section 4.3 refers to 4.5. In 4.5, there is no hard requirement to support iterated tunnels with a common endpoint. >otherwise, what's wrong with that configuration. Can we >know why the implementors requested it that way? Iteration of tunnels adds considerable complexity to processing. There appeared to be no substantive security benefit from such nesting in the cases of primary interest, where a host formed one end of the tunnel. Note that we do require support for the combination of one tunnel and one transport SA involving a host, and that was deemed adequate. However, if one wants to have iterated SAs with a gateway as the endpoint, then tunnel mode is required for both SAs. So, the WG needs to decide if this configuration is one that merits support. If so, we should add it to the list of mandatory configurations, to ensure support. Steve From owner-ipsec Thu Nov 5 20:44:25 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA02391 for ipsec-outgoing; Thu, 5 Nov 1998 20:42:41 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C01EB5A85@wade.reo.dec.com> Date: Thu, 5 Nov 1998 18:35:39 -0500 To: Stephen Waters From: Stephen Kent Subject: RE: IBM VPN Bakeoff Issues Cc: Tim Jenkins , ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve > >Yes, a point that was not raised at the workshop. We did a test with AH+ESP >in tunnel mode. We took this to mean AH+ESP adjacent with a shared tunnel >header. The other vendor took this to mean IP1+AH+IP2+ESP+IP3. There was >some agreement that a proposal that offered AH-tunnel AND ESP-tunnel should >mean a shared tunnel-header, but maybe we need more text somewhere. As I have mentioned in other recent messages, there was an explicit decision to not support the cominnation of AH +ESP in tunnel mode, as opposed to transport mode. It was seen as redundant. Thus I would agree with the other vendor's interpretation. >> Therefore, for the current version version of IPSec, make the following >statements: > >> 1) The order of application of services, from inner header to outer, MUST >be IPCOMP, ESP and AH when more than one >> service is present. Already true for transport mode, not needed for tunnel, unless there is a change of heart about the previous decision. >> 2) The encapsulation mode of all services offered MUST match that >encapsulation mode of the bundle as a whole. Well, remember that a bundle can apply to traffic terminating at two different endpoints, specifically the required combination of a tunnel SA to an SG with a transport SA to a host behind the SG. >> 3) The order of the services in the ANDed offer is not required to be any >particular order. Responders may change the > >>order when selecting the bundle. > >> 4) The entire bundle expires when any one of the services within the >bundle expires. >[[SW]] and IPCOMP MUST be accompanied by a security protocol. See note above about bundles with only one common endpoint. Steve From owner-ipsec Thu Nov 5 20:44:28 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA02400 for ipsec-outgoing; Thu, 5 Nov 1998 20:42:43 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <3.0.1.32.19981105125211.00714fe4@172.16.1.10> References: <3.0.1.32.19981103173528.0074e680@172.16.1.10> Date: Thu, 5 Nov 1998 17:29:32 -0500 To: rohit From: Stephen Kent Subject: Re: Selection of proposals Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Rohit, I have to admit that I cannot follow the example, to understand what was desired vs. what was negotiated and what the problem was. There are too many indefinate atencedents in the text. Please restate the problem in the following terms: Relevant outbound SPD entries for SG1. The entries should be described in terms of selectors, required protocols, and algorithms. (The term "proposal" does not relate to an SPD entry, it's an IKE term, so I can't figure out what you're referring to.) Relevant inbound SPD entries for SG2 and H2, as above. IKE proposals sent by SG1 to SG2, and the response from SG2. Then, with that SA in place, IKE proposals sent by SG1 to H2, and H2's response. Then the resulting pair of iterated tunnels, and why this result does not match what SG2's SPD called for. Steve From owner-ipsec Thu Nov 5 23:53:50 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id XAA13815 for ipsec-outgoing; Thu, 5 Nov 1998 23:52:34 -0500 (EST) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81615@RED-MSG-50> From: Richard Draves To: ipsec@tis.com Subject: RE: IBM VPN Bakeoff Issues Date: Thu, 5 Nov 1998 21:11:33 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk In theory IPsec could support many combinations and permutations of headers. (Infinitely many in fact.) In current practice it appears that only a few possibilities make sense. I agree that only these few possibilities should be mandatory. But I strongly object to ruling out combinations that today appear unnecessary. Who knows what the future will bring? Allowing implementations today to behave "Hmm, they asked for BAC. That can't be right. I'll pretend it was ABC." will unnecessarily limit future flexibility. Rich From owner-ipsec Fri Nov 6 05:02:29 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id FAA24882 for ipsec-outgoing; Fri, 6 Nov 1998 05:00:36 -0500 (EST) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C02155FCB@wade.reo.dec.com> From: Stephen Waters To: Daniel Harkins Cc: ipsec@tis.com, l2tp@zendo.com Subject: RE: Date: Fri, 6 Nov 1998 10:17:46 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk >> >> 11. If L2TP and IPSec are used in conjuc=nction, and there is no ID payload >>in >> the >> IKE Phase 2 exchanges, should the default be to a)apply IPSec protection to a >>ll >> IP >> packets, b) apply IPSec protection only to packets going through the L2TP >> tunnel, >> or c) reject the SA proposal? >> Consensus appeared to be that only the "tunneled" traffic should get >> IPSec >> protection. > > I'm sorry to go against consensus but the draft (when can I start saying >RFC?) is specific about this behavior. I originally had some tangled verbage >on what it meant without client IDs in Quick Mode. Due to WG input it was >rewritten to state the following (this in section 5.5 of IKE): > > The identities of the SAs negotiated in Quick Mode are implicitly > assumed to be the IP addresses of the ISAKMP peers, without any > implied constraints on the protocol or port numbers allowed, unless > client identifiers are specified in Quick Mode. > >This is then overridden by any information in the client identities. So >if there are no client identities the SA is for the whole IP address of >the peer with no constraining port/protocol information. It doesn't matter >if you're doing L2TP or not. In fact, if you're not passing client IDs >how can the peer know your intent is to do L2TP and decide to accept >cleartext packets for everything except UDP port 1701? > > Dan. Good point. Some interesting points came out of the IPSEC+L2TP testing: 1) most folk seemed to 'default' to transport-mode IPSEC protection - taking the IP/UDP/L2TP frames as 'originating packets' - saves adding yet another IP header, and there is a good chance L2TP has just added an 'Internet' header anyway. 2) the L2TP spec (I think) allows the UDP port to 'wonder', which makes selector-based IPSEC tricky (for our implementation at least). It would be 'nice' if the damn thing would stick to one port :) 3) With this 'wondering' in mind, we did contemplate doing some 'socket-based' approach for l2tp, so that when it opened a UDP port, it would request IPSEC protection on it and the quick mode could then easily request the exact src/dest UDP port (l2tp folk?). Applying IPSEC at the socket layer to support L2TP appears to be identical to adding transport-mode once the L2TP packet has gained UDP and IP headers. If L2TP can't be tied-down to a port/set-of-ports, I guess you either lump all UDP traffic in the same security slot, or do something at the transport-protocol interface (sockets approach). Cheers, Steve. From owner-ipsec Fri Nov 6 05:02:31 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id FAA24883 for ipsec-outgoing; Fri, 6 Nov 1998 05:00:36 -0500 (EST) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C02155FC9@wade.reo.dec.com> From: Stephen Waters To: Richard Draves Cc: ipsec@tis.com Subject: RE: IBM VPN Bakeoff Issues Date: Fri, 6 Nov 1998 10:17:43 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk > Yes, a point that was not raised at the workshop. We did a > test with AH+ESP >> in tunnel mode. We took this to mean AH+ESP adjacent with a >> shared tunnel >> header. The other vendor took this to mean >> IP1+AH+IP2+ESP+IP3. There was >> some agreement that a proposal that offered AH-tunnel AND >> ESP-tunnel should >> mean a shared tunnel-header, but maybe we need more text somewhere. > >Maybe I'm not understanding this. Looking at the four possible combinations, >this is my understanding of how transport & tunnel mode combine: >AH-transport + ESP-transport: > IP1 AH ESP transport >AH-transport + ESP-tunnel: > IP1 AH ESP IP2 transport >AH-tunnel + ESP-transport: > IP1 AH IP2 ESP transport >AH-tunnel + ESP-tunnel: > IP1 AH IP2 ESP IP3 transport > >Rich I think the discussion is going along the line that, if the protocols headers are adjacent, they are the same mode and should be declared as such in the proposal. There is room for confusion both ways, but we need to agree on one interpretation (or just cope with different interpretations). For example, AH-transport+ESP-tunnel could be interpreted as IP2 ESP IP1 AH transport. To me, if I am tunneling a packet and, for some reason want to protect it with AH+ESP, I don't want to add two IP-tunnel headers and it seems more 'logical' to call both tunnel-mode (since I did not originate the packet and the protection header is not adjacent to a transport protocol (as in the normal transport case). For me, the only reason to do 'IP3 AH IP2 ESP IP1 transport' would be if IP3 and IP2 had different source or destination address, and in that case, it is more of a policy-bundle where multiple SAs are established to different hosts (usually) with different main/quick mode exchanges. For SA-bundles of adjacent AH and ESP, there are only useful options: AH-transport,ESP-transport, (IP1 AH ESP transport) and AH-tunnel,ESP-tunnel ( IP2 AH ESP IP1 transport). If I wanted to build IP3 AH IP2 ESP IP1 transport, I would expect to do one main/quick mode exchange with IP2 to agree on an ESP tunnel, and then another main/quick mode with IP3 for an AH tunnel (they would probably get requested in the opposite order, but that would be the order they 'came up'). Cheers, Steve. From owner-ipsec Fri Nov 6 07:36:38 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id HAA26531 for ipsec-outgoing; Fri, 6 Nov 1998 07:35:35 -0500 (EST) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C02155FD5@wade.reo.dec.com> From: Stephen Waters To: Stephen Kent Cc: ipsec@tis.com Subject: RE: IBM VPN Bakeoff Issues Date: Fri, 6 Nov 1998 12:52:58 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk >As I have mentioned in other recent messages, there was an explicit >decision to not support the cominnation of AH +ESP in tunnel mode, as >opposed to transport mode. It was seen as redundant. Thus I would agree >with the other vendor's interpretation. We have been here before, I know. My memory of that last discussion was that customers had asked for AH+ESP tunnel. Redundant or not, it was tested at the workshop, and I don't feel like making it an implementation restriction in our product. For those that want to use AH+ESP tunnel adjacency, I'll be sending/expecting both AH and ESP to be expressed as tunnel mode :) >Well, remember that a bundle can apply to traffic terminating at two >different endpoints, specifically the required combination of a tunnel SA >to an SG with a transport SA to a host behind the SG. It seems to me that some new terminology is needed here. This is a 'policy-bundle' and the SA's to the remote SG and the remote host will not get negotiated in the same IKE Phase-2. I will do one phase one/two with the remote SG (perhaps building an SA-bundle for AH and ESP), and then another with the remote-host. I could then have two SA-bundles, probably associated with different SPD policies, making it a 'policy-bundle' as far as the local SG is concerned (which terminates both SA-bundles in this example). Steve From owner-ipsec Fri Nov 6 09:00:15 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA27504 for ipsec-outgoing; Fri, 6 Nov 1998 08:57:34 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF4F824A@exchange> From: Tim Jenkins To: "Michael C. Richardson" , ipsec@tis.com Subject: RE: Bundle Proposals Date: Fri, 6 Nov 1998 09:17:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE0990.39C97450" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE0990.39C97450 Content-Type: text/plain; charset="iso-8859-1" Note subject change. Further, we seem to be diverging past the original *intent* of the discussion. I'll clarify what I thought I was talking about. I want clarification of the implementation when there is 1) a single SA payload 2) in a single quick mode negotiation 3) between 2 peers only 4) there are multiple proposals, and 5) the proposals have the same proposal number. There are 2 issues (and they are sort of separate). 1) What is the order of application of the negotiated services (ESP, AH, IPCOMP)? 2) What encapsulation mode is specified and used for each of those services. Options, Order Issue 1) The services are applied in the order proposed, in the outbound direction. For example, if ESP+IPCOMP+AH is proposed, the packet looks like (ignore encapsulation for now, please) | AH | IPCOMP | ESP | packet | 2) The services are applied in the order proposed, in the inbound direction. Same example: | ESP | IPCOMP | AH | packet | 3) The services are applied on reasonable rules of application, regardless of the order of proposal. Same example: | AH | ESP | IPCOMP | packet | Discussion, Order Issue If option 1 or 2 is chosen, then the responder must not change the order of the proposals. While this allows more flexibility, most of that additional flexibility probably has debatable value. (Remember, we're talking about a single connection between two peers, not layered SAs between different peers.) Proposal 3 may ease implementation issues. Options, Encapsulation Issue 1) Each service specifies its encapsulation mode. This means that the services are not conceptually treated as a single SA. 2) The services are conceptually treated as a single SA, and they all specify tunnel encapsulation for an tunnel mode SA, and they all specify transport encapsulation for a transport mode SA. 3) The services are conceptually treated as a single SA, and the they are all specify transport encapsulation for a transport mode SA, but the inner-most service specifies tunnel mode encapsulation and all other services specify transport mode encapsulation for a tunnel mode SA. Discussion, Encapsulation Issue I don't see any reason to support option 1. First, it's not compatible with option 3 for the order issue. Second, the use of any additional IP headers between the services' headers appears to be a waste of bandwidth without providing any additional services. Option 3 might ease implementation issues, since that's the effect of iterating SAs, but it's not compatible with option 2 of the order issue either. Votes My votes are for option 3 of the order issue (even though we've already implemented option 1) and option 2 of the encapsulation issue. Note that this particular choice does not preclude the negotiation of different SAs between the same peers to get the effect of multiple separate SAs. More below as well... --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Michael C. Richardson [mailto:mcr@sandelman.ottawa.on.ca] > Sent: Thursday, November 05, 1998 4:20 PM > To: ipsec@tis.com > Subject: Re: IBM VPN Bakeoff Issues > > > -----BEGIN PGP SIGNED MESSAGE----- > > > [WRT: Tim comments and Paul's response, no specific quote] > > While I think that a definitive order is good, because it makes > analysis easier (fewer combinations == less work), I am concerned > about Tim's proposal about amalgamating headers. Before you > comment on that: read the archives. > I did that in part to illustrate the concept of how I think proposals with the same proposal number in the same SA payload should be treated. I'm not terribly opinionated on that particular aspect of this issue. > I am further concerned that the needs of the host, and the > host+gateway^n+host are not clear enough to start putting restrictions Could you elaborate on this? What host needs are you referring to? > in the *spec*. If ISCA wants to certify a portion, or certain options, > that is fine (and should be encouraged), but I don't think we should > change things. > Except for buggy code, why would an implementation that wants to do: > IP|ESP|IPCOMP|IP > or > IP|AH|IP|ESP|IP|IPCOMP > > specifiy anything other than the order listed in an IKE proposal? > Why? 1) Because most vendors haven't implemented it that way based on the assumptions of reasonable use. Which we don't seem to have an real disagreement with. "Because we can" is not always a valid reason for doing something. 2) Because (at least) two vendors that did use ordered proposals came up with the opposite order. They both wanted the same thing, but they wouldn't have been able to negotiate it. And we still don't seem to have much comment on the encapsulation assignment. As I said before, if you allow the proposals to be order independent, then you've got to add a rule about encapsulation. ------_=_NextPart_001_01BE0990.39C97450 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Bundle Proposals

Note subject change. Further, we seem to be diverging = past the original *intent* of the discussion. I'll clarify what I = thought I was talking about.

I want clarification of the implementation when there = is
 1) a single SA payload
 2) in a single quick mode negotiation
 3) between 2 peers only
 4) there are multiple proposals, and
 5) the proposals have the same proposal = number.

There are 2 issues (and they are sort of = separate).

1) What is the order of application of the negotiated = services (ESP, AH, IPCOMP)?
2) What encapsulation mode is specified and used for = each of those services.

Options, Order Issue

1) The services are applied in the order proposed, in = the outbound direction. For example, if ESP+IPCOMP+AH is proposed, the = packet looks like (ignore encapsulation for now, please)

  | AH | IPCOMP | ESP | packet |

2) The services are applied in the order proposed, in = the inbound direction. Same example:

  | ESP | IPCOMP | AH | packet |

3) The services are applied on reasonable rules of = application, regardless of the order of proposal. Same example:

  | AH | ESP | IPCOMP | packet |

Discussion, Order Issue

If option 1 or 2 is chosen, then the responder must = not change the order of the proposals. While this allows more = flexibility, most of that additional flexibility probably has debatable = value. (Remember, we're talking about a single connection between two = peers, not layered SAs between different peers.)

Proposal 3 may ease implementation issues.

Options, Encapsulation Issue

1) Each service specifies its encapsulation mode. = This means that the services are not conceptually treated as a single = SA.

2) The services are conceptually treated as a single = SA, and they all specify tunnel encapsulation for an tunnel mode SA, = and they all specify transport encapsulation for a transport mode = SA.

3) The services are conceptually treated as a single = SA, and the they are all specify transport encapsulation for a = transport mode SA, but the inner-most service specifies tunnel mode = encapsulation and all other services specify transport mode = encapsulation for a tunnel mode SA.

Discussion, Encapsulation Issue

I don't see any reason to support option 1. First, = it's not compatible with option 3 for the order issue. Second, the use = of any additional IP headers between the services' headers appears to = be a waste of bandwidth without providing any additional = services.

Option 3 might ease implementation issues, since = that's the effect of iterating SAs, but it's not compatible with option = 2 of the order issue either.

Votes

My votes are for option 3 of the order issue (even = though we've already implemented option 1) and option 2 of the = encapsulation issue.

Note that this particular choice does not preclude = the negotiation of different SAs between the same peers to get the = effect of multiple separate SAs.

More below as well...


---
Tim = Jenkins           = ;            = TimeStep Corporation
tjenkins@timestep.com       =    http://www.timestep.com
(613) 599-3610 = x4304           &= nbsp;   Fax: (613) 599-3617


> -----Original Message-----
> From: Michael C. Richardson [mailto:mcr@sandelman.ottawa.o= n.ca]
> Sent: Thursday, November 05, 1998 4:20 = PM
> To: ipsec@tis.com
> Subject: Re: IBM VPN Bakeoff Issues
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
>
>   [WRT: Tim comments and Paul's = response, no specific quote]
>
>   While I think that a definitive = order is good, because it makes
> analysis easier (fewer combinations =3D=3D less = work), I am concerned
> about Tim's proposal about amalgamating = headers. Before you
> comment on that: read the archives.
>

I did that in part to illustrate the concept of how I = think proposals with the same proposal number in the same SA payload = should be treated. I'm not terribly opinionated on that particular = aspect of this issue.

>   I am further concerned that the = needs of the host, and the
> host+gateway^n+host are not clear enough to = start putting restrictions

Could you elaborate on this? What host needs are you = referring to?

> in the *spec*. If ISCA wants to certify a = portion, or certain options,
> that is fine (and should be encouraged), but I = don't think we should
> change things.
>   Except for buggy code, why would an = implementation that wants to do:
>       = IP|ESP|IPCOMP|IP
>   or
>       = IP|AH|IP|ESP|IP|IPCOMP
>
>   specifiy anything other than the = order listed in an IKE proposal?
>

Why?

1) Because most vendors haven't implemented it that = way based on the assumptions of reasonable use. Which we don't seem to = have an real disagreement with. "Because we can" is not = always a valid reason for doing something.

2) Because (at least) two vendors that did use = ordered proposals came up with the opposite order. They both wanted the = same thing, but they wouldn't have been able to negotiate = it.

And we still don't seem to have much comment on the = encapsulation assignment. As I said before, if you allow the proposals = to be order independent, then you've got to add a rule about = encapsulation.

------_=_NextPart_001_01BE0990.39C97450-- From owner-ipsec Fri Nov 6 09:01:43 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA27569 for ipsec-outgoing; Fri, 6 Nov 1998 09:01:34 -0500 (EST) Message-ID: <778DFE9B4E3BD111A74E08002BA3DC0D827C98@trab-hermes.haninge.trab.se> From: =?ISO-8859-1?Q?Eskil_=C5hlin?= To: "'ipsec@list.tis.com'" Subject: IPsec and SKIP Date: Fri, 6 Nov 1998 15:19:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id JAA27566 Sender: owner-ipsec@ex.tis.com Precedence: bulk This might be a FAQ, but here goes anyway. How do IPsec and SKIP relate? The way I see it SKIP is a key exchange protocol that can be used together with IPsec, but on certain web sites it looks as if it's a complete alternative to IPsec. What have I missed? BTW, why would you use SKIP instead of IKE? IKE and SKIP look very much alike. regards Eskil Åhlin From owner-ipsec Fri Nov 6 09:10:44 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA27686 for ipsec-outgoing; Fri, 6 Nov 1998 09:10:34 -0500 (EST) X-Authentication-Warning: brahma.roc.com: ramana owned process doing -bs Date: Fri, 6 Nov 1998 20:03:53 +0530 (IST) From: Ramana Yarlagadda X-Sender: ramana@brahma.roc.com To: Stephen Kent cc: ipsec@tis.com Subject: Re: Selection of proposals In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi consider the case4 (in Page 27) from H2 H1 must have TWO individual IN-BOUND policies H2-SG2 and H2-H1. And let's assume that SAs are there. Since these two are indivi- dual policies I assume that there are TWO inbound SAs linked to diffrent SPD entries. Then in that case when a packet arrive at H1 from H2 which has Two SAs applied to it ONE @H2 and OTHER ONE @ SG2, if you apply the IpSec processing according to the Steps 1,2,3 and 4 specified on Page-35 in Sec-5.2.1 until Step2 there will be no problem. And at the end of the 2nd step we will have list of SAs applied. But finding an incoming policy (step3 & 4) fails here bcoz there is no single SPD entry matches the list of SAs we collected. otherwise, how will be the Inbound policy at H1 in this case -thanks -ramana On Thu, 5 Nov 1998, Stephen Kent wrote: > Ramana, > > >In Sec4.3 Combining Security Associations(page 12) describes > >how we can bundle SAs. > > 1)Transport adjacency > > 2)Iterated tunneling > > > >And this example matches case2 (in Page 13). so now can I > >say that this is a valid cinfiguration with reference to > >draft. > > Example 2 in 4.3 shows a host with two iterated tunnels, one to a gateway, > and the other to a host. The example that triggered this message exchange > shows a gateway as the common endpoint for the two tunnels. So the two are > not exactly the same. However, I agree that the general case described in > 4.3 should encompass Rohit's example, as it is one in which one of the two > tunnel endpoints is the same. However, Section 4.5 is the authoritative > section describing what one MUST support. Section 4.3 refers to 4.5. In > 4.5, there is no hard requirement to support iterated tunnels with a common > endpoint. > > >otherwise, what's wrong with that configuration. Can we > >know why the implementors requested it that way? > > Iteration of tunnels adds considerable complexity to processing. There > appeared to be no substantive security benefit from such nesting in the > cases of primary interest, where a host formed one end of the tunnel. Note > that we do require support for the combination of one tunnel and one > transport SA involving a host, and that was deemed adequate. However, if > one wants to have iterated SAs with a gateway as the endpoint, then tunnel > mode is required for both SAs. So, the WG needs to decide if this > configuration is one that merits support. If so, we should add it to the > list of mandatory configurations, to ensure support. > > Steve > > From owner-ipsec Fri Nov 6 09:11:39 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA27717 for ipsec-outgoing; Fri, 6 Nov 1998 09:11:33 -0500 (EST) Message-Id: <3.0.1.32.19981106191916.0070dce8@172.16.1.10> X-Sender: rohit@172.16.1.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Fri, 06 Nov 1998 19:19:16 +0500 To: kent@bbn.com From: rohit Subject: Re: Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I am restating the problem, however the scenerio specified here is that given in "draft-ietf-ipsec-arch-sec-06.txt" draft on PAGE 27 case 4: ====================================================== | | |============================== | || | | || ---|----------------------|--- || | | | | H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* | ^ | Intranet) | | ------------------------------ could be dialup admin. boundary (optional) to PPP/ARA server Let us assume that N1 is the IP network address for the network of H1 and N2 that of the network comprising SG2 and H2. The policy at H1 for outbound is direction = out Selectors : src addr H1 dest addr H2 Security Policy : Security Gateway SG2 Protocol ESP with Auth Mode Tunnel Algorithms 3DES or DES MD5 Protocol AH (upto H2) Mode Transport Algorithms SHA-1 or MD5 OR Security Gateway SG2 Protocol ESP with no authentication Mode Tunnel Algorithms 3DES Protocol AH ESP (upto H2) Mode Transport Algorithms SHA-1 DES (We think that this is the way the SPD entry will be and that there arent individual entries for SG2 and H2! If they are two different entries in the SPD, the inbound processing will accumulate an SA bundle that consists of more than one protocol at H1 and finds that the individual SPD entries cannot be satisfied by this.) For inbound the same applies except that the selectors source and destination addresses get interchanged. The inbound policy at SG2 is : direction = in Selectors : src addr H1 destaddr N2 Security Policy : Protocol ESP with no auth Mode Tunnel Algorithms 3DES (NOTE : dest here can be N2 or specifically H2) For outbound the same applies except that the selectors source and destination addresses get interchanged. The policy at H2 for inbound is Selectors : src addr H1 destaddr H2 Security Policy : Protocol AH Mode Transport Algorithms SHA-1 Protocol AH ESP Mode Transport Algorithms SHA-1 DES For outbound the same applies except that the selectors source and destination addresses get interchanged. The questions we have are as follows : * Is it possible for the negotiations with SG2 and H2 from H1 to happen simultaneously or is it always mandatory that the ISAKMP traffic to H2 be protected by the ESP tunnel from H1 to SG2? * In the example policy above, since the negotiations with SG2 and H2 happen independently, SG2 selects the second choice offered by H1 and H2 selects the first one. Since these together satisfy neither of the security policies mandated by H1, they cannot really form an SA bundle but are perfect choices as far as IKE is concerned. The problem here is that we treat the negotiations as completely independent and the selected protocols and transforms are one of those offered. However, since both of them together have to be applied to satisfy security requirements in H1, they cannot form an SA bundle. - Rohit At , you wrote: >At 05:29 PM 11/5/98 -0500, you wrote: >>Rohit, >> >>I have to admit that I cannot follow the example, to understand what was >>desired vs. what was negotiated and what the problem was. There are too >>many indefinate atencedents in the text. Please restate the problem in the >>following terms: >> >> Relevant outbound SPD entries for SG1. The entries should be >>described in terms of selectors, required protocols, and algorithms. (The >>term "proposal" does not relate to an SPD entry, it's an IKE term, so I >>can't figure out what you're referring to.) >> >> Relevant inbound SPD entries for SG2 and H2, as above. >> >> IKE proposals sent by SG1 to SG2, and the response from SG2. Then, >>with that SA in place, IKE proposals sent by SG1 to H2, and H2's response. >>Then the resulting pair of iterated tunnels, and why this result does not >>match what SG2's SPD called for. >> >>Steve >> >> From owner-ipsec Fri Nov 6 09:56:02 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA28315 for ipsec-outgoing; Fri, 6 Nov 1998 09:55:32 -0500 (EST) X-Authentication-Warning: osf1.gmu.edu: xwang4 owned process doing -bs Date: Fri, 6 Nov 1998 10:13:43 -0500 (EST) From: Xunhua Wang To: ipsec@tis.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Hell, all, I am a new comer to ISAKMP and am a little confused about the two-phase protocol: 1. ISAKMP servers establishes ISAKMP SA, using existing shared keys or public key technology. 2. ISAKMP SA is used to negotiate other SAs. What makes me confused is that in the page 15 of the draft-ietf-ipsec-isakmp-10 (postscript version), only cookies appear in the first phase. Another question about IPSEC is about the SPI: ISAKMP SPI is the concatenation of the initiator and responder cookies. How about other SAs? Is there any concrete examples about the generation of SPI of other SAs? Thank you! Xunhua From owner-ipsec Fri Nov 6 10:35:46 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA29192 for ipsec-outgoing; Fri, 6 Nov 1998 10:32:35 -0500 (EST) Date: Fri, 6 Nov 1998 10:32:35 -0500 (EST) From: owner-ipsec@ex.tis.com Message-Id: <199811061532.KAA29192@portal.ex.tis.com> [192.94.214.100]) by portal.ex.tis.com (8.9.1/8.9.1) with ESMTP id HAA26526 for ; Fri, 6 Nov 1998 07:35:31 -0500 (EST) smap (4.1) id xma019984; Fri, 6 Nov 98 08:00:11 -0500 watchdog-rtp.cisco.com (8.6.12/CISCO.SERVER.1.1) with SMTP id MAA17264; Fri, 6 Nov 1998 12:54:25 GMT Date: Fri, 6 Nov 1998 07:53:52 -0500 (EST) From: "W. Mark Townsley" To: Stephen Waters cc: Daniel Harkins , ipsec@tis.com, l2tp@zendo.com Subject: RE: In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C02155FCB@wade.reo.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk On Fri, 6 Nov 1998, Stephen Waters wrote: > >> > >> 11. If L2TP and IPSec are used in conjuc=nction, and there is no ID > payload > >>in > >> the > >> IKE Phase 2 exchanges, should the default be to a)apply IPSec protection > to a > >>ll > >> IP > >> packets, b) apply IPSec protection only to packets going through the L2TP > >> tunnel, > >> or c) reject the SA proposal? > >> Consensus appeared to be that only the "tunneled" traffic should get > >> IPSec > >> protection. > > > > I'm sorry to go against consensus but the draft (when can I start saying > >RFC?) is specific about this behavior. I originally had some tangled > verbage > >on what it meant without client IDs in Quick Mode. Due to WG input it was > >rewritten to state the following (this in section 5.5 of IKE): > > > > The identities of the SAs negotiated in Quick Mode are implicitly > > assumed to be the IP addresses of the ISAKMP peers, without any > > implied constraints on the protocol or port numbers allowed, unless > > client identifiers are specified in Quick Mode. > > > >This is then overridden by any information in the client identities. So > >if there are no client identities the SA is for the whole IP address of > >the peer with no constraining port/protocol information. It doesn't matter > >if you're doing L2TP or not. In fact, if you're not passing client IDs > >how can the peer know your intent is to do L2TP and decide to accept > >cleartext packets for everything except UDP port 1701? > > > > Dan. > > Good point. Some interesting points came out of the IPSEC+L2TP testing: > > 1) most folk seemed to 'default' to transport-mode IPSEC protection - taking > the IP/UDP/L2TP > frames as 'originating packets' - saves adding yet another IP header, and > there is a good > chance L2TP has just added an 'Internet' header anyway. > > 2) the L2TP spec (I think) allows the UDP port to 'wonder', which makes > selector-based IPSEC > tricky (for our implementation at least). It would be 'nice' if the damn > thing would stick to one port :) > > 3) With this 'wondering' in mind, we did contemplate doing some > 'socket-based' approach for l2tp, so that > when it opened a UDP port, it would request IPSEC protection on it and the > quick mode could then > easily request the exact src/dest UDP port (l2tp folk?). Applying IPSEC at > the socket layer to support > L2TP appears to be identical to adding transport-mode once the L2TP packet > has gained UDP and IP > headers. L2TP is allowed to wonder, but a peer is always required to respond to the source port you select. Thus, you always have control over the source port for outgoing traffic, and the destination port for incoming traffic. This, together with the source and destination IP address, is enough to define an individual l2tp tunnel. Among other things, it is important to allow multiple source ports in case you wish to have different policies for different users (tunnels) between the same two tunnel endpoints (ip addresses). > > If L2TP can't be tied-down to a port/set-of-ports, I guess you either lump > all UDP traffic in the same > security slot, or do something at the transport-protocol interface (sockets > approach). > > Cheers, Steve. > > > > From owner-ipsec Fri Nov 6 11:16:44 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA00094 for ipsec-outgoing; Fri, 6 Nov 1998 11:15:38 -0500 (EST) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81616@RED-MSG-50> From: Richard Draves To: "'Stephen Waters'" Cc: "'IPsec'" Subject: RE: IBM VPN Bakeoff Issues Date: Fri, 6 Nov 1998 08:34:07 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk > If your saying 'IKE proposal ordering should have no > signficance', I agree. I think it should have significance. > I think it would also make sense to say that all 'AND' > proposals are the same mode (tunnel or transport) > and MUST be adjacent and in performed on the data in the > 'right' order (IPCOMP,ESP,AH) > and appear in the packet in that order (building outwards). > > Of the AH+ESP test we did last week, I had no problems with > AH+ESP in transport mode, but > our interpretation of AH-tunnel AND ESP-tunnel was different > from another vendors. We thought it > should be 'IP AH ESP IP upper', and they thought it should be > 'IP AH IP ESP IP upper'. I agree with "they". If you want to specify "IP AH ESP IP upper", then ask for AH-transport AND ESP-tunnel. Rich From owner-ipsec Fri Nov 6 17:28:23 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA00547 for ipsec-outgoing; Fri, 6 Nov 1998 17:11:30 -0500 (EST) Message-Id: <199811061804.NAA09883@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Paul Koning: Re: IBM VPN Bakeoff Issues Date: Fri, 06 Nov 1998 13:04:08 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk From: Paul Koning To: mcr@sandelman.ottawa.on.ca Subject: Re: IBM VPN Bakeoff Issues References: <199811052254.RAA04036@tonga.xedia.com> <199811060226.VAA06481@istari.sandelman.ottawa.on.ca> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid X-Filtered-By: NoCeM-E v0.6 (http://www.novia.net/~doumakes) >>>>> "Michael" == Michael C Richardson writes: >>>>> "Paul" == Paul Koning writes: >>>>> "Michael" == Michael C Richardson writes: Michael> Except for buggy code, why would an implementation that Michael> wants to do: IP|ESP|IPCOMP|IP or IP|AH|IP|ESP|IP|IPCOMP Michael> specifiy anything other than the order listed in an IKE Michael> proposal? Paul> Perhaps because I think of this as "AH then ESP then IPCOMP" Paul> because I look at packet formats, and someone else thinks of it Paul> as "IPCOMP then ESP then AH" because they look at encryption Paul> processing order? Michael> [May I post to the list?] Yes, by all means. Michael> So, all we need to do really is define the canonical order, Michael> rather than try and limit IKE to negotiating these Michael> predefined "bundles", which may not be what we want in two Michael> years. That makes sense. paul From owner-ipsec Fri Nov 6 17:28:23 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA00571 for ipsec-outgoing; Fri, 6 Nov 1998 17:11:42 -0500 (EST) Message-Id: <3.0.5.32.19981106191605.00991320@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 06 Nov 1998 19:16:05 +0200 To: ipsec@tis.com From: Joern Sierwald Subject: RE: Bundle Proposals In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF4F824A@exchange> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id RAA00522 Sender: owner-ipsec@ex.tis.com Precedence: bulk At 09:17 06/11/98 -0500, Tim wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note subject change. Further, we seem to be diverging past the original *intent* of the discussion. I'll clarify what I thought I was talking about. I want clarification of the implementation when there is 1) a single SA payload 2) in a single quick mode negotiation 3) between 2 peers only 4) there are multiple proposals, and 5) the proposals have the same proposal number. There are 2 issues (and they are sort of separate). 1) What is the order of application of the negotiated services (ESP, AH, IPCOMP)? 2) What encapsulation mode is specified and used for each of those services. Options, Order Issue 1) The services are applied in the order proposed, in the outbound direction. For example, if ESP+IPCOMP+AH is proposed, the packet looks like (ignore encapsulation for now, please) | AH | IPCOMP | ESP | packet | 2) The services are applied in the order proposed, in the inbound direction. Same example: | ESP | IPCOMP | AH | packet | 3) The services are applied on reasonable rules of application, regardless of the order of proposal. Same example: | AH | ESP | IPCOMP | packet | Discussion, Order Issue If option 1 or 2 is chosen, then the responder must not change the order of the proposals. While this allows more flexibility, most of that additional flexibility probably has debatable value. (Remember, we're talking about a single connection between two peers, not layered SAs between different peers.) Proposal 3 may ease implementation issues. Options, Encapsulation Issue 1) Each service specifies its encapsulation mode. This means that the services are not conceptually treated as a single SA. 2) The services are conceptually treated as a single SA, and they all specify tunnel encapsulation for an tunnel mode SA, and they all specify transport encapsulation for a transport mode SA. 3) The services are conceptually treated as a single SA, and the they are all specify transport encapsulation for a transport mode SA, but the inner-most service specifies tunnel mode encapsulation and all other services specify transport mode encapsulation for a tunnel mode SA. Discussion, Encapsulation Issue I don't see any reason to support option 1. First, it's not compatible with option 3 for the order issue. Second, the use of any additional IP headers between the services' headers appears to be a waste of bandwidth without providing any additional services. Option 3 might ease implementation issues, since that's the effect of iterating SAs, but it's not compatible with option 2 of the order issue either. Votes My votes are for option 3 of the order issue (even though we've already implemented option 1) and option 2 of the encapsulation issue. Note that this particular choice does not preclude the negotiation of different SAs between the same peers to get the effect of multiple separate SAs. More below as well... --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 <<<<<<<<<<<<<<<<<<<<<<<< The order issue should not be option 3). It makes future extensions (new transformations) impossible. If somebody comes up with a transformation that can be used in several places (unlike the ones we have), we have a serious problem. It should be 1) or 2). ESP+IPCOMP+AH is an illegal combination, then. For the encapsulation issue, I'd vote for 1). Same reasoning. Jörn Sierwald From owner-ipsec Fri Nov 6 17:28:25 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA00561 for ipsec-outgoing; Fri, 6 Nov 1998 17:11:38 -0500 (EST) Message-ID: <005d01be09ac$cfcd0f60$7c2068c0@Rock124.frontiertech.com> From: "Christopher McCann" To: "Roy Pereira" Cc: "TIS" Subject: Re: IBM VPN Bakeoff Issues Date: Fri, 6 Nov 1998 11:42:23 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk >> 17. The HASH payload must be the first payload in a info/new group >> exchange. This isn't clear in the documents. >From the draft-ietf-isakmp-oakley-08 draft, section 5.7 and I quote: 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. I also don't understand why we would want to do this: >> 36. X.500 DN is a valid ID type when doing shared-secret authentication To me, shared secret authentication is for allowing IKEs that don't have any knowledge of LDAPs or certificates. Requiring X.500 DN names is hard to express by an administrator without some sort of knowledge about getting the DN name from an LDAP or certificate. I would like to see this requirement go away. I don't mine tying shared secrets to e-mail addresses or fully qualified domain names since these can be expressed easily, but getting the DN name correctly would be a nightmare. Let's drop this requirement. Chris McCann From owner-ipsec Fri Nov 6 17:28:26 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA00570 for ipsec-outgoing; Fri, 6 Nov 1998 17:11:42 -0500 (EST) Message-Id: <199811061718.JAA02282@chip.cisco.com> To: Richard Draves cc: "'Stephen Waters'" , "'IPsec'" Subject: Re: IBM VPN Bakeoff Issues In-reply-to: Your message of "Fri, 06 Nov 1998 08:34:07 PST." <4D0A23B3F74DD111ACCD00805F31D8100AF81616@RED-MSG-50> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2280.910372704.1@cisco.com> Date: Fri, 06 Nov 1998 09:18:24 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk This has been discussed before. There was a whole "ESP and AH used in tunnel mode by a Security Gateway" thread back in July. In that thread I noted that we were discussing something that was discussed back in May when the issue was ESP and IPPCP. What was agreed to back then was that for a _security gateway_, any transit traffic MUST be in tunnel mode so that in IP AH ESP IP both AH and ESP would be in tunnel mode. Steve Kent noted that this is not required by the Arch Doc (but I guess it's not forbidden either). So if that's the way a security gateway negotiates it why would we want to do something different for an end host? Aren't these things complicated enough? Dan. On Fri, 06 Nov 1998 08:34:07 PST you wrote > > If your saying 'IKE proposal ordering should have no > > signficance', I agree. > > I think it should have significance. > > > I think it would also make sense to say that all 'AND' > > proposals are the same mode (tunnel or transport) > > and MUST be adjacent and in performed on the data in the > > 'right' order (IPCOMP,ESP,AH) > > and appear in the packet in that order (building outwards). > > > > Of the AH+ESP test we did last week, I had no problems with > > AH+ESP in transport mode, but > > our interpretation of AH-tunnel AND ESP-tunnel was different > > from another vendors. We thought it > > should be 'IP AH ESP IP upper', and they thought it should be > > 'IP AH IP ESP IP upper'. > > I agree with "they". If you want to specify "IP AH ESP IP upper", then ask > for AH-transport AND ESP-tunnel. > > Rich From owner-ipsec Fri Nov 6 18:22:20 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA01104 for ipsec-outgoing; Fri, 6 Nov 1998 18:12:46 -0500 (EST) Message-ID: <364386CE.FDA818A@redcreek.com> Date: Fri, 06 Nov 1998 15:31:26 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: ipsec@tis.com Subject: Re: minor inconsistency in arch doc (maybe) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, I guess I didn't really make myself clear - let me try again. First, here's a simple schematic: H1-----SGW1-------SGW2----H2 In SGW1, I want to apply ESP tunnel mode to IP datagrams from H1 to H2. Note that there may be other hosts on H1's net, and also on H2's net, and I am including only H1 and H2 as reps of those nets for simplicity. Now, in SGW1, I have the following policy entries, among others: sourceIP destIP protocol ports SA parms ==================================================================== H1's IP H2's IP * * ESP-tunnel,3DES,SHA1 SGW1's IP SGW2's IP ESP -- AH-transport,SHA1 An alternative policy set which produces a similar effect: sourceIP destIP protocol ports SA parms ==================================================================== H1's IP H2's IP ESP * AH-transport,SHA1 Note the use of ESP in the protocol field. My question: does this violate the design intent of the architecture, or is the language I quoted in my earlier post a bit misleading? Scott From owner-ipsec Fri Nov 6 18:59:09 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA01176 for ipsec-outgoing; Fri, 6 Nov 1998 18:47:45 -0500 (EST) Message-ID: <36438F0E.DFC69CC@redcreek.com> Date: Fri, 06 Nov 1998 16:06:38 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Richard Draves CC: ipsec@tis.com Subject: Re: IBM VPN Bakeoff Issues References: <4D0A23B3F74DD111ACCD00805F31D8100AF81615@RED-MSG-50> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Richard Draves wrote: > > In theory IPsec could support many combinations and permutations of headers. > (Infinitely many in fact.) In current practice it appears that only a few > possibilities make sense. I agree that only these few possibilities should > be mandatory. But I strongly object to ruling out combinations that today > appear unnecessary. Who knows what the future will bring? Allowing > implementations today to behave "Hmm, they asked for BAC. That can't be > right. I'll pretend it was ABC." will unnecessarily limit future > flexibility. Here, here. From owner-ipsec Fri Nov 6 19:03:34 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA01194 for ipsec-outgoing; Fri, 6 Nov 1998 18:52:47 -0500 (EST) Message-ID: <3643904B.279FDAB3@redcreek.com> Date: Fri, 06 Nov 1998 16:11:55 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: Stephen Waters , Tim Jenkins , ipsec@tis.com Subject: Re: IBM VPN Bakeoff Issues References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Kent wrote: > > 2) The encapsulation mode of all services offered MUST match that > >encapsulation mode of the bundle as a whole. > > Well, remember that a bundle can apply to traffic terminating at two > different endpoints, specifically the required combination of a tunnel SA > to an SG with a transport SA to a host behind the SG. Precisely. And what about ESP in tunnel mode, wrapped with AH in transport mode between 2 SGs? I recognize all too well how these restrictions would simplify processing, but don't think that makes for a good reason to modify the spec. From owner-ipsec Fri Nov 6 19:09:54 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA01201 for ipsec-outgoing; Fri, 6 Nov 1998 18:57:46 -0500 (EST) Message-ID: <36439155.DC56BFE7@redcreek.com> Date: Fri, 06 Nov 1998 16:16:21 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Waters CC: Richard Draves , ipsec@tis.com Subject: Re: IBM VPN Bakeoff Issues References: <250F9C8DEB9ED011A14D08002BE4F64C02155FC9@wade.reo.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Waters wrote: > I think the discussion is going along the line that, if the protocols > headers are adjacent, > they are the same mode and should be declared as such in the proposal. > If the discussion is really going along this line, then it has gone wrong. AH transport wrapped around an ESP tunnel looks like this: [IP2][AH][ESP][IP1][DATA][TLR] Clearly, the AH and ESP headers are adjacent, yet the modes are different, and should be declared as such in the proposal. From owner-ipsec Fri Nov 6 20:05:38 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id TAA01393 for ipsec-outgoing; Fri, 6 Nov 1998 19:59:58 -0500 (EST) Message-ID: <36439FF9.AC2E9D60@redcreek.com> Date: Fri, 06 Nov 1998 17:18:49 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Harkins CC: Richard Draves , "'Stephen Waters'" , "'IPsec'" Subject: Re: IBM VPN Bakeoff Issues References: <199811061718.JAA02282@chip.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Dan, Daniel Harkins wrote: > > This has been discussed before. There was a whole "ESP and AH used > in tunnel mode by a Security Gateway" thread back in July. In that > thread I noted that we were discussing something that was discussed > back in May when the issue was ESP and IPPCP. > > What was agreed to back then was that for a _security gateway_, any > transit traffic MUST be in tunnel mode so that in IP AH ESP IP > both AH and ESP would be in tunnel mode. Steve Kent noted that this > is not required by the Arch Doc (but I guess it's not forbidden > either). So if that's the way a security gateway negotiates it why > would we want to do something different for an end host? Aren't these > things complicated enough? I *just* received this one, else I would have addressed it in my last post on this topic. I guess I understand your issue here: the architecture doc says that SGWs must use tunnel mode unless they are terminating the flow, and you don't think the SGW is doing that. I think it is. It's terminating the ESP tunnel, so it's okay to use transport mode AH on that flow. This cuts across the earlier thread here about whether ESP/AH are suitable protocols for the 'transport protocol' selector designation. I guess at this point I'd argue that ESP *is* a transport protocol, while AH might more likely be simply an IP extension header, like IP options. If we grant that ESP is a transport protocol, then it follows that the SGWs are terminating it, and that AH in transport mode is acceptable in this case. I would argue that the adjacency of the AH/ESP headers precludes the possiblity that both are in tunnel mode, since by our own definitions, tunnel mode requires encapsulation of the original datagram, while tranport mode consists of header insertion between the original header and the data. I recognize that this is a bit of a twisted web here, but I think you're asking that we agree on a convention which is unnecessary. Waddayathink? Scott From owner-ipsec Fri Nov 6 20:07:43 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA01418 for ipsec-outgoing; Fri, 6 Nov 1998 20:03:54 -0500 (EST) Message-Id: <199811070121.RAA28335@chip.cisco.com> To: "Scott G. Kelly" cc: Stephen Waters , Richard Draves , ipsec@tis.com Subject: Re: IBM VPN Bakeoff Issues In-reply-to: Your message of "Fri, 06 Nov 1998 16:16:21 PST." <36439155.DC56BFE7@redcreek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28333.910401694.1@cisco.com> Date: Fri, 06 Nov 1998 17:21:35 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk On Fri, 06 Nov 1998 16:16:21 PST you wrote > Stephen Waters wrote: > > I think the discussion is going along the line that, if the protocols > > headers are adjacent, > > they are the same mode and should be declared as such in the proposal. > > > > If the discussion is really going along this line, then it has gone > wrong. AH transport wrapped around an ESP tunnel looks like this: > > [IP2][AH][ESP][IP1][DATA][TLR] > > Clearly, the AH and ESP headers are adjacent, yet the modes are > different, and should be declared as such in the proposal. You mean proposal_s_. Proposing AH&ESP to protect tunneled traffic between 2 hosts is different than proposing ESP to protect tunneled traffic between 2 hosts (STOP, seperate negotiation) and then proposing AH to protect ESP traffic in transport mode between the 2 gateways. You can't express the "...protect ESP traffic" part of the AH proposal without specific client IDs which would be different than the client IDs for the ESP traffic. Since client IDs must be consistant across all offers they have to be seperate proposals. Yea, I guess these two things would be constructed pretty much the same. Weird. But they'd be processed differently and they are negotiated differently. (Just for the record, I'm not saying AH in transport protecting ESP in tunnel protecting the protected packets is a good thing. In fact, I think we're right in not requiring support for such a beast). Dan. From owner-ipsec Fri Nov 6 20:16:38 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA01529 for ipsec-outgoing; Fri, 6 Nov 1998 20:13:56 -0500 (EST) Message-ID: <3643A30E.B42002F1@redcreek.com> Date: Fri, 06 Nov 1998 17:31:58 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Harkins CC: Stephen Waters , Richard Draves , ipsec@tis.com Subject: Re: IBM VPN Bakeoff Issues References: <199811070121.RAA28335@chip.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Dan, Daniel Harkins wrote: > > [IP2][AH][ESP][IP1][DATA][TLR] > > > > Clearly, the AH and ESP headers are adjacent, yet the modes are > > different, and should be declared as such in the proposal. > > You mean proposal_s_. > > Proposing AH&ESP to protect tunneled traffic between 2 hosts is different than > proposing ESP to protect tunneled traffic between 2 hosts (STOP, seperate > negotiation) and then proposing AH to protect ESP traffic in transport mode > between the 2 gateways. You can't express the "...protect ESP traffic" part > of the AH proposal without specific client IDs which would be different than > the client IDs for the ESP traffic. Since client IDs must be consistant across > all offers they have to be seperate proposals. Okay, I see what you mean. So, are you arguing that if someone wants this construct, that we should, by convention, combine the AH/ESP proposals using tunnel mode for both? Scott From owner-ipsec Fri Nov 6 20:24:02 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA01563 for ipsec-outgoing; Fri, 6 Nov 1998 20:19:54 -0500 (EST) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81630@RED-MSG-50> From: Richard Draves To: "'Daniel Harkins'" , "Scott G. Kelly" Cc: Stephen Waters , ipsec@tis.com Subject: RE: IBM VPN Bakeoff Issues Date: Fri, 6 Nov 1998 17:38:24 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk > > If the discussion is really going along this line, then it has gone > > wrong. AH transport wrapped around an ESP tunnel looks like this: > > > > [IP2][AH][ESP][IP1][DATA][TLR] > > > > Clearly, the AH and ESP headers are adjacent, yet the modes are > > different, and should be declared as such in the proposal. > > You mean proposal_s_. > > Proposing AH&ESP to protect tunneled traffic between 2 hosts > is different than proposing ESP to protect tunneled traffic > between 2 hosts (STOP, seperate negotiation) and then proposing AH to > protect ESP traffic in transport mode between the 2 gateways. Suppose someone in the future, for some reason we don't understand now, wants to use AH transport wrapped around ESP tunnel, directly between two hosts? Could this be negotiated with one proposal asking for AH-transport + ESP-tunnel? Rich From owner-ipsec Fri Nov 6 20:39:45 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA01621 for ipsec-outgoing; Fri, 6 Nov 1998 20:36:53 -0500 (EST) Message-Id: <199811070155.RAA29671@chip.cisco.com> To: Richard Draves cc: "Scott G. Kelly" , Stephen Waters , ipsec@tis.com Subject: Re: IBM VPN Bakeoff Issues In-reply-to: Your message of "Fri, 06 Nov 1998 17:38:24 PST." <4D0A23B3F74DD111ACCD00805F31D8100AF81630@RED-MSG-50> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29669.910403723.1@cisco.com> Date: Fri, 06 Nov 1998 17:55:23 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Not with IKE. What you're asking for is AH protecting ESP protecting foo. To clarify the AH offer (that it's for ESP) you need client IDs that say "This offer applies to protocol 50". To clarify the ESP offer (that it's for foo) you also need client IDs that say "This offer applies to foo". You can't express all that together in one offer. The same goes for PFS. If you want group 5 for ESP and group 1 for AH you can't do it all in one offer. It has to be separate. Dan. On Fri, 06 Nov 1998 17:38:24 PST you wrote > > Suppose someone in the future, for some reason we don't understand now, > wants to use AH transport wrapped around ESP tunnel, directly between two > hosts? Could this be negotiated with one proposal asking for AH-transport + > ESP-tunnel? > > Rich From owner-ipsec Fri Nov 6 21:12:53 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id VAA01739 for ipsec-outgoing; Fri, 6 Nov 1998 21:10:50 -0500 (EST) Message-Id: <199811070229.SAA00471@chip.cisco.com> To: "Scott G. Kelly" cc: Richard Draves , "'Stephen Waters'" , "'IPsec'" Subject: Re: IBM VPN Bakeoff Issues In-reply-to: Your message of "Fri, 06 Nov 1998 17:18:49 PST." <36439FF9.AC2E9D60@redcreek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <468.910405740.1@cisco.com> Date: Fri, 06 Nov 1998 18:29:00 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Scott, I guess it doesn't matter what we agree to because in 2 bakeoffs hence somebody else raise this as an "issue" and we'll all climb back into the rathole. Yes, what we have today, what we agreed to the time before when this issue was raised, isn't Architecturally Pure (tm) but it works and there is running code, from different people, that does it this way. And it does make sense. I swear, this WG flip flops so much we make Clinton look good. Dan. On Fri, 06 Nov 1998 17:18:49 PST you wrote > Hi Dan, > > Daniel Harkins wrote: > > > > This has been discussed before. There was a whole "ESP and AH used > > in tunnel mode by a Security Gateway" thread back in July. In that > > thread I noted that we were discussing something that was discussed > > back in May when the issue was ESP and IPPCP. > > > > What was agreed to back then was that for a _security gateway_, any > > transit traffic MUST be in tunnel mode so that in IP AH ESP IP > > both AH and ESP would be in tunnel mode. Steve Kent noted that this > > is not required by the Arch Doc (but I guess it's not forbidden > > either). So if that's the way a security gateway negotiates it why > > would we want to do something different for an end host? Aren't these > > things complicated enough? > > I *just* received this one, else I would have addressed it in my last > post on this topic. I guess I understand your issue here: the > architecture doc says that SGWs must use tunnel mode unless they are > terminating the flow, and you don't think the SGW is doing that. I think > it is. It's terminating the ESP tunnel, so it's okay to use transport > mode AH on that flow. > > This cuts across the earlier thread here about whether ESP/AH are > suitable protocols for the 'transport protocol' selector designation. I > guess at this point I'd argue that ESP *is* a transport protocol, while > AH might more likely be simply an IP extension header, like IP options. > If we grant that ESP is a transport protocol, then it follows that the > SGWs are terminating it, and that AH in transport mode is acceptable in > this case. > > I would argue that the adjacency of the AH/ESP headers precludes the > possiblity that both are in tunnel mode, since by our own definitions, > tunnel mode requires encapsulation of the original datagram, while > tranport mode consists of header insertion between the original header > and the data. > > I recognize that this is a bit of a twisted web here, but I think you're > asking that we agree on a convention which is unnecessary. Waddayathink? > > Scott From owner-ipsec Sat Nov 7 12:31:27 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA03066 for ipsec-outgoing; Sat, 7 Nov 1998 12:28:50 -0500 (EST) Message-Id: <199811071747.MAA13631@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: minor inconsistency in arch doc (maybe) In-Reply-To: Your message of "Fri, 06 Nov 1998 15:31:26 PST." <364386CE.FDA818A@redcreek.com> Date: Sat, 07 Nov 1998 12:47:44 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Scott" == Scott G Kelly writes: Scott> Steve, Scott> I guess I didn't really make myself clear - let me try Scott> again. First, here's a simple schematic: Scott> H1-----SGW1-------SGW2----H2 net1 net2 Scott> In SGW1, I want to apply ESP tunnel mode to IP datagrams from H1 Scott> to H2. Note that there may be other hosts on H1's net, and also Okay. Is there some policy for the other nodes at net1/net2? Is this policy on SG1, or on H1? sourceIP destIP protocol ports SA parms ==================================================================== H1's IP H2's IP * * ESP-tunnel,3DES,SHA1 SGW1's IP SGW2's IP ESP -- AH-transport,SHA1 Depending on whether you apply your policy recursively or not, this may or may not achieve double authentication. For simplicity in implementation, I would have have my GUI do the recursive application ahead of time and instantiate something more specific. Your policy may have unintended affects on packets that weren't part of the H1/H2 stream. (or it may have an effect you want) sourceIP destIP protocol ports SA parms ==================================================================== H1's IP H2's IP ESP * AH-transport,SHA1 Scott> Note the use of ESP in the protocol field. My question: does this Scott> violate the design intent of the architecture, or is the language Scott> I quoted in my earlier post a bit misleading? This tells me that H1 and H2 will establish an SA with ESP. SG1, upon seeing such packets, will add an AH to it. This is different from what you wrote above, inner tunnel in the second case will terminate at H1/H2 instead of at SG1/SG2. :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNkSHv9iXVu0RiA21AQH03wL8Dx5gHpSNcFhJIQNeMsgKL7jDX4/D5pEx pOdLISw3gYyf5uYEeRQ4ltH0dY0FjnzFN7rWGDN071cTqBCyQCqmdEbI7pMtmrjs T3Xe3VaztCeKqjIsSCI+VH7OnB24YVgH =24U8 -----END PGP SIGNATURE----- From owner-ipsec Sat Nov 7 12:58:58 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA03142 for ipsec-outgoing; Sat, 7 Nov 1998 12:58:49 -0500 (EST) Message-Id: <199811071817.NAA13692@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: IBM VPN Bakeoff Issues In-Reply-To: Your message of "Fri, 06 Nov 1998 17:18:49 PST." <36439FF9.AC2E9D60@redcreek.com> Date: Sat, 07 Nov 1998 13:17:23 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Scott" == Scott G Kelly writes: >> What was agreed to back then was that for a _security gateway_, any >> transit traffic MUST be in tunnel mode so that in IP AH ESP IP >> both AH and ESP would be in tunnel mode. Steve Kent noted that this is >> not required by the Arch Doc (but I guess it's not forbidden >> either). So if that's the way a security gateway negotiates it why >> would we want to do something different for an end host? Aren't these >> things complicated enough? Scott> I *just* received this one, else I would have addressed it in my Scott> last post on this topic. I guess I understand your issue here: the Scott> architecture doc says that SGWs must use tunnel mode unless they Scott> are terminating the flow, and you don't think the SGW is doing Scott> that. I think it is. It's terminating the ESP tunnel, so it's okay Scott> to use transport mode AH on that flow. I think you are mincing words to say the same thing, but I realize that this is relevant to IKE: Dan says: IP1 AH ESP IP2 AH - tunnel mode ESP- tunnel mode Which I would understand to mean: IP1 AH IP2 ESP IP3 But, if IP1 is identical to IP2, there is really no point in putting them both there. However, I think this heuristic is not specified anywhere, and it is a bit more complicated than that due to the unique processing of AH headers. (tell me if I'm wrong) Scott says that we should describe this sequence as: AH - transport mode for ESP SG1/SG2 ESP- tunnel mode for IP2 Which more directly translates into the desired pattern. Scott> This cuts across the earlier thread here about whether ESP/AH are Scott> suitable protocols for the 'transport protocol' selector Scott> designation. I guess at this point I'd argue that ESP *is* a Scott> transport protocol, while AH might more likely be simply an IP Scott> extension header, like IP options. If we grant that ESP is a I think this is a good characterization. Scott> I recognize that this is a bit of a twisted web here, but I think Scott> you're asking that we agree on a convention which is Scott> unnecessary. Waddayathink? Some agreement is necessary, as it is necessary that IKE have a clear order for presenting transforms in a proposals: inner->outer or outer->inner. :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNkSOsdiXVu0RiA21AQHRLAL/Y2W8A2a4eRZuMHti7rHkUunyDuLIGqNP 69qxn2wuUAYGG5yassITrc+1fPV+U4+B5AsmEW4mRNGkEHnhZHboCYhed3LokFeb in4yPljsM1AIopVpUf3NC859GVTiOiFl =hQwK -----END PGP SIGNATURE----- From owner-ipsec Sat Nov 7 20:52:33 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA04406 for ipsec-outgoing; Sat, 7 Nov 1998 20:46:54 -0500 (EST) From: "Jeff Carr" To: "Daniel Harkins" , "'IPsec'" Subject: IKE Quick Mode Date: Sat, 7 Nov 1998 18:05:39 -0800 Message-ID: <000001be0abc$48ea5a00$17b4a8c0@pc-jcarr.broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-reply-to: <199811070229.SAA00471@chip.cisco.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk I am not clear on the intent of IKE Quick Mode, when ISAKMP is acting as a client negotiator on behalf of another party. In this model described in IKE , the client identities are included in the Identification Payload used in the Quick Mode messages. I understand that the Responder is the guardian of local policy and will establish the SA necessary or allowed for the two clients. The client negotiator, Initiator, is acting on behalf of the two clients to set the SA and to acquire key material. Question -- What assumptions are being made wrt to the subsequent use of this information --- within compliance of IKE? Since only the Initiator and the Responder have the common ISKAMP SA for generating the keying material --- is this intended as an SA between the Initiator and Responder in support of the needs of the clients? ----- or is the Quick Mode information sent back to the clients? From owner-ipsec Sun Nov 8 12:22:54 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA05649 for ipsec-outgoing; Sun, 8 Nov 1998 12:08:54 -0500 (EST) Message-Id: <199811081727.MAA17644@istari.sandelman.ottawa.on.ca> Prev-Resent: Sun, 08 Nov 1998 12:27:11 -0500 Prev-Resent: "ipsec@tis.com " To: Daniel Harkins CC: "Scott G. Kelly" Subject: Re: transform tunnel/transport attributes In-Reply-To: Your message of "Sat, 07 Nov 1998 11:06:30 PST." <199811071906.LAA11898@chip.cisco.com> Date: Sat, 07 Nov 1998 18:51:08 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Daniel" == Daniel Harkins writes: Daniel> So when traffic from a1 to b1 hits SG1 it will send a single Daniel> Quick Mode with a1 and b1 as client IDs. This single Quick Mode Daniel> will specify ESP in tunnel mode. Then when the ESP packet tries Daniel> to go out it will trigger another Quick Mode with SG1 and SG2 as Daniel> client IDs and the protocol field as 50 and specify AH in Daniel> transport mode. Then when traffic from a2 to b2 hits SG1 it will Daniel> trigger yet another Quick Mode for ESP between a2 and b2, in Daniel> tunnel mode. When that ESP packet, protecting a2 and b2, hits the Daniel> output interface it will just use the existing AH SA to protect Daniel> it. Daniel> But the two cases are specifying different policy and are Daniel> negotiated differently. I think that this is significant, and I hadn't realized it. The two policies *are* different because one creates two AH SPIs and the other produces one. While that may not be that exciting for this case, if you swap the AH and ESP, then what you have is per-flow authentication with a single better resistance to traffic analysis by merging flows. [of course, the really paranoid (and rich), do per-flow ESP w/auth, merging into a single ESP flow] Daniel> I really don't want to see case 1 invalidated because the next Daniel> protocol field in the AH packet is ESP and not IPinIP and is Daniel> therefore, *technically*, transport mode. Although one can argue Daniel> that since the AH is protecting the transient traffic and not Daniel> just all ESP between SG1 and SG2 (as is the 2nd) that it truely Daniel> is tunnel mode. It's a pointless arguement since each side is Daniel> right. Given that there's running code that implements case 1 I Daniel> really don't want to open that case up to interpretation Daniel> again. Maybe we just need to clarify the two cases. I think that you just did. Now, how can this be clearly and cleanly described in IKE exchanges? I think we need to add IKE details to this. What would you expect/send for each case? :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNkTc69iXVu0RiA21AQE2igL+PDkv2cQilgz6r0fQ4kmfG8jZ9eL1Et2T IsSm5HSIwfA1NMIalI6ks7QVZBtY/T9SspFwqMB8gzSckxIYBtDgG12dhn1NJdlq UlJi/gPIQP/3epVNptJ5bpfgQ+3y09gw =fEX/ -----END PGP SIGNATURE----- From owner-ipsec Sun Nov 8 12:22:55 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA05648 for ipsec-outgoing; Sun, 8 Nov 1998 12:08:53 -0500 (EST) Message-Id: <199811081726.MAA17633@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: transform tunnel/transport attributes Date: Sun, 08 Nov 1998 12:26:54 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk [Reposted with permission] From: Daniel Harkins To: "Michael C. Richardson" cc: "Scott G. Kelly" Subject: transform tunnel/transport attributes Date: Sat, 07 Nov 1998 11:06:30 -0800 I think there are 2 different parsings and meanings of the following: [ip][ah][esp][whatever] The way it was discussed back in June was that if you have policy that says you must do AH&ESP to protect whatever then they're both in tunnel mode. Your minds can imagine much better than I can ASCII draw so imagine SGA and SGB as security gateways protecting netA and netB respectively. On each network is a bunch of other boxes a1...an, and b1...bn. So SG1 and SG2 can have policy (lets assume they were configured identically for simplicity) that says: a1 to b1 do ESP(3DES w/no auth) AND AH(HMAC-SHA) also a2 to b2 do ESP(CAST w/no auth) AND AH(HMAC-MD5) When traffic from a1 to b1 hits SG1 it will send a single Quick Mode with a1 and b1 as client IDs. This single Quick Mode will specify ESP&AH, both in tunnel mode since they're protecting transient traffic. When traffic from a2 to b2 hits SG1 it will respond with another single Quick Mode that also specifies ESP&AH, again both in tunnel mode. But there's another way of thinking about it. My policy could say a1 to b1 do ESP(3DES w/any auth including null) also a2 to b2 do ESP(CAST w/any auth including null) also ESP traffic from SG1 to SG2 do AH(HMAC-SHA) So when traffic from a1 to b1 hits SG1 it will send a single Quick Mode with a1 and b1 as client IDs. This single Quick Mode will specify ESP in tunnel mode. Then when the ESP packet tries to go out it will trigger another Quick Mode with SG1 and SG2 as client IDs and the protocol field as 50 and specify AH in transport mode. Then when traffic from a2 to b2 hits SG1 it will trigger yet another Quick Mode for ESP between a2 and b2, in tunnel mode. When that ESP packet, protecting a2 and b2, hits the output interface it will just use the existing AH SA to protect it. In either case the packets flowing between SG1 and SG2 look like this: ip ah esp ip But the two cases are specifying different policy and are negotiated differently. The encapsulation attribute is not the only thing shared by the offers in case 1. PFS and lifetime would be shared too. The SAs which were created as a bundle would die as a bundle and be keyed as a bundle. But in case 2 the AH SAs could exist even if all the ESP SAs died and went away and the ESP SAs could have PFS while the AH ones don't or they could have different groups. I really don't want to see case 1 invalidated because the next protocol field in the AH packet is ESP and not IPinIP and is therefore, *technically*, transport mode. Although one can argue that since the AH is protecting the transient traffic and not just all ESP between SG1 and SG2 (as is the 2nd) that it truely is tunnel mode. It's a pointless arguement since each side is right. Given that there's running code that implements case 1 I really don't want to open that case up to interpretation again. Maybe we just need to clarify the two cases. Dan. From owner-ipsec Sun Nov 8 12:22:54 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA05658 for ipsec-outgoing; Sun, 8 Nov 1998 12:09:54 -0500 (EST) Date: Sun, 8 Nov 1998 12:28:15 -0500 (EST) From: "Michael C. Richardson" Message-Id: <199811081728.MAA17657@istari.sandelman.ottawa.on.ca> Prev-Resent: Sun, 08 Nov 1998 12:28:14 -0500 Prev-Resent: "ipsec@tis.com " Replied: Sun, 08 Nov 1998 00:19:32 -0500 Replied: "Daniel Harkins " Sender: owner-ipsec@ex.tis.com Precedence: bulk >From dharkins@cisco.com Sat Nov 7 21: 42:49 1998 Return-Path: Received: from chip.cisco.com (chip.cisco.com [171.69.63.39]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id VAA29139 for ; Sat, 7 Nov 1998 21:42:47 -0500 (EST) Received: from localhost (dharkins@localhost) by chip.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id SAA16982; Sat, 7 Nov 1998 18:42:26 -0800 (PST) Message-Id: <199811080242.SAA16982@chip.cisco.com> To: "Michael C. Richardson" cc: "Scott G. Kelly" Subject: Re: transform tunnel/transport attributes In-reply-to: Your message of "Sat, 07 Nov 1998 18:51:08 EST." <199811072351.SAA13986@istari.sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <16980.910492946.1@cisco.com> Date: Sat, 07 Nov 1998 18:42:26 -0800 From: Daniel Harkins X-Filtered-By: NoCeM-E v0.6 (http://www.novia.net/~doumakes) Resent-To: ipsec@tis.com Resent-Date: Sun, 08 Nov 1998 12:28:14 -0500 Resent-From: "Michael C. Richardson" On Sat, 07 Nov 1998 18:51:08 EST you wrote > > >>>>> "Daniel" == Daniel Harkins writes: > Daniel> So when traffic from a1 to b1 hits SG1 it will send a single > Daniel> Quick Mode with a1 and b1 as client IDs. This single Quick Mode > Daniel> will specify ESP in tunnel mode. Then when the ESP packet tries > Daniel> to go out it will trigger another Quick Mode with SG1 and SG2 as > Daniel> client IDs and the protocol field as 50 and specify AH in > Daniel> transport mode. Then when traffic from a2 to b2 hits SG1 it will > Daniel> trigger yet another Quick Mode for ESP between a2 and b2, in > Daniel> tunnel mode. When that ESP packet, protecting a2 and b2, hits the > Daniel> output interface it will just use the existing AH SA to protect > Daniel> it. > > Daniel> But the two cases are specifying different policy and are > Daniel> negotiated differently. > > I think that this is significant, and I hadn't realized it. > The two policies *are* different because one creates two AH SPIs and the > other produces one. While that may not be that exciting for this case, if you > swap the AH and ESP, then what you have is per-flow authentication with > a single better resistance to traffic analysis by merging flows. > [of course, the really paranoid (and rich), do per-flow ESP w/auth, merging > into a single ESP flow] I think you just made a good case for doing IPSec transport followed by IPSec tunnel. I hadn't thought of that and was only bringing this up to show that that case is different that the other one. But regardles of the utility the processing is different. If the ESP&AH are a bundle they are both operated in a single go-round through your SAPD check and process. If they're separate then I think a fully-formed IP packet has to be reconstructed after the AH transport mode processing and then that packet, which is now an authenticated ESP packet between SG1 and SG2, is reinserted back into the flow path for another SAPD check and then separate processing to decapsulate the inner IP datagram. To me these are two different things and not just two different ways of expressing the same thing. > Daniel> I really don't want to see case 1 invalidated because the next > Daniel> protocol field in the AH packet is ESP and not IPinIP and is > Daniel> therefore, *technically*, transport mode. Although one can argue > Daniel> that since the AH is protecting the transient traffic and not > Daniel> just all ESP between SG1 and SG2 (as is the 2nd) that it truely > Daniel> is tunnel mode. It's a pointless arguement since each side is > Daniel> right. Given that there's running code that implements case 1 I > Daniel> really don't want to open that case up to interpretation > Daniel> again. Maybe we just need to clarify the two cases. > > I think that you just did. Now, how can this be clearly and cleanly > described in IKE exchanges? I think we need to add IKE details to this. What > would you expect/send for each case? Did what? Invalidate case 1 or open it up to re-interpretation? You just gave a good example of why someone would want to do case 2. I still think case 1 has merit. In any event, this is what an IKE offer for case 1 would look like in my hypothetical network (IDxx=addr/protocol/port): SA, [proposal 1: ESP(3DES, no auth)] [proposal 1: AH(HMAC-SHA)], IDci=a1/0/0, IDcr=b1/0/0 then SA, [proposal 1: ESP(CAST, no auth)] [proposal 1: AH(HMAC-MD5)], IDci=a2/0/0, IDcr=b2/0/0 So packets in this case would be: [IP, SG1 to SG2] [AH:HMAC-SHA] [ESP:3DES, noauth] [IP, a1 to b1] and [IP, SG1 to SG2] [AH:HMAC-MD5] [ESP:CAST, noauth] [IP, a2 to b2] Whereas in case 2 it's: SA, [proposal 1: ESP(3DES, whatever auth)], IDci=a1/0/0, IDcr=b1/0/0 then SA, [proposal 1: ESP(CAST, whatever auth)], IDci=a2/0/0, IDcr=b2/0/0 then SA, [proposal 1: AH(HMAC-SHA)], IDci=SG1/50/0, IDcr=SG2/50/0 So packets in this case would be: [IP, SG1 to SG2] [AH:HMAC-SHA] [ESP:3DES, whateverauth] [IP, a1 to b1] and [IP, SG1 to SG2] [AH:HMAC-SHA] [ESP:CAST, whateverauth] [IP, a2 to b2] The same AH SA is used for all ESP traffic between SG1 and SG2 in this case. The packets construction looks identical but they're constructed and processed differently. For instance additional policy in case 1 could specify ESP w/HMAC-SHA for traffic between a3 and b3. Then traffic between a1 and b1, and a2 and b2, would be AH&ESP protected while that from a3 to b3 would just be ESP protected. But if this additional rule is added in case 2 the traffic from a3 to b3 is ESP protected but that packet is further protected by AH. Does this make sense? Dan. From owner-ipsec Sun Nov 8 17:48:07 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA06046 for ipsec-outgoing; Sun, 8 Nov 1998 17:42:50 -0500 (EST) Message-Id: <199811082301.SAA17829@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: transform tunnel/transport attributes In-Reply-To: Your message of "Sat, 07 Nov 1998 18:42:26 PST." <199811080242.SAA16982@chip.cisco.com> Date: Sun, 08 Nov 1998 18:01:28 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Daniel" == Daniel Harkins writes: Daniel> But regardles of the utility the processing is different. If the I agree. Daniel> AH transport mode processing and then that packet, which is now Daniel> an authenticated ESP packet between SG1 and SG2, is reinserted This operation of reinsertation is not something that I think very many people have implemented. Can we have a show of hands as to who thinks they might be able to handle such an operation? Remember that this is not a MUST, so don't feel badly saying no. Daniel> right. Given that there's running code that implements case 1 I Daniel> really don't want to open that case up to interpretation Daniel> again. Maybe we just need to clarify the two cases. >> I think that you just did. Now, how can this be clearly and cleanly >> described in IKE exchanges? I think we need to add IKE details to >> this. What would you expect/send for each case? Daniel> Did what? Invalidate case 1 or open it up to re-interpretation? Daniel> You just gave a good example of why someone would want to do case Daniel> 2. I still think case 1 has merit. I think they both have merit, seeing as they are in fact different, and you have described a way to negotiate them as different things. Do we get any agreement here that what Dan describes is how one would negotiate AH&ESP? [while you might not want to support AH&ESP, you might want to support AH&IPComp] :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNkYixtiXVu0RiA21AQEHXQL9GFDpUtfB8ytV2MzH+8mQ0zaOj5s6hpLn MwBKgtaIagTiJkipAx+TgoklU5r8Aba7ORAD0nQGaQuoyBOdZxnWTihI4pJ4uFbd c9qXuddITHZ7mhwi1ICi8CuN051jwHRc =6Un+ -----END PGP SIGNATURE----- From owner-ipsec Sun Nov 8 17:54:33 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA06069 for ipsec-outgoing; Sun, 8 Nov 1998 17:51:50 -0500 (EST) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199811082306.PAA21452@kc.livingston.com> Subject: Re: Comments on draft-ietf-ipsec-pki-req-01.txt To: kent@bbn.com (Stephen Kent) Date: Sun, 8 Nov 1998 15:06:09 -0800 (PST) Cc: suresh@livingston.com, rodney@unitran.com, ipsec@tis.com In-Reply-To: from "Stephen Kent" at Nov 4, 98 06:46:26 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, Thanks for your responses. My comments below. > > Pyda , > > > > >1. Certificate verification storage requirements > > > > In section 2.2, you say the IPsec device MUST support at least 8 > > signing certificates. Is the requirement necessary? Either you > > know to verify the signature or you dont. How does the number 8 > > help? > > It's not that simple. This aspect of the proposal focuses on how many root > CAs are supported. One might reduce this to one with appropriate use of > locally generated cross certs, but for now this represents an easy way for > folks to think about how to support multiple top level CAs. How does mandating support for a minimum of 8 root CAs help an IKE node in being able to validate a certificate signature chain? I dont understand the logic here. > > > Also, I believe, you neednt make the assumption that the IPSec > > device (that supports IKE) MUST do the signature verification by > > itself. It might take recourse of a CA to do the signature > > verification. Then, it becomes the head-ache of the CA to verify > > the entire certificate chain. > > I disagree. Adding another component to the system creates another failure > point. IPsec is a realtime communication security technology that ought to > minimize its dependence on additional servers, etc., so as to reduce the > likelihood that a DoS attack on these servers can deny service for the > users of IPsec. This is one of the motivations for IKE to support exchange > of certs and CRLs. > Signature verification is an independent process. I dont see why you should mandate that this be an integral part of IKE. Vendors will have to make that choice. FYI, Many remote access systems (not based on IPsec) today use an external authentication mechanism. They dont have large disk space and would rather keep the authentication intelligence in a secure, stand-alone device. > >2. EKU field requirement > > > > In section 3.1.1, you state that an EKU entry MUST be set to > > IKEEnd or IKEIntermidate. Later on, in section 3.4.3, you say > > this field should be validated, if present. Likewise, in section > > 4.3 you make requirement for this field, a SHOULD. Clearly, these > > seem like inconsistencies in the draft. > > > > Personally, I dont see a reason for requiring this. > > Why should you have to create a cert just for IPsec? Are you > > saying that a certificate created otherwise (for use originally > > in non-IPsec applications) may not be valid for use by IPsec in > > some circumstances? How so? > > Certs for use with IPsec ought to match the name spaces in which we perform > access control, since the primary use of authentication here is as an input > to access control. Thus certs with IP addresses, DNS names, and RFC 822 > names are especially appropriate. This may well mean that certs are > specific to an application like IPsec, though that is not necessarily true. I think we are in agreement here. Certs may be specific to IPsec. But, that is not necessarily a requirement. > Also, certs in IKE are used only for auth, not key exchange, > non-repudiation, etc., which may mean that the key usage fields would be > inconsistent with other apps. > Well, I dont see why EKU field should be made mandatory. What does it matter whether the EKU field is IKEEnd or IKEIntermediate. The IPsec SA attributes (phase II) identify whether the encapsulation mode to be tunnel mode or a transport mode. Why should this have to be verified as part of ISAKMP authentication? > >3. SubjectAltName field requirement. > > > > In section 3.1.1, you say this is a MUST. Section 3.4.3 states this > > as a MAY. Section 4.0 (first paragraph) states this field as a > > required field for IPsec. Section 4.2 states that a Certificate > > request SHOULD contain this field. Once again, inconsistencies in > > the requirement terminology. > > > > Personally, I think, this is a SHOULD requirement, not a MUST. > > Here's why. > > > > An IKE initiator should be able to obtain peer's IP address from the > > certificate, in order to initiate a session. Clealry, SubjectAltName > > field in the cert (with an IP address value) is a requirement here. > > Sometimes ID forms other than an Ip address are appropriate, depending on > context. For example, an IP address may not be very useful as a means to > identify a mobile user who has been assigned a temporary address. > That is why the mobile user contacts the edge router and not the other way around, I believe. Can you give me an example where an IKE initiator does not need to know the peer's IP address, no matter what type of ID is used to identify the peer? > > On the other hand, IKE responder needs to verify its peers's ID > > by retrieving a certificate of the peer and validating its authenticity. > > This time, however, the requirement is simply for a certificate that > > mateches the peer's ID. If the peer's ID happened to be an X.500 DN, > > which is the SubjectNAme of Certificate, thats all that is needed. > > Nothing else is required in SubjectAltName field. > > Both peers want to verify the others' ID. Not sure why you state this in > an aysmmetric fashion. IPsec is not a client/server protocol, like SSL. > Well, IDs of the peers neednt be of the same type. IKE initiator could identify itself with X.500 DN, whereas IKE responder could identify itself with an IP address. Right? The only requirement is that the policy that triggers the IKE initiator to initiate a session with IKE peer ought to be based on an ID of the peer that translates itself into an IP address. Otherwise, the initiator would not be able to contact the peer with just it's ID. > > In other words, IKE initiator requires the peer's Cert to contain > > SubjctAltName (peer's IP address, really), whereas the responder > > does not require this always. > > > >5. SubjectAltName values > > > > In Section 4.1.2, you state that this field should contain exactly > > one of IP address or DNS-Name or RFC-822 name. What is the problem > > in assigning multiple of these values? You will need to assign > > multiple values, many times. Example: a FQDN-name and an IP address, > > possibly multiple IP addresses. > > It becomes confusing when we have multiple altnames in a cert, e.g., when > dealing with name constraints. why would we need to assign multiple IP > addresses in a single cert? a router has multiple addresses, but it can > have one cert per interface; certs can be cheap in this context. if we can > keep this simple for now, let's do it. > I dont see the need for mandating that SubjectAltName be assigned a single value. Why do you say that issuing multiple certs, one for each interface of a node makes it simpler? Isnt it simpler and more flexible to allow assigning multiple SubjectAltName values? What is the complexity you are concerned about? > > Also, you state that the DNS-name and RFC-822 names must be checked > > for their validity. Who should do this? Is this the PKI service > > provider who is issuing the Certificate? If so, are you suggesting > > that a secure-DNS and/or Spam-detection techniques are requirements > > for the CA? > > It is always the responsibility of a CA to verify ANY name form it puts in > certificate. But, is that the context of this requirement? I don't have > the doc in front of me right now. > I agree with your first sentence. Section 3.3 states that this is a requirement for certificate validation entity. Section 4.1.2 doesnt explicitly state who should do the checking. But, I interpreted this to mean that the author is refering to the Certtificate issuing authority (i.e., CA) here. In any case, if the author is mandating secure-DNS and anti-spam techniques on the CA or the verification entity, I would like to see these or other alternate techniques stated explicitly. > >6. Retrieval of a Certificate from PKI service provider > > (Section 3.2) > > > > There is no recommendation of a protocol or an automated > > means to retrieve certificates from CA. Also, Is there is a way to > > request a CA to validate a certificate signature chain? > > CA's do not normally perform this service; it is not part of the definition > of a CA. However, I would suggest that retrieval should specifiy the use > of PKIX cert management protocols, if we can wait for these to be finalized. > I would suggest including certificate signature chain validation as a required task for a CA. It should be rather straight forward for a CA to do this. > >7. Definition of "IPsec Usage Certificate" > > > > In section 4.3, your definition of "IPsec Usage certificate" mandates > > a public key component in a certificate. Are you saying certificates > > are not an appropriate infrastructure for PSK based IKE authentication? > > In a PSK based authentication, IKE responder might try to authenticate > > initiator's ID, by contacting a CA to obtain initiator's certificate. > > However, only a pre-shared key (not a public key) is required in the > > certificate. > > What? I was assuming that we were talking about X.509 certs here, since > this is an IETF standards activity and for now, the only cert types being > standardized by the IETF are X.509 (SPKI having passed on). X.509 certs > contain public keys, if they contain keys at all (X.509 attribute certs are > linked to public key certs and the former do not contain keys). > I guess, what I am saying is that the authentication databases used for PSK cannot be based on X.509 certificates. > Steve > cheers, suresh From owner-ipsec Sun Nov 8 22:29:10 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id WAA06563 for ipsec-outgoing; Sun, 8 Nov 1998 22:22:47 -0500 (EST) Message-Id: <199811090237.VAA13179@2gn.com> X-Sender: rodney@module-one.tillerman.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Sun, 08 Nov 1998 22:38:17 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: Fwd: Re: Comments on draft-ietf-ipsec-pki-req-01.txt Cc: rodney@tillerman.nu, suresh@livingston.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk (I'm adding comments to the various points here, perhaps we should split this as the conversation continues...) >From: suresh@livingston.com (Pyda Srisuresh) >How does mandating support for a minimum of 8 root CAs help an IKE node >in being able to validate a certificate signature chain? I dont >understand the logic here. The '8 roots' number came from a desire to declare we should be building implementations that support more than one root. I chose 8 because it seemed like a reasonable number (at least two public PKI service providers, at least two internal CA's, double it for expansion gives 8.) As an additional effect, if you mandate the implementation be able to support at leat 8 signing certificates (they don't actually have to all be roots, i.e. the tops of hierarchies), then you will have enough (space for signing certs) to handle chains of that length. In other words, if you only allow one root, you'll never be able to handle any chains. >Signature verification is an independent process. I dont see why you >should mandate that this be an integral part of IKE. Vendors will have >to make that choice. I believe the intent of the requirement is that the IKE component be able to believe the signature is valid. If the IKE component does the crypto operations itself, that is easy. If local crypto assistance devices, such as the kind that provide signature checking capabilities, then that's still "within the IKE component" for protocol purposes. Once you go to some other component you introduce yet another protocol exchange, in some sense, and I don't think we want to go there... > >FYI, Many remote access systems (not based on IPsec) today use an external >authentication mechanism. They dont have large disk space and would rather >keep the authentication intelligence in a secure, stand-alone device. > >> >2. EKU field requirement >> (from Steve Kent...) >> Certs for use with IPsec ought to match the name spaces in which we perform >> access control, since the primary use of authentication here is as an input >> to access control. Thus certs with IP addresses, DNS names, and RFC 822 >> names are especially appropriate. This may well mean that certs are >> specific to an application like IPsec, though that is not necessarily true. > >I think we are in agreement here. Certs may be specific to IPsec. But, >that is not necessarily a requirement. The idea of the EKU was that it was present, but not necessarily the ONLY EKU OID present. So it would identify the cert as being valid for IPSec. Marking the cert as valid for other things (TLS, S/MIME, etc.) is certainly intended to be allowed in the format. > >> Also, certs in IKE are used only for auth, not key exchange, >> non-repudiation, etc., which may mean that the key usage fields would be >> inconsistent with other apps. >> > >Well, I dont see why EKU field should be made mandatory. What does it >matter whether the EKU field is IKEEnd or IKEIntermediate. The IPsec >SA attributes (phase II) identify whether the encapsulation mode to >be tunnel mode or a transport mode. Why should this have to be verified >as part of ISAKMP authentication? The idea of the EKU was that the certificate would indicate whether or not the IPSec device had been 'certified' to be used as an intermediate node. After all, it has the role of translating encrypted data into clear-text data. At the gathering in Binghampton some people didn't like this, 'because that's policy and we're not supposed to put policy in the cert' (I'm assuming the advocates of this viewpoint are listening) The point here is that the certificate can be used to indicate that this device is supposed to be doing IPSec. You don't want your notebook PC masquerading as a router just because it has a cert that allows it to do IPSec. > >> >3. SubjectAltName field requirement. >> > >> > In section 3.1.1, you say this is a MUST. Section 3.4.3 states this >> > as a MAY. Section 4.0 (first paragraph) states this field as a >> > required field for IPsec. Section 4.2 states that a Certificate >> > request SHOULD contain this field. Once again, inconsistencies in >> > the requirement terminology. >> > >> > Personally, I think, this is a SHOULD requirement, not a MUST. >> > Here's why. >> > >> > An IKE initiator should be able to obtain peer's IP address from the >> > certificate, in order to initiate a session. Clealry, SubjectAltName >> > field in the cert (with an IP address value) is a requirement here. >> >> Sometimes ID forms other than an Ip address are appropriate, depending on >> context. For example, an IP address may not be very useful as a means to >> identify a mobile user who has been assigned a temporary address. >> > >That is why the mobile user contacts the edge router and not the other >way around, I believe. Can you give me an example where an IKE initiator >does not need to know the peer's IP address, no matter what type of ID >is used to identify the peer? DHCP. Wandering users who change ISP's as they move from City to City. >The only requirement is that the policy that triggers the IKE initiator >to initiate a session with IKE peer ought to be based on an ID of the peer >that translates itself into an IP address. Otherwise, the initiator >would not be able to contact the peer with just it's ID. Eh? I thought the requirement was that the IKE peers have to exchange ID's that are acceptable to the other side. So if I want to send an ID with a Distinguished Name to the other side, and the other side is willing to accept that, it's fine. No IP address checking required. > >> > In other words, IKE initiator requires the peer's Cert to contain >> > SubjctAltName (peer's IP address, really), whereas the responder >> > does not require this always. The responder's cert has to contain some identification information that is acceptable to the initiator. That may or may not be IP address. >> > >> >5. SubjectAltName values >> > >> > In Section 4.1.2, you state that this field should contain exactly >> > one of IP address or DNS-Name or RFC-822 name. What is the problem >> > in assigning multiple of these values? You will need to assign >> > multiple values, many times. Example: a FQDN-name and an IP address, >> > possibly multiple IP addresses. >> >> It becomes confusing when we have multiple altnames in a cert, e.g., when >> dealing with name constraints. why would we need to assign multiple IP >> addresses in a single cert? a router has multiple addresses, but it can >> have one cert per interface; certs can be cheap in this context. if we can >> keep this simple for now, let's do it. I personally find multiple altnames in a cert to be rather ugly. If I have a huge router with 32 interfaces, I'd rather have one IP address (or DNS name, or DN) be used as the identity of that device. BUT, the device having 32 certs (or 3200) and using different certs under different circumstances seems completely valid to me. I think we have to allow the idea of one cert with 32 IP addresses in the subjectAltName field, to handle the case where the key pair identity is really to be bound to all 32 of those addresses as a set. >> > >I dont see the need for mandating that SubjectAltName be assigned a >single value. Why do you say that issuing multiple certs, one for each >interface of a node makes it simpler? Isnt it simpler and more flexible >to allow assigning multiple SubjectAltName values? What is the complexity >you are concerned about? Parsing certs is a massive pain in the (implementation.) Adding more fields to the cert makes it more complicated, and I don't think it adds value. Processing multiple (simpler) certs seems like a better idea to me. Other people have other views. That's why both styles of formats are allowed. We already have people complaining about how much code it takes to parse these things in embedded devices. >> > Also, you state that the DNS-name and RFC-822 names must be checked >> > for their validity. Who should do this? Is this the PKI service >> > provider who is issuing the Certificate? If so, are you suggesting >> > that a secure-DNS and/or Spam-detection techniques are requirements >> > for the CA? >> >> It is always the responsibility of a CA to verify ANY name form it puts in >> certificate. But, is that the context of this requirement? I don't have >> the doc in front of me right now. >> > >I agree with your first sentence. > >Section 3.3 states that this is a requirement for certificate validation >entity. Section 4.1.2 doesnt explicitly state who should do the checking. >But, I interpreted this to mean that the author is refering to the >Certtificate issuing authority (i.e., CA) here. > >In any case, if the author is mandating secure-DNS and anti-spam >techniques on the CA or the verification entity, I would like to see >these or other alternate techniques stated explicitly. I pulled this out of later drafts. I don't agree, but many people told me they didn't like the idea of having to check these things. Allowing someone to specify a bogus DNS name, or, a name that isn't really associated with the proper person, didn't seem right to me, but the rough consensus is that this should not be mandated. > >> >6. Retrieval of a Certificate from PKI service provider >> > (Section 3.2) >> > >> > There is no recommendation of a protocol or an automated >> > means to retrieve certificates from CA. Also, Is there is a way to >> > request a CA to validate a certificate signature chain? >> >> CA's do not normally perform this service; it is not part of the definition >> of a CA. However, I would suggest that retrieval should specifiy the use >> of PKIX cert management protocols, if we can wait for these to be finalized. I point out I used the term "PKI Service Provider". This may well be some entity that provides PKIX protocols, such as OCSP, for certificate validity checking. It might be a CA, it might be something (more) than a CA. >I would suggest including certificate signature chain validation as >a required task for a CA. It should be rather straight forward for >a CA to do this. Why should the CA do this? >> >7. Definition of "IPsec Usage Certificate" >> > >> > In section 4.3, your definition of "IPsec Usage certificate" mandates >> > a public key component in a certificate. Are you saying certificates >> > are not an appropriate infrastructure for PSK based IKE authentication? >> > In a PSK based authentication, IKE responder might try to authenticate >> > initiator's ID, by contacting a CA to obtain initiator's certificate. >> > However, only a pre-shared key (not a public key) is required in the >> > certificate. >> >> What? I was assuming that we were talking about X.509 certs here, since >> this is an IETF standards activity and for now, the only cert types being >> standardized by the IETF are X.509 (SPKI having passed on). X.509 certs >> contain public keys, if they contain keys at all (X.509 attribute certs are >> linked to public key certs and the former do not contain keys). It's _NOT_ X.509. It's PKIX. X.509 is a fascinating CCITT/ITU template. We're not doing this in the ITU, we're doing this in the IETF. Pre-shared key (I assume PSK=Pre-shared key, our baroque way of saying "passwords") doesn't use certificates of any form. From owner-ipsec Sun Nov 8 22:29:10 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id WAA06557 for ipsec-outgoing; Sun, 8 Nov 1998 22:21:48 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <3643904B.279FDAB3@redcreek.com> References: Date: Sun, 8 Nov 1998 16:35:14 -0500 To: "Scott G. Kelly" From: Stephen Kent Subject: Re: IBM VPN Bakeoff Issues Cc: Stephen Waters , Tim Jenkins , ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Scott, >> > 2) The encapsulation mode of all services offered MUST match that >> >encapsulation mode of the bundle as a whole. >> >> Well, remember that a bundle can apply to traffic terminating at two >> different endpoints, specifically the required combination of a tunnel SA >> to an SG with a transport SA to a host behind the SG. > >Precisely. And what about ESP in tunnel mode, wrapped with AH in >transport mode between 2 SGs? Transport mode is used between two IP processing endpoints, mot intetrmediate processing points, so one would not use AH in transport mode between two SGs, and thus the combination you descibe is not valid, under the current architecture. Remember, the differences between tunnel and transport mode affect the checking performed on IP headers, not just the question of what is the next protocol field. When AH is used in transport mode, the IP header it encapsulates is the one checked against the SPD. Is that really what you want here? >I recognize all too well how these restrictions would simplify >processing, but don't think that makes for a good reason to modify the >spec. I'm not talking about modifying the spec. I'm reminding people of why we restricted the number of MUST support cases, and observing that when one ventures outside of this realm, interoperability is likely to suffer greatly. In an effort to get these documents out the door, we were implored by a set of implementaors to simplify previous versions of the architecture document which had called for supporting iterated nesting of SAs. steve From owner-ipsec Sun Nov 8 23:03:50 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id XAA06649 for ipsec-outgoing; Sun, 8 Nov 1998 23:00:50 -0500 (EST) Message-Id: <199811090419.XAA21186@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: IBM VPN Bakeoff Issues In-Reply-To: Your message of "Sun, 08 Nov 1998 16:35:14 EST." Date: Sun, 08 Nov 1998 23:19:22 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Stephen" == Stephen Kent writes: Stephen> I'm not talking about modifying the spec. I'm reminding people Stephen> of why we restricted the number of MUST support cases, and Stephen> observing that when one ventures outside of this realm, Stephen> interoperability is likely to suffer greatly. In an effort to Stephen> get these documents out the door, we were implored by a set of Stephen> implementaors to simplify previous versions of the architecture Stephen> document which had called for supporting iterated nesting of Stephen> SAs. This is all well and good, and is fine. Some people want to go beyond the MUSTs (and/or have customers who want them to), and this is good. The architecture is explicitely extendible. The problem is that some people, having read the MUSTs, assume that this is all that is possible, and therefore want to interpret two unequal proposals for non-MUSTs processing as being the same as something that is a MUST. :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. From owner-ipsec Mon Nov 9 05:44:18 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id FAA07533 for ipsec-outgoing; Mon, 9 Nov 1998 05:40:47 -0500 (EST) Message-ID: <250F9C8DEB9ED011A14D08002BE4F64C02155FEF@wade.reo.dec.com> From: Stephen Waters To: "Michael C. Richardson" Cc: ipsec@tis.com Subject: RE: transform tunnel/transport attributes Date: Mon, 9 Nov 1998 10:43:26 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk Does something as 'simple' as this work then: "For ANDed propotals, the 'mode' MUST be the same, and the protocol headers applied MUST be applied adjacent to each other. If multiple proposals are required to protect a packet, and they are to be applied in different modes, this is achieved by using multiple Phase-2 negotiations". Steve. -----Original Message----- From: Michael C. Richardson [mailto:mcr@sandelman.ottawa.on.ca] Sent: Saturday, November 07, 1998 11:51 PM To: Daniel Harkins Cc: Scott G. Kelly Subject: Re: transform tunnel/transport attributes -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Daniel" == Daniel Harkins writes: Daniel> So when traffic from a1 to b1 hits SG1 it will send a single Daniel> Quick Mode with a1 and b1 as client IDs. This single Quick Mode Daniel> will specify ESP in tunnel mode. Then when the ESP packet tries Daniel> to go out it will trigger another Quick Mode with SG1 and SG2 as Daniel> client IDs and the protocol field as 50 and specify AH in Daniel> transport mode. Then when traffic from a2 to b2 hits SG1 it will Daniel> trigger yet another Quick Mode for ESP between a2 and b2, in Daniel> tunnel mode. When that ESP packet, protecting a2 and b2, hits the Daniel> output interface it will just use the existing AH SA to protect Daniel> it. Daniel> But the two cases are specifying different policy and are Daniel> negotiated differently. I think that this is significant, and I hadn't realized it. The two policies *are* different because one creates two AH SPIs and the other produces one. While that may not be that exciting for this case, if you swap the AH and ESP, then what you have is per-flow authentication with a single better resistance to traffic analysis by merging flows. [of course, the really paranoid (and rich), do per-flow ESP w/auth, merging into a single ESP flow] Daniel> I really don't want to see case 1 invalidated because the next Daniel> protocol field in the AH packet is ESP and not IPinIP and is Daniel> therefore, *technically*, transport mode. Although one can argue Daniel> that since the AH is protecting the transient traffic and not Daniel> just all ESP between SG1 and SG2 (as is the 2nd) that it truely Daniel> is tunnel mode. It's a pointless arguement since each side is Daniel> right. Given that there's running code that implements case 1 I Daniel> really don't want to open that case up to interpretation Daniel> again. Maybe we just need to clarify the two cases. I think that you just did. Now, how can this be clearly and cleanly described in IKE exchanges? I think we need to add IKE details to this. What would you expect/send for each case? :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNkTc69iXVu0RiA21AQE2igL+PDkv2cQilgz6r0fQ4kmfG8jZ9eL1Et2T IsSm5HSIwfA1NMIalI6ks7QVZBtY/T9SspFwqMB8gzSckxIYBtDgG12dhn1NJdlq UlJi/gPIQP/3epVNptJ5bpfgQ+3y09gw =fEX/ -----END PGP SIGNATURE----- From owner-ipsec Mon Nov 9 06:29:33 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id GAA07665 for ipsec-outgoing; Mon, 9 Nov 1998 06:27:46 -0500 (EST) Message-Id: <199811091146.GAA24619@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: transform tunnel/transport attributes In-Reply-To: Your message of "Mon, 09 Nov 1998 10:43:26 GMT." <250F9C8DEB9ED011A14D08002BE4F64C02155FEF@wade.reo.dec.com> Date: Mon, 09 Nov 1998 06:46:41 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Stephen" == Stephen Waters writes: Stephen> "For ANDed propotals, the 'mode' MUST be the same, and the Stephen> protocol headers applied MUST be applied adjacent to each other. Stephen> If multiple proposals are required to protect a packet, and they Stephen> are to be applied in different modes, this is achieved by using Stephen> multiple Phase-2 negotiations". The only thing missing is whether the proposals that are in the same mode are to be applied inside-out, or outside-in: "For ANDed proposals, the 'mode' MUST be the same, and the protocol headers applied MUST be applied adjacent to each other. The first proposal describes the inner-most (first on encryption/authentication/compression, last on decryption/checking/decompression) transform to be applied, with the last proposal describing the outer most transform. If multiple proposals are required to protect a packet, and they are to be applied in different modes, this is achieved by using multiple Phase-2 negotiations, the applicability/order of them to be determined the selectors used." :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. From owner-ipsec Mon Nov 9 08:18:46 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA07997 for ipsec-outgoing; Mon, 9 Nov 1998 08:16:46 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF523A12@exchange> From: Tim Jenkins To: "Michael C. Richardson" , ipsec@tis.com Subject: RE: transform tunnel/transport attributes Date: Mon, 9 Nov 1998 08:36:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk If we go this route, then we need an additional clarification in here then: that the responder to the ANDed proposal MUST NOT change the order of the ANDed proposals. I say this because we saw it happen at the interoperability workshop, and it confused the initiating implementation, since it relied on order. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Michael C. Richardson [mailto:mcr@sandelman.ottawa.on.ca] > Sent: Monday, November 09, 1998 6:47 AM > To: ipsec@tis.com > Subject: Re: transform tunnel/transport attributes > > > > >>>>> "Stephen" == Stephen Waters writes: > Stephen> "For ANDed propotals, the 'mode' MUST be the > same, and the > Stephen> protocol headers applied MUST be applied > adjacent to each other. > Stephen> If multiple proposals are required to protect a > packet, and they > Stephen> are to be applied in different modes, this is > achieved by using > Stephen> multiple Phase-2 negotiations". > > The only thing missing is whether the proposals that are in the same > mode are to be applied inside-out, or outside-in: > > "For ANDed proposals, the 'mode' MUST be the same, and the > protocol headers > applied MUST be applied adjacent to each other. The first > proposal describes > the inner-most (first on > encryption/authentication/compression, last on > decryption/checking/decompression) transform to be applied, > with the last > proposal describing the outer most transform. If multiple > proposals are > required to protect a packet, and they are to be applied in > different modes, > this is achieved by using multiple Phase-2 negotiations, the > applicability/order of them to be determined the selectors used." > > :!mcr!: | Network and security > consulting/contract programming > Michael Richardson | Firewalls, TCP/IP and Unix > administration > Personal: > http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bi o.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. From owner-ipsec Mon Nov 9 15:41:09 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA10035 for ipsec-outgoing; Mon, 9 Nov 1998 15:35:47 -0500 (EST) Message-ID: <3647569E.72AF72CC@redcreek.com> Date: Mon, 09 Nov 1998 12:54:54 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: Stephen Waters , Tim Jenkins , ipsec@tis.com Subject: Re: IBM VPN Bakeoff Issues References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Steve, Stephen Kent wrote: > > Transport mode is used between two IP processing endpoints, mot > intetrmediate processing points, so one would not use AH in transport mode > between two SGs, and thus the combination you descibe is not valid, under > the current architecture. Remember, the differences between tunnel and > transport mode affect the checking performed on IP headers, not just the > question of what is the next protocol field. When AH is used in transport > mode, the IP header it encapsulates is the one checked against the SPD. Is > that really what you want here? > As for the desired effect, why else would we apply AH to an encapsulated packet? See the related thread for the rest of the discussion on this topic. I think that given the current language, I *can* wrap an AH transport mode SA around an ESP tunnel between 2 gateways. I've tossed out the notion that ESP is a transport protocol which the SGWs terminate, meaning a transport-mode SA applied to this traffic is reasonable. I remain open to further discussion on this point, as it has important implications. > >I recognize all too well how these restrictions would simplify > >processing, but don't think that makes for a good reason to modify the > >spec. > > I'm not talking about modifying the spec. Right. That comment wasn't aimed at you, but rather at the earlier discussion about adding new protocol numbers for every SA bundle combination we can think of. Sorry, I didn't mean to muddle things. Scott From owner-ipsec Mon Nov 9 15:50:06 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA10141 for ipsec-outgoing; Mon, 9 Nov 1998 15:49:48 -0500 (EST) Message-ID: <364759CF.96489CA0@redcreek.com> Date: Mon, 09 Nov 1998 13:08:31 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Harkins CC: "Michael C. Richardson" , ipsec@tis.com Subject: Re: transform tunnel/transport attributes References: <199811071906.LAA11898@chip.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Sorry for any confusion surrounding my various posts on Friday. There is quite a lag between when messages are posted to the ipsec list and when I receive them (sometimes), and I was receiving messages from may hours prior right after each post which, had I received them sooner, would have modified my thinking. I guess my take on this after reading the various follow-ups is this: for the reasons Dan cited (same IDcx for all proposals), we need the IKE convention which Dan and others have already implemented, i.e. calling both transforms 'tunnel-mode' even though we know this is semantically incorrect. Rough consensus and running code, I believe the doc says... I also agree that language clearing up any misunderstandings might be useful, and that such language has already been proposed. I think there are couple of important things to note: this does not represent an architectural change, and does not violate the architecture doc in any way I can see. This amounts to adoption of an IKE convention which simplifies our lives a bit. Scott From owner-ipsec Mon Nov 9 15:52:54 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA10161 for ipsec-outgoing; Mon, 9 Nov 1998 15:52:48 -0500 (EST) From: avs@winner.lc.lucent.com Message-ID: <36475940.E49379E1@winner.lc.lucent.com> Date: Mon, 09 Nov 1998 16:06:08 -0500 Original-From: Sashidhar Annaluru Organization: Lucent Technologies X-Mailer: Mozilla 4.05 [en]C-EMS-1.4 (WinNT; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: A question about XAUTH Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi All, I have a question about XAUTH draft. The XUTH draft refers to "The ISAKMP Configuration Method" draft, since it is an extension to the configuration draft. Let us say we are using "Request/Reply" mechanism. Let us say that there is a client C1 and a Secure Gateway SG1. Assume that C1 is initiator of IKE phase1. Now the question: What is the normal behavior, if SG1 needs to send REQUEST after the ISAKMP SA are established? Since the C1 is the IKE initiator, does it need to initiate after the ISAKMP SAs are established? In that case how can we use "Request/Reply", requested from SG1? Can some body explain about this? Thanks in advance Sashidhar Annaluru Lucent Technologies. From owner-ipsec Mon Nov 9 16:32:25 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA10353 for ipsec-outgoing; Mon, 9 Nov 1998 16:31:47 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199811090419.XAA21186@istari.sandelman.ottawa.on.ca> References: Your message of "Sun, 08 Nov 1998 16:35:14 EST." Date: Mon, 9 Nov 1998 11:24:04 -0500 To: "Michael C. Richardson" From: Stephen Kent Subject: Re: IBM VPN Bakeoff Issues Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael, > This is all well and good, and is fine. > Some people want to go beyond the MUSTs (and/or have customers who want >them to), and this is good. The architecture is explicitely extendible. > The problem is that some people, having read the MUSTs, assume that this >is all that is possible, and therefore want to interpret two unequal >proposals for non-MUSTs processing as being the same as something that is a >MUST. Fair point. But, as we progress beyond thye "musts" we need to proceed deliberately, and not trash the architecture in a rush to accommoadte more sophisiticated combinations. After all, we settled on a limited set of MUST support combinations so that we could proceed with the standards. So far I have yet to see a client implementation that supports the nesting that is already required, and now we seem to be pushing to work out the kinks to support for more complex comibnations. Steve From owner-ipsec Mon Nov 9 17:13:56 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA10554 for ipsec-outgoing; Mon, 9 Nov 1998 17:11:48 -0500 (EST) Message-ID: <007901be0c30$a0f92a80$0100010a@irish1> From: "John Irish" To: "IPSEC" Subject: IPSEC Policy Selectors and ISAKMP Date: Mon, 9 Nov 1998 17:30:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk After spending considerable time reviewing the various IETF draft documents (i.e., [ARCH] Security Architecture for the IP, ISAKMP, and the [DOI] Internet IP Security DOI for ISAKMP), I am unable to answer the following questions and would appreciate any insight you may offer. 1. The [ARCH] specifies the various Selectors which may be used in constructing, and identifying, a policy entry to be used in establishing a Security Association (SA). I understand how the ISAKMP Initiator may examine the packet, or other available identification information, in locating the appropriate outbound policy. However, I question how the appropriate Selectors may be conveyed to the ISAKMP Responder, during a phase-2 negotiation, so that the Responder may identify the appropriate policy within its database. Neither the DOI Situation, nor Identification payloads, can convey all the Selector values known by the ISAKMP Initiator which could possibly be needed by the Responder in locating a policy entry. 2. The [DOI] defines the Identification payload which provides a single Port value and possibly an address identifier. The [DOI] does not specify the context of these Identification values for the Initiator. Do they represent the source values of the resulting inner or outer IP header? 3. Presuming the specification of an address range/subnet, within an ISAKMP Identification payload, is based upon a selected outbound policy entry, is it assumed that the ISAKMP Responder must have a corresponding policy entry for this range/subnet? What happens if the Responders inbound policy is based upon User Identification, not address? 4. Given the variety of ISAKMP Identification payloads which could be sent during SA negotiation, how does one side know what form of Identification is acceptable to the other side? Is it assumed that the exact same policy entry (based upon a set of selector values), is used by both sides? Thanks for the help! John Irish From owner-ipsec Tue Nov 10 08:46:31 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA13408 for ipsec-outgoing; Tue, 10 Nov 1998 08:35:49 -0500 (EST) X-Authentication-Warning: osf1.gmu.edu: hlin owned process doing -bs Date: Mon, 9 Nov 1998 21:26:59 -0500 (EST) From: Hua Lin To: ipsec@tis.com Subject: two questions? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, all, After reading the IKE document (draft-ietf-ipsec-isakmp-oakley-08.txt), I have the following questions. Could somebody clarify it for me? Thank you in advance! #1. It seems that I have not caught some typing conventions. There are g^xi, g^xr, and g^xy in IKE document. I just wonder what are enclosed in KE payload (ephemeral values) and what are pre-established (long term). g^xy is used to derive SKEYID and g^xi, g^xr are used to compute the HASH_I, HASH_R. #2. In IKE phase 1 Authenticated with Signatures, SIG_I and SIG_R needs to be computed and it is stated that (in Page 9) "SIG_I or SIG_R, is the result of the negotiated digital signature algorithm applied to HASH_I or HASH_R". But at the same time, a CERT is included in the message. Isn't this CERT used to verify the signature? If yes, then the algorithm used to verify the signature should be in the CERT (generally CERT will contain a field about the algorithm). How to explain this? I will greatly appreciate your time if you can clarify this! Thank you! Hua From owner-ipsec Tue Nov 10 10:21:00 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA13931 for ipsec-outgoing; Tue, 10 Nov 1998 10:17:58 -0500 (EST) X-Authentication-Warning: brahma.roc.com: ramana owned process doing -bs Date: Tue, 10 Nov 1998 18:25:27 +0530 (IST) From: Ramana Yarlagadda X-Sender: ramana@brahma.roc.com To: kent@bbn.com, ipsec@tis.com cc: svakil@vpnet.com, clynn@bbn.com, suresh@livingstone.com Subject: Re: Selection of proposals (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, can somebody guide me here, consider the case4 (in Page 27) from H2 +==================================================+ | | | +========================+ | | | | | | | | | H1* ---- (Internet) ------|SG2* ---- (Local ----- H2*| . H1 must have TWO individual IN-BOUND policies H2-SG2 and H2-H1. And let's assume that SAs are there. Since these two are indivi- dual policies I assume that there are TWO inbound SAs linked to diffrent SPD entries. Then in that case when a packet arrive at H1 from H2 which has Two SAs applied to it ONE @H2 and OTHER ONE @ SG2, if you apply the IpSec processing according to the Steps 1,2,3 and 4 specified on Page-35 in Sec-5.2.1 until Step2 there will be no problem. And at the end of the 2nd step we will have list of SAs applied. But finding an incoming policy (step3 & 4) fails here bcoz there is no single SPD entry matches the list of SAs we collected. otherwise, how will be the Inbound policy at H1 in this case? How will check the policy here? -thanks -ramana On Thu, 5 Nov 1998, Stephen Kent wrote: > Ramana, > > >In Sec4.3 Combining Security Associations(page 12) describes > >how we can bundle SAs. > > 1)Transport adjacency > > 2)Iterated tunneling > > > >And this example matches case2 (in Page 13). so now can I > >say that this is a valid cinfiguration with reference to > >draft. > > Example 2 in 4.3 shows a host with two iterated tunnels, one to a gateway, > and the other to a host. The example that triggered this message exchange > shows a gateway as the common endpoint for the two tunnels. So the two are > not exactly the same. However, I agree that the general case described in > 4.3 should encompass Rohit's example, as it is one in which one of the two > tunnel endpoints is the same. However, Section 4.5 is the authoritative > section describing what one MUST support. Section 4.3 refers to 4.5. In > 4.5, there is no hard requirement to support iterated tunnels with a common > endpoint. > > >otherwise, what's wrong with that configuration. Can we > >know why the implementors requested it that way? > > Iteration of tunnels adds considerable complexity to processing. There > appeared to be no substantive security benefit from such nesting in the > cases of primary interest, where a host formed one end of the tunnel. Note > that we do require support for the combination of one tunnel and one > transport SA involving a host, and that was deemed adequate. However, if > one wants to have iterated SAs with a gateway as the endpoint, then tunnel > mode is required for both SAs. So, the WG needs to decide if this > configuration is one that merits support. If so, we should add it to the > list of mandatory configurations, to ensure support. > > Steve > > From owner-ipsec Tue Nov 10 11:17:05 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA14158 for ipsec-outgoing; Tue, 10 Nov 1998 11:14:51 -0500 (EST) X-Authentication-Warning: brahma.roc.com: anupama owned process doing -bs Date: Tue, 10 Nov 1998 16:09:06 +0530 (IST) From: Anupama Potluri X-Sender: anupama@brahma.roc.com To: "Michael C. Richardson" cc: ipsec@tis.com Subject: Re: transform tunnel/transport attributes In-Reply-To: <199811091146.GAA24619@istari.sandelman.ottawa.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Mon, 9 Nov 1998, Michael C. Richardson wrote: > The only thing missing is whether the proposals that are in the same > mode are to be applied inside-out, or outside-in: > > "For ANDed proposals, the 'mode' MUST be the same, and the protocol headers > applied MUST be applied adjacent to each other. The first proposal describes > the inner-most (first on encryption/authentication/compression, last on > decryption/checking/decompression) transform to be applied, with the last > proposal describing the outer most transform. If multiple proposals are > required to protect a packet, and they are to be applied in different modes, > this is achieved by using multiple Phase-2 negotiations, the > applicability/order of them to be determined the selectors used." What is the order currently implemented by most implementations? If you see the second example in the ISAKMP draft on pages 49-50, the first protocol is AH and the second ESP. This seemed to indicate that the order of the protocols is outer to inner rather than inner to outer, since the supported combination is AH ESP. It seems more intuitive to interpret the order in the way it appears in a processed packet - outer to inner. Anupama From owner-ipsec Tue Nov 10 11:24:30 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA14213 for ipsec-outgoing; Tue, 10 Nov 1998 11:21:52 -0500 (EST) Message-Id: <199811101640.LAA27169@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-xauth-03.txt Date: Tue, 10 Nov 1998 11:40:39 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Extended Authentication Within ISAKMP/Oakley Author(s) : R. Pereira Filename : draft-ietf-ipsec-isakmp-xauth-03.txt Pages : 11 Date : 09-Nov-98 This document describes a method for using existing unidirectional authentication mechanisms such as RADIUS, SecurID, and OTP within IPSec's ISAKMP protocol. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-xauth-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-xauth-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-xauth-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19981109150001.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-xauth-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-xauth-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981109150001.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Nov 10 11:43:28 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA14341 for ipsec-outgoing; Tue, 10 Nov 1998 11:41:55 -0500 (EST) X-Authentication-Warning: osf1.gmu.edu: xwang4 owned process doing -bs Date: Tue, 10 Nov 1998 12:00:31 -0500 (EST) From: Xunhua Wang To: ipsec@tis.com Subject: two questions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, all, After reading the IKE document (draft-ietf-ipsec-isakmp-oakley-08.txt), I have the following questions. Could somebody clarify it for me? Thank you in advance! #1. It seems that I have not caught some typing conventions. There are g^xi, g^xr, and g^xy in IKE document. I just wonder what are enclosed in KE payload (ephemeral values) and what are pre-established (long term). g^xy is used to derive SKEYID and g^xi, g^xr are used to compute the HASH_I, HASH_R. #2. In IKE phase 1 Authenticated with Signatures, SIG_I and SIG_R needs to be computed and it is stated that (in Page 9) "SIG_I or SIG_R, is the result of the negotiated digital signature algorithm applied to HASH_I or HASH_R". But at the same time, a CERT is included in the message. Isn't this CERT used to verify the signature? If yes, then the algorithm used to verify the signature should be in the CERT (generally CERT will contain a field about the algorithm). How to explain this? I will greatly appreciate your time if you can clarify this! Thank you! Xunhua From owner-ipsec Tue Nov 10 14:32:49 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA15092 for ipsec-outgoing; Tue, 10 Nov 1998 14:28:06 -0500 (EST) Date: Tue, 10 Nov 1998 21:46:53 +0200 (EET) Message-Id: <199811101946.VAA06598@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Roy Pereira Cc: "IPSEC Mailing List (E-mail)" Subject: IBM VPN Bakeoff Issues In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF4F7C55@exchange> References: <319A1C5F94C8D11192DE00805FBBADDF4F7C55@exchange> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 47 min X-Total-Time: 58 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Roy Pereira writes: > 4. The size of SPIs in NOTIFY messages is ambiguous. Some vendors send zero > bytes while others send 16 bytes. We need to clarify the wording in the > documents. This depends on the notify messages. In status notifications that are send during Phase I negotiation along with other Phase I payloads may contain SPI size 0, but those Phase I notifications that are send after Phase I (delete, errors, initial contact sent as separate informational exchange to authenticate it etc), must have valid SPI (16 bytes, containing cookies) so the responder might find out the related ISAKMP SA. There is also some problems when sending error notifications back when using new group mode or configuration mode. For those exchanges there is no SPI field that could be used to identify the negotiation where this error message belongs. I would suggest that we add text saying that if in the notification payload the Protocol-ID is 0 (==PROTO ISAKMP) then the SPI size may be either 4 or 16. If the SPI size is 4 then the SPI field contains the MESSAGE-ID of the negotiation under the current ISAKMP SA (seen from the cookies of the packet) to whom this error/status notification belongs. If the SPI size is 16 then the SPI field contains cookies of the ISAKMP SA to whom this error/status notification belongs. This allows sending authenticated error notifications to other ISAKMP SAs than current one (for example the invalid cookie notification, which might be sent using different ISAKMP SA, because we have already deleted the ISAKMP SA the other end is trying to use). And it also allows sending errors to configuration mode and new group mode exchanges by just using the message id of those exchanges as a key. For quick modes this really isn't so much problem because we usually have SPI in the SA. Of course if we want to return error because we couldn't parse the SA proposal sent by the other host we cannot use SPI. Also if we have proposals that don't have SPI (IPCOMP?) we might want to use the message-id approach. Also because one SA proposal may contain multiple SPIs, it might be easier to use message-ids always to simplify finding the proper quick mode negotiation when notification is received (currently the SPI may be any of the SPIs inside the SA proposal). > 6. What SPI should be sent in a DELETE message? Some vendors send zero > sized SPI, some send 16 bytes of SPI. Here I think we should always send 16 bytes of SPI, because we might want to use different ISAKMP SA to send that DELETE message instead the one we are deleting. So we cannot use the initiator and responder cookies to specify the sa to be deleted. > 14. Is proposing "RC5 with 128 bit key length" the same as proposing "RC5" > since 128 bits is the default key size? Should vendor's be aware of the > default key size and equate comparable cipher/key sizes? If you mean that if the responder is allowed to remove key length attribute because it has default value, or add key length attribute with default value when sending back selected sa information, then the draft is quite clear (dratf-ietf-ipsec-isakmp-oakley-08.txt): ---------------------------------------------------------------------- for potential security associations to responders. Responders MUST NOT modify attributes of any offer, attribute encoding excepted (see Appendix A). If the initiator of an exchange notices that attribute values have changed or attributes have been added or deleted from an offer made, that response MUST be rejected. ---------------------------------------------------------------------- You are not allowed to modify the SA proposal... > 17. The HASH payload must be the first payload in a info/new group exchange. > This isn't clear in the documents. For new group mode we should just add "In New Group Mode, a HASH payload MUST immediately follow the ISAKMP header", for Informational Exchanges we also have to add something for the cases when we don't have HASH because we dont have ISAKMP SA yet. So something like "In Informational Exchanges, a HASH payload (if present) MUST immediately follow the ISAKMP header". > 20. It would be nice if Delete messages supported multiple protocols instead > of just one protocol. This is handy for deleting SA bundles. There is nothing in the draft that says each informational exchange must only contain one delete payload, so when you want to delete a SA bundle you could just send informational exchange having HDR*, HASH(1), D, D, D ... and each of those Delete payloads will delete one protocol. Hash is again calculated just like in the normal case, message id followed by the rest of the packet. > 22. We need further clarification on when Notify messages start becoming > encrypted. Some vendors start encrypting after message 4 of MainMode, some > wait until phase 1 complete. Because the IV calculation of the encrypted Notify message needs "last phases 1 CBC output block", and if that hasn't been received/sent already then we cannot calculate IV, thus we cannot use authenticated notifications. > 24. Someone pointed out that the same DH group has to be used for all > proposals when using Aggressive Mode and Quick Mode. The draft-ietf-ipsec-isakmp-oakley-08.txt says: ---------------------------------------------------------------------- Security Association negotiation is limited with Aggressive Mode. Due to message construction requirements the group in which the Diffie- Hellman exchange is performed cannot be negotiated. In addition, ---------------------------------------------------------------------- and ---------------------------------------------------------------------- All offers made during a Quick Mode are logically related and must be consistant. For example, if a KE payload is sent, the attribute describing the Diffie-Hellman group (see section 6.1 and [Pip97]) MUST be included in every transform of every proposal of every SA being negotiated. Similarly, if client identities are used, they MUST ---------------------------------------------------------------------- So I think that is already covered in the draft. > 25. Someone pointed out that the ID payload is redundant if we are doing > RSA_SIG authentication, since the certificate already has the identity. If I send you 10 certificates forming a chain, which of those is the one that contains the end user identity? The first? The second? The last? Identity payload is NOT redundant even in RSA signature authentication in case we are having more than one certificates involved. Also the certificate payloads are optional, so the other end might not send anything. > 26. We need clarification on the SPI usage in phase 1's SA payload. The > documents state it can have 0-16 bytes. The draft-ietf-ipsec-isakmp-10.txt says: ---------------------------------------------------------------------- During phase 1 negotiations, the initiator and responder cookies deter- mine 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. ---------------------------------------------------------------------- And I really think that it should be changed to allow only one choice. Either modify that to say: ---------------------------------------------------------------------- During phase 1 negotiations, the initiator and responder cookies deter- mine the ISAKMP SA. Therefore, the SPI field in the Proposal payload is redundant and its size MUST be set to 0. ---------------------------------------------------------------------- or add similar paragraph to the draft-ietf-ipsec-isakmp-oakley-08.txt draft. There is also another paragraph in the draft-ietf-ipsec-isakmp-10.txt saying (proposal payload): ---------------------------------------------------------------------- o SPI Size (1 octet) - Length in octets of the SPI as defined by the Protocol-Id. 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. If the SPI Size is not a multiple of 4 octets it will have some impact on the SPI field and the alignment of all payloads in the message. The Domain of Interpretation (DOI) will dictate the SPI Size for other protocols. ---------------------------------------------------------------------- so that should be modified accordingly. Allowing the cookie to contain anything from 0 to 16 bytes is just useless, and cause interoperability problems. Having useless choices in cases where we dont need them just adds complexity of the protocol. > 27. Vendors should be aware of different IKE version numbers. Currently > v0.1 and v1.0 are defined. The text needs to be clearer on version numbers. I sent some email about this already earlier, see that for my comments. > 31. Do we allow CertReq payloads in shared-secret mode? Yup, but you > probably don't want to reply back with a certificate. The draft-ietf-ipsec-isakmp-10.txt says: ---------------------------------------------------------------------- ing the exchange. The responder to the Certificate Request payload MUST send its certificate, if certificates are supported, based on the values contained in the payload. If multiple certificates are required, then ---------------------------------------------------------------------- so if you support certificates you MUST send it even in shared-secret mode... > 32. Should proposal rank number start with 1 or zero and should they > increase by 1 ? I would say that there is no reason to limit them to start from any specific number or to increase by 1, so I would say we should add some more clarifying text to the draft-ietf-ipsec-isakmp-10.txt. > 34. What should the maximum number of proposals be? Some vendors only > handled a limited number of proposals. I would set this to quite large (128? 256?) value, because the other end might not know before hand what kind of limited version the other end has and might want to offer all possible combinations it supports for maximal interoperability (and if the other end limits numbers of proposal to some very small number like 16, then when the initiator tried to be as interoperative as possible, caused them not to interoperate). -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Wed Nov 11 03:24:33 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id DAA17325 for ipsec-outgoing; Wed, 11 Nov 1998 03:19:07 -0500 (EST) Message-Id: <36494BF5.9FC5F0CC@radguard.com> Date: Wed, 11 Nov 1998 10:33:57 +0200 From: Sara Bitan Organization: RADGUARD X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en Mime-Version: 1.0 To: Yael Dayan , ipsec@tis.com Subject: How do IKE peers synchronize public keys ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Suppose two IKE peers want to issue an ISAKMP sa using RSA signature (or encryption) mode. The initiator has two certificates, one from CA A, and another from CA B. He now has two make a decision which public key to use for the ID message authentication. So he sends two certificate requests to the responder, one with CA A, the other with CA B. There is a hidden assumption here, taken by the initiator : if the responder sends back a certificate or a certificate chain) for a certain CA then he is ready to use a certificate (chain) issued by this CA. Assume further that the responder has certificates both from CA A and from CA B, so he sends both certificates to the initiator. The initiator now uses one of his keys (either the one certified by CA A, or the one certified by CA B) to authenticate the ID message. The responder doesn't know which key was used by the initiator (unless he checks all possibilities). I think that this scenario is possible with the current IKE/ISAKMP drafts. A possible solution might be that the responder will send always only one certificate, and this certificate will be used for the authentication. We can view that as a proposal for several certificate sent by the initiator, to which the responder answer with a single choice. The problem becomes even worse when both peers start caching their certificates. If you have several certificates you have already received from a peer, how do you know which one to use to authenticate his ID message? Thanks, Sara. From owner-ipsec Wed Nov 11 05:41:02 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id FAA17659 for ipsec-outgoing; Wed, 11 Nov 1998 05:38:00 -0500 (EST) Date: Wed, 11 Nov 1998 12:56:45 +0200 (EET) Message-Id: <199811111056.MAA14133@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Sara Bitan Cc: Yael Dayan , ipsec@tis.com Subject: How do IKE peers synchronize public keys ? In-Reply-To: <36494BF5.9FC5F0CC@radguard.com> References: <36494BF5.9FC5F0CC@radguard.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 6 min X-Total-Time: 64 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Sara Bitan writes: > Suppose two IKE peers want to issue an ISAKMP sa using RSA signature (or > encryption) mode. > The initiator has two certificates, one from CA A, and another from CA > B. He now has two make a decision which public key to use for the ID > message authentication. > So he sends two certificate requests to the responder, one > with CA A, the other with CA B. There is a hidden assumption here, taken > by the initiator : if the responder sends back a certificate or a > certificate chain) for a certain CA then he is ready to use a > certificate (chain) issued by this CA. > > Assume further that the responder has certificates both from CA A and > from CA B, so he sends both certificates to the initiator. If the certificates both are for the same public key this is ok, and it doesn't matter which one the initiator uses. If the public key is different, then I think the responder MUST not send two end user certificates, only one. > The initiator now uses one of his keys (either the one certified by CA > A, or the one certified by CA B) to authenticate the ID message. The > responder doesn't know which key was used by the initiator (unless he > checks all possibilities). > > I think that this scenario is possible with the current IKE/ISAKMP > drafts. Yes, the current draft doesn't limit that, but implementations should... > A possible solution might be that the responder will > send always only one certificate, and this certificate will be used for > the authentication. We can view that as a proposal for several > certificate sent by the initiator, to which the responder answer with a > single choice. I would say that the IKE endpoint must only sent certificates leading to one public key, which must also match the one used in the authentication. The draft should say that IKE endpoint MUST not send end user certificates for multiple public keys. > The problem becomes even worse when both peers start caching their > certificates. If you have several certificates you have already received > from a peer, how do you know which one to use to authenticate his ID > message? -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Wed Nov 11 06:06:24 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id GAA17704 for ipsec-outgoing; Wed, 11 Nov 1998 06:05:02 -0500 (EST) Message-Id: <364972D1.36BBC2A6@radguard.com> Date: Wed, 11 Nov 1998 13:19:45 +0200 From: Sara Bitan Organization: RADGUARD X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en Mime-Version: 1.0 To: Tero Kivinen Cc: Yael Dayan , ipsec@tis.com Subject: Re: How do IKE peers synchronize public keys ? References: <36494BF5.9FC5F0CC@radguard.com> <199811111056.MAA14133@torni.ssh.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Thanks Tero, I think some wording should be added to IKE drafts, see below. Tero Kivinen wrote: > > Sara Bitan writes: > > Suppose two IKE peers want to issue an ISAKMP sa using RSA signature (or > > encryption) mode. > > The initiator has two certificates, one from CA A, and another from CA > > B. He now has two make a decision which public key to use for the ID > > message authentication. > > So he sends two certificate requests to the responder, one > > with CA A, the other with CA B. There is a hidden assumption here, taken > > by the initiator : if the responder sends back a certificate or a > > certificate chain) for a certain CA then he is ready to use a > > certificate (chain) issued by this CA. > > > > Assume further that the responder has certificates both from CA A and > > from CA B, so he sends both certificates to the initiator. > > If the certificates both are for the same public key this is ok, and > it doesn't matter which one the initiator uses. If the public key is > different, then I think the responder MUST not send two end user > certificates, only one.> > > The initiator now uses one of his keys (either the one certified by CA > > A, or the one certified by CA B) to authenticate the ID message. The > > responder doesn't know which key was used by the initiator (unless he > > checks all possibilities). > > > > I think that this scenario is possible with the current IKE/ISAKMP > > drafts. > > Yes, the current draft doesn't limit that, but implementations > should... > The limitation must come from the drafts, since as an initiator I must in this case rely on the responder's good will (i.e. not to send back two certificates from different CA for different public keys). > > A possible solution might be that the responder will > > send always only one certificate, and this certificate will be used for > > the authentication. We can view that as a proposal for several > > certificate sent by the initiator, to which the responder answer with a > > single choice. > > I would say that the IKE endpoint must only sent certificates leading > to one public key, which must also match the one used in the > authentication. The draft should say that IKE endpoint MUST not send > end user certificates for multiple public keys. > > > The problem becomes even worse when both peers start caching their > > certificates. If you have several certificates you have already received > > from a peer, how do you know which one to use to authenticate his ID > > message? > -- > kivinen@iki.fi Work : +358-9-4354 3218 > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Wed Nov 11 09:13:22 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA18171 for ipsec-outgoing; Wed, 11 Nov 1998 09:11:01 -0500 (EST) Message-Id: <36499E50.507954C9@radguard.com> Date: Wed, 11 Nov 1998 16:25:20 +0200 From: Sara Bitan Organization: RADGUARD X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en Mime-Version: 1.0 To: Tero Kivinen Cc: Yael Dayan , ipsec@tis.com Subject: Re: How do IKE peers synchronize public keys ? References: <36494BF5.9FC5F0CC@radguard.com> <199811111056.MAA14133@torni.ssh.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Tero Kivinen wrote: > > If the certificates both are for the same public key this is ok, and > it doesn't matter which one the initiator uses. If the public key is > different, then I think the responder MUST not send two end user > certificates, only one. > Looking at the ISAKMP draft once again it says: " The responder to the Certificate Request payload MUST send its certificate, if certificates are supported, based on the values contained in the payload. If multiple certificates are required, then multiple Certificate Request payloads SHOULD be transmitted. " The wording contradicts what we think an implementation should do.... Sara. From owner-ipsec Wed Nov 11 09:13:22 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA18155 for ipsec-outgoing; Wed, 11 Nov 1998 09:05:02 -0500 (EST) Date: Wed, 11 Nov 1998 16:23:21 +0200 (EET) From: Markku Savela Message-Id: <199811111423.QAA09775@anise.tte.vtt.fi> To: ipsec@tis.com cc: msa@anise.tte.vtt.fi In-reply-to: (message from Ramana Yarlagadda on Tue, 10 Nov 1998 18:25:27 +0530 (IST)) Subject: Bundles, policies, tunneling, ordering etc... Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@ex.tis.com Precedence: bulk > consider the case4 (in Page 27) from H2 > +==================================================+ > | | > | +========================+ | > | | | | > | | | | > H1* ---- (Internet) ------|SG2* ---- (Local ----- H2*| > . > > H1 must have TWO individual IN-BOUND policies H2-SG2 and H2-H1. Not in my world. H1 has a single policy entry mapping h1->h2 traffic into two bundle items as follows, selector H1->H2 => ESP(3des,sha1), AH(sha1,tunnel=SG2) The following long and tedious ananlysis attemps to explain my view of this and why I still don't see the reason for all this worry about ordering in the key management. The order is defined by the policies similar to above, and there is no need to make key management unnecessarily comlex by worrying about ordering. Key management should just negotiate each SA pair independently (AQ1 and AQ2 below). KISS principle. This a view from kernel IPSEC/PFKEY to the IKE/ISAKMP, what I expect the key management to achieve. The text below is rather hard to read, but I cannot find a simpler way to express the detail I want. I'm presenting it in hope of someone pointing the flaws in it, if any, because to me this appears to be a workable scenario and this is how my version of IPSEC assumes it to work. If there are flaws, I need to fix something. ---------------------------------------------------------------- Policies: Selector => Bundle @H1: H1<->H2 => ESP(3des,sha1), AH(sha1,tunnel=SG2) @SG2: local<->internet => AH(sha1) @H2: H2<->H1 => ESP(3des,sha1) ===== Setting up the SA's =========================== -- If initiator is H1, and tries to send a packet to H2 -- 1. the packet matches the h1<->h2 selector at H1, no matching SA's exist yet. 2. IPSEC sends two independent ACQUIRE requests AQ1. ACQUIRE ESP src=h1 dst=h2, proposal=(3des,sha1) AQ2. ACQUIRE AH src=h1 dst=sg2, proposal=(sha1) 3. Key management of AQ1 at h1: GETSPI ESP dst=h1 => SA1(ESP,SPI1,h1) at h2: GETSPI ESP dst=h2 => SA2(ESP,SPI2,h2) ADD SA1(3des,sha1) UPDATE SA2(3des,sha1) at h1: ADD SA2(3des,sha1) UPDATE SA1(3des,sha1) 4. Key management of AQ2 at h1: GETSPI AH dst=h1 => SA3(AH,SPI3,h1) at SG2: GETSPI AH dst=sg2 => SA4(AH,SPI4,sg2) ADD SA3(sha1) UPDATE SA4(sha1) at h1: ADD SA4(sha1) UPDATE SA3(sha1) Comment: negotiation doesn't have o care about the order of AH and ESP!! -- If initiator is H2, trying to send packet to H1 -- 1. the packet matches h2<->h1 selector at H1, no matching SA's exist yet. 2. IPSEC at h2 sends ONE ACQUIRE AQ1. ACQUIRE ESP src=h2 dst=h1, proposal=(3des,sha1) 3. Key management of AQ1 at h2: GETSPI ESP dst=h2 => SA2(ESP, SPI2, h2) at h1: GETSPI ESP dst=h1 => SA1(ESP, SPI1, h1) ADD SA2(3des,sha1) UPDATE SA1(3des,sha1) at h2: ADD SA1(3des,sha1) UPDATE SA2(3des,sha1) After this H2 is ready to send the packet, which hits SG2 1. the packet matches the local<->interent selector at SG2, no matching SA's exist yet. 2. IPSEC at sg2 sends ONE ACQUIRE AQ2. ACQUIRE AH src=sg2 dst=h1, proposal=(sha1) [?proxy=h2] 3. Key management of AQ2. at sg2: GETSPI AH dst=sg2 => SA4(AH, SPI4, sg2) at h1: GETSPI AH dst=h1 => SA3(AH, SPI3, h1) ADD SA4(sha1) UPDATE SA3(sha1) at sg2: ADD SA3(sha1) UPDATE SA4(sha1) -- In either case, the end result of SA's is -- @H1 @SG2 @H2 SA1 <------------ SA1 SA2 ------------> SA2 SA3 <---- SA3 SA4 ----> SA4 ====== Excanging IPSEC packets ========================== -- A packet from H1 to H2 -- @H1 starts with [IP h1->h2][data] 1. h1->h2 matches the SPD bundle in above, 1st bundle item matches SA2 (apply ESP) -> [IP h1->h2][ESP] 2nd bundle item specifies a tunnel, apply -> [IP h1->sg2][IP h1->h2][ESP] 2nd bundle item matches SA4 (apply AH) -> [IP h1->sg2][AH][IP h1->h2][ESP] @SG2 receives [IP h1->sg2][AH][IP h1->h2][ESP] 1. SPI of AH selects SA4, applying unwraps AH -> [IP h1->sg2][IP h1->h2][ESP] processes the IP in IP -> [IP h1->h2][ESP] 2. Policy bundle check: (h1->h2) matches the the local<->internet selector in SPD, the SA4 fits the bundle spec for incoming direction. 3. Forward [IP h1->h2][ESP] to local @H2 receives [IP h1->h2][ESP] 1. SPI of ESP selects SA2, applying unwraps ESP -> [IP h1->h2][data] 2. Policy bundle check: (h1->h2) matches the h2<->h1 selector in SPD, the SA2 fits the bundle spec for incoming direction. -- A packet from H2 to H1 -- @H2, starts with [IP h2->h1][data] 1. h2->h1 matches the SPD selector (h2<->h1) The only bundle item matches SA1 (apply ESP) -> [IP h1->h2][ESP] 2. send packet to local net (assumed that the normal routing will get it to the SG2. If that is not the case, it may need to be wrapped by a "bare" tunnel to SG2, but this is outside IPSEC) @SG2 receives [IP h2->h1][ESP] 1. h2->h1 matches the SPD selector (local<->internet) The only bundle item matches SA3, but because the source address is H2 and not SG2, it needs to add a tunnel wrapping first -> [IP sg2->h1][IP h2->h1][ESP] and after this, it can apply the AH -> [IP sg2->h1][AH][IP h2->h1][ESP] Comment: this "implicit tunnel insertion" is not explicit in documents, but it seems that a very mechanical rule can be applied before processing of AH or ESP transforms: "If the src of the IP packet is not current host, then add a tunnel wrapping [src=current host, dst=original dest]" Could also get this explicity by having a special tunnel flag in the SPD entry requesting the transformation. 2. send packet to internet (as this step didn't involve any IPSEC on receive side, no policy bundle checks are needed) @H1 receives [IP sg2->h1][AH][IP h2->h1][ESP] 1. SPI of AH selects SA3, applying unwraps AH -> [IP sg2->h1][IP h2->h1][ESP] revealing a tunnel to h1, unwrapped -> [IP h2->h1][ESP] 2. SPI of ESP selects SA1, applying unwraps ESP -> [IP h2->h1][data] 3. Policy bundle check: h2->h1 matches the SPD entry with two bundle items, the first should match SA1 (ESP) and second should match SA3 (AH), can also check that the original src at AH step matches the tunnel in bundle (SG2). ------------- Comments? -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec Wed Nov 11 09:29:28 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA18289 for ipsec-outgoing; Wed, 11 Nov 1998 09:28:01 -0500 (EST) Message-Id: <199811111446.JAA00792@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-intragkm-00.txt Date: Wed, 11 Nov 1998 09:46:19 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Intra-Domain Group Key Management Protocol Author(s) : T. Hardjono, B. Cain, I. Monga Filename : draft-ietf-ipsec-intragkm-00.txt Pages : 31 Date : 10-Nov-98 This document describes a protocol for intra-domain group key management for IP multicast security, based on the framework of [HCD98]. In order to support multicast groups, the domain is divided into a number of administratively-scoped 'areas'. A host-member of a multicast group is defined to reside within one (and only one) of these areas. The purpose of placing host-members in areas is to achieve flexible and efficient key management, particularly in the face of the problem of changes (joining, leaving, ejections) in the membership of a multicast group. A separate administratively-scoped area control-group is defined for each (data) multicast group, for the express purpose of key management and other control-message delivery. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-intragkm-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-intragkm-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-intragkm-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19981110163121.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-intragkm-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-intragkm-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981110163121.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Nov 11 10:05:43 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA18603 for ipsec-outgoing; Wed, 11 Nov 1998 10:04:01 -0500 (EST) Date: Wed, 11 Nov 1998 17:22:33 +0200 (EET) Message-Id: <199811111522.RAA20080@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Sara Bitan Cc: Yael Dayan , ipsec@tis.com Subject: Re: How do IKE peers synchronize public keys ? In-Reply-To: <36499E50.507954C9@radguard.com> References: <36494BF5.9FC5F0CC@radguard.com> <199811111056.MAA14133@torni.ssh.fi> <36499E50.507954C9@radguard.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 3 min X-Total-Time: 2 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Sara Bitan writes: > > If the certificates both are for the same public key this is ok, and > > it doesn't matter which one the initiator uses. If the public key is > > different, then I think the responder MUST not send two end user > > certificates, only one. > Looking at the ISAKMP draft once again it says: > " The responder to the Certificate Request payload MUST > send its certificate, if certificates are supported, based on the values > contained in the payload. If multiple certificates are required, then > multiple Certificate Request payloads SHOULD be transmitted. " > > The wording contradicts what we think an implementation should do.... Yes, I agree that the current draft says so, but I think the IKE draft should say that we are not allowed to send multiple end user certificates which have different public key. Also the paragraph above doesn't take in account that even if we support certificates it might be possible that we do not have certificate for that CA, so I think that MUST is just too strong. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Wed Nov 11 10:41:33 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA18736 for ipsec-outgoing; Wed, 11 Nov 1998 10:38:05 -0500 (EST) Message-Id: <3.0.5.32.19981111105444.00b12100@cpcug.org> X-Sender: jaubert@cpcug.org (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 11 Nov 1998 10:54:44 -0500 To: ipsec@tis.com From: Jack Aubert Subject: SAD and SPD Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I am trying to research the current state of play with respect to management of large VPNs using IPsec. Imagine a very large VPN with many worldwide SG tunnel entry points using IPsec -- say at least one per country...on the order of 200. Also assume that it is necessary to add, subtract, ore reconfigue any of these devices from one point. "One point" could literally mean one point, or (with appropriate access control) from any one of the 200 points. Reading the current architecture draft, my impression is that the SAD will carry information on SAs that a particular device (in this case a SG) participates in, and would probably be kept close to -- presumably on -- the SG itself. The SPD, on the other hand, would aggregate and summarize policies, and could be kept/coordinated more centrally queried by the devices needing to set up an SA using LDAP. The participating devices would still need to authenticate themselves -- e.g. using either preloaded or aircraft-netted certificates and a CA -- but with the SPD handled centrally, management of the devices could be carried out with a high degree of aggregation. The SPD could consist of 200 rules to allow SAs to be established all-to-all using a list of 200 diverse registered IP addresses, or even a single rule allowing SA establishment within all of a registered class C subnet where each address is advertised separately to the Internet from its remote location. Is this a correct reading of the current drafts, and does it seem to make any sense? From owner-ipsec Wed Nov 11 13:14:44 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA19295 for ipsec-outgoing; Wed, 11 Nov 1998 13:12:02 -0500 (EST) Message-ID: <3649D7DE.CA75F18F@redcreek.com> Date: Wed, 11 Nov 1998 10:30:54 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jack Aubert CC: ipsec@tis.com Subject: Re: SAD and SPD References: <3.0.5.32.19981111105444.00b12100@cpcug.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Jack Aubert wrote: > > I am trying to research the current state of play with respect to > management of large VPNs using IPsec. > > Imagine a very large VPN with many worldwide SG tunnel entry points using > IPsec -- say at least one per country...on the order of 200. Also assume > that it is necessary to add, subtract, ore reconfigue any of these devices > from one point. "One point" could literally mean one point, or (with > appropriate access control) from any one of the 200 points. > > Reading the current architecture draft, my impression is that the SAD will > carry information on SAs that a particular device (in this case a SG) > participates in, and would probably be kept close to -- presumably on -- > the SG itself. The SPD, on the other hand, would aggregate and summarize > policies, and could be kept/coordinated more centrally queried by the > devices needing to set up an SA using LDAP. > Is this a correct reading of the current drafts, and does it seem to make > any sense? Yes, the master SPD could be centrally managed, and queried using any number of mechanisms (not just LDAP), or the entries could be distributed rather then requested, using SNMP or other mechanisms. However, it would be quite inefficient to *always* query it, since the ARCH (rfc?) requires that the SPD be consulted on a per-packet basis. Might be better to distribute all applicable policies to the querying system at one time, and then have some algorithm for maintaining cache coherence. Obviously, it's conceivable that the number of applicable policies for a given SGW could exceed its cache size, in which case we're back to your original proposal. However, this could be viewed as a resource allocation problem for the SGW rather than an architectural issue, and in any event, the SGW will need to cache the SPD entries which produced the active SAs in some form or another. From owner-ipsec Wed Nov 11 13:38:33 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA19397 for ipsec-outgoing; Wed, 11 Nov 1998 13:37:02 -0500 (EST) Message-Id: <199811111854.KAA28637@chip.cisco.com> To: Anupama Potluri cc: "Michael C. Richardson" , ipsec@tis.com Subject: Re: transform tunnel/transport attributes In-reply-to: Your message of "Tue, 10 Nov 1998 16:09:06 +0530." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28632.910810473.1@cisco.com> Date: Wed, 11 Nov 1998 10:54:33 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk The order of offer in IKE shouldn't matter. If they're negotiated in a bundle we do PCP before ESP before AH regardless of how they appear in the offered bundle. If you negotiated ESP to protect AH traffic between SGs (for traffic analysis protection for instance) and that AH traffic protected some transient traffic to which PCP was also applied you could get |IP|ESP|AH|PCP|IP|data| crossing the wire but then it's two separate negotiations and the bundle is AH&PCP and you still do PCP before AH. Dan. On Tue, 10 Nov 1998 16:09:06 +0530 you wrote > > On Mon, 9 Nov 1998, Michael C. Richardson wrote: > > > The only thing missing is whether the proposals that are in the same > > mode are to be applied inside-out, or outside-in: > > > > "For ANDed proposals, the 'mode' MUST be the same, and the protocol header >s > > applied MUST be applied adjacent to each other. The first proposal describe >s > > the inner-most (first on encryption/authentication/compression, last on > > decryption/checking/decompression) transform to be applied, with the last > > proposal describing the outer most transform. If multiple proposals are > > required to protect a packet, and they are to be applied in different modes >, > > this is achieved by using multiple Phase-2 negotiations, the > > applicability/order of them to be determined the selectors used." > > What is the order currently implemented by most implementations? If you > see the second example in the ISAKMP draft on pages 49-50, the first > protocol is AH and the second ESP. This seemed to indicate that the order > of the protocols is outer to inner rather than inner to outer, since the > supported combination is AH ESP. It seems more intuitive to interpret the > order in the way it appears in a processed packet - outer to inner. > > Anupama From owner-ipsec Thu Nov 12 05:24:34 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id FAA22004 for ipsec-outgoing; Thu, 12 Nov 1998 05:20:01 -0500 (EST) Date: Thu, 12 Nov 1998 12:38:11 +0200 (EET) From: Markku Savela Message-Id: <199811121038.MAA10719@anise.tte.vtt.fi> To: ipsec@tis.com cc: msa@anise.tte.vtt.fi In-reply-to: <199811111423.QAA09775@anise.tte.vtt.fi> (message from Markku Savela on Wed, 11 Nov 1998 16:23:21 +0200 (EET)) Subject: Re: Bundles, policies, tunneling, ordering etc... Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@ex.tis.com Precedence: bulk "Michael C. Richardson" wondered privately if the reason I don't have any ordering requirements at the IKE level, is that I only have one transform at other end. The example chosen is represents fairly complex situation, and adding more transforms between h1-sg2 or h1-h2 would still not change the basic idea. However, to demonstrate, I will collapse my example into case where for some odd reason sg2==h2, the picture simplifies into +============================+ | | | +========================+ | | | | | | | | | H1* ---- (Internet) ------|SG2* --- (local) --- H3* Might be seen as situation to occur when a remote admin wants to configure the SG2, or some general service happens to be on the SG2. I'm leaving in the tunnels. Thus, the 'h1' side processing doesn't change at all at IPSEC level. The change may affect key management, if it wants to *optimize* the negotiation when it notices that H2==SG2, by doing it with single exchange instead of two independent exchanges. I think the policies below start to approach a real life situation where a client is on the road, and needs to connect to the company network. Identification of the client cannot be based on IP address, but on something that it gets from the policy definition via ACQUIRE (for example, one could configure some user name as Identity into the policy to be passed in ACQUIRE), or it could be just something that the client key management knows from the environment (current user of the portable). ---------------------------------------------------------------- Policies: Selector => Bundle @H1: H1<->local => ESP(3des,sha1), AH(sha1,tunnel=SG2) @SG2: SG2<->internet => ESP(3des,sha1), AH(sha1,tunnel=H1) local<->internet => AH(sha1) @H3: H2<->H1 => ESP(3des,sha1) Comment:H3 is left as an example to remind that this new configuration is just an extension of my previous example. In above, it is assumed tha 'local', in addition to H3, matches also 'SG2', to simplify the policy. ===== Setting up the SA's =========================== -- If initiator is H1, and tries to send a packet to SG2 -- 1. the packet matches the h1<->local selector at H1, no matching SA's exist yet. 2. IPSEC sends two independent ACQUIRE requests AQ1. ACQUIRE ESP src=h1 dst=sg2, proposal=(3des,sha1) AQ2. ACQUIRE AH src=h1 dst=sg2, proposal=(sha1) 3. Key management of AQ1 at h1: GETSPI ESP dst=h1 => SA1(ESP,SPI1,h1) at sg2: GETSPI ESP dst=sg2 => SA2(ESP,SPI2,sg2) ADD SA1(3des,sha1) UPDATE SA2(3des,sha1) at h1: ADD SA2(3des,sha1) UPDATE SA1(3des,sha1) 4. Key management of AQ2 at h1: GETSPI AH dst=h1 => SA3(AH,SPI3,h1) at sg2: GETSPI AH dst=sg2 => SA4(AH,SPI4,sg2) ADD SA3(sha1) UPDATE SA4(sha1) at h1: ADD SA4(sha1) UPDATE SA3(sha1) Comment: negotiation doesn't have o care about the order of AH and ESP!! -- If initiator is SG2, trying to send packet to H1 -- 1. the packet matches sg2<->internet selector at H1, no matching SA's exist yet. 2. IPSEC at sg2 sends two independent ACQUIRE requests AQ1. ACQUIRE ESP src=sg2 dst=h1, proposal=(3des,sha1) AQ2. ACQUIRE AH src=sg2 dst=h1, proposal=(sha1) 3. Key management of AQ1 at sg2: GETSPI ESP dst=sg2 => SA2(ESP, SPI2, sg2) at h1: GETSPI ESP dst=h1 => SA1(ESP, SPI1, h1) ADD SA2(3des,sha1) UPDATE SA1(3des,sha1) at sg2: ADD SA1(3des,sha1) UPDATE SA2(3des,sha1) 2. Key management of AQ2 at sg2: GETSPI AH dst=sg2 => SA4(AH, SPI4, sg2) at h1: GETSPI AH dst=h1 => SA3(AH, SPI3, h1) ADD SA4(sha1) UPDATE SA3(sha1) at sg2: ADD SA3(sha1) UPDATE SA4(sha1) -- In either case, the end result of SA's is -- @H1 @SG2 SA1 <---- SA1 SA2 ----> SA2 SA3 <---- SA3 SA4 ----> SA4 ====== Excanging IPSEC packets ========================== -- A packet from H1 to SG2 -- @H1 starts with [IP h1->sg2][data] 1. h1->sg2 matches the SPD bundle in above, 1st bundle item matches SA2 (apply ESP) -> [IP h1->sg2][ESP] 2nd bundle item specifies a tunnel, apply -> [IP h1->sg2][IP h1->sg2][ESP] 2nd bundle item matches SA4 (apply AH) -> [IP h1->sg2][AH][IP h1->sg2][ESP] @SG2 receives [IP h1->sg2][AH][IP h1->sg2][ESP] 1. SPI of AH selects SA4, applying unwraps AH -> [IP h1->sg2][IP h1->sg2][ESP] processes the IP in IP, and finds it for me again -> [IP h1->sg2][ESP] 2. SPI of ESP selects SA2, applying unwraps ESP -> [IP h1->sg2][data] 3. Policy bundle check: h1->sg2 matches the SPD entry with two bundle items, the first should match SA2 (ESP) and second should match SA4 (AH) -- A packet from SG2 to H1 -- @SG2, starts with [IP sg2->h1][data] 1. sg2->h1 matches the SPD selector (sg2<->h1) 1st bundle item matches SA1 (apply ESP) -> [IP sg2->h1][ESP] 2nd bundle item specifies a tunnel, apply first -> [IP sg2->h1][IP sg2->h1][ESP] 2nd bundle item matches SA3 (apply AH) -> [IP sg2->h1][AH][IP sg2->h1][ESP] @H1 receives [IP sg2->h1][AH][IP sg2->h1][ESP] 1. SPI of AH selects SA3, applying unwraps AH -> [IP sg2->h1][IP sg2->h1][ESP] revealing a tunnel to h1, unwrapped -> [IP sg2->h1][ESP] 2. SPI of ESP selects SA1, applying unwraps ESP -> [IP sg2->h1][data] 3. Policy bundle check: sg2->h1 matches the SPD entry with two bundle items, the first should match SA1 (ESP) and second should match SA3 (AH), can also check that the original src at AH step matches the tunnel in bundle (sg2). ------------- -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec Thu Nov 12 10:27:16 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA23062 for ipsec-outgoing; Thu, 12 Nov 1998 10:19:00 -0500 (EST) Message-Id: <199811121537.KAA11647@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-mib-02.txt Date: Thu, 12 Nov 1998 10:37:28 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IPSec Monitoring MIB Author(s) : T. Jenkins Filename : draft-ietf-ipsec-mib-02.txt Pages : 58 Date : 11-Nov-98 This document defines monitoring and status MIBs for IPSec. It does not define MIBs that may be used for configuring IPSec implementations or for providing low-level diagnostic or debugging information. Further, it does not provide policy information. Those MIBs may be defined in later versions of this document or in other documents. The purpose of the MIBs is to allow system administrators to determine operating conditions and perform system operational level monitoring of the IPSec portion of their network. Statistics are provided as well. The IPSec MIB definitions use a virtual tunnel model, of which there can be configured permanent tunnels or transient tunnels. The virtual tunnel model is used to allow the use of IPSec from a virtual private networking (VPN) point of view. This allows users of IPSec based products to get similar monitoring and statistical information from an IPSec based VPN as they would from a VPN based on other technologies, such as Frame Relay. Finally, the objects defined perhaps represent a somewhat simplified view of security associations. This is done for the purposes of expediency and for simplification of presentation. Also, some information about SAs has been intentionally left out to reduce the security risk if SNMP traffic becomes compromised. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-mib-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-mib-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-mib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19981111144131.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981111144131.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu Nov 12 14:46:59 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA24476 for ipsec-outgoing; Thu, 12 Nov 1998 14:44:04 -0500 (EST) Date: Thu, 12 Nov 1998 14:44:04 -0500 (EST) From: owner-ipsec@ex.tis.com Message-Id: <199811121944.OAA24476@portal.ex.tis.com> [192.94.214.100]) by portal.ex.tis.com (8.9.1/8.9.1) with ESMTP id OAA24429 for ; Thu, 12 Nov 1998 14:39:01 -0500 (EST) (EST) (EST) (4.1) id xma021401; Thu, 12 Nov 98 15:04:14 -0500 5.0.1460.8) id WS9ZKV3Z; Thu, 12 Nov 1998 14:37:00 -0500 5.0.1460.8) id WP0Y58GN; Thu, 12 Nov 1998 14:36:39 -0500 Message-ID: <364B38C5.890B4271@americasm01.nt.com> Date: Thu, 12 Nov 1998 14:36:38 -0500 From: "Amal Maalouf" Organization: Nortel X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: ipsec@tis.com Subject: IKE questions. Content-Type: multipart/alternative; boundary="------------D0EE2DDA8EB57A6F4C2E0A0A" Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk --------------D0EE2DDA8EB57A6F4C2E0A0A Content-type: text/plain; charset="us-ascii" I have few questions/clarifications on the IKE draft (draft-ietf-ipsec-isakmp-oakley-08.txt): 1. It is not clear from the document how authentication using public keys or the variant to public keys provide authentication (in the sense that both peers are sure that they are talking to themselves and not to a man-in-the-middle) When using public keys authentication it is not clear what HASH_I and HASH_R use as keys. Section 5 states: For public key encryption: SKEYID = prf(hash(Ni_b | Nr_b), CKY-I |CKY-R) For authentication with digital signatures, HASH_I and HASH_R are signed and verified; for authentication with either public key encryption or pre-shared keys, HASH_I and HASH_R directly authenticate the exchange. "hash" in the above formula is not defined anywhere else so I am assuming its the hash algorithm that the two peers negotiated in the SA payload so far, but the clause "HASH_I and HASH_R directly authenticate the exchange" gives the impression that some kind of secret only known to the two peers that ensures to one peer that the other is indeed who he claims he is, is being used as a key. (I am assuming that the "hash" function is using a symmetric key - please correct me if that's not the case). Since the only shared key between the two peers at this stage is the Diffie-Hellman one then how is authentication achieved? Even Section 5.2 states: Using encryption for authentication provides for a plausably deniable exchange. There is no proof (as with a digital signature) that the conversation ever took place since each party can completely reconstruct both sides of the exchange. By the way, don't see how the "variant of public key" method is correcting this either. I am sure I am missing something, so please let me know what I've overlooked. 2. Cert-I_b is not defined anywhere in the document but is used in the variant public key Phase 1 exchanges. What is its use in this exchange and why is it optional? 3. Client negotiation seems pretty vague or incomplete. By reading the archives of this list, the ID payload in Phase 2 has been a subject of many discussions. >From the archives there is mention of dynamically adding SPD entries based on these ID payload contents, but nowhere in the drafts (IKE or the others) was I able to find mention of that. Could you please point me to where this is defined? The only way Client negotiation made sense to me is to not to have to have an IKE engine on all hosts/gateways, but have some other IKE server/gateway do that negotiation on the client's behalf. If that's the case, then how does the client pass his intent to the IKE server/gateway that it wants negotiation to be done on its behalf? and how does the IKE server/gateway communicate the negotiated SA (protocol SA in this case) back to the client, so that the client may use it in its secure communication? Are these configurable? Please point me to where these are defined or indicated to be outside the scope of the IPsec protocol suite. Thanks. -- Amal Maalouf Nortel Networks Tel: (613) 765-5649 Fax: (613) 765-2186 e-mail: amalmaal@nortel.ca From owner-ipsec Thu Nov 12 17:15:29 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA25143 for ipsec-outgoing; Thu, 12 Nov 1998 17:14:09 -0500 (EST) Date: Thu, 12 Nov 1998 17:33:06 -0500 Message-Id: <199811122233.RAA21729@brill.shiva.com> From: John Shriver To: ipsec@tis.com Subject: first comments on draft-ietf-ipsec-mib-02.txt (no ifIndex/ifEntry) Sender: owner-ipsec@ex.tis.com Precedence: bulk My first comment applies to section 4.1 of the document, which states: It should be noted that the MIBs here are not extensions of the Tunnel MIB [IPTun] or the Interface Group MIB [IGMIB]. That approach was rejected for a number of reasons, including: [...] o The virtual tunnels created by IPSec SAs are independent of other logical interfaces. This document takes the point of view that IPSec sits on top of IP. This perspective is used since IPSec adds additional protocol headers before the IP header. In this case, it may be conceptually viewed as a layer 4 protocol from the IP layer point of view. As such, the handling of IPSec secured packets by IP is independent of how IP is routed over the physical or logical layer 2 interfaces. That particular mapping is part of the purpose of the Tunnel MIB, and thus has no direct relationship on the IPSec virtual tunnels. This point is not true. Both RFC 1354 and RFC 2096 are not implementable if there is not an ifTable entry (ifEntry), and ifIndex value, for each "VPN" tunnel. The reason is that the variables (RFC 1354): ipForwardIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The ifIndex value which identifies the local interface through which the next hop of this route should be reached." DEFVAL { 0 } ::= { ipForwardEntry 5 } and (RFC 2096): ipCidrRouteIfIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The ifIndex value which identifies the local interface through which the next hop of this route should be reached." DEFVAL { 0 } ::= { ipCidrRouteEntry 5 } have pointers to "interfaces" (real or virtual) indicated by ifIndex values. I certainly expect that we expect to run OSPF or RIPv2 over "VPN" tunnel interfaces. From the point of view of those protocols, and the IP forwarder, the tunnels are very much interfaces. (Yes, they are recursively on top of IP. But they are still virtual interfaces.) The same thing applies to L2TP, which is why I wanted that MIB oriented by ifIndex. Since [IPtun] is indexed by ifIndex, the fact that there may be many tunnels with the same IP addresses as endpoints will not cause "despair" to that MIB. I suppose another alternative is to have a table with values of InterfaceIndex syntax, but with values not found in ifTable. But, that would be rather ugly, and probably would be shot down as illegal from RFC 2233's point of view. It's really not conformant to the DESCRIPTION of InterfaceIndex. Yet another alternative would be to change the stynax of ipCidrRouteIfIndex from Integer32 to InterfaceIndexOrZero, and redefine it appropriately. But I think that would not be a legal modification to an exisint OBJECT-TYPE. Instead, it probably would have to be deprecated and replaced with a new one, which would stall that MIB's path along the Standards Track. (Thus: unlikely!) From owner-ipsec Thu Nov 12 18:52:32 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA25420 for ipsec-outgoing; Thu, 12 Nov 1998 18:51:18 -0500 (EST) Date: Fri, 13 Nov 1998 02:04:30 +0200 (EET) Message-Id: <199811130004.CAA30623@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: ipsec@tis.com CC: "Amal Maalouf" Subject: Re: IKE questions. In-Reply-To: <199811121944.OAA24476@portal.ex.tis.com> References: <199811121944.OAA24476@portal.ex.tis.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 5 min X-Total-Time: 4 min Sender: owner-ipsec@ex.tis.com Precedence: bulk owner-ipsec@ex.tis.com writes: > For public key encryption: SKEYID = prf(hash(Ni_b | Nr_b), CKY-I |CKY-R) ... > Since the only shared key between the two peers at this stage is the > Diffie-Hellman one > then how is authentication achieved? ... > I am sure I am missing something, so please let me know what I've > overlooked. The Ni and Nr are encrypted using the public key of the remote host, thus only the holder of that private key can decrypt them and calculate that SKEYID hash. > 2. Cert-I_b is not defined anywhere in the document but is used in the > variant public key > Phase 1 exchanges. What is its use in this exchange and why is it > optional? It is normal Cert payload, but encrypted using the symmetric key derived from the encrypted nonces and cookies. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Fri Nov 13 12:37:01 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA28889 for ipsec-outgoing; Fri, 13 Nov 1998 12:31:34 -0500 (EST) Message-ID: From: Ricky Charlet To: "'John Shriver'" , ipsec@tis.com Subject: RE: first comments on draft-ietf-ipsec-mib-02.txt (no ifIndex/ifE ntry) Date: Fri, 13 Nov 1998 09:47:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BE0F2D.BAF4C160" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BE0F2D.BAF4C160 Content-Type: text/plain; charset="iso-8859-1" Howdy () So the point John Shriver was making was related to MIBS and management. Are tunnels virtual interfaces or not? But the comments I make in reply could lead down a very different discussion path... that of how routing protocols treat tunnels. > > I certainly expect that we expect to run OSPF or RIPv2 over "VPN" > tunnel interfaces. From the point of view of those protocols, and the > IP forwarder, the tunnels are very much interfaces. (Yes, they are > recursively on top of IP. But they are still virtual interfaces.) > True, BUT... So has anyone out there actually succeeded in getting OSPF or RIP to recognize and communicate with neighbors across a tunnel? I fear not. This is a subtle but horrible complexity of IP in IP tunnels, that the two endpoint are NOT in the same subnet. (They must not be so that the 'cloud' can route to the two separate end points.) Neither RIP nor OSPF will recognize neighbors outside of their subnets. Ultimately this will force a cooperation who is interested in deploying VPN to either static route or BGP route to a bunch of satellite sub-Autonomous-Systems. Has anyone gotten any IGP to 'neghborize' and communicate across an IP in IP tunnel? What would it take to make that happen [protocol extensions to RIP, HELLO, IS-IS, and OSPF, or specialized route protocol recognition and proxying in IPSec]? Is it worth going down that path? My apologies to John Shriver for the diversion of attention. In fairness to his point and questions I also make this point... IPSec tunnels (SAs) are transitory in nature, they are 'up' only so long as there is traffic and re-key timers haven't popped. I don't think that O&M groups want to see 'interfaces' which come up and down with traffic load. Especially the 'interface down' trap should be something which justified an O&M worker getting a beep on the pager in the wee AM hours. ################################### # Ricky Charlet # rcharlet@RedCreek.com # (510) 795-6903 ################################### end Howdy; ------_=_NextPart_000_01BE0F2D.BAF4C160 Content-Type: application/octet-stream; name="Ricky Charlet.vcf" Content-Disposition: attachment; filename="Ricky Charlet.vcf" Content-Location: ATT-0-D7A0739D867AD211A44600805F650DF2-R ICKYC%7E1.VCF BEGIN:VCARD VERSION:2.1 N:Charlet;Ricky FN:Ricky Charlet ORG:RedCreek Communications Inc.;Engineering TITLE:Engineer ADR;WORK:;2nd Floor;3900 Newpark Mall Rd.;Newark;CA;94560;USA LABEL;WORK;ENCODING=QUOTED-PRINTABLE:2nd Floor=0D=0A3900 Newpark Mall Rd.=0D=0ANewark, CA 94560=0D=0AUSA EMAIL;PREF;INTERNET:rcharlet@redcreek.com REV:19981013T230517Z END:VCARD ------_=_NextPart_000_01BE0F2D.BAF4C160-- From owner-ipsec Fri Nov 13 13:11:11 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA29094 for ipsec-outgoing; Fri, 13 Nov 1998 13:10:40 -0500 (EST) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF816C0@RED-MSG-50> From: Richard Draves To: "'Ricky Charlet'" , "'John Shriver'" , ipsec@tis.com Subject: RE: first comments on draft-ietf-ipsec-mib-02.txt (no ifIndex/ifE ntry) Date: Fri, 13 Nov 1998 10:29:22 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk > So the point John Shriver was making was related to MIBS and > management. Are tunnels virtual interfaces or not? But the > comments I make > in reply could lead down a very different discussion path... > that of how > routing protocols treat tunnels. In our IPv6-based implementation, we are NOT treating tunnel-mode SAs as virtual interfaces. We do support tunnels (encapsulating v6-in-v4 and, soon, v6-in-v6) that ARE virtual interfaces. And because they are interfaces, they can have security policies that call for the use of IPsec, the endpoints have addresses assigned to them, they can participate in routing, etc. Rich From owner-ipsec Fri Nov 13 13:39:32 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA29236 for ipsec-outgoing; Fri, 13 Nov 1998 13:38:42 -0500 (EST) Message-Id: <199811131855.KAA03275@chip.cisco.com> To: Ricky Charlet cc: "'John Shriver'" , ipsec@tis.com Subject: Re: first comments on draft-ietf-ipsec-mib-02.txt (no ifIndex/ifE ntry) In-reply-to: Your message of "Fri, 13 Nov 1998 09:47:49 PST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3181.910983222.1@cisco.com> Date: Fri, 13 Nov 1998 10:55:50 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk On Fri, 13 Nov 1998 09:47:49 PST you wrote > > Howdy () > So the point John Shriver was making was related to MIBS and > management. Are tunnels virtual interfaces or not? Not all tunnels are created equal (at least in our implementation they're not). An IPSec "tunnel endpoint" is not a routable interface but a GRE one is. Dan. From owner-ipsec Fri Nov 13 13:46:56 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA29268 for ipsec-outgoing; Fri, 13 Nov 1998 13:46:42 -0500 (EST) Date: Fri, 13 Nov 1998 14:04:58 -0500 Message-Id: <199811131904.OAA20266@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: rcharlet@redcreek.com Cc: ipsec@tis.com Subject: RE: first comments on draft-ietf-ipsec-mib-02.txt (no ifIndex/ifE ntry) References: X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Ricky" == Ricky Charlet writes: >> I certainly expect that we expect to run OSPF or RIPv2 over "VPN" >> tunnel interfaces. From the point of view of those protocols, and >> the IP forwarder, the tunnels are very much interfaces. (Yes, >> they are recursively on top of IP. But they are still virtual >> interfaces.) >> Ricky> True, BUT... Ricky> So has anyone out there actually succeeded in getting OSPF or Ricky> RIP to recognize and communicate with neighbors across a Ricky> tunnel? Yes to both. paul From owner-ipsec Fri Nov 13 14:23:17 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA29411 for ipsec-outgoing; Fri, 13 Nov 1998 14:22:49 -0500 (EST) Date: Fri, 13 Nov 1998 14:41:32 -0500 Message-Id: <199811131941.OAA26282@brill.shiva.com> From: John Shriver To: ipsec@tis.com In-reply-to: (message from Ricky Charlet on Fri, 13 Nov 1998 09:47:49 -0800) Subject: Re: first comments on draft-ietf-ipsec-mib-02.txt (no ifIndex/ifE ntry) Sender: owner-ipsec@ex.tis.com Precedence: bulk OK, this rash of responses (glad to see the MIB finally merit discussion!) opens some interesting issues. First, I realize that I oversimplified. A Tunnel mode SA could be a virtual interface in the ifTable. On the other hand, a transport mode SA is not going to be an interface in the ifTable. However, if there is a bi-directional tunnel-mode SA, there's no reason that OSPF can't run across it. From OSPF's point of view, it's a point-to-point link (between the SA endpoint) running un-numbered (no IP addresses). Of course the OSPF packets will have to have source IP addresses, these will be the router ID of the router on each end. (The router ID has to be an address from inside the security cloud.) But, we have to consider the whole point of the Security Policy Database. If the two "security gateways" have only one SA tunnel between them, that carries all classes of traffic for all networks on each side of those SG's, then that tunnel is an interface subject to conventional routing via OSPF. But, what happens when there are different tunnels, possibly with different encryption transforms for different classes of traffic, between the two SG's? IP routes don't get that specific, they are only by IP address, but now the route is specific down to the protocol and port level. Do you group these several SA's into a single virtual interface from the point of view of routing? That's one approach, but one too implementation-specific to codify in a MIB. Perhaps we need to do the replacement for RFC 2096, which instead of having CIDR routes, has routes indexed by all the possible keys of the Security Policy Database. Meanwhile, the issue of RFC 2096 is, of course, independent from OSPF, it also has to export static routes. As for running GRE over a tunnel mode SA, that's essentially blasting a hole through the whole point of the Security Policy Database. Once it allows IP protocol 47 (GRE) through, the SPD is rendered ineffective. So, back to the MIBs. Here's my conclusions related to this batch of issues. 1. The IPsec MIB should allow a SA to be an interface, with an ifIndex value, and an ifEntry in the ifTable. But we can't require this by any means. So, it should be data in a table, with syntax InterfaceNumberOrZero. 2. We could have a simple table that sparesely augments ifTable (or more particularly, augments tunnelIfTable) for those SA tunnels that are interfaces. It probably doesn't need any data other than a pointer to the right entry or entries in the SA table. It would be optional, only if tunnels are ever represented as interfaces. 3. We need to have a MIB that exports the "routes" to the granularity of the Security Policy Database. (One might be wise to put this in a MIB view accessible only from the inside of the VPN, but that's not a MIB design issue.) If a MIB is to be useful in troubleshooting problems, it has to allow you to determine the path of a packet, including which tunnel it will go through. From owner-ipsec Mon Nov 16 11:32:29 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA07128 for ipsec-outgoing; Mon, 16 Nov 1998 11:22:46 -0500 (EST) Message-Id: <199811161641.LAA23421@venus.solidum.com> To: ipsec@tis.com cc: ipsec-errors@sandelman.ottawa.on.ca Reply-To: ipsec-errors@sandelman.ottawa.on.ca Subject: Selector fields for ICMP in Arch doc Date: Mon, 16 Nov 1998 11:41:26 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- One point that I think ICMP group is unanimous is that the SPD/SAD support for ICMP. We feel that it should be extended to include ICMP type and code fields as selectors. Matt Crawford has suggested that since the architecture document provides a minimum set, the IPv6 people can impose additional requirements if they need. The question is do we want to make these an item for the IPv4 Standard's Arch document? I suggest that the text read like: "An implementation MAY support ICMP as a selector for the SAD. If an implementation does support ICMP, then it MUST support both ICMP type and code as selectors" Stephen? What say you? This has ramifications for IKE as well: however, if you consider type/code to be a 16 bit item, you might pretend that it is the "port" field. I suggest that type be made the MSB and code the LSB. [do we have RFCs yet???? Do we even have numbers?] :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: mcr@solidum.com. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNlBVtG5vCG0TOZrRAQHa1gP+N75TxUHvxvvcseZdOvstZksB0RGEzm9g /zQ4QVuB0gWrhv+JMiATieJ9JjgWOXV8qV7f/S0WqKGg7jRVfBCIWvaQ4YpHXd8d +t/RaaSutfTS9e08OnJbwS6F9ZrmsPzfui2NAYJ6nn1drf4y6+KDQf/HFYMK8w8z bmtj7w4XJnY= =O2p1 -----END PGP SIGNATURE----- From owner-ipsec Tue Nov 17 17:04:03 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA13092 for ipsec-outgoing; Tue, 17 Nov 1998 16:54:52 -0500 (EST) X400-Received: by mta blsMTA in /c=us/admd=bellsouth/prmd=bis/; converted ( IA5-Text); Relayed; 17 Nov 1998 16:55:07 -0500 X400-Received: by /c=us/admd=bellsouth/prmd=bis/; converted ( IA5-Text); Relayed; 17 Nov 1998 16:55:07 -0500 X400-MTS-Identifier: [/c=us/admd=bellsouth/prmd=bis/; 006E73651F0BB011-blsMTA] Content-Identifier: 006E73651F0BB011 Content-Return: Allowed X400-Content-Type: P2-1988 ( 22 ) Conversion: Allowed Original-Encoded-Information-Types: IA5-Text Disclose-Recipients: Prohibited Alternate-Recipient: Allowed X400-Originator: Stone.Dewayne@bei.bls.com X400-Recipients: non-disclosure; Message-Id: <006E73651F0BB011*/c=us/admd=BellSouth/prmd=bis/o=ccmail/s=Stone/g=Dewayne/@MHS> Date: 17 Nov 1998 16:55:07 -0500 From: DEWAYNE STONE To: ipsec@tis.com (IPM Return requested) Subject: IPSECond MIME-Version: 1.0 Sender: owner-ipsec@ex.tis.com Precedence: bulk How do IPSECond and IPSec compare? Are they the same or is IPSECond intended to run parallel with IPSec? Are there any reference sites to get more information on the two? Thanks, Dewayne From owner-ipsec Wed Nov 18 07:59:59 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id HAA15217 for ipsec-outgoing; Wed, 18 Nov 1998 07:52:47 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF595329@exchange> From: Tim Jenkins To: "'ipsec@tis.com'" Subject: FW: IPSec Monitoring MIB works for IPv4 only? Date: Wed, 18 Nov 1998 08:13:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk Mike's comment appears quite valid. Comments on his proposal for the address issue are requested. Thanks. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 -----Original Message----- From: Mike Daniele [mailto:daniele@zk3.dec.com] Sent: Tuesday, November 17, 1998 10:08 AM To: tjenkins@timestep.com Cc: bound@zk3.dec.com; wong@zk3.dec.com; daniele@zk3.dec.com Subject: IPSec Monitoring MIB works for IPv4 only? Hello Tim, I just did a quick review of draft-ietf-ipsec-mib-02.txt. It appears not to support IPv6. That is, tunnel and peer endpoints are defined as objects with syntax IpAddress, which is limited to 4 octets and hence can't represent an IPv6 address. Since IPSec is mandatory for IPv6, it would make little sense if the IPSec MIB didn't permit implementations by IPv6 nodes. Since the address-valued objects aren't used to index any tables, you could simply add equivalent objects of syntax IPv6Address, and parhaps an enumeration for what address type is in use. See draft-ietf-ipngwg-ipv6-mib-04.txt for IPv6 textual conventions. (All the IPv6-related MIBs have been approved as Proposed Std RFCs, I believe.) Regards, Mike From owner-ipsec Wed Nov 18 10:11:01 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA15820 for ipsec-outgoing; Wed, 18 Nov 1998 10:08:14 -0500 (EST) Date: Wed, 18 Nov 1998 10:26:38 -0500 Message-Id: <199811181526.KAA02345@brill.shiva.com> From: John Shriver To: tjenkins@TimeStep.com CC: ipsec@tis.com In-reply-to: <319A1C5F94C8D11192DE00805FBBADDF595329@exchange> (message from Tim Jenkins on Wed, 18 Nov 1998 08:13:14 -0500) Subject: Re: FW: IPSec Monitoring MIB works for IPv4 only? Sender: owner-ipsec@ex.tis.com Precedence: bulk I don't think that's a suitable solution, but that's because I think that the ipSecSaTable just isn't right in the first place. I'm working with a major customer with extensive experience in operating managed networks. They have worked with us to design a proprietary MIB for IPsec for our product. In that MIB, the SA table has one entry for each SA (not a stack of SAs). The key is the three variables that uniquely identify an SA in The Internnet: destination IP address, SPI, and protocol { ESP, AH }. The reason is that they want to be able to troubleshoot effectively over low-bandwidth links. They want to know why packets sent to this box with a particular SA aren't working. They cannot search the entire SA table looking for the entry they want. Instead, the table needs to be indexed by the data in the table. A MIB is a database. It needs to be an efficient database. Efficient databases are not ipmlemented using grep (especially on the output of an snmpwalk)! It is NOT hard to implement an SNMP table with this sort of triple-index. You just have to design the data right, I've done it many times now. Making our coding easier should not be justification for designing structurally flawed MIBs. One certainly could eliminate one index by having seperate tables for AH and ESP SAs. (Looking at the data, some is specific to AH SAs, and some is specific to ESP SAs, so that split appears logical to me.) Another reason that the ipsecSaTable is flawed is that some of the variables do NOT have the same values for the four SA's that have been lumped together. The ipsecSaCreationTime most certainly will not be the same. There is no requirement in the IKE protocol that ipsecSaTiemLimit and ipsecSaTrafficLimit be the same for the four SA's. Moreover, the attempt to aggregate the traffic statistics at that "tunnel" level is innapropriate. There has to be a traffic counter for both the AH and ESP SA's, after all they each can have a traffic limit. So, one can't try and merge them into one counter to prevent the MIB from requireing "excess instrumentation", since the instrumentation is necessary to implement the protocol correctly. There is nothing wrong with a table that says what SA's a given "tunnel" uses. But it's mostly a cross-reference table. The tables for the SA's must be by the SA. As for IPv6, we can add seperate tables for IPv6 AH and ESP SAs. It really is a seperate numbering space. I'd suggest that they probably belong in a seperate MIB, because we don't want the IPv4 parts of the MIB to get hung up waiting for the IPV6-TC MIB to reach RFC status so it can be cited as a reference. IPsec cannot afford delays caused by excess dependencies. (I'll have more comments on other tables...) From owner-ipsec Wed Nov 18 10:44:05 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA15992 for ipsec-outgoing; Wed, 18 Nov 1998 10:42:15 -0500 (EST) Message-Id: <3.0.32.19981118110357.009bf100@bl-mail1.corpeast.baynetworks.com> X-Sender: smamros@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 18 Nov 1998 11:03:59 -0500 To: DEWAYNE STONE From: Shawn_Mamros@BayNetworks.COM (Shawn Mamros) Subject: Re: IPSECond Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk > How do IPSECond and IPSec compare? Are they the same or is IPSECond > intended to run parallel with IPSec? "IPSecond" is a word that was coined as a catch-all for the follow-on work that the IPSEC working group is now taking on. Despite what some misinformed folks (or folks who seek to deliberately mislead others) say, it is *NOT* a "complete rewrite" of IPSEC. All of the "IPSecond" work is based on IPSEC (and IKE) as its core. -Shawn Mamros E-mail to: Shawn_Mamros@BayNetworks.com From owner-ipsec Wed Nov 18 10:44:39 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA16002 for ipsec-outgoing; Wed, 18 Nov 1998 10:43:15 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF595464@exchange> From: Tim Jenkins To: John Shriver Cc: ipsec@tis.com Subject: RE: FW: IPSec Monitoring MIB works for IPv4 only? Date: Wed, 18 Nov 1998 11:02:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: John Shriver [mailto:jas@shiva.com] > Sent: Wednesday, November 18, 1998 10:27 AM > To: tjenkins@TimeStep.com > Cc: ipsec@tis.com > Subject: Re: FW: IPSec Monitoring MIB works for IPv4 only? > > > I don't think that's a suitable solution, but that's because I think > that the ipSecSaTable just isn't right in the first place. > > I'm working with a major customer with extensive experience in > operating managed networks. They have worked with us to design a > proprietary MIB for IPsec for our product. In that MIB, the SA table > has one entry for each SA (not a stack of SAs). The key is the three > variables that uniquely identify an SA in The Internnet: destination > IP address, SPI, and protocol { ESP, AH }. And we're working with a major customer with extensive experience in operating managed networks, too. They have (relatively) no interest in the individual SAs themselves, but only the virtual tunnels created by those SAs. The existing design is intended to be more efficient for that point of view, rather than the low level diagnostic at the individual SA point of view. > (some deleted here) > > One certainly could eliminate one index by having seperate tables for > AH and ESP SAs. (Looking at the data, some is specific to AH SAs, > and some is specific to ESP SAs, so that split appears logical to me.) > > Another reason that the ipsecSaTable is flawed is that some of the > variables do NOT have the same values for the four SA's that have been > lumped together. The ipsecSaCreationTime most certainly will not be > the same. There is no requirement in the IKE protocol that > ipsecSaTiemLimit and ipsecSaTrafficLimit be the same for the four > SA's. What 'four' SAs are you referring to? I think you're mixing layered SAs (multiple independently negotiated SAs) with SA bundles. While you are technically correct about lifetime specifications in an SA bundle, there is no practical way to re-key one of the services in a bundle if it expires before the other. The prevailing view is that SA bundles are relatively tightly bound services that effectively make up a single SA with multiple services. As an example, if an IPCOMP+ESP+AH SA bundle is negotiated between two peers, and the ESP part expires first, it is likely that the entire SA will be torn down. I stated in the document that the assumption is that the SA bundle lives only as long as the shortest living service in the bundle. Absolutely no one has complained about this. There's a trade-off between being all-encompassing and being practical; perhaps I err on the side of practicality in my assumptions. > > Moreover, the attempt to aggregate the traffic statistics at that > "tunnel" level is innapropriate. There has to be a traffic counter > for both the AH and ESP SA's, after all they each can have a traffic > limit. So, one can't try and merge them into one counter to prevent There is. There statistics for individual SAs, statistics for the tunnel they represent, and aggregates statistics between peers. Why is it inappropriate to have tunnel statistics? That's what users see. They really don't care how many SAs lived and died in a given time period as long as the security service is there. > limit. So, one can't try and merge them into one counter to prevent > the MIB from requireing "excess instrumentation", since the > instrumentation is necessary to implement the protocol correctly. > > There is nothing wrong with a table that says what SA's a given > "tunnel" uses. But it's mostly a cross-reference table. The tables > for the SA's must be by the SA. Again, there is an SA table. While you have to get to it from another table to get its selectors, all the individual SA statistics and information are there. > > As for IPv6, we can add seperate tables for IPv6 AH and ESP SAs. It > really is a seperate numbering space. I'd suggest that they probably > belong in a seperate MIB, because we don't want the IPv4 parts of the > MIB to get hung up waiting for the IPV6-TC MIB to reach RFC status so > it can be cited as a reference. IPsec cannot afford delays caused by > excess dependencies. > Does this mean you recommend that the existing MIB ignore the IPv6 address issue for now? > > (I'll have more comments on other tables...) > From owner-ipsec Wed Nov 18 11:04:44 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA16138 for ipsec-outgoing; Wed, 18 Nov 1998 11:03:17 -0500 (EST) Message-Id: <199811181619.LAA21822@smb.research.att.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Shawn_Mamros@BayNetworks.COM (Shawn Mamros) Subject: Re: IPSECond cc: DEWAYNE STONE , ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Nov 1998 11:19:46 -0500 From: "Steven M. Bellovin" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <3.0.32.19981118110357.009bf100@bl-mail1.corpeast.baynetworks.com>, Shawn Mamros writes: >> How do IPSECond and IPSec compare? Are they the same or is IPSECond >> intended to run parallel with IPSec? > >"IPSecond" is a word that was coined as a catch-all for the follow-on >work that the IPSEC working group is now taking on. Despite what some >misinformed folks (or folks who seek to deliberately mislead others) >say, it is *NOT* a "complete rewrite" of IPSEC. All of the "IPSecond" >work is based on IPSEC (and IKE) as its core. Violent agreement -- and I'm the person who made up that word. I'll state categorically that to my knowledge, at this time at most small changes are needed to IKE. I know of no changes needed to ESP, AH, or the architecture. From owner-ipsec Wed Nov 18 11:40:21 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA16346 for ipsec-outgoing; Wed, 18 Nov 1998 11:37:14 -0500 (EST) Message-Id: <199811090131.UAA00766@morden.sandelman.ottawa.on.ca> To: John Shriver cc: tjenkins@TimeStep.com, ipsec@tis.com Subject: Re: FW: IPSec Monitoring MIB works for IPv4 only? In-reply-to: Your message of "Wed, 18 Nov 1998 10:26:38 EST." <199811181526.KAA02345@brill.shiva.com> Date: Sun, 08 Nov 1998 20:31:41 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk I'd have to agree with John's comments about the indexing. It makes sense to me. I have built indexes like this in the past for policy lookups, and isn't a big deal. ] Internet Security. Have encryption, will travel |1 Fish/2 Fish[ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |Red F./Blow F[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec Wed Nov 18 12:36:23 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA16685 for ipsec-outgoing; Wed, 18 Nov 1998 12:34:22 -0500 (EST) Date: Wed, 18 Nov 1998 12:52:39 -0500 Message-Id: <199811181752.MAA02441@brill.shiva.com> From: John Shriver To: tjenkins@TimeStep.com CC: ipsec@tis.com In-reply-to: <319A1C5F94C8D11192DE00805FBBADDF595464@exchange> (message from Tim Jenkins on Wed, 18 Nov 1998 11:02:56 -0500) Subject: Re: FW: IPSec Monitoring MIB works for IPv4 only? Sender: owner-ipsec@ex.tis.com Precedence: bulk I suppose that we are running into the problems that IKE is far more generous in what it allows compared to what people expect to do. What do we define the MIB to correspond with: IKE, or expected common practice? There's no question that my proprietary MIB also has "tunnels". There are plenty of useful things there. But there really ought to also be a fast way to find your way into the MIB if the only thing you know is the destination IP address and SPI. I think my customer is looking at the "troubleshooting" part of management, and your customer is looking at the "performance monitoring" part of management. Both are valid, and both should be represented in the MIB. (See Perkins' book.) This brings up another issue. I think "tunnel" is not the word to use here. In your own response, you flip between "tunnel" and "bundle". Since "bundle" is what is used in the IPSec Architecture document, I think it would be a better-chosen word to use for what the ipsecSaTable contains. Thus, I'd propose we call it the ipsecBundleTable... I will admit that what I want to call the ipsecBundleTable is really very hard to index by anything other than an arbitrary index. It really should be indexed by the Desc and SPD rules that lead to using that bundle, but that's probably exceedingly unwieldy! As for ipsecSaInboutTraffic, what exactly does it count? Does it count the bytes including AH, ESP, and IPCOMP headers? Well, really it has to count exactly what is supposed to be counted against the lifetime in kbytes. (The comment on ipsecSaTrafficLimit in IpsecSaEntry is wrong, should be -- 1024 byte units, 0 if none.) As for IPv6, I think it should be in a seperate MIB. That is, what you are presently working on is really IPSEC-IPV4-MIB. There will be a seperate IPSEC-IPV6-MIB. This will prevent RFC publication of IPSEC-IPV4-MIB from being held up because IPV6-TC isn't published as an RFC yet. (You cannot publish an RFC with a reference to an Internet-Draft...) Further, as conformance statements are developed for IPSEC-IPV4-MIB, perhaps they should be carefully constructed so as not to require IPv4 specific variables unless the IPsec implementation implements IPv4. Someday, there may be IPv6-only hosts... From owner-ipsec Wed Nov 18 13:14:39 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA16866 for ipsec-outgoing; Wed, 18 Nov 1998 13:12:25 -0500 (EST) Date: Wed, 18 Nov 1998 20:31:04 +0200 (EET) From: Markku Savela Message-Id: <199811181831.UAA17225@anise.tte.vtt.fi> To: ipsec@tis.com In-reply-to: <319A1C5F94C8D11192DE00805FBBADDF595464@exchange> (message from Tim Jenkins on Wed, 18 Nov 1998 11:02:56 -0500) Subject: Bundle or not in negotiation Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@ex.tis.com Precedence: bulk I guess I am getting repetious and perhaps a pain in * for some, but I still make this question once more, prompted by following > From: Tim Jenkins > As an example, if an IPCOMP+ESP+AH SA bundle is negotiated between > two peers, and the ESP part expires first, it is likely that the entire > SA will be torn down. I stated in the document that the assumption is > that the SA bundle lives only as long as the shortest living service > in the bundle. Where does the requirement come that a bundle IPCOMP+ESP+AH needs to be negotiated as a bunch? Assuming IPSEC architecture and PFKEYv2 interface to kernel (and ignoring the IPCOMP for a moment), the key management gets TWO independent and unordered ACQUIRE messages (ESP and AH), there is no need to connect them together, they can be negotiated independentely, and they may even have a different lifetimes. I don't see any problems with this freedom. A while back I posted few scenarios of how I see things to happen in negotiation. I hope that someone could give me an example that actually requires treating them as clump in negotiation phase. The appliation order of IPCOM+ESP+AH is defined by the policy, which *must* specify same order on both sides. The order is non-negotiable. IPCOMP is a problematic. It is not included in the PFKEYv2, there is no way of IPSEC kernel to request IPCOMP in ACQUIRE, even if the policy wanted it. I see only two tracks of solving this: 1) Make new SA type for IPCOMP => then you could negotiate IPCOMP independently same way as AH and ESP 2) Make IPCOMP a new algorithm in SA => this would need a change in PFKEYv2 message format, as a slot would have to alloated for the compression algorithm (at similar to 'auth' and 'encrypt'). Maybe there are other ways, but those above are the first that come to mind. From owner-ipsec Wed Nov 18 13:15:43 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA16873 for ipsec-outgoing; Wed, 18 Nov 1998 13:14:20 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF595526@exchange> From: Tim Jenkins To: John Shriver Cc: ipsec@tis.com Subject: RE: FW: IPSec Monitoring MIB works for IPv4 only? Date: Wed, 18 Nov 1998 13:34:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: John Shriver [mailto:jas@shiva.com] > Sent: Wednesday, November 18, 1998 12:53 PM > To: tjenkins@TimeStep.com > Cc: ipsec@tis.com > Subject: Re: FW: IPSec Monitoring MIB works for IPv4 only? > > > I suppose that we are running into the problems that IKE is far more > generous in what it allows compared to what people expect to do. What > do we define the MIB to correspond with: IKE, or expected common > practice? > My mandate was to *quickly* produce a usable MIB. The speed issue requires some simplification. Further, I have only made a few simplifications: 1) Assumption of only 1 IPCOMP service per bundle, 1 ESP service per bundle, and 1 AH service per bundle. 2) No method to specify the order of the services per bundle, since the normal reasonable order is assumed (see some of the previous email on this). 3) Only 1 phase SA between 2 peers at a time. 4) That IPSec is above IP in a stack. A can't think of any others off the top of my head... (I know that number 4 above has raised concerns, but it looked like they were addressable where implementations needed to do that.) > There's no question that my proprietary MIB also has "tunnels". There > are plenty of useful things there. But there really ought to also be > a fast way to find your way into the MIB if the only thing you know is > the destination IP address and SPI. > This would require the addition of an IP address added to every 'ipsecSaEntry', causing it to be duplicated, since it's already in the 'ipsecIkeSaTable'. > I think my customer is looking at the "troubleshooting" part of > management, and your customer is looking at the "performance > monitoring" part of management. Both are valid, and both should be > represented in the MIB. (See Perkins' book.) > Sure, but if there's a conflict between the two, which has priority? You can still do both with this architecture, it's just easier to do performance monitoring. Which would be done more often by most customers? Would it help if an 'ipsecIkeSaTable' index was placed into each 'ipsecSaEntry', so that one de-referencing step would be removed? Is it worth it? > This brings up another issue. I think "tunnel" is not the word to use > here. In your own response, you flip between "tunnel" and "bundle". > Since "bundle" is what is used in the IPSec Architecture document, I > think it would be a better-chosen word to use for what the > ipsecSaTable contains. Thus, I'd propose we call it the > ipsecBundleTable... I don't flip between tunnel and bundle. I *do* flip between bundle and SA, since this MIB views a bundle as an SA with more than one service. So, in this sense, the 'ipsecSaTable' is really an 'ipsecBundleTable' as you suggest. I considered that name some time ago, but rejected it, since I didn't want confusion with separately negotiated multiple but layered SAs and bundles. Further, some of the drafts also refer to bundles as "security suites"... I also wanted to strengthen the concept that bundles are SAs with multiple services, rather than simply layered SAs. > > I will admit that what I want to call the ipsecBundleTable is really > very hard to index by anything other than an arbitrary index. It > really should be indexed by the Desc and SPD rules that lead to using > that bundle, but that's probably exceedingly unwieldy! > > As for ipsecSaInboutTraffic, what exactly does it count? Does it > count the bytes including AH, ESP, and IPCOMP headers? Well, really > it has to count exactly what is supposed to be counted against the > lifetime in kbytes. (The comment on ipsecSaTrafficLimit in > IpsecSaEntry is wrong, should be -- 1024 byte units, 0 if none.) > Actually, I was waiting for someone to catch this. System administrators (in general) want this mean the *user* traffic carried by the SA. However, there are problems with this if we use your rule above. The expiration value is based on the amount data the service is applied to. So, for ESP, this means the user traffic plus the padding (and next protocol and padding length) bytes. In general, the numbers will be close. However, what happens in a bundle? The ESP packet is then applied to AH (if they are both used), and the data processed by ESP is longer than both the user data and the data applied to ESP. For this reason, I think the 'ipsecSaInboundTraffic' should refer to user data, after all inbound processing. As noted above, this will not necessarily be the same as the amount counted against an SA's expiration by traffic limit. Further comments on this are invited... > > As for IPv6, I think it should be in a seperate MIB. That is, what > you are presently working on is really IPSEC-IPV4-MIB. There will be > a seperate IPSEC-IPV6-MIB. This will prevent RFC publication of > IPSEC-IPV4-MIB from being held up because IPV6-TC isn't published as > an RFC yet. (You cannot publish an RFC with a reference to an > Internet-Draft...) > Okay. > Further, as conformance statements are developed for IPSEC-IPV4-MIB, > perhaps they should be carefully constructed so as not to require IPv4 > specific variables unless the IPsec implementation implements IPv4. > Someday, there may be IPv6-only hosts... > Any one want to do the conformance statements? From owner-ipsec Wed Nov 18 13:35:45 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA16939 for ipsec-outgoing; Wed, 18 Nov 1998 13:34:21 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF595540@exchange> From: Tim Jenkins To: msa@hemuli.tte.vtt.fi, ipsec@tis.com Subject: RE: Bundle or not in negotiation Date: Wed, 18 Nov 1998 13:54:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE1324.E8AB2E80" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE1324.E8AB2E80 Content-Type: text/plain; charset="iso-8859-1" --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Markku Savela [mailto:msa@anise.tte.vtt.fi] > Sent: Wednesday, November 18, 1998 1:31 PM > To: ipsec@tis.com > Subject: Bundle or not in negotiation > > > I guess I am getting repetious and perhaps a pain in * for some, but I > still make this question once more, prompted by following > > > From: Tim Jenkins > > > As an example, if an IPCOMP+ESP+AH SA bundle is negotiated between > > two peers, and the ESP part expires first, it is likely > that the entire > > SA will be torn down. I stated in the document that the > assumption is > > that the SA bundle lives only as long as the shortest living service > > in the bundle. > > Where does the requirement come that a bundle IPCOMP+ESP+AH needs to > be negotiated as a bunch? Assuming IPSEC architecture and PFKEYv2 > interface to kernel (and ignoring the IPCOMP for a moment), the key > management gets TWO independent and unordered ACQUIRE messages (ESP > and AH), there is no need to connect them together, they can be > negotiated independentely, and they may even have a different > lifetimes. Yes, they can. Nothing I said above intends to preclude that. But if you do that, you'll create two *separate* tunnels: 1 with ESP and AH. The SAs that create those tunnels will have been negotiated with separate SA payloads, probably in separate quick modes. The specific case I was referring to, and the implicit (I need to make this explicit) assumption being made, is that the services are being negotiated within the same SA payload, and each service is a proposal with the same proposal number. > ... > > The appliation order of IPCOM+ESP+AH is defined by the policy, which > *must* specify same order on both sides. The order is > non-negotiable. Not according to earlier posts, which state that this issue came up before. They stated that for multiple proposals in the same SA payload, the order is (outbound) IPCOMP before ESP before AH, regardless of the order in the IKE exchange. See below for text from an earlier post from Daniel Harkins [dharkins@cisco.com]: (The second sentence, specifically.) ======= The order of offer in IKE shouldn't matter. If they're negotiated in a bundle we do PCP before ESP before AH regardless of how they appear in the offered bundle. If you negotiated ESP to protect AH traffic between SGs (for traffic analysis protection for instance) and that AH traffic protected some transient traffic to which PCP was also applied you could get |IP|ESP|AH|PCP|IP|data| crossing the wire but then it's two separate negotiations and the bundle is AH&PCP and you still do PCP before AH. Dan. On Tue, 10 Nov 1998 16:09:06 +0530 you wrote > > On Mon, 9 Nov 1998, Michael C. Richardson wrote: > > > The only thing missing is whether the proposals that are in the same > > mode are to be applied inside-out, or outside-in: > > > > "For ANDed proposals, the 'mode' MUST be the same, and the protocol header >s > > applied MUST be applied adjacent to each other. The first proposal describe >s > > the inner-most (first on encryption/authentication/compression, last on > > decryption/checking/decompression) transform to be applied, with the last > > proposal describing the outer most transform. If multiple proposals are > > required to protect a packet, and they are to be applied in different modes >, > > this is achieved by using multiple Phase-2 negotiations, the > > applicability/order of them to be determined the selectors used." > > What is the order currently implemented by most implementations? If you > see the second example in the ISAKMP draft on pages 49-50, the first > protocol is AH and the second ESP. This seemed to indicate that the order > of the protocols is outer to inner rather than inner to outer, since the > supported combination is AH ESP. It seems more intuitive to interpret the > order in the way it appears in a processed packet - outer to inner. > > Anupama ------_=_NextPart_001_01BE1324.E8AB2E80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Bundle or not in negotiation

---
Tim = Jenkins           = ;            = TimeStep Corporation
tjenkins@timestep.com       =    http://www.timestep.com
(613) 599-3610 = x4304           &= nbsp;   Fax: (613) 599-3617


> -----Original Message-----
> From: Markku Savela [mailto:msa@anise.tte.vtt.fi]
> Sent: Wednesday, November 18, 1998 1:31 = PM
> To: ipsec@tis.com
> Subject: Bundle or not in negotiation
>
>
> I guess I am getting repetious and perhaps a = pain in * for some, but I
> still make this question once more, prompted by = following
>
> > From: Tim Jenkins = <tjenkins@TimeStep.com>
>
> > As an example, if an IPCOMP+ESP+AH SA = bundle is negotiated between
> > two peers, and the ESP part expires first, = it is likely
> that the entire
> > SA will be torn down. I stated in the = document that the
> assumption is
> > that the SA bundle lives only as long as = the shortest living service
> > in the bundle.
>
> Where does the requirement come that a bundle = IPCOMP+ESP+AH needs to
> be negotiated as a bunch? Assuming IPSEC = architecture and PFKEYv2
> interface to kernel (and ignoring the IPCOMP = for a moment), the key
> management gets TWO independent and unordered = ACQUIRE messages (ESP
> and AH), there is no need to connect them = together, they can be
> negotiated independentely, and they may even = have a different
> lifetimes.

Yes, they can. Nothing I said above intends to = preclude that. But if
you do that, you'll create two *separate* tunnels: 1 = with ESP and AH.
The SAs that create those tunnels will have been = negotiated with
separate SA payloads, probably in separate quick = modes.

The specific case I was referring to, and the = implicit (I need to make
this explicit) assumption being made, is that the = services are being
negotiated within the same SA payload, and each = service is a
proposal with the same proposal number.

>
...
>
> The appliation order of IPCOM+ESP+AH is defined = by the policy, which
> *must* specify same order on both sides. The = order is
> non-negotiable.

Not according to earlier posts, which state that this = issue came up
before. They stated that for multiple proposals in = the same SA
payload, the order is (outbound) IPCOMP before ESP = before AH,
regardless of the order in the IKE exchange.


See below for text from an earlier post from Daniel = Harkins [dharkins@cisco.com]:

(The second sentence, specifically.)

=3D=3D=3D=3D=3D=3D=3D

  The order of offer in IKE shouldn't matter. If = they're negotiated in
a bundle we do PCP before ESP before AH regardless = of how they appear
in the offered bundle. If you negotiated ESP to = protect AH traffic
between SGs (for traffic analysis protection for = instance) and that AH
traffic protected some transient traffic to which = PCP was also applied
you could get |IP|ESP|AH|PCP|IP|data| crossing the = wire but then it's two
separate negotiations and the bundle is AH&PCP = and you still do PCP
before AH.

  Dan.

On Tue, 10 Nov 1998 16:09:06 +0530 you wrote
>
> On Mon, 9 Nov 1998, Michael C. Richardson = wrote:
>
> >   The only thing missing is = whether the proposals that are in the same
> > mode are to be applied inside-out, or = outside-in:
> >
> >  "For ANDed proposals, the = 'mode' MUST be the same, and the protocol header
>s
> > applied MUST be applied adjacent to each = other. The first proposal describe
>s
> > the inner-most (first on = encryption/authentication/compression, last on
> > decryption/checking/decompression) = transform to be applied, with the last
> > proposal describing the outer most = transform. If multiple proposals are
> > required to protect a packet, and they are = to be applied in different modes
>,
> > this is achieved by using multiple Phase-2 = negotiations, the
> > applicability/order of them to be = determined the selectors used."
>
> What is the order currently implemented by most = implementations? If you
> see the second example in the ISAKMP draft on = pages 49-50, the first
> protocol is AH and the second ESP. This seemed = to indicate that the order
> of the protocols is outer to inner rather than = inner to outer, since the
> supported combination is AH ESP. It seems more = intuitive to interpret the
> order in the way it appears in a processed = packet - outer to inner.
>
> Anupama

------_=_NextPart_001_01BE1324.E8AB2E80-- From owner-ipsec Wed Nov 18 13:36:45 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA16951 for ipsec-outgoing; Wed, 18 Nov 1998 13:35:21 -0500 (EST) Date: Wed, 18 Nov 1998 13:53:46 -0500 Message-Id: <199811181853.NAA02481@brill.shiva.com> From: John Shriver To: ipsec@tis.com CC: Tim Jenkins Subject: more on ipsec-mib-02 - Phase 1 tunnels Sender: owner-ipsec@ex.tis.com Precedence: bulk I've had a chance to digest the implications of the IKE Phase 1 tunnels part of ipsec-mib-02. I'll try and structure this message into parts. DOI values and TEXTUAL-CONVENTIONS ---------------------------------- The first thing is how the various DOI variables are brought into the MIB. I think we should follow the example of using textual conventions, defining them in a seperate document. This was first done for IANAifType-MIB, which is maintained by the IANA. So, there should be an IPSEC-ISAKMP-DOI-TC MIB. It would define Textual Conventions for each of the DOI enumerations used by an IPSec MIB. This document would be revised with each revision of the DOI. But, by being in a seperate document, the changes to it would not reset the standards track progress of IPSEC-MIB (or IPSEC-IPV4-MIB and IPSEC-IPV6-MIB). For example (apologies for the long-winded name): IANAipSecIsakmpDoiIkeSaAuthMethod ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "These are the values of IKE Phase 1 Authentication method defined by the current IPSec DOI." SYNTAX INTEGER { preSharedKey(1), dssSignatures(2), rsaSignatures(3), encryptionWithRsa(4), revisedEncryptionWithRsa(5) } This has the enormous advantage to the network management user that they see something intelligble as the value of ipsecIkeSaAuthMethod, rather than a random integer. Yet, we avoid the interlocking revisions tendril. Presumably the IPSEC-DOI-TC should be administered by the IANA, who also administers these DOI values. This eliminates the whole RFC process issue. Missing Local Address/Port in Phase 1 SA Table ---------------------------------------------- The Phase 1 SA table needs the local IP address and UDP port for the Phase 1 SA. How else can one possibly correlate these table entries between the IPSec devices at each end of this SA? There's no guaruntee that the IPSec device has only one IP address. Also, in cases where IKE collisions have occured (without resolution), this will be the only way to diagnose the situation. So, add ipsecIkeSaLocalIPAddress and ipsecIkeSaLocalPortNumber. Oh, both the port numbers should be described as UDP port numbers, right? Indexing of Phase 1 SA Table ---------------------------- Once we have the tuple that identifies an IKE Phase 1 SA (ipsecIkeSaLocalIpAddress, ipsecIkeSaLocalPortNumber, ipSecIkeSaPeerIpAddress, and ipsecIkeSaPeerPortNumber), we have the true key to an IPSec IKE Phase 1 SA. Thus, I'd propose that those four variables form the INDEX. (Well, at least for IPv4. That problem again!) This is no more complicated an index than tcpConnTable. Mapping Out Port 500 -------------------- I think it's gratuitous complexity to replace port 500 with 0. What should be done is to have a DEFVAL of 500, if only to express that, since it's really meaningless on a read-only variable. Normal Versus Agressive Mode ---------------------------- There should be a variable in ipsecIkeSaTable that reflects whether the phase 1 negotiation was done in normal versus aggressive mode. More States ----------- I think that ipsecIkeSaStatus needs another enumeration, initializing(4). There is a period during which the Phase 1 SA isn't fully formed yet. We can't add detailed states, since they are different for everyipsecIkeSaAuthMethod, and they aren't named in IKE anyways. Who Initiated ------------- We need a variable ipsecIkeSeRole, with syntax INTEGER { intiator(1), responder(2) }. Otherwise how does one know which Cookie is which? Human-Reable Names for Phase 1 SA's ----------------------------------- I'd suggest that we follow the lead of RFC 2233 and predecessors, and define a variable similar to ifAlias. This is a string that can be set by the manager to assign a human-readable name to thie Phase 1 SA. UNITS ----- A lot of variables need UNITS added. For instance, ipsedIkeSaIpsecInboundTraffic should say UNITS "bytes". More importantly, ipsecIkeSaTrafficLimit should say UNITS "Kbytes". (Big K, which is conventionally 1024.) Similarly, ipsecIkeSaTimeLimit should say UNITS "seconds". (I also think it's syntax should probably be INTEGER(0..4294967295). It doesn't have Gauge behavior.) From owner-ipsec Wed Nov 18 14:18:23 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA17109 for ipsec-outgoing; Wed, 18 Nov 1998 14:16:20 -0500 (EST) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81712@RED-MSG-50> From: Richard Draves To: "'Tim Jenkins'" , msa@hemuli.tte.vtt.fi, ipsec@tis.com Subject: RE: Bundle or not in negotiation Date: Wed, 18 Nov 1998 11:35:03 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk Is there an interoperability problem here? Tim, if your implementation expects to negotatiate ESP+AH together in one proposal, and if Markku's implementation tries to negotiate them separately with you, will you fail?   Rich -----Original Message----- From: Tim Jenkins [mailto:tjenkins@TimeStep.com] Sent: Wednesday, November 18, 1998 10:55 AM To: msa@hemuli.tte.vtt.fi; ipsec@tis.com Subject: RE: Bundle or not in negotiation --- Tim Jenkins                       TimeStep Corporation tjenkins@timestep.com          http://www.timestep.com (613) 599-3610 x4304               Fax: (613) 599-3617 > -----Original Message----- > From: Markku Savela [ mailto:msa@anise.tte.vtt.fi ] > Sent: Wednesday, November 18, 1998 1:31 PM > To: ipsec@tis.com > Subject: Bundle or not in negotiation > > > I guess I am getting repetious and perhaps a pain in * for some, but I > still make this question once more, prompted by following > > > From: Tim Jenkins > > > As an example, if an IPCOMP+ESP+AH SA bundle is negotiated between > > two peers, and the ESP part expires first, it is likely > that the entire > > SA will be torn down. I stated in the document that the > assumption is > > that the SA bundle lives only as long as the shortest living service > > in the bundle. > > Where does the requirement come that a bundle IPCOMP+ESP+AH needs to > be negotiated as a bunch? Assuming IPSEC architecture and PFKEYv2 > interface to kernel (and ignoring the IPCOMP for a moment), the key > management gets TWO independent and unordered ACQUIRE messages (ESP > and AH), there is no need to connect them together, they can be > negotiated independentely, and they may even have a different > lifetimes. Yes, they can. Nothing I said above intends to preclude that. But if you do that, you'll create two *separate* tunnels: 1 with ESP and AH. The SAs that create those tunnels will have been negotiated with separate SA payloads, probably in separate quick modes. The specific case I was referring to, and the implicit (I need to make this explicit) assumption being made, is that the services are being negotiated within the same SA payload, and each service is a proposal with the same proposal number. > ... > > The appliation order of IPCOM+ESP+AH is defined by the policy, which > *must* specify same order on both sides. The order is > non-negotiable. Not according to earlier posts, which state that this issue came up before. They stated that for multiple proposals in the same SA payload, the order is (outbound) IPCOMP before ESP before AH, regardless of the order in the IKE exchange. See below for text from an earlier post from Daniel Harkins [dharkins@cisco.com]: (The second sentence, specifically.) =======   The order of offer in IKE shouldn't matter. If they're negotiated in a bundle we do PCP before ESP before AH regardless of how they appear in the offered bundle. If you negotiated ESP to protect AH traffic between SGs (for traffic analysis protection for instance) and that AH traffic protected some transient traffic to which PCP was also applied you could get |IP|ESP|AH|PCP|IP|data| crossing the wire but then it's two separate negotiations and the bundle is AH&PCP and you still do PCP before AH.   Dan. On Tue, 10 Nov 1998 16:09:06 +0530 you wrote > > On Mon, 9 Nov 1998, Michael C. Richardson wrote: > > >   The only thing missing is whether the proposals that are in the same > > mode are to be applied inside-out, or outside-in: > > > >  "For ANDed proposals, the 'mode' MUST be the same, and the protocol header >s > > applied MUST be applied adjacent to each other. The first proposal describe >s > > the inner-most (first on encryption/authentication/compression, last on > > decryption/checking/decompression) transform to be applied, with the last > > proposal describing the outer most transform. If multiple proposals are > > required to protect a packet, and they are to be applied in different modes >, > > this is achieved by using multiple Phase-2 negotiations, the > > applicability/order of them to be determined the selectors used." > > What is the order currently implemented by most implementations? If you > see the second example in the ISAKMP draft on pages 49-50, the first > protocol is AH and the second ESP. This seemed to indicate that the order > of the protocols is outer to inner rather than inner to outer, since the > supported combination is AH ESP. It seems more intuitive to interpret the > order in the way it appears in a processed packet - outer to inner. > > Anupama From owner-ipsec Wed Nov 18 14:35:13 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA17224 for ipsec-outgoing; Wed, 18 Nov 1998 14:32:25 -0500 (EST) Message-Id: <199811181951.LAA03027@dharkins-ss20.cisco.com> To: msa@hemuli.tte.vtt.fi (Markku Savela) cc: ipsec@tis.com Subject: Re: Bundle or not in negotiation In-reply-to: Your message of "Wed, 18 Nov 1998 20:31:04 +0200." <199811181831.UAA17225@anise.tte.vtt.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3025.911418681.1@cisco.com> Date: Wed, 18 Nov 1998 11:51:21 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk On Wed, 18 Nov 1998 20:31:04 +0200 you wrote > I guess I am getting repetious and perhaps a pain in * for some, but I > still make this question once more, prompted by following > > > From: Tim Jenkins > > > As an example, if an IPCOMP+ESP+AH SA bundle is negotiated between > > two peers, and the ESP part expires first, it is likely that the entire > > SA will be torn down. I stated in the document that the assumption is > > that the SA bundle lives only as long as the shortest living service > > in the bundle. > > Where does the requirement come that a bundle IPCOMP+ESP+AH needs to > be negotiated as a bunch? Assuming IPSEC architecture and PFKEYv2 > interface to kernel (and ignoring the IPCOMP for a moment), the key > management gets TWO independent and unordered ACQUIRE messages (ESP > and AH), there is no need to connect them together, they can be > negotiated independentely, and they may even have a different > lifetimes. Where does the requirement to use PFKEY come from? Plumbing from IPSec to IKE and back is not in the IPSec or IKE protocol definitions. We shouldn't dictate how two peers communicate by what they do on the backend. > I don't see any problems with this freedom. A while back I posted few > scenarios of how I see things to happen in negotiation. I hope that > someone could give me an example that actually requires treating them > as clump in negotiation phase. If your mulltiple ACQUIRE messages all refer to the same traffic and peer then it makes sense to negotiate them all at once. When you do they are treated as a bundle. Of course you don't have to do that. You can do multiple negotiations and be inefficient if you want. But if you do negotiate things seperately then what do you do with the packets that are queued up after the 1st negotiation is finish but before the 2nd is finished? If your plumbing can't handle a set of requirements and can only dole things out one at a time and your policy says "AH AND ESP for traffic from foo to bar with frobnitz as the peer" then you'll do an AH negotiation with frobnitz and then a separate ESP negotiation with frobnitz. When the first is finished whaddya do? Send packets with AH but not ESP? Or do you wait until all negotiations are finished? If the latter then what's the point of doing them separate. I'm missing something. > The appliation order of IPCOM+ESP+AH is defined by the policy, which > *must* specify same order on both sides. The order is > non-negotiable. > > IPCOMP is a problematic. It is not included in the PFKEYv2, there is > no way of IPSEC kernel to request IPCOMP in ACQUIRE, even if the > policy wanted it. I see only two tracks of solving this: Again, PFKEY is not a requirement. But this illustrates the problem PFKEY has since it defines its own magic number space instead of multiplexing off a DOI and using what IANA is already defining. Oh well. I don't think this design decision should influence how IKE or IPSec operate. > 1) Make new SA type for IPCOMP => then you could negotiate IPCOMP > independently same way as AH and ESP > > 2) Make IPCOMP a new algorithm in SA => this would need a change in > PFKEYv2 message format, as a slot would have to alloated for the > compression algorithm (at similar to 'auth' and 'encrypt'). > > Maybe there are other ways, but those above are the first that come to > mind. Another way would be for PFKEY to include a DOI identifier and allow for negotiation of IANA defined magic numbers. There is no reason why IKE has to do magic number translation and there is no reason why IKE has to know that if the DOI is 3 and attribute 8 has a value of 2 that it's referring to HMAC-TIGER for RSVP (I'm making those numbers up for illustration). It just offers them and accepts or rejects them based on local policy. Then when another DOI, for OSPF or RIP or whatever, is defined, and a new set of magic numbers is assigned by IANA you don't need to change key management to do magic number translation, it just works. The problem you're having with PCP will reappear when IKE is used to negotiate security parameters for any other service. But that's a PFKEY problem and not an IPSec problem or an IKE problem. Those of us that aren't using PFKEY do not have the problem you describe. Dan. From owner-ipsec Wed Nov 18 15:56:43 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA17745 for ipsec-outgoing; Wed, 18 Nov 1998 15:53:02 -0500 (EST) Date: Wed, 18 Nov 1998 16:11:20 -0500 Message-Id: <199811182111.QAA02573@brill.shiva.com> From: John Shriver To: tjenkins@TimeStep.com CC: ipsec@tis.com In-reply-to: <319A1C5F94C8D11192DE00805FBBADDF595526@exchange> (message from Tim Jenkins on Wed, 18 Nov 1998 13:34:29 -0500) Subject: Re: FW: IPSec Monitoring MIB works for IPv4 only? Sender: owner-ipsec@ex.tis.com Precedence: bulk From: Tim Jenkins To: John Shriver Date: Wed, 18 Nov 1998 13:34:29 -0500 > -----Original Message----- > From: John Shriver [mailto:jas@shiva.com] > To: tjenkins@TimeStep.com > > There's no question that my proprietary MIB also has "tunnels". There > are plenty of useful things there. But there really ought to also be > a fast way to find your way into the MIB if the only thing you know is > the destination IP address and SPI. > This would require the addition of an IP address added to every 'ipsecSaEntry', causing it to be duplicated, since it's already in the 'ipsecIkeSaTable'. > I think my customer is looking at the "troubleshooting" part of > management, and your customer is looking at the "performance > monitoring" part of management. Both are valid, and both should be > represented in the MIB. (See Perkins' book.) > Sure, but if there's a conflict between the two, which has priority? You can still do both with this architecture, it's just easier to do performance monitoring. Which would be done more often by most customers? Would it help if an 'ipsecIkeSaTable' index was placed into each 'ipsecSaEntry', so that one de-referencing step would be removed? Is it worth it? That doesn't address the issue. My customer needs to get the data in the minimum number of bytes over the extremely slow link to the IPSec device. Anything that requires reading the entire table is a no-no. (We tried to convince him.) There doesn't need to be any data other than cross-reference in the table indexed by IP destination address and SPI. Using SNMP exchanges is OK, it's the whole table search that's the killer. The only other thing needed is a pointer to the "bundle" or Phase 2 SA. It's just an efficient lookup key. Your system can require loading the entire contents of two or three tables (due to avoidance of "duplicate" variables), cross-correlation, and search. This is worst case if you need to find the Phase 2 SA corresponding to an out-going SPI. I don't think that duplicate variables are evil when they allow you to make meaningful indices. From owner-ipsec Wed Nov 18 18:28:00 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA18524 for ipsec-outgoing; Wed, 18 Nov 1998 18:22:47 -0500 (EST) Date: Thu, 19 Nov 1998 01:41:09 +0200 (EET) Message-Id: <199811182341.BAA24541@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Tim Jenkins Cc: John Shriver , ipsec@tis.com Subject: RE: FW: IPSec Monitoring MIB works for IPv4 only? In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF595526@exchange> References: <319A1C5F94C8D11192DE00805FBBADDF595526@exchange> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 65 min X-Total-Time: 246 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Tim Jenkins writes: > My mandate was to *quickly* produce a usable MIB. The speed issue requires > some simplification. Further, I have only made a few simplifications: > 3) Only 1 phase SA between 2 peers at a time. I don't like this. There can easily be two phase 1 SAs between 2 peers at a time in case we have simultaneous startup or rekeying going on. Both ends just start phase I negotiation at the same time, we create two phase I SAs and both of them are valid and there is know defined way to select which one of them to leave, and which one to delete. If we just randomly delete one of them and the other end does the same we end up without SA at all 50 % of the time. This issue has been discuessed earlier in the list, but I don't think it have been resolved. As far as I can say any of the drafts doesn't disallow that, or say what you should do to resolve the thing, so it is going to happen. In any case if we end up having (or just want to support them) multiple ISAKMP SAs how are we going to represent them in the MIB? Also for mobile user case it would be nice not to tie ISAKMP SA to ip-addresses but to tie them to cookies. Now the MIB uses the ip-address and port numbers to identify the ISAKMP SA. For mobile users case it would be usefull to reuse old ISAKMP SA to IPsec gateway even if the ip-addresses of the mobile user has already changed. Currently only thing that requires destination address to remain constant between two phase II negotiations is the cookie generation algorithm (and that is quite easy to change, and it is implementation issue). Only cookies really distinguish the ISAKMP SA. I would change the ISAKMP SA table to be two layers just like the ipsec sa table, so that the first table is uniquely identified by the phase I identities (ipsecIkeTunnelTable), and the second table is uniquely identified by the ISAKMP SA cookies (ipsecIkeSaTable). > This would require the addition of an IP address added to every > 'ipsecSaEntry', > causing it to be duplicated, since it's already in the 'ipsecIkeSaTable'. Yes, I would think that would be wise anyways, if we consider this MIB to be used for other things that VPN also. For mobile user the ipsec address might change quite quickly and it might have multiple ipsec tunnels with different ip-address up at the same time (I am talking about mobile user with radio link connection, not necessary road warrior case). > Further comments on this are invited... I am just reading the MIB first time, and I do have some questions and comments. There is a typo in the ipsecIkeSaEncKeyLength definition (ipsecIkeSaEncLeyLength). I assume it is 0 for variable length ciphers that are using default key length defined in the documents? BTW, there IS always encryption for ISAKMP SA, if such exists, so it might be better to change those "... or there is no encryption specified" to "... or there is no ISAKMP SA active". There is also same text for ipsecIkeSaHashAlg. ipsecIkeSaDifHelFieldSize? How is this defined? What is the field size for MODP groups? Is this really needed? (I think the field size attribute in the ike is completely unused, because the field size can be seen from the polynomial anyways). ipsecIkeSaPFS: If your policy doesn't mandate anything then I assume that you set this to TRUE as long as all SAs are created using PFS and set it to FALSE when you have first SA that is not using PFS? I don't really think this variable belongs here at all, because in the beginning you say that this document doesn't specify the policy, and this is clearly policy issue, there is nothing to prevent using one ISAKMP SA to create both PFS and non-PFS ipsec SAs. Why is the ipsecIkeSaTrafficLimit limited to Gauge32? Note that the current IKE draft doesn't limit the size of the life duration attribute (it may be variable length, although I assume all of the implementations will fail, if someone tries to send 64-bit number to them...). Why are the *Packets counters Counter32, instead of Counter64? We may end up using more than 2^32 packets also... It takes for 100 MB ethernet with small packets only less than an half a day to do it. ipsecIkeSaDecryptErrors: How you defined such? Normally that might be guessed from the INVALID-PAYLOAD-TYPE, DOI-NOT-SUPPORTED, PAYLOAD-MALFORMED, BAD-PROPOSAL-SYNTAX error codes or something else. I think it might be quite hard to categorize errors to be decryption errors. At least there should be list of errors that are considered decryption errors. ipsecIkeSaHashErrors: I assume this doesn't contain the AUTHENTICATION-FAILED error codes that are generated when phase I authentication hash failes, only to the INVALID-HASH-INFORMATION that are generated if the hash lenght is invalid etc. The draft-ietf-ipsec-isakmp-10.txt says you should send AUTHENTICATION-FAILED error code if the hash comparision fails. I assume this should really be ipsecIkeSaAuthErrors if you want to calculate authentication errors. I don't know how easy it is to find out ipsec sa decryption errors either, but perhaps just checking the padding is enough. ipsecTunnelLocalAddressOrStart, ipsecTunnelLocalAddressMaskOrEnd: where is the type of these fields given? How does the reader know if they should treat this range, subnet, or just one ip address? "ipsecIkeSaEncAlg - Encryption Algorithm" defines DES40-CBC 65001, which is not defined by the DOI (and should not be defined by the DOI, because is it from the private range). Also because the MIB doesn't provide the vendor id information (I think it should!) there is no way to know whose private number space we are using if there are any numbers from the private number space. I really don't like 3-second-encryption-algorithms to be added to documents, but if they must be mentioned, I would think it is better NOT to take the first available number for it, but take some random number like 65322 instead, so we do not have conflicts so easily. Should we add something about this to the doi and ike draft also (about not taking the first one, but taking them in random order)? Same thing for ESP_DES40 (again the first available one, that everybody is going to use anyway if they ever add private algorithms, and not defined in the other documents). It seems to be odd that group 5 is missing, even when it is much more widely supported than DES40 :-) -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Thu Nov 19 09:17:07 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA22449 for ipsec-outgoing; Thu, 19 Nov 1998 09:13:21 -0500 (EST) From: Mohan Parthasarathy Message-Id: <199811182245.OAA16609@locked.eng.sun.com> Subject: Re: Bundle or not in negotiation To: owner-ipsec@tis.com (Daniel Harkins) Date: Wed, 18 Nov 1998 14:45:09 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <199811181951.LAA03027@dharkins-ss20.cisco.com> from "Daniel Harkins" at Nov 18, 98 11:51:21 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > Of course you don't have to do that. You can do multiple negotiations > and be inefficient if you want. But if you do negotiate things seperately > then what do you do with the packets that are queued up after the 1st > negotiation is finish but before the 2nd is finished? > > If your plumbing can't handle a set of requirements and can only dole > things out one at a time and your policy says "AH AND ESP for traffic > from foo to bar with frobnitz as the peer" then you'll do an AH negotiation > with frobnitz and then a separate ESP negotiation with frobnitz. When the > first is finished whaddya do? Send packets with AH but not ESP? Or do > you wait until all negotiations are finished? If the latter then what's > the point of doing them separate. I'm missing something. > Assume i wait until all negotiations are finished. What is wrong with negotiating them separately, except for some slow performance ? Assume the policy does not mandate unique SAs i.e sharing of SAs are permitted, what is wrong in having AH and ESP SA separately ? Some other connection may want to use just the AH SA and not the ESP SA. Some connection may want use both of them. Is there any reason to bundle them together ? -mohan From owner-ipsec Thu Nov 19 09:57:45 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA22881 for ipsec-outgoing; Thu, 19 Nov 1998 09:57:22 -0500 (EST) Message-Id: <36543550.4360AA53@hplb.hpl.hp.com> Date: Thu, 19 Nov 1998 15:12:17 +0000 From: SALLE Mathias X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en Mime-Version: 1.0 To: ipsec@tis.com Subject: need of information on a selector field Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk hello, can someone help me with the following problem: reference: draft-ietf-ipsec-arch-sec-07.txt paragraph: 4.4.2 selector problem: I don't really understand the use of the Name field of a selector. What is it for? How this field is extracted from a IP packet in order to match an entry in the SPD? regards, mathias -- ___________________________________________ Mathias SALLE Networked Systems Dpt. Hewlett-Packard Research Labs Filton Road Stoke Gifford Bristol BS12 6QZ, UK E-mail: matsal@otter.hpl.hp.com Tel : +44 (0)117 922 9753 ___________________________________________ From owner-ipsec Thu Nov 19 10:18:03 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA22960 for ipsec-outgoing; Thu, 19 Nov 1998 10:16:22 -0500 (EST) Message-ID: <365437CC.228C9C4B@zk3.dec.com> Date: Thu, 19 Nov 1998 10:22:53 -0500 From: Mike Daniele Organization: Compaq 64-bit UNIX networking X-Mailer: Mozilla 4.5 [en] (X11; I; OSF1 X5.0 alpha) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@tis.com Subject: IPv6 in the IPSec MIB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk John Shriver wrote: > As for IPv6, I think it should be in a seperate MIB. That is, what > you are presently working on is really IPSEC-IPV4-MIB. There will be > a seperate IPSEC-IPV6-MIB. This will prevent RFC publication of > IPSEC-IPV4-MIB from being held up because IPV6-TC isn't published as > an RFC yet. (You cannot publish an RFC with a reference to an > Internet-Draft...) There is no issue with your WG delivering a MIB that IMPORTS from IPV6-TC or any other v6-related module. They have already all been approved as Proposed Standards, so can't gate your work. For example, the TCP over IPv6 MIB (draft-ietf-ipngwg-ipv6-tcp-mib-02.txt) IMPORTS from IPV6-TC, and has itself been approved as a Proposed Standard. The reason we had to do separate MIBs for TCP and UDP over IPv6 was because 1) IP addresses are used to index tables, so we needed separate tables for TCP connections and UDP listeners over v6 vs over v4. 2) We didn't want to have to change the existing TCP and UDP MIB RFCs (2012 and 2013), since that would have taken much longer. The ultimate goal however is to have 1 TCP MIB and 1 UDP MIB, with the necessary objects to support both IPv4 and IPv6. You don't have this baggage of existing MIBs, and can do the right thing immediately. The real issue is this: Is "IPSec over v4" a different protocol entity than "IPSec over v6"? If so, then by all means produce 2 MIB specs. If not, and the only difference between the two MIBs would be a few objects change their syntax from IpAddress to Ipv6Address, that would be a real waste. You'd end up with many duplicated objects, and would unnecessarily delay an IPSec MIB that works with IPv6 endpoints. > > Further, as conformance statements are developed for IPSEC-IPV4-MIB, > perhaps they should be carefully constructed so as not to require IPv4 > specific variables unless the IPsec implementation implements IPv4. > Someday, there may be IPv6-only hosts... Using conformance statements is a good idea. When we have a unified TCP MIB that's what we'll do. But it may not even be required for the IPSec MIB. You could define pairs of address objects, and simply state in the object descriptions that a peer, or a tunnel endpoint, is either v4 or v6. If it's v4 the v6 object is not instantiated, etc. Or you could use the TDomain/TAddress mechanism from RFC 1903. Many MIBs that support multiple address families do this. (For reference, we've already defined some for IPv6 , among others, in draft-daniele-iana-addr-mib-00.txt.) This way you'd have a single object for a generic address, and be able to load either v4 or v6 addresses in it. In any event, I don't think it would be a lot of work to emit a draft that supports both v4 and v6. (I'd be glad to help if needed.) And in my opinion the resulting product would be much more useful, timely, and concise. Regards, Mike From owner-ipsec Thu Nov 19 11:11:58 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA23261 for ipsec-outgoing; Thu, 19 Nov 1998 11:11:27 -0500 (EST) Date: Thu, 19 Nov 1998 18:29:50 +0200 (EET) From: Markku Savela Message-Id: <199811191629.SAA18221@anise.tte.vtt.fi> To: ipsec@tis.com In-reply-to: <319A1C5F94C8D11192DE00805FBBADDF595540@exchange> (message from Tim Jenkins on Wed, 18 Nov 1998 13:54:43 -0500) Subject: RE: Bundle or not in negotiation Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@ex.tis.com Precedence: bulk The reason I pursue this, is not to create a flame war, but to press for a simple standard. To me these ordering and bunching requirements appear to make things more restrictive and complex than is required by the IPSEC architecture. It appears that some solutions made by some implementations are changing the standard (not necessarily bad, if changes are really needed, but at this point I am not yet convinced). Concerning ESP+AH negotiation as a bunch or independently... > Yes, they can. Nothing I said above intends to preclude that. But if > you do that, you'll create two *separate* tunnels: 1 with ESP and AH. > The SAs that create those tunnels will have been negotiated with > separate SA payloads, probably in separate quick modes. There is something fundamental difference in our view of this. I don't see any tunnels appearing whether SA's are negotiated separately or together. Whether a tunnel is used or not, is totally independent (policy) decision, as shown in my previous emails with subject "Bundles, policies, tunneling, ordering etc..." > The specific case I was referring to, and the implicit (I need to make > this explicit) assumption being made, is that the services are being > negotiated within the same SA payload, and each service is a > proposal with the same proposal number. Unfortunately, I don't know IKE well enough to understand above statement. My view is totally from IPSEC direction: in this case it needs SA pair for AH and it needs SA pair for ESP, which both it asks from the key management separately. Both requests contain full informations to set them up independently. It is up to key managemnt, if it wants to combine the negotiations. But, even if combined, what is it that AH SA negotiation needs from ESP SA negotiation or vice versa? > > The appliation order of IPCOM+ESP+AH is defined by the policy, which > > *must* specify same order on both sides. > Not according to earlier posts, which state that this issue came up > before. This is what I am doing, I am questioning those earlier posts, the reasoning behind them, because I don't see the need for such requirement from IPSEC point of view. There is nothing in the KERNEL IPSEC architecture that demands ordering or the negotiations. The bundle attached to the policy selector defines the order of SAs to apply. From owner-ipsec Thu Nov 19 11:33:37 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA23401 for ipsec-outgoing; Thu, 19 Nov 1998 11:32:23 -0500 (EST) Date: Thu, 19 Nov 1998 18:51:32 +0200 (EET) From: Markku Savela Message-Id: <199811191651.SAA18252@anise.tte.vtt.fi> To: ipsec@tis.com In-reply-to: <199811181951.LAA03027@dharkins-ss20.cisco.com> (message from Daniel Harkins on Wed, 18 Nov 1998 11:51:21 -0800) Subject: Re: Bundle or not in negotiation Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Daniel Harkins > Where does the requirement to use PFKEY come from? Plumbing from IPSec > to IKE and back is not in the IPSec or IKE protocol definitions. > We shouldn't dictate how two peers communicate by what they do on > the backend. I'm not requiring PFKEY from IKE, but I still assume the IPSEC architecture document holds, and the key management requirements stated by it can be realised with PFKEY. > If your mulltiple ACQUIRE messages all refer to the same traffic and > peer then it makes sense to negotiate them all at once. When you do > they are treated as a bundle. Negotiating them together is a sensible optimization. Why does IKE need to know about bundles (as defined in IPSEC architecture)? What does it use this info for? > But if you do negotiate things seperately then what do you do with > the packets that are queued up after the 1st negotiation is finish > but before the 2nd is finished? A brutal solution is: don't queue up anything, drop all until all required SA's are present. Again, queuing packets for a while and waiting is yet another optimization. Not requirement in the "virtual reference implementation". > Or do you wait until all negotiations are finished? If the latter > then what's the point of doing them separate. Simplicity of implementation. Divide and conquer principle. > Again, PFKEY is not a requirement. But this illustrates the problem PFKEY > has since it defines its own magic number space instead of multiplexing off > a DOI and using what IANA is already defining. Actually I agree somewhat on above, PFKEY doesn't need to care what actual algorithm numbers are. I have totally ignored the symbols SADB_AALG_* and SADB_EALG_*. Instead, IPSEC has a configuration mapping from algorithm number to algorithm implementation function, and could use any numbers as long as both ends use the same to mean same algorithm. > There is no reason why IKE has to do magic number translation and > there is no reason why IKE has to know that if the DOI is 3 and > attribute 8 has a value of 2 that it's referring to HMAC-TIGER for > RSVP (I'm making those numbers up for illustration). Exactly. However, someone needs to tell IPSEC enginge that '2' as authentication algorithm means HMAC-TIGER (= my configuration file), but I agree, IKE or PFKEY should not need to care about exact number values. -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec Thu Nov 19 11:36:35 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA23419 for ipsec-outgoing; Thu, 19 Nov 1998 11:36:23 -0500 (EST) Date: Thu, 19 Nov 1998 11:55:24 -0500 Message-Id: <199811191655.LAA03164@brill.shiva.com> From: John Shriver To: daniele@zk3.dec.com CC: ipsec@tis.com In-reply-to: <365437CC.228C9C4B@zk3.dec.com> (message from Mike Daniele on Thu, 19 Nov 1998 10:22:53 -0500) Subject: Re: IPv6 in the IPSec MIB Sender: owner-ipsec@ex.tis.com Precedence: bulk I presume that the RFC for IPV6-TC is pending in the RFC Editor queue, which is obviously delayed... I suppose one approach to this would be to use Ipv6Address everywhere where an address is in the MIB. IPv4 addresses would be represented as the "canonical" mapping to IPv6. That is, 10.0.0.51 would be 0:0:0:0:0:FFFF:10.0.0.51. Of course, that raises the issue whether SA's really are allowed to be mapped that way. That is, is the SA with IPv4 address 10.0.0.51 and SPI 1 the same as the SA with IPv6 address 0:0:0:0:0:FFFF:10.0.0.51 and SPI 1? Certainly such a pairing would never work for AH, as the translation of the header packet from IPv4 to IPv6 could corrupt the AH prf() value. We need an authoritative answer to whether the SA naming space is IPv4 as a subset of IPv6, or totally skew between IPv4 and IPv6. Then we can make the MIB match it. I don't see TDomain/TAddress as working for this, since these are just addresses, not addresses with UDP ports. (At least in the SA's.) From owner-ipsec Thu Nov 19 12:32:02 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA23595 for ipsec-outgoing; Thu, 19 Nov 1998 12:31:30 -0500 (EST) Message-ID: <70C20C1647EBD11183F800805FA67B4338BFE7@vpnet.com> From: Sumit Vakil To: ipsec@tis.com Subject: RE: Bundle or not in negotiation Date: Thu, 19 Nov 1998 09:50:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Of course you don't have to do that. You can do multiple > negotiations > > and be inefficient if you want. But if you do negotiate > things seperately > > then what do you do with the packets that are queued up > after the 1st > > negotiation is finish but before the 2nd is finished? > > > > If your plumbing can't handle a set of requirements and can > only dole > > things out one at a time and your policy says "AH AND ESP > for traffic > > from foo to bar with frobnitz as the peer" then you'll do > an AH negotiation > > with frobnitz and then a separate ESP negotiation with > frobnitz. When the > > first is finished whaddya do? Send packets with AH but not > ESP? Or do > > you wait until all negotiations are finished? If the latter > then what's > > the point of doing them separate. I'm missing something. > > > Assume i wait until all negotiations are finished. What is wrong with > negotiating them separately, except for some slow performance > ? Assume the > policy does not mandate unique SAs i.e sharing of SAs are > permitted, what > is wrong in having AH and ESP SA separately ? Some other > connection may want > to use just the AH SA and not the ESP SA. Some connection may > want use both > of them. Is there any reason to bundle them together ? > > -mohan > > I think that the ISAKMP document is very clear about this. From section 2.1 "Protection Suite: A protection suite is a list of the security services that must be applied by various security protocols. For example, a pro- tection suite may consist of DES encryption in IP ESP, and keyed MD5 in IP AH. All of the protections in a suite must be treated as a single unit. This is necessary because security services in different security pro- tocols can have subtle interactions, and the effects of a suite must be analyzed and verified as a whole." and "Proposal: A proposal is a list, in decreasing order of preference, of the protection suites that a system considers acceptable to protect traffic under a given situation." >From section 2.2 "Figure 1 is a high level view of the placement of ISAKMP within a system context in a network architecture. An important part of negotiating secu- rity services is to consider the entire ``stack'' of individual SAs as a unit. This is referred to as a ``protection suite''." If my security policy requires that a certain pair of phase 2 ids be protected by both ESP and AH, I'm going to expect the peer to propose a combination of the two. If someone proposes only AH or only ESP for that id pair, then that is a violation of my security policy and I'm going to reject the offer. Under no circumstances do I want to send or receive data between those two ids with inadequate protection. Besides, I have no control over what the peer does. Suppose that the initiator proposes only AH and the responder accepts it. The responder knows that ESP is also required. At that point, does it wait for a second exchange from the initiator? If yes, how long? Or does it just start a fresh exchange with the initiator? That's just going to make the overlapping exchanges issue more of a problem. Sumit A. Vakil VPNet Technologies, Inc. From owner-ipsec Thu Nov 19 12:53:06 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA23718 for ipsec-outgoing; Thu, 19 Nov 1998 12:51:28 -0500 (EST) Message-ID: <36545F65.2C751ABF@redcreek.com> Date: Thu, 19 Nov 1998 10:11:49 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Tim Jenkins CC: John Shriver , ipsec@tis.com Subject: Re: FW: IPSec Monitoring MIB works for IPv4 only? References: <319A1C5F94C8D11192DE00805FBBADDF595526@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Tim Jenkins wrote: > My mandate was to *quickly* produce a usable MIB. The speed issue requires > some simplification. Who mandated speed over good design? > Further, I have only made a few simplifications: > 2) No method to specify the order of the services per bundle, since the > normal reasonable order is assumed (see some of the previous email on > this). No substantive comment, though my gut reaction is that this may bite us later. > 3) Only 1 phase SA between 2 peers at a time. Bad assumption, just plain wrong. The design provides the capability to maintain an arbitrary number of phase 1 SAs between peers, and this is a useful capability. It should not be restricted. > 4) That IPSec is above IP in a stack. No, IPsec is *in* the IP portion of the stack. If it were above IP, you could not look at the IP headers of incoming packets, as they would already have been stripped. Hence, you could not possibly authenticate them using AH. > > This brings up another issue. I think "tunnel" is not the word to use > > here. I made this point on the ipsec-errors list, and I'll reiterate my reasoning. IPsec is very complex. In order to implement (or just understand) it you must wade through the ARCH, ISAKMP, ESP, AH, DOI, and IKE documents, probably all at the same time, skipping back and forth. You already know what a daunting task this is. Why complicate this further by overloading the word 'tunnel', which is integral to the architecture, in this manner? This only serves to confuse and confound. > > In your own response, you flip between "tunnel" and "bundle". > > Since "bundle" is what is used in the IPSec Architecture document, I > > think it would be a better-chosen word to use for what the > > ipsecSaTable contains. Thus, I'd propose we call it the > > ipsecBundleTable... > > I also wanted to strengthen the concept that bundles are SAs with multiple > services, rather than simply layered SAs. The concept you want to strengthen is wrong - here's the definition from ARCH: A Security Association (SA) is a simplex "connection" that affords security services to the traffic carried by it. Security services are afforded to an SA by the use of AH, or ESP, but not both. If both AH and ESP protection is applied to a traffic stream, then two (or more) SAs are created to afford protection to the traffic stream. Clearly, SAs provide a single service. From owner-ipsec Thu Nov 19 13:00:51 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA23789 for ipsec-outgoing; Thu, 19 Nov 1998 13:00:30 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF5957D4@exchange> From: Tim Jenkins To: Tero Kivinen Cc: ipsec@tis.com Subject: RE: FW: IPSec Monitoring MIB works for IPv4 only? Date: Thu, 19 Nov 1998 13:21:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE13E9.5D0B1780" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE13E9.5D0B1780 Content-Type: text/plain; charset="iso-8859-1" --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@ssh.fi] > Sent: Wednesday, November 18, 1998 6:41 PM > To: Tim Jenkins > Cc: John Shriver; ipsec@tis.com > Subject: RE: FW: IPSec Monitoring MIB works for IPv4 only? > > > Tim Jenkins writes: > > My mandate was to *quickly* produce a usable MIB. The speed > issue requires > > some simplification. Further, I have only made a few > simplifications: > > 3) Only 1 phase SA between 2 peers at a time. > > I don't like this. There can easily be two phase 1 SAs between 2 peers > at a time in case we have simultaneous startup or rekeying going on. > Both ends just start phase I negotiation at the same time, we create > two phase I SAs and both of them are valid and there is know defined > way to select which one of them to leave, and which one to delete. If > we just randomly delete one of them and the other end does the same we > end up without SA at all 50 % of the time. > > This issue has been discuessed earlier in the list, but I don't think > it have been resolved. As far as I can say any of the drafts doesn't > disallow that, or say what you should do to resolve the thing, so it > is going to happen. > > In any case if we end up having (or just want to support them) > multiple ISAKMP SAs how are we going to represent them in the MIB? You describe a problem that is not the MIB's problem: how to deal with multiple phase 1 SAs. It's only the MIB's problem if we must support multiple phase 1 SAs. Can anyone tell me why we need to support multiple phase 1 SAs? Obviously, there will be transient times when there are multiple SAs during re-keying of a phase 1 SA. However, I don't see a need for this condition to persist. My impression of the needs for negotiating a second phase 1 SA: 1) A new phase 2 SA needs to be established under the protection of a phase 1 SA that requires more protection than an existing phase 1 SA with the same peer. 2) Pending expiration of the existing phase 1 SA. In both cases, the old SA can be deleted once the new one is up. Additionally, since I made the assumption of a single SA, I could put the phase 1 virtual tunnel stats/characteristics in the same table as the phase 1 SA stats/characteristics. > > Also for mobile user case it would be nice not to tie ISAKMP SA to > ip-addresses but to tie them to cookies. Now the MIB uses the > ip-address and port numbers to identify the ISAKMP SA. Yes, because it's supposed to be a virtual tunnel ID, not an SA ID. In reality, the tunnel ID is the authenticated phase 1 ID. Should the index for this table be changed to the phase 1 ID? > > For mobile users case it would be usefull to reuse old ISAKMP SA to > IPsec gateway even if the ip-addresses of the mobile user has already > changed. Currently only thing that requires destination address to > remain constant between two phase II negotiations is the cookie > generation algorithm (and that is quite easy to change, and it is > implementation issue). I recall that dealing with mobile IP was to be done later. Since the mandate of *this* MIB was to get something out quickly that was usable, I intentionally avoided these complications. > > Only cookies really distinguish the ISAKMP SA. I would change the > ISAKMP SA table to be two layers just like the ipsec sa table, so that > the first table is uniquely identified by the phase I identities > (ipsecIkeTunnelTable), and the second table is uniquely > identified by the > ISAKMP SA cookies (ipsecIkeSaTable). Yes, the cookies identify the SA, but not the phase 1 virtual tunnel. If we insist on support for multiple phase 1 SAs, I would break out the SA specific stuff from the IKE table like I did with the phase 2 SA specific stuff. In that case, you'd end up with four tables, not three. > > > This would require the addition of an IP address added to every > > 'ipsecSaEntry', > > causing it to be duplicated, since it's already in the > 'ipsecIkeSaTable'. > > Yes, I would think that would be wise anyways, if we consider this MIB > to be used for other things that VPN also. For mobile user the ipsec > address might change quite quickly and it might have multiple ipsec > tunnels with different ip-address up at the same time (I am talking > about mobile user with radio link connection, not necessary road > warrior case). Again, I wanted to leave mobile out for now. Wasn't someone supposed to write something up about IPSec and Mobile IP? If they did, can someone point me to it? (Thanks.) > > > Further comments on this are invited... > > I am just reading the MIB first time, and I do have some questions and > comments. > ... > > ipsecIkeSaDifHelFieldSize? How is this defined? What is the field size > for MODP groups? Is this really needed? (I think the field size > attribute in the ike is completely unused, because the field size can > be seen from the polynomial anyways). It was just an exercise in completeness. It comes from the Field Size class described in Appendix A of [IKE]. I'm happy to remove it if no one objects, if its use is either non-existent or unimportant. > > ipsecIkeSaPFS: If your policy doesn't mandate anything then I assume > that you set this to TRUE as long as all SAs are created using PFS and > set it to FALSE when you have first SA that is not using PFS? > > I don't really think this variable belongs here at all, because in the > beginning you say that this document doesn't specify the policy, and > this is clearly policy issue, there is nothing to prevent using one > ISAKMP SA to create both PFS and non-PFS ipsec SAs. Good points. It was intended to indicate that SAs created within this phase 1 SA use PFS (as set by policy). A more appropriate place would be with the SA itself then, if it's wanted at all. Comments? > > Why is the ipsecIkeSaTrafficLimit limited to Gauge32? Note that the > current IKE draft doesn't limit the size of the life duration > attribute (it may be variable length, although I assume all of the > implementations will fail, if someone tries to send 64-bit number to > them...). It's actually an Integer (misprint in -02). Anyway, at 32 bits, I figured 4,294,967,295 1024 byte blocks would be a reasonable upper limit for expressing this. > > Why are the *Packets counters Counter32, instead of Counter64? We may > end up using more than 2^32 packets also... It takes for 100 MB > ethernet with small packets only less than an half a day to do it. > That's fine. And what will it be over the Internet? Even over a T3 with normal traffic, it's still likely more than a day. I really don't want to proliferate 64-bit values unless they're really needed. There are still many users of SNMPv1 that can't support 64-bit values, so I don't want to make the translation any more different than necessary. > ipsecIkeSaDecryptErrors: How you defined such? Normally that might be > guessed from the INVALID-PAYLOAD-TYPE, DOI-NOT-SUPPORTED, > PAYLOAD-MALFORMED, BAD-PROPOSAL-SYNTAX error codes or something else. > I think it might be quite hard to categorize errors to be decryption > errors. At least there should be list of errors that are considered > decryption errors. > > ipsecIkeSaHashErrors: I assume this doesn't contain the > AUTHENTICATION-FAILED error codes that are generated when phase I > authentication hash failes, only to the INVALID-HASH-INFORMATION that > are generated if the hash lenght is invalid etc. The > draft-ietf-ipsec-isakmp-10.txt says you should send > AUTHENTICATION-FAILED error code if the hash comparision fails. > > I assume this should really be ipsecIkeSaAuthErrors if you want to > calculate authentication errors. > These are SA processing errors, just like in IPSec. In other words, the decryption of the payload of an encrypted ISAKMP packet lead to a bad length or whatever. The hash calculation for the authentication of the *packet* failed. These count packet errors in the control stream (the IKE virtual tunnel) as performed by the phase 1 SA. They are not protocol or negotiation errors. ... > > ipsecTunnelLocalAddressOrStart, ipsecTunnelLocalAddressMaskOrEnd: > where is the type of these fields given? How does the reader know if > they should treat this range, subnet, or just one ip address? If the maskOrEnd is a mask, it's a mask and the AddressOrStart is the subnet. A 32-bit mask means the AddressOrStart is an address. Otherwise, it's a range. > > "ipsecIkeSaEncAlg - Encryption Algorithm" defines DES40-CBC 65001, > which is not defined by the DOI (and should not be defined by the DOI, > because is it from the private range). As I stated in the appendix, they are not part of the MIB. They are reproduced for information only. The values for DES40 come from a Cisco document, and were used at the last interoperability workshop by both Microsoft and TimeStep. > > Also because the MIB doesn't provide the vendor id information (I > think it should!) there is no way to know whose private number space > we are using if there are any numbers from the private number space. The DES40 values are not private number space; they are in co-operating implementations number space. > ... > It seems to be odd that group 5 is missing, even when it is much more > widely supported than DES40 :-) At release time of -02 of the MIB, there was a document for DES40. I had not seen the Group 5 document at that time. Maybe I should put in groups 6, 7, 8, 9, 10 etc. now? :-) ------_=_NextPart_001_01BE13E9.5D0B1780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: FW: IPSec Monitoring MIB works for IPv4 only?

---
Tim = Jenkins           = ;            = TimeStep Corporation
tjenkins@timestep.com       =    http://www.timestep.com
(613) 599-3610 = x4304           &= nbsp;   Fax: (613) 599-3617


> -----Original Message-----
> From: Tero Kivinen [mailto:kivinen@ssh.fi]
> Sent: Wednesday, November 18, 1998 6:41 = PM
> To: Tim Jenkins
> Cc: John Shriver; ipsec@tis.com
> Subject: RE: FW: IPSec Monitoring MIB works for = IPv4 only?
>
>
> Tim Jenkins writes:
> > My mandate was to *quickly* produce a = usable MIB. The speed
> issue requires
> > some simplification. Further, I have only = made a few
> simplifications:
> > 3) Only 1 phase SA between 2 peers at a = time.
>
> I don't like this. There can easily be two = phase 1 SAs between 2 peers
> at a time in case we have simultaneous startup = or rekeying going on.
> Both ends just start phase I negotiation at the = same time, we create
> two phase I SAs and both of them are valid and = there is know defined
> way to select which one of them to leave, and = which one to delete. If
> we just randomly delete one of them and the = other end does the same we
> end up without SA at all 50 % of the = time.
>
> This issue has been discuessed earlier in the = list, but I don't think
> it have been resolved. As far as I can say any = of the drafts doesn't
> disallow that, or say what you should do to = resolve the thing, so it
> is going to happen.
>
> In any case if we end up having (or just want = to support them)
> multiple ISAKMP SAs how are we going to = represent them in the MIB?

You describe a problem that is not the MIB's problem: = how to deal with
multiple phase 1 SAs. It's only the MIB's problem if = we must support
multiple phase 1 SAs.

Can anyone tell me why we need to support multiple = phase 1 SAs?
Obviously, there will be transient times when there = are multiple
SAs during re-keying of a phase 1 SA. However, I = don't see a need
for this condition to persist.

My impression of the needs for negotiating a second = phase 1 SA:

1) A new phase 2 SA needs to be established under the = protection of
a phase 1 SA that requires more protection than an = existing phase 1
SA with the same peer.
2) Pending expiration of the existing phase 1 = SA.

In both cases, the old SA can be deleted once the new = one is up.

Additionally, since I made the assumption of a single = SA, I could
put the phase 1 virtual tunnel stats/characteristics = in the same
table as the phase 1 SA = stats/characteristics.

>
> Also for mobile user case it would be nice not = to tie ISAKMP SA to
> ip-addresses but to tie them to cookies. Now = the MIB uses the
> ip-address and port numbers to identify the = ISAKMP SA.

Yes, because it's supposed to be a virtual tunnel ID, = not an SA ID.
In reality, the tunnel ID is the authenticated phase = 1 ID. Should
the index for this table be changed to the phase 1 = ID?

>
> For mobile users case it would be usefull to = reuse old ISAKMP SA to
> IPsec gateway even if the ip-addresses of the = mobile user has already
> changed. Currently only thing that requires = destination address to
> remain constant between two phase II = negotiations is the cookie
> generation algorithm (and that is quite easy to = change, and it is
> implementation issue).

I recall that dealing with mobile IP was to be done = later. Since
the mandate of *this* MIB was to get something out = quickly that
was usable, I intentionally avoided these = complications.

>
> Only cookies really distinguish the ISAKMP SA. = I would change the
> ISAKMP SA table to be two layers just like the = ipsec sa table, so that
> the first table is uniquely identified by the = phase I identities
> (ipsecIkeTunnelTable), and the second table is = uniquely
> identified by the
> ISAKMP SA cookies (ipsecIkeSaTable).

Yes, the cookies identify the SA, but not the phase 1 = virtual tunnel.
If we insist on support for multiple phase 1 SAs, I = would break out
the SA specific stuff from the IKE table like I did = with the phase 2
SA specific stuff. In that case, you'd end up with = four tables, not
three.

>
> > This would require the addition of an IP = address added to every
> > 'ipsecSaEntry',
> > causing it to be duplicated, since it's = already in the
> 'ipsecIkeSaTable'.
>
> Yes, I would think that would be wise anyways, = if we consider this MIB
> to be used for other things that VPN also. For = mobile user the ipsec
> address might change quite quickly and it might = have multiple ipsec
> tunnels with different ip-address up at the = same time (I am talking
> about mobile user with radio link connection, = not necessary road
> warrior case).

Again, I wanted to leave mobile out for now. Wasn't = someone supposed
to write something up about IPSec and Mobile IP? If = they did, can someone
point me to it? (Thanks.)

>
> > Further comments on this are = invited...
>
> I am just reading the MIB first time, and I do = have some questions and
> comments.
>
... <snip>
>
> ipsecIkeSaDifHelFieldSize? How is this defined? = What is the field size
> for MODP groups? Is this really needed? (I = think the field size
> attribute in the ike is completely unused, = because the field size can
> be seen from the polynomial anyways).

It was just an exercise in completeness. It comes = from the Field Size class
described in Appendix A of [IKE]. I'm happy to = remove it if no one objects,
if its use is either non-existent or = unimportant.

>
> ipsecIkeSaPFS: If your policy doesn't mandate = anything then I assume
> that you set this to TRUE as long as all SAs = are created using PFS and
> set it to FALSE when you have first SA that is = not using PFS?
>
> I don't really think this variable belongs here = at all, because in the
> beginning you say that this document doesn't = specify the policy, and
> this is clearly policy issue, there is nothing = to prevent using one
> ISAKMP SA to create both PFS and non-PFS ipsec = SAs.

Good points. It was intended to indicate that SAs = created within this
phase 1 SA use PFS (as set by policy). A more = appropriate place would
be with the SA itself then, if it's wanted at all. = Comments?

>
> Why is the ipsecIkeSaTrafficLimit limited to = Gauge32? Note that the
> current IKE draft doesn't limit the size of the = life duration
> attribute (it may be variable length, although = I assume all of the
> implementations will fail, if someone tries to = send 64-bit number to
> them...).

It's actually an Integer (misprint in -02). Anyway, = at 32 bits,
I figured 4,294,967,295 1024 byte blocks would be a = reasonable upper
limit for expressing this.

>
> Why are the *Packets counters Counter32, = instead of Counter64? We may
> end up using more than 2^32 packets also... It = takes for 100 MB
> ethernet with small packets only less than an = half a day to do it.
>

That's fine. And what will it be over the Internet? = Even over a T3
with normal traffic, it's still likely more than a = day.

I really don't want to proliferate 64-bit values = unless
they're really needed. There are still many users of = SNMPv1 that
can't support 64-bit values, so I don't want to make = the translation
any more different than necessary.

> ipsecIkeSaDecryptErrors: How you defined such? = Normally that might be
> guessed from the INVALID-PAYLOAD-TYPE, = DOI-NOT-SUPPORTED,
> PAYLOAD-MALFORMED, BAD-PROPOSAL-SYNTAX error = codes or something else.
> I think it might be quite hard to categorize = errors to be decryption
> errors. At least there should be list of errors = that are considered
> decryption errors.
>
> ipsecIkeSaHashErrors: I assume this doesn't = contain the
> AUTHENTICATION-FAILED error codes that are = generated when phase I
> authentication hash failes, only to the = INVALID-HASH-INFORMATION that
> are generated if the hash lenght is invalid = etc. The
> draft-ietf-ipsec-isakmp-10.txt says you should = send
> AUTHENTICATION-FAILED error code if the hash = comparision fails.
>
> I assume this should really be = ipsecIkeSaAuthErrors if you want to
> calculate authentication errors.
>

These are SA processing errors, just like in IPSec. = In other words,
the decryption of the payload of an encrypted ISAKMP = packet lead
to a bad length or whatever. The hash calculation = for the authentication
of the *packet* failed.

These count packet errors in the control stream (the = IKE virtual tunnel)
as performed by the phase 1 SA. They are not = protocol or negotiation
errors.

... <snip>
>
> ipsecTunnelLocalAddressOrStart, = ipsecTunnelLocalAddressMaskOrEnd:
> where is the type of these fields given? How = does the reader know if
> they should treat this range, subnet, or just = one ip address?

If the maskOrEnd is a mask, it's a mask and the = AddressOrStart is the
subnet. A 32-bit mask means the AddressOrStart is an = address. Otherwise,
it's a range.

>
> "ipsecIkeSaEncAlg - Encryption = Algorithm" defines DES40-CBC 65001,
> which is not defined by the DOI (and should not = be defined by the DOI,
> because is it from the private range).

As I stated in the appendix, they are not part of the = MIB. They
are reproduced for information only.

The values for DES40 come from a Cisco document, and = were used at
the last interoperability workshop by both Microsoft = and TimeStep.

>
> Also because the MIB doesn't provide the vendor = id information (I
> think it should!) there is no way to know whose = private number space
> we are using if there are any numbers from the = private number space.

The DES40 values are not private number space; they = are in co-operating
implementations number space.

>
...<snip further comments about DES40>
> It seems to be odd that group 5 is missing, = even when it is much more
> widely supported than DES40 :-)

At release time of -02 of the MIB, there was a = document for DES40. I
had not seen the Group 5 document at that time. = Maybe I should put in
groups 6, 7, 8, 9, 10 etc. now? :-)

------_=_NextPart_001_01BE13E9.5D0B1780-- From owner-ipsec Thu Nov 19 13:15:57 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA23922 for ipsec-outgoing; Thu, 19 Nov 1998 13:15:31 -0500 (EST) Message-ID: <365464EF.745F8459@redcreek.com> Date: Thu, 19 Nov 1998 10:35:27 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Mohan Parthasarathy CC: ipsec@tis.com Subject: Re: Bundle or not in negotiation References: <199811182245.OAA16609@locked.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Mohan Parthasarathy wrote: > Assume i wait until all negotiations are finished. What is wrong with > negotiating them separately, except for some slow performance ? Assume the > policy does not mandate unique SAs i.e sharing of SAs are permitted, what > is wrong in having AH and ESP SA separately ? Some other connection may want > to use just the AH SA and not the ESP SA. Some connection may want use both > of them. Is there any reason to bundle them together ? > This nails another point that's been nagging at me lately: the architecture explicitly permits sharing of SAs, which I take to mean between different endpoints which match the policy rule used to instantiate the SAs to begin with. However, there is no way (that I can see) to negotiate this in IKE. That is, once the SA is instantiated, there doesn't seem to be any way to negotiate the addition of more endpoints to it. It appears that fresh SAs must be negotiated, with new keys, etc. My first thought was that I could just pass the SPI of the instantiated SA in the later negotiations, but there's no way to indicate that the original keying material should be shared. Am I way out there on this, or should we think about a way to permit this in IKE? From owner-ipsec Thu Nov 19 13:36:06 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA23991 for ipsec-outgoing; Thu, 19 Nov 1998 13:35:32 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF59580E@exchange> From: Tim Jenkins To: "Scott G. Kelly" Cc: ipsec@tis.com Subject: RE: FW: IPSec Monitoring MIB works for IPv4 only? Date: Thu, 19 Nov 1998 13:55:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE13EE.31BA7F50" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE13EE.31BA7F50 Content-Type: text/plain; charset="iso-8859-1" --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Scott G. Kelly [mailto:skelly@redcreek.com] > Sent: Thursday, November 19, 1998 1:12 PM > To: Tim Jenkins > Cc: John Shriver; ipsec@tis.com > Subject: Re: FW: IPSec Monitoring MIB works for IPv4 only? > > > Tim Jenkins wrote: > > My mandate was to *quickly* produce a usable MIB. The speed > issue requires > > some simplification. > > Who mandated speed over good design? Gee, nice snipe, Scott. Got anything constructive to say? > > > Further, I have only made a few simplifications: > > > > 2) No method to specify the order of the services per > bundle, since the > > normal reasonable order is assumed (see some of the > previous email on > > this). > > No substantive comment, though my gut reaction is that this > may bite us > later. This, and I've said this before, was apparently already decided long ago. Dan Harkins has posted it at least twice, and further, the architecture document itself says that ESP must be applied before AH. This is perfectly enforcable in the context of a protection suite as defined by the isakmp draft. See the "Appendix" below. > > > 3) Only 1 phase SA between 2 peers at a time. > > Bad assumption, just plain wrong. The design provides the > capability to > maintain an arbitrary number of phase 1 SAs between peers, > and this is a > useful capability. It should not be restricted. Having cut my questions as to why you should support more than one, you avoid having to answer, I guess. The reality is, unless I can be convinced I need to keep more than one, as soon as you successfully negotiate a new phase 1 with me, there is nothing in the documents that says I can't send you a delete notification for the old and stop using it. Hell, I'm not even *required* to send you a delete notification, I can just stop using it. So I ask again: Why *should* we support more than one phase 1 SA? ("Because we can" is not a good enough answer.) > > > 4) That IPSec is above IP in a stack. > > No, IPsec is *in* the IP portion of the stack. If it were > above IP, you > could not look at the IP headers of incoming packets, as they would > already have been stripped. Hence, you could not possibly authenticate > them using AH. > Now you're arguing implementation versus conceptual. Conceptually, since many implementations apply IPSec to non-fragmented IP packets, it may be viewed as on top. In any case, it doesn't change the logic for not binding the virtual phase 2 tunnels to the interface MIB. It's implementation specific, so it can be handled in other ways. > > > > This brings up another issue. I think "tunnel" is not > the word to use > > > here. > > I made this point on the ipsec-errors list, and I'll reiterate my > reasoning. IPsec is very complex. In order to implement (or just > understand) it you must wade through the ARCH, ISAKMP, ESP, > AH, DOI, and > IKE documents, probably all at the same time, skipping back and forth. > You already know what a daunting task this is. Why complicate this > further by overloading the word 'tunnel', which is integral to the > architecture, in this manner? This only serves to confuse and > confound. And the last time you raised it I asked you for a better word. If you responded, I didn't see it. So what was your suggestion, anyway? > > > > In your own response, you flip between "tunnel" and "bundle". > > > Since "bundle" is what is used in the IPSec Architecture > document, I > > > think it would be a better-chosen word to use for what the > > > ipsecSaTable contains. Thus, I'd propose we call it the > > > ipsecBundleTable... > > > > > > I also wanted to strengthen the concept that bundles are > SAs with multiple > > services, rather than simply layered SAs. > > The concept you want to strengthen is wrong - here's the > definition from > ARCH: > > A Security Association (SA) is a simplex "connection" that affords > security services to the traffic carried by it. Security services > are afforded to an SA by the use of AH, or ESP, but not both. If > both AH and ESP protection is applied to a traffic stream, then two > (or more) SAs are created to afford protection to the > traffic stream. > > Clearly, SAs provide a single service. > Yes, but protection suites don't. The real mistake I made on this issue was using the more generic term "SA bundle" when I should have said "protection suite" as defined in ISAKMP, and further compounding it by calling the phase 2 protection suite table an SA table. So, the ipsecSaTable should really be called ipsecProtectionSuiteTable. Is that any better? ==> Appendix to this mail: >From ISAKMP Protection Suite: A protection suite is a list of the security services that must be applied by various security protocols. For example, a pro- tection suite may consist of DES encryption in IP ESP, and keyed MD5 in IP AH. All of the protections in a suite must be treated as a single unit. This is necessary because security services in different security pro- tocols can have subtle interactions, and the effects of a suite must be analyzed and verified as a whole. >From ARCH Case 1. The case of providing end-to-end security between 2 hosts across the Internet (or an Intranet). ==================================== | | H1* ------ (Inter/Intranet) ------ H2* Note that either transport or tunnel mode can be selected by the hosts. So the headers in a packet between H1 and H2 could look like any of the following: Transport Tunnel ----------------- --------------------- 1. [IP1][AH][upper] 4. [IP2][AH][IP1][upper] 2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper] 3. [IP1][AH][ESP][upper] Note that there is no requirement to support general nesting, but in transport mode, both AH and ESP can be applied to the packet. In this event, the SA establishment procedure MUST ensure that first ESP, then AH are applied to the packet. ------_=_NextPart_001_01BE13EE.31BA7F50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: FW: IPSec Monitoring MIB works for IPv4 only?

---
Tim = Jenkins           = ;            = TimeStep Corporation
tjenkins@timestep.com       =    http://www.timestep.com
(613) 599-3610 = x4304           &= nbsp;   Fax: (613) 599-3617


> -----Original Message-----
> From: Scott G. Kelly [mailto:skelly@redcreek.com]
> Sent: Thursday, November 19, 1998 1:12 = PM
> To: Tim Jenkins
> Cc: John Shriver; ipsec@tis.com
> Subject: Re: FW: IPSec Monitoring MIB works for = IPv4 only?
>
>
> Tim Jenkins wrote:
> > My mandate was to *quickly* produce a = usable MIB. The speed
> issue requires
> > some simplification.
>
> Who mandated speed over good design?

Gee, nice snipe, Scott. Got anything constructive to = say?

>
> > Further, I have only made a few = simplifications:
> <trimmed...>
>
> > 2) No method to specify the order of the = services per
> bundle, since the
> >    normal reasonable order = is assumed (see some of the
> previous email on
> >    this).
>
> No substantive comment, though my gut reaction = is that this
> may bite us
> later.

This, and I've said this before, was apparently = already decided
long ago. Dan Harkins has posted it at least twice, = and further,
the architecture document itself says that ESP must = be applied
before AH. This is perfectly enforcable in the = context of a
protection suite as defined by the isakmp = draft.

See the "Appendix" below.

>
> > 3) Only 1 phase SA between 2 peers at a = time.
>
> Bad assumption, just plain wrong. The design = provides the
> capability to
> maintain an arbitrary number of phase 1 SAs = between peers,
> and this is a
> useful capability. It should not be = restricted.

Having cut my questions as to why you should support = more than
one, you avoid having to answer, I guess.

The reality is, unless I can be convinced I need to = keep
more than one, as soon as you successfully negotiate = a new
phase 1 with me, there is nothing in the documents = that says
I can't send you a delete notification for the old = and stop
using it. Hell, I'm not even *required* to send you = a delete
notification, I can just stop using it.

So I ask again: Why *should* we support more than one = phase 1
SA? ("Because we can" is not a good enough = answer.)

>
> > 4) That IPSec is above IP in a = stack.
>
> No, IPsec is *in* the IP portion of the stack. = If it were
> above IP, you
> could not look at the IP headers of incoming = packets, as they would
> already have been stripped. Hence, you could = not possibly authenticate
> them using AH.
>

Now you're arguing implementation versus conceptual. = Conceptually,
since many implementations apply IPSec to = non-fragmented IP packets,
it may be viewed as on top.

In any case, it doesn't change the logic for not = binding the virtual
phase 2 tunnels to the interface MIB. It's = implementation specific,
so it can be handled in other ways.

> <trimmed...>
> > > This brings up another issue.  I = think "tunnel" is not
> the word to use
> > > here.
>
> I made this point on the ipsec-errors list, and = I'll reiterate my
> reasoning. IPsec is very complex. In order to = implement (or just
> understand) it you must wade through the ARCH, = ISAKMP, ESP,
> AH, DOI, and
> IKE documents, probably all at the same time, = skipping back and forth.
> You already know what a daunting task this is. = Why complicate this
> further by overloading the word 'tunnel', which = is integral to the
> architecture, in this manner? This only serves = to confuse and
> confound.

And the last time you raised it I asked you for a = better word.
If you responded, I didn't see it. So what was your = suggestion,
anyway?

>
> > > In your own response, you flip = between "tunnel" and "bundle".
> > > Since "bundle" is what is = used in the IPSec Architecture
> document, I
> > > think it would be a better-chosen = word to use for what the
> > > ipsecSaTable contains.  Thus, = I'd propose we call it the
> > > ipsecBundleTable...
> >
> <trimmed...>
>
> > I also wanted to strengthen the concept = that bundles are
> SAs with multiple
> > services, rather than simply layered = SAs.
>
> The concept you want to strengthen is wrong - = here's the
> definition from
> ARCH:
>
>    A Security Association (SA) = is a simplex "connection" that affords
>    security services to the = traffic carried by it.  Security services
>    are afforded to an SA by the = use of AH, or ESP, but not both.  If
>    both AH and ESP protection is = applied to a traffic stream, then two
>    (or more) SAs are created to = afford protection to the
> traffic stream.
>
> Clearly, SAs provide a single service.
>

Yes, but protection suites don't. The real mistake I = made on this
issue was using the more generic term "SA = bundle" when I should
have said "protection suite" as defined in = ISAKMP, and further
compounding it by calling the phase 2 protection = suite table
an SA table.

So, the ipsecSaTable should really be called = ipsecProtectionSuiteTable.
Is that any better?

=3D=3D>

Appendix to this mail:

From ISAKMP


Protection Suite: A protection suite is a list of the = security services
that must be applied by various security = protocols.  For example, a pro-
tection suite may consist of DES encryption in IP = ESP, and keyed MD5 in IP
AH. All of the protections in a suite must be = treated as a single unit.
This is necessary because security services in = different security pro-
tocols can have subtle interactions, and the effects = of a suite must be
analyzed and verified as a whole.

From ARCH

   Case 1.  The case of providing = end-to-end security between 2 hosts
        across = the Internet (or an Intranet).

          &nb= sp;      = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
          &nb= sp;      = |            = ;            = ;          |
          &nb= sp;     H1* ------ (Inter/Intranet) ------ = H2*

        Note that = either transport or tunnel mode can be selected by the
        = hosts.  So the headers in a packet between H1 and H2 could = look
        like any = of the following:

          &nb= sp;       = Transport          &nb= sp;       Tunnel
          &nb= sp;  = -----------------          = ---------------------
          &nb= sp;  1. [IP1][AH][upper]        = 4. [IP2][AH][IP1][upper]
          &nb= sp;  2. [IP1][ESP][upper]       5. = [IP2][ESP][IP1][upper]
          &nb= sp;  3. [IP1][AH][ESP][upper]

        Note that = there is no requirement to support general nesting,
        but in = transport mode, both AH and ESP can be applied to the
        = packet.  In this event, the SA establishment procedure MUST
        ensure = that first ESP, then AH are applied to the packet.


------_=_NextPart_001_01BE13EE.31BA7F50-- From owner-ipsec Thu Nov 19 14:12:09 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA24222 for ipsec-outgoing; Thu, 19 Nov 1998 14:09:32 -0500 (EST) Message-Id: <199811191928.LAA03825@dharkins-ss20.cisco.com> To: Tim Jenkins cc: Tero Kivinen , ipsec@tis.com Subject: Re: FW: IPSec Monitoring MIB works for IPv4 only? In-reply-to: Your message of "Thu, 19 Nov 1998 13:21:02 EST." <319A1C5F94C8D11192DE00805FBBADDF5957D4@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3823.911503697.1@cisco.com> Date: Thu, 19 Nov 1998 11:28:17 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk On Thu, 19 Nov 1998 13:21:02 EST you wrote > > "ipsecIkeSaEncAlg - Encryption Algorithm" defines DES40-CBC 65001, > > which is not defined by the DOI (and should not be defined by the DOI, > > because is it from the private range). > > As I stated in the appendix, they are not part of the MIB. They > are reproduced for information only. > > The values for DES40 come from a Cisco document, and were used at > the last interoperability workshop by both Microsoft and TimeStep. But that document isn't in the WG's batch of I-Ds and no matter who wrote it, numbers from that range can't be defined to be any specific algorithm. 65001 might be DES40 for some but it might be the Hasty Pudding Cipher for others. > > Also because the MIB doesn't provide the vendor id information (I > > think it should!) there is no way to know whose private number space > > we are using if there are any numbers from the private number space. > > The DES40 values are not private number space; they are in co-operating > implementations number space. That *is* the private number space and all values there are intentionally undefined. Dan. From owner-ipsec Thu Nov 19 14:12:09 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA24230 for ipsec-outgoing; Thu, 19 Nov 1998 14:10:32 -0500 (EST) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81720@RED-MSG-50> From: Richard Draves To: "'Tim Jenkins'" Cc: ipsec@tis.com Subject: RE: FW: IPSec Monitoring MIB works for IPv4 only? Date: Thu, 19 Nov 1998 11:28:51 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk >Yes, but protection suites don't. The real mistake I made on this >issue was using the more generic term "SA bundle" when I should >have said "protection suite" as defined in ISAKMP, and further >compounding it by calling the phase 2 protection suite table >an SA table. > >So, the ipsecSaTable should really be called ipsecProtectionSuiteTable. >Is that any better? I thought this is supposed to be an IPsec MIB, not an ISAKMP MIB. What about implementations that aren't using ISAKMP? Rich From owner-ipsec Thu Nov 19 14:18:19 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA24288 for ipsec-outgoing; Thu, 19 Nov 1998 14:17:32 -0500 (EST) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81721@RED-MSG-50> From: Richard Draves To: "'Sumit Vakil'" Cc: ipsec@tis.com Subject: RE: Bundle or not in negotiation Date: Thu, 19 Nov 1998 11:36:17 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk > If my security policy requires that a certain pair of phase 2 ids be > protected by both ESP and AH, I'm going to expect the peer to > propose a > combination of the two. If someone proposes only AH or only > ESP for that id > pair, then that is a violation of my security policy and I'm > going to reject > the offer. Under no circumstances do I want to send or > receive data between > those two ids with inadequate protection. Besides, I have no > control over > what the peer does. Suppose that the initiator proposes only > AH and the > responder accepts it. The responder knows that ESP is also > required. At > that point, does it wait for a second exchange from the > initiator? If yes, > how long? Or does it just start a fresh exchange with the initiator? > That's just going to make the overlapping exchanges issue > more of a problem. I agree with Markku. It should be possible to negotiate separately the two SAs in a bundle, even when both SAs have the same endpoints. Yes, you will not send or receive data unless it is protected by both SAs, but that is enforced separately. (For example, when receiving the data, it's the inbound SPD verification described in section 5.2 of the IPsec architecture spec.) Since there appear to be different opinions on this question, I think there's serious interoperability problem lurking here. Rich From owner-ipsec Thu Nov 19 14:40:01 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA24375 for ipsec-outgoing; Thu, 19 Nov 1998 14:38:43 -0500 (EST) Message-ID: <36547862.28B57715@redcreek.com> Date: Thu, 19 Nov 1998 11:58:26 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Tim Jenkins CC: ipsec@tis.com Subject: Re: FW: IPSec Monitoring MIB works for IPv4 only? References: <319A1C5F94C8D11192DE00805FBBADDF59580E@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Tim Jenkins wrote: > > Tim Jenkins wrote: > > > My mandate was to *quickly* produce a usable MIB. The speed > > issue requires > > > some simplification. > > > > Who mandated speed over good design? > > Gee, nice snipe, Scott. Got anything constructive to say? Let's nip this in the bud: This isn't a snipe, it's an honest question. I was at the meeting where you volunteered to produce this draft. I didn't hear any such 'mandate' iterated. Hence, my question stands: who mandated it? > > > > > 2) No method to specify the order of the services per > > bundle, since the > > > normal reasonable order is assumed (see some of the > > previous email on > > > this). > > > > No substantive comment, though my gut reaction is that this > > may bite us > > later. > > This, and I've said this before, was apparently already decided > long ago. Dan Harkins has posted it at least twice, and further, > the architecture document itself says that ESP must be applied > before AH. This is perfectly enforcable in the context of a > protection suite as defined by the isakmp draft. No, the architecture document simply does not require support for any constructs which choose to apply AH first (for whatever reason). I agree that the arch doc is right not to require these, but think it's wrong to make design decisions which preclude them. Further, the isakmp text you quote below doesn't substantiate your point. The 'protection suites' it refers to are within a given protocol, e.g. for ESP the protection suite might be 3DES, HMAC-SHA1. Your argument seems to be that AH and ESP are bundled together in one protection suite. Have I misinterpreted your argument? > > > > > 3) Only 1 phase SA between 2 peers at a time. > > > > Bad assumption, just plain wrong. The design provides the > > capability to > > maintain an arbitrary number of phase 1 SAs between peers, > > and this is a > > useful capability. It should not be restricted. > > Having cut my questions as to why you should support more than > one, you avoid having to answer, I guess. You're being pretty snippy here, Tim. Relax. This is not a battle, this is a constructive discussion. Your view may prevail, or you may come away with a new view. Either way, we're trying to get the best possible design. > The reality is, unless I can be convinced I need to keep > more than one, as soon as you successfully negotiate a new > phase 1 with me, there is nothing in the documents that says > I can't send you a delete notification for the old and stop > using it. Hell, I'm not even *required* to send you a delete > notification, I can just stop using it. > > So I ask again: Why *should* we support more than one phase 1 > SA? ("Because we can" is not a good enough answer.) I think your unspoken assumption here is that all ISAKMP sessions originate and terminate within the same process on each gateway/host. That's not necessarily true. Further, even if the ISAKMP processes are the same, I may want ID PFS for the new SA, so it MUST be independent of the existing one. Must I tear down the existing one, negotiate a new one for PFS, tear that down, and then renegotiate another (non-PFS) SA? > > > 4) That IPSec is above IP in a stack. > > > > No, IPsec is *in* the IP portion of the stack. If it were > > above IP, you > > could not look at the IP headers of incoming packets, as they would > > already have been stripped. Hence, you could not possibly > authenticate > > them using AH. > > > > Now you're arguing implementation versus conceptual. Conceptually, > since many implementations apply IPSec to non-fragmented IP packets, > it may be viewed as on top. I think you need to give this more thought, but let's not waste time on semantics. > > > > > > This brings up another issue. I think "tunnel" is not > > the word to use > > > > here. > > > > I made this point on the ipsec-errors list, and I'll reiterate my > > reasoning. IPsec is very complex. In order to implement (or just > > understand) it you must wade through the ARCH, ISAKMP, ESP, > > AH, DOI, and > > IKE documents, probably all at the same time, skipping back and > forth. > > You already know what a daunting task this is. Why complicate this > > further by overloading the word 'tunnel', which is integral to the > > architecture, in this manner? This only serves to confuse and > > confound. > > And the last time you raised it I asked you for a better word. > If you responded, I didn't see it. So what was your suggestion, > anyway? No, you didn't ask for a better word. Here's the excerpt from that exchange: I said: > > 3) sec 4.1, "IPSec Virtual Tunnels", line 1: "IPSec implementations > > effectively create tunnels..." - the use of 'tunnels' here is quite > > confusing. We have tunnel-mode SAs and transport-mode SAs. Are you > > including both here? If so, perhaps a better term could be chosen. and you replied: > I will elaborate on the concepts of virtual tunnels created by SAs. It > should deal with a lot of the confusion associated > with our over-loaded use of the word 'tunnel'. Nonetheless, I'll give this some thought and see if I can come up with a better conceptualization. > > > I also wanted to strengthen the concept that bundles are > > SAs with multiple > > > services, rather than simply layered SAs. > > > > The concept you want to strengthen is wrong - here's the > > definition from > > ARCH: > > > > A Security Association (SA) is a simplex "connection" that > affords > > security services to the traffic carried by it. Security > services > > are afforded to an SA by the use of AH, or ESP, but not both. If > > > both AH and ESP protection is applied to a traffic stream, then > two > > (or more) SAs are created to afford protection to the > > traffic stream. > > > > Clearly, SAs provide a single service. > > > > Yes, but protection suites don't. The real mistake I made on this > issue was using the more generic term "SA bundle" when I should > have said "protection suite" as defined in ISAKMP, and further > compounding it by calling the phase 2 protection suite table > an SA table. See comments above regarding distinctions between protection suites and SA bundles. ----- I am not sitting here taking shots at you, Tim. I'm an implementer, just like you, and I want the best possible design to come out of this effort. I'm sorry if I've come across as being hostile or obnoxious in any way - it certainly is not intended. Scott From owner-ipsec Thu Nov 19 15:05:30 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA24481 for ipsec-outgoing; Thu, 19 Nov 1998 15:02:46 -0500 (EST) Message-Id: <199811192021.MAA03898@dharkins-ss20.cisco.com> To: msa@hemuli.tte.vtt.fi (Markku Savela) cc: ipsec@tis.com Subject: Re: Bundle or not in negotiation In-reply-to: Your message of "Thu, 19 Nov 1998 18:29:50 +0200." <199811191629.SAA18221@anise.tte.vtt.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3896.911506913.1@cisco.com> Date: Thu, 19 Nov 1998 12:21:53 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk On Thu, 19 Nov 1998 18:29:50 +0200 you wrote > > Unfortunately, I don't know IKE well enough to understand above > statement. My view is totally from IPSEC direction: in this case it > needs SA pair for AH and it needs SA pair for ESP, which both it asks > from the key management separately. Both requests contain full > informations to set them up independently. It is up to key managemnt, > if it wants to combine the negotiations. But, even if combined, what > is it that AH SA negotiation needs from ESP SA negotiation or vice > versa? It doesn't really need anything but you have to express your wishes to the peer as unambiguously as possible. If your wishes are "protect all these packets with both AH and ESP" but you say "protect all these packets with AH" and then at some later time say "protect all these packets with ESP" the peer can two things. He can refuse your AH offer because his policy says he needs ESP in addition to AH and you just offered AH or he could create the AH SA and hope, perhaps in vain, for you to offer ESP later. That's ambiguous and ripe for failure. But by offering them together you're expressing to the peer your wishes: "I want to do these together on this traffic". There is a desire for some to have opportunistic encryptors who have permiscuous policy: I'll do anything with anyone. Now if you offer AH that box will accept that. Then you offer ESP and that box accepts that. But you failed to specify that both AH and ESP has to be together. And that box will probably try to send you packets, which you'll drop, protected by AH or ESP. Even without opportunistic encryptors there can be situations where policy has not been configured symmetrically. I could require ESP for packets and you require AH and ESP. If you offer ESP to me (assume the first acquire you got was for ESP) I'll accept. If you later offer AH to me I won't. I'll send you packets which you'll drop. To me we successfully negotiated but you're droping my packets. By offering policies as bundles your offer is less ambiguous and there is less room for interpretation and therefore failure. > > > The appliation order of IPCOM+ESP+AH is defined by the policy, which > > > *must* specify same order on both sides. > > > Not according to earlier posts, which state that this issue came up > > before. > > This is what I am doing, I am questioning those earlier posts, the > reasoning behind them, because I don't see the need for such > requirement from IPSEC point of view. There is nothing in the KERNEL > IPSEC architecture that demands ordering or the negotiations. The > bundle attached to the policy selector defines the order of SAs to > apply. The requirements are not imposed on IPSec so there is no reason to look at this soley from an IPSec point-of-view. The requirements are on IKE: you have to negotiate bundles together in one negotiation. You can't argue about negotiation requirements unless you look at them from the perspective of negotiation! You're right. Nothing in your kernel imposes any demands on negotiation. But you can't expect there to be no demands on negotiation because of that. Dan. From owner-ipsec Thu Nov 19 15:13:16 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA24527 for ipsec-outgoing; Thu, 19 Nov 1998 15:10:48 -0500 (EST) Date: Thu, 19 Nov 1998 15:29:13 -0500 Message-Id: <199811192029.PAA18303@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: tjenkins@TimeStep.com Cc: ipsec@tis.com Subject: RE: FW: IPSec Monitoring MIB works for IPv4 only? References: <319A1C5F94C8D11192DE00805FBBADDF5957D4@exchange> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk > > -----Original Message----- > > From: Tero Kivinen [mailto:kivinen@ssh.fi] > > > In any case if we end up having (or just want to support them) > > multiple ISAKMP SAs how are we going to represent them in the MIB? > > You describe a problem that is not the MIB's problem: how to deal with > multiple phase 1 SAs. It's only the MIB's problem if we must support > multiple phase 1 SAs. > > Can anyone tell me why we need to support multiple phase 1 SAs? > Obviously, there will be transient times when there are multiple > SAs during re-keying of a phase 1 SA. However, I don't see a need > for this condition to persist. The MIB lets you examine the state of the system. If the system can be in this state, the MIB has to be able to deal with that. Arguably it should be a transient state, but even if it is transient it isn't necessarily so short that it won't be visible some time, and it certainly may be visible for unexpectedly long times if something unexpected happened. If I have two SAs at time T and the MIB says it handles only one, and someone asks for "the" SA, what am I supposed to do? Crash? Return one of them chosen at random? Stall until one of them goes away? > > Why is the ipsecIkeSaTrafficLimit limited to Gauge32? Note that the > > current IKE draft doesn't limit the size of the life duration > > attribute (it may be variable length, although I assume all of the > > implementations will fail, if someone tries to send 64-bit number to > > them...). > > It's actually an Integer (misprint in -02). Anyway, at 32 bits, > I figured 4,294,967,295 1024 byte blocks would be a reasonable upper > limit for expressing this. That's Unsigned integer, right? > > Why are the *Packets counters Counter32, instead of Counter64? We may > > end up using more than 2^32 packets also... It takes for 100 MB > > ethernet with small packets only less than an half a day to do it. > > > > That's fine. And what will it be over the Internet? Even over a T3 > with normal traffic, it's still likely more than a day. 32 bit counters have been a really bad idea for many years now. Please, let's not perpetuate this mistake in new MIBs. > > "ipsecIkeSaEncAlg - Encryption Algorithm" defines DES40-CBC 65001, > > which is not defined by the DOI (and should not be defined by the DOI, > > because is it from the private range). > > As I stated in the appendix, they are not part of the MIB. They > are reproduced for information only. > > The values for DES40 come from a Cisco document, and were used at > the last interoperability workshop by both Microsoft and TimeStep. There's a DES40 draft, and the authors have defined an OID for DES40, but haven't yet produced an algorithm code for it (I asked a month or two ago). > ... > > It seems to be odd that group 5 is missing, even when it is much more > > widely supported than DES40 :-) > > At release time of -02 of the MIB, there was a document for DES40. I > had not seen the Group 5 document at that time. I haven't either, though it was mentioned at the last interop session. Would whoever has this please post it? paul From owner-ipsec Thu Nov 19 15:32:14 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA24609 for ipsec-outgoing; Thu, 19 Nov 1998 15:29:47 -0500 (EST) Date: Thu, 19 Nov 1998 22:48:37 +0200 (EET) Message-Id: <199811192048.WAA02970@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Tim Jenkins Cc: ipsec@tis.com Subject: RE: FW: IPSec Monitoring MIB works for IPv4 only? In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF5957D4@exchange> References: <319A1C5F94C8D11192DE00805FBBADDF5957D4@exchange> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 61 min X-Total-Time: 100 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Tim Jenkins writes: > > In any case if we end up having (or just want to support them) > > multiple ISAKMP SAs how are we going to represent them in the MIB? > You describe a problem that is not the MIB's problem: how to deal with > multiple phase 1 SAs. It's only the MIB's problem if we must support > multiple phase 1 SAs. Ok, I say now that I want to support multiple phase 1 SAs. > Can anyone tell me why we need to support multiple phase 1 SAs? > Obviously, there will be transient times when there are multiple > SAs during re-keying of a phase 1 SA. However, I don't see a need > for this condition to persist. Per user authentication. Lets say I have unix machine having 20 users inside. Each of them have separate certificate and private key. They want to use ipsec to connect intranet server using that certificate. The user starts intranet client (web?) and the underlaying ipsec engine notices that user A wants to connect to intranet server. Ipsec engine finds out users certificate and private key and uses them to create yet another separate phase I SA to the intranet server. This channel is only used to create IPsec SAs for that user, it cannot be used to create IPsec SAs for anybody else, so when the next person wants to create IPsec SA to same server he must do his own phase I SA to intranet server and use that to create IPsec SA. Here we end up having 20 phase I SAs between the unix machine and intranet server. Each of them has different phase I ID and certificate, but same IP address and port. I think this is will be important case when we move from the VPN case to the host IPsec, where all connections are authenticated using IPsec and we want to support multiple users in the same machine. Note that one user may have multiple phase I SAs to different machines, so one Phase I ID may have multiple Phase I SAs active at one time. > My impression of the needs for negotiating a second phase 1 SA: > 1) A new phase 2 SA needs to be established under the protection of > a phase 1 SA that requires more protection than an existing phase 1 > SA with the same peer. > 2) Pending expiration of the existing phase 1 SA. > In both cases, the old SA can be deleted once the new one is up. I don't think both of them are very important, but per user authentication is important. > > Also for mobile user case it would be nice not to tie ISAKMP SA to > > ip-addresses but to tie them to cookies. Now the MIB uses the > > ip-address and port numbers to identify the ISAKMP SA. > Yes, because it's supposed to be a virtual tunnel ID, not an SA ID. > In reality, the tunnel ID is the authenticated phase 1 ID. Should > the index for this table be changed to the phase 1 ID? Yes, I think so that the ipsecIkeTunnelTable should be indexed by the Phase I ID, and the ipsecIkeSaTable is indexed by either cookies or ip-addresses. > I recall that dealing with mobile IP was to be done later. Since > the mandate of *this* MIB was to get something out quickly that > was usable, I intentionally avoided these complications. Is per user authentication also done later? I think it should be already in now. There are IPsec implementations for multiuser machines out there, and they will need that quite soon. > Yes, the cookies identify the SA, but not the phase 1 virtual tunnel. > If we insist on support for multiple phase 1 SAs, I would break out > the SA specific stuff from the IKE table like I did with the phase 2 > SA specific stuff. In that case, you'd end up with four tables, not > three. I think we should do it. In my last mail message I remembered that there was something I needed multiple phase I SAs between two hosts, but didn't quite catch what it was. Now I remember what it is and I think per user authentication is too important to be ignored in the mib. I don't think it will slow down the standardation, because as you said we can just copy structure from the phase II tables. > > ipsecIkeSaDifHelFieldSize? How is this defined? What is the field size > > for MODP groups? Is this really needed? (I think the field size > > attribute in the ike is completely unused, because the field size can > > be seen from the polynomial anyways). > It was just an exercise in completeness. It comes from the Field Size class > described in Appendix A of [IKE]. I'm happy to remove it if no one objects, > if its use is either non-existent or unimportant. I just noticed it there, and I think it is unimportant, and can be left out from the mib, unless someone says we really need it. I think we could also leave it out from the ike-draft also, and nobody will notice anything. > Good points. It was intended to indicate that SAs created within this > phase 1 SA use PFS (as set by policy). A more appropriate place would > be with the SA itself then, if it's wanted at all. Comments? I would add ipsecTunnelDifHelGroupDesc Integer32, to ipsecTunnelEntry, and copy the description from the ipsecIkeSaDifHelGroupDesc, except define that if this is 0 then no PFS is used. I didn't realize there wasn't anything about that in the ipsecTunnelEntry table. > > Why is the ipsecIkeSaTrafficLimit limited to Gauge32? Note that the > > current IKE draft doesn't limit the size of the life duration > > attribute (it may be variable length, although I assume all of the > > implementations will fail, if someone tries to send 64-bit number to > > them...). > It's actually an Integer (misprint in -02). Anyway, at 32 bits, > I figured 4,294,967,295 1024 byte blocks would be a reasonable upper > limit for expressing this. Might be, but who knows about the future. Changing it now is easy, changing it later is hard. The mib already have lots of 64-bit integers inside so everybody just have to support them anyways, so I would put it as a 64-bit number instead of 32-bit, just to be sure. > > Why are the *Packets counters Counter32, instead of Counter64? We may > > end up using more than 2^32 packets also... It takes for 100 MB > > ethernet with small packets only less than an half a day to do it. > That's fine. And what will it be over the Internet? Even over a T3 > with normal traffic, it's still likely more than a day. I really hate to see counters that wraps too fast. People are going to use IPsec, in other cases than VPN also, and for example the Finnish university network backbone is 155 MBit/s ATM that covers the whole Finland, and if they start using ipsec the counters will wrap every 4 hours... Not very usefull information. > I really don't want to proliferate 64-bit values unless > they're really needed. There are still many users of SNMPv1 that > can't support 64-bit values, so I don't want to make the translation > any more different than necessary. The byte counters are already 64-bit, and they are much more important, so I assume that if the user is still using product that supports only SNMPv1, and the cannot get that information the propably upgrade to newer version or start using another product. We cannot stay in one place forever. > > ipsecIkeSaDecryptErrors: How you defined such? Normally that might be > > guessed from the INVALID-PAYLOAD-TYPE, DOI-NOT-SUPPORTED, > > PAYLOAD-MALFORMED, BAD-PROPOSAL-SYNTAX error codes or something else. > > I think it might be quite hard to categorize errors to be decryption > > errors. At least there should be list of errors that are considered > > decryption errors. > > > > ipsecIkeSaHashErrors: I assume this doesn't contain the > > AUTHENTICATION-FAILED error codes that are generated when phase I > > authentication hash failes, only to the INVALID-HASH-INFORMATION that > > are generated if the hash lenght is invalid etc. The > > draft-ietf-ipsec-isakmp-10.txt says you should send > > AUTHENTICATION-FAILED error code if the hash comparision fails. > > > > I assume this should really be ipsecIkeSaAuthErrors if you want to > > calculate authentication errors. > These are SA processing errors, just like in IPSec. In other words, > the decryption of the payload of an encrypted ISAKMP packet lead > to a bad length or whatever. Yes, but how do you know if the decryption failed? There isn't any kind of checksum or similar in isakmp, that would tell if the decryption failed. There are some errors that usually either means decryption error or that the other end is broken, or we had bit error in the wire. If you leave it that way you can be sure that everybody is calculating them differently. > The hash calculation for the authentication > of the *packet* failed. So only phase II HASH calculation mismatch are calculated here? Then I think it needs more text to clarify that you mean those not Phase I authentication failures. > These count packet errors in the control stream (the IKE virtual tunnel) > as performed by the phase 1 SA. They are not protocol or negotiation > errors. They are. When the IKE-process gets a packet from the network it decrypts it and then starts processing it. After that it might get some kind of error that is sends to other end, and if that error might be caused by decryption error (like INVALID-PAYLOAD-TYPE, DOI-NOT-SUPPORTED, PAYLOAD-MALFORMED, BAD-PROPOSAL-SYNTAX etc) then it also must increment that counter. So it musts know which kind of errors in the packet are considered as decryption errors and which are just errors in the protocol. If the other end send you Phase II packet with payload number 14, it is INVALID-PAYLOAD-TYPE error, and it might be caused by decryption error, or it might be that the other end is just using newer version and incorrectly sends you new payloads. For somebody who has to provide this information it is quite important to know which situations are considered to be decryption errors. > > ipsecTunnelLocalAddressOrStart, ipsecTunnelLocalAddressMaskOrEnd: > > where is the type of these fields given? How does the reader know if > > they should treat this range, subnet, or just one ip address? > > If the maskOrEnd is a mask, it's a mask and the AddressOrStart is the > subnet. A 32-bit mask means the AddressOrStart is an address. Otherwise, > it's a range. So maskOrEnd is defines the type of the address, and type is subnet if the ip address in the maskOrEnd is something that has only 1-bits in the msb end and only 0-bits in the lsb end. Huh. Luckily I propably only need to generate those, I don't have to parse them... It least it would need some more wording to explain that, it wasn't obvious at least for me... > The values for DES40 come from a Cisco document, and were used at > the last interoperability workshop by both Microsoft and TimeStep. Yes. I guessed that someone other is to blame... :-) > > Also because the MIB doesn't provide the vendor id information (I > > think it should!) there is no way to know whose private number space > > we are using if there are any numbers from the private number space. > The DES40 values are not private number space; they are in co-operating > implementations number space. They are. The IKE draft says: ---------------------------------------------------------------------- ... Class Values - Encryption Algorithm DES-CBC 1 ... CAST-CBC 6 values 7-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties. ... ---------------------------------------------------------------------- And the DOI draft says: ---------------------------------------------------------------------- ... 6.5 IPSEC ESP Transform Identifiers ... The values 249-255 are reserved for private use amongst cooperating systems. ---------------------------------------------------------------------- At least I interpret those to be private number spaces, everybody can take number from there and start using that, and if someone wants to interoperate with them using that number, they can agree on doing that. Nobody can reserve any of those numbers. > .. > > It seems to be odd that group 5 is missing, even when it is much more > > widely supported than DES40 :-) > At release time of -02 of the MIB, there was a document for DES40. I I haven't seen any drafts about it in the internet-draft directory, and quick search found DES40 or DES-40 from the draft-hoffman-des40-02.txt and some tls documents. The draft-hoffman-des40-02.txt doesn't mention that 65001 number. The number 65001 hasn't been mentioned in the ipsec-list. > had not seen the Group 5 document at that time. Maybe I should put in > groups 6, 7, 8, 9, 10 etc. now? :-) Daniel Harkins's mail to ipsec@tis.com list at Fri, 11 Sep 1998 10:48:12 -0700, with message id <199809111748.KAA09458@dharkins-ss20.cisco.com>, subject is "issues with IKE that need resolution". That has at least been talked in the working group list. Ok, but enough for that. This isn't any kind of real issue here. -- Start fixing W2K problem, install free unix now. kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Thu Nov 19 15:36:57 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA24629 for ipsec-outgoing; Thu, 19 Nov 1998 15:34:52 -0500 (EST) Message-Id: <199811192053.MAA03943@dharkins-ss20.cisco.com> To: Paul Koning cc: tjenkins@TimeStep.com, ipsec@tis.com Subject: Re: FW: IPSec Monitoring MIB works for IPv4 only? In-reply-to: Your message of "Thu, 19 Nov 1998 15:29:13 EST." <199811192029.PAA18303@tonga.xedia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3941.911508799.1@cisco.com> Date: Thu, 19 Nov 1998 12:53:19 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk On Thu, 19 Nov 1998 15:29:13 EST you wrote > > > > At release time of -02 of the MIB, there was a document for DES40. I > > had not seen the Group 5 document at that time. > > I haven't either, though it was mentioned at the last interop > session. Would whoever has this please post it? OK. This seques nicely into a different subject. Some time ago there was a thread "issues with IKE that need resolution". I compiled all that stuff (including group 5) and put in: http://www.lounge.org/ike_doi_errata.html Please take a look, send comments/criticisms/additions/etc to the list. Dan. From owner-ipsec Thu Nov 19 16:24:48 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA24890 for ipsec-outgoing; Thu, 19 Nov 1998 16:21:50 -0500 (EST) Date: Thu, 19 Nov 1998 13:36:57 -0800 (PST) From: Mohan Parthasarathy Message-Id: <199811192136.NAA00454@locked.eng.sun.com> To: dharkins@dharkins-ss20.cisco.com Subject: Re: Bundle or not in negotiation Cc: ipsec@tis.com X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > > It doesn't really need anything but you have to express your wishes to > the peer as unambiguously as possible. If your wishes are "protect all > these packets with both AH and ESP" but you say "protect all these packets > with AH" and then at some later time say "protect all these packets with > ESP" the peer can two things. He can refuse your AH offer because his > policy says he needs ESP in addition to AH and you just offered AH or > he could create the AH SA and hope, perhaps in vain, for you to offer > ESP later. That's ambiguous and ripe for failure. But by offering them > together you're expressing to the peer your wishes: "I want to do these > together on this traffic". > Is there an implication that one of them (ESP or AH) in the bundle will not be used separately ? I understand your argument that unless you provide both, the other end really can't negotiate properly. But I should be able to use the individual SAs for a different connection - which is left to the policy i.e if policy permits, i can use it. Because there is nothing in the IKE that says "these SA's can't be used for anything else". How it is used depends on the policy. Any comments ? -mohan From owner-ipsec Thu Nov 19 16:49:49 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA25037 for ipsec-outgoing; Thu, 19 Nov 1998 16:47:44 -0500 (EST) Date: Thu, 19 Nov 1998 17:05:44 -0500 Message-Id: <199811192205.RAA18818@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: skelly@redcreek.com Cc: tjenkins@TimeStep.com, ipsec@tis.com Subject: Re: FW: IPSec Monitoring MIB works for IPv4 only? References: <319A1C5F94C8D11192DE00805FBBADDF59580E@exchange> <36547862.28B57715@redcreek.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Scott" == Scott G Kelly writes: Scott> Tim Jenkins wrote: >> > > > 2) No method to specify the order of the services per > >> bundle, since the > > normal reasonable order is assumed (see some >> of the > previous email on > > this). > > No substantive comment, >> though my gut reaction is that this > may bite us > later. >> >> This, and I've said this before, was apparently already decided >> long ago. Dan Harkins has posted it at least twice, and further, >> the architecture document itself says that ESP must be applied >> before AH. This is perfectly enforcable in the context of a >> protection suite as defined by the isakmp draft. Scott> No, the architecture document simply does not require support Scott> for any constructs which choose to apply AH first (for Scott> whatever reason). I agree that the arch doc is right not to Scott> require these, but think it's wrong to make design decisions Scott> which preclude them. I agree with Tim here. It's reasonable enough to preclude things if there is no foreseeable argument why they would become meaningful in the future, which seems to apply here. Even if not, there's the problem that it's hard to design in flexibility for undefinable possible future changes. I've seen enough examples in the past where protocols had things designed into them anticipating features of future versions, only to discover by the time the future version rolled around that the "forward compatibility" hacks were in fact wrong and did not help, actually made things more complicated. (Look at DECnet phase 4 for an example... :-( ) I will happily join in complaints when the MIB proposal doesn't adequately cover things that ARE currently allowed, but for the sake of making good progress I'd be happy to have it not support things that aren't currently allowed, don't make sense, and probably never will. paul From owner-ipsec Thu Nov 19 17:03:53 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA25148 for ipsec-outgoing; Thu, 19 Nov 1998 17:01:48 -0500 (EST) Message-Id: <199811192047.PAA01704@morden.sandelman.ottawa.on.ca> To: rodney@unitran.com cc: ipsec@tis.com Subject: questions re: pki ExtendedKeyUsage Date: Thu, 19 Nov 1998 15:47:34 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk On page 10 of the IPsec PKI requirements, you write: 3. ExtendedKeyUsage SHOULD be checked to ensure the certificate is valid for the system in question, including the criticality fields. This extension MUST be treated as critical. a) which "system" is the system in question? b) does this mean that the key should be a signing key, or an encryption key, or... I think you mean: If RSA (DSS) Signature mode is to be used, the ExtendedKeyUsage should include signatures. If RSA Encryption mode is to be used, the ExtendedKeyUsage should include encryption. I think we also agreed awhile ago that the key should say "signature" even if the key will be ultimately used to establish an encrypted session. I imagine you say this somewhere, but I haven't found it yet. ] Internet Security. Have encryption, will travel |1 Fish/2 Fish[ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |Red F./Blow F[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec Fri Nov 20 01:36:04 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id BAA26377 for ipsec-outgoing; Fri, 20 Nov 1998 01:30:51 -0500 (EST) Message-ID: X-Mailer: XFMail 1.0 [p0] on Linux Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 In-Reply-To: <199811192048.WAA02970@torni.ssh.fi> Date: Fri, 20 Nov 1998 01:04:02 -0500 (EST) From: "M. C. Nelson" To: Tero Kivinen Subject: RE: FW: IPSec Monitoring MIB works for IPv4 only? Cc: ipsec@tis.com, Tim Jenkins Sender: owner-ipsec@ex.tis.com Precedence: bulk The point that Tero raises seems to come close to reprising a question that was discussed on numerous earlier occasions in the working group. I feel that it is still a good question. User keying at layer 3 (or 3-4 if you like) creates an expectation for being problematic, because in the general case one expects any layer N entity that provides services at layer N+m where m is greater than 1, to be problematic. The last time I ventured to offer any comment about this (2-3 years ago), we had a very long (and heated) discussion. Some members of the group cited examples from NFS and other multiplexing protocols. These examples still seem to be good food for thought. Regards, Mitch Nelson On 19-Nov-98 Tero Kivinen wrote: >Tim Jenkins writes: >> > In any case if we end up having (or just want to support them) >> > multiple ISAKMP SAs how are we going to represent them in the MIB? >> You describe a problem that is not the MIB's problem: how to deal with >> multiple phase 1 SAs. It's only the MIB's problem if we must support >> multiple phase 1 SAs. > >Ok, I say now that I want to support multiple phase 1 SAs. > >> Can anyone tell me why we need to support multiple phase 1 SAs? >> Obviously, there will be transient times when there are multiple >> SAs during re-keying of a phase 1 SA. However, I don't see a need >> for this condition to persist. > >Per user authentication. ^^^^^^^^^^^^^^^^^^^^^^^^ > >Lets say I have unix machine having 20 users inside. Each of them have >separate certificate and private key. They want to use ipsec to >connect intranet server using that certificate. The user starts >intranet client (web?) and the underlaying ipsec engine notices that >user A wants to connect to intranet server. Ipsec engine finds out ^^^^^^^^^^^^^^^^^^^^^^ >users certificate and private key and uses them to create yet another >separate phase I SA to the intranet server. This channel is only >used to create IPsec SAs for that user, it cannot be used to create >IPsec SAs for anybody else, so when the next person wants to create >IPsec SA to same server he must do his own phase I SA to intranet >server and use that to create IPsec SA. > >Here we end up having 20 phase I SAs between the unix machine and >intranet server. Each of them has different phase I ID and >certificate, but same IP address and port. > >I think this is will be important case when we move from the VPN case >to the host IPsec, where all connections are authenticated using IPsec >and we want to support multiple users in the same machine. > >Note that one user may have multiple phase I SAs to different >machines, so one Phase I ID may have multiple Phase I SAs active at >one time. > >> My impression of the needs for negotiating a second phase 1 SA: >> 1) A new phase 2 SA needs to be established under the protection of >> a phase 1 SA that requires more protection than an existing phase 1 >> SA with the same peer. >> 2) Pending expiration of the existing phase 1 SA. >> In both cases, the old SA can be deleted once the new one is up. > >I don't think both of them are very important, but per user >authentication is important. > >> > Also for mobile user case it would be nice not to tie ISAKMP SA to >> > ip-addresses but to tie them to cookies. Now the MIB uses the >> > ip-address and port numbers to identify the ISAKMP SA. >> Yes, because it's supposed to be a virtual tunnel ID, not an SA ID. >> In reality, the tunnel ID is the authenticated phase 1 ID. Should >> the index for this table be changed to the phase 1 ID? > >Yes, I think so that the ipsecIkeTunnelTable should be indexed by the >Phase I ID, and the ipsecIkeSaTable is indexed by either cookies or >ip-addresses. > >> I recall that dealing with mobile IP was to be done later. Since >> the mandate of *this* MIB was to get something out quickly that >> was usable, I intentionally avoided these complications. > >Is per user authentication also done later? I think it should be >already in now. There are IPsec implementations for multiuser machines >out there, and they will need that quite soon. > >> Yes, the cookies identify the SA, but not the phase 1 virtual tunnel. >> If we insist on support for multiple phase 1 SAs, I would break out >> the SA specific stuff from the IKE table like I did with the phase 2 >> SA specific stuff. In that case, you'd end up with four tables, not >> three. > >I think we should do it. In my last mail message I remembered that >there was something I needed multiple phase I SAs between two hosts, >but didn't quite catch what it was. Now I remember what it is and I >think per user authentication is too important to be ignored in the >mib. I don't think it will slow down the standardation, because as you >said we can just copy structure from the phase II tables. > >> > ipsecIkeSaDifHelFieldSize? How is this defined? What is the field size >> > for MODP groups? Is this really needed? (I think the field size >> > attribute in the ike is completely unused, because the field size can >> > be seen from the polynomial anyways). >> It was just an exercise in completeness. It comes from the Field Size class >> described in Appendix A of [IKE]. I'm happy to remove it if no one objects, >> if its use is either non-existent or unimportant. > >I just noticed it there, and I think it is unimportant, and can be >left out from the mib, unless someone says we really need it. I think >we could also leave it out from the ike-draft also, and nobody will >notice anything. > >> Good points. It was intended to indicate that SAs created within this >> phase 1 SA use PFS (as set by policy). A more appropriate place would >> be with the SA itself then, if it's wanted at all. Comments? > >I would add > > ipsecTunnelDifHelGroupDesc Integer32, > >to ipsecTunnelEntry, and copy the description from the >ipsecIkeSaDifHelGroupDesc, except define that if this is 0 then no PFS >is used. I didn't realize there wasn't anything about that in the >ipsecTunnelEntry table. > >> > Why is the ipsecIkeSaTrafficLimit limited to Gauge32? Note that the >> > current IKE draft doesn't limit the size of the life duration >> > attribute (it may be variable length, although I assume all of the >> > implementations will fail, if someone tries to send 64-bit number to >> > them...). >> It's actually an Integer (misprint in -02). Anyway, at 32 bits, >> I figured 4,294,967,295 1024 byte blocks would be a reasonable upper >> limit for expressing this. > >Might be, but who knows about the future. Changing it now is easy, >changing it later is hard. The mib already have lots of 64-bit >integers inside so everybody just have to support them anyways, so I >would put it as a 64-bit number instead of 32-bit, just to be sure. > >> > Why are the *Packets counters Counter32, instead of Counter64? We may >> > end up using more than 2^32 packets also... It takes for 100 MB >> > ethernet with small packets only less than an half a day to do it. >> That's fine. And what will it be over the Internet? Even over a T3 >> with normal traffic, it's still likely more than a day. > >I really hate to see counters that wraps too fast. People are going to >use IPsec, in other cases than VPN also, and for example the Finnish >university network backbone is 155 MBit/s ATM that covers the whole >Finland, and if they start using ipsec the counters will wrap every 4 >hours... Not very usefull information. > >> I really don't want to proliferate 64-bit values unless >> they're really needed. There are still many users of SNMPv1 that >> can't support 64-bit values, so I don't want to make the translation >> any more different than necessary. > >The byte counters are already 64-bit, and they are much more >important, so I assume that if the user is still using product that >supports only SNMPv1, and the cannot get that information the propably >upgrade to newer version or start using another product. We cannot >stay in one place forever. > >> > ipsecIkeSaDecryptErrors: How you defined such? Normally that might be >> > guessed from the INVALID-PAYLOAD-TYPE, DOI-NOT-SUPPORTED, >> > PAYLOAD-MALFORMED, BAD-PROPOSAL-SYNTAX error codes or something else. >> > I think it might be quite hard to categorize errors to be decryption >> > errors. At least there should be list of errors that are considered >> > decryption errors. >> > >> > ipsecIkeSaHashErrors: I assume this doesn't contain the >> > AUTHENTICATION-FAILED error codes that are generated when phase I >> > authentication hash failes, only to the INVALID-HASH-INFORMATION that >> > are generated if the hash lenght is invalid etc. The >> > draft-ietf-ipsec-isakmp-10.txt says you should send >> > AUTHENTICATION-FAILED error code if the hash comparision fails. >> > >> > I assume this should really be ipsecIkeSaAuthErrors if you want to >> > calculate authentication errors. >> These are SA processing errors, just like in IPSec. In other words, >> the decryption of the payload of an encrypted ISAKMP packet lead >> to a bad length or whatever. > >Yes, but how do you know if the decryption failed? There isn't any >kind of checksum or similar in isakmp, that would tell if the >decryption failed. There are some errors that usually either means >decryption error or that the other end is broken, or we had bit error >in the wire. If you leave it that way you can be sure that everybody >is calculating them differently. > >> The hash calculation for the authentication >> of the *packet* failed. > >So only phase II HASH calculation mismatch are calculated here? Then I >think it needs more text to clarify that you mean those not Phase I >authentication failures. > >> These count packet errors in the control stream (the IKE virtual tunnel) >> as performed by the phase 1 SA. They are not protocol or negotiation >> errors. > >They are. When the IKE-process gets a packet from the network it >decrypts it and then starts processing it. After that it might get >some kind of error that is sends to other end, and if that error might >be caused by decryption error (like INVALID-PAYLOAD-TYPE, >DOI-NOT-SUPPORTED, PAYLOAD-MALFORMED, BAD-PROPOSAL-SYNTAX etc) then it >also must increment that counter. So it musts know which kind of >errors in the packet are considered as decryption errors and which are >just errors in the protocol. If the other end send you Phase II packet >with payload number 14, it is INVALID-PAYLOAD-TYPE error, and it might >be caused by decryption error, or it might be that the other end is >just using newer version and incorrectly sends you new payloads. > >For somebody who has to provide this information it is quite important >to know which situations are considered to be decryption errors. > >> > ipsecTunnelLocalAddressOrStart, ipsecTunnelLocalAddressMaskOrEnd: >> > where is the type of these fields given? How does the reader know if >> > they should treat this range, subnet, or just one ip address? >> >> If the maskOrEnd is a mask, it's a mask and the AddressOrStart is the >> subnet. A 32-bit mask means the AddressOrStart is an address. Otherwise, >> it's a range. > >So maskOrEnd is defines the type of the address, and type is subnet if >the ip address in the maskOrEnd is something that has only 1-bits in >the msb end and only 0-bits in the lsb end. Huh. > >Luckily I propably only need to generate those, I don't have to parse >them... It least it would need some more wording to explain that, it >wasn't obvious at least for me... > >> The values for DES40 come from a Cisco document, and were used at >> the last interoperability workshop by both Microsoft and TimeStep. > >Yes. I guessed that someone other is to blame... :-) > >> > Also because the MIB doesn't provide the vendor id information (I >> > think it should!) there is no way to know whose private number space >> > we are using if there are any numbers from the private number space. >> The DES40 values are not private number space; they are in co-operating >> implementations number space. > >They are. The IKE draft says: >---------------------------------------------------------------------- >... > Class Values > - Encryption Algorithm > DES-CBC 1 >... > CAST-CBC 6 > > values 7-65000 are reserved to IANA. Values 65001-65535 are for > private use among mutually consenting parties. >... >---------------------------------------------------------------------- >And the DOI draft says: >---------------------------------------------------------------------- >... >6.5 IPSEC ESP Transform Identifiers >... > The values 249-255 are reserved for private use amongst cooperating > systems. >---------------------------------------------------------------------- > >At least I interpret those to be private number spaces, everybody can >take number from there and start using that, and if someone wants to >interoperate with them using that number, they can agree on doing >that. Nobody can reserve any of those numbers. > >> .. >> > It seems to be odd that group 5 is missing, even when it is much more >> > widely supported than DES40 :-) >> At release time of -02 of the MIB, there was a document for DES40. I > >I haven't seen any drafts about it in the internet-draft directory, >and quick search found DES40 or DES-40 from the >draft-hoffman-des40-02.txt and some tls documents. The >draft-hoffman-des40-02.txt doesn't mention that 65001 number. The >number 65001 hasn't been mentioned in the ipsec-list. > >> had not seen the Group 5 document at that time. Maybe I should put in >> groups 6, 7, 8, 9, 10 etc. now? :-) > >Daniel Harkins's mail to ipsec@tis.com list at Fri, 11 Sep 1998 >10:48:12 -0700, with message id ><199809111748.KAA09458@dharkins-ss20.cisco.com>, subject is "issues >with IKE that need resolution". That has at least been talked in the >working group list. > >Ok, but enough for that. This isn't any kind of real issue here. >-- >Start fixing W2K problem, install free unix now. >kivinen@iki.fi Work : +358-9-4354 3218 >SSH Communications Security http://www.ssh.fi/ >SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Fri Nov 20 04:41:39 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id EAA26847 for ipsec-outgoing; Fri, 20 Nov 1998 04:39:51 -0500 (EST) Date: Fri, 20 Nov 1998 11:58:19 +0200 (EET) From: Markku Savela Message-Id: <199811200958.LAA19206@anise.tte.vtt.fi> To: ipsec@tis.com In-reply-to: <199811192021.MAA03898@dharkins-ss20.cisco.com> (message from Daniel Harkins on Thu, 19 Nov 1998 12:21:53 -0800) Subject: Re: Bundle or not in negotiation Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Daniel Harkins > It doesn't really need anything but you have to express your wishes to > the peer as unambiguously as possible. If your wishes are "protect all > these packets with both AH and ESP" but you say "protect all these packets > with AH" and then at some later time say "protect all these packets with > ESP" the peer can two things. This where our views of IPSEC architecture seem to differ radically. IPSEC does not express a "wish" to key management, it gives it a command to set up a matching pair of SAs on both end points h1 (AH) h2 SA1 ------> SA1 SA2 <------ SA2 The only "wish like" component is, that this command may allow some alternatives for the encryption/authentication parameters to be used in this association. The command may succeed or fail. > He can refuse your AH offer because his policy says he needs ESP in > addition to AH and you just offered AH ... No, he cannot refuse on policy grounds. He might on *some* cases know that the negotiated SA is not usable (doesn't match any local policy), but why bother, IPSEC will have to check this again anyway, why burden the key management with duplicating tasks that are already done in other components? Consider the policies on SG2 from my earlier example: > +============================+ > | | > | +========================+ | > | | | | > | | | | > H1* ---- (Internet) ------|SG2* --- (local) --- H3* > Policies: Selector => Bundle @H1: H1<->local => ESP(3des,sha1), AH(sha1,tunnel=SG2) @SG2: (a) SG2<->internet => ESP(3des,sha1), AH(sha1,tunnel=H1) (b) local<->internet => AH(sha1) @H3: H2<->H1 => ESP(3des,sha1) H1 is negotiating AH SA with SG2. When the SA negotiation is simplified to occur independently, the resulting architecture allows (if desired) the use this same SA for both (a) and later for (b) policies. This SA for AH might have been negotiated as a result of setting up a link to H3 (b) or as a result of setting up a link to SG2 directly (a). > Even without opportunistic encryptors there can be situations where policy > has not been configured symmetrically. I could require ESP for packets > and you require AH and ESP. If you offer ESP to me (assume the first acquire > you got was for ESP) I'll accept. If you later offer AH to me I won't. > I'll send you packets which you'll drop. To me we successfully negotiated > but you're droping my packets. What I am trying to do, is to put the key management back to its box (of negotiating single SA pairs) and prevent it meddling (or confusing itself) with things is has no business to touch or know about, such as IPSEC policies. [Or, perhaps I am just asking for a new, simpler key management system, that works with IPSEC (*) :-] Succesful SA negotiation just means that both ends have the SA matching the command issued by IPSEC. Packets are dropped until all the required SAs are present. If the policies on both ends don't match (for example, specified different ordering of transforms), there will be no succesful communication, even if all key negotiations succeeded. Such situation can be very frustrating to the end user. A good implementation should try to detect this and give a proper error message. If IPSEC receives valid packets, that fail on "bundle checking" stage, there is a policy mismatch. This will be detected on the first received packet after all asked SAs are in place. ---- (*) speaking of simple key management. I have only manual keys, but I would really like to have the session keys negotiated, but at this point I am not really up to writing a full IKE for myself. I wonder it would be possible write a very simplified, but IKE compatible application, where most of the exchanges are hard coded, e.g. - Assuming a single user host, with a specific userid (perhaps a public keys are preinstalled on both ends, no need to certificates). - have most the packets compiled statically for this special case, and just have code to fill in the variable information, - whats the mininal number of packets that would go back and forth? Three? Does anyone have a skeleton program for such (I can get the encryptions stuff from outside USA). -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec Fri Nov 20 08:20:41 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA27544 for ipsec-outgoing; Fri, 20 Nov 1998 08:18:52 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF59597C@exchange> From: Tim Jenkins To: Richard Draves Cc: ipsec@tis.com Subject: RE: FW: IPSec Monitoring MIB works for IPv4 only? Date: Fri, 20 Nov 1998 08:16:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Richard Draves [mailto:richdr@microsoft.com] > Sent: Thursday, November 19, 1998 2:29 PM > To: 'Tim Jenkins' > Cc: ipsec@tis.com > Subject: RE: FW: IPSec Monitoring MIB works for IPv4 only? > > > >Yes, but protection suites don't. The real mistake I made on this > >issue was using the more generic term "SA bundle" when I should > >have said "protection suite" as defined in ISAKMP, and further > >compounding it by calling the phase 2 protection suite table > >an SA table. > > > >So, the ipsecSaTable should really be called > ipsecProtectionSuiteTable. > >Is that any better? > > I thought this is supposed to be an IPsec MIB, not an ISAKMP > MIB. What about > implementations that aren't using ISAKMP? I don't understand why this changes the use by IPSec only implementations, so the following may not answer the question. Static SA usage is mentioned in the MIB text. They don't produce a phase 1 virtual tunnel table, and the index to the phase 1 table in the phase 2 tunnel doesn't point to a phase 1 table entry. If your concern is how to express all the protocols, you put 0 for the cipher/hash/compression alg to indicate the protocol is not being used. I'm not even sure that you can't generate the equivalent of ISAKMP's protection suite with statically defined SAs. It would appear to me to be an implementation issue, not a protocol issue. Also: (from the MIB) ==> ipsecTunnelType OBJECT-TYPE SYNTAX INTEGER { static(0), transient(1), permanent(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the virtual tunnel represented by this row. 'static' means that the tunnel is supported by a single static IPSec SA that was setup by configuration, and not by using a key exchange protocol. In this case, the value of ipsecTunnelIkeSa must be 0." ::= { ipsecTunnelEntry 3 } <== Does this help? From owner-ipsec Fri Nov 20 08:23:36 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA27567 for ipsec-outgoing; Fri, 20 Nov 1998 08:22:50 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF595993@exchange> From: Tim Jenkins To: "Scott G. Kelly" Cc: ipsec@tis.com Subject: RE: FW: IPSec Monitoring MIB works for IPv4 only? Date: Fri, 20 Nov 1998 08:40:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Scott G. Kelly [mailto:skelly@redcreek.com] > Sent: Thursday, November 19, 1998 2:58 PM > To: Tim Jenkins > Cc: ipsec@tis.com > Subject: Re: FW: IPSec Monitoring MIB works for IPv4 only? > > > Tim Jenkins wrote: > > > Tim Jenkins wrote: > > > > My mandate was to *quickly* produce a usable MIB. The speed > > > issue requires > > > > some simplification. > > > > > > Who mandated speed over good design? > > > > Gee, nice snipe, Scott. Got anything constructive to say? > > Let's nip this in the bud: This isn't a snipe, it's an honest > question. > I was at the meeting where you volunteered to produce this draft. I > didn't hear any such 'mandate' iterated. Hence, my question > stands: who > mandated it? > If you wanted to know who mandated speed, it was stated by Robert Moskowitz at meetings at the Chicago IETF. The purpose was to get either a) a monitoring only MIB or b) a monitoring only MIB that provided a base for further MIB work. I got the impression that it was felt important that the existence of a monitoring MIB would help IPSec move to the standards stage. I don't know if that's correct or not. Your comment appears to attack the design. In my opinion, the design is a good one based on the assumptions. If you think the assumptions are wrong, discuss them. The intent of simplification is two fold: 1) it reduces ambiguity, and 2) it should make implementation easier for the greatest number of applications. If there are applications for which the MIB isn't sufficient, often augmentation can be used. We've already seen how some implementations want to tie the phase 2 virtual tunnels to the tunnel MIB; a number of methods were suggested. > > > > > > > > 2) No method to specify the order of the services per > > > bundle, since the > > > > normal reasonable order is assumed (see some of the > > > previous email on > > > > this). > > > > > > No substantive comment, though my gut reaction is that this > > > may bite us > > > later. > > > > This, and I've said this before, was apparently already decided > > long ago. Dan Harkins has posted it at least twice, and further, > > the architecture document itself says that ESP must be applied > > before AH. This is perfectly enforcable in the context of a > > protection suite as defined by the isakmp draft. > > No, the architecture document simply does not require support for any > constructs which choose to apply AH first (for whatever > reason). I agree > that the arch doc is right not to require these, but think > it's wrong to > make design decisions which preclude them. > > Further, the isakmp text you quote below doesn't substantiate your > point. The 'protection suites' it refers to are within a > given protocol, > e.g. for ESP the protection suite might be 3DES, HMAC-SHA1. Your > argument seems to be that AH and ESP are bundled together in one > protection suite. Have I misinterpreted your argument? > No, you haven't mis-interpreted me. Please read section 4.2.1 of the ISAKMP document. You'll see an example there: This second example shows a Proposal for two different protection suites. The SA Payload was omitted for space reasons. The first protection suite is presented with one transform for the first protocol and one transform for the second protocol. The second protection suite is presented with two transforms for a single protocol. An example for this proposal might be: Proposal 1 with Protocol 1 as AH with Transform 1 as MD5 AND Protocol 2 as ESP with Transform 1 as 3DES. This is followed by Proposal 2 with Protocol 1 as ESP with Transform 1 as DES and Transform 2 as 3DES. The responder MUST select from the two different proposals. If the second Proposal is selected, the responder MUST select from the two transforms for ESP. The resulting protection suite will be either (1) MD5 AND 3DES OR the selection between (2) DES OR (3) 3DES. It quite clearly describes the first protection suite offered as having two protocols. By extension, IPCOMP is a possible third protocol that may be offered. Protection suites are a subset of SA bundles, as defined in section 4.3 of the architecture document. > > > The reality is, unless I can be convinced I need to keep > > more than one, as soon as you successfully negotiate a new > > phase 1 with me, there is nothing in the documents that says > > I can't send you a delete notification for the old and stop > > using it. Hell, I'm not even *required* to send you a delete > > notification, I can just stop using it. > > > > So I ask again: Why *should* we support more than one phase 1 > > SA? ("Because we can" is not a good enough answer.) > > I think your unspoken assumption here is that all ISAKMP sessions > originate and terminate within the same process on each gateway/host. > That's not necessarily true. Further, even if the ISAKMP processes are > the same, I may want ID PFS for the new SA, so it MUST be > independent of > the existing one. Must I tear down the existing one, > negotiate a new one > for PFS, tear that down, and then renegotiate another (non-PFS) SA? > Fine, I'll add another table, that splits out the actual phase 1 SAs from the phase 1 tunnel table. (Would "channel" be a better word here?) > > > > > > > > > This brings up another issue. I think "tunnel" is not > > > the word to use > > > > > here. > > > > > > I made this point on the ipsec-errors list, and I'll reiterate my > > > reasoning. IPsec is very complex. In order to implement (or just > > > understand) it you must wade through the ARCH, ISAKMP, ESP, > > > AH, DOI, and > > > IKE documents, probably all at the same time, skipping back and > > forth. > > > You already know what a daunting task this is. Why complicate this > > > further by overloading the word 'tunnel', which is integral to the > > > architecture, in this manner? This only serves to confuse and > > > confound. For the phase 1 tunnel table, the only other word that appears appropriate so far is "channel", since the phase virtual tunnel is really a control channel for SA negotiation. Comments on this? For phase 2, though, I think tunnel is the right word, if for no other reason that many implementations want this to be tied to the tunnel interface MIB. They really are tunnels, anyway. > > > > I also wanted to strengthen the concept that bundles are > > > SAs with multiple > > > > services, rather than simply layered SAs. > > > > > > The concept you want to strengthen is wrong - here's the > > > definition from > > > ARCH: > > > > > > A Security Association (SA) is a simplex "connection" that > > affords > > > security services to the traffic carried by it. Security > > services > > > are afforded to an SA by the use of AH, or ESP, but > not both. If > > > > > both AH and ESP protection is applied to a traffic stream, then > > two > > > (or more) SAs are created to afford protection to the > > > traffic stream. > > > > > > Clearly, SAs provide a single service. > > > > > > > Yes, but protection suites don't. The real mistake I made on this > > issue was using the more generic term "SA bundle" when I should > > have said "protection suite" as defined in ISAKMP, and further > > compounding it by calling the phase 2 protection suite table > > an SA table. > > See comments above regarding distinctions between protection > suites and > SA bundles. See my comments above and the text from ISAKMP. The SA bundle issue is somewhat related to the MIB design. The MIB supports only two kinds of SA bundles: protection suites as defined in ISAKMP, and interated tunneling when the selectors for the negotiated SAs are different. From owner-ipsec Fri Nov 20 08:55:50 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA27833 for ipsec-outgoing; Fri, 20 Nov 1998 08:54:50 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF5959C3@exchange> From: Tim Jenkins To: Tero Kivinen Cc: ipsec@tis.com Subject: RE: FW: IPSec Monitoring MIB works for IPv4 only? Date: Fri, 20 Nov 1998 09:15:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@ssh.fi] > Sent: Thursday, November 19, 1998 3:49 PM > To: Tim Jenkins > Cc: ipsec@tis.com > Subject: RE: FW: IPSec Monitoring MIB works for IPv4 only? > > > > > Also for mobile user case it would be nice not to tie ISAKMP SA to > > > ip-addresses but to tie them to cookies. Now the MIB uses the > > > ip-address and port numbers to identify the ISAKMP SA. > > Yes, because it's supposed to be a virtual tunnel ID, not an SA ID. > > In reality, the tunnel ID is the authenticated phase 1 ID. Should > > the index for this table be changed to the phase 1 ID? > > Yes, I think so that the ipsecIkeTunnelTable should be indexed by the > Phase I ID, and the ipsecIkeSaTable is indexed by either cookies or > ip-addresses. > Okay, I've been convinced to add the separate table for phase 1 SAs. Now, given the discussion that's occurred about how to identify a phase 1 tunnel (IKE channel?), how do the SAs in the phase 1 SA table become associated with the phase 1 tunnels? Further, how do the phase 2 tunnels become associated with the phase 1 tunnels? Take your multi-user example: Say you've got two users, both authenticated. They both want to access a server, so they end up needing a phase 2 tunnel with the same selectors. Are there now two phase 2 tunnels with the same selectors created? If so, how would you use them at the packet transfer level? Is this the kind of thing you are trying to support? Or am I over-complicating this? The intent was to link phase 2 tunnels to the phase 1 tunnel based on the tunnel endpoints (for tunnel encapsulation) or the IP header IP addresses (for transport encapsulation). Now, you're suggesting we need multiple phase 1 tunnels with the same endpoints, that are distinct. So how do we link the phase tunnels to them? Do we force implementations to do it based on creator? > > > > ipsecIkeSaDifHelFieldSize? How is this defined? What is > the field size > > > for MODP groups? Is this really needed? (I think the field size > > > attribute in the ike is completely unused, because the > field size can > > > be seen from the polynomial anyways). > > It was just an exercise in completeness. It comes from the > Field Size class > > described in Appendix A of [IKE]. I'm happy to remove it if > no one objects, > > if its use is either non-existent or unimportant. > > I just noticed it there, and I think it is unimportant, and can be > left out from the mib, unless someone says we really need it. I think > we could also leave it out from the ike-draft also, and nobody will > notice anything. > > > Good points. It was intended to indicate that SAs created > within this > > phase 1 SA use PFS (as set by policy). A more appropriate > place would > > be with the SA itself then, if it's wanted at all. Comments? > > I would add > > ipsecTunnelDifHelGroupDesc Integer32, > > to ipsecTunnelEntry, and copy the description from the > ipsecIkeSaDifHelGroupDesc, except define that if this is 0 then no PFS > is used. I didn't realize there wasn't anything about that in the > ipsecTunnelEntry table. And polynomial, etc. etc. right? > > > > Why is the ipsecIkeSaTrafficLimit limited to Gauge32? > Note that the > > > current IKE draft doesn't limit the size of the life duration > > > attribute (it may be variable length, although I assume all of the > > > implementations will fail, if someone tries to send > 64-bit number to > > > them...). > > It's actually an Integer (misprint in -02). Anyway, at 32 bits, > > I figured 4,294,967,295 1024 byte blocks would be a reasonable upper > > limit for expressing this. > > Might be, but who knows about the future. Changing it now is easy, > changing it later is hard. The mib already have lots of 64-bit > integers inside so everybody just have to support them anyways, so I > would put it as a 64-bit number instead of 32-bit, just to be sure. > But, if its going change, shouldn't it then be changed to be unlimited length? In any case, I'll go to 64-bit for more of the counters. > > > ipsecIkeSaDecryptErrors: How you defined such? Normally > that might be > > > guessed from the INVALID-PAYLOAD-TYPE, DOI-NOT-SUPPORTED, > > > PAYLOAD-MALFORMED, BAD-PROPOSAL-SYNTAX error codes or > something else. > > > I think it might be quite hard to categorize errors to be > decryption > > > errors. At least there should be list of errors that are > considered > > > decryption errors. > > > > > > ipsecIkeSaHashErrors: I assume this doesn't contain the > > > AUTHENTICATION-FAILED error codes that are generated when phase I > > > authentication hash failes, only to the > INVALID-HASH-INFORMATION that > > > are generated if the hash lenght is invalid etc. The > > > draft-ietf-ipsec-isakmp-10.txt says you should send > > > AUTHENTICATION-FAILED error code if the hash comparision fails. > > > > > > I assume this should really be ipsecIkeSaAuthErrors if you want to > > > calculate authentication errors. > > These are SA processing errors, just like in IPSec. In other words, > > the decryption of the payload of an encrypted ISAKMP packet lead > > to a bad length or whatever. > > Yes, but how do you know if the decryption failed? There isn't any > kind of checksum or similar in isakmp, that would tell if the > decryption failed. There are some errors that usually either means > decryption error or that the other end is broken, or we had bit error > in the wire. If you leave it that way you can be sure that everybody > is calculating them differently. Fine. Anyone care to take a stab at what should be where? > > > The hash calculation for the authentication > > of the *packet* failed. > > So only phase II HASH calculation mismatch are calculated here? Then I > think it needs more text to clarify that you mean those not Phase I > authentication failures. > Okay, I'll clarify that. > > > ipsecTunnelLocalAddressOrStart, ipsecTunnelLocalAddressMaskOrEnd: > > > where is the type of these fields given? How does the > reader know if > > > they should treat this range, subnet, or just one ip address? > > > > If the maskOrEnd is a mask, it's a mask and the > AddressOrStart is the > > subnet. A 32-bit mask means the AddressOrStart is an > address. Otherwise, > > it's a range. > > So maskOrEnd is defines the type of the address, and type is subnet if > the ip address in the maskOrEnd is something that has only 1-bits in > the msb end and only 0-bits in the lsb end. Huh. > > Luckily I propably only need to generate those, I don't have to parse > them... It least it would need some more wording to explain that, it > wasn't obvious at least for me... Would you prefer another field that states how to interpret those fields? From owner-ipsec Fri Nov 20 09:08:43 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA28007 for ipsec-outgoing; Fri, 20 Nov 1998 09:07:50 -0500 (EST) Message-ID: From: Greg Carter To: rodney@unitran.com, "'Michael Richardson'" Cc: ipsec@tis.com Subject: RE: questions re: pki ExtendedKeyUsage Date: Fri, 20 Nov 1998 09:19:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, I think you are confusing ExtendedKeyUsage with KeyUsage. Here the ExtendedKeyUsage extensions is used to say "IPSEC key". KeyUsage is still used to identify the key as digitalSignature, keyEnchipherment, etc... Bye. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com > ---------- > From: Michael Richardson[SMTP:mcr@sandelman.ottawa.on.ca] > Sent: Thursday, November 19, 1998 3:47 PM > To: rodney@unitran.com > Cc: ipsec@tis.com > Subject: questions re: pki ExtendedKeyUsage > > On page 10 of the IPsec PKI requirements, you write: > > 3. ExtendedKeyUsage SHOULD be checked to ensure the > certificate > is valid for the system in question, including the > criticality fields. This extension MUST be treated as > critical. > > a) which "system" is the system in question? > b) does this mean that the key should be a signing key, or an > encryption key, or... > I think you mean: > If RSA (DSS) Signature mode is to be used, the > ExtendedKeyUsage should include signatures. > If RSA Encryption mode is to be used, the ExtendedKeyUsage > should include encryption. > > I think we also agreed awhile ago that the key should say > "signature" even if the key will be ultimately used to establish an > encrypted session. I imagine you say this somewhere, but I haven't > found it yet. > > ] Internet Security. Have encryption, will travel |1 Fish/2 > Fish[ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |Red > F./Blow F[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong > crypto[ > ] panic("Just another NetBSD/notebook using, kernel hacking, security > guy"); [ > > > > > > > From owner-ipsec Fri Nov 20 11:30:59 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA28638 for ipsec-outgoing; Fri, 20 Nov 1998 11:27:50 -0500 (EST) Message-Id: <199811201653.LAA09698@relay.hq.tis.com> Date: Fri, 20 Nov 98 11:42:25 EST From: Charles Lynn To: SALLE Mathias cc: ipsec@tis.com Subject: Re: need of information on a selector field Sender: owner-ipsec@ex.tis.com Precedence: bulk Mathias, > reference: draft-ietf-ipsec-arch-sec-07.txt > paragraph: 4.4.2 selector > problem: > I don't really understand the use of the Name field of a selector. What > is it for? This selector is used to express policies that are specific to a given "user" or "system", on hosts that support those concepts. > How this field is extracted from a IP packet in order to match an > entry in the SPD? The names are not typically passed in the IP packets that form the user communications. The names are associated with the system or with logged in users or applications they are running, by the operating system, and are available to the IPSec implementation when the user sends or receives traffic. One example would be to associate a name with a "socket", maybe via a process control structure, and that information would be available to IPSec. In the incoming direction, the host would check that traffic arriving on the SA was destined for (one of) the socket(s) associated with the name. Charlie From owner-ipsec Fri Nov 20 12:25:47 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA28832 for ipsec-outgoing; Fri, 20 Nov 1998 12:22:52 -0500 (EST) Message-Id: <3655A8F2.FE209139@hplb.hpl.hp.com> Date: Fri, 20 Nov 1998 17:37:54 +0000 From: SALLE Mathias X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en Mime-Version: 1.0 To: clynn@bbn.com Cc: ipsec@tis.com Subject: Work around using SPKI certificates instead of X509 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk hi, REFERENCE: ipsec drafts, SPKI drafts PROBLEM: Is it possible to use ISAKMP/Oakley to establish an SA and at the same time exchange users SPKI certificates, this in a context of a Host to Host mode. QUESTION: Is there any work around using SPKI certificates instead of X509 certificates in ISAKMP? If no, would it be possible to use Certificate Request Payload and Certificate Payload to exchange SPKI certificates? Is there any drafts on that? The Extended Authentication Within ISAKMP/OAkley describe different authentication methods but none of them are related to this problem. I will appreciate all your comments, thanks regards, mathias -- ___________________________________________ Mathias SALLE Networked Systems Dpt. Hewlett-Packard Research Labs Filton Road Stoke Gifford Bristol BS12 6QZ, UK E-mail: matsal@otter.hpl.hp.com Tel : +44 (0)117 922 9753 ___________________________________________ From owner-ipsec Fri Nov 20 12:41:03 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA28925 for ipsec-outgoing; Fri, 20 Nov 1998 12:38:53 -0500 (EST) Message-Id: <199811200418.XAA00744@morden.sandelman.ottawa.on.ca> To: Jon McCown CC: ipsec@tis.com In-reply-to: Your message of "Thu, 19 Nov 1998 13:16:33 EST." <01BE13BE.D549F360@da8.icsa.net> Date: Thu, 19 Nov 1998 23:18:09 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Recently, >>>>> "Jon" == Jon McCown wrote: Jon> RED Node/Red Net - A red network is (most simply) a private Jon> network which has an IPSEC gateway connecting it to another Jon> network. Red nodes are non-IPSEC hosts which are connected Alas, I wrote: red interface is the interface that is exposed to the Internet black interface is the interface that is connected only to the internal network I'd like to do a straw poll. I'd like to come up with a clear, simple set of terms for things. "Public network" and "private network" are pretty clear. Should we lose the "red" "black", and go for just "public" and "private", or should one even discard that and use "encrypted" and "clear"?? ] Internet Security. Have encryption, will travel |1 Fish/2 Fish[ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |Red F./Blow F[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQBVAwUBNlTteR4XQavxnHg9AQF4TwH+JtZVdWNa7ZABjV3xdzY5WLddKnwXODWD EciDG1h+fKLZlCGHX48DYyxhtP4KVAD/0ulAg6HXE2yFk4YYxbEVgA== =Ot6S -----END PGP SIGNATURE----- From owner-ipsec Fri Nov 20 12:41:19 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA28940 for ipsec-outgoing; Fri, 20 Nov 1998 12:39:54 -0500 (EST) Message-Id: <199811200351.WAA00694@morden.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: security in diff-serv Date: Thu, 19 Nov 1998 22:51:23 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk A draft was just posted to diff-serv. I don't know if it is in the draft directory yet, (isn't the deadline tomorrow?). It partly concerns itself with secure communication between edge routers and Bandwidth Brokers. draft-fu-diffserv-security-00.txt ] Internet Security. Have encryption, will travel |1 Fish/2 Fish[ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |Red F./Blow F[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec Fri Nov 20 12:41:18 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA28939 for ipsec-outgoing; Fri, 20 Nov 1998 12:39:53 -0500 (EST) Message-Id: <199811200406.XAA00721@morden.sandelman.ottawa.on.ca> To: SALLE Mathias cc: ipsec@tis.com Subject: Re: need of information on a selector field In-reply-to: Your message of "Thu, 19 Nov 1998 15:12:17 GMT." <36543550.4360AA53@hplb.hpl.hp.com> Date: Thu, 19 Nov 1998 23:06:52 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "SALLE" == SALLE Mathias writes: SALLE> problem: I don't really understand the use of the Name SALLE> field of a selector. What is it for? How this field is SALLE> extracted from a IP packet in order to match an entry in SALLE> the SPD? It isn't, in general, extracted from the packet. Remember that IPsec will often be found on the host that is actually originating the packet (e.g. "client" or "end node" implementations in tunnel, but especially transport mode between end nodes) So "user" may make a lot of sense: you know the login name because of the credentials attached to the Protocol Control Block. You know your domain name, so you can easily form an RFC822 name and/or DN. In addition, a gateway that did NAT might have to use the original source address to lookup into a secure translation table giving a FQDN and/or DN. ] Internet Security. Have encryption, will travel |1 Fish/2 Fish[ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |Red F./Blow F[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQBVAwUBNlTq1x4XQavxnHg9AQERNwH9FJXmI+bIUCvtSF0qtULS982PJ2++/Z7K u0MAVnkbIVk4bfgcLbi8dnVUs6HcRk3uFhgEkxB/0x2l6GWcKOKDag== =esKf -----END PGP SIGNATURE----- From owner-ipsec Fri Nov 20 14:59:55 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA00369 for ipsec-outgoing; Fri, 20 Nov 1998 14:56:58 -0500 (EST) Message-Id: <199811201956.OAA00369@portal.ex.tis.com> Date: Fri, 20 Nov 1998 14:51:04 -0500 (EST) From: owner-ipsec@ex.tis.com To: owner-ipsec@tis.com Subject: BOUNCE ipsec@portal.ex.tis.com: Non-member submission from [Will Price ] Sender: owner-ipsec@ex.tis.com Precedence: bulk >From majordomo-owner Fri Nov 20 14:50:55 1998 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [192.94.214.100]) by portal.ex.tis.com (8.9.1/8.9.1) with ESMTP id OAA00271 for ; Fri, 20 Nov 1998 14:50:55 -0500 (EST) Received: by relay.hq.tis.com; id PAA19913; Fri, 20 Nov 1998 15:17:51 -0500 (EST) Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (4.1) id xma019849; Fri, 20 Nov 98 15:16:56 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.9.1/8.9.1) with ESMTP id PAA17645 for ; Fri, 20 Nov 1998 15:07:04 -0500 (EST) Received: by relay.hq.tis.com; id PAA19834; Fri, 20 Nov 1998 15:16:51 -0500 (EST) Received: from enigma.cyphers.net(205.178.102.88) by relay.hq.tis.com via smap (4.1) id xma019779; Fri, 20 Nov 98 15:15:56 -0500 Received: from cyphers.net (blowfish.cyphers.net [205.178.102.84]) by enigma.cyphers.net (8.8.7/8.8.7) with ESMTP id NAA15404; Fri, 20 Nov 1998 13:09:30 -0800 Message-ID: <3655CC64.F3493E09@cyphers.net> Date: Fri, 20 Nov 1998 12:09:12 -0800 From: Will Price X-Mailer: Mozilla 4.5 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: SALLE Mathias CC: ipsec@tis.com Subject: Re: Work around using SPKI certificates instead of X509 References: <3655A8F2.FE209139@hplb.hpl.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 IKE is particularly brain dead with regards to certificate type negotiation (ie there is no certificate type negotiation). In the absence of such, I've been using the Vendor ID field with a generic value such as "SPKI" or "OpenPGP1" to get some idea of whether the remote system supports a particular certificate type. Since inclusion of multiple Vendor ID payloads is allowed, this is an adequate solution for now. This really needs to become an attribute in the IKE transform for the next version of IKE. - -Will -----BEGIN PGP SIGNATURE----- Version: PGP 6.0.2 iQA/AwUBNlXMGqy7FkvPc+xMEQKTOQCeNEMmGCODcQQyWp8gaL7zNbov0FUAoPlv sa36Ayfb/4sbkZsSTpF+OFLZ =wGyN -----END PGP SIGNATURE----- SALLE Mathias wrote: > > hi, > > REFERENCE: ipsec drafts, SPKI drafts > PROBLEM: > Is it possible to use ISAKMP/Oakley to establish an SA and at the same > time exchange users SPKI certificates, this in a context of a Host to > Host mode. > > QUESTION: > Is there any work around using SPKI certificates instead of X509 > certificates in ISAKMP? > > If no, would it be possible to use Certificate Request Payload and > Certificate Payload to exchange SPKI certificates? Is there any drafts > on that? > > The Extended Authentication Within ISAKMP/OAkley > describe different authentication > methods but none of them are related to this problem. > > I will appreciate all your comments, > > thanks > > regards, > > mathias > -- > ___________________________________________ > Mathias SALLE > Networked Systems Dpt. > Hewlett-Packard Research Labs > Filton Road > Stoke Gifford > Bristol BS12 6QZ, UK > > E-mail: matsal@otter.hpl.hp.com > Tel : +44 (0)117 922 9753 > ___________________________________________ -- Will Price, Architect/Sr. Mgr., PGP Client Products Total Network Security Division Network Associates, Inc. Direct (408)346-5906 Cell/VM (650)533-0399 PGPkey: From owner-ipsec Fri Nov 20 15:02:22 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA00429 for ipsec-outgoing; Fri, 20 Nov 1998 15:00:58 -0500 (EST) From: "Luis A. Sanchez" Message-Id: <199811201519.PAA01801@nutmeg.bbn.com> Subject: Security Policy System Draft and Reference Implementation To: ipsec@tis.com Date: Fri, 20 Nov 1998 15:19:32 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Please check www.net-tech.bbn.com/pbsm/pbsm-index.html for a draft specification of the Security Policy System (SPS). Also, our reference implementation is available through the same URL. This implementation MAY be subject to the export control laws of the United States of America as implemented by the United States Department of State Office of Defense Trade Controls. Enclosed you will find a short blurb on SPS. Comments, suggestions and flames are welcome. Luis ----- The Security Policy System (SPS) is a distributed database of security policy information. It provides the mechanisms needed for discovering, accessing and processing security policy information of hosts, subnets or networks of a security domain. SPS provides hosts and security gateways with the policy information required to establish a secure communication end-to-end through possibly multiple security gateways. Policy clients and servers exchange information using the Security Policy Protocol. The protocol defines how the policy information is exchanged, processed, and protected by clients and servers. The protocol also defines what policy information is exchanged and the format used to encode the information. From owner-ipsec Fri Nov 20 15:10:35 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA00514 for ipsec-outgoing; Fri, 20 Nov 1998 15:08:58 -0500 (EST) Message-ID: <3655D12A.DD83A240@redcreek.com> Date: Fri, 20 Nov 1998 12:29:30 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Richardson CC: Jon McCown , ipsec@tis.com Subject: Re: References: <199811200418.XAA00744@morden.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael Richardson wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Recently, > > >>>>> "Jon" == Jon McCown wrote: > Jon> RED Node/Red Net - A red network is (most simply) a private > Jon> network which has an IPSEC gateway connecting it to another > Jon> network. Red nodes are non-IPSEC hosts which are connected > > Alas, I wrote: > > red interface > is the interface that is exposed to the Internet > black interface > is the interface that is connected only to the internal network > > I'd like to do a straw poll. I'd like to come up with a clear, > simple set of terms for things. "Public network" and "private network" > are pretty clear. Should we lose the "red" "black", and go for just > "public" and "private", or should one even discard that and use > "encrypted" and "clear"?? > I guess I'd vote for public/private, because the meaning seems quite clear. However, we can't always assume that traffic into the gateway from the private side is cleartext. For example, I may want to encrypt my session to the gateway so that other users on my net can't see what I'm up to. From owner-ipsec Fri Nov 20 15:53:54 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA00762 for ipsec-outgoing; Fri, 20 Nov 1998 15:51:58 -0500 (EST) Message-ID: <3655DB0C.1E3FBA42@redcreek.com> Date: Fri, 20 Nov 1998 13:11:40 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Tim Jenkins CC: ipsec@tis.com Subject: Re: FW: IPSec Monitoring MIB works for IPv4 only? References: <319A1C5F94C8D11192DE00805FBBADDF595993@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk First, I'd like to apologize to all concerned for this exchange: Tim Jenkins wrote: > > > > > My mandate was to *quickly* produce a usable MIB. The speed > > > > issue requires > > > > > some simplification. > > > > > > > > Who mandated speed over good design? > > > > > > Gee, nice snipe, Scott. Got anything constructive to say? I've given this a bit of thought, and I think I could have phrased my thoughts differently. Please accept my apology. I've trimmed most of the Tim's latest reply on this thread, and will limit my response to a few issues. > > No, you haven't mis-interpreted me. Please read section 4.2.1 > of the ISAKMP document. You'll see an example there: > > > This second example shows a Proposal for two different protection suites. I was using the section 2.1 definition, and had (apparently incorrectly) interpreted this to mean that the protection suite falls within the protocol (AH or ESP), but did not encompass both. After rereading your examples and other portions of the doc, I see what you mean. This taps into another issue which I think Markku has touched on, that being that the SAs in the kernel are really independent of ISAKMP, IKE, SKIP, or whatever you used to negotiate them. Hence, for an ipsec monitoring mib, maybe the definitions should also be independent of the SA/Key mgmt subsystems. > Protection suites are a subset of SA bundles, as defined in section 4.3 > of the architecture document. I guess I would say the protection suites, an ISAKMP construct, are a direct mapping of SA bundles, an architecture construct. However, they do not represent the only mapping. As others have noted, the SAs could be negotiated individually, and only bundled at the kernel level. > Fine, I'll add another table, that splits out the actual phase 1 > SAs from the phase 1 tunnel table. (Would "channel" be a better > word here?) Not sure - still thinking about this one. > For the phase 1 tunnel table, the only other word that appears > appropriate so far is "channel", since the phase virtual tunnel > is really a control channel for SA negotiation. Comments on this? > > For phase 2, though, I think tunnel is the right word, if for > no other reason that many implementations want this to be tied > to the tunnel interface MIB. They really are tunnels, anyway. Wait, you lost me. Say that between 2 SGWs I have 3 tunnel-mode (protocol) SAs. Up until now, I would say I have 3 tunnels. If I had 2 GRE tunnels in addition to these, I would say I have 5 tunnels. If (for some reason) I also had a L2TP tunnel, then I would say I have 6 tunnels. How many tunnels would you say I have? If your answer is not 6, please explain your reasoning. Also, who specifically wants this tied to the tunnel interface mib? > The SA bundle issue is somewhat related to the MIB design. The MIB supports > only two kinds of SA bundles: protection suites as defined in ISAKMP, > and interated tunneling when the selectors for the negotiated SAs are > different. What I have been trying to express is that the mib should support any legal SA bundle as defined in the architecture document. My comments regarding rigid ordering, e.g. [AH][ESP][IPPCP], were based mostly on the fact that the architecture doc does not forbid other orderings, but rather does not mandate support for more than a few likely ones. This doesn't mean others are illegal, only that support for them is not required. So long as they are not illegal, it is somewhat probable that some other orderings will occur, in which case the mib would be broken. This bothers me (a little). Scott From owner-ipsec Fri Nov 20 16:26:06 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA00885 for ipsec-outgoing; Fri, 20 Nov 1998 16:23:01 -0500 (EST) Message-ID: From: Greg Carter To: "'ipsec@tis.com'" Cc: "'matsal@hplb.hpl.hp.com'" , "'wprice@cyphers.net'" Subject: RE: Work around using SPKI certificates instead of X509 Date: Fri, 20 Nov 1998 16:32:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Why wouldn't you use the Certificate Request Payload with type SPKI or PGP? _________Certificate_Type____________Value____ NONE 0 PKCS #7 wrapped X.509 certificate 1 PGP Certificate 2 DNS Signed Key 3 X.509 Certificate - Signature 4 X.509 Certificate - Key Exchange 5 Kerberos Tokens 6 Certificate Revocation List (CRL) 7 Authority Revocation List (ARL) 8 SPKI Certificate 9 X.509 Certificate - Attribute 10 RESERVED 11 - 255 ---- Greg Carter, Entrust Technologies greg.carter@entrust.com > ---------- > From: owner-ipsec@ex.tis.com[SMTP:owner-ipsec@ex.tis.com] > Sent: Friday, November 20, 1998 2:51 PM > To: owner-ipsec@tis.com > Subject: BOUNCE ipsec@portal.ex.tis.com: Non-member submission > from [Will Price ] > > From: Will Price > X-Mailer: Mozilla 4.5 (Macintosh; U; PPC) > X-Accept-Language: en > MIME-Version: 1.0 > To: SALLE Mathias > CC: ipsec@tis.com > Subject: Re: Work around using SPKI certificates instead of X509 > References: <3655A8F2.FE209139@hplb.hpl.hp.com> > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > IKE is particularly brain dead with regards to certificate type > negotiation (ie there is no certificate type negotiation). > > In the absence of such, I've been using the Vendor ID field with a > generic value such as "SPKI" or "OpenPGP1" to get some idea of whether > the remote system supports a particular certificate type. Since > inclusion of multiple Vendor ID payloads is allowed, this is an > adequate solution for now. This really needs to become an attribute > in the IKE transform for the next version of IKE. > > - -Will > -----BEGIN PGP SIGNATURE----- > Version: PGP 6.0.2 > > iQA/AwUBNlXMGqy7FkvPc+xMEQKTOQCeNEMmGCODcQQyWp8gaL7zNbov0FUAoPlv > sa36Ayfb/4sbkZsSTpF+OFLZ > =wGyN > -----END PGP SIGNATURE----- > > > > SALLE Mathias wrote: > > > > hi, > > > > REFERENCE: ipsec drafts, SPKI drafts > > PROBLEM: > > Is it possible to use ISAKMP/Oakley to establish an SA and at the same > > time exchange users SPKI certificates, this in a context of a Host to > > Host mode. > > > > QUESTION: > > Is there any work around using SPKI certificates instead of X509 > > certificates in ISAKMP? > > > > If no, would it be possible to use Certificate Request Payload and > > Certificate Payload to exchange SPKI certificates? Is there any drafts > > on that? > > > > The Extended Authentication Within ISAKMP/OAkley > > describe different authentication > > methods but none of them are related to this problem. > > > > I will appreciate all your comments, > > > > thanks > > > > regards, > > > > mathias > > -- > > ___________________________________________ > > Mathias SALLE > > Networked Systems Dpt. > > Hewlett-Packard Research Labs > > Filton Road > > Stoke Gifford > > Bristol BS12 6QZ, UK > > > > E-mail: matsal@otter.hpl.hp.com > > Tel : +44 (0)117 922 9753 > > ___________________________________________ > > -- > > Will Price, Architect/Sr. Mgr., PGP Client Products > Total Network Security Division > Network Associates, Inc. > Direct (408)346-5906 > Cell/VM (650)533-0399 > > > PGPkey: > From owner-ipsec Fri Nov 20 16:26:42 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA00901 for ipsec-outgoing; Fri, 20 Nov 1998 16:24:59 -0500 (EST) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF8175B@RED-MSG-50> From: Richard Draves To: "'Scott G. Kelly'" , Tim Jenkins Cc: ipsec@tis.com Subject: RE: FW: IPSec Monitoring MIB works for IPv4 only? Date: Fri, 20 Nov 1998 13:43:52 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipsec@ex.tis.com Precedence: bulk > Wait, you lost me. Say that between 2 SGWs I have 3 tunnel-mode > (protocol) SAs. Up until now, I would say I have 3 tunnels. If I had 2 > GRE tunnels in addition to these, I would say I have 5 > tunnels. If (for > some reason) I also had a L2TP tunnel, then I would say I have 6 > tunnels. How many tunnels would you say I have? If your > answer is not 6, > please explain your reasoning. The terminology is certainly confusing. Some would say that anytime there is encapsulation (IP in IP, whether it be 4-in-4, 6-in-6, 4-in-6, 6-in-4) there is a tunnel. Others would reserve the term tunnel for those situations where encapsulation is used to create a virtual interface, and that interface enjoys the same privileges as real physical interfaces (assign addresses to it, routable, etc). > into another issue which I think Markku has touched on, that > being that > the SAs in the kernel are really independent of ISAKMP, IKE, SKIP, or > whatever you used to negotiate them. Hence, for an ipsec > monitoring mib, > maybe the definitions should also be independent of the SA/Key mgmt > subsystems. Yes! > What I have been trying to express is that the mib should support any > legal SA bundle as defined in the architecture document. My comments > regarding rigid ordering, e.g. [AH][ESP][IPPCP], were based mostly on > the fact that the architecture doc does not forbid other > orderings, but > rather does not mandate support for more than a few likely ones. This > doesn't mean others are illegal, only that support for them is not > required. So long as they are not illegal, it is somewhat > probable that > some other orderings will occur, in which case the mib would > be broken. > This bothers me (a little). It bothers me a lot. Rich From owner-ipsec Sat Nov 21 01:48:00 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id BAA02174 for ipsec-outgoing; Sat, 21 Nov 1998 01:41:59 -0500 (EST) Message-Id: <199811210027.TAA00279@morden.sandelman.ottawa.on.ca> To: SALLE Mathias cc: spki@c2.org, ipsec@tis.com Subject: Re: Work around using SPKI certificates instead of X509 In-reply-to: Your message of "Fri, 20 Nov 1998 17:37:54 GMT." <3655A8F2.FE209139@hplb.hpl.hp.com> Date: Fri, 20 Nov 1998 19:27:21 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "SALLE" == SALLE Mathias writes: SALLE> REFERENCE: ipsec drafts, SPKI drafts PROBLEM: Is it SALLE> possible to use ISAKMP/Oakley to establish an SA and at the SALLE> same time exchange users SPKI certificates, this in a SALLE> context of a Host to Host mode. SALLE> QUESTION: Is there any work around using SPKI certificates SALLE> instead of X509 certificates in ISAKMP? SALLE> If no, would it be possible to use Certificate Request SALLE> Payload and Certificate Payload to exchange SPKI SALLE> certificates? Is there any drafts on that? There is a certificate type in ISAKMP for SPKI. The format of it has not been defined. I would suggest that one could either put multiple SPKI certs (in binary form), just pasted together, or better, a (sequence ...) of them. See isakmp-10, page 34. A draft defining a SPKI certificate tag for IPsec SA's would be a wonderful thing. ] Internet Security. Have encryption, will travel |1 Fish/2 Fish[ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |Red F./Blow F[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQBVAwUBNlYI5B4XQavxnHg9AQFjGAH/U9TqPbOfjpI8X8GTO/fbqe8mBfoihf6/ O2rgrDzlEQGw9GxmBat7hI5AvfSRG01s5Sik1rPGdHlKPi+dQToSFQ== =Pxxs -----END PGP SIGNATURE----- From owner-ipsec Sat Nov 21 12:49:13 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA03162 for ipsec-outgoing; Sat, 21 Nov 1998 12:44:04 -0500 (EST) Date: Sat, 21 Nov 1998 20:03:11 +0200 (EET) Message-Id: <199811211803.UAA08669@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Tim Jenkins Cc: ipsec@tis.com Subject: RE: FW: IPSec Monitoring MIB works for IPv4 only? In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF5959C3@exchange> References: <319A1C5F94C8D11192DE00805FBBADDF5959C3@exchange> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 47 min X-Total-Time: 53 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Tim Jenkins writes: > Okay, I've been convinced to add the separate table for phase 1 SAs. > > Now, given the discussion that's occurred about how to identify a > phase 1 tunnel (IKE channel?), how do the SAs in the phase 1 SA table > become associated with the phase 1 tunnels? I think we can identify the phase 1 tunnels by the the phase 1 identities they are using. The phase 1 SAs can be identified by the cookies. Note that, there might be several phase 1 SAs for one phase 1 tunnel, and the ipaddresses are only valid for phase 1 SAs, not tunnels. I give an example: IKE Tunnel 1 index = 1 IDi = type: rfc822, proto: any, port: any, data: foo@ssh.fi, IDr = type: fqdn, proto: any, port: any, data: www.intranet.ssh.fi IKE Tunnel 2 index = 2 IDi = type: rfc822, proto: any, port: any, data: foo@ssh.fi, IDr = type: fqdn, proto: any, port: any, data: mail.intranet.ssh.fi IKE SA 1 <0x4e6c9c0f e2000000 - 0x5484b4fd 71000000> index = 1 src IP = 192.168.2.4 dst IP = 192.168.2.43 IKE tunnel index = 1 IKE SA 2 <0xcaf52e31 1d000001 - 0xf2cbe754 90000001> index = 2 src IP = 192.168.2.4 dst IP = 192.168.2.44 IKE tunnel index = 1 IKE SA 3 <0x8c80fb79 b0000001 - 0x402511bb a1000004> index = 3 src IP = 192.168.2.4 dst IP = 192.168.2.43 IKE tunnel index = 2 Etc. So we have two intranet web servers each offering service for www.intranet.ssh.fi name (load balancing) which have two ip-addresses (192.168.2.43 and 192.168.2.44). We also have one mail server that is running in the same machine than the first web server. The user foo@ssh.fi, have two IKE tunnels, one to the web server and one to the mail server. The web server IKE tunnel have to IKE SAs, one to both machines. The mail server IKE tunnel have only one IKE SA. > Further, how do the > phase 2 tunnels become associated with the phase 1 tunnels? It depends about the policy and the implementation. Either you do that with per connection SAs, i.e. you create one IPsec SA per tcp/ip connection. Here is a example of that (given the previous IKE example). IPsec tunnel 1 index = 1 Quick mode IDci = type:ipv4, proto:tcp, port:3434, data:192.168.2.4 Quick mode IDcr = type:ipv4, proto:tcp, port:www, data:192.168.2.43 IKE SA index = 1 Encryption algorithm = ... IPsec tunnel 2 index = 2 Quick mode IDci = type:ipv4, proto:tcp, port:3435, data:192.168.2.4 Quick mode IDcr = type:ipv4, proto:tcp, port:www, data:192.168.2.43 IKE SA index = 2 Encryption algorithm = ... IPsec tunnel 3 index = 3 Quick mode IDci = type:ipv4, proto:tcp, port:3436, data:192.168.2.4 Quick mode IDcr = type:ipv4, proto:tcp, port:smtp, data:192.168.2.43 IKE SA index = 3 Encryption algorithm = ... IPsec SA 123 <123> index = 123 IPsec tunnel index = 1 SPI = ... IPsec SA 222 <222> index = 222 IPsec tunnel index = 2 SPI = ... IPsec SA 312 <312> index = 312 IPsec tunnel index = 3 SPI = ... Now we have three IPsec tunnels, one to the first web server and another to second web server. Then we also have one IPsec tunnel to the mail server. Each of those IPsec tunnels currently only have one IPsec SA. Another alternative would be to modify the implementation so that the IPsec engine knows about the users, and then he can just create similar entries than above, except the Quick mode IDci, has port any instead of specific port number. The engine will then see that now user foo is trying to send packets to port 25 of the 192.168.2.43 so it should use the IPsec SA 321, because that is associated with the IPsec tunnel 3 that is associated with the IKE SA 3, that is associated with the user name foo... > Take your multi-user example: Say you've got two users, both > authenticated. They both want to access a server, so they end > up needing a phase 2 tunnel with the same selectors. Are there > now two phase 2 tunnels with the same selectors created? Not with same selectors. If the IPsec engine doesn't allow using the username (or uid or similar) as a selector then it must use per connection (per port) SAs. So either end up having one IPsec SA for each of them, having selectors or with as many IPsec SAs as they have open connections, having selectors . > If so, how would you use them at the packet transfer level? Again, this is implementation issue. > Is this the kind of thing you are trying to support? Or am I > over-complicating this? The MIB really doesn't have to know how the IPsec engine creates those SAs and how it does the per user based authentication. It just have to be able to express the resultant structure. And yes, I think we are trying to support per user authentication over IPsec. > The intent was to link phase 2 tunnels to the phase 1 tunnel > based on the tunnel endpoints (for tunnel encapsulation) or > the IP header IP addresses (for transport encapsulation). I tought that the ipsecTunnelIkeSa was for that purpose? > Now, you're suggesting we need multiple phase 1 tunnels with > the same endpoints, that are distinct. So how do we link the > phase tunnels to them? Do we force implementations to do it > based on creator? For the protocol implementators point of the view the problem is quite simple. If the policy code asks for IPsec SA from x to y authenticated by z, and we don't have Phase I tunnel between x and y authenticated by z, we just create Phase I SA and then IPsec SA and add all these entries to the table. We have to maintain the mapping from IPsec SA to phase I SA that was used to create it anyways if we want to for example support dropping that connection when the certificate used in the authentication is revoced. > > I would add > > > > ipsecTunnelDifHelGroupDesc Integer32, > > > > to ipsecTunnelEntry, and copy the description from the > > ipsecIkeSaDifHelGroupDesc, except define that if this is 0 then no PFS > > is used. I didn't realize there wasn't anything about that in the > > ipsecTunnelEntry table. > > And polynomial, etc. etc. right? Polynomial? ??? > > Might be, but who knows about the future. Changing it now is easy, > > changing it later is hard. The mib already have lots of 64-bit > > integers inside so everybody just have to support them anyways, so I > > would put it as a 64-bit number instead of 32-bit, just to be sure. > But, if its going change, shouldn't it then be changed to be unlimited > length? Ok, for me, but I think 64-bit is enough... > > Yes, but how do you know if the decryption failed? There isn't any > > kind of checksum or similar in isakmp, that would tell if the > > decryption failed. There are some errors that usually either means > > decryption error or that the other end is broken, or we had bit error > > in the wire. If you leave it that way you can be sure that everybody > > is calculating them differently. > > Fine. Anyone care to take a stab at what should be where? Usually what you see is you either see invalid payload type, reserved byte not being zero, or with unequal payload length. The errors of course depend on the order you check things (if you check length before reserved bytes, then you get more unequal payload lengths instead of the reserved non being zero). Also if you process packet only one payload at time, and the packet is corrupted in the middle of the payload and rest is garbage, you start getting errors inside some payload before you notice that the rest of the payloads are also garbage. Perhaps we could add some wording that says "If there is a any error in the packets generic payload structure (next payload field, reserved, payload length) then this is considered being decryption error. If any error happens inside the payload structure, then it is not assumed being decryption errors." This means that you should check the whole packets generic payload structure first before you start looking inside the payloads. This means that if we flip one bit inside the payload we do not end up having decryption error, but something else, but if we flip it in the any of the generic payload headers then we end up having decryption errors. > > So maskOrEnd is defines the type of the address, and type is subnet if > > the ip address in the maskOrEnd is something that has only 1-bits in > > the msb end and only 0-bits in the lsb end. Huh. > > > > Luckily I propably only need to generate those, I don't have to parse > > them... It least it would need some more wording to explain that, it > > wasn't obvious at least for me... > Would you prefer another field that states how to interpret those > fields? Yes. Just adding ipsecTunnelLocalIdType Integer32 ipsecTunnelRemoteIdType Integer32 and copying their descriptions from the ipsecIkeSaPeerIdType would be fine. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Sat Nov 21 14:55:42 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA03463 for ipsec-outgoing; Sat, 21 Nov 1998 14:52:09 -0500 (EST) Message-Id: <199811212010.PAA28100@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: FW: IPSec Monitoring MIB works for IPv4 only? In-Reply-To: Your message of "Fri, 20 Nov 1998 13:11:40 PST." <3655DB0C.1E3FBA42@redcreek.com> Date: Sat, 21 Nov 1998 15:10:45 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Scott" == Scott G Kelly writes: Scott> both. After rereading your examples and other portions of the doc, Scott> I see what you mean. This taps into another issue which I think Scott> Markku has touched on, that being that the SAs in the kernel are Scott> really independent of ISAKMP, IKE, SKIP, or whatever you used to Scott> negotiate them. Hence, for an ipsec monitoring mib, maybe the Scott> definitions should also be independent of the SA/Key mgmt Scott> subsystems. While I think that a MIB that provides just the IPsec SAs in a raw mode would be useful, I don't think that it is this MIB. There is a desire to get something minimally useful, rather than complete. While "good design" should not be compromised for speed, the speed issue is still important. Jack Shriver's comments about how long it takes to walk the structures were probably relevant, but were not as revolutionary as what you suggest. I'd like to see something designed, implemented, and used for six months before we revise it. That doesn't stop other people from starting work on something more complicated right now. :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. From owner-ipsec Sat Nov 21 23:36:25 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id XAA04424 for ipsec-outgoing; Sat, 21 Nov 1998 23:31:58 -0500 (EST) Date: Sun, 22 Nov 1998 06:51:04 +0200 (EET) Message-Id: <199811220451.GAA11542@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: ipsec@tis.com Subject: SSH X.509 certificate enrollment page announcement X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 0 min X-Total-Time: 1 min Sender: owner-ipsec@ex.tis.com Precedence: bulk The SSH X.509 certificate enrollment test page is now available for testing. See: . The SSH ISAKMP/Oakley test site now allows PKCS #10 certificate enrollment testing. This test page allows processing of PKCS #10 requests and it returns X.509 certificates signed by our Web test CA keys. It offers selection of either DSA or RSA root. You can also sign keys with the sub CA 7 that allows you to do chain testing with ISAKMP/Oakley test page (the sub CA 7 (either RSA or DSA) is signed by the master root CA (either DSA or RSA) using chain of 6 certificates between them). The PKCS #10 certificate enrollment page supports both PKCS #10 Extension Requests having ASN1 sequence inside or the T61 strings. Also if you cannot generate PKCS #10 request with extensions, you can just fill in the information to web page (or if want to change some data in the request). The verify PKCS #10 data page allows you also to create your own sub CA certificates, and it allows you to modify the key usage bits of the final certificate. Because this is just a quick test program it DOES not keep track of the serial numbers and validity periods, but just asks you yo fill in the values. You can also select the signature format (sha1WithRSAEncryption (RSA Root key), md5WithRSAEncryption (RSA Root key), or dsaWithSHA-1 (DSA Root key)). For more information about SSH X.509 Certificate Tools see http://www.ssh.fi/certs/ -- Start fixing W2k problem, install a free unix now. kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Sat Nov 21 23:36:29 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id XAA04418 for ipsec-outgoing; Sat, 21 Nov 1998 23:29:59 -0500 (EST) Date: Sun, 22 Nov 1998 06:49:06 +0200 (EET) Message-Id: <199811220449.GAA11925@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: ipsec@tis.com Subject: SSH ISAKMP/Oakley interoperability test site announcement X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 6 min X-Total-Time: 6 min Sender: owner-ipsec@ex.tis.com Precedence: bulk I updated the SSH ISAKMP/Oakley interoperability test site to support our SSH IPSEC Express 1.2. New features includes: - Certificate enrollment page. - Tiger hash in Phase I. - RipeMD160 hash in Phase I. - Well known group 3 (EC2N) in Phase I or II. - Well known group 4 (EC2N) in Phase I or II. - Inline EC2N and ECP private groups in Phase I IKE negotation. - EC2N and ECP private groups in new group mode. - CRL support. - Two different CA keys (DSA or RSA root) - Certificate hierarchy testing (certificate chains) (8 level hierarchy). - Longer timeouts. The URL for the test site is . Here is a updated announcement text: ---------------------------------------------------------------------- The SSH ISAKMP/Oakley test site is now available for testing. See: . This site was already announced in the Washington IETF IPSec session, and has been operational since then, but this is updated announcement for its availability for testing. The SSH ISAKMP/Oakley test site is web based test site for ISAKMP/Oakley servers and it allows your implementation to perform negotiations against the test server. It gives you sufficient debugging output, so you can resolve most problems yourself; we are happy to work with you on the remaining ones (send mail to isakmp-support@ssh.fi). For demonstration purposes, you can also put our implementation negotiating against itself by giving 194.100.55.1 as the IP address for the other end and using different port number for each end. I've now configured the system so that you can also use port 500 for testing at the SSH end. So if you couldn't test earlier because you couldn't configure the remote port, now you can also use port 500. I also raised the default timeout from 30 seconds to 60 seconds if you are using port 500, and to 180 seconds if you are using some other port than 500. I had to raise the timeout because the 120 MHz pentium wasn't able to fetch 8 CRLs from the ldap server, check signatures of those all 8 certificates and their CRLs and sign its responce in 30 seconds when using DSA keys and running boths end in the same machine. Because only one user can be testing in the same port at same time (the test servers are each completely separate from each other, but running on same machine), it would be good to use some other port if you can, and leave port 500 for those who cannot choose... The SSH ISAKMP/Oakley test site supports latest drafts (isakmp-10, oakley-02, isakmp-oakley-08, doi-10), and following options in those drafts: - Several compatibility flags. - Authentication with Pre-Shared keys and support for DSA/RSA signatures and RSA encryption authentications. Now there is also certificate enrollment page, where you can process your own PKCS#10 request and get a certificate signed by our CA key back, so now you can test DSA/RSA signature and RSA encryption authentications yourself. The certificate sent by the other end must have the correct IP address in the subject alt name field. - Two configurable CA keys, DSA or RSA root. - 8 level certificate chain test (CA certificate + 7 intermediate signing certificates and the end user certificate). - Both responder and initiator ends. - Both Main mode and Aggressive mode. - New group mode between main or aggressive mode and quick mode. - Quick mode. - Encryption algorithms: DES, IDEA, Blowfish, RC5, 3DES, and CAST-128. - Hash algorithms: MD5, SHA, Tiger and RipeMD160 - Diffie-Hellman Groups: 1, 2, 3, 4, private group arguments given in ISAKMP proposal, and private group negotiated in new group mode (for quick mode). It also supports 1536 bit modp group created by Richard Schroeppel and posted to linux-ipsec list. This is numbered to be group 5. - MODP, EC2N, ECP private groups. - With or without PFS in quick mode. - Limited configuration mode support, it will respond to any configuration mode (or extended authentication) requests, but the user interface doesn't allow you to initiate them. - CRL support (Currently it always gets CRLs from the ldap.ssh.fi, and that ldap server also has CRLs for all of the our CA keys, but if you send CRL in the ike payload it will also process that). The ISAKMP/Oakley test site is NOT connected to an IPSec engine so it will just print out the resulting keys after negotiation, so you can check them (note, that it will print just raw key material, parity bits etc are fixed in the IPSec engine level, not in this level). The ISAKMP/Oakley test site will be connected to the IPSec responder engine quite soon, so wait for another announcement. If you have any comments, problems, enchancements etc please send mail to isakmp-support@ssh.fi. I will try to add some more help texts to the pages later, but I think implementators should be able to understand the user interface and debug output already. I really hope this service will be usefull to IPSec community. For more information about SSH IPSEC Express see http://www.ssh.fi/ipsec/ -- Start fixing W2k problem, install a free unix now. kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Mon Nov 23 13:25:54 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA09746 for ipsec-outgoing; Mon, 23 Nov 1998 13:18:01 -0500 (EST) Message-Id: <199811231659.LAA25667@ietf.org> To: IETF-Announce:; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipsec@tis.com From: The IESG Subject: Protocol Action: The ESP CBC-Mode Cipher Algorithms to Proposed Standard Date: Mon, 23 Nov 1998 11:59:49 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk The IESG has approved the Internet-Draft The ESP CBC-Mode Cipher Algorithms as a Proposed Standard. This document is the product of the IP Security Protocol Working Group. The IESG contact persons are Jeffrey Schiller and Marcus Leech. Technical Summary This document defines how to use the Cipher-Block-Chaining modes of cipher algorithms with the Encapsulating Security Protocol (ESP). Working Group Summary Rough consensus was achieved on this document. Note: This document should have been part of the recent IP Security Working Group submission which contained ISAKMP and related protocols. Protocol Quality This document was reviewed by Jeffrey I. Schiller for the IESG. From owner-ipsec Mon Nov 23 13:40:26 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA09849 for ipsec-outgoing; Mon, 23 Nov 1998 13:40:02 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF596056@exchange> From: Tim Jenkins To: "Scott G. Kelly" Cc: ipsec@tis.com Subject: RE: FW: IPSec Monitoring MIB works for IPv4 only? Date: Mon, 23 Nov 1998 13:55:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE1712.E09ACA30" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE1712.E09ACA30 Content-Type: text/plain; charset="iso-8859-1" --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Scott G. Kelly [mailto:skelly@redcreek.com] > Sent: Friday, November 20, 1998 4:12 PM > To: Tim Jenkins > Cc: ipsec@tis.com > Subject: Re: FW: IPSec Monitoring MIB works for IPv4 only? > > > First, I'd like to apologize to all concerned for this exchange: > > Tim Jenkins wrote: > > > > > > My mandate was to *quickly* produce a usable MIB. The speed > > > > > issue requires > > > > > > some simplification. > > > > > > > > > > Who mandated speed over good design? > > > > > > > > Gee, nice snipe, Scott. Got anything constructive to say? > > I've given this a bit of thought, and I think I could have phrased my > thoughts differently. Please accept my apology. Accepted. I'll try to remember to put on my kevlar-and-asbestos lined jacket from now on anyway. > > I've trimmed most of the Tim's latest reply on this thread, and will > limit my response to a few issues. > > > > > No, you haven't mis-interpreted me. Please read section 4.2.1 > > of the ISAKMP document. You'll see an example there: > > > > > > This second example shows a Proposal for two different > protection suites. > > > I was using the section 2.1 definition, and had (apparently > incorrectly) > interpreted this to mean that the protection suite falls within the > protocol (AH or ESP), but did not encompass both. After rereading your > examples and other portions of the doc, I see what you mean. This taps > into another issue which I think Markku has touched on, that > being that > the SAs in the kernel are really independent of ISAKMP, IKE, SKIP, or > whatever you used to negotiate them. Hence, for an ipsec > monitoring mib, > maybe the definitions should also be independent of the SA/Key mgmt > subsystems. > > > Protection suites are a subset of SA bundles, as defined in > section 4.3 > > of the architecture document. > > I guess I would say the protection suites, an ISAKMP construct, are a > direct mapping of SA bundles, an architecture construct. However, they > do not represent the only mapping. As others have noted, the SAs could > be negotiated individually, and only bundled at the kernel level. > I agree with the last of this only if the selectors are different. Dan Harkins has (a number of times) pointed out difficulties with bundling separately negotiated SAs with the same selectors and different protocols (ESP, AH or IPCOMP). IMO, the negotiation of a new SA with a different protocol than the previous one is that a re-keying just took place, and the policy was also changed. As others have said: If you want bundled service with the same selectors, negotiate them at the same time. This means to use a protection suite. > > For the phase 1 tunnel table, the only other word that appears > > appropriate so far is "channel", since the phase virtual tunnel > > is really a control channel for SA negotiation. Comments on this? > > > > For phase 2, though, I think tunnel is the right word, if for > > no other reason that many implementations want this to be tied > > to the tunnel interface MIB. They really are tunnels, anyway. > > Wait, you lost me. Say that between 2 SGWs I have 3 tunnel-mode > (protocol) SAs. Up until now, I would say I have 3 tunnels. If I had 2 > GRE tunnels in addition to these, I would say I have 5 > tunnels. If (for > some reason) I also had a L2TP tunnel, then I would say I have 6 > tunnels. How many tunnels would you say I have? If your > answer is not 6, > please explain your reasoning. > Yes, it's 6. > Also, who specifically wants this tied to the tunnel interface mib? > I had long discussions with one of our longest customers on this, I believe John Shriver preferred that route, and perhaps others. > > The SA bundle issue is somewhat related to the MIB design. > The MIB supports > > only two kinds of SA bundles: protection suites as defined > in ISAKMP, > > and interated tunneling when the selectors for the > negotiated SAs are > > different. > > What I have been trying to express is that the mib should support any > legal SA bundle as defined in the architecture document. My comments > regarding rigid ordering, e.g. [AH][ESP][IPPCP], were based mostly on > the fact that the architecture doc does not forbid other > orderings, but > rather does not mandate support for more than a few likely ones. This > doesn't mean others are illegal, only that support for them is not > required. So long as they are not illegal, it is somewhat > probable that > some other orderings will occur, in which case the mib would > be broken. > This bothers me (a little). >From 'case 1' of section 4.5 of the architecture document: Note that there is no requirement to support general nesting, but in transport mode, both AH and ESP can be applied to the packet. In this event, the SA establishment procedure MUST ensure that first ESP, then AH are applied to the packet. I read this as saying that for simultaneously negotiated SAs (a protection suite), the processing of AH before ESP (outbound) IS illegal. As such, the MIB won't explicitly support it. Further, from section 2 of The compression of outbound IP datagrams MUST be done before any IP security processing, such as encryption and authentication, and before any fragmentation of the IP datagram. ... I read this as saying that for simultaneously negotiated SAs (a protection suite), the processing of ESP or AH before IPCOMP (outbound) IS illegal. This leads to a simple conclusion: for protection suites, there is only one possible order of application of protocols (outbound): IPCOMP before ESP before AH. There's nothing in the MIB that prevents the presentation of separately negotiated SAs with the same selector with different services. However, they won't show up in what was called the ipsecSaTable as a single entry; they'll just take two entries in that table. (Table is now called ipsecProtSuiteTable.) Further, if you insist on negotiating the outbound application of AH before ESP with the same SA selectors, you can still do that; it's just that the current MIB won't be able to show the order of application. Should it? I don't think so. Like I said, I view the separate negotiation (when the SA selectors are the same) as a re-key, not bundle creation. Further again, if you really want AH before ESP, it can be done by specifying policy that says creates ESP SAs with AH as the selector, and making sure packets pass through your SPD/SAD twice before they get out of your implementation. ------_=_NextPart_001_01BE1712.E09ACA30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: FW: IPSec Monitoring MIB works for IPv4 only?

---
Tim = Jenkins           = ;            = TimeStep Corporation
tjenkins@timestep.com       =    http://www.timestep.com
(613) 599-3610 = x4304           &= nbsp;   Fax: (613) 599-3617


> -----Original Message-----
> From: Scott G. Kelly [mailto:skelly@redcreek.com]
> Sent: Friday, November 20, 1998 4:12 PM
> To: Tim Jenkins
> Cc: ipsec@tis.com
> Subject: Re: FW: IPSec Monitoring MIB works for = IPv4 only?
>
>
> First, I'd like to apologize to all concerned = for this exchange:
>
> Tim Jenkins wrote:
> > > > > > My mandate was to = *quickly* produce a usable MIB. The speed
> > > > > issue requires
> > > > > > some = simplification.
> > > > >
> > > > > Who mandated speed over = good design?
> > > >
> > > > Gee, nice snipe, Scott. Got = anything constructive to say?
>
> I've given this a bit of thought, and I think I = could have phrased my
> thoughts differently. Please accept my apology. =

Accepted. I'll try to remember to put on my = kevlar-and-asbestos lined jacket from now on anyway.

>
> I've trimmed most of the Tim's latest reply on = this thread, and will
> limit my response to a few issues.
>
> >
> > No, you haven't mis-interpreted me. Please = read section 4.2.1
> > of the ISAKMP document. You'll see an = example there:
> >
> > <begin quote>
> > This second example shows a Proposal for = two different
> protection suites.
> <trimmed...>
>
> I was using the section 2.1 definition, and had = (apparently
> incorrectly)
> interpreted this to mean that the protection = suite falls within the
> protocol (AH or ESP), but did not encompass = both. After rereading your
> examples and other portions of the doc, I see = what you mean. This taps
> into another issue which I think Markku has = touched on, that
> being that
> the SAs in the kernel are really independent of = ISAKMP, IKE, SKIP, or
> whatever you used to negotiate them. Hence, for = an ipsec
> monitoring mib,
> maybe the definitions should also be = independent of the SA/Key mgmt
> subsystems.
>
> > Protection suites are a subset of SA = bundles, as defined in
> section 4.3
> > of the architecture document.
>
> I guess I would say the protection suites, an = ISAKMP construct, are a
> direct mapping of SA bundles, an architecture = construct. However, they
> do not represent the only mapping. As others = have noted, the SAs could
> be negotiated individually, and only bundled at = the kernel level.
>

I agree with the last of this only if the selectors = are different. Dan Harkins has (a number of times) pointed out = difficulties with bundling separately negotiated SAs with the same = selectors and different protocols (ESP, AH or IPCOMP).

IMO, the negotiation of a new SA with a different = protocol than the previous one is that a re-keying just took place, and = the policy was also changed.

As others have said: If you want bundled service with = the same selectors, negotiate them at the same time. This means to use = a protection suite.

<snip>

> > For the phase 1 tunnel table, the only = other word that appears
> > appropriate so far is "channel", = since the phase virtual tunnel
> > is really a control channel for SA = negotiation. Comments on this?
> >
> > For phase 2, though, I think tunnel is the = right word, if for
> > no other reason that many implementations = want this to be tied
> > to the tunnel interface MIB. They really = are tunnels, anyway.
>
> Wait, you lost me. Say that between 2 SGWs I = have 3 tunnel-mode
> (protocol) SAs. Up until now, I would say I = have 3 tunnels. If I had 2
> GRE tunnels in addition to these, I would say I = have 5
> tunnels. If (for
> some reason) I also had a L2TP tunnel, then I = would say I have 6
> tunnels. How many tunnels would you say I have? = If your
> answer is not 6,
> please explain your reasoning.
>

Yes, it's 6.

> Also, who specifically wants this tied to the = tunnel interface mib?
>

I had long discussions with one of our longest = customers on this, I believe John Shriver preferred that route, and = perhaps others.

> > The SA bundle issue is somewhat related to = the MIB design.
> The MIB supports
> > only two kinds of SA bundles: protection = suites as defined
> in ISAKMP,
> > and interated tunneling when the selectors = for the
> negotiated SAs are
> > different.
>
> What I have been trying to express is that the = mib should support any
> legal SA bundle as defined in the architecture = document. My comments
> regarding rigid ordering, e.g. = [AH][ESP][IPPCP], were based mostly on
> the fact that the architecture doc does not = forbid other
> orderings, but
> rather does not mandate support for more than a = few likely ones. This
> doesn't mean others are illegal, only that = support for them is not
> required. So long as they are not illegal, it = is somewhat
> probable that
> some other orderings will occur, in which case = the mib would
> be broken.
> This bothers me (a little).

From 'case 1' of section 4.5 of the architecture = document:

<start quote>
        Note that = there is no requirement to support general nesting,
        but in = transport mode, both AH and ESP can be applied to the
        = packet.  In this event, the SA establishment procedure MUST
        ensure = that first ESP, then AH are applied to the packet.
<end quote>

I read this as saying that for simultaneously = negotiated SAs (a protection suite), the processing of AH before ESP = (outbound) IS illegal. As such, the MIB won't explicitly support = it.

Further, from section 2 of = <draft-ietf-ippcp-protocol-06.txt>

<start quote>

   The compression of outbound IP datagrams = MUST be done before any IP
   security processing, such as encryption = and authentication, and
   before any fragmentation of the IP = datagram.  ...

<end quote>

I read this as saying that for simultaneously = negotiated SAs (a protection suite), the processing of ESP or AH before = IPCOMP (outbound) IS illegal.

This leads to a simple conclusion: for protection = suites, there is only one possible order of application of protocols = (outbound): IPCOMP before ESP before AH.

There's nothing in the MIB that prevents the = presentation of separately negotiated SAs with the same selector with = different services. However, they won't show up in what was called the = ipsecSaTable as a single entry; they'll just take two entries in that = table. (Table is now called ipsecProtSuiteTable.)

Further, if you insist on negotiating the outbound = application of AH before ESP with the same SA selectors, you can still = do that; it's just that the current MIB won't be able to show the order = of application. Should it? I don't think so. Like I said, I view the = separate negotiation (when the SA selectors are the same) as a re-key, = not bundle creation.

Further again, if you really want AH before ESP, it = can be done by specifying policy that says creates ESP SAs with AH as = the selector, and making sure packets pass through your SPD/SAD twice = before they get out of your implementation.

------_=_NextPart_001_01BE1712.E09ACA30-- From owner-ipsec Mon Nov 23 14:02:16 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA09966 for ipsec-outgoing; Mon, 23 Nov 1998 14:02:04 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF59608D@exchange> From: Tim Jenkins To: Daniel Harkins Cc: ipsec@tis.com Subject: RE: FW: IPSec Monitoring MIB works for IPv4 only? Date: Mon, 23 Nov 1998 14:21:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk The re-keying issues aren't there. For my opinions on that see . This document also expresses our concerns with the delete notification and its use. I will be updating this (sometime) to reflect the view that there should be more than one phase 1 SA allowed between peers. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Daniel Harkins [mailto:dharkins@dharkins-ss20.cisco.com] > Sent: Thursday, November 19, 1998 3:53 PM > To: Paul Koning > Cc: tjenkins@TimeStep.com; ipsec@tis.com > Subject: Re: FW: IPSec Monitoring MIB works for IPv4 only? > > > On Thu, 19 Nov 1998 15:29:13 EST you wrote > > > > > > At release time of -02 of the MIB, there was a document > for DES40. I > > > had not seen the Group 5 document at that time. > > > > I haven't either, though it was mentioned at the last interop > > session. Would whoever has this please post it? > > OK. This seques nicely into a different subject. Some time ago there > was a thread "issues with IKE that need resolution". I > compiled all that > stuff (including group 5) and put in: > http://www.lounge.org/ike_doi_errata.html Please take a look, send comments/criticisms/additions/etc to the list. Dan. From owner-ipsec Mon Nov 23 14:56:04 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA10369 for ipsec-outgoing; Mon, 23 Nov 1998 14:55:04 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF5960F7@exchange> From: Tim Jenkins To: John Shriver , ipsec@tis.com Subject: RE: more on ipsec-mib-02 - Phase 1 tunnels Date: Mon, 23 Nov 1998 15:15:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: John Shriver [mailto:jas@shiva.com] > Sent: Wednesday, November 18, 1998 1:54 PM > To: ipsec@tis.com > Cc: Tim Jenkins > Subject: more on ipsec-mib-02 - Phase 1 tunnels > > > I've had a chance to digest the implications of the IKE Phase 1 > tunnels part of ipsec-mib-02. I'll try and structure this message > into parts. > > DOI values and TEXTUAL-CONVENTIONS > ---------------------------------- > > > Presumably the IPSEC-DOI-TC should be administered by the IANA, who > also administers these DOI values. This eliminates the whole RFC > process issue. This sounds good to me. How do we go about getting it done? > > Missing Local Address/Port in Phase 1 SA Table > ---------------------------------------------- > > The Phase 1 SA table needs the local IP address and UDP port for the > Phase 1 SA. How else can one possibly correlate these table entries > between the IPSec devices at each end of this SA? There's no > guaruntee that the IPSec device has only one IP address. Also, in > cases where IKE collisions have occured (without resolution), this > will be the only way to diagnose the situation. > > So, add ipsecIkeSaLocalIPAddress and ipsecIkeSaLocalPortNumber. Agreed, but not to the IKE tunnel table; I've created a specific IKE SA table to allow for multiple phase 1 SAs between two peers. > > Oh, both the port numbers should be described as UDP port numbers, > right? > > Indexing of Phase 1 SA Table > ---------------------------- > > Once we have the tuple that identifies an IKE Phase 1 SA > (ipsecIkeSaLocalIpAddress, ipsecIkeSaLocalPortNumber, > ipSecIkeSaPeerIpAddress, and ipsecIkeSaPeerPortNumber), we have the > true key to an IPSec IKE Phase 1 SA. Thus, I'd propose that those > four variables form the INDEX. (Well, at least for IPv4. That > problem again!) > > This is no more complicated an index than tcpConnTable. The actual tunnel identifier is more correctly the tuple of the authenticated IDs at each end of the tunnel. This will also be added. > > Mapping Out Port 500 > -------------------- > > I think it's gratuitous complexity to replace port 500 with 0. > > What should be done is to have a DEFVAL of 500, if only to express > that, since it's really meaningless on a read-only variable. Fine. > > Normal Versus Agressive Mode > ---------------------------- > More States > ----------- > Who Initiated > ------------- > The states will be increased in detail and added to the IKE SAs themselves. > > Human-Reable Names for Phase 1 SA's > ----------------------------------- > > I'd suggest that we follow the lead of RFC 2233 and predecessors, and > define a variable similar to ifAlias. This is a string that can be > set by the manager to assign a human-readable name to thie Phase 1 SA. > Given that the MIB is read-only, I'm not sure this is very useful. Do I mis-understand how this alias is used? From owner-ipsec Mon Nov 23 15:17:30 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA10508 for ipsec-outgoing; Mon, 23 Nov 1998 15:17:09 -0500 (EST) Date: Mon, 23 Nov 1998 15:36:06 -0500 Message-Id: <199811232036.PAA02859@brill.shiva.com> From: John Shriver To: tjenkins@TimeStep.com CC: ipsec@tis.com In-reply-to: <319A1C5F94C8D11192DE00805FBBADDF5960F7@exchange> (message from Tim Jenkins on Mon, 23 Nov 1998 15:15:47 -0500) Subject: Re: more on ipsec-mib-02 - Phase 1 tunnels Sender: owner-ipsec@ex.tis.com Precedence: bulk From: Tim Jenkins To: John Shriver , ipsec@tis.com Subject: RE: more on ipsec-mib-02 - Phase 1 tunnels Date: Mon, 23 Nov 1998 15:15:47 -0500 > > Presumably the IPSEC-DOI-TC should be administered by the IANA, who > also administers these DOI values. This eliminates the whole RFC > process issue. This sounds good to me. How do we go about getting it done? I will contact the IANA about this. From past experience requesting ifType values, it will be a while until we get a response. We possibly should also put the initial version of this IPSEC-DOI-TC MIB into one of the standards track documents. For instance, there is a copy of IANAifType-MIB in RFC 1573, but not in the later RFC 2233. (Not sure what the preffered approach is.) Certainly, the IANA would appreciate an initial draft of the IPSEC-DOI-TC MIB, I certainly could cut & paste & type it up... From owner-ipsec Mon Nov 23 15:17:31 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA10507 for ipsec-outgoing; Mon, 23 Nov 1998 15:17:08 -0500 (EST) Message-Id: <199811232035.MAA01557@chip.cisco.com> To: Tim Jenkins cc: ipsec@tis.com Subject: rekeying issues, was Re: FW: IPSec Monitoring MIB works for IPv4 only? In-reply-to: Your message of "Mon, 23 Nov 1998 14:21:50 EST." <319A1C5F94C8D11192DE00805FBBADDF59608D@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1554.911853332.1@cisco.com> Date: Mon, 23 Nov 1998 12:35:32 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Yea, you're right. I'm somewhat baffled by the re-keying issue. At the Raleigh bakeoff and at the Binghamton bakeoff there was quite a bit of re-keying done. In fact, in Raleigh there was a 6 or 7 vendor mesh (each had 5 or 6 peers) with re-keying every 5 minutes or so. This went on for a couple of hours until people got distracted and tore their node down to do other things. In Binghamton I did re-keying with a few vendors (like 4, I'd have to check my notes) and as far as I know none did what was proposed in draft-jenkins-ipsec-rekeying-00.txt and, from my brief discussions with 2 of the implementors I successfully rekeyed with, we did things subtly different and it still worked. The draft mentions quite a bit of conditional state that must be maintained, like creating but not using outbound SAs until traffic is received on the inbound SA, that is difficult to maintain and also might have its own issues. Perhaps if the vendors who've exhibited successful rekeying (I can think of SSH, TimeStep, Checkpoint, Cisco, Radguard, Network Alchemy, IRE, TIS off the top of my head, but that is not meant to be a complete list and I apologise in advance if I didn't mention anyone with whom I did successfully re-key) just documented what they do this might cease to be an issue. Dan. On Mon, 23 Nov 1998 14:21:50 EST you wrote > The re-keying issues aren't there. > > For my opinions on that see > . > > This document also expresses our concerns with the delete notification and > its use. > > I will be updating this (sometime) to reflect the view that there should be > more than one phase 1 SA allowed between peers. From owner-ipsec Mon Nov 23 15:30:33 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA10567 for ipsec-outgoing; Mon, 23 Nov 1998 15:30:07 -0500 (EST) Message-ID: <000b01be1722$e952d7c0$0100010a@irish1> From: "John Irish" To: "IPSEC" Subject: ISAKMP Extended Authentication Date: Mon, 23 Nov 1998 15:50:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk Is anyone aware of an accepted method of having a server/gateway authenticate both a host, and the user on that host, using ISAKMP/Oakley? X.509 certificates will be used for all users and systems. The user certificate is stored within a smart card and will only be available for signing after the user has entered the correct security PIN. It is desirable to have the server/gateway authenticate both the host, which accepts the smart card, as well as the user. It is my understanding that ISAKMP/Oakley Phase 1 can only mutually authenticate based upon a single certificate for both the initiator and responder. It would appear that the methods specified in the IPSEC Draft "Extended Authentication Within ISAKMP/Oakley", , could be extended to facilitate a public key challenge/response authentication mechanism, permitting the user to be authenticated after the Phase 1 negotiation was complete. The current draft does not address the use of a public key signature for authenticating a user. In the absence of a certificate distribution mechanism, the authentication mechanism would need to permit the user's certificate to be passed with the response. This would allow the user's host and server/gateway to mutually authenticated each other during the Phase 1 negotiation, and the user to be authenticated to the server/gateway prior to a Phase 2 negotiation. If the extended authentication of the user failed, the SA resulting from the Phase 1 negotiation would be removed. Any suggestions on this topic would be appreciated. John Irish RABA Technologies From owner-ipsec Mon Nov 23 15:52:32 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA10618 for ipsec-outgoing; Mon, 23 Nov 1998 15:52:09 -0500 (EST) Date: Mon, 23 Nov 1998 16:10:42 -0500 Message-Id: <199811232110.QAA02877@brill.shiva.com> From: John Shriver To: dharkins@cisco.com CC: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Are the Attribute Assigned Numbers in Appendix A of draft-ietf-ipsec-isakmp-oakley-08.txt intended to be fully managed by the IANA just like the ones in draft-ietf-ipsec-ipsec-doi-10.txt? The reason is that we want to be sure which "magic numbers" should be in the IPSEC-DOI-TC MIB, which would be maintained by the IANA. From owner-ipsec Mon Nov 23 16:03:02 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA10669 for ipsec-outgoing; Mon, 23 Nov 1998 16:02:12 -0500 (EST) Message-Id: <199811232120.NAA03310@chip.cisco.com> To: Tim Jenkins , ipsec@tis.com Subject: Re: rekeying issues, was Re: FW: IPSec Monitoring MIB works for IPv4 only? In-reply-to: Your message of "Mon, 23 Nov 1998 12:35:32 PST." <199811232035.MAA01557@chip.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3306.911856044.1@cisco.com> Date: Mon, 23 Nov 1998 13:20:44 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk I should've noted that a link to this draft has been added to the errata. Thanks for bringing that up Tim. Dan. On Mon, 23 Nov 1998 12:35:32 PST I wrote > Yea, you're right. I'm somewhat baffled by the re-keying issue. At > the Raleigh bakeoff and at the Binghamton bakeoff there was quite a > bit of re-keying done. In fact, in Raleigh there was a 6 or 7 vendor > mesh (each had 5 or 6 peers) with re-keying every 5 minutes or so. This > went on for a couple of hours until people got distracted and tore > their node down to do other things. > > In Binghamton I did re-keying with a few vendors (like 4, I'd have > to check my notes) and as far as I know none did what was proposed > in draft-jenkins-ipsec-rekeying-00.txt and, from my brief discussions > with 2 of the implementors I successfully rekeyed with, we did things > subtly different and it still worked. The draft mentions quite a > bit of conditional state that must be maintained, like creating but > not using outbound SAs until traffic is received on the inbound SA, > that is difficult to maintain and also might have its own issues. > > Perhaps if the vendors who've exhibited successful rekeying (I can > think of SSH, TimeStep, Checkpoint, Cisco, Radguard, Network Alchemy, IRE, > TIS off the top of my head, but that is not meant to be a complete list > and I apologise in advance if I didn't mention anyone with whom I did > successfully re-key) just documented what they do this might cease to > be an issue. > > Dan. > > On Mon, 23 Nov 1998 14:21:50 EST you wrote > > The re-keying issues aren't there. > > > > For my opinions on that see > > . > > > > This document also expresses our concerns with the delete notification and > > its use. > > > > I will be updating this (sometime) to reflect the view that there should be > > more than one phase 1 SA allowed between peers. From owner-ipsec Mon Nov 23 16:15:24 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA10771 for ipsec-outgoing; Mon, 23 Nov 1998 16:15:12 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF5C953F@exchange> From: Tim Jenkins To: Daniel Harkins , ipsec@tis.com Subject: RE: rekeying issues, was Re: FW: IPSec Monitoring MIB works for IPv4 only? Date: Mon, 23 Nov 1998 16:35:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Daniel Harkins [mailto:dharkins@cisco.com] > Sent: Monday, November 23, 1998 4:21 PM > To: Tim Jenkins; ipsec@tis.com > Subject: Re: rekeying issues, was Re: FW: IPSec Monitoring > MIB works for > IPv4 only? > > > I should've noted that a link to this draft has been added > to the errata. > Thanks for bringing that up Tim. No problem... > > Dan. > > On Mon, 23 Nov 1998 12:35:32 PST I wrote > > > > In Binghamton I did re-keying with a few vendors (like 4, I'd have > > to check my notes) and as far as I know none did what was proposed > > in draft-jenkins-ipsec-rekeying-00.txt and, from my brief > discussions > > with 2 of the implementors I successfully rekeyed with, we > did things > > subtly different and it still worked. The draft mentions quite a > > bit of conditional state that must be maintained, like creating but > > not using outbound SAs until traffic is received on the inbound SA, > > that is difficult to maintain and also might have its own issues. > > The phase 2 re-keying described in section 2 of that document is what we use today, and have for quite some time. If you re-keyed with us, you re-keyed with that. Excessively short life-time issues (<2 minutes) aside, we find it works very well, and is also very resilient. I'm also very interested to see what others are doing. We arrived at the described method since we felt it was the only way possible to handle the greatest number of things we'd seen. I agree that it's fairly complicated, but now that it's done...!! However, I would still like to see the IPSecond proposal I made in that document. Comments on that are welcomed. > > Perhaps if the vendors who've exhibited successful rekeying (I can > > think of SSH, TimeStep, Checkpoint, Cisco, Radguard, > Network Alchemy, IRE, > > TIS off the top of my head, but that is not meant to be a > complete list > > and I apologise in advance if I didn't mention anyone with > whom I did > > successfully re-key) just documented what they do this > might cease to > > be an issue. > > > > Dan. > > > > On Mon, 23 Nov 1998 14:21:50 EST you wrote > > > The re-keying issues aren't there. > > > > > > For my opinions on that see > > > > . > > > > This document also expresses our concerns with the delete notification and > > its use. > > > > I will be updating this (sometime) to reflect the view that there should be > > more than one phase 1 SA allowed between peers. From owner-ipsec Mon Nov 23 16:40:40 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA10895 for ipsec-outgoing; Mon, 23 Nov 1998 16:40:14 -0500 (EST) Date: Mon, 23 Nov 1998 16:59:02 -0500 Message-Id: <199811232159.QAA05227@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: dharkins@cisco.com Cc: tjenkins@TimeStep.com, ipsec@tis.com Subject: Re: rekeying issues, was Re: FW: IPSec Monitoring MIB works for IPv4 only? References: <319A1C5F94C8D11192DE00805FBBADDF59608D@exchange> <199811232035.MAA01557@chip.cisco.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm not sure yet whether what Tim has proposed is the full answer. But we certainly saw problems under high rekeying load. Problems in the sense of traffic being lost -- not what you could call protocol malfunction. The improvements Tim suggested make logical sense and certainly seem to help make things better. paul From owner-ipsec Mon Nov 23 17:24:09 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA11086 for ipsec-outgoing; Mon, 23 Nov 1998 17:23:11 -0500 (EST) Date: Tue, 24 Nov 1998 00:41:55 +0200 (EET) Message-Id: <199811232241.AAA05060@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "John Irish" Cc: "IPSEC" Subject: ISAKMP Extended Authentication In-Reply-To: <000b01be1722$e952d7c0$0100010a@irish1> References: <000b01be1722$e952d7c0$0100010a@irish1> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 11 min X-Total-Time: 10 min Sender: owner-ipsec@ex.tis.com Precedence: bulk John Irish writes: > Is anyone aware of an accepted method of having a server/gateway > authenticate both a host, and the user on that host, using ISAKMP/Oakley? > X.509 certificates will be used for all users and systems. Yes, by using temporary certificates. Put the PKCS#10 certificate request (or just read the certificate data from the normal certificate) on the smart card and then the host starts it operation by reading that out and signing it using the hosts own private key. After that the authentication continues using the private key on the smart card just as normally, except the host uses the temporary certificate it created for the user, not the certificate in the smartcard. So the hierarchy will be like this: CA Root ----------------------------------. | \ Host key | | | Temporary user certificate permanent user certificate Here "Temporary user certificate" and "permanent user certificate" are both certificates for the private key in the smart card. If only user authentication is needed then we use the "permanent user certificate", and if the both user and host authentication is needed then we have to create that "temporary user certificate" and use that. The validity period of the temporary user certificate can be quite short, and the host can revoke the certificate immediately when the user removes his smart card. The host must of course also check that the "permanent user certificate" is valid and the copy that information to the temporary user certificate. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Mon Nov 23 19:29:40 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id TAA11487 for ipsec-outgoing; Mon, 23 Nov 1998 19:28:13 -0500 (EST) Message-ID: <365A026E.719F58AE@redcreek.com> Date: Mon, 23 Nov 1998 16:48:46 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Tim Jenkins CC: ipsec@tis.com Subject: Re: FW: IPSec Monitoring MIB works for IPv4 only? References: <319A1C5F94C8D11192DE00805FBBADDF596056@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I wrote: > > What I have been trying to express is that the mib should support > any > > legal SA bundle as defined in the architecture document. My comments > > > regarding rigid ordering, e.g. [AH][ESP][IPPCP], were based mostly > on > > the fact that the architecture doc does not forbid other > > orderings, but > > rather does not mandate support for more than a few likely ones. Tim wrote: > From 'case 1' of section 4.5 of the architecture document: > > > Note that there is no requirement to support general nesting, > but in transport mode, both AH and ESP can be applied to the > packet. In this event, the SA establishment procedure MUST > ensure that first ESP, then AH are applied to the packet. > > > I read this as saying that for simultaneously negotiated SAs (a > protection suite), the processing of AH before ESP (outbound) IS > illegal. As such, the MIB won't explicitly support it. I understand what you're saying here, but I think there is an ambiguity. Just prior to the text you quote (also in section 4.5) is the following text: This section describes four examples of combinations of security associations that MUST be supported by compliant IPsec hosts or security gateways. Additional combinations of AH and/or ESP in tunnel and/or transport modes MAY be supported at the discretion of the implementor. Compliant implementations MUST be capable of generating these four combinations and on receipt, of processing them, but SHOULD be able to receive and process any combination. The diagrams and text below describe the basic cases. I take this to mean that any combination is possible. I take the text you quote to mean that for case 1, the specific ordering is a defining characteristic of this particular case. > Further, from section 2 of > > > > The compression of outbound IP datagrams MUST be done before any IP > security processing, such as encryption and authentication, and > before any fragmentation of the IP datagram. ... > > > > I read this as saying that for simultaneously negotiated SAs (a > protection suite), the processing of ESP or AH before IPCOMP > (outbound) IS illegal. I agree with the sensibility of this approach in most cases, i.e. it doesn't make sense to try to compress ostensibly random data. However, it might make sense to compress authenticated data in some cases. In any event, since the draft in question originated outside of this wg, I'm not sure we should cite it as a constraining authority for ipsec implementations. >There's nothing in the MIB that prevents the presentation of separately > negotiated SAs with the same selector with different services. > However, they won't show up in what was called the ipsecSaTable as a > single entry; they'll just take two entries in that table. (Table is > now called ipsecProtSuiteTable.) I guess this is the bottom line. This means there is a (new) mechanism for representing arbitrary nesting of SAs, although it may not be optimal. I guess that addresses my concern. Scott From owner-ipsec Tue Nov 24 08:28:39 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA13918 for ipsec-outgoing; Tue, 24 Nov 1998 08:25:15 -0500 (EST) Message-ID: From: Greg Carter To: John Irish , "'Tero Kivinen'" Cc: IPSEC Subject: RE: ISAKMP Extended Authentication Date: Tue, 24 Nov 1998 08:36:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Tero, While a neat idea I don't see how this could scale, as well tuning every host system into a CA seems problematic. How do you enforce the identity in the temporary cert when the 'authority' is the host, the host can claim the 'user' identity is anyone? Is the gateway obligated to verify the info in the temp cert matches the one in the 'permanent' cert? What about access to the crl repository, typically it would be behind the gateway, so how does the host gain access to post the crl? Bye. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com > ---------- > From: Tero Kivinen[SMTP:kivinen@ssh.fi] > Sent: Monday, November 23, 1998 5:41 PM > To: John Irish > Cc: IPSEC > Subject: ISAKMP Extended Authentication > > > So the hierarchy will be like this: > > CA Root ----------------------------------. > | \ > Host key | > | | > Temporary user certificate permanent user certificate > > Here "Temporary user certificate" and "permanent user certificate" > are both certificates for the private key in the smart card. If only > user authentication is needed then we use the "permanent user > certificate", and if the both user and host authentication is needed > then we have to create that "temporary user certificate" and use that. > > From owner-ipsec Tue Nov 24 10:18:27 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA14654 for ipsec-outgoing; Tue, 24 Nov 1998 10:17:28 -0500 (EST) Date: Tue, 24 Nov 1998 17:36:09 +0200 (EET) From: Markku Savela Message-Id: <199811241536.RAA22910@anise.tte.vtt.fi> To: ipsec@tis.com Subject: Bundles (in Kernel) Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@ex.tis.com Precedence: bulk When I started to read the IPSEC architecture, I had some difficulties to understand how the bundle thing would work, especially the receive side was a bit problematic. But, I went on and coded here and there, building parts of IPSEC one at time, and now I think I have all done. But, I notice that my choices lead to simple looking implementation, which does not quite match the description in architecture document (5.1.1 and 5.2.1). However, my belief (or hope) is that actually "on the wire" my choice is the same. I like impelemting "orthogonally", writing simple automaton which does some basic steps, without giving any concern about the sensibility of the combinations. In my view it is a higher level issue to decide what use they put this machinery. Thus, what I have done, will send and accept whatever combination of ESP/AH/Tunnel one wishes to specify with the policy. And I don't see why anyone would want to do this differently. Totally another issue is, that one could have an optimized IPCOMP+ESP/AH routine, which is called if this or some other common pecific combination is detected. It does not change this underlying "virtual reference implementation", where everything can be done individually (which is what I have been worrying all along: optimizations should not cause limitations to the base standard). The rest of this, tries to describe my implementation (SA bundling issue part). I do not claim it implements the spirit of IPSEC architecture, but I do hope it produces correct things happening "on the wire". If there are potential problems with this implementation, I am greatful for anyone pointing the pitfalls and errors I have created, so that I can really write a conforming implementation. Differences in outgoing (5.1.1) ------------------------------- 1. Match the packet's selector fields against the outbound policies in the SPD to locate the first appropriate policy, which will point to zero or more SA bundles in the SAD. Logically no differences, but my selectors don't point to real SA's. Instead, each selector is attached to list of SA descriptions (templates) which specify the required operations (AH/ESP, algorithms, replay window length, etc.) 2. Match the packet's selector fields against those in the SA bundles found in (1) to locate the first SA bundle that matches. If no SAs were found or none match, create an appropriate SA bundle and link the SPD entry to the SAD entry. If no key management entity is found, drop the packet. Here is rather radical(?) difference: as my selector doesn't point to real SA bundles. This is what I do: process the each descriptor in the bundle in order a) search SA combining the data from the descriptor and the packet (src/dst/protocol etc.) under study (descriptor has flags which tell whether SA should match various data, such as src/protocol/connection etc., setting these flags is part of the policy design) b) if SA not found, generate ACQUIRE message (if not already done earlier), and proceed to the next description c) if SA found, apply the tranformation to the packet. (the desctiption may have contained a tunnel address, if so, the tunnel transformation is applied first, and only then the AH or ESP. After all descriptors, if any of them failed on (b), drop packet. Actually, after first (b), I will also skip (c), and loop only to generate all ACQUIRE messages at one packet. 3. Use the SA bundle found/created in (2) to do the required IPsec processing, e.g., authenticate and encrypt. Well, this already got done on previous step. Differences on incoming (5.2.1) ------------------------------- Here I have outer loop which runs while there are ESP or AH as a protocol in the IP packet. For each I do step 1 and 2 from 5.2.1 1. Use the packet's destination address (outer IP header), IPsec protocol, and SPI to look up the SA in the SAD. If the SA lookup fails, drop the packet and log/report the error. Above step 1 is pretty much the same, but next has some major differences in organization: 2. Use the SA found in (1) to do the IPsec processing, e.g., authenticate and decrypt. This step includes matching the packet's (Inner Header if tunneled) selectors to the selectors in the SA. Local policy determines the specificity of the SA selectors (single value, list, range, wildcard). In general, a packet's source address MUST match the SA selector value. However, an ICMP packet received on a tunnel mode SA may have a source address other than that bound to the SA and thus such packets should be permitted as exceptions to this check. For an ICMP packet, the selectors from the enclosed problem packet (the source and destination addresses and ports should be swapped) should be checked against the selectors for the SA. Note that some or all of these selectors may be inaccessible because of limitations on how many bits of the problem packet the ICMP packet is allowed to carry or due to encryption. My step 2 is much simpler a) use the SA found in (1) to do the IPsec processing. (drop packet on any error) b) if "uncovered" IPIP protocol (this is a tunnel), then process it too (unwrap layer of IP). c) remember SA and the tunnel address, if it was present Now I have an IP packet without IPsec layers, this is what I apply to architecture step 3: 3. Find an incoming policy in the SPD that matches the packet. This could be done, for example, by use of backpointers from the SAs to the SPD or by matching the packet's selectors (Inner Header if tunneled) against those of the policy entries in the SPD. ...with a difference (I don't have real SA's in policy, nor I see possibility to use backpointers): I just use the same routine that I use with outgoing packet to locate the bundle template from SPD (one may have different SPD lists for in and out, but the search is same). Also, note that I don't need any wording abot inner/outer headers at any stage, I just always use what I have at hand in the packet. After I have the bundle description, ... 4. Check whether the required IPsec processing has been applied, i.e., verify that the SA's found in (1) and (2) match the kind and order of SAs required by the policy found in (3). I loop over each descriptor of the bundle, and as with outgoing processing, I search for SA combining the data from the descriptor and the packet (src/dst/protocol etc.) under study (again the same routine is used). If SA is not found or does not match the SA used in the step 2, or the the tunnel does not match, then drop the packet as invalid (basicly, non-matching policies, or someone trying to sneak in with less or different security than policy says). Naturally SA's from step 2 must be in same order (in reality reversed in my implementation) as the bundle list. NOTE: The correct "matching" policy will not necessarily be the first inbound policy found. If the check in (4) fails, steps (3) and (4) are repeated until all policy entries have been checked or until the check succeeds. This is a mystery to me at this point. When using my version of the implementation, when would this NOTE apply, if ever? I would really prefer *not* to search more. regards, -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec Tue Nov 24 10:18:28 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA14648 for ipsec-outgoing; Tue, 24 Nov 1998 10:16:23 -0500 (EST) From: Pat.Calhoun@Eng.Sun.Com (Patrice Calhoun) Message-Id: <199811241534.HAA11822@hsmpka.eng.sun.com> Date: Tue, 24 Nov 1998 07:29:28 -0800 To: "Greg Carter" , "'Tero Kivinen'" , "John Irish" Cc: "IPSEC" Reply-To: Subject: RE: ISAKMP Extended Authentication X-Mailer: Sun NetMail 2.2.2 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Some of you interested in this topic may be interested to know that there will be an EAP BOF in Orlando. EAP is documented in RFC 2284 and specifies a method to encapsulate authentication protocols. This would be an ideal candidate to use in an IKE exchange. Although the RFC is very PPP specific, some of us have been working to make this protocol more generic (the protocol itself is in no way PPP specifc, but the RFC is document as a PPP extension). PatC >Hi Tero, > >While a neat idea I don't see how this could scale, as well tuning every >host system into a CA seems problematic. How do you enforce the identity in >the temporary cert when the 'authority' is the host, the host can claim the >'user' identity is anyone? Is the gateway obligated to verify the info in >the temp cert matches the one in the 'permanent' cert? What about access to >the crl repository, typically it would be behind the gateway, so how does >the host gain access to post the crl? >Bye. >---- >Greg Carter, Entrust Technologies >greg.carter@entrust.com > > >> ---------- >> From: Tero Kivinen[SMTP:kivinen@ssh.fi] >> Sent: Monday, November 23, 1998 5:41 PM >> To: John Irish >> Cc: IPSEC >> Subject: ISAKMP Extended Authentication >> >> >> So the hierarchy will be like this: >> >> CA Root ----------------------------------. >> | \ >> Host key | >> | | >> Temporary user certificate permanent user certificate >> >> Here "Temporary user certificate" and "permanent user certificate" >> are both certificates for the private key in the smart card. If only >> user authentication is needed then we use the "permanent user >> certificate", and if the both user and host authentication is needed >> then we have to create that "temporary user certificate" and use that. >> >> From owner-ipsec Tue Nov 24 11:18:30 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA14844 for ipsec-outgoing; Tue, 24 Nov 1998 11:17:17 -0500 (EST) Message-ID: <002601be17c8$9ed1cc00$0100010a@irish1> From: "John Irish" To: "Greg Carter" , "'Tero Kivinen'" Cc: "IPSEC" Subject: Re: ISAKMP Extended Authentication Date: Tue, 24 Nov 1998 11:36:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk I should point out that the application I am looking at is a Network Computer which could be powered down at any point in time. Such a host is not necessarily trusted to the same extent that a CA would be. The approach Tero recommends would also permit the host to fabricate a user certificate since the host could easily make up a public/private key pair and ignore the smart card altogether. I don't think turning all these host systems into CA's is prudent. If every host had the authority of a CA, the trust associated with a CA would disappear. Given that this level of trust is not acceptable when deploying 100's of such systems, I would think that the extended authentication mechanism I suggested may be cleaner - presuming it could be adapted to this role. What are your thoughts on the use of this mechanism? Clipping from my original email: >>> It would appear that the methods specified in the IPSEC Draft >>> "Extended Authentication Within ISAKMP/Oakley", >>> , could be extended to facilitate a >>> public key challenge/response authentication mechanism, permitting the user >>> to be authenticated after the Phase 1 negotiation was complete. The current >>> draft does not address the use of a public key signature for authenticating >>> a user. In the absence of a certificate distribution mechanism, the >>> authentication mechanism would need to permit the user's certificate to be >>> passed with the response. ------------ >Hi Tero, > >While a neat idea I don't see how this could scale, as well tuning every >host system into a CA seems problematic. How do you enforce the identity in >the temporary cert when the 'authority' is the host, the host can claim the >'user' identity is anyone? Is the gateway obligated to verify the info in >the temp cert matches the one in the 'permanent' cert? What about access to >the crl repository, typically it would be behind the gateway, so how does >the host gain access to post the crl? >Bye. >---- >Greg Carter, Entrust Technologies >greg.carter@entrust.com > > >> ---------- >> From: Tero Kivinen[SMTP:kivinen@ssh.fi] >> Sent: Monday, November 23, 1998 5:41 PM >> To: John Irish >> Cc: IPSEC >> Subject: ISAKMP Extended Authentication >> >> >> So the hierarchy will be like this: >> >> CA Root ----------------------------------. >> | \ >> Host key | >> | | >> Temporary user certificate permanent user certificate >> >> Here "Temporary user certificate" and "permanent user certificate" >> are both certificates for the private key in the smart card. If only >> user authentication is needed then we use the "permanent user >> certificate", and if the both user and host authentication is needed >> then we have to create that "temporary user certificate" and use that. >> >> From owner-ipsec Tue Nov 24 11:36:37 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA14921 for ipsec-outgoing; Tue, 24 Nov 1998 11:36:21 -0500 (EST) Date: Tue, 24 Nov 1998 12:13:20 -0800 (PST) From: "Hilarie K. Orman" Message-Id: <199811242013.MAA01385@earth.hpc.org> To: ipsec@tis.com Subject: Re: Bundle or not in negotiation Sender: owner-ipsec@ex.tis.com Precedence: bulk The discussion below points out the need to separate mechanisms from policy about the use of those mechanisms. However, while some may find it sufficient to have IKE create mechanism sets and to have IPSEC enforce policy over use of those sets, I believe that many people want a way to have a rational negotiation of mutually acceptable policy, prior to use. This was the reason for suggesting "trust management" as a separate protocol --- one that could be mapped to the uses of several IETF security suites. Trust management would fill the gap between "IKE proposes, IPSEC disposes" without requiring changes to either of them. Is there enough interest in this to motivate discussion of requirements? Hilarie > From: Markku Savela > > > From: Daniel Harkins > > > It doesn't really need anything but you have to express your wishes to > > the peer as unambiguously as possible. If your wishes are "protect all > > these packets with both AH and ESP" but you say "protect all these packets > > with AH" and then at some later time say "protect all these packets with > ESP" the peer can two things. > > This where our views of IPSEC architecture seem to differ > radically. IPSEC does not express a "wish" to key management, it gives > it a command to set up a matching pair of SAs on both end points ... > What I am trying to do, is to put the key management back to its box > (of negotiating single SA pairs) and prevent it meddling (or confusing > itself) with things is has no business to touch or know about, such as > IPSEC policies. Hilarie From owner-ipsec Tue Nov 24 13:47:26 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA15484 for ipsec-outgoing; Tue, 24 Nov 1998 13:43:21 -0500 (EST) Message-Id: <365B01D9.790A0C9E@hplb.hpl.hp.com> Date: Tue, 24 Nov 1998 18:58:33 +0000 From: SALLE Mathias X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en Mime-Version: 1.0 To: ipsec@tis.com Subject: Standard APIs for ISAKMP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Is there any definition of standard APIs for ISAKMP/Oakley? By the way, is there any reason for the configuration message types in draft-ietf-ipsec-isakmp-mode-cfg-04 (3.3 page 6) to be named ISKAMP_CFG_XXXXX instead of ISAKMP_CFG_XXXXX? Thanks a lot regards, mathias -- ___________________________________________ Mathias SALLE Networked Systems Dpt. Hewlett-Packard Research Labs Filton Road Stoke Gifford Bristol BS12 6QZ, UK E-mail: matsal@otter.hpl.hp.com Tel : +44 (0)117 922 9753 ___________________________________________ From owner-ipsec Tue Nov 24 14:16:44 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA15582 for ipsec-outgoing; Tue, 24 Nov 1998 14:16:22 -0500 (EST) Date: Tue, 24 Nov 1998 21:35:24 +0200 (EET) Message-Id: <199811241935.VAA17742@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Greg Carter Cc: John Irish , IPSEC Subject: RE: ISAKMP Extended Authentication In-Reply-To: References: X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 17 min X-Total-Time: 17 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Greg Carter writes: > While a neat idea I don't see how this could scale, as well tuning every > host system into a CA seems problematic. I don't think that is that problematic. Note that this host is not really acting as a real CA, it only creates (short lived) temporary certificate. It doesn't have to maintain any kind of permanent directory of the certificates, it can even restrict itself to having only one valid signed certificates at a time. > How do you enforce the identity in > the temporary cert when the 'authority' is the host, the host can claim the > 'user' identity is anyone? If the other end trusts the host, it trusts the host. If the other end doesn't trust the host, there is no use to try to authenticate the host, and we just use end user certificate directly. Of course the host can also send the permanent end user certificate to the server so the server can check that the temporary certificate has identical data than the permanent certificate. This migth be needed if the server doesn't trust the host to be smart enough to check crls and such for the end user certificate. > Is the gateway obligated to verify the info in > the temp cert matches the one in the 'permanent' cert? It can either check that, or trust the host (which is authenticated by the host key certificate) to do the check. It depends on the security policy you want to enforce. > What about access to > the crl repository, typically it would be behind the gateway, so how does > the host gain access to post the crl? The CA root is propably going to issue CRLs, but the host propably just uses very short validity period (like 10 minutes), and creates new certificate every 10 minutes. If the host provides crls, it does not put them in to any crl repository, but just sends them along the IKE negotiation (so instead of creating new certificate every 10 minutes it creates new CRL every 10 minutes). Creating a new certificate and creating a new crl takes equal amount of time (one signing operation), so I would just simplify the system so that the host system never creates crls, it just uses very short validity periods. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Tue Nov 24 14:37:45 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA15738 for ipsec-outgoing; Tue, 24 Nov 1998 14:37:23 -0500 (EST) Date: Tue, 24 Nov 1998 21:55:27 +0200 (EET) Message-Id: <199811241955.VAA17572@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "John Irish" Cc: "Greg Carter" , "IPSEC" Subject: Re: ISAKMP Extended Authentication In-Reply-To: <002601be17c8$9ed1cc00$0100010a@irish1> References: <002601be17c8$9ed1cc00$0100010a@irish1> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 18 min X-Total-Time: 19 min Sender: owner-ipsec@ex.tis.com Precedence: bulk John Irish writes: > I should point out that the application I am looking at is a Network > Computer which could be powered down at any point in time. I don't think that is a problem, as long as it has kind of protected permanent storage to store the host private key and its certificate. > Such a host is not necessarily trusted to the same extent that a CA > would be. If the machine cannot be trusted, why you try to authenticate the machine at all? Remember that you can also make the system so that the host always sends also the permament user certificate from the smart card to the server, so the server can check: 1) that the permanent user certificate is valid (validity, crls etc), and is signed by trusted CA. 2) that the host certificate is valid (validity, crls etc) and is signed by the trusted CA (same than the user certificate or different one). 3) that the temporary user certificate contains the same user identification that the permanent user certificate. 4) that the temporary user certificate is signed by the host certificate, and contains the identification of that (for example host adds subjectAltName ipaddress field having its own ip-number). 5) that the temporary user certificate has short enough validity period (check against policy). So after that the server can be sure that both the hosts private key and user private key are are needed for the authentication. > The approach Tero recommends would also permit the host to fabricate > a user certificate since the host could easily make up a > public/private key pair and ignore the smart card altogether. Yes, but if the server wants to see also the permanent user certificate, then the host cannot do it, because it doesn't know the private key in the smart card. You need to do this if you don't trust the host enough. > I don't think turning all these host systems into CA's is prudent. > If every host had the authority of a CA, the trust associated with a > CA would disappear. No. The host is not a real CA, it is just sub CA, which is not trusted itself. The host still must provide the chain of certificates to proper root CA to get any trust at all. The trust will still be in the root CA, the host CA is just a way to say, that this host (authenticated by the root CA) is saying that this user (authenticated by the user root CA and permanent user certificate) is using this machine, and this certificate will be provided to proof that for next 10 minutes. > Given that this level of trust is not acceptable when deploying > 100's of such systems, I would think that the extended > authentication mechanism I suggested may be cleaner - presuming it > could be adapted to this role. What are your thoughts on the use of > this mechanism? If you don't trust the host, why are you trying to authenticate it? Why isn't the user authentication enough, so just using the user certificate on the smart card? I would say that implementing the system I explain above is propably easier than using extended authentication. Also it doesn't need any changes to the isakmp protocol, only some changes to the implementations. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Tue Nov 24 14:42:44 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA15762 for ipsec-outgoing; Tue, 24 Nov 1998 14:42:24 -0500 (EST) Message-ID: From: Greg Carter To: "'Tero Kivinen'" Cc: John Irish , IPSEC Subject: RE: ISAKMP Extended Authentication Date: Tue, 24 Nov 1998 14:51:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk > ---------- > From: Tero Kivinen[SMTP:kivinen@ssh.fi] > Sent: Tuesday, November 24, 1998 2:35 PM > To: Greg Carter > Cc: John Irish; IPSEC > Subject: RE: ISAKMP Extended Authentication > > > If the other end trusts the host, it trusts the host. If the other end > doesn't trust the host, there is no use to try to authenticate the > host, and we just use end user certificate directly. > > That's the problem the other end does NOT trust the host, it trusts only the CA for identity binding. In order for the host to be able to create these short lived certificates the hosts would have to be certified as CA's (i.e. basicConstraints set to CA and have Certificate Sign bit turned on in key usage). You may be able to argue that with path constraints you could narrow what that host would be able to sign, but if you tried to narrow the available set of users for a particular host it probably wouldn't have much practical use (I could be wrong). In the end I don't think you will find many customers willing to have 'hosts' acting as CA's . Bye. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com From owner-ipsec Tue Nov 24 15:06:21 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA15887 for ipsec-outgoing; Tue, 24 Nov 1998 15:05:21 -0500 (EST) Date: Tue, 24 Nov 1998 22:24:12 +0200 (EET) Message-Id: <199811242024.WAA17775@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Greg Carter Cc: John Irish , IPSEC Subject: RE: ISAKMP Extended Authentication In-Reply-To: References: X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 9 min X-Total-Time: 8 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Greg Carter writes: > That's the problem the other end does NOT trust the host, it trusts only the > CA for identity binding. In order for the host to be able to create these > short lived certificates the hosts would have to be certified as CA's (i.e. > basicConstraints set to CA and have Certificate Sign bit turned on in key > usage). You may be able to argue that with path constraints you could > narrow what that host would be able to sign, but if you tried to narrow the > available set of users for a particular host it probably wouldn't have much > practical use (I could be wrong). In the end I don't think you will find > many customers willing to have 'hosts' acting as CA's . Yes, thats why you propably want to keep the end users certificates CA root different than the one that acts CA root for the host hierarchy. So my picture was really too simple, it should be: Host CA Root User CA Root | | Host sub CA certificate | | | Temporary user certificate - - Permanent user certificate And you just want the host to provide valid certificate chains from the public key to bot Host CA Root and User CA Root, and you do not want to trust Host CA Root in any other applications. Even with this the ike protocol doesn't have any changes, the server just requests certificate giving both host CA Root and User CA Root, and the host MUST provide certificates to both of them, if it support certificates (plus it may provide the Host sub CA certificate). -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Tue Nov 24 15:40:51 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA16002 for ipsec-outgoing; Tue, 24 Nov 1998 15:40:24 -0500 (EST) Message-ID: <008b01be17ed$771363c0$0100010a@irish1> From: "John Irish" To: "Tero Kivinen" Cc: "Greg Carter" , "IPSEC" Subject: Re: ISAKMP Extended Authentication Date: Tue, 24 Nov 1998 16:00:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk Taking this a step further ... presuming you generated this temporary User certificate. How could the "server" use this certificate to authenticate via public key "encryption" during an ISAKMP/Oakley (IKE) Phase 1 negotiation? Assuming a certificate push were permitted with the first "HDR, SA" packet, how would the initiator know which CA and certificate type was acceptable to the responder? Per the IKE spec, issuing a certificate request, when using public key encryption for authentication in Phase 1, is not supported. As a Network Computer we are trying to avoid the use of pre-shared secrets/keys leaving us with public key encryption for the Phase 1 authentication method. This method would appear to dictate the use of a directory server to acquire certificates prior to completing the Diffie-Hellman exchange in Phase 1. John -----Original Message----- From: Tero Kivinen To: John Irish Cc: Greg Carter ; IPSEC Date: Tuesday, November 24, 1998 2:56 PM Subject: Re: ISAKMP Extended Authentication >John Irish writes: >> I should point out that the application I am looking at is a Network >> Computer which could be powered down at any point in time. > >I don't think that is a problem, as long as it has kind of protected >permanent storage to store the host private key and its certificate. > >> Such a host is not necessarily trusted to the same extent that a CA >> would be. > >If the machine cannot be trusted, why you try to authenticate the >machine at all? Remember that you can also make the system so that the >host always sends also the permament user certificate from the smart >card to the server, so the server can check: > > 1) that the permanent user certificate is valid (validity, > crls etc), and is signed by trusted CA. > 2) that the host certificate is valid (validity, crls etc) and > is signed by the trusted CA (same than the user certificate > or different one). > 3) that the temporary user certificate contains the same > user identification that the permanent user certificate. > 4) that the temporary user certificate is signed by the host > certificate, and contains the identification of that (for > example host adds subjectAltName ipaddress field having its > own ip-number). > 5) that the temporary user certificate has short enough > validity period (check against policy). > >So after that the server can be sure that both the hosts private key >and user private key are are needed for the authentication. > >> The approach Tero recommends would also permit the host to fabricate >> a user certificate since the host could easily make up a >> public/private key pair and ignore the smart card altogether. > >Yes, but if the server wants to see also the permanent user >certificate, then the host cannot do it, because it doesn't know the >private key in the smart card. You need to do this if you don't trust >the host enough. > >> I don't think turning all these host systems into CA's is prudent. >> If every host had the authority of a CA, the trust associated with a >> CA would disappear. > >No. The host is not a real CA, it is just sub CA, which is not trusted >itself. The host still must provide the chain of certificates to >proper root CA to get any trust at all. The trust will still be in the >root CA, the host CA is just a way to say, that this host >(authenticated by the root CA) is saying that this user (authenticated >by the user root CA and permanent user certificate) is using this >machine, and this certificate will be provided to proof that for next >10 minutes. > >> Given that this level of trust is not acceptable when deploying >> 100's of such systems, I would think that the extended >> authentication mechanism I suggested may be cleaner - presuming it >> could be adapted to this role. What are your thoughts on the use of >> this mechanism? > >If you don't trust the host, why are you trying to authenticate it? >Why isn't the user authentication enough, so just using the user >certificate on the smart card? > >I would say that implementing the system I explain above is propably >easier than using extended authentication. Also it doesn't need any >changes to the isakmp protocol, only some changes to the >implementations. >-- >kivinen@iki.fi Work : +358-9-4354 3218 >SSH Communications Security http://www.ssh.fi/ >SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Tue Nov 24 16:04:52 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA16073 for ipsec-outgoing; Tue, 24 Nov 1998 16:04:24 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199811161641.LAA23421@venus.solidum.com> Date: Tue, 24 Nov 1998 13:14:10 -0500 To: ipsec-errors@sandelman.ottawa.on.ca From: Stephen Kent Subject: Re: Selector fields for ICMP in Arch doc Cc: ipsec@tis.com, ipsec-errors@sandelman.ottawa.on.ca Sender: owner-ipsec@ex.tis.com Precedence: bulk Michael, > One point that I think ICMP group is unanimous is that the SPD/SAD support >for ICMP. We feel that it should be extended to include ICMP type and code >fields as selectors. > > Matt Crawford has suggested that since the architecture document provides >a minimum set, the IPv6 people can impose additional requirements if they >need. > The question is do we want to make these an item for the IPv4 Standard's >Arch document? I suggest that the text read like: > "An implementation MAY support ICMP as a selector for the SAD. If an > implementation does support ICMP, then it MUST support both ICMP > type and code as selectors" > > Stephen? What say you? I agree that we should extend the architecture doc to include selectors for ICMP processing, as part of a more comprehensive ICMP processing description, under IPsecond. > This has ramifications for IKE as well: however, if you consider type/code >to be a 16 bit item, you might pretend that it is the "port" field. I suggest >that type be made the MSB and code the LSB. > > [do we have RFCs yet???? Do we even have numbers?] Yes, the numbers are 2401-2412. Jon assigned them prior to his death, to allow us to cite them appropriately in a National Reserach Council report that Bellovin and I worked on. Steve From owner-ipsec Tue Nov 24 18:06:31 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA16489 for ipsec-outgoing; Tue, 24 Nov 1998 18:05:25 -0500 (EST) Date: Tue, 24 Nov 1998 18:24:45 -0500 (EST) From: "Michael C. Richardson" Message-Id: <199811242324.SAA08705@istari.sandelman.ottawa.on.ca> Prev-Resent: Tue, 24 Nov 1998 18:24:44 -0500 Prev-Resent: "ipsec@tis.com " Sender: owner-ipsec@ex.tis.com Precedence: bulk >From mcr@sandelman.ottawa.on.ca Tue Nov 24 16: 22:55 1998 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id QAA05419 for ; Tue, 24 Nov 1998 16:22:53 -0500 (EST) Received: from [128.33.238.111] (TC111.BBN.COM [128.33.238.111]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id QAA06528; Tue, 24 Nov 1998 16:22:35 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199811161641.LAA23421@venus.solidum.com> Date: Tue, 24 Nov 1998 13:14:10 -0500 To: ipsec-errors@sandelman.ottawa.on.ca From: Stephen Kent Subject: Re: Selector fields for ICMP in Arch doc Cc: ipsec@tis.com, ipsec-errors@sandelman.ottawa.on.ca Resent-To: ipsec@tis.com Resent-Date: Tue, 24 Nov 1998 18:24:45 -0500 Resent-From: "Michael C. Richardson" Michael, > One point that I think ICMP group is unanimous is that the SPD/SAD support >for ICMP. We feel that it should be extended to include ICMP type and code >fields as selectors. > > Matt Crawford has suggested that since the architecture document provides >a minimum set, the IPv6 people can impose additional requirements if they >need. > The question is do we want to make these an item for the IPv4 Standard's >Arch document? I suggest that the text read like: > "An implementation MAY support ICMP as a selector for the SAD. If an > implementation does support ICMP, then it MUST support both ICMP > type and code as selectors" > > Stephen? What say you? I agree that we should extend the architecture doc to include selectors for ICMP processing, as part of a more comprehensive ICMP processing description, under IPsecond. > This has ramifications for IKE as well: however, if you consider type/code >to be a 16 bit item, you might pretend that it is the "port" field. I suggest >that type be made the MSB and code the LSB. > > [do we have RFCs yet???? Do we even have numbers?] Yes, the numbers are 2401-2412. Jon assigned them prior to his death, to allow us to cite them appropriately in a National Reserach Council report that Bellovin and I worked on. Steve From owner-ipsec Tue Nov 24 19:23:31 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id TAA16656 for ipsec-outgoing; Tue, 24 Nov 1998 19:22:26 -0500 (EST) Message-Id: <199811250041.TAA10457@adk.gr> To: "Hilarie K. Orman" Cc: ipsec@tis.com, mab@research.att.com Subject: Re: Bundle or not in negotiation In-reply-to: Your message of "Tue, 24 Nov 1998 12:13:20 PST." <199811242013.MAA01385@earth.hpc.org> Date: Tue, 24 Nov 1998 19:41:02 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- To: "Hilarie K. Orman" Subject: Re: Bundle or not in negotiation Cc: ipsec@tis.com, mab@research.att.com Date: 11/24/98, 19:41:01 In message <199811242013.MAA01385@earth.hpc.org>, "Hilarie K. Orman" writes: >The discussion below points out the need to separate mechanisms from >policy about the use of those mechanisms. However, while some may >find it sufficient to have IKE create mechanism sets and to have IPSEC >enforce policy over use of those sets, I believe that many people want >a way to have a rational negotiation of mutually acceptable policy, >prior to use. This was the reason for suggesting "trust management" as >a separate protocol --- one that could be mapped to the uses of >several IETF security suites. > >Trust management would fill the gap between "IKE proposes, IPSEC >disposes" without requiring changes to either of them. Is there >enough interest in this to motivate discussion of requirements? I would also add that in those cases where IPsec is used in conjunction with firewalls (or similar), access policy is necessary. This is not a simple issue, and there are a number of variations of IPsec usage (which is probably why people seem to be talking past each other sometimes -- thinking about slightly different scenarios). As Hilarie pointed out, the Trust Management group (it's not yet a WG) was formed to address these kinds of issues. I think Matt Blaze is going to talk for 10 minutes at the next meeting about some of these issues (Matt, am I right ?) We are also working on a preliminary document on the subject -- at this point an issues/requirements docs -- but we probably won't have it ready in time for this IETF. - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQEVAwUBNltSHXcrsxJuc7vBAQGUfAgAj/oeb+LOLUdCs6T5jaz05Sw9QwI2Agff sjewYpIjyFb2+qHF+25O8I0EIC+ATAqVJYPHtcEAT+jPX3UBPfPlfOJL4oxHqFXw gRP+ad7Kjn/vbsMzLYQueLu3ZUNzraOeUXG2F+NfKz63eUkpgzxt93OEBFVpcdir JjYjG9O9crF+9YCBSG2KDWmDENQpFwmjlnJq9DC+Vg8klk0A7DnwF1NllajVwKSp yKELsJKoN1qyZu8Clz9AEv+GkT3RL52sNR+SKBWc2yCyLOO3tsF/lsjk3443PV/7 Xy6Vwx8Uw25JD2AT16zO7sxNVlWoYpHWQOd5Y6vXf2gXwODG64YTbA== =cpg1 -----END PGP SIGNATURE----- From owner-ipsec Tue Nov 24 20:45:15 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA16942 for ipsec-outgoing; Tue, 24 Nov 1998 20:42:28 -0500 (EST) Message-ID: <365B6559.4D878D5E@redcreek.com> Date: Tue, 24 Nov 1998 18:03:05 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hilarie K. Orman" CC: ipsec@tis.com Subject: Re: Bundle or not in negotiation References: <199811242013.MAA01385@earth.hpc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk "Hilarie K. Orman" wrote: > Trust management would fill the gap between "IKE proposes, IPSEC > disposes" without requiring changes to either of them. Is there > enough interest in this to motivate discussion of requirements? I'm very interested in this discussion. I think that in the course of implementation, we've hit on some complexities that the current doc set doesn't fully accommodate. This is not meant to slight the doc editors in any way - this stuff is really complicated, and there are very subtle interactions. It may be that we'll ultimately opt to simplify as much as possible, which I think is what's tacitly occurring now. On the other hand, I think discussion could be a good thing. Scott From owner-ipsec Wed Nov 25 10:40:27 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA19464 for ipsec-outgoing; Wed, 25 Nov 1998 10:36:29 -0500 (EST) Message-ID: <001601be188b$ebcc2d20$0100010a@irish1> From: "John Irish" To: "Dave Clark" Cc: "IPSEC" Subject: ISAKMP/Oakley - Certificate exchange Date: Wed, 25 Nov 1998 10:54:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk (I changed the Subject description to better reflect the change in topic) Within the IKE spec , Section 5.2 - Authentication with Public Key Encryption, the 2nd paragraph states: "In order to perform public key encryption, the initiator must already have the responder's public key." My statement should have indicated that the initiator can not issue a certificate request based upon the statement above. It would appear, although it is not stated, that in Main mode the responder could include a certificate request with the first response packet which includes the SA payload. It is not clear why the initiator could not include a certificate request with the very first packet, and the responder include its certificate plus a certificate request in the first response packet. Part of the reason may be that system identities would be revealed by the certificate exchange in Main mode. In addition, the certificate needed by the initiator may depend upon the proposal selected by the responder, thus making a certificate request in the first packet premature (I'm guessing here). Does anyone have an answer to this? HDR, SA, CertReq --> <-- HDR, SA, CERT, CertReq HDR, KE, CERT, PubKey_r, PubKey_r --> <-- HDR, KE, PubKey_i, PubKey_i HDR, HASH_I --> <-- HDR, HASH_R John -----Original Message----- From: Dave Clark To: John Irish Date: Wednesday, November 25, 1998 9:27 AM Subject: Re: ISAKMP Extended Authentication Hello John; At 04:00 PM 11/24/98 , you wrote: >Assuming a certificate push were permitted with the first "HDR, SA" packet, >how would the initiator know which CA and certificate type was acceptable to >the responder? Per the IKE spec, issuing a certificate request, when using >public key encryption for authentication in Phase 1, is not supported. I'm new to IKE; forgive me if the answer to this question is obvious ;-) ... where does it say this in the IKE spec? - thanks for your help; Dave Clark From owner-ipsec Wed Nov 25 10:50:17 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA19568 for ipsec-outgoing; Wed, 25 Nov 1998 10:48:31 -0500 (EST) Message-Id: <199811251606.IAA14574@chip.cisco.com> To: John Shriver cc: ipsec@tis.com In-reply-to: Your message of "Mon, 23 Nov 1998 16:10:42 EST." <199811232110.QAA02877@brill.shiva.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14572.912009993.1@cisco.com> Date: Wed, 25 Nov 1998 08:06:33 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Absolutely. That's what section 11 is all about. The ones that are defined are given to IANA and the ones in the range that is "reserved to IANA" are just that. The only ones that are not maintained by IANA are the ones in a range that is for "private use among mutually consenting parties". (And let me note again that writing a draft to say "if you want to do 40bit DES use number 65001" is not the proper use of the private use range since that attempts to define a number out of a range that in intentionally undefined). I'm happy to say it's RFC 2409 now. Dan. On Mon, 23 Nov 1998 16:10:42 EST you wrote > Are the Attribute Assigned Numbers in Appendix A of > draft-ietf-ipsec-isakmp-oakley-08.txt intended to be fully managed by > the IANA just like the ones in draft-ietf-ipsec-ipsec-doi-10.txt? > > The reason is that we want to be sure which "magic numbers" should be > in the IPSEC-DOI-TC MIB, which would be maintained by the IANA. From owner-ipsec Wed Nov 25 11:12:20 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA19776 for ipsec-outgoing; Wed, 25 Nov 1998 11:10:30 -0500 (EST) Message-Id: <365C2F94.2DB77781@hplb.hpl.hp.com> Date: Wed, 25 Nov 1998 16:25:56 +0000 From: SALLE Mathias X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en Mime-Version: 1.0 To: ipsec@tis.com Subject: ISAKMP certificat exchange using transaction exchanges Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Thanks for any comments on the following. SUBJECT: Extension of configuration attributes for draft-ietf-ipsec-isakmp-mode-cfg-04.txt. REFERENCE: draft-ietf-ipsec-isakmp-mode-cfg-04.txt pages 5 and 6. PURPOSE: Transfert a user's SKPI certificates using a transaction exchanges. I am trying to find the best solution in order to transfert a user SPKI certificate within an IPSec connection establishment. Note that the SPKI certificate is not used to authenticate the host but to send user's permissions SCENARIO: A user using host H1 access a file on host H2. To access this file, the user needs to provide a SPKI certificate. We are trying here to make this transfert of certificate independant of the application. The idea is to use the IPSec connection establishment to send the required certificate. A solution would be to use the transaction exchanges define in pages 5 and 6. In such a case, the ISAKMP transaction will be as follows: Initiator (H2) Responder (H1) ----------------- --------------------- HDR*, HASH, ATTR1(REQUEST) --> <-- HDR*,HASH,ATTR2(REPLY) where ATTR1(REQUEST) = SPKI_CERTIFICATE() ATTR2(REPLY) = SPKI_CERTIFICATE(certificate) In this scenario, the certificate is just transported by the transaction exchange and at the IPSec level, there is no use of this certificate. QUESTIONS: In you say: "It is hoped that more attribute types will be defined in the future documents. Some suggestions would be to distribute local policy, or even authenticate certificates." 1. Would it be interesting to add this kind of configuration attributes? 2. The transaction exchange will happen after completion of ISAKMP phase I and therefore the payload will be encrypted. Do you think that the certificate needs to be signed by the host H1 so that H2 knows that the received certificate is the one of the user using H1 or the ISAKMP header (in particular COOKIE-I and COOKIE-R) is enough to know that it is the right certificate? 3. The extended authentication within ISAKMP/Oakley does not mention the use of SPKI certificates? As it could be seen as a one way authentication (and more than just authentication), would it be interesting to have a look at it? 4. There is a lot of emails around ISAKMP/Oakley Certificate Exchange but this exchange happens during PhaseI and not after. What are the benefit of this approach compare to the use of Transaction Exchange? 5. Lastly, it is possible that I am smoking somewhere mixing 2 things that should not be mixed together, therefore, I will appreciate your views on that. Thanks a lot best regards, Mathias -- ___________________________________________ Mathias SALLE Networked Systems Dpt. Hewlett-Packard Research Labs Filton Road Stoke Gifford Bristol BS12 6QZ, UK E-mail: matsal@otter.hpl.hp.com Tel : +44 (0)117 922 9753 ___________________________________________ From owner-ipsec Wed Nov 25 12:56:52 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA20368 for ipsec-outgoing; Wed, 25 Nov 1998 12:54:32 -0500 (EST) Date: Wed, 25 Nov 1998 20:12:52 +0200 (EET) Message-Id: <199811251812.UAA20218@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "John Irish" Cc: "Greg Carter" , "IPSEC" Subject: Re: ISAKMP Extended Authentication In-Reply-To: <008b01be17ed$771363c0$0100010a@irish1> References: <008b01be17ed$771363c0$0100010a@irish1> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 14 min X-Total-Time: 14 min Sender: owner-ipsec@ex.tis.com Precedence: bulk John Irish writes: > Taking this a step further ... presuming you generated this temporary User > certificate. How could the "server" use this certificate to authenticate > via public key "encryption" during an ISAKMP/Oakley (IKE) Phase 1 > negotiation? If you want to use public key encryption authentication then you either must have the certificate already or, you must send it along the first ike packet of the main mode (you cannot use aggressive mode). There are also some other problems with public key encryption authentication. > Assuming a certificate push were permitted with the first "HDR, SA" packet, Yes, it is allowed. The isakmp draft says that certificate payloads may exists in any packet. > how would the initiator know which CA and certificate type was acceptable to > the responder? Per the IKE spec, issuing a certificate request, when using > public key encryption for authentication in Phase 1, is not supported. The isakmp draft says that the certificate request payload may exists in any packet, and the ike draft only limits them in the final packet (== i.e. where it would expand the negotiation). Certificate requests are allowed also with public key encryption authentication. The example in the draft doesn't list any CERT or CR payloads, but that doesn't mean they are not allowed. The problem with the public key encryption is that you must be able to find correct certificate for the other end, when you are encrypting the identity to be send to other end. This means that if the other end doesn't send certificates in the first or second packet then you must have some other method of finding them. Note also, that in this case it doesn't really matter which certificate we choose (temporary user certificate or permanent user certificate), because both of them have the same public key. What we cannot select is the host certificate based on the ip-address, because the other end is using the user public key to authenticate itself, not host public key. The selection is quite easy, because host certificate has the basic constraints extension saying it is CA, so we can select any of the certificates other end sends, that doesn't have CA bit on. > As a Network Computer we are trying to avoid the use of pre-shared > secrets/keys leaving us with public key encryption for the Phase 1 > authentication method. This method would appear to dictate the use of a > directory server to acquire certificates prior to completing the > Diffie-Hellman exchange in Phase 1. Note, that public key signatures authentication doesn't have this restrictions, there we need certificates only in the end to authenticate the full exchange. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Wed Nov 25 13:33:31 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA20524 for ipsec-outgoing; Wed, 25 Nov 1998 13:32:30 -0500 (EST) Date: Wed, 25 Nov 1998 20:51:06 +0200 (EET) Message-Id: <199811251851.UAA20349@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "John Irish" Cc: "Dave Clark" , "IPSEC" Subject: ISAKMP/Oakley - Certificate exchange In-Reply-To: <001601be188b$ebcc2d20$0100010a@irish1> References: <001601be188b$ebcc2d20$0100010a@irish1> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 16 min X-Total-Time: 19 min Sender: owner-ipsec@ex.tis.com Precedence: bulk John Irish writes: > Within the IKE spec , Section 5.2 - > Authentication with Public Key Encryption, the 2nd paragraph states: > > "In order to perform public key encryption, the initiator must already have > the responder's public key." > > My statement should have indicated that the initiator can not issue a > certificate request based upon the statement above. That doesn't say anything about certificate requests or certificates. The isakmp draft (draft-ietf-ipsec-isakmp-10.txt) says: ---------------------------------------------------------------------- 3.9 Certificate Payload ... ... The Certificate payload MUST be accepted at any point during an exchange. ... 3.10 Certificate Request Payload ... ... The Certificate Request payload MUST be accepted at any point dur- ing the exchange. The responder to the Certificate Request payload MUST send its certificate, if certificates are supported, based on the values contained in the payload. ... ---------------------------------------------------------------------- And the ike draft (draft-ietf-ipsec-isakmp-oakley-08.txt) limits the certificate request only by this: ---------------------------------------------------------------------- ... Exchanges in IKE are not open ended and have a fixed number of messages. Receipt of a Certificate Request payload MUST NOT extend the number of messages transmitted or expected. ... ---------------------------------------------------------------------- So and certificate payload MUST be supported in any packet using any authentication method etc. Certificate requests MUST be supported in any packet using any authentication method except when it would expand the exchange (== it cannot be in the final packet). The reason for this: > "In order to perform public key encryption, the initiator must already have > the responder's public key." Is that in order to encrypt the identity and the nonce the initiator needs the public key of the other end in the 3rd packet in the main mode or in the 1st packet in the aggressive mode. So in the aggressive mode using public key encryption as a authentication method the initiator must already have responder's public key. In main mode the initiator needs that certificate only in the when it sends its second packet (3rd packet in the main mode), and if the other end didn't send his certificate in the his first packet (2nd packet in the main mode), and he don't have methods to find the key he has no other choise than to abort the negotiation. Because of this the draft says that you must already have the responder's public key. > It would appear, although it is not stated, that in Main mode the responder > could include a certificate request with the first response packet which > includes the SA payload. It is not clear why the initiator could not > include a certificate request with the very first packet, and the responder > include its certificate plus a certificate request in the first response > packet. It could, but it is not mandated that the responder must send its certificates inside his first packet. The certificate request description only says that the response must come, but it doesn't say when. I think we could remove that paragraph from the draft. In the aggressive mode it is quite clear that we need that certificate before we can start, because we need it to construct the first packet. In the main mode if the initiator is capable of finding certificates it can start the exchange and wait until the second packet before starting the lookup for the certificate. This gives the responder opportunity to send his certificate inside the his first ike packet, saving the initiator a lookup from the directory. > Part of the reason may be that system identities would be revealed > by the certificate exchange in Main mode. That is true, and if that is the reason (it might be), then it should be stated in the draft also. > In addition, the certificate > needed by the initiator may depend upon the proposal selected by the > responder, thus making a certificate request in the first packet premature > (I'm guessing here). Does anyone have an answer to this? That is true, but it doesn't matter. Extra certificates are cheap inside the ike messages, if they save one extra ldap search from the directory... > HDR, SA, CertReq --> > <-- HDR, SA, CERT, CertReq > HDR, KE, CERT, PubKey_r, PubKey_r --> > <-- HDR, KE, PubKey_i, PubKey_i > HDR, HASH_I --> > <-- HDR, HASH_R This doesn't violate the draft, but what do you do if the responder doesn't send his certificate request in his first packet (2nd packet of the whole exchange), but still selected the public key encryption authentication. You can either try to lookup the certificate from somewhere or you can abort the negotiation. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec Wed Nov 25 16:16:10 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA21056 for ipsec-outgoing; Wed, 25 Nov 1998 16:12:31 -0500 (EST) Message-Id: <199811252131.QAA15847@venus.solidum.com> To: ipsec@tis.com Subject: Its officially official now! Date: Wed, 25 Nov 1998 16:31:01 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk A new Request for Comments is now available in online RFC libraries. RFC 2401: Title: Security Architecture for the Internet Protocol Author(s): S. Kent, R. Atkinson Status: Proposed Standard Date: November 1998 ... WooHOO!!!! Not news to the authors, editors, but I don't think this was ever posted to the list: RFC 2401: Security Architecture for the Internet Protocol RFC 2402: IP Authentication header RFC 2403: The Use of HMAC-MD5-96 within ESP and AH RFC 2404: The Use of HMAC-SHA-1-96 within ESP and AH RFC 2405: The ESP DES-CBC Cipher Algorithm With Explicit IV RFC 2406: IP Encapsulating Security Payload (ESP) RFC 2407: The Internet IP Security Domain of Interpretation for ISAKMP RFC 2408: Internet Security Association and Key Management Protocol (ISAKMP) RFC 2409: The Internet Key Exchange (IKE) RFC 2410: The NULL Encryption Algorithm and Its Use With IPsec RFC 2411: IP Security Document Roadmap RFC 2412: The OAKLEY Key Determination Protocol The numbering is a bit unfortunate, as reading them in series doesn't give you the best view, but ... yeah ... now I just have to explain to my wife why I'm so happy when I get home. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: mcr@solidum.com. From owner-ipsec Wed Nov 25 16:50:58 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA21222 for ipsec-outgoing; Wed, 25 Nov 1998 16:50:34 -0500 (EST) Message-ID: <365C8019.264D424C@mit.edu> Date: Wed, 25 Nov 1998 17:09:29 -0500 From: "Jeffrey I. Schiller" Organization: Massachusetts Institute of Technology X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.30 i586) X-Accept-Language: en MIME-Version: 1.0 To: Michael Richardson CC: ipsec@tis.com Subject: Re: Its officially official now! References: <199811252131.QAA15847@venus.solidum.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Happy Thanksgiving... -Jeff From owner-ipsec Wed Nov 25 17:17:36 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA21326 for ipsec-outgoing; Wed, 25 Nov 1998 17:16:36 -0500 (EST) Message-Id: <199811252235.OAA19451@gallium.network-alchemy.com> To: Michael Richardson Cc: ipsec@tis.com Subject: Re: Its officially official now! In-reply-to: Your message of "Wed, 25 Nov 1998 16:31:01 EST." <199811252131.QAA15847@venus.solidum.com> Date: Wed, 25 Nov 1998 14:35:12 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hell Freezes Over. Film at 11. From owner-ipsec Wed Nov 25 19:05:29 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id TAA21583 for ipsec-outgoing; Wed, 25 Nov 1998 19:04:36 -0500 (EST) From: "Jeff Carr" To: Subject: RE: Bundle or not in negotiation Date: Wed, 25 Nov 1998 16:23:43 -0800 Message-ID: <000701be18d3$06a204c0$75a8a8c0@pc-jcarr.broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <365464EF.745F8459@redcreek.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@ex.tis.com Precedence: bulk Would someone please address Scott's earlier questions; copied in the paragraph below? This is my understanding according to the "Security Architecture for the IP" ---- but now I am not sure that I can do this with ISKAMP without breaking something. I thought the SPD would dictate these relationships. Scott G. Kelly wrote: > This nails another point that's been nagging at me lately: the > architecture explicitly permits sharing of SAs, which I take to mean > between different endpoints which match the policy rule used to > instantiate the SAs to begin with. However, there is no way (that I can > see) to negotiate this in IKE. That is, once the SA is instantiated, > there doesn't seem to be any way to negotiate the addition of more > endpoints to it. It appears that fresh SAs must be negotiated, with new > keys, etc. My first thought was that I could just pass the SPI of the > instantiated SA in the later negotiations, but there's no way to > indicate that the original keying material should be shared. Am I way > out there on this, or should we think about a way to permit this in IKE? > From owner-ipsec Wed Nov 25 23:24:31 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id XAA22223 for ipsec-outgoing; Wed, 25 Nov 1998 23:22:37 -0500 (EST) Message-Id: <4.1.19981125233904.00bb4680@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 25 Nov 1998 23:40:59 -0500 To: "Jeffrey I. Schiller" , Michael Richardson From: Robert Moskowitz Subject: Re: Its officially official now! Cc: ipsec@tis.com In-Reply-To: <365C8019.264D424C@mit.edu> References: <199811252131.QAA15847@venus.solidum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 05:09 PM 11/25/98 -0500, Jeffrey I. Schiller wrote: >Happy Thanksgiving... > And I want to thank everyone here. People who have put in a lot of hours to get us to a solid baseline for IPsec/IKE. Jeff, thanks for bird-dogging this through the IESG. I know it was not an easy road. I will be getting a rough agenda out, hopefully within 24 hours. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Fri Nov 27 15:12:19 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA29616 for ipsec-outgoing; Fri, 27 Nov 1998 15:04:31 -0500 (EST) Message-Id: <4.1.19981127123012.00b9eef0@homebase.htt-consult.com> Message-Id: <4.1.19981127123012.00b9eef0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 27 Nov 1998 15:23:15 -0500 To: ipsec@tis.com From: Robert Moskowitz Subject: Agenda stuff Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk OK we have 2 hours on tuesday afternoon. I have attempted to collect 9 months of notes to figure out where we are going now. So here it is. I will collect comments through monday night and get a first agenda draft out for tuesday. (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: RFC and blocked ID status T'so draft-ietf-ipsec-auth-hmac-ripemd-160-96-02.txt draft-simpson-desx-02.txt Revs for IKE D. Harkins Revs for DOI Rekeying T. Jenkins draft-jenkins-ipsec-rekeying-00.txt New Items: Rechartering Moskowitz MIBs T. Jenkins draft-ietf-ipsec-mib-02.txt IPsec items 'Transport friendly ESP' Bellovin ICMP handling M. Richardson draft-ietf-ipsec-icmp-handle-v4-00.txt draft-ietf-ipsec-icmp-options-00.txt draft-richardson-ipsec-pmtu-discov-02.txt Digital Certs X.509 req R. Thayer draft-ietf-ipsec-pki-req-01.txt DNSSEC ?? IKE items Error messages ?? MS Kerberos auth Dixon Xauth Pereira draft-ietf-ipsec-isakmp-mode-cfg-04.txt draft-ietf-ipsec-isakmp-xauth-03.txt draft-gupta-ipsec-remote-access-01.txt Hybrid auth M. Litvin, R. Shamir ?? draft-litvin-ipsec-isakmp-hybrid-auth-00.txt Policy Schema Pereira draft-ietf-ipsec-vpn-policy-schema-00.txt draft-ietf-policy-core-schema-00.txt draft-ietf-ipsec-secconf-00.txt Policy engine M. Condell, C. Lynn, J. Zao ? draft-ietf-ipsec-spsl-00.txt NAT Issues ??? draft-montenegro-aatn-nar-00.txt draft-moskowitz-net66-vpn-00.txt draft-ietf-nat-hnat-00.txt draft-ietf-nat-security-00.txt SA Mobility Daniels?? Mulitcast ?? draft-canetti-secure-multicast-taxonomy-00.txt draft-ietf-ipsec-gkmframework-00.txt draft-wallner-key-arch-01.txt draft-ietf-ipsec-intragkm-00.txt APIs ?? draft-mcdonald-pf-key-v2-06.txt JAVA Security API? Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Mon Nov 30 08:25:13 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA05830 for ipsec-outgoing; Mon, 30 Nov 1998 08:15:19 -0500 (EST) Date: Mon, 30 Nov 1998 15:34:17 +0200 (EET) From: Markku Savela Message-Id: <199811301334.PAA28327@anise.tte.vtt.fi> To: ipsec@tis.com Subject: Use IPSEC as SSH replacement Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@ex.tis.com Precedence: bulk Just some idle thoughs... Not knowing enoguh of the IKE/ISAKMP, I need to ask: Does it support a similar system as SSH? That is, asuming IKE/IPSEC implementation on both ends, two totally unrelated hosts can setup a secure connection between them. Without any preconfigured keys or knowledge about each others public keys? After that one could just use unmodified tools (telnet, smtp, etc) again. And the next step: perhaps we could have a "conditional policy": even when communication is allowed to be in clear, the system would just activate KEY negotiation on parallel, and if the other end actually replies and loads SA's, IPSEC would kick in (and, of course should remain enforced from then on during that session). -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec Mon Nov 30 09:23:50 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA06091 for ipsec-outgoing; Mon, 30 Nov 1998 09:22:19 -0500 (EST) Message-Id: <199811301441.JAA18980@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Use IPSEC as SSH replacement In-Reply-To: Your message of "Mon, 30 Nov 1998 15:34:17 +0200." <199811301334.PAA28327@anise.tte.vtt.fi> Date: Mon, 30 Nov 1998 09:41:35 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Markku" == Markku Savela writes: Markku> Does it support a similar system as SSH? That is, asuming Markku> IKE/IPSEC implementation on both ends, two totally unrelated Markku> hosts can setup a secure connection between them. Without any Markku> preconfigured keys or knowledge about each others public keys? Markku> After that one could just use unmodified tools (telnet, smtp, Markku> etc) again. Two unrelated hosts could *not* set up a secure connection, as they would have no mechanism to trust each other, although doing opportunistic encryption is one of the goals of the FreeSWAN project. Such encryption does not provide security. SSH has the same properties, but it provides an easy way to make the initial exchange of keys. That initial connection is generaly not secure. If SSH or IKE end points have signaatures from a common CA, then there is probably a way to establish trusted connection. (There may be other issues that prevent it). But that requires "preconfiguration" of the root CA. Markku> And the next step: perhaps we could have a "conditional policy": Markku> even when communication is allowed to be in clear, the system Markku> would just activate KEY negotiation on parallel, and if the other Markku> end actually replies and loads SA's, IPSEC would kick in (and, of Markku> course should remain enforced from then on during that session). FreeSWAN may provide something like this. However, since the first thing I do in a session is type my password in, I'd rather wait. :!mcr!: | Network and security consulting/contract programming Michael Richardson | Firewalls, TCP/IP and Unix administration Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. From owner-ipsec Mon Nov 30 09:37:03 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA06196 for ipsec-outgoing; Mon, 30 Nov 1998 09:36:20 -0500 (EST) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199811301455.GAA07093@kc.livingston.com> Subject: Re: Agenda stuff To: rgm-sec@htt-consult.com (Robert Moskowitz) Date: Mon, 30 Nov 1998 06:55:23 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <4.1.19981127123012.00b9eef0@homebase.htt-consult.com> from "Robert Moskowitz" at Nov 27, 98 03:23:15 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Robert, The IETF agenda page has two time-slots for IPsec WG. 1300-1415 on tuesday and 0900-1130 wednesday. One for IPsec and another for IPsecond? You have a lot of items listed for the agenda. Below is a draft I noticed missing mention in your list. This seems relevant in the context of secure policy specification and exchange in IKE. "The Keynote Trust-Management System" Also, I wanted to mention that two of the drafts you list under "NAT list" are going to be reviewed in NAT WG. Thanks. Have a nice day. regards, suresh > > OK we have 2 hours on tuesday afternoon. I have attempted to collect 9 > months of notes to figure out where we are going now. So here it is. I > will collect comments through monday night and get a first agenda draft out > for tuesday. > > (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: > > RFC and blocked ID status T'so > draft-ietf-ipsec-auth-hmac-ripemd-160-96-02.txt > draft-simpson-desx-02.txt > Revs for IKE D. Harkins > Revs for DOI > Rekeying T. Jenkins > draft-jenkins-ipsec-rekeying-00.txt > > New Items: > > Rechartering Moskowitz > MIBs T. Jenkins > draft-ietf-ipsec-mib-02.txt > > IPsec items > > 'Transport friendly ESP' Bellovin > ICMP handling M. Richardson > draft-ietf-ipsec-icmp-handle-v4-00.txt > draft-ietf-ipsec-icmp-options-00.txt > draft-richardson-ipsec-pmtu-discov-02.txt > > > Digital Certs > > X.509 req R. Thayer > draft-ietf-ipsec-pki-req-01.txt > DNSSEC ?? > > > IKE items > > Error messages ?? > MS Kerberos auth Dixon > Xauth Pereira > draft-ietf-ipsec-isakmp-mode-cfg-04.txt > draft-ietf-ipsec-isakmp-xauth-03.txt > draft-gupta-ipsec-remote-access-01.txt > Hybrid auth M. Litvin, R. Shamir ?? > draft-litvin-ipsec-isakmp-hybrid-auth-00.txt > Policy Schema Pereira > draft-ietf-ipsec-vpn-policy-schema-00.txt > draft-ietf-policy-core-schema-00.txt > draft-ietf-ipsec-secconf-00.txt > Policy engine M. Condell, C. Lynn, J. Zao ? > draft-ietf-ipsec-spsl-00.txt > NAT Issues ??? > draft-montenegro-aatn-nar-00.txt > draft-moskowitz-net66-vpn-00.txt > draft-ietf-nat-hnat-00.txt > draft-ietf-nat-security-00.txt > SA Mobility Daniels?? > Mulitcast ?? > draft-canetti-secure-multicast-taxonomy-00.txt > draft-ietf-ipsec-gkmframework-00.txt > draft-wallner-key-arch-01.txt > draft-ietf-ipsec-intragkm-00.txt > APIs ?? > draft-mcdonald-pf-key-v2-06.txt > JAVA Security API? > > > > > Robert Moskowitz > ICSA > Security Interest EMail: rgm-sec@htt-consult.com > From owner-ipsec Mon Nov 30 10:48:39 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA06605 for ipsec-outgoing; Mon, 30 Nov 1998 10:47:28 -0500 (EST) Date: Mon, 30 Nov 1998 11:06:04 -0500 (EST) From: Henry Spencer To: Markku Savela cc: ipsec@tis.com Subject: Re: Use IPSEC as SSH replacement In-Reply-To: <199811301334.PAA28327@anise.tte.vtt.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > Does it support a similar system as SSH? That is, asuming IKE/IPSEC > implementation on both ends, two totally unrelated hosts can setup a > secure connection between them. Without any preconfigured keys or > knowledge about each others public keys? It's close. The two IKE daemons need a way to authenticate each other, and that needs either shared secrets or a trusted third party. SSH has this requirement too, hidden in its "I haven't talked to that host before, should I accept that he's telling the truth about who he is?" question, but IKE needs a more definitive solution than "ask the user". The trusted third party for IKE could be Secure DNS, or it could be a certificate authority whose identity and authenticity is known to the IKE daemon by other means. > After that one could just use unmodified tools (telnet, smtp, etc) > again. Exactly. IPSEC is secure *IP*, which covers all IP-using applications. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec Mon Nov 30 14:33:46 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA08174 for ipsec-outgoing; Mon, 30 Nov 1998 14:30:39 -0500 (EST) Message-Id: <4.1.19981130144233.00bb3820@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 30 Nov 1998 14:47:05 -0500 To: suresh@livingston.com (Pyda Srisuresh) From: Robert Moskowitz Subject: Re: Agenda stuff Cc: ipsec@tis.com In-Reply-To: <199811301455.GAA07093@kc.livingston.com> References: <4.1.19981127123012.00b9eef0@homebase.htt-consult.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 06:55 AM 11/30/98 -0800, Pyda Srisuresh wrote: > >The IETF agenda page has two time-slots for IPsec WG. 1300-1415 on >tuesday and 0900-1130 wednesday. One for IPsec and another for IPsecond? Hey, I missed that! Ted put in for 2 slots and I thought that the 1 full slot equals 2. So with attention to timings we can cover a lot this week. >You have a lot of items listed for the agenda. Below is a draft I noticed >missing mention in your list. This seems relevant in the context of secure >policy specification and exchange in IKE. > >"The Keynote Trust-Management System" > Yes, I should have included that, as I talked at the BOF in chicago! >Also, I wanted to mention that two of the drafts you list under "NAT list" >are going to be reviewed in NAT WG. Ah, but they have IPec implications, just like Matts policy. I was trying to raise awareness so that we know what we have to deal with. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Mon Nov 30 21:15:46 1998 Received: by portal.ex.tis.com (8.9.1/8.9.1) id VAA09523 for ipsec-outgoing; Mon, 30 Nov 1998 21:13:45 -0500 (EST) Message-Id: <199812010231.VAA15466@jekyll.piermont.com> To: Henry Spencer cc: Markku Savela , ipsec@tis.com Subject: Re: Use IPSEC as SSH replacement In-reply-to: Your message of "Mon, 30 Nov 1998 11:06:04 EST." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 30 Nov 1998 21:31:48 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk I had originally hoped, in fact, that IPSec would make tools like SSH unnecessary by providing upper layer tools sufficient information that they could simply ask the identity of the other side of any TCP session from the security layer and not need to manage any cryptography on their own at all. Sadly, things have not thus far worked out this way, but it is not an unreasonable goal for people to be striving for. Perry Henry Spencer writes: > > Does it support a similar system as SSH? That is, asuming IKE/IPSEC > > implementation on both ends, two totally unrelated hosts can setup a > > secure connection between them. Without any preconfigured keys or > > knowledge about each others public keys? > > It's close. The two IKE daemons need a way to authenticate each other, > and that needs either shared secrets or a trusted third party. SSH has > this requirement too, hidden in its "I haven't talked to that host before, > should I accept that he's telling the truth about who he is?" question, > but IKE needs a more definitive solution than "ask the user". > > The trusted third party for IKE could be Secure DNS, or it could be a > certificate authority whose identity and authenticity is known to the IKE > daemon by other means. > > > After that one could just use unmodified tools (telnet, smtp, etc) > > again. > > Exactly. IPSEC is secure *IP*, which covers all IP-using applications.