From owner-ipsec Tue Apr 1 14:46:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA06195 for ipsec-outgoing; Tue, 1 Apr 1997 14:26:38 -0500 (EST) Message-Id: <199704011932.LAA28570@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Stephen Kent Cc: ipsec@tis.com Subject: MUST vs. SHOULD audit Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 01 Apr 1997 11:32:10 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, This is taken from draft-ietf-ipsec-auth-04.txt but there is similar wording in the esp draft as well so my comments apply there too. From section 3.3.2 Security Association Lookup: > If no valid Security Association exists for this session (e.g., the > receiver has no key), the receiver MUST discard the packet and the > failure MUST be recorded in an audit log. I don't want to discount the wisdom of auditing (and am, in fact, all in favor of it) but I don't want to see an otherwise conforming implementation be rendered non-conforming simply because it didn't audit. Some devices which provide IPsec have no harddisk and a limited amount of memory (e.g. a router) and auditing of packets that arrive for which no valid SA exists opens one up to a denial-of-service attack. I propose that "the failure MUST be recorded" be changed to "the failure SHOULD be recorded". Also, section 3.3.3 Sequence Number Verification states: > If the received packet falls within the window, then the receiver > proceeds to ICV verification. If the ICV validation fails, the > receiver MUST discard the received IP datagram as invalid and MUST > record the authentication failure in an audit log. I believe the 2nd sentence should begin, "If the sequence number check fails...." since the next section, 3.3.4 Integrity Check Value Verification states: > If the computed and received ICV's match, then the datagram is valid, > and it is accepted. If the test fails, then the receiver MUST > discard the received IP datagram as invalid and MUST record the > authentication failure in an audit log. Of course, I would also like those two references to "MUST audit" be changed to "SHOULD audit". regards, Dan. From owner-ipsec Tue Apr 1 16:00:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA06752 for ipsec-outgoing; Tue, 1 Apr 1997 15:52:40 -0500 (EST) Date: Tue, 1 Apr 1997 15:55:36 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704012055.PAA15379@earth.hpc.org> To: dharkins@cisco.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199704012006.NAA23247@baskerville.CS.Arizona.EDU> Subject: Re: MUST vs. SHOULD audit Sender: owner-ipsec@ex.tis.com Precedence: bulk An implementation that is not capable of auditing these events wouldn't conform to the expectations of the community. What I'd think would be reasonable would be to say that if the platform has an audit facility, these events must be logged. This leaves open the possibility of tailoring the logging rate for this event type to the system administrator. After all, IPSEC is unlikely to be the only way to introduce denial of service through excessive logging, so the audit system must already be capable of dealing with such things. If there is no audit facility, should one say that IPSEC cannot be implemented on that platform? Seems drastic, but less drastic than requiring that IPSEC implementations carry a full audit log capability along with them. Hilarie From owner-ipsec Tue Apr 1 16:22:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA06964 for ipsec-outgoing; Tue, 1 Apr 1997 16:19:58 -0500 (EST) Date: Tue, 1 Apr 1997 16:22:07 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704012122.QAA16158@earth.hpc.org> To: HUGO@watson.ibm.com Cc: iesg@ietf.org, IPSEC@tis.com, DHARKINS@cisco.com, carrel@ipsec.org, RJA@inet.org, PALAMBER@us.oracle.com, CANETTI@watson.ibm.com In-reply-to: Yourmessage <199703250456.VAA15742@baskerville.CS.Arizona.EDU> Subject: Re: oakley-03: last call comments Sender: owner-ipsec@ex.tis.com Precedence: bulk I agree that the first recommendation in its entirety is very important and must be implemented. Hilarie From owner-ipsec Tue Apr 1 16:50:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07275 for ipsec-outgoing; Tue, 1 Apr 1997 16:39:40 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199704011932.LAA28570@dharkins-ss20> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 1 Apr 1997 16:44:10 -0500 To: Daniel Harkins From: Stephen Kent Subject: Re: MUST vs. SHOULD audit Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, I was worried about the MUSTs in both documents re auditing and potential denial of service implications, but chose to copy them and hope for feedback from the WG. I'd be comfortable with a spec that required logging if the platform already supported audit, but I'm up in the air re the right requirement if the platform does not perform audit. If marking this case as SHOULD would make folks happy, I'm certainly comfortable with that sort of change, though I'm not sure what the bottom line effect would be. Thanks for catching the "ICV" vs. "sequence number" check typo. Steve From owner-ipsec Tue Apr 1 16:50:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07283 for ipsec-outgoing; Tue, 1 Apr 1997 16:40:36 -0500 (EST) Message-Id: <199704012145.NAA28713@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ho@earth.hpc.org (Hilarie Orman) Cc: ipsec@tis.com Subject: Re: MUST vs. SHOULD audit In-Reply-To: Your message of "Tue, 01 Apr 1997 15:55:36 EST." <199704012055.PAA15379@earth.hpc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 01 Apr 1997 13:45:42 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Hilarie, My feeling is that auditing is a local matter and not part of the protocol. > An implementation that is not capable of auditing these events > wouldn't conform to the expectations of the community. What I'd think > would be reasonable would be to say that if the platform has an audit > facility, these events must be logged. This leaves open the > possibility of tailoring the logging rate for this event type to the > system administrator. After all, IPSEC is unlikely to be the only way > to introduce denial of service through excessive logging, so the audit > system must already be capable of dealing with such things. I think the market will decide what the expectations of the community are. > If there is no audit facility, should one say that IPSEC cannot be > implemented on that platform? Seems drastic, but less drastic than > requiring that IPSEC implementations carry a full audit log capability > along with them. That's really drastic. If an implementation does all the mandatory transforms and the mandatory key management and interoperates with every other implement- ation are you saying that it's not IPsec because it doesn't audit? It's a wise thing to audit (and an even wiser thing to be able to tailor a logging rate) and there should be mention of it as a security recommendation in the drafts, but I don't feel such a local matter which does not affect the bits-on-the-wire should be part of the definition of what makes you IPsec-compliant. Dan. From owner-ipsec Tue Apr 1 17:16:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA07628 for ipsec-outgoing; Tue, 1 Apr 1997 17:15:24 -0500 (EST) From: Uri Blumenthal Message-Id: <9704012220.AA31931@hawpub.watson.ibm.com> Subject: Re: MUST vs. SHOULD audit To: dharkins@cisco.com (Daniel Harkins) Date: Tue, 1 Apr 1997 17:20:32 -0500 (EST) Cc: ipsec@tis.com In-Reply-To: <199704012145.NAA28713@dharkins-ss20> from "Daniel Harkins" at Apr 1, 97 01:45:42 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Daniel Harkins says: > My feeling is that auditing is a local matter and not part of the > protocol. I support this. > > would be reasonable would be to say that if the platform has an audit > > facility, these events must be logged....... I think that IPSEC defines the protocol. How much of the exchange should be logged (if at all) is personal business of the implementor. Different buyers may have different req's wrt. this and make their purchasing choice accordingly. Still, it's not IPSEC's business. > > If there is no audit facility, should one say that IPSEC cannot be > > implemented on that platform? Of course not. One should not say anything, except: "THIS IS AN IMPLEMENTATION-SPECIFIC ISSUE". If you want it to be REMOTELY controlled, then it's a remote management issue, which again, isn't really part of IPSEC. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Tue Apr 1 18:03:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA07862 for ipsec-outgoing; Tue, 1 Apr 1997 18:00:13 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199704012305.PAA03949@kebe.eng.sun.com> Subject: Re: MUST vs. SHOULD audit To: ipsec@tis.com Date: Tue, 1 Apr 1997 15:05:30 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > My feeling is that auditing is a local matter and not part of the > protocol. I have to agree with Dan on this one. *I* have logging facilities and will do my best to log where I can. OTOH, a small system, like a router or perhaps a Javastation, won't necessarily have all of these capabilities. > there should be mention of it as a security recommendation in the drafts, Great idea! This is the sort of issue the _Security Recommendations_ are for. Dan McD. (disambiguating token added) From owner-ipsec Tue Apr 1 19:09:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA08205 for ipsec-outgoing; Tue, 1 Apr 1997 19:08:05 -0500 (EST) Message-ID: <3341A51E.4EFC@htc.sj.nec.com> Date: Tue, 01 Apr 1997 16:15:26 -0800 From: Bill Pabst Reply-To: bpabst@holontech.com Organization: Holontech X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: Hilarie Orman CC: dharkins@cisco.com, ipsec@tis.com Subject: Re: MUST vs. SHOULD audit References: <199704012055.PAA15379@earth.hpc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Would this be something that could be enabled/disabled through a Radius Server with its audit and accounting capibilities? New to the Group. Bill From owner-ipsec Tue Apr 1 19:33:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA08347 for ipsec-outgoing; Tue, 1 Apr 1997 19:33:37 -0500 (EST) Message-Id: <199704020037.QAA00806@fluffy.cisco.com> To: ipsec@tis.com Subject: auditing Date: Tue, 01 Apr 1997 16:37:41 -0800 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk Auditing is obviously a host-system issue and outside of the scope of the network protocol or IPSEC architecture document(s). However, there's nothing wrong with pointing out where a host should perform auditing, if it's capable of doing so. In this spirit, it would seem more appropriate for the specs to read SHOULD instead of MUST. Derrell From owner-ipsec Wed Apr 2 10:20:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13719 for ipsec-outgoing; Wed, 2 Apr 1997 10:17:44 -0500 (EST) Date: Wed, 2 Apr 1997 10:20:18 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704021520.KAA18004@earth.hpc.org> To: ipsec@tis.com Subject: Re: MUST vs. SHOULD audit Sender: owner-ipsec@ex.tis.com Precedence: bulk Of course interoperability is the main point of the spec, but is the discussion so far well-founded? I'm a little confused by the responses --- most seem comfortable having the audit requirement mentioned, as long as it's "should", but a "must" is declared out of scope for a protocol specification. That doesn't seem logical; if you're in for a "should", then you're in for a "must". If there is an important security-related protocol event, it seems to me on technical grounds that it "must" be logged, if at all possible. If that can't be said in the protocol specification, then it "must" go somewhere else. If the logging is deemed crucial, then we can discuss where to put the requirement, I suppose. I'd thought the group would have interest in whether or not receipt of an invalid SA identifier (or any similar event) is significant enough to require logging. I'd thought the reason in favor would be that anything that seemed to indicate an attempt to explore the valid security states of the host would probably indicate an attack attempt, and it would be critically important to notify the administrator, if at all possible. And I'd thought the argument against would be that the built-in safeguards are strong enough to render such attempts feeble and useless. I can appreciate the reasons for the "should" preference on grounds of scope, but maybe the requirements for security protocol implementations "should" be more stringent. Not so stringent as to constitute denial of solution, but something more than an SEP* nod to security technology that is not evident on-the-wire. Hilarie * Somebody Else's Problem, cit. Douglas Adams From owner-ipsec Wed Apr 2 10:27:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13783 for ipsec-outgoing; Wed, 2 Apr 1997 10:27:19 -0500 (EST) Message-Id: <3.0.1.32.19970402101620.0072de94@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 02 Apr 1997 10:16:20 -0500 To: Derrell Piper From: Rodney Thayer Subject: Re: auditing Cc: ipsec@tis.com In-Reply-To: <199704020037.QAA00806@fluffy.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I think auditing is WITHIN scope since as an IETF WG we've been told we need to address all those real-world issues a draft is supposed to cover, including network management. Auditing is one form of network management. In fact, we should have our own SNMP MIB and be generating (in my opinion optional) traps at theses points where the docs reference auditing. [Refer to Bradner's talk at the San Jose IETF meeting for my thinking we've been told we should consider network management.] At 04:37 PM 4/1/97 -0800, you wrote: >Auditing is obviously a host-system issue and outside of the scope of the >network protocol or IPSEC architecture document(s). However, there's >nothing wrong with pointing out where a host should perform auditing, if >it's capable of doing so. In this spirit, it would seem more appropriate >for the specs to read SHOULD instead of MUST. > >Derrell > > -------- Rodney Thayer PGP: BB1B6428 409129AC 076B9DE1 4C250DD8 From owner-ipsec Wed Apr 2 12:29:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14681 for ipsec-outgoing; Wed, 2 Apr 1997 12:26:28 -0500 (EST) Date: Wed, 2 Apr 97 17:18:56 GMT Daylight Time From: Ran Atkinson Subject: Re: MUST vs. SHOULD audit To: Daniel Harkins Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199704011932.LAA28570@dharkins-ss20> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk [co-chair hat off; IPsec implementer and former cisco coder hat on :-] Dan, Ciscos do have the ability to record events to logging hosts that are outside the router which do have non-volatile storage (an SNMP trap is an example of such a mechanism[1], though cisco IOS has other possibilities in addition). This would fully meet the requirement of "MUST audit" as currently written in the draft. Note also that, this is not a new requirement as it exists also in the current RFCs which were previously agreed to by this WG. Past experience in security-related IETF documents is that anything not made "MUST implement" is generally not implemented. As you note, auditing is an important property of an IPsec implementation because it is a good way of detecting important security-relevant events (e.g. a denial of service attack on the cisco that causes the router to spend cycles computing MD5 over forgeries instead of forwarding packets). If the language is changed at all (which I don't believe is best), I'd propose changing it to something like "IPsec implementations having access to non-volatile storage MUST audit... and all other implementations SHOULD audit...". Ran rja@inet.org [1] In the absence of SNMP security, an SNMP trap is not the best choice for security-related logging, IMHO. From owner-ipsec Wed Apr 2 12:36:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14736 for ipsec-outgoing; Wed, 2 Apr 1997 12:35:33 -0500 (EST) Message-Id: <199704021740.JAA00327@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ho@earth.hpc.org (Hilarie Orman) Cc: ipsec@tis.com Subject: Re: MUST vs. SHOULD audit In-Reply-To: Your message of "Wed, 02 Apr 1997 10:20:18 EST." <199704021520.KAA18004@earth.hpc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 02 Apr 1997 09:40:08 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > Of course interoperability is the main point of the spec, but is the > discussion so far well-founded? I'm a little confused by the > responses --- most seem comfortable having the audit requirement > mentioned, as long as it's "should", but a "must" is declared out of > scope for a protocol specification. That doesn't seem logical; if > you're in for a "should", then you're in for a "must". Well, no. There's language in the drafts for "MUST", "SHOULD", and "MAY" for a reason. They're not all the same and being in for "SHOULD" does not make you in for "MUST". [snip] > I can appreciate the reasons for the "should" preference on grounds of > scope, but maybe the requirements for security protocol > implementations "should" be more stringent. Not so stringent as to > constitute denial of solution, but something more than an SEP* nod to > security technology that is not evident on-the-wire. I'm confused now. Are you saying that an implementation that implements all the mandatory transforms and the mandatory key management and interoperates with every other "IPsec compliant" implementation is itself not "IPsec compliant" because it doesn't do auditing? Dan. From owner-ipsec Wed Apr 2 12:46:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14797 for ipsec-outgoing; Wed, 2 Apr 1997 12:45:06 -0500 (EST) Date: Wed, 2 Apr 1997 12:47:57 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704021747.MAA22459@earth.hpc.org> To: dharkins@cisco.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199704021740.JAA00327@dharkins-ss20> Subject: Re: MUST vs. SHOULD audit Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm not taking much of a stand on the issue of whether or not auditing should be required, it's more the form of the debate that is at issue. > > Of course interoperability is the main point of the spec, but is the > > discussion so far well-founded? I'm a little confused by the > > responses --- most seem comfortable having the audit requirement > > mentioned, as long as it's "should", but a "must" is declared out of > > scope for a protocol specification. That doesn't seem logical; if > > you're in for a "should", then you're in for a "must". > Well, no. There's language in the drafts for "MUST", "SHOULD", and "MAY" > for a reason. They're not all the same and being in for "SHOULD" does not > make you in for "MUST". No, I'm just saying that if a sentence containing "should" is in scope then "must" also would be in scope. > > I can appreciate the reasons for the "should" preference on grounds of > > scope, but maybe the requirements for security protocol > > implementations "should" be more stringent. Not so stringent as to > > constitute denial of solution, but something more than an SEP* nod to > > security technology that is not evident on-the-wire. > I'm confused now. Are you saying that an implementation that implements > all the mandatory transforms and the mandatory key management and > interoperates with every other "IPsec compliant" implementation is itself > not "IPsec compliant" because it doesn't do auditing? I'm saying that it is an allowable outcome of group discussion. Hilarie From owner-ipsec Wed Apr 2 12:48:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14869 for ipsec-outgoing; Wed, 2 Apr 1997 12:47:38 -0500 (EST) Message-Id: <97Apr2.125416est.11649@elgreco.rnd.border.com> To: ho@earth.hpc.org (Hilarie Orman) cc: ipsec@tis.com Subject: Re: MUST vs. SHOULD audit References: <199704021520.KAA18004@earth.hpc.org> In-reply-to: Your message of "Wed, 02 Apr 1997 10:20:18 -0500". <199704021520.KAA18004@earth.hpc.org> From: "C. Harald Koch" X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Wed, 2 Apr 1997 12:52:39 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199704021520.KAA18004@earth.hpc.org>, Hilarie Orman writes: > Of course interoperability is the main point of the spec, but is the > discussion so far well-founded? I'm a little confused by the > responses --- most seem comfortable having the audit requirement > mentioned, as long as it's "should", but a "must" is declared out of > scope for a protocol specification. That doesn't seem logical; if > you're in for a "should", then you're in for a "must". >From RFC 2119: 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. I'd postulate that "must if possible" is the same as "should", given these definitions of the words. -- Harald Koch From owner-ipsec Wed Apr 2 12:53:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14954 for ipsec-outgoing; Wed, 2 Apr 1997 12:52:10 -0500 (EST) Date: Wed, 2 Apr 97 17:33:59 GMT Daylight Time From: Ran Atkinson Subject: Re: MUST vs. SHOULD audit To: Bill Pabst , Hilarie Orman Cc: dharkins@cisco.com, ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <3341A51E.4EFC@htc.sj.nec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Tue, 01 Apr 1997 16:15:26 -0800 Bill Pabst wrote: > Would this be something that could be enabled/disabled through a Radius > Server with its audit and accounting capibilities? > > New to the Group. > > Bill A fine idea. RADIUS has some transmission security built-in, hence might be a better choice than an insecure SNMP Trap. cisco routers support RADIUS Accounting as of (at least) IOS 11.2, as I've been learning lately. Another observation is that cisco implemented full DNSIX (a US DoD networking security protocol suite to support MLS with IP networks) a long while back (IOS 10.0 ? 9.21 ?) -- including full support for the DNSIX Audit Protocol (if you have a cisco router, you can see this by browsing at the top level of "config term" using the string "dnsix ?"... So there ought to be several ways that cisco can comply with the current I-Ds without having to write gobs of new code. I'd suggest that other router vendors can use similar methods for addressing the same issue. Ran rja@inet.org From owner-ipsec Wed Apr 2 12:56:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14967 for ipsec-outgoing; Wed, 2 Apr 1997 12:55:12 -0500 (EST) To: ho@earth.hpc.org (Hilarie Orman) Cc: ipsec@tis.com Subject: Re: MUST vs. SHOULD audit References: <199704021520.KAA18004@earth.hpc.org> From: Marc Horowitz Date: 02 Apr 1997 13:00:02 -0500 In-Reply-To: ho@earth.hpc.org's message of Wed, 2 Apr 1997 10:20:18 -0500 Message-ID: Lines: 25 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-ipsec@ex.tis.com Precedence: bulk ho@earth.hpc.org (Hilarie Orman) writes: >> I'd thought the group would have interest in whether or not receipt of >> an invalid SA identifier (or any similar event) is significant enough >> to require logging. I'd thought the reason in favor would be that >> anything that seemed to indicate an attempt to explore the valid >> security states of the host would probably indicate an attack attempt, >> and it would be critically important to notify the administrator, if >> at all possible. And I'd thought the argument against would be that >> the built-in safeguards are strong enough to render such attempts >> feeble and useless. I think this issue explains why people are against making auditing a must. Some sites will want to know about every conceivable event. Some sites will run high-profile services which will get probed so often that logging such probes would be a waste of cheap disk space. Having the protocol spec flag certain events as candidates for auditing seems like a fine idea. However, stating what should or must be logged it seems like it would be more appropriate in a Best Current Practices (BCP) document, rather than a protocol RFC. You could even have more than one, from the billion-dollar paranoid financial industry logging BCP to the toaster oven logging BCP. Marc From owner-ipsec Wed Apr 2 12:59:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14983 for ipsec-outgoing; Wed, 2 Apr 1997 12:58:14 -0500 (EST) Message-Id: <199704021803.KAA00360@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Ran Atkinson Cc: ipsec@tis.com Subject: Re: MUST vs. SHOULD audit In-Reply-To: Your message of "Wed, 02 Apr 1997 17:18:56 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 02 Apr 1997 10:03:32 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran, While my motivation for starting this may be obvious, I would feel the same way if I had a 5GB disk at my disposal. Auditing is not germane to the protocol itself. Its a security feature that is very valuable but I don't think it should be part of the definition of what makes an implementation be "IPsec compliant". The suggestion that implementors don't do the "SHOULD implement" is not really true as the recent ANX IPsec bake-off demonstrated. "SHOULD" is very important and things like auditing capability will weigh heavily in the minds of customers when they start to buy this stuff. > If the language is changed at all (which I don't believe is best), > I'd propose changing it to something like "IPsec implementations having > access to non-volatile storage MUST audit... and all other implementations > SHOULD audit...". This is even worse. NVRAM is a precious resource. I'm not saying that a cisco router cannot audit. There are ways it can satisfy this requirement but I just think the requirement is bull. I actually didn't think it was all that controversial either. Dan. From owner-ipsec Wed Apr 2 13:02:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA15030 for ipsec-outgoing; Wed, 2 Apr 1997 13:01:16 -0500 (EST) Date: Wed, 2 Apr 1997 13:03:48 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704021803.NAA23032@earth.hpc.org> To: marc@cygnus.com Cc: ipsec@tis.com In-reply-to: Yourmessage Subject: Re: MUST vs. SHOULD audit Sender: owner-ipsec@ex.tis.com Precedence: bulk > Some sites will want to know about every conceivable event. > Some sites will run high-profile services which will get probed so > often that logging such probes would be a waste of cheap disk space. I'm not familiar with state-of-the-art in audit, but I'd assumed that all auditing systems allowed administrator control over such things. Hilarie From owner-ipsec Wed Apr 2 13:05:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA15079 for ipsec-outgoing; Wed, 2 Apr 1997 13:04:19 -0500 (EST) Date: Wed, 2 Apr 97 17:50:09 GMT Daylight Time From: Ran Atkinson Subject: Re: auditing To: Derrell Piper , ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199704020037.QAA00806@fluffy.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk [co-chair hat off] --- On Tue, 01 Apr 1997 16:37:41 -0800 Derrell Piper wrote: > Auditing is obviously a host-system issue and outside of the scope of the > network protocol or IPSEC architecture document(s). I hear your opinion. This is not what the IPsec WG has concluded in the past. It is also not what other IETF WGs have concluded in the past. The requirement for implementing audit support is entirely consistent with past and current IETF standards-track specifications and practices. [co-chair hat on; a general comment not specific to Derrell] There is not a standards process issue with having an IETF specification require logging or auditing or such like. The group might decide to abandon auditing, but it would not be legitimate to claim a standards process violation as the rationale for doing so. [co-chair hat off] > However, there's > nothing wrong with pointing out where a host should perform auditing, if > it's capable of doing so. In this spirit, it would seem more appropriate > for the specs to read SHOULD instead of MUST. The current RFCs and drafts require that some form of auditing be implemented. They do not, however, specify any _particular_ form of auditing. One form might be syslog(), another might be SNMP, a third might be appending text strings to an ASCII file [the approach Windows95 takes with respect to PPP connections]. So the current requirement is quite minimal really and gives implementers LOTS of manuevering room to pick an implementation approach that is most sensible for their platforms. Hilarie is quite right that auditing is really an essential component. It needs to continue to be a mandatory-to-implement part of the specifications. One could argue that it would be useful to have a standards-track SNMP IPsec MIB for diagnostic and auditing information. If anyone wants to volunteer to write up such a MIB for this WG to consider, please send an email to me and Paul Lambert. I would suggest that things like the crypto keys be kept outside such an SNMP MIB because it would be unfortunate if a SNMP security breach caused an IPsec security breach. Regards, Ran rja@inet.org From owner-ipsec Wed Apr 2 13:07:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA15096 for ipsec-outgoing; Wed, 2 Apr 1997 13:05:50 -0500 (EST) Message-Id: <199704021811.KAA00372@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Ran Atkinson Cc: Bill Pabst , Hilarie Orman , ipsec@tis.com Subject: Re: MUST vs. SHOULD audit In-Reply-To: Your message of "Wed, 02 Apr 1997 17:33:59 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 02 Apr 1997 10:11:28 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran, > So there ought to be several ways that cisco can comply with the current > I-Ds without having to write gobs of new code. I'd suggest that other > router vendors can use similar methods for addressing the same issue. That there are ways to comply do not make the requirement valid. Is there a reason for this to be a MUST (please don't say that SHOULDs aren't implemented or that the old RFCs had this because the fact that we have these I-Ds renders that void)? We're getting away from the protocol specification and dealing with mandating how it is implemented. Bad, bad, bad. Dan. From owner-ipsec Wed Apr 2 14:12:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA15684 for ipsec-outgoing; Wed, 2 Apr 1997 14:09:50 -0500 (EST) To: ho@earth.hpc.org (Hilarie Orman) Cc: ipsec@tis.com Subject: Re: MUST vs. SHOULD audit References: <199704021803.NAA23032@earth.hpc.org> From: Marc Horowitz Date: 02 Apr 1997 14:13:50 -0500 In-Reply-To: ho@earth.hpc.org's message of Wed, 2 Apr 1997 13:03:48 -0500 Message-ID: Lines: 15 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-ipsec@ex.tis.com Precedence: bulk ho@earth.hpc.org (Hilarie Orman) writes: >> > Some sites will want to know about every conceivable event. >> > Some sites will run high-profile services which will get probed so >> > often that logging such probes would be a waste of cheap disk space. >> >> I'm not familiar with state-of-the-art in audit, but I'd assumed that all >> auditing systems allowed administrator control over such things. I assume most would, too. But what does "MUST log" mean? Must end up in the audit log? Must be given to the audit system as input? I think this is outside the scope of the IPsec protocol document, and should be discussed in a different document. Marc From owner-ipsec Wed Apr 2 14:21:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA15739 for ipsec-outgoing; Wed, 2 Apr 1997 14:20:22 -0500 (EST) Message-Id: <199704021925.OAA00299@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: Stephen Kent Cc: ipsec@tis.com Subject: Re: auditing Date: Wed, 02 Apr 1997 14:25:03 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk Hmm. Let's look at the text which started this thread.. > If no valid Security Association exists for this session (e.g., the > receiver has no key), the receiver MUST discard the packet and the > failure MUST be recorded in an audit log. This is pretty unambiguous, and goes pretty far. I read it as saying: a) you must have auditing. b) you must not be able to turn auditing off. ("the failure MUST be recorded in an audit log") Most of the responses I've seen so far in this thread appear to assume that (b) is not the case. I'd like to make a modest suggestion: change the text to: ... discard the packet. This failure MUST be auditable. and add some common text defining what "auditable" means. This document defines several events as being "auditable". At a minimum, "auditable" means that an implementation MUST provide a mechanism which securely records the fact that the event occurred one or more times in the recent past. Other relevant information about the event (time, source address, destination address, SPI, etc.,) SHOULD also be recorded. Auditing MUST be enabled by default, but it MUST be possible for an administrator to disable auditing. [This can easily be tweaked if the consensus is that the default should be to disable auditing unless explicitly requested.] --- One cautionary note on circular dependancies: We ran into some serious problems with circular dependancies when auditing was added to DCE security and was secured by DCE security; in particular, certain facilities within DCE security which were used by the audit system could also generate audit records. A number of people have suggested using various forms of networked auditing (RADIUS, syslog, etc.) to record events noticed by ipsec. If you're in a position where the communication with the audit server may be secured using ipsec, you need to be careful, lest you wind up in a recursive spiral of death when the SA with your audit server goes bad.. - Bill From owner-ipsec Wed Apr 2 15:38:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16321 for ipsec-outgoing; Wed, 2 Apr 1997 15:34:27 -0500 (EST) Date: Wed, 02 Apr 1997 14:34:40 -0500 From: "Freedman, Jerome" Subject: RE: MUST vs. SHOULD audit To: "'ipsec@tis.com'" Message-id: MIME-version: 1.0 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > > >> If the language is changed at all (which I don't believe is best), >>I'd propose changing it to something like "IPsec implementations having >>access to non-volatile storage MUST audit... and all other implementations >>SHOULD audit...". > >> Ran >> rja@inet.org > As an implementor for an embedded sytem would be happier with this change. A straight "MUST" is a bit strong. Jerry Freedman Jerome.Freedman@gsc.gte.co >m From owner-ipsec Wed Apr 2 15:47:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16449 for ipsec-outgoing; Wed, 2 Apr 1997 15:46:05 -0500 (EST) Message-Id: <2.2.32.19970402205305.014b03f8@fh.us.bosch.com> X-Sender: cwerner@fh.us.bosch.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 02 Apr 1997 15:53:05 -0500 To: ipsec@tis.com From: "Christopher L. Werner" Subject: Re: MUST vs. SHOULD audit Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:03 AM 4/2/97 -0800, Dan Harkins wrote: > Ran, [snip] > The suggestion that implementors don't do the "SHOULD implement" is not >really true as the recent ANX IPsec bake-off demonstrated. "SHOULD" is >very important and things like auditing capability will weigh heavily in >the minds of customers when they start to buy this stuff. > Actually there are a number of legal ramifications which are directly related to whether one has an audit trail or not. When things go wrong and law enforcement/lawyers are involved the evidence provided by a log file can be the difference between success and failure of litigation. This issue alone may have more influence on the 'market' decision to use products which log vs those which do not. Some businesses will rely on IPsec as their primary security mechanism and it's effectiveness will be very critical. [returning to listening mode...] ----------------------------------------------------------------------- Opinions expressed are mine and not necessarily those of my employer. ----------------------------------------------------------------------- Christopher L. Werner Robert Bosch Corporation System Engineer 38000 Hills Tech Dr. (810)553-1389 Farmington Hills, MI 48331-3417 From owner-ipsec Wed Apr 2 15:55:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16524 for ipsec-outgoing; Wed, 2 Apr 1997 15:53:44 -0500 (EST) Date: Wed, 2 Apr 1997 15:55:04 -0500 Message-Id: <9704022055.AA21260@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Ran Atkinson Cc: Derrell Piper , ipsec@tis.com In-Reply-To: Ran Atkinson's message of Wed, 2 Apr 97 17:50:09 GMT Daylight Time, Subject: Re: auditing Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk I have to agree with those who think that audit support should be a SHOULD, not a MUST, for the same reasons they cited; it's not protocol issue, it should be a host issue, there may be some host environments where logging isn't possible, etc. I have two other thoughts. What happens if the administrators decides not turn off auditing those types of events, or the other end of the SNMP trap receiver which the Cisco router has been forwarding the events is just ignoring all of the packets and sending the logs to /dev/null. Does the way the administrator configure a product make that product non-conformant with the RFC? Also, why is it so critical that we log packets with non-existent security associations? Is the security of IPSEC fundamentally compromised if system administrators don't review the logs daily looking for these events? I understand the desireability of influencing vendors to provide auditing capability for these sorts of events, but we're in pretty bad shape if the security of a protocol depends on someone poring over the audit logs! - Ted From owner-ipsec Wed Apr 2 16:22:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA16703 for ipsec-outgoing; Wed, 2 Apr 1997 16:20:55 -0500 (EST) Date: Wed, 2 Apr 97 21:18:49 GMT Daylight Time From: Ran Atkinson Subject: Re: MUST vs. SHOULD audit To: Daniel Harkins Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199704021803.KAA00360@dharkins-ss20> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, NVRAM was NOT one of the several proposals I made for router-originated auditing, if you read my notes in detail. I made several different proposals, NONE of which requires ANY non-volatile on-board storage within the router and several of which are already coded up inside IOS 11.x (hence NOT a lot of work for you or Cheryl Madson). Regards, Ran rja@inet.org From owner-ipsec Wed Apr 2 16:27:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA16746 for ipsec-outgoing; Wed, 2 Apr 1997 16:26:28 -0500 (EST) Date: Wed, 2 Apr 97 21:25:26 GMT Daylight Time From: Ran Atkinson Subject: Re: auditing To: Bill Sommerfeld , Stephen Kent Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199704021925.OAA00299@thunk.ch.apollo.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, RADIUS has its own security and does not rely on IPsec, hence there is no circular dependency. The question is a good one. Your proposed editorial changes seem reasonable to me. It is the ability to audit that is essential, whether the sys admin turns it off is a separable issue. Ran rja@inet.org From owner-ipsec Wed Apr 2 16:48:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA16823 for ipsec-outgoing; Wed, 2 Apr 1997 16:42:41 -0500 (EST) Message-Id: <199704022147.QAA00458@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: Ran Atkinson Cc: Stephen Kent , ipsec@tis.com Subject: Re: auditing In-Reply-To: rja's message of Wed, 02 Apr 1997 21:25:26 -0500. Date: Wed, 02 Apr 1997 16:47:55 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > RADIUS has its own security and does not rely on IPsec, hence there > is no circular dependency. Of course, this means that outbound (and inbound) logging traffic needs to be treated the same way as key management traffic, bypassing any ipsec policy engine which might trigger the creation or use of a security association... - Bill From owner-ipsec Wed Apr 2 16:51:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA16843 for ipsec-outgoing; Wed, 2 Apr 1997 16:46:37 -0500 (EST) Message-ID: <01BC3F6D.1B601C80@Tastid.cisco.com> From: adams@cisco.com (Rob Adams) To: rja@inet.org (Ran Atkinson), tytso@MIT.EDU ('Theodore Y. Ts'o') cc: piper@cisco.com (Derrell Piper), ipsec@tis.com (ipsec@tis.com) Subject: RE: auditing Date: Wed, 2 Apr 1997 13:45:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I agree with Ted. I also agree with Mark.. The BCP idea is a good one. I agree for all the various reasons listed. The security of the base protocol doesn't depend on it. There are places were implementing auditing is at best difficult and leaves implementations open to denial of service attacks. Etc. etc. Auditing is not a protocol issue. If we choose to make it a protocol issue, we MUST spell out the details a lot more clearly than saying compliant implementations have to audit this or that. If we aren't willing to do that, and I for one, am not willing, we SHOULD leave it as a SHOULD. The implementors of the target implementation and finally the market place will determine what MUST be done for auditing. -Rob ---------- From: Theodore Y. Ts'o[SMTP:tytso@MIT.EDU] Sent: Wednesday, April 02, 1997 12:55 PM To: Ran Atkinson Cc: Derrell Piper; ipsec@tis.com Subject: Re: auditing I have to agree with those who think that audit support should be a SHOULD, not a MUST, for the same reasons they cited; it's not protocol issue, it should be a host issue, there may be some host environments where logging isn't possible, etc. I have two other thoughts. What happens if the administrators decides not turn off auditing those types of events, or the other end of the SNMP trap receiver which the Cisco router has been forwarding the events is just ignoring all of the packets and sending the logs to /dev/null. Does the way the administrator configure a product make that product non-conformant with the RFC? Also, why is it so critical that we log packets with non-existent security associations? Is the security of IPSEC fundamentally compromised if system administrators don't review the logs daily looking for these events? I understand the desireability of influencing vendors to provide auditing capability for these sorts of events, but we're in pretty bad shape if the security of a protocol depends on someone poring over the audit logs! - Ted From owner-ipsec Wed Apr 2 17:23:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA17055 for ipsec-outgoing; Wed, 2 Apr 1997 17:20:20 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199704022225.OAA00456@kebe.eng.sun.com> Subject: Re: auditing To: sommerfeld@apollo.hp.com (Bill Sommerfeld) Date: Wed, 2 Apr 1997 14:25:35 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <199704022147.QAA00458@thunk.ch.apollo.hp.com> from "Bill Sommerfeld" at Apr 2, 97 04:47:55 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I have to say that after some further thought, if you HAVE logging facilities, you MUST audit. This, I guess, puts me in violent agreement with Bill. I keep having this sinking feeling that there might be some class of attack that can only get caught by auditing/logging. Anyone care to comment on this? And speaking of Bill, he mentions... > Of course, this means that outbound (and inbound) logging traffic > needs to be treated the same way as key management traffic, bypassing > any ipsec policy engine which might trigger the creation or use of a > security association... I'll insert a plug for draft-mcdonald-simple-ipsec-api-01.txt, which includes such a BYPASS setting for privileged applications. Dan From owner-ipsec Wed Apr 2 17:37:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA17145 for ipsec-outgoing; Wed, 2 Apr 1997 17:34:55 -0500 (EST) Date: Wed, 2 Apr 97 22:30:56 GMT Daylight Time From: Ran Atkinson Subject: Re: auditing To: Bill Sommerfeld , Ran Atkinson Cc: ipsec@tis.com, Stephen Kent X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199704022147.QAA00458@thunk.ch.apollo.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Wed, 02 Apr 1997 16:47:55 -0500 Bill Sommerfeld wrote: > > RADIUS has its own security and does not rely on IPsec, hence there > > is no circular dependency. > > Of course, this means that outbound (and inbound) logging traffic > needs to be treated the same way as key management traffic, bypassing > any ipsec policy engine which might trigger the creation or use of a > security association... > > - Bill OR it means that the IPsec Policy Engine knows to bypass RADIUS traffic around IPsec -- as part of the Policy Engine's knowledge of the IPsec policy for that system. Bypassing might be quite reasonable for RADIUS since RADIUS has its own built-in security. I suspect that there are in fact N applications where one doesn't want to apply IPsec on top of some other higher-layer security mechanism (SSH, SSL, and PEM, provide potential examples of this). Ran rja@inet.org From owner-ipsec Wed Apr 2 17:42:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA17159 for ipsec-outgoing; Wed, 2 Apr 1997 17:39:25 -0500 (EST) Date: Wed, 2 Apr 97 21:47:43 GMT Daylight Time From: Ran Atkinson Subject: Re: auditing To: Bill Sommerfeld , Stephen Kent Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199704021925.OAA00299@thunk.ch.apollo.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Wed, 02 Apr 1997 14:25:03 -0500 Bill Sommerfeld wrote: > I'd like to make a modest suggestion: > > change the text to: > > ... discard the packet. This failure MUST be auditable. > > and add some common text defining what "auditable" means. > > This document defines several events as being "auditable". > > At a minimum, "auditable" means that an implementation MUST > provide a mechanism which securely records the fact that the ^^^^^^^ Dan Harkins suggests replacing "records" with "reports", which would permit network-based reporting to be substituted for local storage if appropriate in some implementation. > event occurred one or more times in the recent past. Other > relevant information about the event (time, source address, > destination address, SPI, etc.,) SHOULD also be recorded. ^^^^^^^^ Similarly, the word "recorded" above should be changed to "reported". > Auditing MUST be enabled by default, but it MUST be possible > for an administrator to disable auditing. > [This can easily be tweaked if the consensus is that the default > should be to disable auditing unless explicitly requested.] I personally don't care about which is the default. I have also heard a private suggestion that maybe some of the auditing material might be moved into the "Security Considerations" section. That wouldn't bother me, though I will observe that verbage anywhere in the RFC is equally binding on implementations. Would this be a reasonable compromise position on this topic, given that there are some seemingly deep philosophical differences amongst various parties on the question of whether the IETF is permitted to say anything beyond what 'goes on the wire' ?? Ran rja@inet.org From owner-ipsec Wed Apr 2 18:11:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA17336 for ipsec-outgoing; Wed, 2 Apr 1997 18:07:35 -0500 (EST) Date: Wed, 2 Apr 97 23:05:05 GMT Daylight Time From: Ran Atkinson Subject: Apology To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199704022247.OAA00553@kebe.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk All, The note appended below was inappropriate and out of line in its personal tone. I wish to retract it. I apologise to Dan, Cheryl, and the list at large for my error. Ran rja@inet.org --- On Wed, 2 Apr 1997 14:47:01 -0800 (PST) Dan McDonald wrote: > Return-Path: > Dan, > > NVRAM was NOT one of the several proposals I made for router-originated > auditing, if you read my notes in detail. > > I made several different proposals, NONE of which requires ANY non-volatile > on-board storage within the router and several of which are already coded up > inside IOS 11.x (hence NOT a lot of work for you or Cheryl Madson). > > Regards, > > Ran > rja@inet.org > ---------------End of Original Message----------------- From owner-ipsec Thu Apr 3 08:21:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA17336 for ipsec-outgoing; Wed, 2 Apr 1997 18:07:35 -0500 (EST) Date: Wed, 2 Apr 97 23:05:05 GMT Daylight Time From: Ran Atkinson Subject: Apology To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199704022247.OAA00553@kebe.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk All, The note appended below was inappropriate and out of line in its personal tone. I wish to retract it. I apologise to Dan, Cheryl, and the list at large for my error. Ran rja@inet.org --- On Wed, 2 Apr 1997 14:47:01 -0800 (PST) Dan McDonald wrote: > Return-Path: > Dan, > > NVRAM was NOT one of the several proposals I made for router-originated > auditing, if you read my notes in detail. > > I made several different proposals, NONE of which requires ANY non-volatile > on-board storage within the router and several of which are already coded up > inside IOS 11.x (hence NOT a lot of work for you or Cheryl Madson). > > Regards, > > Ran > rja@inet.org > ---------------End of Original Message----------------- From owner-ipsec Thu Apr 3 08:33:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00463 for ipsec-outgoing; Thu, 3 Apr 1997 08:32:39 -0500 (EST) Message-ID: <61CDD2C9A961CF11B6A000805FD40AA902BD416F@RED-84-MSG.dns.microsoft.com> From: Glen Zorn To: Stephen Kent , Daniel Harkins Cc: ipsec@tis.com Subject: RE: MUST vs. SHOULD audit Date: Wed, 2 Apr 1997 19:07:35 -0800 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.8) Sender: owner-ipsec@ex.tis.com Precedence: bulk I think that auditing recommendations belong in the Security Considerations section. -----Original Message----- From: Stephen Kent [SMTP:kent@bbn.com] Sent: Tuesday, April 01, 1997 1:44 PM To: Daniel Harkins Cc: ipsec@tis.com Subject: Re: MUST vs. SHOULD audit Dan, I was worried about the MUSTs in both documents re auditing and potential denial of service implications, but chose to copy them and hope for feedback from the WG. I'd be comfortable with a spec that required logging if the platform already supported audit, but I'm up in the air re the right requirement if the platform does not perform audit. If marking this case as SHOULD would make folks happy, I'm certainly comfortable with that sort of change, though I'm not sure what the bottom line effect would be. Thanks for catching the "ICV" vs. "sequence number" check typo. Steve From owner-ipsec Thu Apr 3 08:37:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00621 for ipsec-outgoing; Thu, 3 Apr 1997 08:37:15 -0500 (EST) Message-ID: <01BC3F81.69FF4780@Tastid.cisco.com> From: adams@cisco.com (Rob Adams) To: sommerfeld@apollo.hp.com (Bill Sommerfeld), Dan.McDonald@Eng.sun.com ('Dan McDonald') cc: ipsec@tis.com (ipsec@tis.com) Subject: RE: auditing Date: Wed, 2 Apr 1997 16:17:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk >>I'll insert a plug for draft-mcdonald-simple-ipsec-api-01.txt, which includes >>such a BYPASS setting for privileged applications. Some platforms don't have the notion of privileged applications. ie. Windows 95. -Rob From owner-ipsec Thu Apr 3 08:37:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00633 for ipsec-outgoing; Thu, 3 Apr 1997 08:37:20 -0500 (EST) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199704030024.QAA01009@kebe.eng.sun.com> Subject: Re: auditing To: sommerfeld@apollo.hp.com (Bill Sommerfeld) Date: Wed, 2 Apr 1997 16:24:43 -0800 (PST) Cc: adams@cisco.com, Dan.McDonald@Eng.sun.com, ipsec@tis.com In-Reply-To: <199704030021.TAA00664@thunk.ch.apollo.hp.com> from "Bill Sommerfeld" at Apr 2, 97 07:21:27 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Some platforms don't have the notion of privileged > > applications. ie. Windows 95. Or MacOS for that matter. But Bill has beaten me to the punch when he says... > Actually, it was my impression that Win95 doesn't have a notion of > *un*priviledged applications. This is a subtle, but important, > distinction.. Yep. Win95/MacOS have all procs on the same playing field, for the most part, therefore you can't deny BYPASS to any app for that particular platform. Dan From owner-ipsec Thu Apr 3 08:37:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00641 for ipsec-outgoing; Thu, 3 Apr 1997 08:37:22 -0500 (EST) Message-ID: <01BC3F81.68C986A0@Tastid.cisco.com> From: adams@cisco.com (Rob Adams) To: dharkins@cisco.com (Daniel Harkins), rja@inet.org ('Ran Atkinson') cc: ipsec@tis.com (ipsec@tis.com) Subject: RE: MUST vs. SHOULD audit Date: Wed, 2 Apr 1997 16:14:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk >> (hence NOT a lot of work for you or Cheryl Madson). Okay... This doesn't have anything to do with this particular thread, BUT. Could people stop making judgements about how difficult it would be for other people to implement something??!?!? In reality, none of us know how difficult it is for someone to implement something. Simply because there are other things in IOS that already do something like this, doesn't mean that Cheryl or Dan can just use the prior art with no modification. It may be easy, then again, it may be nearly impossible. "Oh well, Windows 3.11 already has NETBUI, we can just shove the NRL code in there! No problem!!" Why don't we let them judge how hard it would be. Back to the thread... The ease of bolting the functionality into IOS is not relevant to the discussion. Should it be in the standard if it isn't appropriate in some instances? It certainly SHOULD NOT be in the standard because someone thinks it is easy to put the functionality in someone else's product. From owner-ipsec Thu Apr 3 08:37:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00634 for ipsec-outgoing; Thu, 3 Apr 1997 08:37:20 -0500 (EST) Message-Id: <199704030021.TAA00664@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: adams@cisco.com (Rob Adams) Cc: Dan.McDonald@Eng.sun.com ('Dan McDonald'), ipsec@tis.com (ipsec@tis.com) Subject: Re: auditing In-Reply-To: adams's message of Wed, 02 Apr 1997 16:17:35 -0800. <01BC3F81.69FF4780@Tastid.cisco.com> Date: Wed, 02 Apr 1997 19:21:27 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > >... a BYPASS setting for privileged applications. > > Some platforms don't have the notion of privileged > applications. ie. Windows 95. Actually, it was my impression that Win95 doesn't have a notion of *un*priviledged applications. This is a subtle, but important, distinction.. - Bill From owner-ipsec Thu Apr 3 08:37:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00655 for ipsec-outgoing; Thu, 3 Apr 1997 08:37:25 -0500 (EST) Message-Id: <199704030004.QAA00961@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Ran Atkinson Cc: Bill Sommerfeld , Stephen Kent , ipsec@tis.com Subject: Re: auditing In-Reply-To: Your message of "Wed, 02 Apr 1997 21:47:43 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 02 Apr 1997 16:04:35 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk On Wed, 02 Apr 1997 21:47:43 EST (Ran, set your TZ correctly!), Ran modified Bill Sommerfeld's suggestion: >> change the text to: >> >> ... discard the packet. This failure MUST be auditable. >> >> and add some common text defining what "auditable" means. >> >> This document defines several events as being "auditable". >> >> At a minimum, "auditable" means that an implementation MUST >> provide a mechanism which securely reports the fact that the >> event occurred one or more times in the recent past. Other >> relevant information about the event (time, source address, >> destination address, SPI, etc.,) SHOULD also be reports. >> >> Auditing MUST be enabled by default, but it MUST be possible >> for an administrator to disable auditing. > > I personally don't care about which is the default. > Would this be a reasonable compromise position on this topic, >given that there are some seemingly deep philosophical differences >amongst various parties on the question of whether the IETF is >permitted to say anything beyond what 'goes on the wire' ?? This sound reasonable to me. Thanks Bill for sensible suggestion. Let me add that my philisophical differences (which BTW have nothing to do with what the IETF is permitted to say) do not reflect cisco's position vis-a-vis auditing. cisco will provide tunable auditing capability regardless of the wording in these I-Ds. It is regrettable that I must remind some people of this: I do not speak for cisco, ever. Dan. From owner-ipsec Thu Apr 3 08:37:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00659 for ipsec-outgoing; Thu, 3 Apr 1997 08:37:28 -0500 (EST) Message-Id: <199704022344.SAA00612@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: Ran Atkinson Cc: Stephen Kent , ipsec@tis.com Subject: Re: auditing In-Reply-To: rja's message of Wed, 02 Apr 1997 21:47:43 -0500. Date: Wed, 02 Apr 1997 18:44:38 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > > At a minimum, "auditable" means that an implementation MUST > > provide a mechanism which securely records the fact that the > ^^^^^^^ > Dan Harkins suggests replacing "records" with "reports", > which would permit network-based reporting to be substituted > for local storage if appropriate in some implementation. I don't have a problem with this change to my amendment.. Note that as worded, a single counter per event (or perhaps a (counter,timestamp) pair) could conceivably be considered a minimal, but compliant, implementation of "auditing". I don't think this is an extreme burden, but it may be too minimalistic for some.. > I have also heard a private suggestion that maybe some of the > auditing material might be moved into the "Security Considerations" > section. That wouldn't bother me, though I will observe that verbage > anywhere in the RFC is equally binding on implementations. Hmm. I think that a statement that a given exceptional condition is an "auditable event" should be right next to the defintion of the exceptional condition. There could be a (redundant) complete list of auditable events in an appendix or in the security considerations section.. - Bill From owner-ipsec Thu Apr 3 09:11:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA01089 for ipsec-outgoing; Thu, 3 Apr 1997 09:10:05 -0500 (EST) From: Uri Blumenthal Message-Id: <9704031414.AA175163@hawpub.watson.ibm.com> Subject: Re: MUST vs. SHOULD audit To: rja@inet.org (Ran Atkinson) Date: Thu, 3 Apr 1997 09:14:03 -0500 (EST) Cc: ipsec@tis.com In-Reply-To: from "Ran Atkinson" at Apr 2, 97 05:18:56 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran Atkinson says: > As you note, auditing is an important property of an IPsec implementation It may be an important property of the IMPLEMENTATION, but why do people insist it should be STANDARDIZED?! You want it - implement it. Does it have to be exactly like mine? > [1] In the absence of SNMP security, an SNMP trap is not the best choice > for security-related logging, IMHO. I dislike this. It's absent in almost the same sense as IPSEC is absent. There were and are working models, some of them are deployed, the work is still going on. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Thu Apr 3 09:15:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA01192 for ipsec-outgoing; Thu, 3 Apr 1997 09:15:09 -0500 (EST) From: Uri Blumenthal Message-Id: <9704031420.AA175280@hawpub.watson.ibm.com> Subject: Re: auditing To: rja@inet.org (Ran Atkinson) Date: Thu, 3 Apr 1997 09:20:17 -0500 (EST) Cc: ipsec@tis.com In-Reply-To: from "Ran Atkinson" at Apr 2, 97 05:50:09 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran Atkinson says: > One could argue that it would be useful to have a standards-track SNMP > IPsec MIB for diagnostic and auditing information. If anyone wants to > volunteer to write up such a MIB for this WG to consider, please send > an email to me and Paul Lambert. OK, I volunteer. We'll talk about it in Memphis. > I would suggest that things like > the crypto keys be kept outside such an SNMP MIB because it would be > unfortunate if a SNMP security breach caused an IPsec security breach. I'm sorry but I have to disagree. 1. Without secure SNMP deployed, I find the wisdom of being manageable via non-secure SNMP questionble. 2. You either want IPSEC to be managed by SNMP or you don't. In the first case, several crypto-related variables will have to be not only "visible" but "modifiable"... That's life. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Thu Apr 3 09:43:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA01373 for ipsec-outgoing; Thu, 3 Apr 1997 09:42:25 -0500 (EST) Message-ID: From: Andrew Robison To: "'ipsec@tis.com'" Subject: RE: MUST vs. SHOULD audit Date: Thu, 3 Apr 1997 09:46:34 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Here's my two cents worth from five years writing and working with IT security criteria: MUST AUDIT - the implementation must always audit the event in question, the feature cannot be turned off ever. MUST BE ABLE TO AUDIT - the implementation must include the configurable ability, at the request of the administrator, to audit the event. SHOULD AUDIT - the implementation may include the ability to audit the event in question and some justification may be required to explain why any given implementation does not. There is no requirement that the feature if present be configurable or able to be turned off. SHOULD BE ABLE TO AUDIT - as per SHOULD AUDIT except that the administrator must be able to turn on and off the auditing. MIGHT AUDIT - the implementers of the standard thought that if you were implementing an audit facility then this was an event which they considered worth auditing. Any details as to whether auditing can be turned on or off are outside of this requirement. I think that either SHOULD AUDIT or MIGHT AUDIT are the only reasonable terms to use. MUST is out because it means that all implementations must have auditing which may not always make sense given for instance an unmanaged IPSEC proxy. SHOULD BE ABLE TO AUDIT is out because it implies that the audit must be configurable to at least the granularity >of on/off. From owner-ipsec Thu Apr 3 10:25:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01653 for ipsec-outgoing; Thu, 3 Apr 1997 10:24:46 -0500 (EST) Message-ID: From: Greg Carter To: "'Bill Sommerfeld'" , "'Stephen Kent'" , "'Ran Atkinson'" Cc: "'ipsec@tis.com'" Subject: RE: auditing - RADIUS Date: Thu, 3 Apr 1997 10:14:12 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ipsec@ex.tis.com Precedence: bulk >---------- >From: Ran Atkinson[SMTP:rja@inet.org] >Sent: Wednesday, April 02, 1997 4:25 PM >To: Bill Sommerfeld; Stephen Kent >Cc: ipsec@tis.com >Subject: Re: auditing > > >Bill, > > RADIUS has its own security and does not rely on IPsec, hence there >is no circular dependency. The question is a good one. Before anyone plans on using RADIUS, some things should be made clear: 1) All RADIUS communication is in the clear, with the only exception that user passwords (and the variations of them) are hidden. 2) The U in RADIUS is for USER. Good luck trying to get the RADIUS working group to add attributes to configure a router/NAS for auditing. It wont happen. You could argue for auditing on a per user basis, but is that what you want? and does that make sense? 3) RADIUS accounting is geared toward billable attributes. I don't know if you would get much support to add IPSec audit trails to the RADIUS account attributes. 4) RADIUS is shared secret based for all authentication between the RADIUS client and the RADIUS server. Wow, we just spent all this time implementing ISAKMP/Oakley with certificates, and now you want to tell your customers that in order to configure their router to do IPSec auditing that they'll have to configure a RADIUS server and manage shared secrets... (ok I could be biased) 5) The security of RADIUS is questionable when used in environments where proxying is necessary between RADIUS servers (i.e. roaming users). As long as all the RADIUS servers are run by the same organization things are fine. But as soon as it becomes necessary to proxy through a RADIUS server for which your organization has no control over things go down hill. A RADIUS server which proxies must decrypt the user password then re-encrypt it before sending it on to the RADIUS server which does the final authentication. This means that all passwords are exposed at the proxies. 6) If the user is setup to do CHAP authentication in RADIUS, there is NO authentication of the RADIUS client's request when received by the RADIUS server. This is due to the nature of how the shared secret is used in RADIUS. Basically when doing PAP the shared secret is used to encrypt the users password, proof that the RADIUS client holds the shared secret is shown when the RADIUS server decrypts the password correctly. When CHAP is done the CHAP response is not encrypted before being sent to the RADIUS server, therefore there is no proof that the RADIUS client is who they say they are since the shared secret is not used in the initial request. I'll admit that most of the security concerns wouldn't have much to do with auditing, but are you happy with recommending an IPSec solution based on a protocol with these characteristics (if you were successful at getting the RADIUS wg to add the necessary attributes)? As for the circular reference, if I was running a RADIUS environment with IPSec capable equipment I think the first thing I would do was configure IPSec between the clients and the server so I could at least get protection of the ids and possible authentication (if not proxying) when CHAP is in use (which I understand to be the majority). Bye ---- Greg Carter Entrust Technologies carterg@entrust.com > > From owner-ipsec Thu Apr 3 12:57:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA02694 for ipsec-outgoing; Thu, 3 Apr 1997 12:56:20 -0500 (EST) Message-Id: <199704031800.KAA12965@mailsun3-fddi.us.oracle.com> Date: 03 Apr 97 09:55:34 -0800 From: "PALAMBER.US.ORACLE.COM" To: ipsec@tis.com Subject: IPSEC Agenda - Preliminary Cc: PALAMBER@us.oracle.com MIME-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.4.0.25) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Sender: owner-ipsec@ex.tis.com Precedence: bulk If you have not sent me a note with "IPSEC Agenda" in the subject line you are not on next weeks agenda. Last minute requests will be accepted. A very drafty agenda showing requested slots is attached below. Note order and times are preliminary and will change. Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Wednesday, April 9 at 0900-1115 Introduction 10 Grand Unified AH and ESP Specifications Nina Yuan 15 ISAKMP+Oakley draft, comments,requests, and burning issues Daniel Harkins 5 Issues for Closure Naganand Doraswamy 5 Cryptographic Aspects of the ISAKMP/Oakley Ran Canetti 10 New AH-HMAC transform drafts Robert Glenn Summary and Action Items ---------------- Thursday, April 10 at 1300-1500 IPSEC Implementation Survey Rodney Thayer Testing Results Robert Moskowitz Addressing/routing Issues Robert Moskowitz 10 "Test Cases for HMAC-MD5 and HMAC-SHA-1" Pau-Chen Cheng Summary and Action Items From owner-ipsec Thu Apr 3 13:42:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA03003 for ipsec-outgoing; Thu, 3 Apr 1997 13:41:44 -0500 (EST) Message-ID: <01BC401C.6C9FB880@Tastid.cisco.com> From: adams@cisco.com (Rob Adams) To: ipsec@tis.com ('ipsec@tis.com') Subject: comments on draft-ietf-new-auth-00 Date: Thu, 3 Apr 1997 10:47:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I read this again and had a few comments, but the major comment is.. wow.. good job! Thanks Steve, Ran and all other contributors... This makes a lot of things explicit and clear... My comments are mostly nits.. I'm an engineer, what do you want? Section 1: >> AH may be applied in combination with the IP Encapsulating >> Security Payload (ESP) [KA97b] I think I'm stupid. I don't really get the usefulness of this combination anymore other than it signs the IP header of an ESP'd packet. Is it really necessary to do this? And is there a situation where this would foil a realistic attack? I'm probably just being dumb, nothing new, but I'm at a loss. This made loads of sense before combined ESP transforms, but does it anymore? Section 2.2: Remove the null algorithm reference. I think this is only useful for debugging and probably doesn't belong in this document. Section 3.2.2: >> the transmitter increments the sequence number Earlier you said that the sequence starts at one, and here you say increment it first implying that the first on the wire is 2. Okay, Okay, I know this is a ridiculous comment and everyone knows what is meant, but I've actually had conversations with implementers where this particular point has caused confusion. Section 3.2.3.1.1: Offset and Flags. We actually had an interesting conversation about this at the anx bakeoff. Re-assembly is to take place underneath you but you can't be assured that the flags will be the same at the receiver as they are at the sender. You may not do MTU discovery on your host, but a gateway may. It could set the DF bit before forwarding. At the other end, the DF bit may still be set. In this case, fragmentation/reassembly may not even happen, but the bit will still be set in transit. Section 3.3.2: >>There is no requirement for the receiver to transmit any message >>to the purported transmitter in response I'd like to see a "MAY send an administratively prohibited ICMP" here... This could be very useful to some implementations, and probably ought to be a matter of policy. Say for example, in my LAN, I want this message so I can solve problems quickly, outside my LAN, let them stew... Not necessary, just an idea. Section 3.3.3: Could we update the example algorithm in the Hughes draft to do the window test/update in two separate operations? Now it does it in one, and the recommended path here is to test, authenticate then set. Any example algorithms published should fit the recommendation. That's it. Like I said.. mostly silly.. Again thanks to Steve, Ran and all who contributed, this feels like a real step forward. -Rob From owner-ipsec Thu Apr 3 14:13:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA03192 for ipsec-outgoing; Thu, 3 Apr 1997 14:13:04 -0500 (EST) Message-ID: <01BC4020.D79923C0@Tastid.cisco.com> From: adams@cisco.com (Rob Adams) To: ipsec@tis.com ('ipsec@tis.com') Subject: comments on draft-ietf-ipsec-new-esp-00 Date: Thu, 3 Apr 1997 11:18:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk %) good one.. Here we go again.. Section 2.3: The draft should probably state that the IV should always be a multiple of 32 bits. Or require multiples of 64 for IPv6. Section 2.4: To solve the alignment problem, could we always simply require the replay field. Don't use it if you don't have AH but leave it there with random trash otherwise to preserve alignment. I don't believe I'm saying this... %) -Rob From owner-ipsec Thu Apr 3 14:15:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA03209 for ipsec-outgoing; Thu, 3 Apr 1997 14:15:34 -0500 (EST) From: svakil@usr.com Mime-Version: 1.0 Date: Thu, 3 Apr 1997 13:15:45 -0600 Message-ID: <34401680.3000@usr.com> Cc: ipsec@tis.com Subject: Re[2]: auditing - ISAKMP Content-Type: multipart/mixed; boundary="IMA.Boundary.428490068" Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.428490068 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part >From section 5 of the ISAKMP draft: This section suggests the logging of events to a system au- dit file. This action is controlled by a system security policy and is, therefore, only a suggested action. Why is it that some IPSec protocols make auditing mandatory, whereas others make it optional? Shouldn't this be uniform for all IPSec protocols? Sumit A. Vakil Software Engineer, Routing Consulting Engineering US Robotics, Access Corp. --IMA.Boundary.428490068 Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Disposition: attachment; filename="RFC822 message headers" Received: from usr.com (mail.usr.com) by robogate2.usr.com with SMTP (IMA Internet Exchange 2.02 Enterprise) id 343EE530; Thu, 3 Apr 97 11:52:19 -0600 Received: from portal.ex.tis.com by usr.com (8.7.5/3.1.090690-US Robotics) id LAA05723; Thu, 3 Apr 1997 11:54:17 -0600 (CST) Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA17159 for ipsec-outgoing; Wed, 2 Apr 1997 17:39:25 -0500 (EST) Date: Wed, 2 Apr 97 21:47:43 GMT Daylight Time From: Ran Atkinson Subject: Re: auditing To: Bill Sommerfeld , Stephen Kent Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199704021925.OAA00299@thunk.ch.apollo.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.428490068-- From owner-ipsec Thu Apr 3 16:59:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA04408 for ipsec-outgoing; Thu, 3 Apr 1997 16:56:43 -0500 (EST) Message-ID: <61CDD2C9A961CF11B6A000805FD40AA902BD417A@RED-84-MSG.dns.microsoft.com> From: Glen Zorn To: Bill Sommerfeld , Ran Atkinson Cc: Stephen Kent , ipsec@tis.com Subject: RE: auditing Date: Thu, 3 Apr 1997 10:25:29 -0800 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.8) Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill Sommerfeld [sommerfeld@apollo.hp.com] writes: > > At a minimum, "auditable" means that an implementation MUST > > provide a mechanism which securely records the fact that the > ^^^^^^^ > Dan Harkins suggests replacing "records" with "reports", > which would permit network-based reporting to be substituted * for local storage if appropriate in some implementation. I would second this suggestion. I am concerned with the word "securely" in the above, however. For example, neither of the popular suggestions I've heard for auditing (syslog, RADIUS) qualify as being particularly secure in my mind. I would be much more comfortable if we eithe a) removed or b) more closely defined the word "securely". Must the audit messages (if sent on the net) be tamper-proof? Encrypted? I don't have a problem with this change to my amendment.. Note that as worded, a single counter per event (or perhaps a (counter,timestamp) pair) could conceivably be considered a minimal, but compliant, implementation of "auditing". I don't think this is an extreme burden, but it may be too minimalistic for some.. > I have also heard a private suggestion that maybe some of the > auditing material might be moved into the "Security Considerations" > section. That wouldn't bother me, though I will observe that verbage > anywhere in the RFC is equally binding on implementations. Hmm. I think that a statement that a given exceptional condition is an "auditable event" should be right next to the defintion of the exceptional condition. There could be a (redundant) complete list of auditable events in an appendix or in the security considerations section.. - Bill From owner-ipsec Thu Apr 3 17:52:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA04787 for ipsec-outgoing; Thu, 3 Apr 1997 17:50:48 -0500 (EST) Message-ID: <61CDD2C9A961CF11B6A000805FD40AA902BD4180@RED-84-MSG.dns.microsoft.com> From: Glen Zorn To: Ran Atkinson , Bill Sommerfeld Cc: ipsec@tis.com, Stephen Kent Subject: RE: auditing Date: Thu, 3 Apr 1997 11:19:01 -0800 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.8) Sender: owner-ipsec@ex.tis.com Precedence: bulk Before we go too far down this "RADIUS for auditing" path, please note that 1. RADIUS is _not_ designed to carry this kind of information 2. RADIUS accounting provides only weak client authentication; RADIUS itself provides _no_ client authentication except that provided by checking the client IP address 3. RADIUS Accounting _only_ sends messages at the beginning and end of sessions (although this is under discussion) 4. RADIUS Accounting is not (according to Mike O'Dell, never will be) an IETF standard protocol 5. RADIUS does not scale due to its shared-secret form of security and there are no plans to incorporate either stronger or more scalable forms of encryption. In fact, RADIUS over IPSEC has been discussed at length recently on the RoamOps list as a possible means of solving this scalability problem 6. There is no provision in RADIUS for any data encryption Basically, this is _not_ a good idea (IMHO). As illustration (though anecdotal) of this: I was prohibited (by a non-competition agreement) from doing any security work from 1/96-1/97. My former employer was serious about enforcing this agreement, to the point of sending me a registered lawyer letter just because I published an Internet-Draft the title of which contained the word "authentication". In this period of time, I developed (with the blessing of said employer) two RADIUS servers. Tell you anything? -----Original Message----- From: Ran Atkinson [SMTP:rja@inet.org] Sent: Wednesday, April 02, 1997 2:31 PM To: Bill Sommerfeld; Ran Atkinson Cc: ipsec@tis.com; Stephen Kent Subject: Re: auditing --- On Wed, 02 Apr 1997 16:47:55 -0500 Bill Sommerfeld wrote: > > RADIUS has its own security and does not rely on IPsec, hence there > > is no circular dependency. > > Of course, this means that outbound (and inbound) logging traffic > needs to be treated the same way as key management traffic, bypassing > any ipsec policy engine which might trigger the creation or use of a > security association... > > - Bill OR it means that the IPsec Policy Engine knows to bypass RADIUS traffic around IPsec -- as part of the Policy Engine's knowledge of the IPsec policy for that system. Bypassing might be quite reasonable for RADIUS since RADIUS has its own built-in security. I suspect that there are in fact N applications where one doesn't want to apply IPsec on top of some other higher-layer security mechanism (SSH, SSL, and PEM, provide potential examples of this). Ran rja@inet.org From owner-ipsec Thu Apr 3 18:12:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA04933 for ipsec-outgoing; Thu, 3 Apr 1997 18:11:52 -0500 (EST) Message-Id: <199704032316.SAA00991@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: Glen Zorn Cc: Ran Atkinson , ipsec@tis.com, Stephen Kent Subject: Re: auditing In-Reply-To: glennz's message of Thu, 03 Apr 1997 11:19:01 -0800. <61CDD2C9A961CF11B6A000805FD40AA902BD4180@RED-84-MSG.dns.microsoft.com> Date: Thu, 03 Apr 1997 18:16:15 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk Thanks for the information about RADIUS; it sounds like that rules it out as a possible way to implement ipsec auditing.... - Bill From owner-ipsec Thu Apr 3 22:39:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA06774 for ipsec-outgoing; Thu, 3 Apr 1997 22:38:05 -0500 (EST) Message-ID: <61CDD2C9A961CF11B6A000805FD40AA9033E9E48@RED-84-MSG.dns.microsoft.com> From: Glen Zorn To: Bill Sommerfeld Cc: Ran Atkinson , ipsec@tis.com, Stephen Kent Subject: RE: auditing Date: Thu, 3 Apr 1997 19:26:51 -0800 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.8) Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill Sommerfeld [sommerfeld@apollo.hp.com] writes: Thanks for the information about RADIUS; it sounds like that rules it out as a possible way to implement ipsec auditing.... I'd say so - almost anything (Kerberized syslog, anyone?) would be more appropriate, I think. - Bill From owner-ipsec Fri Apr 4 11:51:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA11486 for ipsec-outgoing; Fri, 4 Apr 1997 11:43:15 -0500 (EST) Date: Fri, 4 Apr 1997 11:48:15 -0500 From: Norman Shulman X-Sender: norm@rafael.rnd.border.com To: ipsec@tis.com Subject: Manual keying and replay prevention Message-Id: <97Apr4.115005est.11649@elgreco.rnd.border.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk The new auth and esp drafts contain the following identical wording: 4. Conformance Requirements Note that support for manual key distribution is required, but its use is inconsistent with the anti-replay service, and thus a compliant implementation must not negotiate this service in conjunction with SAs that are manually keyed. Why not? Thanks. Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@border.com Fax 1 416 813 2001 From owner-ipsec Fri Apr 4 14:37:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA12695 for ipsec-outgoing; Fri, 4 Apr 1997 14:36:49 -0500 (EST) Message-Id: <3.0.1.32.19970404143729.006e7d80@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Fri, 04 Apr 1997 14:37:29 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: Manual keying and replay prevention and ISAKMP negotiation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Does it make sense to talk about automatic negotiation of manual keying? The DOI has parameters for the manual case. Are people expecting that an ISAKMP implementation would potentially somehow decided to negotiate manual keying? Isn't the DOI only relevant to the ISAKMP (i.e. automatic key negotiation) schemes? >Date: Fri, 4 Apr 1997 11:48:15 -0500 >From: Norman Shulman >X-Sender: norm@rafael.rnd.border.com >To: ipsec@tis.com >Subject: Manual keying and replay prevention >Sender: owner-ipsec@ex.tis.com > >The new auth and esp drafts contain the following identical wording: > >4. Conformance Requirements > > Note that support for > manual key distribution is required, but its use is inconsistent with > the anti-replay service, and thus a compliant implementation must not > negotiate this service in conjunction with SAs that are manually > keyed. > >Why not? > >Thanks. > >Norm > > Norman Shulman Secure Computing Canada > Systems Developer Tel 1 416 813 2075 > norm@border.com Fax 1 416 813 2001 > > > -------- Rodney Thayer PGP: BB1B6428 409129AC 076B9DE1 4C250DD8 From owner-ipsec Fri Apr 4 15:05:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA12976 for ipsec-outgoing; Fri, 4 Apr 1997 15:05:06 -0500 (EST) Date: Fri, 4 Apr 1997 15:06:56 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704042006.PAA21375@earth.hpc.org> To: rodney@sabletech.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199704041955.MAA09374@baskerville.CS.Arizona.EDU> Subject: Re: Manual keying and replay prevention and ISAKMP negotiation Sender: owner-ipsec@ex.tis.com Precedence: bulk There are two types of manual keying. The AH and ESP implementations must be able to work in the absence of any keying protocols at all. That's why the drafts mention manual keying: it's all you can count on without a key exchange protocol. The ISAKMP/Oakley manual keying is for a different case. If one party has a key generated by a method that he is especially fond of (e.g. hardware), he can securely transmit it to another party and assign it to an SA. Hilarie From owner-ipsec Fri Apr 4 15:18:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13048 for ipsec-outgoing; Fri, 4 Apr 1997 15:18:17 -0500 (EST) Message-Id: <199704042023.PAA01450@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: Norman Shulman Cc: ipsec@tis.com Subject: Re: Manual keying and replay prevention In-Reply-To: norm's message of Fri, 04 Apr 1997 11:48:15 -0500. <97Apr4.115005est.11649@elgreco.rnd.border.com> Date: Fri, 04 Apr 1997 15:23:11 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > Note that support for manual key distribution is required, but > its use is inconsistent with the anti-replay service, and thus a > compliant implementation must not negotiate this service in > conjunction with SAs that are manually keyed. > > Why not? The wording seems convoluted; as my impression was that manual keying implies that no negotiation takes place. I think the issue with manual keying and replay is recovery from a reboot.. unless you store the receive-side replay state in stable storage as each packet is processed, you can't allow the SA to survive a crash without running the risk that you'll accept a replayed packet. (On the send side, you could checkpoint every N packets, and waste up to N packets of sequence space on a reboot. if you tried a similar hack on the receive side, you'd wind up needing to *ignore* up to N incoming in-sequence un-replayed packets..) Also, there's the issue of what to do when the replay counter maxes out.. - Bill From owner-ipsec Fri Apr 4 15:22:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13112 for ipsec-outgoing; Fri, 4 Apr 1997 15:22:20 -0500 (EST) Message-Id: <3.0.1.32.19970404152508.009d1e20@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 04 Apr 1997 15:25:08 -0500 To: Ran Atkinson , Bill Pabst , Hilarie Orman From: Robert Moskowitz Subject: Re: MUST vs. SHOULD audit Cc: dharkins@cisco.com, ipsec@tis.com In-Reply-To: References: <3341A51E.4EFC@htc.sj.nec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 05:33 PM 4/2/97 Time, Ran Atkinson wrote: > >--- On Tue, 01 Apr 1997 16:15:26 -0800 Bill Pabst wrote: > >> Would this be something that could be enabled/disabled through a Radius >> Server with its audit and accounting capibilities? >> > >A fine idea. RADIUS has some transmission security built-in, hence >might be a better choice than an insecure SNMP Trap. cisco routers support >RADIUS Accounting as of (at least) IOS 11.2, as I've been learning lately. > There are many implementations that will have nothing to do with Radius. Particularly UNIX and MS OS implementations. Of course these systems have their own way to log audit information. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Fri Apr 4 15:24:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13127 for ipsec-outgoing; Fri, 4 Apr 1997 15:23:50 -0500 (EST) Message-Id: <199704042023.PAA13127@portal.ex.tis.com> From: rob.glenn@nist.gov (Rob Glenn) To: norm@border.com Subject: Re: Manual keying and replay prevention Cc: ipsec@tis.com Date: Fri, 04 Apr 1997 20:30:03 GMT Sender: owner-ipsec@ex.tis.com Precedence: bulk I would guess that it would be difficult to "re-key" before the sequence number would wrap without having a KMP. In our own implementation (NIST), we're simply going to add a SA-Delete before the SN wraps in the case of manual key management. In this case, the manual key management system is no longer "completely" manual. Rob G. >The new auth and esp drafts contain the following identical wording: > >4. Conformance Requirements > > Note that support for > manual key distribution is required, but its use is inconsistent with > the anti-replay service, and thus a compliant implementation must not > negotiate this service in conjunction with SAs that are manually > keyed. > >Why not? > >Thanks. > >Norm > > Norman Shulman Secure Computing Canada > Systems Developer Tel 1 416 813 2075 > norm@border.com Fax 1 416 813 2001 > From owner-ipsec Fri Apr 4 15:35:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13211 for ipsec-outgoing; Fri, 4 Apr 1997 15:35:29 -0500 (EST) Date: Fri, 4 Apr 1997 15:40:44 -0500 From: Norman Shulman X-Sender: norm@rafael.rnd.border.com To: Bill Sommerfeld cc: ipsec@tis.com Subject: Re: Manual keying and replay prevention In-Reply-To: <199704042023.PAA01450@thunk.ch.apollo.hp.com> Message-Id: <97Apr4.154235est.11649@elgreco.rnd.border.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Fri, 4 Apr 1997, Bill Sommerfeld wrote: > > Note that support for manual key distribution is required, but > > its use is inconsistent with the anti-replay service, and thus a > > compliant implementation must not negotiate this service in > > conjunction with SAs that are manually keyed. > > > > Why not? > > The wording seems convoluted; as my impression was that manual keying > implies that no negotiation takes place. I assumed the negotiation takes place out of band (over the phone). > I think the issue with manual keying and replay is recovery from a > reboot.. unless you store the receive-side replay state in stable > storage as each packet is processed, you can't allow the SA to survive > a crash without running the risk that you'll accept a replayed packet. This issue is no different from the case of a stream cipher like RC4. You have to rekey after rebooting. > (On the send side, you could checkpoint every N packets, and waste up > to N packets of sequence space on a reboot. if you tried a similar > hack on the receive side, you'd wind up needing to *ignore* up to N > incoming in-sequence un-replayed packets..) > > Also, there's the issue of what to do when the replay counter maxes > out.. Again as in the case of a stream cipher, the connection breaks and must be rekeyed. Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@border.com Fax 1 416 813 2001 From owner-ipsec Fri Apr 4 15:42:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13227 for ipsec-outgoing; Fri, 4 Apr 1997 15:40:33 -0500 (EST) Date: Fri, 4 Apr 1997 15:46:04 -0500 From: Norman Shulman X-Sender: norm@rafael.rnd.border.com To: Rob Glenn cc: ipsec@tis.com Subject: Re: Manual keying and replay prevention In-Reply-To: <199704042027.PAA19919@snad.ncsl.nist.gov> Message-Id: <97Apr4.154755est.11649@elgreco.rnd.border.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Fri, 4 Apr 1997, Rob Glenn wrote: > I would guess that it would be difficult to "re-key" before the sequence > number would wrap without having a KMP. In our own implementation (NIST), > we're simply going to add a SA-Delete before the SN wraps in the case > of manual key management. In this case, the manual key management system > is no longer "completely" manual. Semi-automatic sounds good to me. Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@border.com Fax 1 416 813 2001 From owner-ipsec Fri Apr 4 15:57:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13404 for ipsec-outgoing; Fri, 4 Apr 1997 15:56:45 -0500 (EST) Date: Fri, 4 Apr 1997 15:59:33 -0500 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704042059.PAA23010@earth.hpc.org> To: rob.glenn@nist.gov Cc: ipsec@tis.com In-reply-to: Yourmessage <199704042038.NAA13597@baskerville.CS.Arizona.EDU> Subject: Re: Manual keying and replay prevention Sender: owner-ipsec@ex.tis.com Precedence: bulk > we're simply going to add a SA-Delete before the SN wraps > Semi-automatic sounds good to me. And after removing the bullet from your foot, what do you plan to do? :-) Seriously, this is a case where the inline-hashed-key idea makes sense. It's a simple way to continue operating when security is less-than-perfect but no good alternative is available. Of course, you'd be forced at gunpoint to log the event ... Hilarie From owner-ipsec Fri Apr 4 15:59:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13436 for ipsec-outgoing; Fri, 4 Apr 1997 15:59:18 -0500 (EST) Message-Id: <199704042104.NAA03097@fluffy.cisco.com> To: rodney@sabletech.com (Rodney Thayer) cc: ipsec@tis.com Subject: Re: Manual keying and replay prevention and ISAKMP negotiation In-reply-to: Your message of "Fri, 04 Apr 1997 14:37:29 EST." <3.0.1.32.19970404143729.006e7d80@pop3.pn.com> Date: Fri, 04 Apr 1997 13:04:05 -0800 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney, The specific provision in the IPSEC DOI is for a manual key exchange algorithm, separate from Oakley. I actually feel that the manual keying requirement should be removed from the base architecture documents. Our security architecture should not mandate something that doesn't scale and is insecure. The ISAKMP/Oakley resolution document describes how to use "pre-shared" keys (i.e. passwords) to authenticate the Diffie-Hellman exchange, which provides the necessary attribute of manual authentication without digital certificates. I believe it's essential that ephemeral session keys be used for IPSEC, regardless of the associated authentication method. Derrell From owner-ipsec Fri Apr 4 16:13:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA13580 for ipsec-outgoing; Fri, 4 Apr 1997 16:13:27 -0500 (EST) Message-Id: <3.0.1.32.19970404161127.006e7134@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Fri, 04 Apr 1997 16:11:27 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: Re: Manual keying and replay prevention and ISAKMP negotiation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk In this case may I suggest we call it "externally generated keys" rather than manual keys. I believe this case, where there is some sort of external mechanism (i.e. hardware, etc.) generating the keys is compatible with Cisco's views, as opposed to (old style humans-type-them-in) manual keying. >Date: Fri, 4 Apr 1997 15:06:56 -0500 >From: ho@earth.hpc.org (Hilarie Orman) >To: rodney@sabletech.com >Cc: ipsec@tis.com >Subject: Re: Manual keying and replay prevention and ISAKMP negotiation >Sender: owner-ipsec@ex.tis.com > >There are two types of manual keying. The AH and ESP implementations must >be able to work in the absence of any keying protocols at all. That's >why the drafts mention manual keying: it's all you can count on without >a key exchange protocol. > >The ISAKMP/Oakley manual keying is for a different case. If one party >has a key generated by a method that he is especially fond of >(e.g. hardware), he can securely transmit it to another party and >assign it to an SA. > >Hilarie > > > From owner-ipsec Fri Apr 4 18:49:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA14161 for ipsec-outgoing; Fri, 4 Apr 1997 18:38:52 -0500 (EST) Message-Id: <1.5.4.16.19970404223038.423fdf8a@world.std.com> X-Sender: dpj@world.std.com X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 04 Apr 1997 17:30:38 -0500 To: Derrell Piper From: "David P. Jablon" Subject: Re: Manual keying and replay prevention and ISAKMP negotiation Cc: ipsec@tis.com, rodney@sabletech.com (Rodney Thayer) Sender: owner-ipsec@ex.tis.com Precedence: bulk Derrell, I think you are wrong in suggesting that the ISAKMP/Oakley draft encourage the "pre-shared secrets" to be based on passwords. The word "password" is carefully (I suppose) omitted in the draft, and for good reason: Use of a too-small password exposes their protocol to dictionary attack. It *is* possible to do a password-authenticated DH exchange, immune to network dictionary attack. (e.g. SPEKE or DH-EKE) Such exchanges could be very convenient for secure re-connections, based on a temporary memorizable secret -- but these are not specified in Oakley. Forgive me if you think this is a nit, but I think wanton use of passwords as keys is a *bad thing*, especially in light of truly appropriate password alternatives. -- David At 01:04 PM 4/4/97 -0800, you wrote (to Rodney): > The specific provision in the IPSEC DOI is for a manual key exchange > algorithm, separate from Oakley. > ... > The ISAKMP/Oakley resolution document describes how to use "pre-shared" > keys (i.e. passwords) to authenticate the Diffie-Hellman exchange, which > provides the necessary attribute of manual authentication without digital > certificates. ------------------------------------ David Jablon Tel: +1 508 898 9024 http://world.std.com/~dpj/ E-mail: dpj@world.std.com From owner-ipsec Fri Apr 4 22:00:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA15099 for ipsec-outgoing; Fri, 4 Apr 1997 21:59:09 -0500 (EST) Message-Id: <199704050304.TAA02427@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Rodney Thayer Cc: ipsec@tis.com Subject: Re: Manual keying and replay prevention and ISAKMP negotiation In-Reply-To: Your message of "Fri, 04 Apr 1997 16:11:27 EST." <3.0.1.32.19970404161127.006e7134@pop3.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 04 Apr 1997 19:04:19 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > In this case may I suggest we call it "externally generated keys" rather > than manual keys. I believe this case, where there is some sort of > external mechanism (i.e. hardware, etc.) generating the keys is compatible > with Cisco's views, as opposed to (old style humans-type-them-in) manual > keying. cisco's views? I don't think that cisco has a view on what manual keying is. (Or if it does I haven't been let in on it). Lots of us have opinions but they don't necessarily have any relation to our employer's. Dan (speaking only for myself-- still). From owner-ipsec Sat Apr 5 02:46:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA16254 for ipsec-outgoing; Sat, 5 Apr 1997 02:45:24 -0500 (EST) Message-Id: <199704050749.XAA21207@mailsun3-fddi.us.oracle.com> Date: 04 Apr 97 17:01:29 -0800 From: "PALAMBER.US.ORACLE.COM" To: ipsec@tis.com Subject: Memphis IPSEC Cc: PALAMBER@us.oracle.com MIME-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.5.1.55) 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 CAA16251 Sender: owner-ipsec@ex.tis.com Precedence: bulk WEDNESDAY, April 9, 1997 0900-1115 Memphis C SEC ipsec IP Security Protocol WG ipsec I-Ds THURSDAY, April 10, 1997 0900-1130 Continental SEC ipsec IP Security Protocol WG Interoperability Discussions Paul From owner-ipsec Sat Apr 5 08:29:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA17450 for ipsec-outgoing; Sat, 5 Apr 1997 08:26:32 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <97Apr4.115005est.11649@elgreco.rnd.border.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 5 Apr 1997 04:27:24 -0500 To: Norman Shulman From: Stephen Kent Subject: Re: Manual keying and replay prevention Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Norm, I inserted the cited note re manually positioned keys was because I assumed that these keys would not be changed frequently (to assume otherwise would facilitate a management vulnerability) and because I assumed that saving state for the anti-replay sequence number would be problematic (across crashes, etc.). Under these assumptions, counter cycling becomes a problem. It does not seem to be realistic to assume that a manually positioned key would be changed in a timely fashion as the counter neared 2**32-1. These are conservative assumptions, but this is a security protocol, so such assumptions are not necessarily out of line. Later e-mail from others attempts to clarify the use of the phrase "manual keying," but I based this text on the prevous IPsec RFCs, where the intent (Ran can confirm this) was to refer to symmetric keys. Steve From owner-ipsec Sat Apr 5 08:29:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA17456 for ipsec-outgoing; Sat, 5 Apr 1997 08:27:02 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <9704012220.AA31931@hawpub.watson.ibm.com> References: <199704012145.NAA28713@dharkins-ss20> from "Daniel Harkins" at Apr 1, 97 01:45:42 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 5 Apr 1997 07:54:54 -0500 To: uri@watson.ibm.com From: Stephen Kent Subject: Re: MUST vs. SHOULD audit Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Uri, IPsec defines a protocol, and a protocol definition inlcludes the processing that takes place at the sender and receiver in response to the transmission and reception of packets, not just the format of the packet bits on the wire. On that basis, I'd argue that auditing is within the scope of the IPsec specs, especially since auditing is a security function and IPsec defines security protocols. I do agree with later contributors to this discussion, that we need to distinguish between "audited" and "auditable." Certainly we do not want to require that events be audited; that is a local policy matter. Thus, at a minimum, we need to chnage the wording to indicate that what is required (or recommended) is that an implementation allow a local security administrator to elect auditing for the specified events. I suspect that was Ran's intent when he first wrote this text (but which escaped noticed untile this round of revisions!). I like the general tone of Bill's and Andrew's proposed text; both are consistent with the notion of expressing what is to be audited if an event occurs and if auditing is turned on. I am a bit concerned about leaving the extent of what is logged be so general. A counter of events is not very helpful in identifying the source of a problem, characterizing an attack, etc. I'd be hapy with the notion that a certain set of data MUST be available for an audit log, but that the local security manager gets to select which of these data items is actually logged. I also believe that the IPsec architecture document is a good place to discuss when to audit, and what systems MUST/SHOULD provide an audit capability and what is meant by "secure audit." That audit records can be maintained locally, or transmitted to a remote location, is an appropriate elaboartion of the audit concept and I'm happy to include that as well. Auditing is a common concern for both AH and ESP, so I'd prefer not duplicating the text in each document, although I could be persuaded otherwise. Steve From owner-ipsec Sat Apr 5 08:29:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA17474 for ipsec-outgoing; Sat, 5 Apr 1997 08:28:34 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <01BC401C.6C9FB880@Tastid.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 5 Apr 1997 08:06:06 -0500 To: adams@cisco.com (Rob Adams) From: Stephen Kent Subject: Re: comments on draft-ietf-new-auth-00 Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Rob, Thanks for the feedback; we worked on clarifying wherever possible, but the messages last week show that we still have some work ahead of us. Now onto your comments: Section 1 I agree that often one will not need to use AH and ESP together, now that we have integrity/authentication options within ESP, and assuming that we adopt the revised ESP, that makes encryption optional. However, if one makes use of security labels, AH is important in transport mode. Also, in IPv6, use of AH to protect the new style source routing header has been cited as a motivation for using AH. Section 2.2 I'm all in favor of removing the null algorithm, or rewording if this is just a debugging place holder. Section 3.2.2 You caught me! We'll reword to make it clear that the first packet packet on the wire should be number 1. We'll also add that the receive counter should be initialized to 0. Section 3.2.3.1.1 OK, that's a good explanation for the DF flag, but how about OFFSET? Section 3.3.2 If others do not object, I'm happy to add your proposed text. Section 3.3.3 The algorithm should be updated, as you note, to reflect the split processing. We get a brief reprieve on this, since we pushed it to an appendix in the architecture document. From owner-ipsec Sat Apr 5 08:30:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA17475 for ipsec-outgoing; Sat, 5 Apr 1997 08:28:35 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <01BC4020.D79923C0@Tastid.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 5 Apr 1997 08:14:08 -0500 To: adams@cisco.com (Rob Adams) From: Stephen Kent Subject: Re: comments on draft-ietf-ipsec-new-esp-00 Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Rob, Some more responses to your additional comments: >Section 2.3: > >The draft should probably state that the IV should always be a multiple of >32 bits. >Or require multiples of 64 for IPv6. Well, this is really an algorithm independence issue. We don't get to pick IV lengths; they are defined by the algorithms. However, we can require this field to be a multiple of 32 bits and note that if the real IV does not conform to this requiremend, then the algorithm spec will describe how padding is performed. >Section 2.4: > >To solve the alignment problem, could we always simply require the replay >field. >Don't use it if you don't have AH but leave it there with random trash >otherwise >to preserve alignment. I don't believe I'm saying this... %) Yes, we could, but I hesitate to adopt that approach. It wastes space in an IPv4 context, and the presence/absence of an IV also affects the overall alignment problem, so always requiring the sequence number does not fix this in all cases anyway. For example, if one uses the 32-bit IV (for DES CBC) that is part of the original RFCs, and one allocates 32 bits for the anti-replay sequence counter, we have an IPv6 alignment problem anyway! Steve From owner-ipsec Sat Apr 5 09:51:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA17783 for ipsec-outgoing; Sat, 5 Apr 1997 09:50:38 -0500 (EST) Message-Id: <199704051455.GAA03570@fluffy.cisco.com> To: dpj@world.std.com (David P. Jablon) Cc: ipsec@tis.com Subject: Re: Manual keying and replay prevention and ISAKMP negotiation In-reply-to: Your message of "Fri, 04 Apr 1997 17:30:38 EST." <1.5.4.16.19970404223038.423fdf8a@world.std.com> Date: Sat, 05 Apr 1997 06:55:55 -0800 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk David, It was not the intent of my previous message to suggest that the resolution document encourages the definition of pre-shared secret to be based on a simple password. As you have observed, the resolution document does not currently specify how the pre-shared key is derived. If you have a suggestion as to what it should say about deriving the pre-shared secret, I suspect the authors of that document would be receptive to your comments. Derrell > Derrell, > > I think you are wrong in suggesting that the ISAKMP/Oakley > draft encourage the "pre-shared secrets" to be based on passwords. > The word "password" is carefully (I suppose) omitted in the draft, > and for good reason: Use of a too-small password exposes their > protocol to dictionary attack. > > It *is* possible to do a password-authenticated DH exchange, immune > to network dictionary attack. (e.g. SPEKE or DH-EKE) Such exchanges > could be very convenient for secure re-connections, based on a > temporary memorizable secret -- but these are not specified in Oakley. > > Forgive me if you think this is a nit, but I think > wanton use of passwords as keys is a *bad thing*, especially > in light of truly appropriate password alternatives. > > -- David > > > At 01:04 PM 4/4/97 -0800, you wrote (to Rodney): > > > The specific provision in the IPSEC DOI is for a manual key exchange > > algorithm, separate from Oakley. > > ... > > The ISAKMP/Oakley resolution document describes how to use "pre-shared" > > keys (i.e. passwords) to authenticate the Diffie-Hellman exchange, which > > provides the necessary attribute of manual authentication without digital > > certificates. > > ------------------------------------ > David Jablon > Tel: +1 508 898 9024 > http://world.std.com/~dpj/ > E-mail: dpj@world.std.com From owner-ipsec Sat Apr 5 15:09:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA19032 for ipsec-outgoing; Sat, 5 Apr 1997 15:03:28 -0500 (EST) Message-Id: <199704052007.PAA03116@raptor.research.att.com> To: Stephen Kent cc: adams@cisco.com (Rob Adams), ipsec@tis.com Subject: Re: comments on draft-ietf-ipsec-new-esp-00 Date: Sat, 05 Apr 1997 15:07:09 -0500 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk > >The draft should probably state that the IV should always be a multiple of > >32 bits. > >Or require multiples of 64 for IPv6. > > > Well, this is really an algorithm independence issue. We don't get to pick > IV lengths; they are defined by the algorithms. However, we can require > this field to be a multiple of 32 bits and note that if the real IV does > not conform to this requiremend, then the algorithm spec will describe how > padding is performed. No -- your first instinct is right. The pair is opaque to any level above the decryption routine; thus, higher-level routines can neither known nor care if one is present. At most, the existence of one is a parameter to be passed from the key negotiation layer straight through to the encryption/decryption layer. Let me give a concrete example. In, say, DES-CBC, the IV can be seen as the first block of ciphertext; it's decrypted with any IV whatsoever. The only difference is that the first block of the resulting plaintext -- that is, the plaintext that comes from the (conceptual) decryption of the IV -- is discarded. Seen this way, the difference between the IV and some other portion of the ciphertext is irrelevant. We can carry this further by assuming a block cipher with an 80-bit block size, and hence 80-bit IV. Why would we want to pad the IV? Again, it's just part of the input to the decryption engine. Decisions on the format of the field belong in the RFCs describing individual transforms. Those documents can and should consider block alignment and efficiency considerations for likely implementation techniques. From owner-ipsec Sun Apr 6 00:34:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA21291 for ipsec-outgoing; Sun, 6 Apr 1997 00:33:03 -0500 (EST) Date: Sun, 6 Apr 1997 00:38:30 -0500 From: Norman Shulman X-Sender: norm@rafael.rnd.border.com To: Stephen Kent cc: Rob Adams , ipsec@tis.com Subject: Re: comments on draft-ietf-new-auth-00 In-Reply-To: Message-Id: <97Apr6.003929est.11649@elgreco.rnd.border.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Sat, 5 Apr 1997, Stephen Kent wrote: > Rob, > > Section 3.2.2 > You caught me! We'll reword to make it clear that the first packet > packet on the wire should be number 1. We'll also add that the receive > counter should be initialized to 0. In this case, Section 2.5 should be changed to state that the SA must be changed prior to transmitting 2^32 packets. Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@border.com Fax 1 416 813 2001 From owner-ipsec Sun Apr 6 10:26:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA23291 for ipsec-outgoing; Sun, 6 Apr 1997 10:15:49 -0400 (EDT) From: Uri Blumenthal Message-Id: <9704061421.AA285590@hawpub.watson.ibm.com> Subject: Re: MUST vs. SHOULD audit To: kent@bbn.com (Stephen Kent) Date: Sun, 6 Apr 1997 10:21:13 -0400 (EDT) Cc: ipsec@tis.com In-Reply-To: from "Stephen Kent" at Apr 5, 97 07:54:54 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Kent says: > IPsec defines a protocol, and a protocol definition inlcludes the > processing that takes place at the sender and receiver in response to the > transmission and reception of packets, not just the format of the packet > bits on the wire. Yes, but what to do with the INFORMATION AFTER it is processed clearly is beyond the scope. Verify auth - within. Enter a certain state when the auth failed - within. Define what the alert contains, who it is sent to etc. - questionably outside. Insisting that this alert really gets somewhere - clearly outside. > On that basis, I'd argue that auditing is within the > scope of the IPsec specs, especially since auditing is a security function > and IPsec defines security protocols. By this logic, since physical access to the computer room is a security function too - why don't you put it in the IPSEC paper? > I also believe that the IPsec architecture document is a good place > to discuss when to audit, and what systems MUST/SHOULD provide an audit > capability and what is meant by "secure audit." That audit records can be > maintained locally, or transmitted to a remote location, is an appropriate > elaboartion of the audit concept and I'm happy to include that as well. Let us not mix the two things! It is good and well to ADVISE the user and RECOMMEND the best spots to insert certain implementation-dependent features, like auditing. It is BAD to ENFORCE this 100% imlementation- dependent thing. > Auditing is a common concern for both AH and ESP, so I'd prefer not > duplicating the text in each document, although I could be persuaded > otherwise. No, you are correct here (I think). -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Mon Apr 7 09:52:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA00078 for ipsec-outgoing; Mon, 7 Apr 1997 09:43:03 -0400 (EDT) Message-Id: <3.0.1.32.19970406224934.006ca9d0@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Sun, 06 Apr 1997 22:49:34 -0500 To: Daniel Harkins From: Rodney Thayer Subject: Re: Manual keying and replay prevention and ISAKMP negotiation Cc: ipsec@tis.com In-Reply-To: <199704050304.TAA02427@dharkins-ss20> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Excuse me. I was trying to may attention to Derrell's comments and I chose my words poorly. At 07:04 PM 4/4/97 -0800, you wrote: >> In this case may I suggest we call it "externally generated keys" rather >> than manual keys. I believe this case, where there is some sort of >> external mechanism (i.e. hardware, etc.) generating the keys is compatible >> with Cisco's views, as opposed to (old style humans-type-them-in) manual >> keying. > >cisco's views? I don't think that cisco has a view on what manual keying is. >(Or if it does I haven't been let in on it). Lots of us have opinions but >they don't necessarily have any relation to our employer's. > > Dan (speaking only for myself-- still). > > > From owner-ipsec Tue Apr 8 13:01:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA10666 for ipsec-outgoing; Tue, 8 Apr 1997 12:51:51 -0400 (EDT) Date: Tue, 8 Apr 1997 19:40:09 +0200 (IST) From: Sara Bitan To: Uri Blumenthal Cc: Ran Atkinson , ipsec@tis.com Subject: Re : keys visability (was : Re: auditing) In-Reply-To: <9704031420.AA175280@hawpub.watson.ibm.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk I don't see any reason why secret and private keys should be "visible" let alone be "modifiable". If secret keys are automatically generated (using let's say ISAKMP/Oakley), there is certainly no sense in modifying them, and no need in viewing them. Even if secure SNMP is used, this certainly decreases the security of the system. I think that it is good practice that private/ secret keys will never leave the machine on which they were generated (except maybe for key recovery purposes, and then a secure way of transporting the keys parts should be deviced). The only case when you need to modify keys, is when you use manual keying. Even in this case, I think we should discuss if SNMP is the best way to enter these keys. I don't see any problem with having SNMP manage all but keys. Sara Bitan sarab@radguard.com RADGUARD http://www.radguard.com Tel-Aviv, Israel. -------------------------------------------- On Thu, 3 Apr 1997, Uri Blumenthal wrote: > Ran Atkinson says: > > One could argue that it would be useful to have a standards-track SNMP > > IPsec MIB for diagnostic and auditing information. If anyone wants to > > volunteer to write up such a MIB for this WG to consider, please send > > an email to me and Paul Lambert. > > OK, I volunteer. We'll talk about it in Memphis. > > > I would suggest that things like > > the crypto keys be kept outside such an SNMP MIB because it would be > > unfortunate if a SNMP security breach caused an IPsec security breach. > > I'm sorry but I have to disagree. > > 1. Without secure SNMP deployed, I find the wisdom of being > manageable via non-secure SNMP questionble. > > 2. You either want IPSEC to be managed by SNMP or you don't. > In the first case, several crypto-related variables will > have to be not only "visible" but "modifiable"... > That's life. > -- > Regards, > Uri uri@watson.ibm.com > -=-=-=-=-=-=- > > From owner-ipsec Wed Apr 9 00:14:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA14217 for ipsec-outgoing; Wed, 9 Apr 1997 00:13:03 -0400 (EDT) From: Uri Blumenthal Message-Id: <9704090413.AA35223@hawpub.watson.ibm.com> Subject: Re: Re : keys visability (was : Re: auditing) To: sarab@radguard.com (Sara Bitan) Date: Wed, 9 Apr 1997 00:13:32 -0400 (EDT) Cc: ipsec@tis.com In-Reply-To: from "Sara Bitan" at Apr 8, 97 07:40:09 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Sara Bitan says: > I don't see any reason why secret and private keys should be "visible" let > alone be "modifiable". it is the other way around. The keys may need to be "modifiable", but of course by NO MEANS should they be "visible". When I said "sensitive information" I did not have the keys in mind! > The only case when you need to modify keys, is when you use manual > keying. Even in this case, I think we should discuss if SNMP is the best > way to enter these keys. Secure SNMP probably would be a "good enough" way, especially if integrated in the management framework. > I don't see any problem with having SNMP manage all but keys. (:-) > > 2. You either want IPSEC to be managed by SNMP or you don't. > > In the first case, several crypto-related variables will > > have to be not only "visible" but "modifiable"... > > That's life. Obviously this excludes the keys! -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Wed Apr 9 03:38:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA15400 for ipsec-outgoing; Wed, 9 Apr 1997 03:36:53 -0400 (EDT) From: pcn@teil.soft.net (P.C.Narasimha Reddy) Message-Id: <199704091836.NAA29914@teil.soft.net> Subject: isakmp doubts To: ipsec@tis.com Date: Wed, 9 Apr 1997 13:06:09 -0530 (IST) Cc: pcn@teil.soft.net (P.C.Narasimha Reddy), suren@teil.soft.net (S. Arockia Suren) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk hi I am having some doubts about the isakmp+oakley, can anyone please clarify them. 1) Is the SPI space used by the various protocols defined anywhere? In page 16 of the ISAKMP draft it says that "Each security protocol has its own SPI-space." 2) Is SPI unique on a host? Or is it unique for a particular destination IP address in the SA Data Base? 3) A "PROPOSAL" contains details of one "PROTECTION SUITE", and a "PROTECTION SUITE", may contain many "SECURITY PROTOCOLS". But SPI is part of the proposal payload, and one proposal payload is used to give the details of one "SECURITY PROTOCOL" only. To give details of more than one "SECURITY PROTOCOL" in a proposal we use multiple proposal payloads with the same proposal# (proposal number). So there can be different SPI values for the "SECURITY PROTOCOLS" within the same "PROPOSAL"(ie. multiple proposal payloads with the same proposal number)? So my doubt is whether it is mandatory to use different SPI values for different "SECURITY PROTOCOLS" within the same "PROPOSAL"? Or is it mandatory to use the same SPI value? In the case where different SPI values are mandatory, how is a SA identified, because an SA will then have more than one SPI values(one for each "SECURITY PROTOCOL")? 4) The different Exchanges defined in the ISAKMP have a defined set of messages to be exhanged to negotiate the ISAKMP SA and the IPSEC SA later. How do you handle the issue of "TIMEOUT" and "RE-TRANSMITION" of messages during these Exchanges? Is there an agreed upon way as to how we should handle this issue? I feel that this issue needs an agreed upon standard solution for interoperability reasons. 5) ISAKMP can be used to negotiate multiple SA's between two entities. So when there are multiple active SA's between any two nodes, how do I decide which of the active SA to use for the outgoing traffic? Because in IPSEC, the securing of the IP packets is done in the IP layer, And in the IP layer the information of which process had generated this IP packet is all lost, this information is only available in the socket layer. When we have a very dynamic situation where we have each user on the system, using his own ID_USER_FQDN (example piper@foo.bar.com) and each user negotiates an SA for his use. So we will ultimately have a situation where there are more than one active SA between two nodes(nodes that are identified by IP addresses). Here when the IP layer is securing outgoing traffic, it has to use the SA corresponding to the perticular user, so it has to know which process has generated this traffic, and who is the owner of that process. How can this situation be supported using IPSEC? 6) In a "Video on demand" application, it is logical to have just encryption from the service provider to the customer, and to have just Authentication from the customer to the service provider traffic. In this situation there is a requirement for two SA's to the same destination IP address, one for outgoing traffic only and another for incoming traffic only. How do I negotiate such SA's using ISAKMP? Thanks in advance regards narasimha E-mail: pcn@teil.soft.net From owner-ipsec Wed Apr 9 08:48:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA17299 for ipsec-outgoing; Wed, 9 Apr 1997 08:47:06 -0400 (EDT) Date: Tue, 8 Apr 1997 23:36:10 -0400 (Eastern Daylight Time) From: Rob Glenn Reply-To: Rob Glenn Subject: Comments on draft-ietf-ipsec-new-auth-00.txt To: ipsec@tis.com cc: rob.glenn@nist.gov Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk General comments: I'm a little concerned that by specifying the HMAC MD5 and HMAC SHA-1 algorithms in this draft, we are now one step away from the goal of algorithm independence. - I think it is now more difficult to specify other algorithms for use with AH since the mechanism to do so has been removed (i.e. transform documents) and new algorithm documents will have to point to the AH spec instead of the other way around. - As a result, other algorithms may be presented in a form similar to "transform" documents which defeats the main goal of re- writing the RFCs. - A possible solution would be to remove the references to specific algs. from the draft and point to another draft that contains just a list of algorithms, alg-ids, and the implementation conformance requirements(MUST, SHOULD, or MAY). - This comment applies to the new-esp draft as well. More Specific comments: 1. Anti-replay and multicast are problematic together. See the last paragraph of section 2.1 in draft-ietf-ipsec-ah-hmac-sha-1-96-00.txt 2. I think it is too strong to say that "... a compliant implementation must not negotiate this service (Anti-Replay) in conjuction with SAs that are manually keyed." The implication is that only with a full-blown dynamic key management engine will you ever use Anti- Replay. 3. The straw poll taken a few weeks back concluded that we didn't want a variable sized field in the middle of the AH header. By making the Seq. Number field optional this way, once again we have a variable sized field in the header. One way to fix this would be to move the Authentication Data pad to the beginning of the Authentication Data instead of the end. That way when HMAC-{MD5,SHA-1}-96 is used without Anti-replay and 64-bit alignment is desired, the 32-bits of pad will be located in the same position where the SN would have been. Of course, another solution would be to just fix the SN field. 4. If it is decided to still include algs. in the drafts, then the AH draft should: - specify the default 96-bit truncation in the conformance section, and - mention that HMAC-MD5 is MUST and HMAC-SHA-1 is SHOULD (as previously recommended). From owner-ipsec Wed Apr 9 10:45:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA18155 for ipsec-outgoing; Wed, 9 Apr 1997 10:44:04 -0400 (EDT) Message-Id: <199704091446.KAA27810@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM To: pcn@teil.soft.net, ipsec@tis.com X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: Edward Russell Subject: RE: isakmp doubts Date: Wed, 09 Apr 1997 10:49:14 -0400 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id KAA18152 Sender: owner-ipsec@ex.tis.com Precedence: bulk My turn to be on info duty. >>P.C.Narasimha Reddy (pcn@teil.soft.net) said on 4/9/97 at 3:55 AM > >hi > > I am having some doubts about the isakmp+oakley, > can anyone please clarify them. > > 1) Is the SPI space used by the various protocols > defined anywhere? In page 16 of the ISAKMP draft > it says that "Each security protocol has its own > SPI-space." > The SPI is used for your own implementation's purposes to identify a security association. Use what ever you want (most use a random number, others increment a counter). However below 100 (or is it 500?) is reserved for other purposes. And DON"T use 0 (it will mess up my implementation :-)) Remember, there are 2 SPIs, your SPI and the other guy's SPI. When sending, you must use the other guy's SPI for the SA so he can find the SA. When receiving, you will receive your own SPI for the SA so you can find the SA. > 2) Is SPI unique on a host? Or is it unique for > a particular destination IP address in the > SA Data Base? > That is up to your implementation. You could have unique SPIs per system, per protocol (ESP/AH), or whatever. Just as long as you can find the right SA using the SPI value. > 3) A "PROPOSAL" contains details of one "PROTECTION > SUITE", and a "PROTECTION SUITE", may contain many > "SECURITY PROTOCOLS". But SPI is part of the > proposal payload, and one proposal payload is used > to give the details of one "SECURITY PROTOCOL" only. > To give details of more than one "SECURITY PROTOCOL" > in a proposal we use multiple proposal payloads with > the same proposal# (proposal number). So there can > be different SPI values for the "SECURITY PROTOCOLS" > within the same "PROPOSAL"(ie. multiple proposal > payloads with the same proposal number)? > So my doubt is whether it is mandatory to use different > SPI values for different "SECURITY PROTOCOLS" within the > same "PROPOSAL"? > Or is it mandatory to use the same SPI value? > In the case where different SPI values are mandatory, how > is a SA identified, because an SA will then have more than > one SPI values(one for each "SECURITY PROTOCOL")? > Dealing only with proposal and transform payloads, yes the SPI is in the proposal payload. Proposal payloads may or may not have the same SPI. Again this depends on the uniqueness of your SPIs. If the proposals are of the same number and have the same SPI, you are saying you are using the same SPI for AH and for ESP and that you will be able to find the SA during IPSEC traffic based on both SPI and protocol. If the SPIs have different values for proposals of the same number, you are using SPIs which are unique even across protocols. Either way is fine as long as you can deal with it during IPSEC traffic. As for proposals of different numbers, there is no reason not to use the same AH spi and ESP spi in all proposals since only one will be picked, but again it doesn't matter since the spi for each protocol will be returned to you in the selected proposal response. > 4) The different Exchanges defined in the ISAKMP have > a defined set of messages to be exhanged to negotiate the > ISAKMP SA and the IPSEC SA later. How do you handle > the issue of "TIMEOUT" and "RE-TRANSMITION" of messages > during these Exchanges? Is there an agreed upon way as > to how we should handle this issue? I feel that this > issue needs an agreed upon standard solution for > interoperability reasons. Timeout the message and resend it. After n tries give up and send a notify or delete payload and forget about the negotiation. I do not believe there is an interoperability issue here as long as the implementation can deal with receiving duplicate messages and tossing all but the first. > > 5) ISAKMP can be used to negotiate multiple SA's between > two entities. So when there are multiple active SA's > between any two nodes, how do I decide which of the > active SA to use for the outgoing traffic? Because > in IPSEC, the securing of the IP packets is done > in the IP layer, And in the IP layer the information > of which process had generated this IP packet is all > lost, this information is only available in the socket > layer. When we have a very dynamic situation where we have > each user on the system, using his own ID_USER_FQDN > (example piper@foo.bar.com) and each user negotiates > an SA for his use. So we will ultimately have a > situation where there are more than one active SA > between two nodes(nodes that are identified by IP addresses). > Here when the IP layer is securing outgoing traffic, it > has to use the SA corresponding to the perticular user, > so it has to know which process has generated this traffic, > and who is the owner of that process. How can this situation > be supported using IPSEC? This is user based IPSEC and is in great demand but is not solved yet. Note, I say user based in the sense that multiple "people" or "personalities" on a machine want to talk to the same host using different SAs. We CAN do psuedo-user where authentication of the entire machine is done via a user based certificate, say. But this is not the multiple user case. > > 6) In a "Video on demand" application, it is logical to have > just encryption from the service provider to the customer, and > to have just Authentication from the customer to the service > provider traffic. In this situation there is a requirement for > two SA's to the same destination IP address, one for outgoing > traffic only and another for incoming traffic only. How do I > negotiate such SA's using ISAKMP? > Well, I answered 5 out of 6 anyway. I can certainly send with whatever SA I want, but how do I tell the other side to send to me using a particular SA (SPI)? Is there the concept of SA direction in ISAKMP negotiation? Edward Russell erussell@ftp.com From owner-ipsec Wed Apr 9 13:50:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA19342 for ipsec-outgoing; Wed, 9 Apr 1997 13:44:32 -0400 (EDT) From: "Marcus Leech" Message-Id: <199704091747.AA190658064@bcarh6dc.ott.bnr.ca> Subject: Effective policy enforcement To: ipsec@tis.com Date: Wed, 9 Apr 1997 13:47:43 -0500 (EDT) Organization: Nortel Technologies, System Security Services X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I've been thinking a fair amount about the question of, once we have IPSEC, what kinds of access control (and other) policy may actually be implemented by system administrators using IPSEC with ISAKMP. The current implementations of ISKMP use X.509 certificates, which allow the administrator to establish very broad policy, like: "I will establish an SA with any entitiy bearing a certificate signed by my CA" "I will establish an SA with an entity named Marcus Leech, provided that the certificate was signed by Nortel". Both of these policy directives are implementable with the existing ISAKMP assumptions about certificates. Note, however, that in the second case, if I want to produce (for example) a "group" policy, I must enumerate the Distinguished Names of each member in the group, or I must establish a group CA, and use the first type of policy statement mentioned above. The work of the SPKI group allows for much richer policy enforcement than is possible with an X.509 scheme. I would like to see three things: (1) ISAKMP implementation hooks for SPKI certificate formats. I understand that the SPKI group doesnt' yet have any implementable output, but I don't want to see us do anything to prevent its incorporation at a later date. (2) Viable policy engines in IPSEC/ISAKMP systems that make rich policy enforcement possible, and easy to administer. (3) Availability to the applications of any and all attributes and/or authorizations carried in a certificate used to establish an SA (this applies to both X.509 and SPKI). In other words, it ought to be possible for an application to determine all of the security-relevant attributes for incoming connections to those applications. This kind of support SHOULD NOT be delegated to the application layer. There are HUGE efficency and code-maintability gains to be had by offering this kind of policy management at the IPSEC layer. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQBVAwUBM0vWPKp9EtiCAjydAQGCHwH/WzMrzBdQfiC7z23s3exJwKw6pLklIxhM J9aefOrXQJeoAKfL2Gpiq1uRd9QHVLCC3v2pL9q/QngtbE+7vPqmmg== =oNgJ -----END PGP SIGNATURE----- -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 8M86, MS 238, CAR Systems Security Architect Phone: (ESN) 393-9145 +1 613 763 9145 Systems Security Services Fax: (ESN) 395-1407 +1 613 765 1407 Nortel Technology mleech@nortel.ca -----------------Expressed opinions are my own, not my employer's------ From owner-ipsec Wed Apr 9 16:59:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA20485 for ipsec-outgoing; Wed, 9 Apr 1997 16:55:03 -0400 (EDT) Message-Id: <199704092056.QAA26512@relay.hq.tis.com> Date: Wed, 9 Apr 1997 16:58:21 -0400 From: gary flynn To: ipsec@tis.com, owner-ipsec@tis.com Subject: Re: Effective policy enforcement Sender: owner-ipsec@ex.tis.com Precedence: bulk > This kind of support SHOULD NOT be delegated to the application layer. > There are HUGE efficency and code-maintability gains to be had by > offering this kind of policy management at the IPSEC layer. Not to mention the realization of universal, interoperable authentication/authorization implementations. Gary Flynn Network Analyst James Madison University From owner-ipsec Wed Apr 9 18:43:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA21214 for ipsec-outgoing; Wed, 9 Apr 1997 18:42:42 -0400 (EDT) Date: Wed, 9 Apr 1997 17:48:09 -0400 Message-Id: <199704092148.RAA00302@alisan.ibm.net> From: Uri Blumenthal To: ipsec@tis.com Subject: IPSec MIB Reply-to: uri@watson.ibm.com Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Howdy! A good news is, as you should have already heard - IPSec MIB work has begun. Rodney Thayer and myself kindly undertook the mission. (:-) It is possible that we create an ipsec-mib mailing list for information exchange that isn't of interest to "generic" IPSEC crowd. If so, the announcement will come out her shortly. Otherwise we'll stay here, for your benefit and our amusement. In the meanwhile, please inhale, exhale and contemplate the following: what information that one could retrieve would help you monitor, control and DEBUG an IPSEC code? As has been already said, we can give you plenty of counters - but do you care to have 'em? If you are an implementor who has the pleasure of debugging the code, or a NetAdmin who's going to have the sorry job of configuring the installations and figuring out why the hell the dozen of seemingly healthy computers absolutely refuse to talk to each other - please read on and be ready to give us peace of your mind wrt. what we can do to make your life easier. IPSEC MIB can offer you knowb and dials to monitor what the protocol is doing and to affect (control) its operations. Probably IPSEC MIB will be used in conjunction with the other MIBs your box is likely to have ("interfaces" group, for example, that gives you some info on what's going on with the interface cards - how much traffic went through, error rate etc). A first shot. Dials: - a list of SPIs with the parameter values might be helpful; - a list of the hashes of the keys in use might assist in debugging; - some counters (number of rekeys, number of bad auth, garbled crypto, etc.) could be of some use; - do you care to have anything else? Precisely what? What for (i.e. how would you use it)? Knobs/buttons: - enforce rekey now; - control of various windows and timeouts (make 'em narrower or wider); - enabling/disabling certain algorithms (that could be then used in the negotiations); - enabling/disabling certain modes (i.e. from now on only encrypting SA can be negotiated); - set certain parameters (length of something...?); - again, anything else? If this MIB is to be useful and not just a placeholder (like too many of the existing MIBs) - please give us your input. If you have anything [constructive] to say, please either post it here, or e-mail to BOTH of us: uri@watson.ibm.com rodney@sabletech.com Thanks for your attention, you may get back to work now (:-). Regards, Uri -=-=-==-=-=- uri@watson.ibm.com From owner-ipsec Wed Apr 9 18:52:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA21271 for ipsec-outgoing; Wed, 9 Apr 1997 18:52:11 -0400 (EDT) To: ipsec@tis.com Subject: slicing and dicing From: Marc Horowitz Date: 09 Apr 1997 18:57:31 -0400 Message-ID: Lines: 11 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-ipsec@ex.tis.com Precedence: bulk There has recently been interest in my draft which explains (partially by reference) a method for using a bunch of bits to generate a set of keys. Here is a pointer to the i-d: ftp://ietf.org/internet-drafts/draft-horowitz-key-derivation-01.txt This document needs a few tweaks (in particular, I should inline the necessary part of blumenthal & bellovin's paper, as it's very simple), but it should be easily modified for IPsec use. Marc From owner-ipsec Thu Apr 10 00:14:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA22759 for ipsec-outgoing; Thu, 10 Apr 1997 00:12:48 -0400 (EDT) From: Uri Blumenthal Message-Id: <9704100418.AA54137@hawpub.watson.ibm.com> Subject: Re: IPSec MIB To: angelos@dsl.cis.upenn.edu (Angelos D. Keromytis) Date: Thu, 10 Apr 1997 00:18:23 -0400 (EDT) Cc: ipsec@tis.com In-Reply-To: <199704100311.XAA19424@codex.cis.upenn.edu> from "Angelos D. Keromytis" at Apr 9, 97 10:10:59 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Angelos D. Keromytis says: > > - a list of the hashes of the keys in use > > might assist in debugging; > > I'll point out that this allows for exhaustive search. It just *helps* an exhaustive search, making it slightly easier than a known-plaintext-exhaustive-search attack. An access to these particular objects should be restricted in any case, or these objects may not exist at all. The question here is whether the usefulness of these objects justifies their existence (and so we should devise a way to remove or minimize the exposure), or the benefit is too small to bother. When trying to figure out how come that the two boxes refuse to talk to each other, observing that: - the counter of "rejected 'cause of bad auth" is increasing rapidly; - the hashes of the key presumably used are different, one can make a pretty good guess what is happening. This assumes that there is an "authorized" NetAdmin whose job is to get the things working on his whole admin domain. As I said earlier, I'm not really sure what info is absolutely necessary to quickly determine the cause of the problem, nor whether the existing (plus those being designed now) protection methods of SNMP are deemed adequate. That is one of the reasons I'm asking all these questions. > > - some counters (number of rekeys, number of > > bad auth, garbled crypto, etc.) could be > > of some use; > > Yes. Two implementations use the netstat mechanism to display such > information. Good. Let's have it solidified, what counters could be of use. Obviously the ones I mentioned. Anything else? > >Knobs/buttons: > > I'd argue against *setting* anything. This is best done through the > key management daemon and policy engine. SNMP would complicate matters. Possibly. I tend to prefer to "concentrate" my control (i.e. both "watching" and "tweaking") in the same spot/tool... Anybody else cares to comment on this? > This however is a very critical MIB. I'm not sure whether setting > IPsec related SNMP variables makes any sense, since most of the > decisions are taken at a user level process (the KMP). This is a very good point. I didn't think about it. Of course KMP can be instrumented too... Should it be...? -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Thu Apr 10 07:52:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA25363 for ipsec-outgoing; Thu, 10 Apr 1997 07:51:23 -0400 (EDT) Message-Id: <199704101151.HAA25363@portal.ex.tis.com> To: uri@watson.ibm.com cc: ipsec@tis.com Subject: Re: IPSec MIB In-reply-to: Your message of "Wed, 09 Apr 1997 17:48:09 -0400." <199704092148.RAA00302@alisan.ibm.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12366.860641859.1@dsl.cis.upenn.edu> Date: Wed, 09 Apr 1997 22:10:59 +0000 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199704092148.RAA00302@alisan.ibm.net>, Uri Blumenthal writes: > > - a list of SPIs with the parameter values > might be helpful; Absolutely. Three implementations right now use the kernfs/procfs interface for this. > - a list of the hashes of the keys in use > might assist in debugging; I'll point out that this allows for exhaustive search. > - some counters (number of rekeys, number of > bad auth, garbled crypto, etc.) could be > of some use; Yes. Two implementations use the netstat mechanism to display such information. >Knobs/buttons: > - enforce rekey now; > - control of various windows and timeouts (make > 'em narrower or wider); > - enabling/disabling certain algorithms (that > could be then used in the negotiations); > - enabling/disabling certain modes (i.e. from now > on only encrypting SA can be negotiated); > - set certain parameters (length of something...?); > - again, anything else? I'd argue against *setting* anything. This is best done through the key management daemon and policy engine. SNMP would complicate matters. >If this MIB is to be useful and not just a placeholder >(like too many of the existing MIBs) - please give us >your input. This however is a very critical MIB. I'm not sure whether setting IPsec related SNMP variables makes any sense, since most of the decisions are taken at a user level process (the KMP). My $.02 + tax. -Angelos From owner-ipsec Thu Apr 10 10:38:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27200 for ipsec-outgoing; Thu, 10 Apr 1997 10:36:44 -0400 (EDT) Date: Thu, 10 Apr 1997 10:40:22 -0400 (EDT) Message-Id: <199704101440.KAA23886@carp.morningstar.com> From: Ben Rogers To: ipsec@tis.com Subject: Inconsistent Specs. Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk It seems that there is an inconsistency between the most recent drafts on IPsec and ISAKMP with respect to SPI/SA spaces. The IPsec draft seems to indicate that there is a single SPI space shared by all protocols, whereas the ISAKMP spec clearly indicates that this should not be the case. from draft-ietf-ipsec-arch-sec-01.txt: SPI Acronym for "Security Parameters Index." The combination of an SPI and a destination address uniquely identifies a simplex security association (SA, see below). The SPI is carried in IPsec protocols to select the set of parameters bound to an SA. An SPI has only local significance, defined by the creator of the SA; thus an SPI is generally viewed as an opaque bit string. However, the creator of an SA may choose to interpret the bits in an SPI to facilitate local processing. [SNIP] 1.5 Security Association Management The concept of a "Security Association" is fundamental to both the IP Encapsulating Security Payload and the IP Authentication Header. The combination of a given Security Parameter Index (SPI) and Destination Address uniquely identifies a particular "Security Association". An implementation of the Authentication Header or the Encapsulating Security Payload MUST support this concept of a Security Association. A single IPsec Security Association is a simplex (unidirectional) connection with which either AH or ESP (but not both) is employed. If both AH and ESP protection is to be applied to a traffic stream, then two (or more) security associations are created to control processing of the traffic stream. from draft-ietf-ipsec-isakmp-07.txt: Security Parameter Index (SPI) An identifier for a Security Assocation, relative to some security protocol. Each security protocol has its own ``SPI-space''. A (security protocol, SPI) pair may uniquely identify an SA. Depending on the DOI, additional information (e.g. host address) may be necessary to identify an SA. From owner-ipsec Thu Apr 10 12:29:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA27864 for ipsec-outgoing; Thu, 10 Apr 1997 12:26:59 -0400 (EDT) Message-Id: <199704100013.TAA00333@morden.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Effective policy enforcement In-reply-to: Your message of "Wed, 09 Apr 1997 13:47:43 CDT." <199704091747.AA190658064@bcarh6dc.ott.bnr.ca> Date: Wed, 09 Apr 1997 19:13:52 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Marcus" == Marcus Leech writes: Marcus> (2) Viable policy engines in IPSEC/ISAKMP systems that Marcus> make rich policy enforcement possible, and easy to Marcus> administer. I too want to see this too. I know that this is planned for several implementations. I'm hoping that the "FreeSWAN" implementations will be one of them. Marcus> (3) Availability to the applications of any and all Marcus> attributes and/or authorizations carried in a certificate Marcus> used to establish an SA (this applies to both X.509 and Marcus> SPKI). In other words, it ought to be possible for an Marcus> application to determine all of the security-relevant Marcus> attributes for incoming connections to those applications. This requires an extensive API. I'd like to see, as a first step, a work new ipsec wg work item: we should be writing drafts to describe SPKI auth/tag fields. I suggest that this be scheduled for post-Proposed Status for the existing drafts. ] IETF #38. In Memphis, TN. Elvis is in the terminal room! | one quark [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON | two quark [ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | red q blue q[ ] 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 iQB1AwUBM0wwu8mxxiPyUBAxAQElCAL/ai1DXZOvAzhIBgGINaLQfJ0Q5MC5QmcB FVHxExmWrbhDGrHv5I54lio+z0rXFLUhMlv9hgVNdUEVpbidWIrwS3Vmi1wqsiWS t1hX77QSX915n0dAuJAR7PJSBCKDplXE =6eZq -----END PGP SIGNATURE----- From owner-ipsec Thu Apr 10 17:28:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA29667 for ipsec-outgoing; Thu, 10 Apr 1997 17:22:10 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <9704061421.AA285590@hawpub.watson.ibm.com> References: from "Stephen Kent" at Apr 5, 97 07:54:54 am Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 10 Apr 1997 17:26:08 -0400 To: uri@watson.ibm.com From: Stephen Kent Subject: Re: MUST vs. SHOULD audit Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Uri, >> IPsec defines a protocol, and a protocol definition inlcludes the >> processing that takes place at the sender and receiver in response to the >> transmission and reception of packets, not just the format of the packet >> bits on the wire. > >Yes, but what to do with the INFORMATION AFTER it is processed clearly >is beyond the scope. Verify auth - within. Enter a certain state when >the auth failed - within. Define what the alert contains, who it is >sent to etc. - questionably outside. Insisting that this alert >really gets somewhere - clearly outside. The events that trigger audit activities are part of the protocol spec, as are other specifications of error conditions. A requirement that an implementation be capable of creating audit log entries in response to such events is also a legitimate part of the protocol processing spec. [SNIP] >> I also believe that the IPsec architecture document is a good place >> to discuss when to audit, and what systems MUST/SHOULD provide an audit >> capability and what is meant by "secure audit." That audit records can be >> maintained locally, or transmitted to a remote location, is an appropriate >> elaboartion of the audit concept and I'm happy to include that as well. > >Let us not mix the two things! It is good and well to ADVISE the user >and RECOMMEND the best spots to insert certain implementation-dependent >features, like auditing. It is BAD to ENFORCE this 100% imlementation- >dependent thing. Responses from other WG members suggests that so long as we restrict the specs to requring support for what COULD be audited, IF auditing is turned on and IF the system in which IPsec is embedde supports auditing, then this is a reasonable part of the IPsec specifications. Steve From owner-ipsec Thu Apr 10 17:50:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA29817 for ipsec-outgoing; Thu, 10 Apr 1997 17:50:02 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199704101440.KAA23886@carp.morningstar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 10 Apr 1997 17:54:29 -0400 To: ben@Ascend.COM (Ben Rogers) From: Stephen Kent Subject: Re: Inconsistent Specs. Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Ben, You're right! We will modify the AH and ESP specs to note that an SPI uniquely identifies an SA on a per destination AND per security protocol basis. Thanks for picking up on that inconsistency. Steve From owner-ipsec Thu Apr 10 19:14:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA00188 for ipsec-outgoing; Thu, 10 Apr 1997 19:13:51 -0400 (EDT) Message-Id: <199704102118.RAA06537@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: ipsec@tis.com Subject: Slicing and Dicing in new-esp Date: Thu, 10 Apr 1997 17:18:25 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk The new esp draft, draft-ietf-ipsec-new-esp-00.txt, has two "slots" into which algorithms can be plugged -- an encryption slot, and an integrity slot. This is somewhat different from the previous monolithic transform architecture in the Hughes draft. The consensus on slice & dice at the meeting today was that transforms get one key, and are responsible for dividing the "key blob" between the various uses they have for it. In the case of new-esp, we have a hierarchical arrangement, with ESP in the middle, key management above, and algorithms beneath; the new-esp document really defines both ESP and a "meta" transform. I presume that the new-esp meta-transform gets a (single) key blob from "above" and needs to break it up and pass "key blobs" down into the algorithms which plug into it. Now, there are certain, obvious to a non-cryptographer, problems with passing the exact same blob to both algorithms. I believe that the right thing to do here is to specify that new-ESP is responsible for dividing the blob into two pieces and feeding one to the encryption algorithm and the other into the integrity algorithm; the individual algorithms are resposible for any relevant algorithmic-specific key processing. - Bill From owner-ipsec Fri Apr 11 07:50:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA04255 for ipsec-outgoing; Fri, 11 Apr 1997 07:49:47 -0400 (EDT) Message-Id: <199704111149.HAA04255@portal.ex.tis.com> To: Michael Richardson cc: ipsec@tis.com Subject: Re: Effective policy enforcement MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13733.860736298.1@dsl.cis.upenn.edu> Date: Fri, 11 Apr 1997 00:24:58 +0000 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199704100013.TAA00333@morden.sandelman.ottawa.on.ca>, Michael Richa rdson writes: > This requires an extensive API. Well, i would think that the important attributes are whether the link is: a) encrypted b) authenticated c) tunneled (ie the options are protected) d) compressed (?) These are addressed (at least to some extend) in Dan McDonald's draft. > I'd like to see, as a first step, a work new ipsec wg work item: we >should be writing drafts to describe SPKI auth/tag fields. I suggest >that this be scheduled for post-Proposed Status for the existing drafts. I agree. I wouldn't even mind working towards it. -Angelos From owner-ipsec Fri Apr 11 07:50:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA04247 for ipsec-outgoing; Fri, 11 Apr 1997 07:48:46 -0400 (EDT) Message-Id: <199704111148.HAA04247@portal.ex.tis.com> To: uri@watson.ibm.com cc: ipsec@tis.com Subject: Re: IPSec MIB MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13466.860733942.1@dsl.cis.upenn.edu> Date: Thu, 10 Apr 1997 23:45:43 +0000 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <9704100418.AA54137@hawpub.watson.ibm.com>, Uri Blumenthal writes: >An access to these particular objects should be restricted in >any case, or these objects may not exist at all. The question >here is whether the usefulness of these objects justifies >their existence (and so we should devise a way to remove >or minimize the exposure), or the benefit is too small >to bother. Well, i think that: a) this is useful mostly for debugging (-> development) b) why open a potential hole there if it's not going to be used by your every-day user/admin/whoever >Of course KMP can be instrumented too... Should it be...? I believe that mandating KMPs to monitor SNMP variables is unreasonable (i will admit i have little knowledge of the inner workings of SNMP). If you make it optional, router vendors will probably support it. For all other implementations (ie. non-routers), i think it's not realistic to use a network monitoring protocol to control a user application (the KMP). My 4.8 drachmas (about $0.02). -Angelos From owner-ipsec Fri Apr 11 07:50:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA04279 for ipsec-outgoing; Fri, 11 Apr 1997 07:50:46 -0400 (EDT) Message-Id: <199704111150.HAA04279@portal.ex.tis.com> To: Stephen Kent cc: uri@watson.ibm.com, ipsec@tis.com Subject: Re: MUST vs. SHOULD audit MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13869.860737233.1@dsl.cis.upenn.edu> Date: Fri, 11 Apr 1997 00:40:33 +0000 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message , Stephen Kent writes: > >Responses from other WG members suggests that so long as we restrict the >specs to requring support for what COULD be audited, IF auditing is turned >on and IF the system in which IPsec is embedde supports auditing, then this >is a reasonable part of the IPsec specifications. Well, today's implementor's meeting at the IPsec decided that auditing *should* be done. I strongly disagree with going into details of the sort "well, if you have auditing and you have it turned on then you should log this and that event". -Angelos From owner-ipsec Fri Apr 11 07:58:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA04347 for ipsec-outgoing; Fri, 11 Apr 1997 07:57:49 -0400 (EDT) Message-Id: <199704111157.HAA04347@portal.ex.tis.com> To: Bill Sommerfeld cc: ipsec@tis.com Subject: Re: Slicing and Dicing in new-esp MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13892.860737473.1@dsl.cis.upenn.edu> Date: Fri, 11 Apr 1997 00:44:33 +0000 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199704102118.RAA06537@thunk.ch.apollo.hp.com>, Bill Sommerfeld writ es: >Now, there are certain, obvious to a non-cryptographer, problems with >passing the exact same blob to both algorithms. I believe that the >right thing to do here is to specify that new-ESP is responsible for >dividing the blob into two pieces and feeding one to the encryption >algorithm and the other into the integrity algorithm; the individual >algorithms are resposible for any relevant algorithmic-specific key >processing. I fully agree. -Angelos From owner-ipsec Fri Apr 11 08:24:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA04573 for ipsec-outgoing; Fri, 11 Apr 1997 08:24:25 -0400 (EDT) Message-Id: <199704111227.HAA00308@smb.research.att.com> To: "Angelos D. Keromytis" cc: uri@watson.ibm.com, ipsec@tis.com Subject: Re: IPSec MIB Date: Fri, 11 Apr 1997 07:27:56 -0500 From: "Steven M. Bellovin" Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <9704100418.AA54137@hawpub.watson.ibm.com>, Uri Blumenthal writes: >An access to these particular objects should be restricted in >any case, or these objects may not exist at all. The question >here is whether the usefulness of these objects justifies >their existence (and so we should devise a way to remove >or minimize the exposure), or the benefit is too small >to bother. Well, i think that: a) this is useful mostly for debugging (-> development) b) why open a potential hole there if it's not going to be used by your every-day user/admin/whoever >Of course KMP can be instrumented too... Should it be...? I believe that mandating KMPs to monitor SNMP variables is unreasonable (i will admit i have little knowledge of the inner workings of SNMP). If you make it optional, router vendors will probab ly support it. Current IETF policy requires that every protocol have a MIB, and that all network elements be manageable via SNMP. After all, if we can mandate security, others can mandate manageability... From owner-ipsec Fri Apr 11 10:40:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA05503 for ipsec-outgoing; Fri, 11 Apr 1997 10:39:04 -0400 (EDT) Date: Fri, 11 Apr 1997 10:41:31 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704111441.KAA08079@earth.hpc.org> To: sommerfeld@apollo.hp.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199704102326.QAA09456@baskerville.CS.Arizona.EDU> Subject: Re: Slicing and Dicing in new-esp Sender: owner-ipsec@ex.tis.com Precedence: bulk The discussion seems to cover only slicing the key blob, not inflating. If the key blob is shorter than the total key length needed by the transform algorithms, then it must be inflated, and the inflation should be done on the total key blob, not slices of it. E.g., integrity needs 160 bits of key, encryption needs 112, the key blob is 200 bits. I've recommended using something like K' = hash(K,0) | hash(K,1) as the inflated key blob, and then 160 and 112 can be sliced from K', assuming that the output of the hash function is large enough. And the hash function is the one used for the key negotiation. BTW, it's not obvious to me that having encryption and integrity use the same key blob is so very awful. Hilarie From owner-ipsec Fri Apr 11 14:19:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA06767 for ipsec-outgoing; Fri, 11 Apr 1997 14:17:00 -0400 (EDT) From: Uri Blumenthal Message-Id: <9704111822.AA22459@hawpub.watson.ibm.com> Subject: Re: IPSec MIB To: angelos@dsl.cis.upenn.edu (Angelos D. Keromytis) Date: Fri, 11 Apr 1997 14:22:41 -0400 (EDT) Cc: ipsec@tis.com In-Reply-To: <199704110446.AAA25757@codex.cis.upenn.edu> from "Angelos D. Keromytis" at Apr 10, 97 11:45:43 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Angelos D. Keromytis says: > Well, i think that: > a) this is useful mostly for debugging (-> development) > b) why open a potential hole there if it's not going to be used by > your every-day user/admin/whoever You might be surprised, but most OTHER vendors do have bugs in their code, and systems do get misconfigured more often than not. Thus, "debugging" isn't only done by the vendor quality control - but often by the customers as well. > >Of course KMP can be instrumented too... Should it be...? > I believe that mandating KMPs to monitor SNMP variables is > unreasonable (i will admit i have little knowledge of the inner > workings of SNMP). If you make it optional, router vendors will probably > support it. Oh no, either IPSEC nor KMP would ever *monitor* SNMP variables! They might *maintain* those variables so that SNMP may *access* them (i.e. "request" the values of those variables, if al the proper credentials are shown). > For all other implementations (ie. non-routers), i think it's not > realistic to use a network monitoring protocol to control a user > application (the KMP). Well, there's megabucks market for application management, and there are at least two WG's in the IETF that are working on application management via SNMP (ApplMIB and SysAplMIB to name a few)... And those aim at monitoring (and managing?) various applications running on different systems... > My 4.8 drachmas (about $0.02). (:-) -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Fri Apr 11 16:39:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07587 for ipsec-outgoing; Fri, 11 Apr 1997 16:37:58 -0400 (EDT) Message-Id: <199704112041.QAA05594@amaterasu.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Slicing and Dicing in new-esp In-reply-to: Your message of "Fri, 11 Apr 1997 10:41:31 EDT." <199704111441.KAA08079@earth.hpc.org> Date: Fri, 11 Apr 1997 16:41:13 -0400 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Hilarie" == Hilarie Orman writes: Hilarie> not inflating. If the key blob is shorter than the total Hilarie> key length needed by the transform algorithms, then it Hilarie> must be inflated, and the inflation should be done on the This keeps coming up. My understanding is that this won't happen: the key management daemon can produce as many bits as needed for the security bundle. :!mcr!: | Network security consulting and Michael Richardson | contract programming WWW: mcr@sandelman.ottawa.on.ca. PGP key available. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBM06ftKZpLyXYhL+BAQF2cAL+LKH6FUpdjITciiJIhDHk8EicRiq8F0f0 TUqseC0uQ0aF+3hLUsu+IeUWoxcyqS50A6Xg4sdauCyMBL1JGp59GEg+e/toSGHW amwj/Bka8r9jPLHR/tGUjwCdbFYa1Py9 =xSOt -----END PGP SIGNATURE----- From owner-ipsec Fri Apr 11 17:26:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA07845 for ipsec-outgoing; Fri, 11 Apr 1997 17:24:53 -0400 (EDT) Date: Fri, 11 Apr 1997 17:25:43 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704112125.RAA20181@earth.hpc.org> To: mcr@sandelman.ottawa.on.ca Cc: ipsec@tis.com In-reply-to: Yourmessage <199704112057.NAA14171@baskerville.CS.Arizona.EDU> Subject: Re: Slicing and Dicing in new-esp Sender: owner-ipsec@ex.tis.com Precedence: bulk > My understanding is that this won't happen: the key management > daemon can produce as many bits as needed for the security bundle. I hope it won't happen. The key management can produce as many bits of entropy as are needed for the security bundle; whether or not it presents that entropy in a string with as many bits as the security bundle desires is less clear. If it does produce the correct number of bits, then it might as well present them pre-sliced, it seems to me. If the transforms still wish to twiddle the bits, they can do so. Hilarie From owner-ipsec Sat Apr 12 12:13:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA12319 for ipsec-outgoing; Sat, 12 Apr 1997 12:09:17 -0400 (EDT) Message-ID: <01BC4732.ADC2E860@tastid.cisco.com> From: Rob Adams To: "mcr@sandelman.ottawa.on.ca" , "'Hilarie Orman'" Cc: "ipsec@tis.com" Subject: RE: Slicing and Dicing in new-esp Date: Sat, 12 Apr 1997 11:14:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk In the implementors meeting we agreed that the key management layer will create for the transform a minimum number of bits of key material specified by the transform. We shouldn't have a problem anymore. -Rob ---------- From: Hilarie Orman[SMTP:ho@earth.hpc.org] Sent: Friday, April 11, 1997 2:25 PM To: mcr@sandelman.ottawa.on.ca Cc: ipsec@tis.com Subject: Re: Slicing and Dicing in new-esp > My understanding is that this won't happen: the key management > daemon can produce as many bits as needed for the security bundle. I hope it won't happen. The key management can produce as many bits of entropy as are needed for the security bundle; whether or not it presents that entropy in a string with as many bits as the security bundle desires is less clear. If it does produce the correct number of bits, then it might as well present them pre-sliced, it seems to me. If the transforms still wish to twiddle the bits, they can do so. Hilarie From owner-ipsec Sat Apr 12 12:25:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA12423 for ipsec-outgoing; Sat, 12 Apr 1997 12:25:35 -0400 (EDT) Message-Id: <199704111939.PAA07189@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: ho@earth.hpc.org (Hilarie Orman) Cc: ipsec@tis.com Subject: Re: Slicing and Dicing in new-esp In-Reply-To: ho's message of Fri, 11 Apr 1997 10:41:31 -0400. <199704111441.KAA08079@earth.hpc.org> Date: Fri, 11 Apr 1997 15:39:54 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm trying to make sure that the boundary between key management and ESP/AH is well specified. Assuming I understand it correctly, the current new-esp draft mentions receiving two keys from key management (one auth key, one encryption key), while the current ipsec DOI draft specifies providing one key blob to ESP. This sounds like a mismatch to me.. > The discussion seems to cover only slicing the key blob, not > inflating. If the key blob is shorter than the total key length > needed by the transform algorithms, then it must be inflated, and the > inflation should be done on the total key blob, not slices of it. Right, but this expansion should happen in key management, not the transforms/algorithms; ESP should not need to know which prf was used for key negotiation. During the implementors meeting, there seemed to be no objection to the concept that the transform should ask for a specific amount of keying material, and that key management is responsible for delivering at least that much. - Bill From owner-ipsec Sat Apr 12 12:26:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA12436 for ipsec-outgoing; Sat, 12 Apr 1997 12:26:05 -0400 (EDT) Message-Id: <199704112048.QAA07306@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: "Angelos D. Keromytis" Cc: Stephen Kent , uri@watson.ibm.com, ipsec@tis.com Subject: Re: MUST vs. SHOULD audit In-Reply-To: angelos's message of Fri, 11 Apr 1997 00:40:33 -0000. <199704111150.HAA04279@portal.ex.tis.com> Date: Fri, 11 Apr 1997 16:48:53 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > >Responses from other WG members suggests that so long as we restrict the > >specs to requring support for what COULD be audited, IF auditing is turned > >on and IF the system in which IPsec is embedde supports auditing, then this > >is a reasonable part of the IPsec specifications. > > Well, today's implementor's meeting at the IPsec decided that auditing > *should* be done. I strongly disagree with going into details of > the sort "well, if you have auditing and you have it turned on then > you should log this and that event". Ok, between Steve's message and what I saw at the meeting yesterday, there seems to be general agreement that the drafts should define the "audit points" in the protocol (that may not be quite the right term, but I think people know what I mean), and that if ipsec auditing is supported by an implementation, it should be possible for an administrator to enable/disable it. The remaining point of contention appears to be the difference between "SHOULD support auditing" and "MUST support auditing if the platform supports auditing". I think that there's not going to be a whole lot of difference in practice between these two points, so I don't see a need to overspecify on this point -- the documents are long enough as it is.. - Bill From owner-ipsec Sun Apr 13 00:10:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA15274 for ipsec-outgoing; Sun, 13 Apr 1997 00:08:31 -0400 (EDT) Message-Id: <2.2.32.19970413041321.0068e7a8@pita.cisco.com> X-Sender: shacham@pita.cisco.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 12 Apr 1997 21:13:21 -0700 To: ipsec@tis.com From: Avram Shacham Subject: IPComp presentation URL Sender: owner-ipsec@ex.tis.com Precedence: bulk Per several requests, the IP Compression data, as presented to the IPSec working group in Memphis, Tennessee, on 4-9-97, are located at http://www.tgv.cisco.com/public/shacham/ipcomp.ppt The file is in PowerPoint v7.0 format. Regards, avram From owner-ipsec Mon Apr 14 07:55:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA24659 for ipsec-outgoing; Mon, 14 Apr 1997 07:45:57 -0400 (EDT) Date: Mon, 14 Apr 1997 01:40:02 -0400 From: Ran Canetti Message-Id: <9704140540.AA25094@ornavella.watson.ibm.com> To: ipsec@tis.com Subject: Re: IPSec MIB Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > - a list of the hashes of the keys in use > > > might assist in debugging; > > > > I'll point out that this allows for exhaustive search. > > It just *helps* an exhaustive search, making it slightly easier > than a known-plaintext-exhaustive-search attack. Let me just point out that making public the hash of the secret key can be disastrous to the security is some scenarios (I slightly elaborate below.) So, if the intention is to publicize the hash only during development stage than that's ok (as long as this option is later turned off). But doing that in real deployment of the protocol is a no-no. Assume for simplicity that Alice wants to encrypt only one word: either "yes" or "no". Also, not trusting DES, Alice uses the most secure encryption protocol, namely one-time-pad. That is, the ciphertext is the cleartext xored with the key. If Alice uses a key derived from the current ISAKMP/Oakley protocol then the transmission will be secure. But if the protocl publishes a hash of the key, then it's easy to find out whether the message was "yes" or "no"! (Simply xor the ciphertext with "yes", hash, and compare with the hashed key.) Even if we do not know the possible messages and cannot do exhaustive search, then by making public the hash of the key we're making a very strong assumption on the hash function: we assume that the hash does not reveal *any relevant information* on the key. The existing hash functions were not designed for such a purpose and it's far from clear that they are strong enough for this use. Hope I'm not barging through an already open door, Ran From owner-ipsec Mon Apr 14 07:55:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA24740 for ipsec-outgoing; Mon, 14 Apr 1997 07:51:02 -0400 (EDT) Date: Fri, 11 Apr 97 23:01:59 GMT From: "William Allen Simpson" Message-ID: <2264.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: IPSec MIB Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Uri Blumenthal > Angelos D. Keromytis says: > > a) this is useful mostly for debugging (-> development) > > b) why open a potential hole there if it's not going to be used by > > your every-day user/admin/whoever > > You might be surprised, but most OTHER vendors do have bugs > in their code, and systems do get misconfigured more often > than not. Thus, "debugging" isn't only done by the vendor > quality control - but often by the customers as well. > Gentlefolk, in my experience, it has been a long standing policy of the network management area that protocol debugging and development variables are _not_ appropriate for MIBs. I expect that IESG integration of management with operations should make that even more clear. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Mon Apr 14 12:13:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA26716 for ipsec-outgoing; Mon, 14 Apr 1997 12:10:04 -0400 (EDT) Date: Mon, 14 Apr 1997 12:14:52 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199704141614.MAA17818@argon.ncsc.mil> To: ipsec@tis.com Subject: Re: Effective policy enforcement X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: "Marcus Leech" > > I've been thinking a fair amount about the question of, once we have > IPSEC, what kinds of access control (and other) policy may actually > be implemented by system administrators using IPSEC with ISAKMP. > > The current implementations of ISKMP use X.509 certificates, which allow > the administrator to establish very broad policy, like: > > "I will establish an SA with any entitiy bearing a certificate signed by > my CA" > > "I will establish an SA with an entity named Marcus Leech, provided that > the certificate was signed by Nortel". > > Both of these policy directives are implementable with the existing ISAKMP > assumptions about certificates. Note, however, that in the second case, > if I want to produce (for example) a "group" policy, I must enumerate > the Distinguished Names of each member in the group, or I must establish > a group CA, and use the first type of policy statement mentioned above. > > The work of the SPKI group allows for much richer policy enforcement than > is possible with an X.509 scheme. This is certainly not true. The evolving SPKI mechanism can allow a richer set of authorizations than the two broad examples you specified above. But so does X.509. The richness of expression (and the attendent complexity) of an access control mechanism is determined by the capabilities of the mechanism, not by a particular certificate encoding format. A recent message by David Simonetti (in a non-IETF forum) listed seven access control mechanisms currently being developed for a specific (X.509-based, non-IETF) application, and proposed that they be consolidated into four categories: "ISO 10181-3, Access Control Framework, provides the following classification of access control mechanisms: Cabability-based, Label-based, List-based, and Contextual-based." The point of this quotation is not that the MISSI access control framework or ISO 10181-3 are the be-all and end-all of "policy administration". The point is that characterizing X.509 certificates based on the capabilities of current IPSEC/ISAKMP implementations is a tad myopic, and ignores a large body of prior art. From owner-ipsec Mon Apr 14 16:12:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA28606 for ipsec-outgoing; Mon, 14 Apr 1997 16:11:08 -0400 (EDT) Date: Mon, 14 Apr 1997 16:16:20 -0400 From: Norman Shulman X-Sender: norm@rafael.rnd.border.com To: ipsec@tis.com Subject: ESP with stream ciphers Message-Id: <97Apr14.161245edt.11650@janus.border.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk I am wondering how to handle stream ciphers like RC4 in ESP. In particular, where does the stream offset go? I can think of three possibilities: 1. Abuse the IV field. The draft remains unchanged. 2. Consider the stream offset field part of the payload data, as suggested by Steve Bellovin. The draft remains unchanged. 3. Rename the IV field. (Algorithm Specific Data?) A simple textual substitution in the draft and in the drafts for the individual encryption algorithms. 4. Consider the IV and stream offset fields part of the payload data, as suggested by Steve Bellovin. This is a more substantive change, and also affects the drafts for the individual encryption algorithms. But it would simplify ESP by eliminating an optional variable-length field. It would also generalize ESP to accommodate any encryption algorithm with or without any algorithm-specific data at all. What do you think? Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@border.com Fax 1 416 813 2001 From owner-ipsec Mon Apr 14 16:45:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA28844 for ipsec-outgoing; Mon, 14 Apr 1997 16:45:41 -0400 (EDT) Date: Mon, 14 Apr 1997 16:51:13 -0400 From: Ran Canetti Message-Id: <9704142051.AA26905@ornavella.watson.ibm.com> To: ho@earth.hpc.org, sommerfeld@apollo.hp.com Subject: Re: Slicing and Dicing in new-esp Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Hilarie, >BTW, it's not obvious to me that having encryption and integrity use >the same key blob is so very awful. I must strongly differ on that issue. As was pointed out several times before, using the same keying material for two different purposes (or even for the same purpose but with two different algorithms) can result in totally insecure systems, even if the individual components are secure. A "quintessential" example is DES-CBC for encryption and DES-CBC-MAC for authentication. If you use the same key for both then your authentication is useless: the MAC output will always be identical to the last block of the ciphertext. Thus an attacker can change the ciphertext at wish. More generally, different algorithms may have weakenesses on different parts of the key, in a way that makes the combination insecure. For instance, assume the same key k is used for two imaginary algorithms A and B. Algorithm A leaks the first half of its key, but is still secure based on the second half. Algorithm B leaks the second half of its key, but is still secure based on the first half. If, however, you use the same key for both A and B then the entire key is leaked and both algorithms become insecure... Ran Canetti From owner-ipsec Mon Apr 14 17:54:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA29284 for ipsec-outgoing; Mon, 14 Apr 1997 17:45:33 -0400 (EDT) Date: Mon, 14 Apr 1997 17:51:04 -0400 From: Ran Canetti Message-Id: <9704142151.AA26313@ornavella.watson.ibm.com> To: ipsec@tis.com, sommerfeld@apollo.hp.com Subject: Re: Slicing and Dicing in new-esp Sender: owner-ipsec@ex.tis.com Precedence: bulk > > The consensus on slice & dice at the meeting today was that transforms > get one key, and are responsible for dividing the "key blob" between > the various uses they have for it. > > In the case of new-esp, we have a hierarchical arrangement, with ESP > in the middle, key management above, and algorithms beneath; the > new-esp document really defines both ESP and a "meta" transform. > > I presume that the new-esp meta-transform gets a (single) key blob > from "above" and needs to break it up and pass "key blobs" down into > the algorithms which plug into it. > > Now, there are certain, obvious to a non-cryptographer, problems with > passing the exact same blob to both algorithms. I believe that the > right thing to do here is to specify that new-ESP is responsible for > dividing the blob into two pieces and feeding one to the encryption > algorithm and the other into the integrity algorithm; the individual > algorithms are resposible for any relevant algorithmic-specific key > processing. > > - Bill > I concur. This is the "cryptographically right" way to do it. A transform gets as much keying material as it needs from the key exchange module, and is responsible to slice it and use it in the correct way. In the case of ESP this means to partition the keying material to two DISJOINT parts, hand one part to the authentication algorithm and the other part to the encryption algorithm. Ran From owner-ipsec Mon Apr 14 19:22:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA29694 for ipsec-outgoing; Mon, 14 Apr 1997 19:19:00 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <97Apr14.161245edt.11650@janus.border.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 14 Apr 1997 19:17:17 -0400 To: Norman Shulman From: Stephen Kent Subject: Re: ESP with stream ciphers Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Norm, I agree with Steve Bellovin's suggestion that we should view the IV as the beginning of the payload, since each encryption algorithm mode will "know" whether an IV is explicitly present, or not, and how big it is, etc. This tact was adopted in some other security protocols, e.g., the IEEE SDE protocol, while others opted for an explicit IV field. In an effort to simplify the format and minimize optional variable length fields, I'm in favor of adopoting Steve's suggestion. In this vein, a stream cipher offset(or an IV for a stream cipher) could also appear as the beginning of an encrypted payload. If there are no objections, I'll plan to make these changes to the next rev of the ESP spec. Steve From owner-ipsec Tue Apr 15 00:03:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA01010 for ipsec-outgoing; Tue, 15 Apr 1997 00:01:30 -0400 (EDT) Date: Tue, 15 Apr 1997 00:05:35 -0400 From: Ran Canetti Message-Id: <9704150405.AA24745@ornavella.watson.ibm.com> To: ipsec@tis.com Subject: A pothole in ISAKMP/Oakley Cc: carrel@ipsec.org, dharkins@cisco.com, pau@watson.ibm.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, Pau-Chen and I just stumbled over a pretty significant security pothole in the ISAKMP/Oakley draft. I believe it's important enough to mandate the appropriate change, as annoying as it may be. Luckily, the required change is small. Assume that the same instance of quickmode is used to create two different SA's (say, one for AH and one for ESP). The current method for deriving KEYMAT allows unsuspecting implementations to have the same KEYMAT for the two SA's. This situation - two SA's with the same KEYMAT - is a cryptographic show stopper. (See my note to the list from earlier today about the hazards of using the same key for two different algorithms/purposes.) Details: The problem: Currently, KEYMAT is calculated as follows: (page 15) KEYMAT = prf(SKEYID_d, SPI | Ni | Nr) or KEYMAT = prf(SKEYID_d, g^xy | SPI | Ni | Nr) In either case, the only field that makes the KEYMAT of the two SA's different is the SPI. However, do the SPIs of the two SA's need to be different? Here the opinions differ... ISAKMP draft 07 (section 2.1) says: "Each security protocol has its own ``SPI-space''. A (security protocol, SPI) pair may uniquely identify an SA. Depending on the DOI, additional information (e.g. host address) may be necessary to identify an SA." The IPSEC architecture document says: "The combination of an SPI and a destination address uniquely identifies a simplex security association". In practice, we have actually encountered during interop tests an implementation where two such SA's had the same SPI! The fix: The goal is, as usual, to avoid having the security of the protocol rely on architectural issues such as whether the SPI's should be different or not. Specifically, A relatively simple fix is to add protocol-ID as an additional input to the prf in the computation of KEYMAT. This way, we will be assured that the inputs to the prf differ between the two SA's, thus the two SA's will have cryptographically independent values of KEYMAT. That is, define KEYMAT = prf(SKEYID_d, protocol-ID | SPI | Ni | Nr) or KEYMAT = prf(SKEYID_d, protocol-ID | g^xy | SPI | Ni | Nr) Ran Canetti From owner-ipsec Tue Apr 15 08:46:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA03934 for ipsec-outgoing; Tue, 15 Apr 1997 08:41:19 -0400 (EDT) Message-Id: <3.0.1.32.19970415084450.00df7c0c@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 15 Apr 1997 08:44:50 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: Re: ESP with stream ciphers In-Reply-To: References: <97Apr14.161245edt.11650@janus.border.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Exactly what will this look like? I guess the current scheme is: <8 byte IV> and the new scheme will be: <8 byte IV> -OR- So... Am I correct this stream offset is a 32-bit animal not a 64-bit animal? We need 8 byte IV's for DES and 3DES, right? Not 24 bytes for 3DES? Why do we need a stream offset anyway? I assume that, since it's a stream, the data order is significant, and if you get packets out of order you have to be careful how you feed them into the decryption logic. But wouldn't the IP header give you enough information to detect out-of-order anyway? Also, regardless of how you determine stream offset, what are you going to do when you get bytes out of order? At 07:17 PM 4/14/97 -0400, you wrote: >Norm, > > I agree with Steve Bellovin's suggestion that we should view the IV >as the beginning of the payload, since each encryption algorithm mode will >"know" whether an IV is explicitly present, or not, and how big it is, etc. >This tact was adopted in some other security protocols, e.g., the IEEE SDE >protocol, while others opted for an explicit IV field. In an effort to >simplify the format and minimize optional variable length fields, I'm in >favor of adopoting Steve's suggestion. In this vein, a stream cipher >offset(or an IV for a stream cipher) could also appear as the beginning of >an encrypted payload. If there are no objections, I'll plan to make these >changes to the next rev of the ESP spec. > >Steve > > > > From owner-ipsec Tue Apr 15 09:49:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA04377 for ipsec-outgoing; Tue, 15 Apr 1997 09:48:05 -0400 (EDT) Date: Tue, 15 Apr 1997 09:50:44 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704151350.JAA26384@earth.hpc.org> To: canetti@watson.ibm.com Cc: ipsec@tis.com, carrel@ipsec.org, dharkins@cisco.com, pau@watson.ibm.com In-reply-to: Yourmessage <199704150414.VAA27630@baskerville.CS.Arizona.EDU> Subject: Re: A pothole in ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk The basic problem was noted in January, and the fragility of the use of the SPI was also noted then. My preference is to include a state variable with SKEYID that is an instance number; the state variable gets incremented every time keying material is generated, and the keying material depends on the variable. I will note, however, that if the SPI's are pseudo-randomly generated, as is required by the spec, then the probability of using the same SPI twice should be extremely low. So the implementations that revealed this problem were defective. Hilarie From owner-ipsec Tue Apr 15 10:53:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA04822 for ipsec-outgoing; Tue, 15 Apr 1997 10:52:13 -0400 (EDT) Date: Tue, 15 Apr 1997 10:57:20 -0400 From: Norman Shulman X-Sender: norm@rafael.rnd.border.com To: Rodney Thayer cc: ipsec@tis.com Subject: Re: ESP with stream ciphers In-Reply-To: <3.0.1.32.19970415084450.00df7c0c@pop3.pn.com> Message-Id: <97Apr15.105340edt.11653@janus.border.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Tue, 15 Apr 1997, Rodney Thayer wrote: > Am I correct this stream offset is a 32-bit animal not a 64-bit animal? The first draft for stream ciphers specified a 64 bit offset. The second draft specifies an offset of 32 or 64 bits, with 32 bits recommended. > We need 8 byte IV's for DES and 3DES, right? Not 24 bytes for 3DES? DES requires a 64 bit IV, but for ESP a 32 bit folded IV is often transmitted. Early 3DES drafts require a 64 bit IV (outer, not inner). > Why do we need a stream offset anyway? I assume that, since it's a stream, > the data order is significant, > and if you get packets out of order you have to be careful how you feed > them into the decryption > logic. But wouldn't the IP header give you enough information to detect > out-of-order anyway? > Also, regardless of how you determine stream offset, what are you going to > do when you get > bytes out of order? The ciphers are stream ciphers, but IP has no concept of streams. Stream offsets are needed by stream ciphers for the same reason that IVs are needed by chained block ciphers: so that packets can be decrypted even if they are received out of order. Using the ip_id field to detect out-of-order packets is problematic for a couple of reasons. First, this value is unique for all IP packets sent by a host, so on any given connection it is not necessarily contiguous. This complicates window management. Second, this is a 16-bit value initialized from the system clock, so you would have to deal with wraparound. Given an out-of-order packet with a stream offset, what you do depends on the cipher. For SEAL, the pad can be computed directly. RC4 can move forward or backward in the key stream; cacheing state can save work here. Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@border.com Fax 1 416 813 2001 From owner-ipsec Tue Apr 15 11:03:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA04934 for ipsec-outgoing; Tue, 15 Apr 1997 11:03:45 -0400 (EDT) Date: Tue, 15 Apr 97 08:08:00 PDT From: John H Wilson Message-ID: To: ipsec@tis.com Subject: Re[2]: ESP with stream ciphers Sender: owner-ipsec@ex.tis.com Precedence: bulk Text item: Rodney Thayer wrote: > > >So... >Am I correct this stream offset is a 32-bit animal not a 64-bit animal? I really think we ought to go with 64 bits. Video conferencing streams could persist for some time at quite a high bit rate. 2^32 just doesn't seem enough to me. (Unless you could negotiate 32 v 64). >Also, regardless of how you determine stream offset, what are you going to >do when you get bytes out of order? Did you mean packets out of order? In the case of audio/video streams, reset the algorithm to that bit position, and recover from the missing/late packet(s). John Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Precedence: bulk Sender: owner-ipsec@ex.tis.com Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 References: <97Apr14.161245edt.11650@janus.border.com> In-Reply-To: Subject: Re: ESP with stream ciphers From: Rodney Thayer To: ipsec@tis.com Date: Tue, 15 Apr 1997 08:44:50 -0400 X-Mailer: Windows Eudora Light Version 3.0.1 (32) X-Sender: rodney@pop3.pn.com Message-Id: <3.0.1.32.19970415084450.00df7c0c@pop3.pn.com> Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA039 34 for ipsec-outgoing; Tue, 15 Apr 1997 08:41:19 -0400 (EDT) Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mailbag .jf.intel.com (8.8.5/8.7.3) with ESMTP id HAA07610 for ; Tue, 15 Apr 1997 07:42:44 -0700 (PDT) Received: from mailbag.jf.intel.com (mailbag.jf.intel.com [134.134.248.4]) by re lay.jf.intel.com (8.7.6/8.7.3) with ESMTP id HAA22623 for ; Tue, 15 Apr 1997 07:40:25 -0700 (PDT) Return-Path: owner-ipsec@portal.ex.tis.com From owner-ipsec Tue Apr 15 11:09:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA04966 for ipsec-outgoing; Tue, 15 Apr 1997 11:08:48 -0400 (EDT) From: pau@watson.ibm.com Date: Tue, 15 Apr 1997 11:20:18 -0400 Message-Id: <9704151520.AA21376@secpwr.watson.ibm.com> To: canetti@watson.ibm.com, ho@earth.hpc.org Subject: Re: A pothole in ISAKMP/Oakley Cc: ipsec@tis.com, carrel@ipsec.org, dharkins@cisco.com, pau@watson.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Md5: YezaRzTis0oi+pnfJrzO/w== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id LAA04963 Sender: owner-ipsec@ex.tis.com Precedence: bulk > From ho@earth.hpc.org Tue Apr 15 10:15:11 1997 > Date: Tue, 15 Apr 1997 09:50:44 -0400 > From: ho@earth.hpc.org (Hilarie Orman) > Message-Id: <199704151350.JAA26384@earth.hpc.org> > To: canetti@watson.ibm.com > Cc: ipsec@tis.com, carrel@ipsec.org, dharkins@cisco.com, pau@watson.ibm.com > In-Reply-To: Yourmessage <199704150414.VAA27630@baskerville.CS.Arizona.EDU> > Subject: Re: A pothole in ISAKMP/Oakley > Content-Length: 563 > Status: RO > Hilarie : > The basic problem was noted in January, and the fragility of the use > of the SPI was also noted then. My preference is to include a state > variable with SKEYID that is an instance number; the state variable > gets incremented every time keying material is generated, and the > keying material depends on the variable. This may require some tight synchorization between I and R to keep the instance number in sync. I prefer not to do that. > > I will note, however, that if the SPI's are pseudo-randomly generated, > as is required by the spec, then the probability of using the same SPI > twice should be extremely low. So the implementations that revealed > this problem were defective. Yes. But the fix suggested in Ran's msg make the protocol immune to such "defect". Besides, there is value to use non pseudo-random SPI's for ESP and AH SA's (such as array indices to speed up SA look-up); I agree that for ISAKMP SA's the SPI's (cookies) should be pseudo-random to counter clogging attacks. > > Hilarie Regards, Pau-Chen From owner-ipsec Tue Apr 15 11:27:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA05121 for ipsec-outgoing; Tue, 15 Apr 1997 11:27:26 -0400 (EDT) From: Uri Blumenthal Message-Id: <9704151532.AA244730@hawpub.watson.ibm.com> Subject: Re: ESP with stream ciphers To: norm@border.com (Norman Shulman) Date: Tue, 15 Apr 1997 11:32:48 -0400 (EDT) Cc: rodney@sabletech.com, ipsec@tis.com In-Reply-To: <97Apr15.105340edt.11653@janus.border.com> from "Norman Shulman" at Apr 15, 97 10:57:20 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Norman Shulman says: > On Tue, 15 Apr 1997, Rodney Thayer wrote: > > We need 8 byte IV's for DES and 3DES, right? Not 24 bytes for 3DES? > > DES requires a 64 bit IV, but for ESP a 32 bit folded IV is often transmitted. > Early 3DES drafts require a 64 bit IV (outer, not inner). 3DES is secure only if used as a black-box engine (see Biham's paper). That means - no inner feedbacks. That in turn means - only one IV for the first DES is needed. It has to be 64 bits, and it can be folded for transmission to 32 bits, just like the good ESP draft says. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Tue Apr 15 12:38:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA05593 for ipsec-outgoing; Tue, 15 Apr 1997 12:37:05 -0400 (EDT) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199704151642.JAA14702@kebe.eng.sun.com> Subject: Re: A pothole in ISAKMP/Oakley To: ho@earth.hpc.org (Hilarie Orman) Date: Tue, 15 Apr 1997 09:42:43 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <199704151350.JAA26384@earth.hpc.org> from "Hilarie Orman" at Apr 15, 97 09:50:44 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > I will note, however, that if the SPI's are pseudo-randomly generated, > as is required by the spec, then the probability of using the same SPI > twice should be extremely low. So the implementations that revealed > this problem were defective. Hilarie is right. SPI values must be {pseudo-,}randomly generated, if I remember the specs correctly. Implementations that do otherwise are probably broken. Dan From owner-ipsec Tue Apr 15 13:14:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA05851 for ipsec-outgoing; Tue, 15 Apr 1997 13:13:25 -0400 (EDT) From: pau@watson.ibm.com Date: Tue, 15 Apr 1997 13:25:16 -0400 Message-Id: <9704151725.AA22888@secpwr.watson.ibm.com> To: ho@earth.hpc.org, Dan.McDonald@Eng.sun.com Subject: Re: A pothole in ISAKMP/Oakley Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Md5: s6Gwv0HOKs6iwmnFRSQuGw== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id NAA05848 Sender: owner-ipsec@ex.tis.com Precedence: bulk > From owner-ipsec@portal.ex.tis.com Tue Apr 15 12:57:42 1997 > From: Dan.McDonald@Eng.sun.com (Dan McDonald) > Message-Id: <199704151642.JAA14702@kebe.eng.sun.com> > Subject: Re: A pothole in ISAKMP/Oakley > To: ho@earth.hpc.org (Hilarie Orman) > Date: Tue, 15 Apr 1997 09:42:43 -0700 (PDT) > Cc: ipsec@tis.com > In-Reply-To: <199704151350.JAA26384@earth.hpc.org> from "Hilarie Orman" at Apr 15, 97 09:50:44 am > X-Mailer: ELM [version 2.4 PL25] > Mime-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit > Sender: owner-ipsec@ex.tis.com > Precedence: bulk > Content-Length: 415 > Status: RO > > > I will note, however, that if the SPI's are pseudo-randomly generated, > > as is required by the spec, then the probability of using the same SPI > > twice should be extremely low. So the implementations that revealed > > this problem were defective. > > Hilarie is right. SPI values must be {pseudo-,}randomly generated, if I > remember the specs correctly. Implementations that do otherwise are probably > broken. Dan, the spec does say so. But if an implementation uses a montonically increasing counter to generate SPI's for ESP and AH, it can interop with others. So I think it is worthwhile to put in a safeguard. Also, I would like to emphasize that Ran's msg is about QUICK Mode KEYMAT derivation in Phase 2. It is NOT about Phase 1. > Dan > Regards, Pau-Chen From owner-ipsec Tue Apr 15 14:22:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA06317 for ipsec-outgoing; Tue, 15 Apr 1997 14:21:08 -0400 (EDT) Date: Tue, 15 Apr 1997 14:23:33 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704151823.OAA04580@earth.hpc.org> To: pau@watson.ibm.com Cc: Dan.McDonald@Eng.sun.com, canetti@watson.ibm.com, ipsec@tis.com In-reply-to: Yourmessage <9704151748.AA23438@secpwr.watson.ibm.com> Subject: Re: A pothole in ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk > Also, it is possible to run a pseudo-random generator once, and use the > new random value as SPI for both ESP and AH (since the spec also says > they > have separate SPI-spaces, see section 2.1 of ISAKMP draft 7). Is this > broken ? > I guess it is a border-line case. The requirement for pseudo-random SPI's was not motivated by key management concerns, but rather to protect against denial of service attacks, I thought. > Will it interop, I think so. I didn't realize that the IETF had strict constructionists! Hilarie From owner-ipsec Tue Apr 15 14:33:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA06528 for ipsec-outgoing; Tue, 15 Apr 1997 14:33:18 -0400 (EDT) Message-Id: <199704151838.LAA09674@fluffy.cisco.com> To: pau@watson.ibm.com cc: ho@earth.hpc.org, Dan.McDonald@Eng.sun.com, ipsec@tis.com Subject: Re: A pothole in ISAKMP/Oakley In-reply-to: Your message of "Tue, 15 Apr 1997 13:25:16 EDT." <9704151725.AA22888@secpwr.watson.ibm.com> Date: Tue, 15 Apr 1997 11:38:38 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > I will note, however, that if the SPI's are pseudo-randomly generated, > > > as is required by the spec, then the probability of using the same SPI > > > twice should be extremely low. So the implementations that revealed > > > this problem were defective. > > > > Hilarie is right. SPI values must be {pseudo-,}randomly generated, if I > > remember the specs correctly. Implementations that do otherwise are probably > > broken. > > Dan, the spec does say so. But if an implementation uses a montonically > increasing counter to generate SPI's for ESP and AH, it can interop with > others. So I think it is worthwhile to put in a safeguard. > > Also, I would like to emphasize that Ran's msg is about QUICK Mode > KEYMAT derivation in Phase 2. It is NOT about Phase 1. Correct me if I'm wrong, but there's no longer any security basis for having the Phase 2 SPI's be pseudo-randomly generated. In fact, there were implementations at the IPSEC bake-off that used monotonically increasing SPI's. This argues for fixing this in the protocol. On the other hand, this is not a problem if you're doing the combined ESP for authentication, as you wouldn't then have a separate SA for an AH key. I think this is the normal case. I would like to reitterate what Douglas Maughan pointed out at the implementor's discussion last week, which is to remind everyone that the ISAKMP framework is specifically designed to accomodate multiple and divergent key exchange protocols. This allows us to cleanly define a new key exchange identifier in the future with fixes for "problems" like this. This might also include the performance improvements requested by Hugo. I don't think this is worth reopening the document to fix. I'd like to see it corrected in the next rev of the protocol, which should have a new key exchange identifier in the IPSEC DOI. In the mean time, the suggested use of pseudo-randomly generated Phase 2 SPI's remains a useful recommendation. Derrell, last seen rooting around his office for the Nomex suit... From owner-ipsec Tue Apr 15 15:16:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA06822 for ipsec-outgoing; Tue, 15 Apr 1997 15:15:40 -0400 (EDT) From: pau@watson.ibm.com Date: Tue, 15 Apr 1997 15:27:04 -0400 Message-Id: <9704151927.AA22368@secpwr.watson.ibm.com> To: pau@watson.ibm.com, ho@earth.hpc.org Subject: Re: A pothole in ISAKMP/Oakley Cc: Dan.McDonald@Eng.sun.com, canetti@watson.ibm.com, ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Md5: dTSiU+E84Wkotzl+GVVvMg== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id PAA06819 Sender: owner-ipsec@ex.tis.com Precedence: bulk > From ho@earth.hpc.org Tue Apr 15 14:32:44 1997 > Date: Tue, 15 Apr 1997 14:23:33 -0400 > From: ho@earth.hpc.org (Hilarie Orman) > Message-Id: <199704151823.OAA04580@earth.hpc.org> > To: pau@watson.ibm.com > Cc: Dan.McDonald@Eng.Sun.COM, canetti@watson.ibm.com, ipsec@tis.com > In-Reply-To: Yourmessage <9704151748.AA23438@secpwr.watson.ibm.com> > Subject: Re: A pothole in ISAKMP/Oakley > Content-Length: 537 > Status: RO > > > Also, it is possible to run a pseudo-random generator once, and use the > > new random value as SPI for both ESP and AH (since the spec also says > > they > > have separate SPI-spaces, see section 2.1 of ISAKMP draft 7). Is this > > broken ? > > I guess it is a border-line case. > > The requirement for pseudo-random SPI's was not motivated by key management > concerns, but rather to protect against denial of service attacks, I thought. You are right. But since Quick Mode Exchange is proteted (encrypted and authenticated) by the phase 1 ISAKMP SA, clogging attack should not be a big problem. Ran's msg is about OAKLEY Quick Mode KEYMAT derivation, NOT phase 1 main mode. Regards, Pau-Chen From owner-ipsec Tue Apr 15 15:39:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA06997 for ipsec-outgoing; Tue, 15 Apr 1997 15:38:30 -0400 (EDT) Date: Tue, 15 Apr 1997 15:41:03 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704151941.PAA06920@earth.hpc.org> To: pau@watson.ibm.com Cc: ipsec@tis.com, canetti@watson.ibm.com, Dan.McDonald@Eng.sun.com In-reply-to: Yourmessage <9704151927.AA22368@secpwr.watson.ibm.com> Subject: Re: A pothole in ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk > You are right. But since Quick Mode Exchange is proteted > (encrypted and authenticated) by the phase 1 ISAKMP SA, > clogging attack should not be a big problem. Maybe we are talking about different attacks. The requirement for AH and ESP SPI generation was there before there was key management. We should ask why. I'd guess that the worry has been that an attacker could predict the SPI sequence and insert bogus messages with valid SPI's into the traffic stream, forcing the recipient to go through at least the trouble of checking the hash if not also decrypting. Hilarie From owner-ipsec Tue Apr 15 15:43:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA07062 for ipsec-outgoing; Tue, 15 Apr 1997 15:43:03 -0400 (EDT) Message-Id: <2.2.32.19970415195448.00ba9240@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Apr 1997 15:54:48 -0400 To: Ran Canetti From: Naganand Doraswamy Subject: Re: Slicing and Dicing in new-esp Cc: ipsec@tis.com, sommerfeld@apollo.hp.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran > >I concur. This is the "cryptographically right" way to do it. >A transform gets as much keying material as it needs from the >key exchange module, and is responsible to slice it and use >it in the correct way. In the case of ESP this means to >partition the keying material to two DISJOINT parts, >hand one part to the authentication algorithm and the other part to >the encryption algorithm. > > This is what we agreed in the working group. The transform knows how many bits it requires. The transforms need to define how they are going to split the keying material into disjoint parts. They may have to check for weak keys etc. --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Tue Apr 15 15:46:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA07133 for ipsec-outgoing; Tue, 15 Apr 1997 15:46:37 -0400 (EDT) From: pau@watson.ibm.com Date: Tue, 15 Apr 1997 15:58:33 -0400 Message-Id: <9704151958.AA22946@secpwr.watson.ibm.com> To: piper@cisco.com Subject: Re: A pothole in ISAKMP/Oakley Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Md5: Tb/P7lanKZnbuqvuYcqbWg== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id PAA07130 Sender: owner-ipsec@ex.tis.com Precedence: bulk > From piper@cisco.com Tue Apr 15 14:45:12 1997 > Message-Id: <199704151838.LAA09674@fluffy.cisco.com> > To: pau@watson.ibm.com > Cc: ho@earth.HPC.ORG, Dan.McDonald@eng.sun.com, ipsec@tis.com > Subject: Re: A pothole in ISAKMP/Oakley > In-Reply-To: Your message of "Tue, 15 Apr 1997 13:25:16 EDT." <9704151725.AA22888@secpwr.watson.ibm.com> > Date: Tue, 15 Apr 1997 11:38:38 -0700 > From: Derrell Piper > Content-Length: 2040 > Status: RO > > > > > I will note, however, that if the SPI's are pseudo-randomly generated, > > > > as is required by the spec, then the probability of using the same SPI > > > > twice should be extremely low. So the implementations that revealed > > > > this problem were defective. > > > > > > Hilarie is right. SPI values must be {pseudo-,}randomly generated, if I > > > remember the specs correctly. Implementations that do otherwise are probably > > > broken. > > > > Dan, the spec does say so. But if an implementation uses a montonically > > increasing counter to generate SPI's for ESP and AH, it can interop with > > others. So I think it is worthwhile to put in a safeguard. > > > > Also, I would like to emphasize that Ran's msg is about QUICK Mode > > KEYMAT derivation in Phase 2. It is NOT about Phase 1. > Derrell: > Correct me if I'm wrong, but there's no longer any security basis for > having the Phase 2 SPI's be pseudo-randomly generated. In fact, there were > implementations at the IPSEC bake-off that used monotonically increasing > SPI's. This argues for fixing this in the protocol. > > On the other hand, this is not a problem if you're doing the combined ESP > for authentication, as you wouldn't then have a separate SA for an AH key. > I think this is the normal case. AH still has its value in that it protects the "invariant" parts of IP header. I remember there was a (big) debate on this in the ipsec list and we end up with the AH we have today. > > I would like to reitterate what Douglas Maughan pointed out at the > implementor's discussion last week, which is to remind everyone that the > ISAKMP framework is specifically designed to accomodate multiple and > divergent key exchange protocols. This allows us to cleanly define a new > key exchange identifier in the future with fixes for "problems" like this. > This might also include the performance improvements requested by Hugo. > > I don't think this is worth reopening the document to fix. I'd like to see > it corrected in the next rev of the protocol, which should have a new key > exchange identifier in the IPSEC DOI. In the mean time, the suggested use > of pseudo-randomly generated Phase 2 SPI's remains a useful recommendation. If this were a change for performance, I think we should wait for the next rev.. But it is really a change to close a potential security loop hole. This is a 2-line change to the ISAKMP-OAKLEY doc. As for the code, the current doc requires the code to take the SPI value from the PROPOSAL payload header when computing Quick Mode KEYMAT. The proposed change requires the code to also take the "Protocol-ID" value from the SAME PROPOSAL payload header when computing Quick Mode KEYMAT. I don't think that is a difficult change. > > Derrell, last seen rooting around his office for the Nomex suit... Regards, Pau-Chen From owner-ipsec Tue Apr 15 15:58:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA07216 for ipsec-outgoing; Tue, 15 Apr 1997 15:58:47 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199704151642.JAA14702@kebe.eng.sun.com> References: <199704151350.JAA26384@earth.hpc.org> from "Hilarie Orman" at Apr 15, 97 09:50:44 am Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Apr 1997 16:02:15 -0400 To: ipsec@tis.com From: Stephen Kent Subject: Re: A pothole in ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, I'm somehwat at fault here. In re-writing the AH and ESP specs I re-worded the brief description of SPIs to deemphasize any notion of randomness for secruity purposes, as there was no documentation explaining the motivation for such selection in the previous documents and those documents merely hinted that the SPis should be "arbitrary," if I recall correctly. I presume that the anti-D0S argument put forth here is based on the notion that one can very quickly reject traffic that claims to be AH or ESP is there is no matching SPI, rather than expending any effort for further processing. If so, we need to be explicit about that in our documentation, i.e., provide a brief statement of motivation as well as a requirement specification. I guess that the threat model that motivates this technique assumes that the attacker has no passive wiretap capability, which we also need to mention in the architecture document. Note that requiring pseudo-random SPIs does have potentially adverse performance implications, e.g., simple index SPIs are outlawed and that makes table lookups harder. So, we should be convinced that making this a requirement is worthwhile, e.g., we believe in the threat model I mentioned, before insisting on this characteristic for SPIs. Steve From owner-ipsec Tue Apr 15 16:00:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07237 for ipsec-outgoing; Tue, 15 Apr 1997 16:00:17 -0400 (EDT) Date: Tue, 15 Apr 1997 16:06:04 -0400 Message-Id: <9704152006.AA29509@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: pau@watson.ibm.com Cc: ho@earth.hpc.org, Dan.McDonald@Eng.sun.com, ipsec@tis.com In-Reply-To: pau@watson.ibm.com's message of Tue, 15 Apr 1997 13:25:16 -0400, <9704151725.AA22888@secpwr.watson.ibm.com> Subject: Re: A pothole in ISAKMP/Oakley Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk From: pau@watson.ibm.com Date: Tue, 15 Apr 1997 13:25:16 -0400 Dan, the spec does say so. But if an implementation uses a montonically increasing counter to generate SPI's for ESP and AH, it can interop with others. So I think it is worthwhile to put in a safeguard. It sounds like testing for a monotonically increasing counter would be a good thing to put into a conformance test suite; if a implementation dues that, it should be considered broken. Is this important enough that we want to put more explicit words in the spec? (I will note that in general, this is really about how much we trust the intelligence and/or competence of the implementors that come after us. There are certainly those who believe we shouldn't trust their competence at all --- although if that's really true, the situation is probably hopeless.) - Ted From owner-ipsec Tue Apr 15 16:09:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07304 for ipsec-outgoing; Tue, 15 Apr 1997 16:08:59 -0400 (EDT) Message-Id: <199704152013.QAA02665@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: ho@earth.hpc.org (Hilarie Orman) Cc: pau@watson.ibm.com, ipsec@tis.com, canetti@watson.ibm.com, Dan.McDonald@Eng.sun.com Subject: Re: A pothole in ISAKMP/Oakley In-Reply-To: ho's message of Tue, 15 Apr 1997 15:41:03 -0400. <199704151941.PAA06920@earth.hpc.org> Date: Tue, 15 Apr 1997 16:13:49 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > Maybe we are talking about different attacks. The requirement for AH > and ESP SPI generation was there before there was key management. We > should ask why. I'd guess that the worry has been that an attacker > could predict the SPI sequence and insert bogus messages with valid > SPI's into the traffic stream, forcing the recipient to go through at > least the trouble of checking the hash if not also decrypting. I'll re-state that to clarify my view of the benefit: Random SPI's serve a similar function as cookies: they make it harder to do an off-path active attack against someone not in the communication path between the peers. Given that certain off-path active attacks (e.g., SYN floods) are known to be in the bag of tricks in the cracker community, I think resistance to such threats should be considered fairly important. An ESP/AH implementation which does sequential SPI generation is asking for trouble. It's probably OK to kludge it while you're coming up to speed, but it should take all of a dozen lines of code in an implementation to do random SPI generation. (BTW, I hope the implementations doing sequential assignment are doing collision checks against manually-configured SPI's while they're at it..). - Bill From owner-ipsec Tue Apr 15 16:17:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07369 for ipsec-outgoing; Tue, 15 Apr 1997 16:17:35 -0400 (EDT) Message-Id: <3.0.1.32.19970415160749.0073f58c@world.std.com> X-Sender: dpj@world.std.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 15 Apr 1997 16:07:49 -0400 To: ipsec@tis.com, carrel@ipsec.org, dharkins@cisco.com, ho@earth.hpc.org From: "David P. Jablon" Subject: Another pothole in ISAKMP/Oakley In-Reply-To: <199704151350.JAA26384@earth.hpc.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Another pothole of note in ISAKMP is Diffie-Hellman small-subgroup confinement. Although ISAKMP refers to X9.42, which I believe will have a description of how to avoid the problem, it should also probably be mentioned in some IETF document relevant to DH in ISAKMP. There are just too many published descriptions of DH that fail to mention the problem, so that there's a good chance of trapping an unwary implementor. -- David From owner-ipsec Tue Apr 15 16:21:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07412 for ipsec-outgoing; Tue, 15 Apr 1997 16:21:08 -0400 (EDT) From: pau@watson.ibm.com Date: Tue, 15 Apr 1997 16:32:37 -0400 Message-Id: <9704152032.AA23062@secpwr.watson.ibm.com> To: ho@earth.hpc.org Subject: Re: A pothole in ISAKMP/Oakley Cc: ipsec@tis.com, canetti@watson.ibm.com, Dan.McDonald@Eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Md5: msLW7lllUmNfbpEjjJyA3Q== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id QAA07409 Sender: owner-ipsec@ex.tis.com Precedence: bulk > From owner-ipsec@portal.ex.tis.com Tue Apr 15 15:55:29 1997 > Date: Tue, 15 Apr 1997 15:41:03 -0400 > From: ho@earth.hpc.org (Hilarie Orman) > Message-Id: <199704151941.PAA06920@earth.hpc.org> > To: pau@watson.ibm.com > Cc: ipsec@tis.com, canetti@watson.ibm.com, Dan.McDonald@Eng.sun.com > In-Reply-To: Yourmessage <9704151927.AA22368@secpwr.watson.ibm.com> > Subject: Re: A pothole in ISAKMP/Oakley > Sender: owner-ipsec@ex.tis.com > Precedence: bulk > Content-Length: 584 > Status: RO > > > You are right. But since Quick Mode Exchange is proteted > > (encrypted and authenticated) by the phase 1 ISAKMP SA, > > clogging attack should not be a big problem. > > Maybe we are talking about different attacks. The requirement for AH > and ESP SPI generation was there before there was key management. We > should ask why. Maybe we have been. But let's focus on the phase 2 OAKLEY Quick mode in this msg. > > I'd guess that the worry has been that an attacker > could predict the SPI sequence and insert bogus messages with valid > SPI's into the traffic stream, forcing the recipient to go through at > least the trouble of checking the hash if not also decrypting. Correct me if I am wrong. But my understanding of the OAKLEY quick mode as defined in section 5.4 of is like this : 1. The cookies in the ISAKMP msg header are the I-cookie and R-cookie of the phase-1 SA which is protecting the quick mode exchange. 2. the SPI's for the would-be ESP and AH SA's are placed in their corresponding PROPOSAL payloads which are inside an SA payload. 3. A keyed-hash (HMAC) defined by the phase-1 SA is computed over the Quick mode payloads and the msg-ID in the ISAKMP msg header. 4. Everything, including the keyed-hash digest but excluding the ISAKMP msg header, is ENCRYPTED through the phase-1 SA. Point 4 is worth noticing because the receiver of a Quick mode msg has to decrypt the msg then authenticate it (by veryfing the keyed hash) before doing anything else. I think the anit-clogging value of the SPI has vanished in this case. Since a relatively expensive decryption has always to be done first and an active attack is defeated by the keyed-hash (and of course also by the fresh nonces in the msgs). Regards, Pau-Chen > > Hilarie > From owner-ipsec Tue Apr 15 16:24:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07446 for ipsec-outgoing; Tue, 15 Apr 1997 16:24:09 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.1.32.19970415084450.00df7c0c@pop3.pn.com> References: <97Apr14.161245edt.11650@janus.border.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Apr 1997 16:30:19 -0400 To: Rodney Thayer From: Stephen Kent Subject: Re: ESP with stream ciphers Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney, As I mentioned in an earlier message to Norm, the size of the IV depends on the algorithm and mode. The DES specs (in terms of FIPS) call for 4 or 8 bytes IVs, depending on the mode. Some proposals for ESP transforms have implicit IVs (generated from other packet info), while others have also allowed for 4 or 8 byte ecplicit IVs. As for stream ciphers for which an offset is employed for crypto synch, the offset value size will vary depending on the algorithm. But, at least the size of these values is fixed as part of the SA negotiation process and not variable. Steve From owner-ipsec Tue Apr 15 16:36:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07511 for ipsec-outgoing; Tue, 15 Apr 1997 16:35:51 -0400 (EDT) Message-Id: <2.2.32.19970415204817.00bc9520@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Apr 1997 16:48:17 -0400 To: Bill Sommerfeld From: Naganand Doraswamy Subject: Re: A pothole in ISAKMP/Oakley Cc: ho@earth.hpc.org (Hilarie Orman), pau@watson.ibm.com, ipsec@tis.com, canetti@watson.ibm.com, Dan.McDonald@Eng.sun.com Sender: owner-ipsec@ex.tis.com Precedence: bulk >(BTW, I hope the implementations doing sequential assignment are doing >collision checks against manually-configured SPI's while they're at >it..). It will be good if implementations in addition to generating random SPI's also check for collision so that if the SPI is already allocated then we generate another random number till we find one that is unused. I do it in my implementation. --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Tue Apr 15 16:40:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07552 for ipsec-outgoing; Tue, 15 Apr 1997 16:39:55 -0400 (EDT) Date: Tue, 15 Apr 1997 16:45:22 -0400 From: Norman Shulman X-Sender: norm@rafael.rnd.border.com To: Hilarie Orman cc: ipsec@tis.com Subject: Re: A pothole in ISAKMP/Oakley In-Reply-To: <199704151941.PAA06920@earth.hpc.org> Message-Id: <97Apr15.164137edt.11659@janus.border.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Tue, 15 Apr 1997, Hilarie Orman wrote: > Maybe we are talking about different attacks. The requirement for AH > and ESP SPI generation was there before there was key management. We > should ask why. I'd guess that the worry has been that an attacker > could predict the SPI sequence and insert bogus messages with valid > SPI's into the traffic stream, forcing the recipient to go through at > least the trouble of checking the hash if not also decrypting. An attacker could only predict the SPI sequence if they could read the traffic stream. If they can do this, then they can see actual SPIs and use these in bogus packets. So why would AH and ESP require pseudorandom SPIs? (The current drafts just say that the SPI is an arbitrary value.) Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@border.com Fax 1 416 813 2001 From owner-ipsec Tue Apr 15 16:44:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07611 for ipsec-outgoing; Tue, 15 Apr 1997 16:43:58 -0400 (EDT) Message-Id: <199704152049.NAA10076@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: pau@watson.ibm.com Cc: piper@cisco.com, ipsec@tis.com Subject: Re: A pothole in ISAKMP/Oakley In-Reply-To: Your message of "Tue, 15 Apr 1997 15:58:33 EDT." <9704151958.AA22946@secpwr.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Apr 1997 13:49:47 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Pau-Chen, > This is a 2-line change to the ISAKMP-OAKLEY doc. > As for the code, the current doc requires the code to take the SPI value > from the PROPOSAL payload header when computing Quick Mode KEYMAT. > The proposed change requires the code to also take the "Protocol-ID" > value from the SAME PROPOSAL payload header when computing Quick Mode KEYMAT. > I don't think that is a difficult change. The size of the change isn't the issue, it's the merit of the change. Another way of looking at this is that we're changing the document to accomodate incorrect implementations (monotonically increasing a counter to generate a SPI is probably unwise regardless of this pothole). In that light, is this change meritorious? Personally, I'm in favor of this change but I'd like to note that the cement is drying on this document. If we have some consensus that this is really a problem that really needs to be addressed it can be changed, but I'd like to avoid what is becoming an even bigger problem: document creep. Dan. From owner-ipsec Tue Apr 15 16:56:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07671 for ipsec-outgoing; Tue, 15 Apr 1997 16:56:12 -0400 (EDT) Message-Id: <199704152101.OAA10099@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "David P. Jablon" Cc: ipsec@tis.com, carrel@ipsec.org, ho@earth.hpc.org Subject: Re: Another pothole in ISAKMP/Oakley In-Reply-To: Your message of "Tue, 15 Apr 1997 16:07:49 EDT." <3.0.1.32.19970415160749.0073f58c@world.std.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Apr 1997 14:01:10 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk David, Is this really a pothole in ISAKMP/Oakley? > Another pothole of note in ISAKMP is Diffie-Hellman > small-subgroup confinement. > > Although ISAKMP refers to X9.42, which I believe will > have a description of how to avoid the problem, it > should also probably be mentioned in some IETF document > relevant to DH in ISAKMP. There are just too many published > descriptions of DH that fail to mention the problem, so that > there's a good chance of trapping an unwary implementor. Are you suggesting a reference to X9.42 in the ISAKMP/Oakley document? Also, for the benefit of those of us who are not cryptographers, can you elaborate on the problem of "small sub-group confinement" and how ISAKMP/Oakley fails to address it? thanks, Dan. From owner-ipsec Tue Apr 15 17:18:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA07843 for ipsec-outgoing; Tue, 15 Apr 1997 17:18:32 -0400 (EDT) Date: Tue, 15 Apr 1997 17:21:01 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704152121.RAA10084@earth.hpc.org> To: dharkins@cisco.com Cc: dpj@world.std.com, carrel@ipsec.org, ipsec@tis.com In-reply-to: Yourmessage <199704152101.OAA10099@dharkins-ss20> Subject: Re: Another pothole in ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk wrt to the subgroup question ... If one is using new group mode, one might be advised to acquire some expertise in determining the size of largest subgroup. One cannot simply pick a number at random and use it as a modulus. Photuris had good practical advice on this score, and Oakley had a brief discussion of the problem, some words about Sophie-Germaine primes, Schnorr subgroups, etc. But this is a piece of cake. Solving the problem for elliptic curve groups is much harder. That's why there are no new EC groups (it's not that they eat their young). Hilarie From owner-ipsec Tue Apr 15 17:18:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA07842 for ipsec-outgoing; Tue, 15 Apr 1997 17:18:31 -0400 (EDT) From: pau@watson.ibm.com Date: Tue, 15 Apr 1997 17:30:13 -0400 Message-Id: <9704152130.AA23206@secpwr.watson.ibm.com> To: pau@watson.ibm.com, dharkins@cisco.com Subject: Re: A pothole in ISAKMP/Oakley Cc: piper@cisco.com, ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Md5: enRKANXiuuj5weVcwbQmbA== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id RAA07834 Sender: owner-ipsec@ex.tis.com Precedence: bulk > From dharkins@cisco.com Tue Apr 15 16:56:27 1997 > Message-Id: <199704152049.NAA10076@dharkins-ss20> > X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol > To: pau@watson.ibm.com > Cc: piper@cisco.com, ipsec@tis.com > Subject: Re: A pothole in ISAKMP/Oakley > In-Reply-To: Your message of "Tue, 15 Apr 1997 15:58:33 EDT." <9704151958.AA22946@secpwr.watson.ibm.com> > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > Date: Tue, 15 Apr 1997 13:49:47 -0700 > From: Daniel Harkins > Content-Length: 1036 > Status: RO > > Pau-Chen, > > > This is a 2-line change to the ISAKMP-OAKLEY doc. > > As for the code, the current doc requires the code to take the SPI value > > from the PROPOSAL payload header when computing Quick Mode KEYMAT. > > The proposed change requires the code to also take the "Protocol-ID" > > value from the SAME PROPOSAL payload header when computing Quick Mode KEYMAT. > > I don't think that is a difficult change. > > The size of the change isn't the issue, it's the merit of the change. > Another way of looking at this is that we're changing the document to > accomodate incorrect implementations (monotonically increasing a counter to > generate a SPI is probably unwise regardless of this pothole). In that light, > is this change meritorious? > > Personally, I'm in favor of this change but I'd like to note that the > cement is drying on this document. If we have some consensus that this is > really a problem that really needs to be addressed it can be changed, but > I'd like to avoid what is becoming an even bigger problem: document creep. > > Dan. > Dan, I agree that document creeping should be avoided, especially now. There has been discussion on "SPI usage". It seems that there are opinions on both sides. However, if OAKLEY adopts the change suggested in Ran's note, OAKLEY is cryptographiocally more sound and can stay out of the discusion on "SPI usage", whichever end the discussion will lead to. Regards, Pau-Chen From owner-ipsec Tue Apr 15 17:42:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA08003 for ipsec-outgoing; Tue, 15 Apr 1997 17:41:12 -0400 (EDT) Date: Tue, 15 Apr 97 14:45:00 PDT From: John H Wilson Message-ID: To: kent@bbn.com, rodney@sabletech.com cc: ipsec@tis.com Subject: Re[2]: ESP with stream ciphers Sender: owner-ipsec@ex.tis.com Precedence: bulk Text item: On 4/15, Stephen Kent wrote: > As for stream ciphers for which an offset is employed for crypto >synch, the offset value size will vary depending on the algorithm. But, at >least the size of these values is fixed as part of the SA negotiation >process and not variable. Why doesn't the offset value depend on the (potential) length of the stream, rather than the encryption algorithm involved? John Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Precedence: bulk Sender: owner-ipsec@ex.tis.com Cc: ipsec@tis.com Subject: Re: ESP with stream ciphers From: Stephen Kent To: Rodney Thayer Date: Tue, 15 Apr 1997 16:30:19 -0400 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 References: <97Apr14.161245edt.11650@janus.border.com> In-Reply-To: <3.0.1.32.19970415084450.00df7c0c@pop3.pn.com> Message-Id: X-Sender: kent@po1.bbn.com Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA074 46 for ipsec-outgoing; Tue, 15 Apr 1997 16:24:09 -0400 (EDT) Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mailbag .jf.intel.com (8.8.5/8.7.3) with ESMTP id OAA04004 for ; Tue, 15 Apr 1997 14:38:45 -0700 (PDT) Received: from mailbag.jf.intel.com (mailbag.jf.intel.com [134.134.248.4]) by re lay.jf.intel.com (8.7.6/8.7.3) with ESMTP id OAA02958 for ; Tue, 15 Apr 1997 14:36:26 -0700 (PDT) Return-Path: owner-ipsec@portal.ex.tis.com From owner-ipsec Tue Apr 15 18:26:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA08247 for ipsec-outgoing; Tue, 15 Apr 1997 18:26:06 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Apr 1997 18:30:42 -0400 To: John H Wilson From: Stephen Kent Subject: Re[2]: ESP with stream ciphers Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk John, In general, I'd view the recommended safe stream length as an intrinsic part of the "algorithm" definition. In that context, the algorithm ID suffices for this purpose. In the context of ISASKMP SA negotiation, we can certainly ensure that the algorithm IDs that are negotiated suffice to represent this info. Steve From owner-ipsec Tue Apr 15 18:27:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA08272 for ipsec-outgoing; Tue, 15 Apr 1997 18:27:07 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <97Apr15.164137edt.11659@janus.border.com> References: <199704151941.PAA06920@earth.hpc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Apr 1997 18:27:39 -0400 To: Norman Shulman From: Stephen Kent Subject: Re: A pothole in ISAKMP/Oakley Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Norm, If one selects SPIs to be small integers so that they represent indices into local tables, then they may be very predictable and thus an attacker without passive wiretapping ability may be able to formulate credible-loooking SPIs for existing SAs. Remember, the SPI plus destination address completely defines the SA, so there is no source address check that would be pereformed at this stage of packet processing. Steve From owner-ipsec Wed Apr 16 09:08:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA12933 for ipsec-outgoing; Wed, 16 Apr 1997 09:04:24 -0400 (EDT) Date: Wed, 16 Apr 1997 09:09:21 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199704161309.JAA20179@argon.ncsc.mil> To: ipsec@tis.com Subject: Predictable SPIs (was: Re: A pothole in ISAKMP/Oakley) X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Stephen Kent > > If one selects SPIs to be small integers so that they represent > indices into local tables, then they may be very predictable and thus an > attacker without passive wiretapping ability may be able to formulate > credible-loooking SPIs for existing SAs. Remember, the SPI plus > destination address completely defines the SA, so there is no source > address check that would be pereformed at this stage of packet processing. If one believes that inject-only attackers are a threat, then it is possible to get both unpredictable (to the attacker) SPIs and efficient SPI lookup at the destination by picking a random offset once at boot time and adding it to small integer indices to form the SPIs. Since SPI selection does not affect interoperability, since DOS in general is a hard problem, and since entropy testing of SPI sequences for conformance testing purposes is impossible, it seems unwise to write a MUST requirement on SPI generation. I'd write a note on the rationale for unpredictable SPIs in the Security Considerations section and leave it at that. From owner-ipsec Wed Apr 16 11:46:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14043 for ipsec-outgoing; Wed, 16 Apr 1997 11:45:38 -0400 (EDT) Date: Wed, 16 Apr 1997 18:42:05 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199704161542.SAA21433@ee.technion.ac.il> To: ipsec@tis.com Subject: Re: Predictable SPIs (was: Re: A pothole in ISAKMP/Oakley) Sender: owner-ipsec@ex.tis.com Precedence: bulk Although I have trouble following this list these days I want to addd my voice to those that recommend decoupling the issue of SPI randomness/predictability from the key derivation question. As in many other cases I am in favor of making the crypto right and robust independently of changing system requirements. The structure or lack of structure of an SPI is mainly a system requirement not a cryptographic one. Even if decisions are made on this issue on the basis of defending against denial of service attacks one cannot compare the importance of this functionality relative to having a robust key derivation mechanism in place. The suggestion by Pau-Chen and Ran solves the problem independently of the SPI decisions. Hugo From owner-ipsec Wed Apr 16 11:55:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14173 for ipsec-outgoing; Wed, 16 Apr 1997 11:55:16 -0400 (EDT) Message-Id: <3.0.1.16.19970416115729.1d8f0f5c@world.std.com> X-Sender: dpj@world.std.com X-Mailer: Windows Eudora Light Version 3.0.1 (16) Date: Wed, 16 Apr 1997 11:57:29 -0400 To: Daniel Harkins From: "David P. Jablon" Subject: Re: Another pothole in ISAKMP/Oakley Cc: :@world.std.com In-Reply-To: <199704152101.OAA10099@dharkins-ss20> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, Regarding: > Is this really a pothole in ISAKMP/Oakley? >> Another pothole of note in ISAKMP is Diffie-Hellman >> small-subgroup confinement. Well, it's a problem in Diffie-Hellman itself, on which ISAKMP/Oakley depends. Apparently not enough people know about it. > Are you suggesting a reference to X9.42 in the ISAKMP/Oakley > document? Also, for the benefit of those of us who are not > cryptographers, can you elaborate on the problem of "small > sub-group confinement" and how ISAKMP/Oakley fails to address it? Yes. See my reply to Hilarie's message for more elaboration. -- David From owner-ipsec Wed Apr 16 11:55:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14174 for ipsec-outgoing; Wed, 16 Apr 1997 11:55:16 -0400 (EDT) Message-Id: <3.0.1.16.19970416115934.1d8f2d58@world.std.com> X-Sender: dpj@world.std.com X-Mailer: Windows Eudora Light Version 3.0.1 (16) Date: Wed, 16 Apr 1997 11:59:34 -0400 To: ho@earth.hpc.org (Hilarie Orman) From: "David P. Jablon" Subject: Re: Another pothole in ISAKMP/Oakley Cc: ipsec@tis.com, dharkins@cisco.com, carrel@ipsec.org In-Reply-To: <199704152121.RAA10084@earth.hpc.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hilarie, Regarding your comments on subgroup confinement ... > If one is using new group mode, one might be advised to acquire some > expertise in determining the size of largest subgroup. One cannot > simply pick a number at random and use it as a modulus. Photuris had > good practical advice on this score, and Oakley had a brief discussion > of the problem, some words about Sophie-Germaine primes, Schnorr > subgroups, etc. But this is a piece of cake. Solving the problem for > elliptic curve groups is much harder. That's why there are no new > EC groups (it's not that they eat their young). To clarify my concern, I am not referring to the problems with poorly-chosen DH parameters, but rather to the subgroup attack on Diffie-Hellman assuming the use of well-chosen parameters. The attack is possible in any ordinary DH groups as well as typical choices for EC groups. Also, for both ordinary and EC groups, the attack is easily prevented. For any DH group where the order of the full group (m) is not prime, DH computations are restricted to a large subgroup of prime order (q), where q divides m. This leaves a co-factor t = m/q. Small subgroups always exist in Z_p*. For Sophie-Germain primes, often called "safe-primes", where p = 2q+1, the cofactor is 2. Suitable elliptic curve groups also typically have a small co-factor t, where t > 1. A problem occurs when a man-in-the-middle forces each DH exponential into a small subgroup, by raising each number to the power of q. Both legitimate parties will derive the same key K, but it will be confined to one of "t" possible values, making it easy for the middleman to guess it. Alice->Mary: g^Ra Mary->Bob: (g^Ra)^q Bob->Mary: g^Rb Mary->Alice: (g^Rb)^q K = g^(Ra Rb q q) Two papers published last year describe these attacks, this one in a paper by Wiener and vanOorschot, and a related attack relevant to authenticated- Diffie-Hellman in a paper of mine. The solution is to have each party make sure that the derived key K is in the proper subgroup, or at least not confined to a small subgroup. One way to prevent the problem is to use K' = K^t, which "forces" K' into the group of order q, and then test to make sure that K' is not the identity element. Although discussion of this will be in the forthcoming P1363 and X9.62 standards, given the current limited awareness of the problem, I think this or some other solution or specific reference to a solution should be included in all standards that specify a DH exchange. -- David From owner-ipsec Wed Apr 16 12:11:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14268 for ipsec-outgoing; Wed, 16 Apr 1997 12:11:22 -0400 (EDT) Date: Wed, 16 Apr 1997 12:14:07 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704161614.MAA13550@earth.hpc.org> To: dpj@world.std.com Cc: carrel@ipsec.org, dharkins@cisco.com, ipsec@tis.com In-reply-to: Yourmessage <3.0.1.16.19970416115934.1d8f2d58@world.std.com> Subject: Re: Another pothole in ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk OK, but for a Sophie Germaine prime, (g^a)^q = +- 1, so a check for this is sufficient, as is authentication of the offered exponentials. I can see adding the +-1 check to the spec, just for belt and suspenders. The EC group recommended in the original Oakley has a subgroup of order 12; I suppose that before using it one should be warned to implement the small group check, again as belt and suspenders. Hilarie From owner-ipsec Wed Apr 16 12:57:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14678 for ipsec-outgoing; Wed, 16 Apr 1997 12:56:27 -0400 (EDT) Message-Id: <199704161701.KAA11219@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "David P. Jablon" Cc: ho@earth.hpc.org (Hilarie Orman), ipsec@tis.com, carrel@ipsec.org Subject: Re: Another pothole in ISAKMP/Oakley In-Reply-To: Your message of "Wed, 16 Apr 1997 11:59:34 EDT." <3.0.1.16.19970416115934.1d8f2d58@world.std.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 Apr 1997 10:01:45 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk David, > A problem occurs when a man-in-the-middle forces each DH exponential into > a small subgroup, by raising each number to the power of q. Both > legitimate parties > will derive the same key K, but it will be confined to one of "t" possible > values, > making it easy for the middleman to guess it. But since each exponential is authenticated I don't see how this is a problem. A middleman changing *anything*-- exponentials, initial offer of EHA-- will result in a failed authentication (page 9 of draft). This does seem to be a particularly devious sort of attack but I don't think ISAKMP/Oakley is susceptible. Dan. From owner-ipsec Wed Apr 16 13:12:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA14809 for ipsec-outgoing; Wed, 16 Apr 1997 13:12:03 -0400 (EDT) Date: Wed, 16 Apr 1997 13:17:15 -0400 From: Ran Canetti Message-Id: <9704161717.AA21561@ornavella.watson.ibm.com> To: dpj@world.std.com, ho@earth.hpc.org Subject: Re: Another pothole in ISAKMP/Oakley Cc: carrel@ipsec.org, dharkins@cisco.com, ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: "David P. Jablon" > > A problem occurs when a man-in-the-middle forces each DH exponential into > a small subgroup, by raising each number to the power of q. Both > legitimate parties > will derive the same key K, but it will be confined to one of "t" possible > values, > making it easy for the middleman to guess it. > > Alice->Mary: g^Ra Mary->Bob: (g^Ra)^q > Bob->Mary: g^Rb Mary->Alice: (g^Rb)^q > K = g^(Ra Rb q q) > > Two papers published last year describe these attacks, this one in a paper by > Wiener and vanOorschot, and a related attack relevant to authenticated- > Diffie-Hellman in a paper of mine. The solution is to have each party make > sure > that the derived key K is in the proper subgroup, or at least not confined > to a > small subgroup. > Let me point out that such an attack is possible only against the signature mode of ISAKMP/Oakley. In the encryption mode this doesn't work since the DH challenges are sent encrypted by the public key encryption algorithm (eg, RSA). This is another example where the encryption mode is more secure than the signature mode... Ran Canetti From owner-ipsec Wed Apr 16 13:12:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA14834 for ipsec-outgoing; Wed, 16 Apr 1997 13:12:34 -0400 (EDT) Date: Wed, 16 Apr 1997 19:39:16 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199704161639.TAA22501@ee.technion.ac.il> To: dpj@world.std.com, ho@earth.hpc.org Subject: Re: Another pothole in ISAKMP/Oakley Cc: carrel@ipsec.org, dharkins@cisco.com, ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk > >A problem occurs when a man-in-the-middle forces each DH exponential into >a small subgroup, by raising each number to the power of q. Both >legitimate parties >will derive the same key K, but it will be confined to one of "t" possible >values, >making it easy for the middleman to guess it. > >Alice->Mary: g^Ra Mary->Bob: (g^Ra)^q >Bob->Mary: g^Rb Mary->Alice: (g^Rb)^q >K = g^(Ra Rb q q) > David, If I understand correctly your point then it is NOT a problem in isakmp-oakley. There HASH_I and HASH_R are computed over the values of g^xr and g^xr. Thus, a man in the middle cannot change them without detection. (This attack holded against earlier versions of the draft but not after the later corrections) Or am I missing something in your argument? Hugo From owner-ipsec Wed Apr 16 13:16:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA14894 for ipsec-outgoing; Wed, 16 Apr 1997 13:16:42 -0400 (EDT) Message-Id: <199704161722.KAA11241@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Ran Canetti Cc: dpj@world.std.com, ho@earth.hpc.org, carrel@ipsec.org, ipsec@tis.com Subject: Re: Another pothole in ISAKMP/Oakley In-Reply-To: Your message of "Wed, 16 Apr 1997 13:17:15 EDT." <9704161717.AA21561@ornavella.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 Apr 1997 10:22:07 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran Cannetti wrote: > > From: "David P. Jablon" > > > > A problem occurs when a man-in-the-middle forces each DH exponential into > > a small subgroup, by raising each number to the power of q. Both > > legitimate parties > > will derive the same key K, but it will be confined to one of "t" possible > > values, > > making it easy for the middleman to guess it. > > > > Alice->Mary: g^Ra Mary->Bob: (g^Ra)^q > > Bob->Mary: g^Rb Mary->Alice: (g^Rb)^q > > K = g^(Ra Rb q q) > > Let me point out that such an attack is possible only against the signature > mode of ISAKMP/Oakley. In the encryption mode this doesn't work since > the DH challenges are sent encrypted by the public key encryption algorithm > (eg, RSA). This is another example where the encryption mode is more > secure than the signature mode... I'll agree that encryption mode is more secure but how is this attack made against signature mode (or pre-shared key for that matter)? HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAp | IDii) HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAp | IDii) This is signed in signature mode (and generated directly in pre-shared key mode). Since both exponentials are there how can any man-in-the-middle change them without each party being aware of that? Dan. From owner-ipsec Wed Apr 16 14:33:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA15395 for ipsec-outgoing; Wed, 16 Apr 1997 14:32:31 -0400 (EDT) Date: Wed, 16 Apr 1997 20:39:11 +0200 From: saiz@gc.ssr.upm.es ("LUIS SAIZ GIMENO") Message-Id: <199704161839.AA09834@orfeo.gc.ssr.upm.es> To: tytso@MIT.EDU Subject: Re: A pothole in ISAKMP/Oakley Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk > From owner-ipsec@portal.ex.tis.com Tue Apr 15 22:41:40 1997 > Date: Tue, 15 Apr 1997 16:06:04 -0400 > From: "Theodore Y. Ts'o" > To: pau@watson.ibm.com > Cc: ho@earth.hpc.org, Dan.McDonald@Eng.sun.com, ipsec@tis.com > Subject: Re: A pothole in ISAKMP/Oakley > Address: 1 Amherst St., Cambridge, MA 02139 > Phone: (617) 253-8091 > Sender: owner-ipsec@ex.tis.com > Content-Length: 863 > > From: pau@watson.ibm.com > Date: Tue, 15 Apr 1997 13:25:16 -0400 > > Dan, the spec does say so. But if an implementation uses a montonically > increasing counter to generate SPI's for ESP and AH, it can interop with > others. So I think it is worthwhile to put in a safeguard. > > It sounds like testing for a monotonically increasing counter would be a > good thing to put into a conformance test suite; if a implementation > dues that, it should be considered broken. Non-monotonically doesn't implies (strong)pseudorandomness. Must we check for randomness too? > > Is this important enough that we want to put more explicit words in the > spec? (I will note that in general, this is really about how much we > trust the intelligence and/or competence of the implementors that come > after us. There are certainly those who believe we shouldn't trust > their competence at all --- although if that's really true, the > situation is probably hopeless.) > > - Ted > Regards, Luis Saiz --------------------------------------------------------------------- Protocol cryptanalysis is essentially formalized paranoia. G. Simmons. --------------------------------------------------------------------- From owner-ipsec Wed Apr 16 15:07:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA15647 for ipsec-outgoing; Wed, 16 Apr 1997 15:06:49 -0400 (EDT) Date: Wed, 16 Apr 1997 20:42:35 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199704161742.UAA24164@ee.technion.ac.il> To: canetti@watson.ibm.com, dharkins@cisco.com Subject: Re: Another pothole in ISAKMP/Oakley Cc: carrel@ipsec.org, dpj@world.std.com, ho@earth.hpc.org, ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk > >I'll agree that encryption mode is more secure but how is this attack made >against signature mode (or pre-shared key for that matter)? > > HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAp | IDii) > HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAp | IDii) > >This is signed in signature mode (and generated directly in pre-shared key >mode). Since both exponentials are there how can any man-in-the-middle change >them without each party being aware of that? > > Dan. > Dan is correct. The inclusion of g^xr and g^xi in HASH solves the problem in all the modes. This is no particular advantage of the encryption mode. It is an advantage of having the same HASH in all modes and all include the exponents. Befoere doing that, draft-01 was susceptible to this problem. Hugo From owner-ipsec Wed Apr 16 15:19:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA15791 for ipsec-outgoing; Wed, 16 Apr 1997 15:18:56 -0400 (EDT) Date: Wed, 16 Apr 1997 15:24:43 -0400 Message-Id: <9704161924.AA00059@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: saiz@gc.ssr.upm.es ("LUIS SAIZ GIMENO") Cc: ipsec@tis.com In-Reply-To: "LUIS SAIZ GIMENO"'s message of Wed, 16 Apr 1997 20:39:11 +0200, <199704161839.AA09834@orfeo.gc.ssr.upm.es> Subject: Re: A pothole in ISAKMP/Oakley Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Wed, 16 Apr 1997 20:39:11 +0200 From: saiz@gc.ssr.upm.es ("LUIS SAIZ GIMENO") Non-monotonically doesn't implies (strong)pseudorandomness. Must we check for randomness too? No, but it's an easy check to prevent really bad implementations. Yes, it's easy enough to pass that check without doing it with good random number generator... but see my question about what level of stupidity/hostility are we expecting from our implementors? - Ted From owner-ipsec Wed Apr 16 18:25:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA16893 for ipsec-outgoing; Wed, 16 Apr 1997 18:23:50 -0400 (EDT) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 Apr 1997 10:03:28 -0500 To: Rob Glenn From: Stephen Kent Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt Cc: ipsec@tis.com, rob.glenn@nist.gov Sender: owner-ipsec@ex.tis.com Precedence: bulk Rob, I included HMAC with MD5 and SHA-1 in the I-D as a means of expressing the default algorithm support requirements. Additional algrotihms can be specified by separate RFCs; the difference is that these RFCs need not include the rest of the AH (or ESP) spec. Instead, they will just be algorithm defintions, perhaps with a few references to the relevent RFCs. The additional algorithms will be registered with the IANA. We can improve the I-Ds by emphasizing this means of adding other algorithms. However, I don't think the current I-Ds are unduly algorithm dependent as a result of the approach adopted here, but there is a clear intent to establish default, required algorithms. I'm not sure that the indirection through another RFC for specifying requirement algorithms is an improvement. If we change the defaults, another RFC gets produced and the indirection doesn't seem to buy us that much. As for anti-replay and manual keys, I think other messages have addressed that topic. Mostly, we need to refine the terminology, but I think the intent is correct. If one uses a manually positioned key for AH, then AR seems incompatible in that reliable state retention would be required across crashes and some means would be needed to prevent cycling, despite the lack of an automated ability to load new keys. Since we are trying to minimize creating situations where procedural errors will result in insecurities, I think it is appropropriate to rule out the use of AR with static, manual authentication keys. As for the optional nature of the AR counter, I'm quite happy to make it permanent field if that's what the WG wants, but as the I-D points out, this will result in an extra 4 bytes of overhead for IPv4. Given that some folks have produced ESP drafts that employ implicit IVs specifically to reduce per-packet transmission overhead in the 4-8 byte range, it seems a bit inconsistent to mandate this 4 byte field. I have also heard that there was some concern expressed over the issue of making anti-replay optional, because of the overhead of negotiating this security service, especially in terms of window size negotiation. I've had some private communication with folks immediately preceeding the meeting, and one suggestion that arose was making a window size of 32 the default, if AR is negotiated. One might eliminate the need to negotiate a window size at all if this default were considered adequate, and the receiver were free to implement a larger window as a local option. This would simplify the negotiation process, and allow it to be expressed as just a compound "transform" along with the algorithm negotiation. That would require no additional ISAKMP messages and thus should not raise objections re added negotiation complexity. Steve From owner-ipsec Wed Apr 16 19:11:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA17160 for ipsec-outgoing; Wed, 16 Apr 1997 19:11:17 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 16 Apr 1997 17:16:17 -0600 From: John Kennedy To: ho@earth.hpc.org, dpj@world.std.com Cc: dharkins@cisco.com, carrel@ipsec.org, ipsec@tis.com Subject: Small subgroups and ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk All, David is right that this problem should be addressed in a DH standard. In X9.42, the following checks are mandatory for an implementation: 1) Received public numbers are checked to insure that they are not equal to 1 or -1. (note -1 = (p-1) mod p) 2) The shared-secret number Z=g(xy) mod p is checked to make sure that (Z ^j)) mod p <> 1, where j=(p-1)/q. I.e. j is the "co-factor" used to multiply q: p = jq+1. Typically, j is fairly small so this is a quick operation to detect the small sub-group attack. 3) Finally, the generation of the prime modulus p may be optionally checked because X9.42 specifies a repeatable method for prime generation similar to that specified in the DSS standard. Also, the order of the generator g may be check to make sure the order is q. Since I haven't gotten around to the new and improved OAKLEY draft, I don't know how much of this is there or not. During X9.42 development discussion it was not necessarily a man-in-the-middle that was feared with regards to the small sub-group attack. Conceivably, one of the communicating parties could send a "bad" public number on purpose. Is this a realistic scenario? Whatever your opinion it makes since to do the relatively inexpensive checks outlined above. Finally, with regards to elliptic curve DH I think it would be best to refer to the work being done by IEEE P1363. You might want to consider deferring to P1363 for the GF(P) DH stuff too. ANSI X9.42 is much more application specific than the work in P1363. (P1363 can be profiled into something X9.42 compliant however.) Also, the P1363 drafts are all freely-avaliable on-line and not as subject to US-centric interests. See http://stdsbbs.ieee.org/groups/1363/ . IMHO, the P1363 work is the most comprehensive and up-to-date standards work on public-key technology available right now and deserves to be a primary reference for all IETF standards on crypto. With regards to elliptic curve PK it is unparalled. -John Kennedy >>> "David P. Jablon" 04/16/97 09:59AM >>> Hilarie, Regarding your comments on subgroup confinement ... > If one is using new group mode, one might be advised to acquire some > expertise in determining the size of largest subgroup. One cannot > simply pick a number at random and use it as a modulus. Photuris had > good practical advice on this score, and Oakley had a brief discussion > of the problem, some words about Sophie-Germaine primes, Schnorr > subgroups, etc. But this is a piece of cake. Solving the problem for > elliptic curve groups is much harder. That's why there are no new > EC groups (it's not that they eat their young). To clarify my concern, I am not referring to the problems with poorly-chosen DH parameters, but rather to the subgroup attack on Diffie-Hellman assuming the use of well-chosen parameters. The attack is possible in any ordinary DH groups as well as typical choices for EC groups. Also, for both ordinary and EC groups, the attack is easily prevented. For any DH group where the order of the full group (m) is not prime, DH computations are restricted to a large subgroup of prime order (q), where q divides m. This leaves a co-factor t = m/q. Small subgroups always exist in Z_p*. For Sophie-Germain primes, often called "safe-primes", where p = 2q+1, the cofactor is 2. Suitable elliptic curve groups also typically have a small co-factor t, where t > 1. A problem occurs when a man-in-the-middle forces each DH exponential into a small subgroup, by raising each number to the power of q. Both legitimate parties will derive the same key K, but it will be confined to one of "t" possible values, making it easy for the middleman to guess it. Alice->Mary: g^Ra Mary->Bob: (g^Ra)^q Bob->Mary: g^Rb Mary->Alice: (g^Rb)^q K = g^(Ra Rb q q) Two papers published last year describe these attacks, this one in a paper by Wiener and vanOorschot, and a related attack relevant to authenticated- Diffie-Hellman in a paper of mine. The solution is to have each party make sure that the derived key K is in the proper subgroup, or at least not confined to a small subgroup. One way to prevent the problem is to use K' = K^t, which "forces" K' into the group of order q, and then test to make sure that K' is not the identity element. Although discussion of this will be in the forthcoming P1363 and X9.62 standards, given the current limited awareness of the problem, I think this or some other solution or specific reference to a solution should be included in all standards that specify a DH exchange. -- David ! ! ! From owner-ipsec Wed Apr 16 19:54:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA17357 for ipsec-outgoing; Wed, 16 Apr 1997 19:53:00 -0400 (EDT) Date: Wed, 16 Apr 1997 19:55:51 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704162355.TAA27524@earth.hpc.org> To: JKENNEDY@novell.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199704162320.QAA22212@baskerville.CS.Arizona.EDU> Subject: Re: Small subgroups and ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk The 1,-1 check should be added to the spec, but I think the rest of the good work of IEEE and X9.42 is beyond the intended scope of ISAKMP/OAKLEY; there's no intent to reference all possible attacks. I recommend adding a comment that only strong/Sophie Germaine/j=2 primes be used for the modulus in the New Group exchange, but the consenting parties must either trust each other's math or be able to independently validate the Sophie Germaineness of the modulus (off-line beforehand or in-line on a fast machine). With regard to having one party force a bad key, it is still possible for the second party to choose and exponential that forces many of the key bits to a known value, thus opening up some room for a passive attacker. There's no trick to this, it simply requires a lot of fast computation. Hilarie From owner-ipsec Wed Apr 16 21:41:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA18025 for ipsec-outgoing; Wed, 16 Apr 1997 21:39:29 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 16 Apr 1997 19:44:20 -0600 From: John Kennedy To: ho@earth.hpc.org Cc: ipsec@tis.com Subject: Re: Small subgroups and ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk What you suggest is probably a good minimum check. There is also some wisdom to allowing implementors to compete based what types of additional checks they choose to perform and the performance they deliver. Regarding ANSI and IEEE, my main point was to get implementors to read these documents to educate themselves, not to necessarily have IETF tie itself to this related work. On the Sophie-Germaine/j=2 thing: Is there some reason you think having j>2 is a problem? Using a 160-bit q is not necessarily a bad thing. -John >>> Hilarie Orman 04/16/97 05:55PM >>> The 1,-1 check should be added to the spec, but I think the rest of the good work of IEEE and X9.42 is beyond the intended scope of ISAKMP/OAKLEY; there's no intent to reference all possible attacks. I recommend adding a comment that only strong/Sophie Germaine/j=2 primes be used for the modulus in the New Group exchange, but the consenting parties must either trust each other's math or be able to independently validate the Sophie Germaineness of the modulus (off-line beforehand or in-line on a fast machine). With regard to having one party force a bad key, it is still possible for the second party to choose and exponential that forces many of the key bits to a known value, thus opening up some room for a passive attacker. There's no trick to this, it simply requires a lot of fast computation. Hilarie ! From owner-ipsec Wed Apr 16 21:47:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA18071 for ipsec-outgoing; Wed, 16 Apr 1997 21:47:02 -0400 (EDT) Message-ID: <33558269.41C6@cs.umass.edu> Date: Wed, 16 Apr 1997 21:52:41 -0400 From: Lewis McCarthy Organization: Theoretical Computer Science Group, UMass-Amherst, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) MIME-Version: 1.0 To: IP Security List Subject: Re: Small subgroups and ISAKMP/Oakley References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk John Kennedy writes: > During X9.42 development discussion it was not necessarily a > man-in-the-middle that was feared with regards to the small sub-group > attack. Conceivably, one of the communicating parties could send a > "bad" public number on purpose. Is this a realistic scenario? One of the legitimate parties might be a broken implementation that doesn't correctly check whether it has computed a public exponential that lies in the small subgroup. -Lewis From owner-ipsec Thu Apr 17 07:59:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA21287 for ipsec-outgoing; Thu, 17 Apr 1997 07:57:21 -0400 (EDT) Message-Id: <199704171157.HAA21287@portal.ex.tis.com> Date: Wed, 16 Apr 1997 18:40:43 -0700 From: David Carrel Organization: RedBack Networks Inc. X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: palamber@us.oracle.com CC: ipsec@tis.com, isakmp-oakley@cisco.com Subject: notes from developer's portion of IETF meeting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Paul, here are the notes that I took at the developers portion of the IPSEC meetings. Please include these in the official minutes. Thanks Dave Carrel carrel@ipsec.org ------------------------------------------------------------- anti-replay decision is that it is not optional! The bits are always in the header It MUST be used by sender. Always starts at 1. key management will NOT negotiate whether it's used. integrity decicion is that it is optional but if not used in ESP, it must be used in AH. Words to this effect must be added to arch docs. optional encryption not optional in ESP A tunnel mode must be added to the specs for AH encrypt/auth order encrypt first, auth next but IV MUST NOT be constant and MUST be included in every packet IV size is transform dependant and must be specified in the transform docs signature format Dan will send to list, with comments from Eric Rescolla IBM- rsa encryption format leave current format as is to avoid document creep Ran and Hugo will write a draft of their exchange slice and dice remove current key derivation text from Hughes draft It is based on who is initiator and responder (*** action item for Paul Lambert ***) All transforms MUST specify a number of keying bits required and how to generate keys, IVs, etc from that (# keying bits requested equals the # bits of entropy) transform must specify what to do in case of weak key if alg has a small number of weak keys then the recommendation is to request a new SA Name space to IANA need algorithm ids forward issue to list Audit Decision is that this will be documented as "SHOULD implement" MIB take issue to list ---------------------- The following issues were discussed and agreed upon in the Wednesday mtg. ISAKMP ISAKMP should be bound to port 500 (i.e. send and receive on port 500) No need to negotiate replay window size. replay window size is 32. Increase it to a higher value later on if necesary. Situation and DOI must be included in calculating hash for the quick mode for public-key encryption, SKEYID = prf(Ni | Nr, g^xy) (it was hash(Ni | Nr). HASH(2) in Quick Mode includes the initiator's nonce. For ease of processing stick it after the message-id, i.e. HASH(2) = prf(SKEYID_a, M-ID | Ni | SA | Nr [ | KE ] [ | IDui | IDur ] ) ^^^^ From owner-ipsec Thu Apr 17 09:19:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA21691 for ipsec-outgoing; Thu, 17 Apr 1997 09:12:45 -0400 (EDT) Date: Thu, 17 Apr 1997 09:17:30 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199704171317.JAA21004@argon.ncsc.mil> To: ipsec@tis.com Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Stephen Kent > > As for the optional nature of the AR counter, I'm quite happy to > make it permanent field if that's what the WG wants, but as the I-D points > out, this will result in an extra 4 bytes of overhead for IPv4. Given that > some folks have produced ESP drafts that employ implicit IVs specifically > to reduce per-packet transmission overhead in the 4-8 byte range, it seems > a bit inconsistent to mandate this 4 byte field. > > I have also heard that there was some concern expressed over the > issue of making anti-replay optional, because of the overhead of > negotiating this security service, especially in terms of window size > negotiation. I've had some private communication with folks immediately > preceeding the meeting, and one suggestion that arose was making a window > size of 32 the default, if AR is negotiated. One might eliminate the need > to negotiate a window size at all if this default were considered adequate, > and the receiver were free to implement a larger window as a local option. > This would simplify the negotiation process, and allow it to be expressed > as just a compound "transform" along with the algorithm negotiation. That > would require no additional ISAKMP messages and thus should not raise > objections re added negotiation complexity. Perhaps I am missing something important, but I've never understood the justification for negotiating replay window sizes. Replay window size is entirely a property of the receiver, no? Does the transmitter do anything different with a window size of 32 than it would with a window size of, say, 128? If there is no difference in the bits on the wire, why do window size negotiation at all? Your point about replay yes/no negotiation is well taken - it seems inconsistent to mandate 4 bytes of AR overhead while negotiating IVs to save 4-8 bytes. Nonetheless, I think Cheryl's suggestion towards the end of the first IPSEC session has great merit: never negotiate AR, always transmit the AR counter, then the receiver can unilaterally decide whether or not to do AR, and if so, what window size to use. That is the ultimate in simplicity, and it gets my vote^H^H^H^H straw poll ballot. From owner-ipsec Thu Apr 17 09:40:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA21837 for ipsec-outgoing; Thu, 17 Apr 1997 09:40:28 -0400 (EDT) Date: Thu, 17 Apr 1997 09:42:08 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704171342.JAA22336@earth.hpc.org> To: JKENNEDY@novell.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199704170149.SAA01801@baskerville.CS.Arizona.EDU> Subject: Re: Small subgroups and ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk > On the Sophie-Germaine/j=2 thing: > > Is there some reason you think having j>2 is a problem? Using a 160-bit q is not necessarily a bad thing. One reason that it is bad is that it may force implementors to become number theorists. While in the greater scheme of things, this would be a positive development, in the small it is merely quixotic. Is there some reason that j=2 is an unreasonable restriction? The only reason I can see for non-Sophie-Germaineness* is that it might be possible for one party to propose a new group of a particular type and for the recipient to verify its subgroup structure quickly (a few minutes). Hilarie Why not simply Germaine primes? No one says Emma-Noetherian rings. From owner-ipsec Thu Apr 17 09:50:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA21901 for ipsec-outgoing; Thu, 17 Apr 1997 09:50:30 -0400 (EDT) Date: Thu, 17 Apr 1997 09:53:12 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704171353.JAA22585@earth.hpc.org> To: carrel@redbacknetworks.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199704171209.FAA21072@baskerville.CS.Arizona.EDU> Subject: Re: notes from developer's portion of IETF meeting Sender: owner-ipsec@ex.tis.com Precedence: bulk Wouldn't it be easiest to have the transforms present a callback routine for key generation? The routine would take a variable precision integer as input (length >= requested entropy) and produce a list of bitstrings as output. > slice and dice ... > All transforms MUST specify a number of keying bits > required and how to generate keys, IVs, etc from that > (# keying bits requested equals the # bits of entropy) Hilarie From owner-ipsec Thu Apr 17 10:27:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA22171 for ipsec-outgoing; Thu, 17 Apr 1997 10:26:48 -0400 (EDT) Message-Id: <199704171428.KAA11109@relay.hq.tis.com> Date: Thu, 17 Apr 97 10:32:54 EDT From: Charles Lynn To: David Carrel cc: palamber@us.oracle.com, ipsec@tis.com, CLynn@bbn.com Subject: Tunnel mode AH (Was: notes from developer's portion of IETF meeting) Sender: owner-ipsec@ex.tis.com Precedence: bulk David, > optional encryption > not optional in ESP > A tunnel mode must be added to the specs for AH Did the working group decide on a mechanism, e.g., a bit in the RESERVED field, to indicate a "tunnel mode" in which none of the headers preceding the AH are to be covered by the integrity mechanism? Such a mode is needed both for efficiency (hop-by-hop protection of every packet sent between two systems) and for extensibility (as new extension header versions, etc. are defined). This was provided by the "ESP with integrity but not confidentiality" combination. Charlie From owner-ipsec Thu Apr 17 10:33:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA22232 for ipsec-outgoing; Thu, 17 Apr 1997 10:33:21 -0400 (EDT) Message-Id: <3.0.1.16.19970417103637.22bf37a0@world.std.com> X-Sender: dpj@world.std.com X-Mailer: Windows Eudora Light Version 3.0.1 (16) Date: Thu, 17 Apr 1997 10:36:37 -0400 To: ho@earth.hpc.org (Hilarie Orman) From: "David P. Jablon" Subject: Re: Small subgroups and ISAKMP/Oakley Cc: John Kennedy , Lewis McCarthy , ipsec@tis.com In-Reply-To: <199704162355.TAA27524@earth.hpc.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hilarie, In light of Dan Harkin's comments about the HASH'ed authenticated exponentials preventing middleman confinement attack in the latest draft of ISAKMP/Oakley, I presume we're now talking about DH in general. In regards to John's and Lewis' comments about end-party confinement, I think the significance of this is largely for other uses of DH. With this in mind, ... At 07:55 PM 4/16/97 -0400, you wrote: > With regard to having one party force a bad key, it is still possible for > the second party to choose and exponential that forces many of the key > bits to a known value, thus opening up some room for a passive attacker. > There's no trick to this, it simply requires a lot of fast computation. By "still possible" do you mean even if the first party checks for confinement? I think the problem of known key bits is only there if the chosen exponential is of small order. If the "bad" exponential is a generator of a large-order group, then the good party's large random exponent should prevent any predictable bits. There was some discussion related to this at the last P1363 meeting. Specifically, does one need to insure that the result is in the correct large subgroup, or is it enough to prevent it from being in a small subgroup? And then if so, how small is small? How to properly deal with prime moduli with large co-factors was left as an open issue. Raising the result to the co-factor works, but may not be the most efficient solution. -- David ------------------------------------ David P. Jablon Tel: +1 508 898 9024 http://world.std.com/~dpj/ E-mail: dpj@world.std.com From owner-ipsec Thu Apr 17 10:51:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA22376 for ipsec-outgoing; Thu, 17 Apr 1997 10:51:35 -0400 (EDT) Date: Thu, 17 Apr 1997 10:54:14 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704171454.KAA24458@earth.hpc.org> To: dpj@world.std.com Cc: ipsec@tis.com, lmccarth@cs.umass.edu, JKENNEDY@novell.com In-reply-to: Yourmessage <3.0.1.16.19970417103637.22bf37a0@world.std.com> Subject: Re: Small subgroups and ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk > > With regard to having one party force a bad key, it is still possible for > > the second party to choose and exponential that forces many of the key > > bits to a known value, thus opening up some room for a passive attacker. > > There's no trick to this, it simply requires a lot of fast computation. > By "still possible" do you mean even if the first party checks for > confinement? Yes. There's no number theory involved, just trial-and-error. The reason I mention this is that I think that confinement is overall a minor problem (because there are so many reasonable ways to avoid it) and that worrying about confinement with an authenticated but unscrupulous conversant is even more minor. For comparison I offer the brute force method, an attack that is ignored because there is no cure. At least, I don't know of one. Hilarie From owner-ipsec Thu Apr 17 11:54:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA22990 for ipsec-outgoing; Thu, 17 Apr 1997 11:53:47 -0400 (EDT) Message-Id: <199704171558.LAA03975@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: Charles Lynn Cc: David Carrel , palamber@us.oracle.com, ipsec@tis.com Subject: Re: Tunnel mode AH (Was: notes from developer's portion of IETF meeting) In-Reply-To: clynn's message of Thu, 17 Apr 1997 10:32:54 -0400. <199704171428.KAA11109@relay.hq.tis.com> Date: Thu, 17 Apr 1997 11:58:32 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > Did the working group decide on a mechanism, e.g., a bit in the > RESERVED field, to indicate a "tunnel mode" in which none of the > headers preceding the AH are to be covered by the integrity > mechanism? If we were going to do this (and I'm not sure it's the right thing to do), I'd think that this should be an attribute of the SA, not a bit in the header.. - Bill From owner-ipsec Thu Apr 17 12:39:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA23359 for ipsec-outgoing; Thu, 17 Apr 1997 12:39:07 -0400 (EDT) Message-ID: <335639C2.59C0@newoak.com> Date: Thu, 17 Apr 1997 10:54:58 -0400 From: smamros@newoak.com (Shawn Mamros) X-Mailer: Mozilla 4.0b2 (WinNT; I) MIME-Version: 1.0 To: ipsec@tis.com CC: smamros@newoak.com Subject: CBC IV generation in ISAKMP/Oakley X-Priority: 3 (Normal) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk In the latest (-03) version of the ISAKMP/Oakley resolution draft, there's a change in how the IV for ISAKMP message encryption is performed. Previously, in the -02 draft, a hash of the D-H public values was used as the IV for all messages. Now, that hash is only used for the first encrypted message in Phase 1; all other Phase 1 messages use the last CBC encryption block from the previous message. The first message of a Phase 2/Quick Mode exchange uses a hash of the last Phase 1 CBC output block output block with the Phase 2 message ID as its IV, with later messages in that particular exchange using the last CBC encryption block from the previous message in the exchange. (One can read Appendix B of the -03 draft for the rest of the details.) I guess that changing the IV for every message is a good thing from a cryptographic point of view (at least to this non-cryptographer), but I'm concerned that it might not be such a good thing from a protocol point of view. Specifically, I have two concerns: 1. Handling retransmissions: ISAKMP entities MUST retransmit when a response is not received after some period of time (isakmp-07 draft, section 5.1). This, coupled with the fact that IVs change now, makes the following scenario possible: i. Once Phase 1 is complete, one of the ISAKMP peers sends out an initial Phase 2/Quick Mode message. ii. No response is received, so the initiator retransmits. iii. The intended responder finally receives the first message. The IV for the initial message is calculated, the message is decrypted and processed, the reply is sent out, and the responder is now prepared to decrypt the next message using the last CBC block of that message as the IV. iv. The responder receives the retransmission of the first message. It cannot be decrypted cleanly, because the IV is now wrong. Since there is no sequence number or other "hint" in the ISAKMP header which allows one to detect retransmissions, about the only thing a Phase 2 responder can do is "guesstimate" the likely size of the initiator's second Phase 2 message, and throw out anything larger than that as being a likely retransmission of the first message. Or recalculate the initial IV and try to decrypt the message over again. Both of these approaches are, at best, workarounds for something for which the protocol itself really ought to handle better (or at least document the proper workaround...). 2. Informational exchange messages (Notify and Delete): isakmp-07 states that Informational exchange messages MUST be protected by the ISAKMP SA once it is established (section 4.8). However, isakmp-oakley-03 does not state what one should use for an IV when sending an Informational exchange message. One could assume that a Notify payload sent in reply to some Phase 2 message should use the CBC output block from the previous message as the IV. (One should not have to assume this; it should be stated clearly somewhere.) If, however, there are several Phase 2 exchanges going on at the same time, how does one tell which IV to use? Is it legal to use the Message ID in an Informational exchange? What if a message is not decrypted cleanly (due perhaps to an IV problem with a retransmission as described above?). Should one send a Notify payload back? Encrypted or not? If encrypted, what IV does one use? Better still, what about Delete payloads? Those may not arrive until much later. They should obviously be protected by an ISAKMP SA, but what should one use for an IV? I'm certain all of these can be handled one way or another. Maybe it would make sense to include the IV as part of the message, the way ESP transforms do. Or perhaps it just requires some clarifying text in the draft(s). Or maybe I'm missing something really obvious... -Shawn Mamros E-mail to: smamros@newoak.com From owner-ipsec Thu Apr 17 13:35:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA23879 for ipsec-outgoing; Thu, 17 Apr 1997 13:34:09 -0400 (EDT) Message-Id: <199704171739.KAA11940@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: smamros@newoak.com (Shawn Mamros) Cc: ipsec@tis.com Subject: Re: CBC IV generation in ISAKMP/Oakley In-Reply-To: Your message of "Thu, 17 Apr 1997 10:54:58 EDT." <335639C2.59C0@newoak.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Apr 1997 10:39:50 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Shawn, In the -02 draft the IV was not constant. That might not have been explained very clearly but that was the intent (and in fact, the most recent bake-off was against -02 and everyone had a running IV). > I guess that changing the IV for every message is a good thing from > a cryptographic point of view (at least to this non-cryptographer), > but I'm concerned that it might not be such a good thing from a > protocol point of view. Specifically, I have two concerns: A changing IV is mandatory. There is no point in having an IV if it is the same for all messages. > 1. Handling retransmissions: ISAKMP entities MUST retransmit when > a response is not received after some period of time (isakmp-07 > draft, section 5.1). This, coupled with the fact that IVs change > now, makes the following scenario possible: > > i. Once Phase 1 is complete, one of the ISAKMP peers sends out an > initial Phase 2/Quick Mode message. > > ii. No response is received, so the initiator retransmits. > > iii. The intended responder finally receives the first message. > The IV for the initial message is calculated, the message is > decrypted and processed, the reply is sent out, and the responder > is now prepared to decrypt the next message using the last CBC > block of that message as the IV. > > iv. The responder receives the retransmission of the first message. > It cannot be decrypted cleanly, because the IV is now wrong. I've seen this happen in testing. > Since there is no sequence number or other "hint" in the ISAKMP > header which allows one to detect retransmissions, about the only > thing a Phase 2 responder can do is "guesstimate" the likely > size of the initiator's second Phase 2 message, and throw out anything > larger than that as being a likely retransmission of the first message. > Or recalculate the initial IV and try to decrypt the message over > again. Both of these approaches are, at best, workarounds for > something for which the protocol itself really ought to handle > better (or at least document the proper workaround...). No, the 2nd one is dropped because the decryption failed. The protocol handles this just fine. > 2. Informational exchange messages (Notify and Delete): isakmp-07 > states that Informational exchange messages MUST be protected by > the ISAKMP SA once it is established (section 4.8). However, > isakmp-oakley-03 does not state what one should use for an IV > when sending an Informational exchange message. This needs some wordsmithing and coordination with the ISAKMP authors. The solution is to require Informational exchanges to have a message-ID in the header. The IV for these exchanges would then be derived in an identical manner as that for Quick Mode exchanges. Your concerns about IVs getting out of sync if messages are dropped can be alleviated by retaining the encrypted payload for retransmission purposes. If your counter times out, resend the encrypted payload, don't retain the cleartext payload and re-encrypt it. Like I said, I've seen this happen and there is a brief hiccup and then they get back into sync. > I'm certain all of these can be handled one way or another. Maybe > it would make sense to include the IV as part of the message, the > way ESP transforms do. Or perhaps it just requires some clarifying > text in the draft(s). Or maybe I'm missing something really obvious... Clarification in the drafts is the way to go. I think it was Idi Amin who said, "Sometimes people mistake the things I say for the way I think." For me it's: the way I write for what I think. Dan. From owner-ipsec Thu Apr 17 13:35:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA23907 for ipsec-outgoing; Thu, 17 Apr 1997 13:35:39 -0400 (EDT) Date: Thu, 17 Apr 1997 13:38:19 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704171738.NAA29401@earth.hpc.org> To: smamros@newoak.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199704171650.JAA07669@baskerville.CS.Arizona.EDU> Subject: Re: CBC IV generation in ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk Surely this is true. > Maybe > it would make sense to include the IV as part of the message, the > way ESP transforms do. Hilarie From owner-ipsec Thu Apr 17 14:18:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA24293 for ipsec-outgoing; Thu, 17 Apr 1997 14:18:16 -0400 (EDT) Message-ID: <33566146.49F@redbacknetworks.com> Date: Thu, 17 Apr 1997 10:43:34 -0700 From: David Carrel Organization: RedBack Networks Inc. X-Mailer: Mozilla 3.01Gold (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Hilarie Orman CC: ipsec@tis.com Subject: Re: notes from developer's portion of IETF meeting References: <199704171353.JAA22585@earth.hpc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hilarie, that might be a fine implementation detail. I'll spare everyone my opinion on that. However, the only point that was decided upon in the meeting is the onus of specifying the details for generating keys, IVs, etc... If the working group wishes to work on an API or ABI for ISAKMP and/or IPSEC (such as PF_KEY) then issues such as what you mention will need to be decided upon. Dave Hilarie Orman wrote: > > Wouldn't it be easiest to have the transforms present a callback > routine for key generation? The routine would take a variable > precision integer as input (length >= requested entropy) and produce a > list of bitstrings as output. > > > slice and dice > ... > > All transforms MUST specify a number of keying bits > > required and how to generate keys, IVs, etc from that > > (# keying bits requested equals the # bits of entropy) > > Hilarie From owner-ipsec Thu Apr 17 14:20:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA24318 for ipsec-outgoing; Thu, 17 Apr 1997 14:20:18 -0400 (EDT) Message-ID: <335661D9.6B5A@redbacknetworks.com> Date: Thu, 17 Apr 1997 10:46:01 -0700 From: David Carrel Organization: RedBack Networks Inc. X-Mailer: Mozilla 3.01Gold (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Charles Lynn CC: palamber@us.oracle.com, ipsec@tis.com Subject: Re: Tunnel mode AH (Was: notes from... IETF meeting) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Charlie, no such decision was made (that I am aware of) in Memphis. It would be good to start thrashing that out here. Dave Charles Lynn wrote: > > David, > > > optional encryption > > not optional in ESP > > A tunnel mode must be added to the specs for AH > > Did the working group decide on a mechanism, e.g., a bit in the > RESERVED field, to indicate a "tunnel mode" in which none of the > headers preceding the AH are to be covered by the integrity > mechanism? > > Such a mode is needed both for efficiency (hop-by-hop protection of > every packet sent between two systems) and for extensibility (as new > extension header versions, etc. are defined). This was provided by > the "ESP with integrity but not confidentiality" combination. > > Charlie From owner-ipsec Thu Apr 17 14:21:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA24370 for ipsec-outgoing; Thu, 17 Apr 1997 14:21:20 -0400 (EDT) Date: Thu, 17 Apr 1997 18:42:16 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199704171542.SAA25241@ee.technion.ac.il> To: dpj@world.std.com, ho@earth.hpc.org Subject: Re: Small subgroups and ISAKMP/Oakley Cc: JKENNEDY@novell.com, ipsec@tis.com, lmccarth@cs.umass.edu Sender: owner-ipsec@ex.tis.com Precedence: bulk A feature of isakmp/oakley's public key encryption mode, which I do not think is enjoyed by any of the other mentioned standards, is that even if an attacker derives g^xy (by means of preprocessing against a "universal" prime p, or by degenarate choices of one of the parties in the exchange) it still cannot decrypt the traffic since the key also depends on an ephemeral key exchanged under RSA. (That is, both the RSA AND DH exchanges need to be broken simultaneously). The current drawback of this mode in isakmp-oakley is that it requires an additional exponentiation for protecting id's. Unfortunately, the simple correction of this problem will need to wait until the next draft revision... Hugo From owner-ipsec Thu Apr 17 14:23:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA24418 for ipsec-outgoing; Thu, 17 Apr 1997 14:23:50 -0400 (EDT) Message-ID: <33557F9B.72A1@redbacknetworks.com> Date: Wed, 16 Apr 1997 18:40:43 -0700 From: David Carrel Organization: RedBack Networks Inc. X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: palamber@us.oracle.com CC: ipsec@tis.com, isakmp-oakley@cisco.com Subject: notes from developer's portion of IETF meeting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Paul, here are the notes that I took at the developers portion of the IPSEC meetings. Please include these in the official minutes. Thanks Dave Carrel carrel@ipsec.org ------------------------------------------------------------- anti-replay decision is that it is not optional! The bits are always in the header It MUST be used by sender. Always starts at 1. key management will NOT negotiate whether it's used. integrity decicion is that it is optional but if not used in ESP, it must be used in AH. Words to this effect must be added to arch docs. optional encryption not optional in ESP A tunnel mode must be added to the specs for AH encrypt/auth order encrypt first, auth next but IV MUST NOT be constant and MUST be included in every packet IV size is transform dependant and must be specified in the transform docs signature format Dan will send to list, with comments from Eric Rescolla IBM- rsa encryption format leave current format as is to avoid document creep Ran and Hugo will write a draft of their exchange slice and dice remove current key derivation text from Hughes draft It is based on who is initiator and responder (*** action item for Paul Lambert ***) All transforms MUST specify a number of keying bits required and how to generate keys, IVs, etc from that (# keying bits requested equals the # bits of entropy) transform must specify what to do in case of weak key if alg has a small number of weak keys then the recommendation is to request a new SA Name space to IANA need algorithm ids forward issue to list Audit Decision is that this will be documented as "SHOULD implement" MIB take issue to list ---------------------- The following issues were discussed and agreed upon in the Wednesday mtg. ISAKMP ISAKMP should be bound to port 500 (i.e. send and receive on port 500) No need to negotiate replay window size. replay window size is 32. Increase it to a higher value later on if necesary. Situation and DOI must be included in calculating hash for the quick mode for public-key encryption, SKEYID = prf(Ni | Nr, g^xy) (it was hash(Ni | Nr). HASH(2) in Quick Mode includes the initiator's nonce. For ease of processing stick it after the message-id, i.e. HASH(2) = prf(SKEYID_a, M-ID | Ni | SA | Nr [ | KE ] [ | IDui | IDur ] ) ^^^^ From owner-ipsec Thu Apr 17 17:27:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA25759 for ipsec-outgoing; Thu, 17 Apr 1997 17:26:05 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 17 Apr 1997 15:31:03 -0600 From: John Kennedy To: ho@earth.hpc.org Cc: ipsec@tis.com Subject: Re: Small subgroups and ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk I agree with you that implementors should not have to become number theorists. Given the rather protracted development time for this family of standards I think it is advisable to nail down as much as possible in Oakley. No doubt, other key management mechanisms will be developed in the future to fit under the ISAKMP framework. In other words, I think there is a lot of wisdom to restricting the degrees of freedom offered in Oakley. Using j=2 is a nice conservative choice and any potential loss of efficiency by not allowing a larger j (i.e. smaller q) is negligible at this point. -John Kennedy >>> Hilarie Orman 04/17/97 07:42AM >>> > On the Sophie-Germaine/j=2 thing: > > Is there some reason you think having j>2 is a problem? Using a 160-bit q is not necessarily a bad thing. One reason that it is bad is that it may force implementors to become number theorists. While in the greater scheme of things, this would be a positive development, in the small it is merely quixotic. Is there some reason that j=2 is an unreasonable restriction? The only reason I can see for non-Sophie-Germaineness* is that it might be possible for one party to propose a new group of a particular type and for the recipient to verify its subgroup structure quickly (a few minutes). Hilarie Why not simply Germaine primes? No one says Emma-Noetherian rings. ! From owner-ipsec Thu Apr 17 17:59:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA25914 for ipsec-outgoing; Thu, 17 Apr 1997 17:58:53 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 17 Apr 1997 16:03:55 -0600 From: John Kennedy To: lmccarth@cs.umass.edu, ipsec@tis.com Subject: Re: Small subgroups and ISAKMP/Oakley Sender: owner-ipsec@ex.tis.com Precedence: bulk Given the nature of modular exponentiation I would expect the chances of "accidently" generating such a public number to be pretty small. In other words, I wouldn't expect there to be much value in a sender doing this check. Creating such a public number is something a communicant would do on purpose. The reason a communicant would do this is because he wants to enable a third party to listen in. As far as this being realistic, some argue that it is just as easy for the bad party to just leak the plaintext out to the third party through another channel. Thus, I think testing of the public number is something that is the responsiblity of the the receiver. Balancing the risk and cost of doing or not doing most of these different types of checks is something best left to implementors. Where there is clear value to a check that is easy to do then we should include it as mandatory. Otherwise, let the implementors make these choices based on the application, value of the information being protected, and the implementation platform. The more conservative implementors may not get market share due to performance problems, but when their competitor gets raked over the coals because they took a little "shortcut", suddenly the conservative guys look a lot better. That's what makes this business so much fun. :) -John >>> Lewis McCarthy 04/16/97 07:52PM >>> John Kennedy writes: > During X9.42 development discussion it was not necessarily a > man-in-the-middle that was feared with regards to the small sub-group > attack. Conceivably, one of the communicating parties could send a > "bad" public number on purpose. Is this a realistic scenario? One of the legitimate parties might be a broken implementation that doesn't correctly check whether it has computed a public exponential that lies in the small subgroup. -Lewis ! From owner-ipsec Fri Apr 18 09:05:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA00796 for ipsec-outgoing; Fri, 18 Apr 1997 09:00:31 -0400 (EDT) From: jryder@vnet.ibm.com Message-Id: <199704181301.JAA13339@relay.hq.tis.com> Date: Fri, 18 Apr 97 08:58:10 EDT To: IPSEC@tis.com Subject: ...IPSEC-ISAKMP-07.TXT Sender: owner-ipsec@ex.tis.com Precedence: bulk To Doug Maughan, Mark Schertler, Mark Schneider, or Jeff Turner I recognize that this comment is not of the lofty caliber of the current discussions but may I point out that on page 21, in figure 2 'ISAKMP Header Format', the initiator and responder cookies are represented as 4 octet entities? Each is described as an 8 octet entity in the rest of the document. -- Jim From owner-ipsec Fri Apr 18 09:21:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA00918 for ipsec-outgoing; Fri, 18 Apr 1997 09:19:07 -0400 (EDT) Message-Id: <199704181321.JAA13845@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM To: ipsec@tis.com X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: Edward Russell Subject: RE: CBC IV generation in ISAKMP/Oakley Date: Fri, 18 Apr 1997 09:23:48 -0400 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id JAA00915 Sender: owner-ipsec@ex.tis.com Precedence: bulk >>Shawn Mamros (smamros@newoak.com) said on 4/17/97 at 1:05 PM >The first message of a Phase 2/Quick Mode exchange uses >a hash of the last Phase 1 CBC output block output block with the >Phase 2 message ID as its IV, with later messages in that particular >exchange using the last CBC encryption block from the previous message >in the exchange. (One can read Appendix B of the -03 draft for the >rest of the details.) > Dan, How does this solve the IV situation when there are two simultaneous quick modes going on. We had discussed a while ago that if each side is negotiating a quick mode with each other simultaneously (which can happen if SAs expire at the sime time) there's no way that using the last CBC encryption block from the previous message in the exchange would work. You had indicated that this was solved in V3. I don't see the solution. Edward Russell erussell@ftp.com From owner-ipsec Fri Apr 18 09:21:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA00924 for ipsec-outgoing; Fri, 18 Apr 1997 09:19:37 -0400 (EDT) From: jryder@vnet.ibm.com Message-Id: <199704181320.JAA14013@relay.hq.tis.com> Date: Fri, 18 Apr 97 09:23:41 EDT To: IPSEC@tis.com Subject: Cookies Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm sorry. I didn't take into account the 2 !'s worth of vertical page space. Please disregard my previous comment. -- Jim From owner-ipsec Fri Apr 18 09:26:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA00985 for ipsec-outgoing; Fri, 18 Apr 1997 09:26:16 -0400 (EDT) Message-Id: <9704181331.AA15062@cichlid.raleigh.ibm.com> To: dpkemp@missi.ncsc.mil (David P. Kemp) Cc: ipsec@tis.com Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt In-Reply-To: Your message of "Thu, 17 Apr 1997 09:17:30 EDT." <199704171317.JAA21004@argon.ncsc.mil> Date: Fri, 18 Apr 1997 09:31:20 -0300 From: Thomas Narten Sender: owner-ipsec@ex.tis.com Precedence: bulk > Perhaps I am missing something important, but I've never understood the > justification for negotiating replay window sizes. I also agree, and have been disheartened by the number of times the above question has been asked but not answered. Indeed, it has been my impression that the vast majority of IP packets are delivered in order (one reason why TCP's header prediction works well in practice). It is rare in practice to have packets arrive out of order. Which begs the question of whether a window is even needed. Does someone have data that argues otherwise? In any case, this is certainly a receiver issue *only*. Thomas From owner-ipsec Fri Apr 18 09:53:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA01158 for ipsec-outgoing; Fri, 18 Apr 1997 09:53:25 -0400 (EDT) Date: Fri, 18 Apr 1997 09:59:07 -0400 Message-Id: <9704181359.AA18730@ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Thomas Narten , dpkemp@missi.ncsc.mil (David P. Kemp) From: Naganand Doraswamy Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk At 09:31 AM 4/18/97 -0300, Thomas Narten wrote: >> Perhaps I am missing something important, but I've never understood the >> justification for negotiating replay window sizes. > >I also agree, and have been disheartened by the number of times the >above question has been asked but not answered. Indeed, it has been >my impression that the vast majority of IP packets are delivered in >order (one reason why TCP's header prediction works well in >practice). It is rare in practice to have packets arrive out of >order. Which begs the question of whether a window is even >needed. Does someone have data that argues otherwise? > This issue has been resolved. The replay window isnot negotiated any more and it is upto the receiver to decide what size to use. The recommended size is 32. Naganand From owner-ipsec Fri Apr 18 10:25:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01377 for ipsec-outgoing; Fri, 18 Apr 1997 10:24:12 -0400 (EDT) Message-Id: <199704181426.KAA08328@raptor.research.att.com> To: Thomas Narten cc: dpkemp@missi.ncsc.mil (David P. Kemp), ipsec@tis.com Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt Date: Fri, 18 Apr 1997 10:26:58 -0400 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk > Perhaps I am missing something important, but I've never understood the > justification for negotiating replay window sizes. I also agree, and have been disheartened by the number of times the above question has been asked but not answered. Indeed, it has been my impression that the vast majority of IP packets are delivered in order (one reason why TCP's header prediction works well in practice). It is rare in practice to have packets arrive out of order. Which begs the question of whether a window is even needed. Does someone have data that argues otherwise? Yes, there is data. I've heard Vern Paxson's talk on his measurements, and a reasonably high percentage of TCP connections do see out-of-order packets. Furthermore, since dropped packets have a very serious effect on TCP throughput, it's really worth some effort to avoid any extra drops. The incidence of out-of-order delivery seems to depend on the site involved. This suggests that it's useful if a site can tune its own replay window. (There was at least one incident where a window of *54* would have been necessary to accept the packet!) Vern felt that currently, a window of 32 was quite sufficient. But it does seem prudent to plan ahead for 64 some day. In any case, this is certainly a receiver issue *only*. Yes. I still don't understand what a sender can possibly do differently, even if a receiver indicates that it needs a larger replay window. From owner-ipsec Fri Apr 18 11:12:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA01683 for ipsec-outgoing; Fri, 18 Apr 1997 11:12:15 -0400 (EDT) Message-Id: <199704181515.LAA07342@amaterasu.sandelman.ottawa.on.ca> To: anx-sec@dot.netrex.net Reply-To: ipsec@tis.com CC: ipsec@tis.com Subject: Re: introduction; certificates & proxy authentication. In-reply-to: Your message of "Thu, 17 Apr 1997 16:59:36 EDT." <199704172059.QAA00244@thunk.ch.apollo.hp.com> Date: Fri, 18 Apr 1997 11:15:02 -0400 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bill" == Bill Sommerfeld writes: Bill> Now, perhaps the following belongs on the ipsec WG list, but Bill> since the topic came up on the conference call today. Yes, it *does* belong on ipsec. Will you repost to ipsec? Bill> For instance, you may have a network looking vaguely like: Bill> user <-> GWA <-> GWB ... Bill> where user already has set up SA's with GWA, and GWA is Bill> negotiating with GWB and proxying for `user'. Bill> Now, certificates bind a set of attributes to a public key, Bill> and implicitly link those attributes to the *holder* of the Bill> private part of that key; there's not much point in passing Bill> around a certificate except to link the attributes in the Bill> certificate to something signed by the certified key. This was the crux of my point in Montreal. I am still hoping that Bob will release his document RSN. I (at least) never got a copy of his requirements document for his "challenge" either... I have come to the conclusion that this signature shall be done out of band to ISAKMP for now. Bill> I don't see any place where a protocol is defined which Bill> allows `GWA' to ask `user' to sign something destined for Bill> GWB, to prove to GWB that the user is really there.. Merely Bill> forwarding the cert doesn't prove anything; GWA could have Bill> pulled the cert out of the certificate directory.. There needs to be certificates which grant "gateway" or "firewall" authority from "user" to "GWA". This is one of the most important certificates that the IPSEC group has to define later this summer. (Does the chair agree that this is important work, and to the timing of this work?) Bill> So, is the model that GWB trusts GWA's claim that `user' has Bill> successfully authenticated to GWA? If so, this may be Bill> expedient, but I don't think it's a scalable trust model.. Bill> What am I missing? Nothing I think. You are bang on. :!mcr!: | Network security consulting and Michael Richardson | contract programming WWW: mcr@sandelman.ottawa.on.ca. PGP key available. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBM1eP7qZpLyXYhL+BAQFXmwMAwSnPxu4aHkcosT9xOvrGtl3akcrzqk3s tHKA74HRf3KPD+Gr4yM859RECrDYvoHyjBpamIIi1kaSKQdCQnjqScnMrWfUCrJA 4nZjCXP3T3rsDy1NDwM8lpi5TWUYy5bG =iw/g -----END PGP SIGNATURE----- From owner-ipsec Fri Apr 18 11:32:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA01798 for ipsec-outgoing; Fri, 18 Apr 1997 11:31:54 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199704171157.HAA21287@portal.ex.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Apr 1997 11:37:44 -0500 To: David Carrel From: Stephen Kent Subject: Re: notes from developer's portion of IETF meeting Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dave, The implementors' meeting notes say that the proposal for encryption as an optional aspect of ESP was rejected, yet no rationale was provided. I was surprized to see this recommendation from this group since I briefed this notion back in San Jose and received no negative feedback at that time, nor do I recall any negative feedback on the list since then, with the exception of one message from Ran. Since I expect to see noticeable performance differences between AH and ESP authentication, because of the complexity of omitting some fields from the calculation in AH, I'm surprized that implementors would not consider encryptionless ESP to be an attractive feature for clients. Also, in light of the message from Charlie Lynn, it would seem that ESP w/o encryption provides an important facility in various contexts. So, why did this group recommend not supporting that security service combination for ESP? Also under the optional encryption heading, there is a mantion of tunnel mode needing to be described in the AH specs. Since the current AH I-D contains an extensive tunnel mode discussion, to what do these notes refer? The anti-replay notes do not distinguish between AH and ESP. Is the intent that this field is mandatory in ESP too, if authentication is negotiated? As for the IV comments, these too seem odd to me. Not all encryption modes require an IV, yet your notes suggest otherwise. Both the presence and size of an IV is an algorithm/mode dependent feature. The suggested requirement would undermine the algorithm independence of ESP. What I assumed the group was moving toward is collapsing the IV into the payload field (for ESP with encryption) to avoid having another optional field in the header, a suggestion voiced by Steve Bellovin. Steve From owner-ipsec Fri Apr 18 11:32:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA01797 for ipsec-outgoing; Fri, 18 Apr 1997 11:31:53 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199704171317.JAA21004@argon.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Apr 1997 11:31:42 -0500 To: dpkemp@missi.ncsc.mil (David P. Kemp) From: Stephen Kent Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dave, You raise two points that I'll address separately: - it is true that the AR window protects the receiver, and imposes no changes in how the sender operates. However, I think that the use or non-use of use of AR is of interest to the sender. If communication performance problems arise between two IPSEC sites, one reason might be the rejection of some number of packets due to the size of the AR and the out-of-order delivery characteristics associated with the path. Certainly, if a default window size of 1 were adopted (as had been suggested), there would be a significant opportunity for such behavior. However, if the use of AR is purely at the discretion of the receiver, I have no way of knowing if that might be a problem, if I am troubleshooting the problem from the sender's end. So, at a minimum, I'd like to know if AR is a characteristic of each SA. With a minimum window size of 32, excessive packet rejection (leading to performance problems) seems unlikely, but it may not be impossible for paths with long delay pipes. If I were responsible for the management of the sending end of the IPSEC SA being affected, I'd like to be able to determine the window size in use by the receiver. If the window size in use by the receiver was merely reported as a side effect of SA establishment (vs. being negotiated) that would suffice. However, this seemed less in keeping with the general SA parameter management philosophy we've adopted. Also, the sender may have more knowledge about the nature of the application using the SA and, if source routing is employed, may know more about the path being used, and hence may be better equipped to suggest an appropriate windwo size, i.e., one that is less likely to experience problems due to substantial out-of-order arrivals. Maybe that's pushing the point, but it would argue for sender input into a window size negotiaion. Yes, always carrying the field, and always maintaining the counter and letting the receiver dedice whether to pay attention is the simplest approach in some respects. But leaving the sender not knowing the security characteristics of an SA is bothersome. It also suggests that conformamce testing is hard (or maybe just useless?), as any behavior by the receiver would appear to be OK re AR! Steve From owner-ipsec Fri Apr 18 11:39:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA01876 for ipsec-outgoing; Fri, 18 Apr 1997 11:38:54 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <9704181359.AA18730@ftp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Apr 1997 11:45:07 -0500 To: Naganand Doraswamy From: Stephen Kent Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Naganand, I just want to point out that the WG is not composed exclusively of attendees at IETF meetings and thus the anti-replay issue is not necessarily resolved. We've had discussions on the list and there were discissions at the WG meetings and the two don't necessarily seem to be completely consistent yet. maybe a straw poll will be required, but let's see how messages sort out over the next week before we state too strongly that this issie is closed. Steve From owner-ipsec Fri Apr 18 11:46:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA01937 for ipsec-outgoing; Fri, 18 Apr 1997 11:44:58 -0400 (EDT) Message-Id: <199704181550.IAA12511@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Edward Russell Cc: ipsec@tis.com Subject: Re: CBC IV generation in ISAKMP/Oakley In-Reply-To: Your message of "Fri, 18 Apr 1997 09:23:48 EDT." <199704181321.JAA13845@MAILSERV-2HIGH.FTP.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Apr 1997 08:50:33 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Ed Russell wrote: > >Shawn Mamros (smamros@newoak.com) said on 4/17/97 at 1:05 PM > >The first message of a Phase 2/Quick Mode exchange uses > >a hash of the last Phase 1 CBC output block output block with the > >Phase 2 message ID as its IV, with later messages in that particular > >exchange using the last CBC encryption block from the previous message > >in the exchange. (One can read Appendix B of the -03 draft for the > >rest of the details.) > > How does this solve the IV situation when there are two simultaneous > quick modes going on. We had discussed a while ago that if each side > is negotiating a quick mode with each other simultaneously (which can > happen if SAs expire at the sime time) there's no way that using the last CBC > encryption block from the previous message in the exchange would work. > You had indicated that this was solved in V3. I don't see the solution. The IV for Quick Mode is hash(phase1-IV | message-ID). Since the message-ID is unique for each quick mode the IV will be different. This is the IV for this Quick Mode, after it's over the IV and all associated state goes away. The next Quick Mode has another (new and different) IV. If two start simultaneously they'll each have a different IV. The message-id in the header lets you identify the state (incl. the IV) for this particular exchange. The IVs are still running, there is a defined start (so each side has the same one) but after processing each Quick Mode packet it changes until the Quick Mode ends then it goes away. Dan. From owner-ipsec Fri Apr 18 12:13:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA02116 for ipsec-outgoing; Fri, 18 Apr 1997 12:12:41 -0400 (EDT) Message-Id: <199704181618.JAA12563@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ipsec@tis.com, anx-sec@dot.netrex.net Subject: Re: introduction; certificates & proxy authentication. In-Reply-To: Your message of "Fri, 18 Apr 1997 11:15:02 EDT." <199704181515.LAA07342@amaterasu.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Apr 1997 09:18:09 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk > There needs to be certificates which grant "gateway" or "firewall" > authority from "user" to "GWA". This is one of the most important > certificates that the IPSEC group has to define later this > summer. (Does the chair agree that this is important work, and to the > timing of this work?) How about adding another record in (secure) DNS analogous to the MX record? This thing (KX?) would say "if you want to talk to blah.cisco.com negotiate with gw1.cisco.com or gw2.cisco.com". That idea has been floated around several times. It solves the problem and scales beautifully. It seems better than defining another certificate. And isn't SPKI doing that work anyway? Dan. From owner-ipsec Fri Apr 18 12:33:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA02211 for ipsec-outgoing; Fri, 18 Apr 1997 12:31:30 -0400 (EDT) Message-Id: <01BC4BF5.3F239AE0@erussell-2.ftp.com> From: "Edward A. Russell" To: "'ipsec@tis.com'" , "'Daniel Harkins'" Subject: RE: CBC IV generation in ISAKMP/Oakley Date: Fri, 18 Apr 1997 12:37:14 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk ---------- From: Daniel Harkins[SMTP:dharkins@cisco.com] Sent: Friday, April 18, 1997 11:51 AM To: Edward Russell Cc: ipsec@tis.com Subject: Re: CBC IV generation in ISAKMP/Oakley > The IV for Quick Mode is hash(phase1-IV | message-ID). Since the message-ID >is unique for each quick mode the IV will be different. This is the IV >for this Quick Mode, after it's over the IV and all associated state >goes away. The next Quick Mode has another (new and different) IV. If >two start simultaneously they'll each have a different IV. The message-id >in the header lets you identify the state (incl. the IV) for this particular >exchange. The IVs are still running, there is a defined start (so each side >has the same one) but after processing each Quick Mode packet it changes >until the Quick Mode ends then it goes away. > Dan. O.K. It still makes me nervous that the "running" is dependent on messages not passing in the night. What if each side decides to send notifies simultaneously within the same Main Mode. I guess that goes along with what Shawn was referring to. I almost wish the IV were the last block of the CURRENT message, but that's the same as sending the IV along with the message (in fact it is). Ed Russell erussell@ftp.com From owner-ipsec Fri Apr 18 13:11:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA02541 for ipsec-outgoing; Fri, 18 Apr 1997 13:10:52 -0400 (EDT) Message-Id: <199704181716.NAA00721@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: ipsec@tis.com Subject: certificates & proxy authentication. Date: Fri, 18 Apr 1997 13:16:46 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk [This is the message which Michael Richardson was referring to.. As he said, I wasn't missing anything; proxy identities are merely assertions by the proxy.] There was some discussion of proxy authentication in ISAKMP, which is mentioned in passing in a couple places in the drafts, but is not discussed in very much detail. It appears the functionality is intended to be used to allow a gateway to act as a proxy for a principal behind the gateway; the gateway presents its identity and the identity of the principal (user or host) behind the gateway. For instance, you may have a network looking vaguely like: user <-> GWA <-> GWB ... where user already has set up SA's with GWA, and GWA is negotiating with GWB and proxying for `user'. Now, certificates bind a set of attributes to a public key, and implicitly link those attributes to the *holder* of the private part of that key; there's not much point in passing around a certificate except to link the attributes in the certificate to something signed by the certified key. I don't see any place where a protocol is defined which allows `GWA' to ask `user' to sign something destined for GWB, to prove to GWB that the user is really there.. Merely forwarding the cert doesn't prove anything; GWA could have pulled the cert out of the certificate directory.. So, is the model that GWB trusts GWA's claim that `user' has successfully authenticated to GWA? If so, this may be expedient, but I don't think it's a scalable trust model.. What am I missing? - Bill From owner-ipsec Fri Apr 18 13:42:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA02682 for ipsec-outgoing; Fri, 18 Apr 1997 13:39:37 -0400 (EDT) Message-Id: <9704181745.AA17250@cichlid.raleigh.ibm.com> To: Steven Bellovin Cc: dpkemp@missi.ncsc.mil (David P. Kemp), ipsec@tis.com, Vern Paxson Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt In-Reply-To: Your message of "Fri, 18 Apr 1997 10:26:58 EDT." <199704181426.KAA08328@raptor.research.att.com> Date: Fri, 18 Apr 1997 13:45:07 -0300 From: Thomas Narten Sender: owner-ipsec@ex.tis.com Precedence: bulk Steven Bellovin writes: > Yes, there is data. I've heard Vern Paxson's talk on his measurements, > and a reasonably high percentage of TCP connections do see out-of-order > packets. Furthermore, since dropped packets have a very serious effect > on TCP throughput, it's really worth some effort to avoid any extra drops. > The incidence of out-of-order delivery seems to depend on the site > involved. This suggests that it's useful if a site can tune its own > replay window. (There was at least one incident where a window of *54* > would have been necessary to accept the packet!) This is very useful data/rational to have. I certainly hope suitable (discussion) text along these lines makes it into the draft. Also, is there a pointer to Vern's measurements on this particular topic? Thomas From owner-ipsec Fri Apr 18 14:11:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA02864 for ipsec-outgoing; Fri, 18 Apr 1997 14:11:28 -0400 (EDT) Message-Id: <199704181817.LAA12734@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Thomas Narten Cc: dpkemp@missi.ncsc.mil (David P. Kemp), ipsec@tis.com Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt In-Reply-To: Your message of "Fri, 18 Apr 1997 09:31:20 -0300." <9704181331.AA15062@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Apr 1997 11:17:12 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Now perhaps I'm missing something.... > > Perhaps I am missing something important, but I've never understood the > > justification for negotiating replay window sizes. > > I also agree, and have been disheartened by the number of times the > above question has been asked but not answered. Indeed, it has been > my impression that the vast majority of IP packets are delivered in > order (one reason why TCP's header prediction works well in > practice). It is rare in practice to have packets arrive out of > order. Which begs the question of whether a window is even > needed. Does someone have data that argues otherwise? The replay window is not meant to address the issue of packets arriving out-of-order it's meant to address an attack where a previously processed packet is replayed by some attacker forcing the receiver to spin his wheels authenticating and possibly decrypting a packet which he's already authenticated and possibly decrypted. Out-or-order packets can be handled just fine by IPsec. I will 2nd that emotion, though, that negotiating a replay window size is silly. Dan. From owner-ipsec Fri Apr 18 15:13:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA03242 for ipsec-outgoing; Fri, 18 Apr 1997 15:11:47 -0400 (EDT) Message-ID: <01BC4BF4.54CB6310@BIGHUGE> From: Rob Adams To: "'Stephen Kent'" , David Carrel Cc: "ipsec@tis.com" Subject: RE: notes from developer's portion of IETF meeting Date: Fri, 18 Apr 1997 12:30:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk -----Original Message----- From: Stephen Kent [SMTP:kent@bbn.com] Sent: Friday, April 18, 1997 9:38 AM To: David Carrel Cc: ipsec@tis.com Subject: Re: notes from developer's portion of IETF meeting Dave, The implementors' meeting notes say that the proposal for encryption as an optional aspect of ESP was rejected, yet no rationale was provided. I was surprized to see this recommendation from this group since I briefed this notion back in San Jose and received no negative feedback at that time, nor do I recall any negative feedback on the list since then, with the exception of one message from Ran. Since I expect to see noticeable performance differences between AH and ESP authentication, because of the complexity of omitting some fields from the calculation in AH, I'm surprized that implementors would not consider encryptionless ESP to be an attractive feature for clients. Also, in light of the message from Charlie Lynn, it would seem that ESP w/o encryption provides an important facility in various contexts. So, why did this group recommend not supporting that security service combination for ESP? My belief is that the slight gain in performance that you get from not hashing over the headers isn't worth another option. If you want integrity, use AH. If we're going to go this route, why not bag AH and always do ESP with an option for header inclusion in the integrity calculation? One option is the same as another at this point. I'm not suggesting this because I think it is too late for this magnitude of change, but it would reduce the complexity. Also under the optional encryption heading, there is a mantion of tunnel mode needing to be described in the AH specs. Since the current AH I-D contains an extensive tunnel mode discussion, to what do these notes refer? I think this is in reference to the next point that ESP without AH is more or less useless. If you do ESP without AH you have to at least wrap the thing in an AH tunnel. I might be stupid here but this is what I remember. Ran, do you recall what we decided here? You came up with the proposed solution to this problem if I recall correctly, and at the time it struck me as very well put and spot on. The anti-replay notes do not distinguish between AH and ESP. Is the intent that this field is mandatory in ESP too, if authentication is negotiated? Not negotiated, always sent, regardless of use. Since we require the packet to have some sort of integrity (tunnel or otherwise) there is no sense in not sending the replay field. As for the IV comments, these too seem odd to me. Not all encryption modes require an IV, yet your notes suggest otherwise. Both the presence and size of an IV is an algorithm/mode dependent feature. The suggested requirement would undermine the algorithm independence of ESP. What I assumed the group was moving toward is collapsing the IV into the payload field (for ESP with encryption) to avoid having another optional field in the header, a suggestion voiced by Steve Bellovin. IV is specific to the algorithm correct, and your last assumption about moving the IV into the payload field is also correct. This comment had a lot to do with the Hughes transform. We decided to bag the fixed IV you get from key mangling that Hughes originally did. And because of other changes to the format, fixed IV's in this context are now deemed very bad. Therefore, for what was Hughes, we decided to always send the IV. Somone correct me if I blew it on any of these questions -Rob From owner-ipsec Fri Apr 18 16:23:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA03617 for ipsec-outgoing; Fri, 18 Apr 1997 16:21:19 -0400 (EDT) Message-ID: <01BC4BFE.0833F350@BIGHUGE> From: Rob Adams To: "'Stephen Kent'" , "'David Carrel'" Cc: "'ipsec@tis.com'" Subject: RE: notes from developer's portion of IETF meeting Date: Fri, 18 Apr 1997 13:39:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk After getting a few complaints about the format of my message, I'm sending it again.. Sorry, Microsoft Outlook got me.. I didn't realize that the formatting I see isn't what I actually got back when I received my own reply.... Here it is again.. sorry for the inconvience.. > -----Original Message----- > From: Stephen Kent [SMTP:kent@bbn.com] > Sent: Friday, April 18, 1997 9:38 AM > To: David Carrel > Cc: ipsec@tis.com > Subject: Re: notes from developer's portion of IETF meeting > Dave, > The implementors' meeting notes say that the proposal for >encryption as an optional aspect of ESP was rejected, yet no rationale was >provided. I was surprized to see this recommendation from this group since >I briefed this notion back in San Jose and received no negative feedback at >that time, nor do I recall any negative feedback on the list since then, >with the exception of one message from Ran. Since I expect to see >noticeable performance differences between AH and ESP authentication, >because of the complexity of omitting some fields from the calculation in >AH, I'm surprized that implementors would not consider encryptionless ESP >to be an attractive feature for clients. Also, in light of the message >from Charlie Lynn, it would seem that ESP w/o encryption provides an >important facility in various contexts. So, why did this group recommend >not supporting that security service combination for ESP? My belief is that the slight gain in performance that you get from not hashing over the headers isn't worth another option. If you want integrity, use AH. If we're going to go this route, why not bag AH and always do ESP with an option for header inclusion in the integrity calculation? One option is the same as another at this point. I'm not suggesting this because I think it is too late for this magnitude of change, but it would reduce the complexity. > Also under the optional encryption heading, there is a mantion of >tunnel mode needing to be described in the AH specs. Since the current AH >I-D contains an extensive tunnel mode discussion, to what do these notes >refer? I think this is in reference to the next point that ESP without AH is more or less useless. If you do ESP without AH you have to at least wrap the thing in an AH tunnel. I might be stupid here but this is what I remember. Ran, do you recall what we decided here? You came up with the proposed solution to this problem if I recall correctly, and at the time it struck me as very well put and spot on. > The anti-replay notes do not distinguish between AH and ESP. Is >the intent that this field is mandatory in ESP too, if authentication is >negotiated? Not negotiated, always sent, regardless of use. Since we require the packet to have some sort of integrity (tunnel or otherwise) there is no sense in not sending the replay field. > As for the IV comments, these too seem odd to me. Not all >encryption modes require an IV, yet your notes suggest otherwise. Both the >presence and size of an IV is an algorithm/mode dependent feature. The >suggested requirement would undermine the algorithm independence of ESP. >What I assumed the group was moving toward is collapsing the IV into the >payload field (for ESP with encryption) to avoid having another optional >field in the header, a suggestion voiced by Steve Bellovin. IV is specific to the algorithm correct, and your last assumption about moving the IV into the payload field is also correct. This comment had a lot to do with the Hughes transform. We decided to bag the fixed IV you get from key mangling that Hughes originally did. And because of other changes to the format, fixed IV's in this context are now deemed very bad. Therefore, for what was Hughes, we decided to always send the IV. Somone correct me if I blew it on any of these questions -Rob From owner-ipsec Sat Apr 19 15:46:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA09308 for ipsec-outgoing; Sat, 19 Apr 1997 15:42:11 -0400 (EDT) Date: Sat, 19 Apr 1997 15:48:03 -0400 (EDT) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199704161309.JAA20179@argon.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: dpkemp@missi.ncsc.mil (David P. Kemp) From: Stephen Kent Subject: Re: Predictable SPIs (was: Re: A pothole in ISAKMP/Oakley) Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk David, I like your suggestion re unpredictable SPIs and easy indexing, but it does seem that there is a minor vulnerability. If I am not able to establish an SA to the target IPSEC implementation (and we assume that passive wiretapping of valid SPIs is not generally feasible), then the approach you describe does allow for easy indexing into an SPI table, while making SPI values hard to guess. However, if I can establish one such SA, then I'll know the range in which the SPIs are being generated (since they must be in the neighborhood of the one I have). Thus, there is an opportunity for me to use this info to generate probably SPIs that could be inserted into packets carrying spurious source addresses, to divert attention away from me as an attacker. If the implementation is robust, then the random offset would be relatively long lived, and thus this vulnerability might be exploitable for some time. Another concern arises relative to the ease of getting any valid SPI from an implemenattion. I don't recall at what point in an ISAKMP exchange does the target of an SA transmit the SPI that the initiator will employ? Can an attacker manage to get the SPI without successfully completing the exchange? If so, it might be easy for an attacker to get a valid SPI to use as input to the sort of attack I noted above. Steve From owner-ipsec Mon Apr 21 07:41:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA19425 for ipsec-outgoing; Mon, 21 Apr 1997 07:33:22 -0400 (EDT) Message-Id: <199704211133.HAA19425@portal.ex.tis.com> To: Thomas Narten Cc: Steven Bellovin , dpkemp@missi.ncsc.mil (David P. Kemp), ipsec@tis.com Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt In-reply-to: Your message of Fri, 18 Apr 1997 13:45:07 PDT. Date: Fri, 18 Apr 1997 22:38:26 PDT From: Vern Paxson Sender: owner-ipsec@ex.tis.com Precedence: bulk A draft paper that discusses out-of-order delivery, among a bunch of other things, is available from: ftp://ftp.ee.lbl.gov/.vp-pkt-dyn-sigcomm-draft.ps.gz A revised version will by available by the end of May (to appear in SIGCOMM '97). The out-of-order results won't be changed much. I filed my dissertation today, and will have an on-line version of it available shortly. It goes into greater detail than the paper (naturally!). Something to keep in mind is that large reordering events will often lead to unnecessary retransmissions anyway, because the out-of-order packets will cause duplicate acks that in turn trigger fast retransmission. So if this is aggravated by dropping some packets on the floor due to other reasons, it may not actually cause much of an *additional* performance hit. Steve & I discussed this a couple of weeks ago. As I recall, the question is whether accommodating reorderings of up to 32 packets suffices. It should - while larger reorderings can happen, they are very rare (at least in today's Internet), and furthermore will already cause performance problems, as noted above. > > The incidence of out-of-order delivery seems to depend on the site Right, it's strongly site-specific. Some sites see a whole lot of reordering and some see very little. This is because some sites have load-balancing routing near them and others don't. Also, some sites are much more prone to large reordering events than are others, which is due to their proximity to certain types of routers (though I haven't identified the make) that are much more prone to causing such events than are others. Vern From owner-ipsec Mon Apr 21 17:22:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA23661 for ipsec-outgoing; Mon, 21 Apr 1997 17:19:51 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <01BC4BFE.0833F350@BIGHUGE> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 21 Apr 1997 17:29:05 -0400 To: Rob Adams From: Stephen Kent Subject: RE: notes from developer's portion of IETF meeting Cc: "ipsec@tis.com" Sender: owner-ipsec@ex.tis.com Precedence: bulk ROb, Thanks for the responses. Let me see if I can follow through on your comments to help close the loop on these matters: >> The implementors' meeting notes say that the proposal for >>encryption as an optional aspect of ESP was rejected, yet no rationale was >>provided. I was surprized to see this recommendation from this group since >>I briefed this notion back in San Jose and received no negative feedback at >>that time, nor do I recall any negative feedback on the list since then, >>with the exception of one message from Ran. Since I expect to see >>noticeable performance differences between AH and ESP authentication, >>because of the complexity of omitting some fields from the calculation in >>AH, I'm surprized that implementors would not consider encryptionless ESP >>to be an attractive feature for clients. Also, in light of the message >>from Charlie Lynn, it would seem that ESP w/o encryption provides an >>important facility in various contexts. So, why did this group recommend >>not supporting that security service combination for ESP? > >My belief is that the slight gain in performance that you get from not hashing >over the headers isn't worth another option. If you want integrity, use >AH. If >we're going to go this route, why not bag AH and always do ESP with an option >for header inclusion in the integrity calculation? One option is the same as >another at this point. I'm not suggesting this because I think it is too >late >for this magnitude of change, but it would reduce the complexity. Use of AH is not the same as use of ESP w/o encryption, precisely because of the coverage issue, and the associated performance hit. Remember that to compute AH , one must perform the logical equivalent of copying the IP header (and all options) over to a new buffer, then zeroing each header field that is always excluded, then examine every option to see if it is included or excluded. For IPv6, with more header extentions/options/etc. this might be come a more time consuming task. My guess is that use of ESP in tunnel mode will be popular, with one end of the SA at a firewall. Under those circumstances, AH in tunnel mode does not buy one much, because the outer header is not very interesting, i.e., it will be discarded. (Only rarely would it make sense to copy portions of it into an inner header.) Thus tunnel mode ESP would provide suitable protection for traffic with greater efficiency and less per-packet overhead. What I'm hearing from this discussion is that the motivation for not offering ESP w/o encryption is added complexity. I'm all in favor of reducing complexity, if it doesn't cost functionality, but I'm really surprized to hear that offering ESP w/o encryption is percieved as a significant increase in complexity. >> Also under the optional encryption heading, there is a mantion of >>tunnel mode needing to be described in the AH specs. Since the current AH >>I-D contains an extensive tunnel mode discussion, to what do these notes >>refer? > >I think this is in reference to the next point that ESP without AH is more >or less >useless. If you do ESP without AH you have to at least wrap the thing in >an AH >tunnel. I might be stupid here but this is what I remember. Ran, do you >recall >what we decided here? You came up with the proposed solution to this problem >if I recall correctly, and at the time it struck me as very well put and >spot on. I assume you meat to say that ESP with authentication was useless, but I have to disagree. I know folks who are sending packet voice and packet video on an end-to-end basis. I recommend use of ESP w/o authentication in this context. With an appropriate encryption mode (such as CBC), the nature of the application makes it unlikely that one can twiddle bits in an effective manner, given use of a suitable encryption mode (e.g., CBC). Also, since people are the consumers of this data, we can rely on them to discard obviously errored traffic. Reordering and replay will be detected by the builtin timestamp facility. However, per-packet overhead is a big concern here and thus stripping out everyting but the encryption support is an important feature. Thus the flexibility offered by modular use of ESP and AH is important to these folks and is in keeping with the original intent of IPSEC. >> The anti-replay notes do not distinguish between AH and ESP. Is >>the intent that this field is mandatory in ESP too, if authentication is >>negotiated? > >Not negotiated, always sent, regardless of use. Since we >require the packet to have some sort of integrity (tunnel or otherwise) >there is no sense in not sending the replay field. I sent a separate message arguing for why I'd like to be able to negotiate use of AR for eithe protocol, although I can see merit to adopting a default window size of 32 to minimize the need for negotiating a window size. However, the comment about "no sense in not sending the replay" counter since integrity is always rerquired puzzles me. As noted above, I can cite real applications where encryption w/o authenitcation is appropriate. Sending it takes up space that may be critical to such applications, especially when it's not going to be used. I think the better argument is that AR counter inclusion makes alignment "work" for AH in the IPv6 context, and in ESP this inclusion aligns the start of the payload (assuming that we fold the IV into the payload) on an 8-byte boundary as well, to facilitate crypto processing. Also, by always sending this field, one simplifies packet parsing, by eliminating variability. If these are the reasons for mandating inclusion of the AR counter in every AH and ESP packet, then so be it, but at least lets agree on a rationale that makes it clear what tradeoffs were considered in coming to this conclusion. Also, even if we do include it in every packet, for these alignment and parsing reasons, whether we negotiate use of the field > >> As for the IV comments, these too seem odd to me. Not all >>encryption modes require an IV, yet your notes suggest otherwise. Both the >>presence and size of an IV is an algorithm/mode dependent feature. The >>suggested requirement would undermine the algorithm independence of ESP. >>What I assumed the group was moving toward is collapsing the IV into the >>payload field (for ESP with encryption) to avoid having another optional >>field in the header, a suggestion voiced by Steve Bellovin. > >IV is specific to the algorithm correct, and your last assumption >about moving the IV into the payload field is also correct. This comment had >a lot to do with the Hughes transform. We decided to bag the fixed IV you get >from key mangling that Hughes originally did. And because of other changes >to the format, fixed IV's in this context are now deemed very bad. Therefore, >for what was Hughes, we decided to always send the IV. This clarifies the last comment. In general I propose that we remove the IV as an explcit, optional field and fold it into the beginning of the payload. The text will be modified to state this convention, noting that each algorithm document must state the presence/absence of an IV (or a sequence space pointer for some types of stream ciphers) and the size of the IV. That way we can keep the ESP document simple and algorithm independent. Steve From owner-ipsec Tue Apr 22 10:23:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA29321 for ipsec-outgoing; Tue, 22 Apr 1997 10:16:03 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-mcdonald-pf-key-v2-02.txt Date: Tue, 22 Apr 1997 09:39:54 -0400 Message-ID: <9704220939.aa26685@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : PF_KEY Key Management API, Version 2 Author(s) : D. McDonald, C. Metz, B Phan Filename : draft-mcdonald-pf-key-v2-02.txt Pages : 14 Date : 04/21/1997 A generic key management API that can be used not only for IP Security [Atk95a] [Atk95b] [Atk95c] but also for other network security services is presented in this document. Version 1 of this API was implemented inside 4.4-Lite BSD as part of the U. S. Naval Research Laboratory's freely distributable and usable IPv6 and IPsec implementation[AMPMC96]. It is documented here for the benefit of thers who might also adopt and use the API, thus providing increased portability of key management applications (e.g. an ISAKMP daemon, a Photuris daemon or SKIP certificate discovery protocol daemon). 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-mcdonald-pf-key-v2-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-mcdonald-pf-key-v2-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-mcdonald-pf-key-v2-02.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19970421155501.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mcdonald-pf-key-v2-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-mcdonald-pf-key-v2-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970421155501.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Apr 22 11:12:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA29688 for ipsec-outgoing; Tue, 22 Apr 1997 11:05:25 -0400 (EDT) Message-Id: <199704221509.LAA19920@amaterasu.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: notes from developer's portion of IETF meeting In-reply-to: Your message of "Mon, 21 Apr 1997 17:29:05 EDT." Date: Tue, 22 Apr 1997 11:09:22 -0400 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Stephen" == Stephen Kent writes: Stephen> consuming task. My guess is that use of ESP in tunnel Stephen> mode will be popular, with one end of the SA at a Stephen> firewall. Under those circumstances, AH in tunnel mode Stephen> does not buy one much, because the outer header is not Stephen> very interesting, i.e., it will be discarded. (Only Stephen> rarely would it make sense to copy portions of it into an Stephen> inner header.) Thus tunnel mode ESP would provide Stephen> suitable protection for traffic with greater efficiency Stephen> and less per-packet overhead. What I'm hearing from this Stephen> discussion is that the motivation for not offering ESP Stephen> w/o encryption is added complexity. I'm all in favor of As long as you are optimizing in favour of the VPN application, then let's be explicit and do that. The reason why ESP without encryption is not interesting is because the P in VPN means private. If there comes to exist a strong encrypting transform with built in integrity, VPN people will want that. Stephen> reducing complexity, if it doesn't cost functionality, Stephen> but I'm really surprized to hear that offering ESP w/o Stephen> encryption is percieved as a significant increase in Stephen> complexity. We know AH is complex. Fine. AH isn't interesting for VPN applications. Fine. Let's allow a VPN-only to deal with lower complexity, and do only what it needs to do. That means it might not do AH. It will encrypt. I realize that is in oposition to the IPv6 MUST implement (AH, but not ESP). An encryption-less ESP could then become a MUST implement for IPv6. Remember: fewer options == interoperability. Stephen> support is an important feature. Thus the flexibility Stephen> offered by modular use of ESP and AH is important to Stephen> these folks and is in keeping with the original intent of Stephen> IPSEC. Authentication-less ESP was left as an option. I'm not sure I completely agree that audio data is not that sensitive to integrity problems, but I see your point. You have provided a motivation for continuing to include authentication-less ESP. I'm not convinced that if you are encrypting, that authentication costs that much more: I know Stephen saw this talk at NDSS, but for others: @inproceedings{Nahum1996, AUTHOR="Erich Nahum and David J. Yates and Sean O'Malley and Hilarie Orman and Richard Schroeppel", TITLE="Parallelized Network Security Protocols", BOOKTITLE="Proceedings of the 1996 Symposium on Network and Distributed Systems Security", YEAR=1996, note = "NDSS online proceedings \htmladdnormallink{http://bilbo.isu.edu/sndss/nahum.ps}{http://bilbo.isu.edu/sndss/nahum.ps}", } :!mcr!: | Network security consulting and Michael Richardson | contract programming WWW: mcr@sandelman.ottawa.on.ca. PGP key available. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBM1zUiaZpLyXYhL+BAQGFngL+JKb0Qn11mdj6kTkzm8IoGW4rics3KFDX dB48gnvVrng95AuRMxWL/3ys31lsmEX40N6tunvOg/Xr0I6dvaX6Uy2mSPnZF4ou Ma3lmSX6FXqAue6L4bB9rWXg4Xo+tZJK =5dZ1 -----END PGP SIGNATURE----- From owner-ipsec Tue Apr 22 13:13:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA00212 for ipsec-outgoing; Tue, 22 Apr 1997 12:42:45 -0400 (EDT) Date: Tue, 22 Apr 97 14:36:02 GMT From: "William Allen Simpson" Message-ID: <5749.bsimpson@morningstar.com> To: Stephen Kent Cc: "ipsec@tis.com" Subject: Re: notes from developer's portion of IETF meeting Sender: owner-ipsec@ex.tis.com Precedence: bulk Sorry that you couldn't be there Steve, as the implementors meeting was the most useful of any IPSec meeting in recent memory. But, part of the problem seems to be that the "notes" sent to the list don't quite match my understanding of the decisions reached, and have little of the rationale that was voiced in the meeting. I thought that someone else was taking notes; could they send their writeup, instead? In my view, the result was that we have _finally_ returned to the packet formats and functionality agreed in Amsterdam in July 1993. We have come full circle. > From: Stephen Kent > Use of AH is not the same as use of ESP w/o encryption, precisely because > of the coverage issue, and the associated performance hit. (analysis omitted) > What I'm > hearing from this discussion is that the motivation for not offering ESP > w/o encryption is added complexity. I'm all in favor of reducing > complexity, if it doesn't cost functionality, but I'm really surprized to > hear that offering ESP w/o encryption is percieved as a significant > increase in complexity. > The verbal rationale that I remember was that the main use of AH would be for the tunnelling gateways that Moskowitz diagrammed, where you need to authenticate the IP addresses of the routers. This keeps the tunnel down to a single tunnel across the net. I remember Richardson giving us the same (single tunnel level) recommendation over a year ago. The orthogonal use of AH provides function that would not be available with ESP alone. And, it _also_ reduces complexity in implementation of ESP. You are correct, the implementors seemed quite taken with that idea.... :-) No rationale was given for the practical need for authentication-only ESP, and thus it was not chosen as an option. Is there any reason other than the minor performance gain that you mention, that cannot be handled by AH as it stands? > I assume you meat to say that ESP with authentication was useless, but I > have to disagree. I know folks who are sending packet voice and packet > video on an end-to-end basis. I recommend use of ESP w/o authentication in > this context. Here, the notes are simply wrong (by omission). The group agreed that ESP encryption without integrity needs an external AH _only_ where required for security! You are correct, and was elaborated by Bellovin's paper long ago, there are many instances where extra authentication for integrity is not required. As I recall, integrity is required for security _only_ when there are mutually hostile users on multi-user systems at both ends of the connection/path. These multi-user systems "know" that they require integrity, and can negotiate it appropriately. OTOH, a dialup user encrypting to a firewall (or even their target multi-user host) from a laptop would _not_ require added integrity. Big interactive RTT savings on a low speed link. > However, per-packet overhead is a big > concern here and thus stripping out everyting but the encryption support is > an important feature. Thus the flexibility offered by modular use of ESP > and AH is important to these folks and is in keeping with the original > intent of IPSEC. > Could you put that in the architecture for posterity? > I think the better argument is that AR counter inclusion makes alignment > "work" for AH in the IPv6 context, and in ESP this inclusion aligns the > start of the payload (assuming that we fold the IV into the payload) on an > 8-byte boundary as well, to facilitate crypto processing. Also, by always > sending this field, one simplifies packet parsing, by eliminating > variability. If these are the reasons for mandating inclusion of the AR > counter in every AH and ESP packet, then so be it, but at least lets agree > on a rationale that makes it clear what tradeoffs were considered in coming > to this conclusion. > Could you cite all of the above in the architecture for posterity? I will note that there were questions raised by several in the room about mandating the field in AH, as this would be a change in bits on the wire for older implementations. Perhaps someone could post their arguments here for the rest of the group. I don't think we had agreement on AH. Just ESP. > In general I propose that we remove the > IV as an explcit, optional field and fold it into the beginning of the > payload. The text will be modified to state this convention, noting that > each algorithm document must state the presence/absence of an IV (or a > sequence space pointer for some types of stream ciphers) and the size of > the IV. That way we can keep the ESP document simple and algorithm > independent. > Yes, that was my understanding of the agreement; please put that rationale in the ESP document. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Tue Apr 22 15:44:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA01331 for ipsec-outgoing; Tue, 22 Apr 1997 15:41:31 -0400 (EDT) Message-Id: <199704221942.PAA04915@relay.hq.tis.com> Date: Tue, 22 Apr 97 15:41:57 EDT From: Karen Seo To: ipsec@tis.com cc: skent@bbn.com, clynn@bbn.com, nyuan@bbn.com, kseo@bbn.com Subject: PMTU/DF issues Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, The text below discusses some IPSEC/PMTU/DF issues and the corresponding proposed changes to the IPSEC Architecture document. The initial section is the text we propose to include in the IPSEC Architecture document. That is followed by more detailed discussion/analysis which will be in an Appendix. The term "communication association" refers to the "connection" defined by source and destination addresses, transport protocol, source and destination ports, and user id. ICMP PMTU is used to refer to an ICMP message for: IPv4: - Type = 3 (Destination Unreachable) - Code = 4 (Fragmentation needed and DF set) - Next-Hop MTU in the low-order 16 bits of the second word of the ICMP header (labelled unused in RFC 792), with high-order 16 bits set to zero IPv6 (RFC 1885): - Type = 2 (Packet Too Big) - Code = 0 (Fragmentation needed and DF set) - Next-Hop MTU in the 32 bit MTU field of the ICMP6 Thank you, IPSEC Document Editing Team ========================================================================= We propopse to add the following text to the IPSEC Architecture document re: Fragmentation and PMTU -- The analysis/discussion of these topics will be included in Appendix X to the Architecture document. 1. DF bit: In cases where a system (host or gateway) adds an encapsulating header (ESP or AH tunnel), it MUST support the option of copying the DF bit from the original packet to the encapsulating header (and processing ICMP PMTU messages). This means that it MUST be possible to configure the system's treatment of the DF bit (set, clear, copy from encapsulated header) for each interface. (See Appendix X for rationale.) 2. Fragmentation: Fragmentation MUST be done after outbound IPSEC processing and reassembly MUST be done before inbound IPSEC processing. (See Appendix X for analysis of how this is impacted by the location (where in the stack) of the IPSEC implementation.) (Footnote) Any IPSEC implementation that is not integrated into an IP implementation MUST support constructing any encapsulating IP headers and doing any necessary fragmentation and re-assembly. (See Appendix X for further discussion.) 3. Path MTU Discovery: The amount of information returned with the ICMP PMTU message (IPv4 or IPv6) is limited and this affects what selectors are available for use in further propagating the PMTU information. (See Appendix X for more detailed discussion of this topic.) A. If the ICMP PMTU message contains only 64 bits of the IPSEC header (minimum for IPv4), then a security gateway MUST support the following options on a per SPI/SA basis: a. if the originating host(s) can be determined, send the PMTU information to all the possible originating hosts. b. if the originating host(s) cannot be determined, store the PMTU with the SPI/etc and wait until the next packet(s) arrive from the originating host(s) for the relevant security association. If it/they are bigger than the PMTU, drop the packet(s), and compose ICMP PMTU message(s) with the new packet(s) and the updated PMTU, and send the ICMP message(s) about the problem to the originating host(s) . B. If the ICMP message contains more information from the original packet, e.g., the 576 byte minimum for IPv6, then there MAY be enough information to immediately determine to which host to propagate the ICMP/PMTU message and to provide that system with a 5-selector pointer for storing/updating the PMTU. Under such circumstances, a security gateway MUST generate an ICMP PMTU message immediately upon receipt of an ICMP PMTU from further down the path. The calculation of PMTU from an ICMP PMTU MUST take into account the addition of any IPSEC header -- ESP or AH transport, or ESP or AH tunnel. (See Appendix X for discussion of implementation issues.) In hosts, the granularity with which PMTU ICMP processing can be done differs depending on the implementation situation. Looking at a host, there are 3 situations that are of interest with respect to PMTU issues (See Appendix X for detailed discussion of this issue): a. Integration of IPSEC into the native IP implementation b. Bump-in-the-stack implementations, where IPSEC is implemented "underneath" an existing implementation of a TCP/IP protocol stack, between the native IP and the local network drivers c. No IPSEC implementation -- This case is included because it is relevant in cases where a security gateway is sending PMTU information back to a host. Only in case (a) can the PMTU data be maintained at the same granularity as communication associations. In (b) and (c), the IP layer will only be able to maintain PMTU data at the granularity of source and destination IP addresses (and optionally ToS), as described in RFC 1191. This is an important difference, because more than one communication association may map to the same source and destination IP addresses, and each communication association may have a different amount of IPSEC header overhead (e.g., due to use of different transforms or different algorithms). Implementation of the calculation of PMTU and support for PTMUs at the granularity of individual communication associations is a local matter. However, a socket-based implementation of IPSEC in a host SHOULD maintain the information on a per socket basis. Bump in the stack systems MUST pass an ICMP PMTU to the host IP implementation, after adjusting it for any IPSEC header overhead added by these systems. The calculation of the overhead SHOULD be determined by analysis of the SPI and any other selector information present in a returned ICMP PMTU message. The host mechanism for getting the updated PMTU to the transport layer is unchanged, as specified in RFC 1191 (Path MTU Discovery). In all systems (host or gateway) implementing IPSEC and maintaining PMTU information, the PMTU associated with a security association (transport or tunnel) MUST be "aged" and some mechanism put in place for updating the PMTU in a timely manner, especially for discovering if the PMTU is smaller than it needs to be. A given PMTU has to remain in place long enough for a packet to get from the source end of the security association to the system at the other end of the security association and propagate back an ICMP error message if the current PMTU is too big. Systems SHOULD use the approach described in the Path MTU Discovery document (RFC 1191, Section 6.3), which suggests periodically resetting the PMTU to the first-hop data-link MTU and then letting the normal PMTU Discovery processes update the PMTU as necessary. The period SHOULD be configurable. ========================================================================= Appendix X -- Analysis/Discussion of PMTU/DF/Fragmentation Issues The legend for the diagrams is: ==== = security association (AH or ESP, transport or tunnel) ---- = connectivity (or if so labelled, administrative boundary) .... = ICMP message (hereafter referred to as ICMP PMTU) for IPv4: - Type = 3 (Destination Unreachable) - Code = 4 (Fragmentation needed and DF set) - Next-Hop MTU in the low-order 16 bits of the second word of the ICMP header (labelled unused in RFC 792), with high-order 16 bits set to zero IPv6 (RFC 1885): - Type = 2 (Packet Too Big) - Code = 0 (Fragmentation needed and DF set) - Next-Hop MTU in the 32 bit MTU field of the ICMP6 Hx = host x Sx = socket x SGx = security gateway x X* = X supports IPSEC 1. DF bit -- In cases where a system (host or gateway) adds an encapsulating header (e.g., ESP tunnel), should/must the DF bit in the original packet be copied to the encapsulating header? Fragmenting seems correct for some situations, e.g., it might be appropriate to fragment packets over a network with a very small MTU, e.g., a packet radio network, or a cellular phone hop to mobile node, rather than propagate back a very small PMTU for use over the rest of the path. In other situations, it might be appropriate to set the DF bit in order to get feedback from later routers about PMTU constraints which require fragmentation. The existence of both of these situations argues for enabling a system to decide whether or not to fragment over a particular network "link", i.e., for requiring an implementation to be able to copy the DF bit (and to process ICMP PMTU messages), but making it an option to be selected on a per interface basis. In other words, an administrator should be able to configure the router's treatment of the DF bit (set, clear, copy from encapsulated header) for each interface. 2. Fragmentation -- Fragmentation MUST be done after outbound IPSEC processing. Reassembly MUST be done before inbound IPSEC processing. The general reasoning is shown below (delimited by the *******'s). NOTE: IPSEC always has to figure out what the encapsulating IP header fields are. This is independent of where you insert IPSEC and is intrinsic to the definition of IPSEC. Therefore any IPSEC implementation that is not integrated into an IP implementation must include code to construct the necessary IP headers (IP2): o AH-tunnel --> IP2-AH-IP1-Transport-Data o ESP-tunnel --> IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer **************************************************************************** Overall, the fragmentation/reassembly approach described above works for all cases examined. AH Xport AH Tunnel ESP Xport ESP Tunnel Implementation approach IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 ----------------------- ---- ---- ---- ---- ---- ---- ---- ---- Hosts (integr w/ IP stack) Y Y Y Y Y Y Y Y Hosts (betw/ IP and drivers) Y Y Y Y Y Y Y Y S. Gwy (integr w/ IP stack) Y Y Y Y Outboard crypto processor * * If the crypto processor system has its own IP address, then it is covered by the security gateway case. This box receives the packet from the host and performs IPSEC processing. It has to be able to handle the same AH, ESP, and related IPv4/IPv6 tunnel processing that a security gateway would have to handle. If it doesn't have it's own address, then it is similar to the bump-in-the stack implementation between IP and the network drivers. The following analysis assumes that: 1. There is only one IPSEC module in a given system's stack. There isn't an IPSEC module A (adding ESP/encryption and thus) hiding the transport protocol, SRC port, and DEST port from IPSEC module B. 2. There are several places where IPSEC could be implemented (as shown in the table above). a. Hosts with integration of IPSEC into the native IP implementation. Implementer has access to the source for the stack. b. Hosts with bump-in-the-stack implementations, where IPSEC is implemented between IP and the local network drivers. Source access for stack is not available; but there are well-defined interfaces that allows the IPSEC code to be incorporated into the system. c. Security gateways and outboard crypto processors with integration of IPSEC into the stack. 3. Not all of the above approaches are feasible in all hosts. But it was assumed that for each approach, there are some hosts for whom the approach is feasible. For each of the above 3 categories, there are IPv4 and IPv6, AH transport and tunnel modes, and ESP transport and tunnel modes -- for a total of 24 cases (3 x 2 x 4). Some header fields and interface fields are listed here for ease of reference -- they're not in the header order, but instead listed to allow comparison between the columns. (* = not covered by AH authentication. ESP authentication doesn't cover any headers that precede it.) IP/Transport Interface IPv4 IPv6 (RFC 1122 -- Sec 3.4) ---- ---- ---------------------- Version = 4 Version = 6 Header Len *TOS Prty,Flow Lbl TOS Packet Len Payload Len Len ID ID (optional) *Flags DF *Offset *TTL *Hop Limit TTL Protocol Next Header *Checksum Src Address Src Address Src Address Dst Address Dst Address Dst Address Opt?ions Opt?ions Opt ? = AH covers Option-Type and Option-Length, but not Option-Data. The results for each of the 24 cases is shown below ("works" = will work if system fragments after outbound IPSEC processing, reassembles before inbound IPSEC processing). Notes indicate implementation issues. a. Hosts (integrated into IP stack) o AH-transport --> (IP1-AH-Transport-Data) - IPv4 -- works - IPv6 -- works o AH-tunnel --> (IP2-AH-IP1-Transport-Data) - IPv4 -- works - IPv6 -- works o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works b. Hosts (Bump-in-the-stack) -- put IPSEC between IP layer and network drivers. In this case, the IPSEC module would have to do something like one of the following for fragmentation and reassembly. - do the fragmentation/reassembly work itself and send/receive the packet directly to/from the network layer. In AH or ESP transport mode, this is fine. In AH or ESP tunnel mode where the tunnel is to the ultimate destination, this is fine. But in AH or ESP tunnel modes where the tunnel end is different from the ultimate destination and where the source host is multi-homed, this approach could result in sub-optimal routing because the IPSEC module may be unable to obtain the information needed (LAN interface and next-hop gateway) to direct the packet to the appropriate network interface. This is not a problem if the interface and next-hop gateway are the same for the ultimate destination and for the tunnel end. But if they are different, then IPSEC would need to know the LAN interface and the next-hop gateway for the tunnel end. OR - pass the IPSEC'd packet back to the IP layer where an extra IP header would end up being pre-pended and the IPSEC module would have to check and let IPSEC'd fragments go by. OR - pass the packet contents to the IP layer in a form such that the IP layer recreates an appropriate IP header At the network layer, the IPSEC module will have access to the following selectors from the packet -- SRC address, DST address, TOS, Next Protocol, and if there's a transport layer header --> SRC port and DST port. One cannot assume IPSEC has access to the User ID. It is assumed that the available selector information is sufficient to figure out the relevant Security Association(s). o AH-transport --> (IP1-AH-Transport-Data) - IPv4 -- works - IPv6 -- works o AH-tunnel --> (IP2-AH-IP1-Transport-Data) - IPv4 -- works - IPv6 -- works o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works c. Security gateways -- integrate IPSEC into the IP stack NOTE: The IPSEC module will have access to the following selectors from the packet -- SRC address, DST address, TOS, Next Protocol, and if there's a transport layer header --> SRC port and DST port. It won't have access to the User ID (only Hosts have access to User ID information.) It also won't have access to the transport layer information if there is an ESP header, or if it's not the first fragment of a fragmented message. It is assumed that the available selector information is sufficient to figure out the relevant Security Association(s). o AH-tunnel --> (IP2-AH-IP1-Transport-Data) - IPv4 -- works - IPv6 -- works o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works **************************************************************************** 3. Path MTU Discovery -- As mentioned earlier, "ICMP PMTU" refers to an ICMP message used for Path MTU Discovery. A. The amount of information returned with the ICMP message is limited and this affects what selectors are available to identify security associations, originating hosts, etc. for use in further propagating the PMTU information. In brief... An ICMP message must contain from the "offending" packet: - IPv4 (RFC 792) -- IP header plus a minimum of 64 bits - IPv6 (RFC 1885) -- IP header plus a minimum of 576 bytes Accordingly, in the IPv4 context, an ICMP PMTU may identify only the first (outermost) security association. This is because the ICMP PMTU may contain only 64 bits of the "offending" packet beyond the IP header, which would capture only the first SPI from AH or ESP. In the IPv6 context, an ICMP PMTU will probably provide all the SPIs and the selectors in the IP header, but maybe not the SRC/DST ports (in the transport header) or the encapsulated (TCP, UDP, etc.) protocol. Moreover, if ESP is used, the transport ports and protocol selectors may be encrypted. Looking at the diagram below of a security gateway tunnel (as mentioned elsewhere, security gateways do not use transport mode)... H1 =================== H3 \ | | / H0 -- SG1* ---- R1 ---- SG2* ---- R2 -- H5 / ^ | \ H2 |........| H4 Suppose H0 sends a data packet to H5 via SG1 and SG2 and there is a security association between SG1 and SG2. SG1 maps the IPSEC selectors (source address, destination address, next protocol, source port, destination port) into a security association that defines the SPI, source and destination gateways, and how to process the packet. It determines that this packet should go through the IPSEC ESP (or AH) tunnel between SG1 and SG2. It then does the IPSEC processing needed for the SG1/SG2 hop and sends the packet -- adds encapsulating IP header with SRC = SG1, DEST = SG2 and adds ESP header before data packet and ESP trailer after. Now suppose R1 sends an ICMP PMTU to SG1. How does SG1 determine the PMTU selectors to use to return the ICMP message to the originating host (H1)? original after IPSEC ICMP packet processing packet -------- ----------- ------ IP-3 header (S = R1, D = SG1) ICMP header (includes PMTU) IP-2 header IP-2 header (S = SG1, D = SG2) ESP header minimum of 64 bits of ESP hdr (*) IP-1 header IP-1 header TCP header TCP header TCP data TCP data ESP trailer (*) The 64 bits will include enough of the ESP (or AH) header to include the SPI. - ESP -- SPI (32 bits), unknown (32 bits) -- could be the optional Replay counter but one can't be sure. - AH -- Next header (8 bits), Payload Len (8 bits), Reserved (16 bits), SPI (32 bits) This limitation on the amount of information returned with an ICMP message creates a problem in identifying the originating hosts for the packet (so as to know where to further propagate the ICMP PMTU information). If the ICMP message contains only 64 bits of the IPSEC header (minimum for IPv4), then the 5 original IPSEC selectors will have been lost -- Source and Destination addresses, Next Protocol, Source and Destination ports. But the ICMP error message will still provide SG1 with the SPI, the PMTU information and the source and destination gateways for the relevant security association. The destination security gateway and SPI uniquely define a security association which in turn defines a set of possible originating hosts. At this point, SG1 could: a. send the PMTU information to all the possible originating hosts. This would not work well if the host list is a wild card or if many/most of the hosts weren't sending to SG1; but it might work if the SPI/destination/etc mapped to just one host. b. store the PMTU with the SPI/etc and wait until the next packet(s) arrive from the originating host(s) for the relevant security association. If it/they are bigger than the PMTU, drop the packet(s), and compose ICMP PMTU message(s) with the new packet(s) and the updated PMTU, and send the originating host(s) the ICMP message(s) about the problem. This involves a delay in notifying the originating host(s), but avoids the problems of (a). Since only the latter approach is feasible in all instances, a security gateway MUST provide such support, as an option. However, if the ICMP message contains more information from the original packet, e.g., the 576 byte minimum for IPv6, then there MAY be enough information to immediately determine to which host to propagate the ICMP/PMTU message and to provide that system with a 5-selector pointer for storing/updating the PMTU. Under such circumstances, a security gateway MUST generate an ICMP PMTU message immediately upon receipt of an ICMP PMTU from further down the path. NOTE: The Next Protocol field MAY not be contained in the 576 bytes and the use of ESP encryption MAY hide the selector fields that have been encrypted. B. The calculation of PMTU from an ICMP PMTU has to take into account the addition of any IPSEC header by H1 -- ESP or AH transport, or ESP or AH tunnel. Within a single host, multiple applications may share an SPI and nesting of security associations may occur. The diagram below illustrates several possible combinations of security associations between a pair of hosts (as viewed from the perspective of one of the hosts.) (ESPt or AHt = tunnel mode; ESPx or AHx = transport mode) Socket 1 ----------------------------------------------- I | n Socket 2 (ESPt/SPI-A) ------------------------------- | t \ | e Socket 3 (AHx/SPI-B, ESPt/SPI-C) --- AHx (SPI-D) --- ESPt (SPI-E)--r / n Socket 4 (ESPx/SPI-F, ESPt/SPI-G) -- ESPx (SPI-H) --- e t In order to figure out the PMTU for each socket that maps to SPI-E, it will be necessary to have backpointers from SPI-E to each of the 4 paths that lead to it -- Socket 1, SPI-A, SPI-D, and SPI-H. C. In hosts, the granularity with which PMTU ICMP processing can be done differs depending on the implementation situation. Looking at a host, there are 3 situations that are of interest with respect to PMTU issues: a. Integration of IPSEC into the native IP implementation b. Bump-in-the-stack implementations, where IPSEC is implemented "underneath" an existing implementation of a TCP/IP protocol stack, between the native IP and the local network drivers c. No IPSEC implementation -- This case is included because it is relevant in cases where a security gateway is sending PMTU information back to a host. Only in case (a) can the PMTU data be maintained at the same granularity as communication associations. In the other cases, the IP layer will maintain PMTU data at the granularity of Source and Destination IP addresses (and optionally ToS), as described in RFC 1191. This is an important difference, because more than one communication association may map to the same source and destination IP addresses, and each communication association may have a different amount of IPSEC header overhead (e.g., due to use of different transforms or different algorithms). The examples below illustrate this. In cases (a) and (b)... Suppose you have the following situation. H1 is sending to H2 and the packet to be sent from R1 to R2 exceeds the PMTU of the network hop between them. ================================== | | H1* --- R1 ----- R2 ---- R3 ---- H2* ^ | |.......| If R1 is configured to not fragment subscriber traffic, then R1 sends an ICMP PMTU message with the appropriate PMTU to H1. H1's processing would vary with the nature of the implementation. In case (a) (native IP), the security services are bound to sockets or the equivalent. Here the IP/IPSEC implementation in H1 can store/update the PMTU for the associated socket. In cases (b), the IP layer in H1 can store/update the PMTU but only at the granularity of Source and Destination addresses and possibly ToS, as noted above. So the result may be sub-optimal, since the PMTU for a given SRC/DST/ToS will be the subtraction of the largest amount of IPSEC header used for any communication association between a given source and destination. In case (c), there has to be a security gateway to have any IPSEC processing. So suppose you have the following situation. H1 is sending to H2 and the packet to be sent from SG1 to R exceeds the PMTU of the network hop between them. ================ | | H1 ---- SG1* --- R --- SG2* ---- H2 ^ | |.......| As described above for case (b), the IP layer in H1 can store/update the PMTU but only at the granularity of Source and Destination addresses, and possibly ToS. So the result may be sub-optimal, since the PMTU for a given SRC/DST/ToS will be the subtraction of the largest amount of IPSEC header used for any communication association between a given source and destination. D. Implementation of the calculation of PMTU (B) and support for PTMUs at the granularity of individual "communication association s" (C) is a local matter. However, a socket-based implementation of IPSEC in a host SHOULD maintain the information on a per socket basis. Bump in the stack systems MUST pass an ICMP PMTU to the host IP implementation, after adjusting it for any IPSEC header overhead added by these systems. The determination of the overhead SHOULD be determined by analysis of the SPI and any other selector information present in a returned ICMP PMTU message. E. The host mechanism for getting the updated PMTU to the transport layer is unchanged, as specified in RFC 1191 (Path MTU Discovery). F. In all systems (host or gateway) implementing IPSEC and maintaining PMTU information, the PMTU associated with a security association (transport or tunnel) has to be "aged" and some mechanism put in place for updating the PMTU in a timely manner, especially for discovering if the PMTU is smaller than it needs to be. A given PMTU has to remain in place long enough for a packet to get from the source end of the security association to the system at the other end of the security association and propagate back an ICMP error message if the current PMTU is too big. Systems SHOULD use the approach described in the Path MTU Discovery document (RFC 1191, Section 6.3), which suggests periodically resetting the PMTU to the first-hop data-link MTU and then letting the normal PMTU Discovery processes update the PMTU as necessary. The period SHOULD be configurable. From owner-ipsec Tue Apr 22 16:49:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA01843 for ipsec-outgoing; Tue, 22 Apr 1997 16:42:29 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <5749.bsimpson@morningstar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 Apr 1997 16:26:42 -0400 To: "William Allen Simpson" From: Stephen Kent Subject: Re: notes from developer's portion of IETF meeting Cc: "ipsec@tis.com" Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, NIce to hear from you again. Here are some responses to your comments: >> Use of AH is not the same as use of ESP w/o encryption, precisely because >> of the coverage issue, and the associated performance hit. >(analysis omitted) >> What I'm >> hearing from this discussion is that the motivation for not offering ESP >> w/o encryption is added complexity. I'm all in favor of reducing >> complexity, if it doesn't cost functionality, but I'm really surprized to >> hear that offering ESP w/o encryption is percieved as a significant >> increase in complexity. >> >The verbal rationale that I remember was that the main use of AH would >be for the tunnelling gateways that Moskowitz diagrammed, where you need >to authenticate the IP addresses of the routers. This keeps the tunnel >down to a single tunnel across the net. I remember Richardson giving us >the same (single tunnel level) recommendation over a year ago. It's good to see an exmaple of the rationale behind the proposal. In general, if I am tunneling traffic between two security gateways, why do I need to protect the outer IP header? Would I not generally discard it upon arrival? The inner IP header is the real focus of protection. There is no reason why I cannot multiplex the same scope of traffic in a tunnel with ESP as I can with an AH tunnel, so I don't view that as a differentiator. >The orthogonal use of AH provides function that would not be available >with ESP alone. > >And, it _also_ reduces complexity in implementation of ESP. You are >correct, the implementors seemed quite taken with that idea.... :-) > >No rationale was given for the practical need for authentication-only >ESP, and thus it was not chosen as an option. Is there any reason other >than the minor performance gain that you mention, that cannot be handled >by AH as it stands? I guess I look at the question from the opposite perspective: if all I need is provided by an authentication-only ESP, why pay any additional performance penalty by requiring AH? I remember when ESP had no authentication transforms and one had to use AH in conjunction with ESP to achieve both sets of services. I was among those who argued for autehntication/integrity features for ESP precisely to avoid the overhead of using AH. I like the logical completeness of having ESP be modular, allowing selected subsets of security services to be applied to payloads in a clean, encapsulated fashion. >> I assume you meat to say that ESP with authentication was useless, but I >> have to disagree. I know folks who are sending packet voice and packet >> video on an end-to-end basis. I recommend use of ESP w/o authentication in >> this context. > >Here, the notes are simply wrong (by omission). The group agreed that >ESP encryption without integrity needs an external AH _only_ where >required for security! > >You are correct, and was elaborated by Bellovin's paper long ago, there >are many instances where extra authentication for integrity is not >required. > >As I recall, integrity is required for security _only_ when there are >mutually hostile users on multi-user systems at both ends of the >connection/path. These multi-user systems "know" that they require >integrity, and can negotiate it appropriately. > >OTOH, a dialup user encrypting to a firewall (or even their target >multi-user host) from a laptop would _not_ require added integrity. Big >interactive RTT savings on a low speed link. Glad to see we agree here! >> However, per-packet overhead is a big >> concern here and thus stripping out everyting but the encryption support is >> an important feature. Thus the flexibility offered by modular use of ESP >> and AH is important to these folks and is in keeping with the original >> intent of IPSEC. >> >Could you put that in the architecture for posterity? Yes, I'll make sure that the architecture document captures the rationale that motivates the various combinations of AH and ESP use, etc. >> I think the better argument is that AR counter inclusion makes alignment >> "work" for AH in the IPv6 context, and in ESP this inclusion aligns the >> start of the payload (assuming that we fold the IV into the payload) on an >> 8-byte boundary as well, to facilitate crypto processing. Also, by always >> sending this field, one simplifies packet parsing, by eliminating >> variability. If these are the reasons for mandating inclusion of the AR >> counter in every AH and ESP packet, then so be it, but at least lets agree >> on a rationale that makes it clear what tradeoffs were considered in coming >> to this conclusion. >> >Could you cite all of the above in the architecture for posterity? If we decide to mandate inclusion of the AR counter, then rest assured that the AH and ESP documents will cite the rationale for this, since inclusion of a field that might not be used by the receiver demands an explanation! >I will note that there were questions raised by several in the room >about mandating the field in AH, as this would be a change in bits on >the wire for older implementations. Perhaps someone could post their >arguments here for the rest of the group. > >I don't think we had agreement on AH. Just ESP. I'm asking these questions precisely to clairfy the minutes and make sure that the WG as a whole, not just those attending the most recent meeting, understand what is being proposed and why. >> In general I propose that we remove the >> IV as an explcit, optional field and fold it into the beginning of the >> payload. The text will be modified to state this convention, noting that >> each algorithm document must state the presence/absence of an IV (or a >> sequence space pointer for some types of stream ciphers) and the size of >> the IV. That way we can keep the ESP document simple and algorithm >> independent. >> >Yes, that was my understanding of the agreement; please put that >rationale in the ESP document. Will do. From owner-ipsec Tue Apr 22 16:49:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA01849 for ipsec-outgoing; Tue, 22 Apr 1997 16:43:04 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199704221509.LAA19920@amaterasu.sandelman.ottawa.on.ca> References: Your message of "Mon, 21 Apr 1997 17:29:05 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 Apr 1997 16:42:46 -0400 To: Michael Richardson From: Stephen Kent Subject: Re: notes from developer's portion of IETF meeting Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Mike, >>>>>> "Stephen" == Stephen Kent writes: > Stephen> consuming task. My guess is that use of ESP in tunnel > Stephen> mode will be popular, with one end of the SA at a > Stephen> firewall. Under those circumstances, AH in tunnel mode > Stephen> does not buy one much, because the outer header is not > Stephen> very interesting, i.e., it will be discarded. (Only > Stephen> rarely would it make sense to copy portions of it into an > Stephen> inner header.) Thus tunnel mode ESP would provide > Stephen> suitable protection for traffic with greater efficiency > Stephen> and less per-packet overhead. What I'm hearing from this > Stephen> discussion is that the motivation for not offering ESP > Stephen> w/o encryption is added complexity. I'm all in favor of > > As long as you are optimizing in favour of the VPN application, then >let's be explicit and do that. > The reason why ESP without encryption is not interesting is because >the P in VPN means private. If there comes to exist a strong >encrypting transform with built in integrity, VPN people will want >that. Well, many systems that claim to provide virtual private nets do so without confidentiality. The closed user group facility in X.25 and frame relay nets, the analogous facility in ATM nets, and similar soft configuration options in switched ethernets are all cited as bases for VPNs. Today, we rely on firewalls to provide access control at the perimeter of local/campus nets. However, we do so with authentictaion of traffic sources, or we sdo so based on bind time (vs. continuous) authentication. So, using IPSEC to authenticate traffic provides a solid basis for making the same access control decision, a noticeable improvement. We will not always want to provide confidentiality for traffic at the firewall boundary. For example, the traffic might be encrypted to the desktop or server behind the firewall, so the extra layer of encryption might be seen as unnecessary and an unwarrented performence hit. Higher layer encryption might be employed, e.g., for e-mail, and here too layer 3 encryption may be deemed redundant and not worth the cost. So, a flexible architectuire should allow for SAs that terminate at a firewall and provide just authentication . The debatem then, is whether it's better to provide this service using ESP in tunnel mode or AH in tunnel mode. > Stephen> reducing complexity, if it doesn't cost functionality, > Stephen> but I'm really surprized to hear that offering ESP w/o > Stephen> encryption is percieved as a significant increase in > Stephen> complexity. > > We know AH is complex. Fine. AH isn't interesting for VPN >applications. Fine. > Let's allow a VPN-only to deal with lower complexity, and do only >what it needs to do. That means it might not do AH. It will encrypt. > I realize that is in oposition to the IPv6 MUST implement (AH, but >not ESP). An encryption-less ESP could then become a MUST implement >for IPv6. > Remember: fewer options == interoperability. Yes, fewer options does increase the likelihood of interoperability. But, as my comments describe above, there are valid reasons for authentication-only tunnels in firewalls. So far we don't have v4 compliance reuqirements re AH and ESP, but we will need to address that issue later, e.g., must one implement both to claim "IPSEC compliance?" The architecture document can address this issue. > Stephen> support is an important feature. Thus the flexibility > Stephen> offered by modular use of ESP and AH is important to > Stephen> these folks and is in keeping with the original intent of > Stephen> IPSEC. > > Authentication-less ESP was left as an option. I'm not sure I >completely agree that audio data is not that sensitive to integrity >problems, but I see your point. You have provided a motivation for >continuing to include authentication-less ESP. I'm not convinced that >if you are encrypting, that authentication costs that much more: The meeting minutes suggested that ESP must always be used with authentication, either intrinsic to ESP or via a separate AH, hence my concern and an example of why I felt such a requirement would be unduly restrictive. Authentication costs more in packet processing time, and especially in space for the small packets that characterize compressed audio. We've been sending packet voice around the Internet in experimental implementations for well over 15 years. The folks at Lincoln Labs have been pioneers in this area, in DoD-sponsored work. Their continuing activities motivated my comments about authenticationless-ESP. Steve From owner-ipsec Tue Apr 22 17:12:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA02158 for ipsec-outgoing; Tue, 22 Apr 1997 17:11:54 -0400 (EDT) Message-Id: <199704222025.QAA01680@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: "William Allen Simpson" Cc: Stephen Kent , "ipsec@tis.com" Subject: Re: notes from developer's portion of IETF meeting In-Reply-To: bsimpson's message of Tue, 22 Apr 1997 14:36:02 +0000. <5749.bsimpson@morningstar.com> Date: Tue, 22 Apr 1997 16:25:48 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > As I recall, integrity is required for security _only_ when there are > mutually hostile users ... One terminology nit: I say "mutually suspicious" rather than "mutually hostile", as actual hostility is not required, merely suspicion that the other guys are, or may become, hostile.. > ... on multi-user systems at both ends of the > connection/path. These multi-user systems "know" that they require > integrity, and can negotiate it appropriately. This is true only if you consider an encrypting router fronting for multiple mutually suspicious end users to be a multi-user system. > OTOH, a dialup user encrypting to a firewall (or even their target > multi-user host) from a laptop would _not_ require added integrity. Big > interactive RTT savings on a low speed link. This is simply not true if the firewall is fronting for mutually suspicious users. This may seem improbable, but I know of sites where (for historical reasons) two different organizations sharing a building also share a large chunk of the network infrastructure.. Here's a very specific, concrete example, of a case where lack of integrity leads to lack of confidentiality. A / C =====M==== GW \ B assume a pair of ESP SA's between C and GW (one in each direction) so there's a single key in use in each direction between C and GW; assume also that the encryption in question is a block cipher in CBC mode. assume that B can't tap the A-GW link because it's physically secure, but wants to spy on A->C traffic; it also has a wiretap/traffic injection point at M, where it can inject arbitrary messages into the network. assume C runs an ICMP echo service. B sends a large ICMP echo request packet to C, and captures the encrypted form of the packet at M. so, what it has is: IV ciphertext of B->C ICMP header ciphertext of B->C ICMP data ciphertext of pad (at least one full block's worth) ciphertext of B->C ESP trailer B also captures traffic it wants decrypted. it then constructs a packet of the form: IV ciphertext of B->C ICMP header IV of the A->C message <---+-- same length as ciphertext from A->C message <---+ ICMP data above ciphertext of pad ciphertext of B->C ESP trailer Because of the properties of CBC-mode ciphers, C will receive an ICMP packet with a valid header, a garbled data block corresponding to the A->C IV, the plaintext of a sequence of blocks from A->C message, another garbled block (conveniently located in the middle of the padding) and then a valid ESP trailer. C will then promply return the decrypted plaintext to B in an ICMP echo reply. One might think that the icmp checksum might get in the way, but there's at least one way around this which only adds a work factor of 2**16-1: B can construct echo packets with all 2**16-1 possible checksums, and try all of them; C returns the one for which the checksum matches. Tapping the C->A traffic is even easier: pull the encrypted packets at M, substitute the ciphertext into the middle of the encrypted ICMP reply from C to B, and send them (again) to GW; B simply "forgets" to check the ICMP checksum on reciept. - Bill From owner-ipsec Tue Apr 22 17:54:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA02512 for ipsec-outgoing; Tue, 22 Apr 1997 17:53:23 -0400 (EDT) Date: Tue, 22 Apr 1997 17:56:06 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704222156.RAA12940@earth.hpc.org> To: ipsec@tis.com In-reply-to: Yourmessage <199704222101.OAA01764@baskerville.CS.Arizona.EDU> Subject: Re: notes from developer's portion of IETF meeting Sender: owner-ipsec@ex.tis.com Precedence: bulk Authonly ESP seems both simple and useful, to me. And the performance penalty due to AH header handling might turn out to be the limiting factor at high speeds. RE the recollection: >As I recall, integrity is required for security _only_ when there are >mutually hostile users on multi-user systems at both ends of the >connection/path. These multi-user systems "know" that they require >integrity, and can negotiate it appropriately. This idea has always puzzled me. Surely block ciphers without some kind of integrity are insecure in any active attack environment. Hilarie From owner-ipsec Tue Apr 22 18:13:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA02590 for ipsec-outgoing; Tue, 22 Apr 1997 18:13:05 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199704222025.QAA01680@thunk.ch.apollo.hp.com> References: bsimpson's message of Tue, 22 Apr 1997 14:36:02 +0000. <5749.bsimpson@morningstar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 Apr 1997 18:18:44 -0400 To: Bill Sommerfeld From: Stephen Kent Subject: Re: notes from developer's portion of IETF meeting Cc: "ipsec@tis.com" Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, You provide a good example of how to exploit a tunnel mode use of ESP w/o integrity. I would note that it does require a confluence of wiretap capabilities that often will not be easy to attain, in conjunction with other wiretap capabilities not being available. Specificlally, the lack of a local passive wiretap ability in conjunction with an active and passive remote capability may seem odd in many circumstances, although it certainly is possible in others. However, in a transport mode environment, not involving multi-user end systems, ESP w/o authentication seems very reasonable. In tunnel mode with a firewall at one end, whether this form of ESP is OK depends on one's threat model. We could be very cautious and have the architectrure document prohibit such use, or we could have that document merely warn users (system administrators) about the pitfalls of such use. Steve From owner-ipsec Tue Apr 22 19:34:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA02937 for ipsec-outgoing; Tue, 22 Apr 1997 19:32:34 -0400 (EDT) Date: Tue, 22 Apr 1997 16:38:47 -0700 From: David Wagner Message-Id: <199704222338.QAA11325@joseph.cs.berkeley.edu> To: kent@bbn.com, ipsec@ex.tis.com Subject: Re: notes from developer's portion of IETF meeting Sender: owner-ipsec@ex.tis.com Precedence: bulk kent@bbn.com writes: > The meeting minutes suggested that ESP must always be used with > authentication, either intrinsic to ESP or via a separate AH, hence my > concern and an example of why I felt such a requirement would be unduly > restrictive. Authentication costs more in packet processing time, and > especially in space for the small packets that characterize compressed > audio. Now that I read this paragraph, I know how to phrase my objection more clearly. If packet voice folks are worried about the performance hit from the extra couple of words of overhead for AH, they shouldn't be using ipsec; they should be using some higher-level application-level authentication, which lets them do all sorts of application-specific optimizations (e.g. MACing entire kilobytes at a time). (By the way, typically authentication should require significantly less CPU time than encryption -- at least in my limited experience, though I admit I haven't written any ipsec code in two years.) We dare not carve a hole out of ipsec for each special-purpose group who wants their own optimization. The great value of ipsec is in its robustness across the great diversity of internet applications. An authentication-less ESP detracts from ipsec robustness, and I think that's bad for everyone. All IMHO, of course. -- Dave From owner-ipsec Tue Apr 22 19:59:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA03065 for ipsec-outgoing; Tue, 22 Apr 1997 19:59:10 -0400 (EDT) To: ipsec@ex.tis.com Path: not-for-mail From: daw@cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: notes from developer's portion of IETF meeting Date: 22 Apr 1997 17:05:17 -0700 Organization: ISAAC Group, UC Berkeley Lines: 38 Message-ID: <5jjjnt$b31@joseph.cs.berkeley.edu> References: <199704222101.OAA01764@baskerville.CS.Arizona.EDU> <199704222156.RAA12940@earth.hpc.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk In article <199704222156.RAA12940@earth.hpc.org>, Hilarie Orman wrote: > >As I recall, integrity is required for security _only_ when there are > >mutually hostile users on multi-user systems at both ends of the > >connection/path. These multi-user systems "know" that they require > >integrity, and can negotiate it appropriately. > > This idea has always puzzled me. Surely block ciphers without some kind of > integrity are insecure in any active attack environment. Well, yes, I think that's roughly the case, in practice. Bellovin's cut-and-paste attack shows that block ciphers aren't secure against chosen-ciphertext attacks (where the attacker gets the target to release the decryption of a stretch of attacker-chosen ciphertext). Multi-user systems (with host-pair keying) are one practical environment where chosen-ciphertext queries can be mounted; but there are others, too. For instance, imagine: a mail message comes in over the ipsec-encrypted link A->B; B's sendmail forwards the message to C; host C doesn't do ipsec, and so the message is sent unencrypted on the B->C link. B's sendmail is letting A mount a chosen-ciphertext query; now A can cut-and-paste ciphertext from B's other ipsec connections to get them decrypted. This is an instance of application-layer forwarding. Also, short-block attacks work even against single-user machines. Of course, the proper immunization against chosen-ciphertext attacks is authentication of the ciphertexts. This is just a robustness argument: if you're using encryption in an active attack environment, I say you'd better authenticate the connection too, or you may very well be subject to pernicious, subtle, and unanticipated attacks. Let's learn from earlier mistakes, and be extremely wary of integrity-less encryption transforms. From owner-ipsec Wed Apr 23 07:34:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA06556 for ipsec-outgoing; Wed, 23 Apr 1997 07:33:19 -0400 (EDT) Date: Tue, 22 Apr 1997 20:30:45 -0700 (PDT) From: Jan Vilhuber To: David Wagner cc: kent@bbn.com, ipsec@ex.tis.com Subject: Re: notes from developer's portion of IETF meeting In-Reply-To: <199704222338.QAA11325@joseph.cs.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Er... I must be missing something. I apologize if this is wrong, or has been mentioned (or if I'm misunderstanding something), but weren't there some serious security flaws in ESP without Authentication (AH)? See Belovin's paper. I've heard that ESP by nature now includes an authentication to cover those cases. Is that what is being discussed here? I MUST be missing something.. jan On Tue, 22 Apr 1997, David Wagner wrote: > kent@bbn.com writes: > > The meeting minutes suggested that ESP must always be used with > > authentication, either intrinsic to ESP or via a separate AH, hence my > > concern and an example of why I felt such a requirement would be unduly > > restrictive. Authentication costs more in packet processing time, and > > especially in space for the small packets that characterize compressed > > audio. > > Now that I read this paragraph, I know how to phrase my objection > more clearly. > > If packet voice folks are worried about the performance hit from > the extra couple of words of overhead for AH, they shouldn't be using > ipsec; they should be using some higher-level application-level > authentication, which lets them do all sorts of application-specific > optimizations (e.g. MACing entire kilobytes at a time). > > (By the way, typically authentication should require significantly > less CPU time than encryption -- at least in my limited experience, > though I admit I haven't written any ipsec code in two years.) > > We dare not carve a hole out of ipsec for each special-purpose group > who wants their own optimization. The great value of ipsec is in its > robustness across the great diversity of internet applications. An > authentication-less ESP detracts from ipsec robustness, and I think > that's bad for everyone. > > All IMHO, of course. -- Dave > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec Wed Apr 23 08:27:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA06795 for ipsec-outgoing; Wed, 23 Apr 1997 08:27:01 -0400 (EDT) Message-Id: <2.2.32.19970423121920.006e7a08@wasted.zk3.dec.com> X-Sender: ewong@wasted.zk3.dec.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Apr 1997 08:19:20 -0400 To: Stephen Kent From: "Eric L. Wong" Subject: Re: notes from developer's portion of IETF meeting Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk > ......... We could be very cautious and have the architectrure >document prohibit such use, or we could have that document merely warn >users (system administrators) about the pitfalls of such use. > I think these should be mentioned in the document. It also brings up the issue of 'policy' of enforcing security. After all, it is a policy thing. /eric From owner-ipsec Wed Apr 23 12:00:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA08331 for ipsec-outgoing; Wed, 23 Apr 1997 11:55:43 -0400 (EDT) Date: Wed, 23 Apr 1997 19:01:22 +0300 (IDT) From: Hugo Krawczyk Message-Id: <199704231601.TAA13455@ee.technion.ac.il> To: ipsec@tis.com Subject: Re: notes from developer's portion of IETF meeting Sender: owner-ipsec@ex.tis.com Precedence: bulk I am worried about this (revived) integrity-less encryption mood. It does not make sense to justify this approach under the argument that in some circumstances some particular attack (e.g. Bellovin's) will not work. Even if not said explicitly most of the arguments are based on the never-to-disappear illusions on the (pseudo) integrity properties inherent to CBC mode (would anyone suggest integrity-less encryption using a stream cipher?). It is time to abandon such illusions. The only people that can use integrity-less security are those that DO NOT CARE about their traffic being changed in route and do not care about chosen ciphertext attacks. If there are applications that consciously decide to take all these risks I suggest they negotiate the EMPTY-MAC as their authentication algorithm (no processing penalty) rather than having ipsec explictly allowing integrity-less IP security. As for computation time we keep seeing MAC algorithms getting much faster than encryption algorithms (although the effeect on ipsec processing speed of these faster algorithms is not entirely clear). Hugo From owner-ipsec Wed Apr 23 12:43:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA08617 for ipsec-outgoing; Wed, 23 Apr 1997 12:43:31 -0400 (EDT) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199704231646.JAA25014@kebe.eng.sun.com> Subject: Re: notes from developer's portion of IETF meeting To: hugo@ee.technion.ac.il (Hugo Krawczyk) Date: Wed, 23 Apr 1997 09:46:36 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <199704231601.TAA13455@ee.technion.ac.il> from "Hugo Krawczyk" at Apr 23, 97 07:01:22 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk It's kinda interesting watching this discussion. The _only_ reason integrity-less encryption is still allowed is because AH+ESP(transport) is a valid and useful combination. I'll bet small sums of money that AH+ESP(transport) was probably an original suggestion to solve Steve Bellovin's [Bel96] cut-and-paste attacks. I'm not sure why the two-algorithms-in-one-SA approach was ever adopted, but it's too late to argue these questions. Auth-less ESP is dangerous for the very reasons documented both here on the mailing list and in [Bel96]. We all know that, and it's nice to see the reasons being brought up here. It helps any newbies out there, as well as remind us implementors what to watch out for. BTW, I can see an ESP module issuing a warning or logging a danger sign that an auth-less ESP SA has been added. It could even say so again if such an SA is actually being USED. Dan From owner-ipsec Wed Apr 23 12:57:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA08746 for ipsec-outgoing; Wed, 23 Apr 1997 12:57:38 -0400 (EDT) Date: Wed, 23 Apr 1997 13:00:19 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704231700.NAA17206@earth.hpc.org> To: ipsec@tis.com Subject: Re: notes from developer's portion of IETF meeting Sender: owner-ipsec@ex.tis.com Precedence: bulk Block ciphers like DES without integrity are intensely vulnerable to active attacks, for any kind of machine, and in more ways than have been described on this list. Block splicing based on captured ciphertext with known plaintext allows the attacker great latitude for inserting bogus traffic with only minimal integrity violations. The last block attack shows how you can use this general technique even without knowing all the plaintext, and traffic modification poses yet another problem. Weak integrity checks in the application are an illusionary defense. I'd thought the goal of the group was to protect the Internet environment, i.e. an active attack environment. Thus, it seems to me that leaving integrity as an administrator option is contrary to the charter of the group. The conditions for safely dispensing with integrity are very narrow, i.e. one of 1. Physical impossibility of active attacks (NB analysis must be end-to-end) 2. Encryption method has strong internal integrity (not DES) 3. Connection limited to use by applications with strong internal integrity 4. Attacker can never know or guess ciphertext/plaintext pairs from observed traffic I am hesitant to leave this analysis to the system administrator; item 1 might arguably be an administrator decision, being highly environmental, but are these environments of concern to the Internet? Depending on implementations, the ratio of MD5 speed to DES speed can be between 3 to 1 and 10 to 1*, according to my notes, so integrity should not be eliminated based on performance considerations. However, the time to transmit 128 bytes on a slow connection is considerable and especially annoying if the data is shorter than the checksum, so that I can well understand the reluctance to include the it. Nonetheless, it seems very unlikely to me that a risk analysis would show that elimination of integrity was a winning trade-off, even at low speeds. Hilarie * ratios reported outside this range may depend on cache effects or byte reordering subtleties From owner-ipsec Wed Apr 23 14:42:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA09611 for ipsec-outgoing; Wed, 23 Apr 1997 14:41:39 -0400 (EDT) Message-Id: <97Apr23.144337edt.11650@janus.border.com> To: Thomas Narten cc: dpkemp@missi.ncsc.mil (David P. Kemp), ipsec@tis.com Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt References: <9704181331.AA15062@cichlid.raleigh.ibm.com> In-reply-to: narten's message of "Fri, 18 Apr 1997 08:31:20 -0400". <9704181331.AA15062@cichlid.raleigh.ibm.com> From: "C. Harald Koch" Date: Wed, 23 Apr 1997 14:47:40 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <9704181331.AA15062@cichlid.raleigh.ibm.com>, Thomas Narten writes: > I also agree, and have been disheartened by the number of times the > above question has been asked but not answered. Indeed, it has been > my impression that the vast majority of IP packets are delivered in > order (one reason why TCP's header prediction works well in > practice). It is rare in practice to have packets arrive out of > order. Which begs the question of whether a window is even > needed. Does someone have data that argues otherwise? Two sample points, my internet firewalls (A good place to look, since they re-synthesize all TCP streams in/out. This is roughly akin to combining the statistics for all 100 hosts behind the firewalls...). ----- elgreco ----- 2:39pm up 11 days, 4:51, 1 user, load average: 0.25, 0.16, 0.05 5796665 packets received 2703533 acks (for 1066489852 bytes) 3301088 packets (900448165 bytes) received in-sequence 107878 completely duplicate packets (10966707 bytes) 987 packets with some dup. data (122695 bytes duped) 198927 out-of-order packets (40226774 bytes) ----- janus ----- 2:38pm up 11 days, 4:52, 1 user, load average: 0.02, 0.06, 0.02 28417190 packets received 19533317 acks (for 371944057 bytes) 21278080 packets (176197867 bytes) received in-sequence 51170 completely duplicate packets (12418673 bytes) 519 packets with some dup. data (63691 bytes duped) 199859 out-of-order packets (69912188 bytes) That's 6.4 percent on elgreco, and 2.3 percent on janus, of all data packets received out-of-order. I wouldn't define that as "rare", especially given the (additional) performance penalties for dropping them instead of queueing them. -- Harald Koch From owner-ipsec Wed Apr 23 15:04:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA09829 for ipsec-outgoing; Wed, 23 Apr 1997 15:03:49 -0400 (EDT) Message-ID: <01BC4FDF.39536800@Tastid.cisco.com> From: Rob Adams To: "ipsec@tis.com" , "'Hilarie Orman'" Subject: RE: notes from developer's portion of IETF meeting Date: Wed, 23 Apr 1997 12:09:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Thank you Hugo, Dan, and Hilarie for stating clearly why the group at the IETF chose to make integrity mandatory. Btw, Dan, I think you're correct in stating why we are still having this discussion and where it came from in the first place.. At any rate, if MAC is optional for ESP, I think you'll be seeing a lot of implementations that don't allow the negotiation of a MACless ESP, or force policy to include a MAC algorithm with any ESP policy... %) As for optional encryption... I still think, if you don't want encryption you should use AH. I don't really buy the argument that processing the headers takes that more processing time. Table 18.2 in Applied Cryptography, Second Edition, says that MD5 will do 174 Mbytes a second on a 33MHz 486SX... so that means that your average 1500 byte packet, assuming 1/3 is headers (being very conservative) would... oh well, you can do the math... Looks like it doesn't add a noticable overhead per packet to me... And probably over the course of the exchange will get lost in the noise... So, can we agree? Optional integrity for ESP? No.? yes...? I'd say no. Optional confidentiality for ESP? I'd also say no. How 'bout other people? -Rob ---------- From: Hilarie Orman[SMTP:ho@earth.hpc.org] Sent: Wednesday, April 23, 1997 10:00 AM To: ipsec@tis.com Subject: Re: notes from developer's portion of IETF meeting Block ciphers like DES without integrity are intensely vulnerable to active attacks, for any kind of machine, and in more ways than have been described on this list. Block splicing based on captured ciphertext with known plaintext allows the attacker great latitude for inserting bogus traffic with only minimal integrity violations. The last block attack shows how you can use this general technique even without knowing all the plaintext, and traffic modification poses yet another problem. Weak integrity checks in the application are an illusionary defense. I'd thought the goal of the group was to protect the Internet environment, i.e. an active attack environment. Thus, it seems to me that leaving integrity as an administrator option is contrary to the charter of the group. The conditions for safely dispensing with integrity are very narrow, i.e. one of 1. Physical impossibility of active attacks (NB analysis must be end-to-end) 2. Encryption method has strong internal integrity (not DES) 3. Connection limited to use by applications with strong internal integrity 4. Attacker can never know or guess ciphertext/plaintext pairs from observed traffic I am hesitant to leave this analysis to the system administrator; item 1 might arguably be an administrator decision, being highly environmental, but are these environments of concern to the Internet? Depending on implementations, the ratio of MD5 speed to DES speed can be between 3 to 1 and 10 to 1*, according to my notes, so integrity should not be eliminated based on performance considerations. However, the time to transmit 128 bytes on a slow connection is considerable and especially annoying if the data is shorter than the checksum, so that I can well understand the reluctance to include the it. Nonetheless, it seems very unlikely to me that a risk analysis would show that elimination of integrity was a winning trade-off, even at low speeds. Hilarie * ratios reported outside this range may depend on cache effects or byte reordering subtleties From owner-ipsec Wed Apr 23 15:53:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA10264 for ipsec-outgoing; Wed, 23 Apr 1997 15:52:17 -0400 (EDT) Message-Id: <9704231957.AA16928@cichlid.raleigh.ibm.com> To: "C. Harald Koch" Cc: dpkemp@missi.ncsc.mil (David P. Kemp), ipsec@tis.com Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt In-Reply-To: Your message of "Wed, 23 Apr 1997 14:47:40 EDT." <97Apr23.144337edt.11650@janus.border.com> Date: Wed, 23 Apr 1997 15:57:13 -0300 From: Thomas Narten Sender: owner-ipsec@ex.tis.com Precedence: bulk > That's 6.4 percent on elgreco, and 2.3 percent on janus, of all data packets > received out-of-order. I wouldn't define that as "rare", especially given the > (additional) performance penalties for dropping them instead of queueing them. Are these "netstat -s" numbers that come from a BSD-derived TCP stack? If so, I believe that numbers like: 198927 out-of-order packets (40226774 bytes) also include TCP segments that arrive *after* a packet loss, i.e., they are out of order in the sense that they aren't the packet TCP expects to see next. However, they aren't out of order in the sense that the missing packet will arrive later due to reordering by the network. More likely, the missing segment was lost and needs to be retransmitted. So unless I'm mistaken about what this stat means, I don't think it counts the right quantity (unfortunately). Thomas From owner-ipsec Wed Apr 23 15:55:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA10302 for ipsec-outgoing; Wed, 23 Apr 1997 15:55:22 -0400 (EDT) Date: Wed, 23 Apr 1997 15:58:01 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704231958.PAA22586@earth.hpc.org> To: adams@cisco.com Cc: ipsec@tis.com In-reply-to: Yourmessage <199704231915.MAA15719@baskerville.CS.Arizona.EDU> Subject: RE: notes from developer's portion of IETF meeting Sender: owner-ipsec@ex.tis.com Precedence: bulk > Btw, Dan, I think you're correct in stating why we are still > having this discussion and where it came from in the first place.. Not the way I remember it, but having followed this discussion for so many years is nothing to be bragged about. > Table 18.2 in Applied Cryptography, Second Edition, says that MD5 will > do 174 Mbytes a second on a 33MHz 486SX... Ridiculous by a factor of 100. Note the spelling of snefru for an indication of the dedication to accuracy in that table. > Optional integrity for ESP? No.? yes...? I'd say no. Well, for AH+ESP, my numbers indicate that would be a 10% to 30% penalty, besides the bytes for the extra checksum. A sort of heavy penalty for authenticating the header. All I'm saying is that you must have SOME integrity, not that you need it twice. > Optional confidentiality for ESP? I'd also say no. Unless you've got AH with it. Why not use AH instead? Because, it may well turn out that at high speeds (> OC-3), AH will have regrettable performance no overwhelming benefit. Hilarie From owner-ipsec Wed Apr 23 16:44:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA10702 for ipsec-outgoing; Wed, 23 Apr 1997 16:43:53 -0400 (EDT) Date: Wed, 23 Apr 1997 16:49:33 -0400 From: Norman Shulman X-Sender: norm@rafael.rnd.border.com To: "C. Harald Koch" cc: ipsec@tis.com Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt In-Reply-To: <97Apr23.144337edt.11650@janus.border.com> Message-Id: <97Apr23.164528edt.11656@janus.border.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Wed, 23 Apr 1997, C. Harald Koch wrote: > In message <9704181331.AA15062@cichlid.raleigh.ibm.com>, Thomas Narten writes: > > I also agree, and have been disheartened by the number of times the > > above question has been asked but not answered. Indeed, it has been > > my impression that the vast majority of IP packets are delivered in > > order (one reason why TCP's header prediction works well in > > practice). It is rare in practice to have packets arrive out of > > order. Which begs the question of whether a window is even > > needed. Does someone have data that argues otherwise? > > Two sample points, my internet firewalls (A good place to look, since they > re-synthesize all TCP streams in/out. This is roughly akin to combining the > statistics for all 100 hosts behind the firewalls...). > > ----- elgreco ----- > 2:39pm up 11 days, 4:51, 1 user, load average: 0.25, 0.16, 0.05 > > 5796665 packets received > 2703533 acks (for 1066489852 bytes) > 3301088 packets (900448165 bytes) received in-sequence > 107878 completely duplicate packets (10966707 bytes) > 987 packets with some dup. data (122695 bytes duped) > 198927 out-of-order packets (40226774 bytes) > > > ----- janus ----- > 2:38pm up 11 days, 4:52, 1 user, load average: 0.02, 0.06, 0.02 > > 28417190 packets received > 19533317 acks (for 371944057 bytes) > 21278080 packets (176197867 bytes) received in-sequence > 51170 completely duplicate packets (12418673 bytes) > 519 packets with some dup. data (63691 bytes duped) > 199859 out-of-order packets (69912188 bytes) > > > That's 6.4 percent on elgreco, and 2.3 percent on janus, of all data packets > received out-of-order. I wouldn't define that as "rare", especially given the > (additional) performance penalties for dropping them instead of queueing them. This is interesting data, but I think the percentages were miscalculated. Apparently the formula used was out-of-order/(total - acks). But note that acks + in-sequence > total, so it seems that acks includes all acks, isolated and piggy-backed. I'm not sure exactly how all the statistics fit together, but using a conservative formula that considers everything except isolated acks out-of-order/(in-sequence + duplicates + out-of-order) gives 5.5% on elgreco and 0.9% on janus. These proportions are too high to ignore. Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@border.com Fax 1 416 813 2001 From owner-ipsec Wed Apr 23 17:00:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA10797 for ipsec-outgoing; Wed, 23 Apr 1997 16:59:02 -0400 (EDT) Date: Wed, 23 Apr 1997 17:03:34 -0400 From: Norman Shulman X-Sender: norm@rafael.rnd.border.com To: Hilarie Orman cc: ipsec@tis.com Subject: RE: notes from developer's portion of IETF meeting In-Reply-To: <199704231958.PAA22586@earth.hpc.org> Message-Id: <97Apr23.170023edt.11654@janus.border.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Wed, 23 Apr 1997, Hilarie Orman wrote: > > Table 18.2 in Applied Cryptography, Second Edition, says that MD5 will > > do 174 Mbytes a second on a 33MHz 486SX... > > Ridiculous by a factor of 100. Note the spelling of snefru for an > indication of the dedication to accuracy in that table. The column mislabeled Encryption Speed is in KB/sec. Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@border.com Fax 1 416 813 2001 From owner-ipsec Wed Apr 23 22:07:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA12396 for ipsec-outgoing; Wed, 23 Apr 1997 22:05:50 -0400 (EDT) Message-Id: <3.0.1.32.19970423215014.006b724c@alphy.lkg.dec.com> X-Sender: altamatt@alphy.lkg.dec.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 23 Apr 1997 21:50:14 -0400 To: Rob Adams From: Matt Thomas Subject: RE: notes from developer's portion of IETF meeting Cc: ipsec@tis.com In-Reply-To: <01BC4FDF.39536800@Tastid.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk >Optional integrity for ESP? No.? yes...? I'd say no. I was one of ones arguing for option integrity for ESP. Why? Because Mobile-IPv6 requires authentication of the entire packet (especially the routing and/or destination option headers) I didn't want to have to do an AH and then integrity again for ESP. However I did think of an alternative after the meeting (and since this topic has been reopened...): Define AH such if AH and ESP are in the same packet but are not separated by an IPv4 or IPv6 header (ie. not tunnelled), define the AH such that it stops after the first 12 bytes of ESP header. If this was the case, I would not mind having ESP always include integrity since I would be not doing integrity twice over the entire packet. >Optional confidentiality for ESP? I'd also say no. Agreed. -- Matt Thomas Internet: matt.thomas@altavista-software.com Internet Locksmith WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc. From owner-ipsec Thu Apr 24 07:47:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA15451 for ipsec-outgoing; Thu, 24 Apr 1997 07:46:00 -0400 (EDT) From: Uwe Ellermann Date: Thu, 24 Apr 1997 09:12:33 +0200 (MET DST) Message-Id: <199704240712.JAA03901@wave.fwl.dfn.de> To: ipsec@tis.com, ho@earth.hpc.org, adams@cisco.com Subject: RE: notes from developer's portion of IETF meeting X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > Optional integrity for ESP? No.? yes...? I'd say no. Considering a VPN scenario using tunnel-mode ESP, mandatory integrity for ESP wouldn't gain much more security, iff all tunneled IP packets are already required to use AH by the site's policy. It should be possible to save the additional overhead of applying integrity mechanisms twice (ie. AH and ESP) on the same data. Greetings, Uwe Ellermann -- Uwe Ellermann, Ellermann@fwl.dfn.de, Tel.:+49-40-5494-2262, Fax: -2241 DFN-FWL, University of Hamburg, Vogt-Koelln-Strasse 30, D-22527 Hamburg PGP-key available via http://www.cert.dfn.de/~ue/pgp.html or Keyserver From owner-ipsec Thu Apr 24 17:08:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA19366 for ipsec-outgoing; Thu, 24 Apr 1997 17:02:29 -0400 (EDT) Message-Id: <199704242108.RAA21948@codex.cis.upenn.edu> To: Uwe Ellermann cc: ipsec@tis.com, ho@earth.hpc.org, adams@cisco.com Subject: Re: notes from developer's portion of IETF meeting In-reply-to: Your message of "Thu, 24 Apr 1997 09:12:33 +0200." <199704240712.JAA03901@wave.fwl.dfn.de> Date: Thu, 24 Apr 1997 17:06:52 +0100 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In message <199704240712.JAA03901@wave.fwl.dfn.de>, Uwe Ellermann writes: > >Considering a VPN scenario using tunnel-mode ESP, mandatory >integrity for ESP wouldn't gain much more security, iff all >tunneled IP packets are already required to use AH by the >site's policy. It should be possible to save the additional >overhead of applying integrity mechanisms twice (ie. AH and ESP) >on the same data. So your end host is creating packets with an AH header. Who can verify this AH header ? - - Your local firewall: Not useful in the general case. All it does it further assure the firewall that you're who you claim you are. But since the packets appear on the trusted network, this is already implied. In this case, the local firewall would strip that header, add an ESP(*) header to the remote firewall and send the packet out. - - The remote end host: How would the remote firewall know when to let packets in ? Remember, it can't verify them. In this case, your local firewall would add the ESP header to prove to the other firewall that the packet came from a trusted network (VPN and all that). Usually, this AH SPI would be established after the firewalls themselves have established an ESP SPI. - - The remote firewall: In that case, you don't really need the local firewall to do anything; you should use ESP to the remote firewall, and the local firewall should do nothing. This would imply that your administrator trusts you not to violate the VPN. If he doesn't, then you shouldn't be able to establish an SPI with the remote firewall/host in the first place (wouldn't allow the KMP to run in proxy mode, or whatever it's called today). - - A (sub)set of the above: we don't have group shared keys (yet ?). (*) ESP with authentication So i think the scenario you presented is unrealistic. - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBM1/La70pBjh2h1kFAQFw8QP/aUZQ+RPttO4kr6K1W44NBaVV86tPpBNU zVl7VVF3bYILoqmLvFuYeehAr5b5WWJL51wlYU8lH6tpCXMAZAxWzFmopHjGTQxj XM4SQIVdxAshW59zsmkcSIHCWR+Hqqfn0AEHde0x6YhNMp8WjETesvzamfIIM5r1 Wys6kEgz/DU= =i+KC -----END PGP SIGNATURE----- From owner-ipsec Mon Apr 28 21:52:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA14129 for ipsec-outgoing; Mon, 28 Apr 1997 21:47:24 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199704222338.QAA11325@joseph.cs.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Apr 1997 14:30:47 -0400 To: David Wagner From: Stephen Kent Subject: Re: notes from developer's portion of IETF meeting Cc: ipsec@ex.tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dave, I agree that it is always approrpiate to ask whether one is distorting a protocol like ESP to accommodate a "special need" for some application. If so, then leave the common protocol alone and suggest that the application do something application-specific. However, this is not the case here. The example you cite "...MACing entire kilobytes at a time..." is completely off base for this context. One of the aspects of packet voice and packet video that makes use of crypto authentication relatively expensive is the small size of the packets. So the "custom optimazation" you cite is totally inapprorpiate here. You note that authentication should be faster than encryption, which is often true, but I don't see why this is relevant to the argument. If I am willing top accept the delay and the possible throughptu limitations imposed by encryption, is that supposed to imply that I will not mind the additional delay and the throughout limits that adding HMAC will imply? Unless we have parallel processing of the ESP packet (which probably will not be common), the delay imposed by the HMAC computation is serial and thus one ought not assume that this added delay is not a problem just because the encryption delay may have been acceptable. I think we're loosing sight of the issues here. Contrary to your comment, we are not "carving out a hole" in the specs. I suggested that it is reasonable to allow negotiation of an ESP-protected SA without authentication. This is a characteristic of the current IPSEC RFCs and I merely indicated a plan to preserve this modularity. This is not a change from the previously issued specs. We have had additional transforms that have been published since the base RFCs, but the current RFCs don't require combined encryption and authentiction for ESP (the default transforms don't do this), nor do they precude definition of new transforms that have that requirement. The objections to retaining this modular feature seem to be based on several different observations: 1. Under some circumstances, use of encryption w/o authentication can result in violations of confidentiality, as Steve Bellovin has pointed out. I agree that use of ESP with encryption (but w/o authentication) would be inappropriate in most cases where such attacks could be mounted. If one is electing encryption, it is inappropriate to use ESP in a fashion that could undermine the confidentiality service that is implied. However, one can safely use encryption w/o authentication in some contexts because the network enviromment effectively precluded the sort of attacks that would compromise confidentiality. So the thrust of this argument is that we ought to foolproof IPSEC to prevent selection ofpotentially dangerous security service combinations. I'll address this arguemnt below. 2. Some forms of chosen plaintext attack are facilitated by use of encryption w/o authentication. This is true, but I am not at all persuaded by the argument. History has sihown many ways in which chosen plainetext attack scan be launched against systems, so closing this one attack path does not, by itself, seem worth removing a potentially useful function. 3. Encryption w/o authentication is dangerous because all packets should be authenticated. This seems like another insistance on foolproofing IPSEC, i.e., preventing selection/configuration of any combination of options that could lead to insecurity. I argue that one may use higher level authentication mechanisms in conjunction with lower level encryption to achieve a reasonable set of security features for an application. This may be more attractive than either turing on all of the security services offered at a lower layer, or implementing all of the services in the application. I appreciate the notion that most users are not prepared to make determinations of when selective use of encryption w/o authentication is appropriate, and thus one can argue that we ought to change the spec to prevent use of ESP in a fashion that might subject them to such attacks. However, I am hesitant to take this approach. Experience shows that we cannot do that for all elements of a system; trying to do it in this narrow context deprives users/system designers of flexibility. Why don't we also say that you cannot implement IPSEC if the crypto will be done in software, which is susceptibale to many forms of attack that hardware crypto would prevent? Why not preclude implemenmtation in a typically managed Unix workstation, since such a worksta tion is subject to many attacks that will circumvent IPSEC, as opposed to use with a more secure Unix platform? These and other vulnerabilities associated with use of IPSEC present significant opportunities for attack, but we're willing to live with them. If we decide to insist on authentication for all encrypted packets, then we must do so without the expectation that this decision will really foolproof use of IPSEC, and with the understanding that it will impose additional burdens on some users. Also, as noted in another message I just sent, there may be crypto modes that are not subject to the sorts of attacks that Steve Bellovin has cited, in which case precluding authenticationless ESP is unduly restrictive for a protocol that is supposed to be algorithm independent. Steve From owner-ipsec Mon Apr 28 21:52:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA14123 for ipsec-outgoing; Mon, 28 Apr 1997 21:47:21 -0400 (EDT) From: Dan.McDonald@Eng.sun.com (Dan McDonald) Message-Id: <199704290153.SAA22730@kebe.eng.sun.com> Subject: Test... To: ipsec@tis.com Date: Mon, 28 Apr 1997 18:53:09 -0700 (PDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Sorry 'bout this, but I haven't received any IPsec mail lately. Curious, Dan From owner-ipsec Mon Apr 28 22:23:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA14602 for ipsec-outgoing; Mon, 28 Apr 1997 22:23:29 -0400 (EDT) Message-Id: <199704281959.MAA00938@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Stephen Kent Cc: ipsec@tis.com Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt In-Reply-To: Your message of "Fri, 18 Apr 1997 11:31:42 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Apr 1997 12:59:00 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, In Memphis there was general agreement that AR must always be sent but that the receiver could elect to check it or not (it is in the receiver's best interest to do so anyway). You objected with the following point: > - it is true that the AR window protects the receiver, and imposes > no changes in how the sender operates. However, I think that the use or > non-use of use of AR is of interest to the sender. If communication > performance problems arise between two IPSEC sites, one reason might be the > rejection of some number of packets due to the size of the AR and the > out-of-order delivery characteristics associated with the path. Certainly, > if a default window size of 1 were adopted (as had been suggested), there > would be a significant opportunity for such behavior. However, if the use > of AR is purely at the discretion of the receiver, I have no way of knowing > if that might be a problem, if I am troubleshooting the problem from the > sender's end. So, at a minimum, I'd like to know if AR is a characteristic > of each SA. I don't see this as a compelling arguement. If you want to troubleshoot the problem from the sender's end, you always assume it is being used. (If it is not then AR is not the problem). I can't see such troubleshooting being done in a vacuum anyway. For the sender to determine the cause of a large number of his packets being rejected by the receiver, some coordination with the receiver is necessary (like phoning the site and asking whether anything interesting is in the audit logs, or accessing some IPsec MIB on the receiver). This WG seems to have a tendancy to say "oh, just let key management handle that" and AR (and the size of the AR window!) seems to fall into this category. A problem with this is that the more things key management must negotiate the more likely all offers from initiator will be rejected by the responder. And (the voice of experience talking here) that is a difficult problem to troubleshoot. Another point raised in Memphis is that complexity can introduce subtle bugs in code. Since we're talking about security code, a subtle bug can be a security hole. Is a relatively simple, secure 95% solution better than a complex, potentially problematic 97% solution? I think so. There will always be obscure edge conditions for which IPsec is a solution but not an optimal one. (Also, note that the more options to negotiate the more complex the method of configuration-- and the more complex the configuration itself-- and the more likely that a system can be misconfigured, with potentially tragic results). AR being always sent, optionally used, and a window size of 32 is a relatively simple solution that can be implemented straighforwardly without worrying about special case coding. It may not be the best solution for every single potential use of IPsec but for the vast majority it is. regards, Dan. From owner-ipsec Mon Apr 28 22:26:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA14628 for ipsec-outgoing; Mon, 28 Apr 1997 22:26:29 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.1.32.19970423215014.006b724c@alphy.lkg.dec.com> References: <01BC4FDF.39536800@Tastid.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Apr 1997 14:36:57 -0400 To: Matt Thomas From: Stephen Kent Subject: RE: notes from developer's portion of IETF meeting Cc: Rob Adams , ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Matt, I think we're too far along to change the definition of what is covered by AH, as per your suggestion. (I was pleasantly surprized that the meeting was amenable to the most significant proposed change, i.e., the reversal of the order of encryption and authentcation in ESP.) The proposals we're deabting now involve allowing certain combinations of security services that are already part of the ESP spec; we're merely arguing over how bundled these service are. Steve From owner-ipsec Mon Apr 28 22:26:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA14629 for ipsec-outgoing; Mon, 28 Apr 1997 22:26:31 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <01BC4FDF.39536800@Tastid.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Apr 1997 14:28:46 -0400 To: Rob Adams From: Stephen Kent Subject: RE: notes from developer's portion of IETF meeting Cc: "ipsec@tis.com" , "'Hilarie Orman'" Sender: owner-ipsec@ex.tis.com Precedence: bulk Rob, Another message addresses the question of whether ESP w/o crypto authentication is meaningful, so I'll just comment on ESP w/o encryption. The issue I have raised is not so much the raw speed of the algorithm, but rather the overhead of data manipulation related to the fields in the IP header that have to be copied and those that have to be zeroed and the logic to make sure we treat each one appropriately. AH is a somewhat awkward protocol because it reaches forward in the protocol stream, in a selective fashion, unlike ESP which is a traditional encapsulation protocol and "cleaner." But, AH can be appropriate in some circumstances, as I have cited in previous messages. However, some of the examples cited for AH vs. encryptionless ESP are not good ones. For example, if we have a tunnel-mode SA between two IPSEC sites, the outer IP header doesn't seem to require protection and thus ESP-based authentication would be just fine. So, no, it's not settled yet ... Steve From owner-ipsec Mon Apr 28 22:33:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA14747 for ipsec-outgoing; Mon, 28 Apr 1997 22:33:01 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199704231601.TAA13455@ee.technion.ac.il> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Apr 1997 12:59:50 -0400 To: Hugo Krawczyk , ho@earth.hpc.org (Hilarie Orman) From: Stephen Kent Subject: Re: notes from developer's portion of IETF meeting Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Hugo + Hilarie, You made some good points why CBC mode, w/o cryptographic-based authentication, is not generally adequate to protect traffic from disclosure given the ability to launch more subtle attacks at the IP or higher layers. However, ESP is intended to be an algorithm and mode independent protocol, What about other modes? I recall a plaintext/ciphertext block chaining mode developed by IBM in the early 80s (late 70s?) that would seem to be more resistant to any form of packet modification. Would use of this mode with ESP still require separate, cryptographic-based authentication, in your opinion? Might there be other modes that would provide adequate protection? if so, then we ought not preclude use of ESP with encryption but without cryptographic-based authentication. Also, let me suggest another application example of where I think this would be approrpriate, perhaps even with CBC mode. The directory access protocol for X.500, DAP, has built-in signature autehntication and integrity mechansims, and even a weak form of timestamp-based anti-replay. However, because of the use of chaining in X.500, no confidentiality is provide at the application layer. Instead, the spec calls for use of lower layer encrytion for that purpose, e.g., at the network layer. So, this would seem to be a reasonable context in which to use ESP w/o authentication. Steve From owner-ipsec Mon Apr 28 22:35:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA14825 for ipsec-outgoing; Mon, 28 Apr 1997 22:35:05 -0400 (EDT) Date: Mon, 28 Apr 97 15:50:24 GMT From: "William Allen Simpson" Message-ID: <5752.wsimpson@greendragon.com> To: ipsec@tis.com Subject: policy versus protocol Sender: owner-ipsec@ex.tis.com Precedence: bulk > Date: Wed, 23 Apr 1997 13:00:19 -0400 > From: ho@earth.hpc.org (Hilarie Orman) > I'd thought the goal of the group was to protect the Internet > environment, i.e. an active attack environment. Thus, it seems to me > that leaving integrity as an administrator option is contrary to the > charter of the group. > Nobody is talking about leaving _anything_ to an administrator. We are talking about how to make a _protocol_ specification (bits on a wire) generic enough to handle current and future needs. > The conditions for safely dispensing with integrity are very narrow, > i.e. one of > > 1. Physical impossibility of active attacks (NB analysis must be > end-to-end) > 2. Encryption method has strong internal integrity (not DES) > 3. Connection limited to use by applications with strong > internal integrity > 4. Attacker can never know or guess ciphertext/plaintext pairs > from observed traffic > This is good (although I'd put #2 first), and should be in the architecture document! Then, implementors can read the architecture to decide what threat scenarios apply to their product. This is supposed to be a protocol Working Group, not a policy debate group. Document the applicability, and let the implementors make the choices.... For example, only the implementor knows whether the encryption method includes integrity. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Mon Apr 28 22:35:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA14820 for ipsec-outgoing; Mon, 28 Apr 1997 22:35:04 -0400 (EDT) Date: Mon, 28 Apr 97 15:59:30 GMT From: "William Allen Simpson" Message-ID: <5753.wsimpson@greendragon.com> To: ipsec@tis.com Subject: policy versus protocol Sender: owner-ipsec@ex.tis.com Precedence: bulk > Date: Wed, 23 Apr 1997 19:01:22 +0300 (IDT) > From: Hugo Krawczyk > If there are applications that consciously decide to take all these risks > I suggest they negotiate the EMPTY-MAC as their authentication > algorithm (no processing penalty) rather than having ipsec explictly allowing > integrity-less IP security. > I think that Hugo has hit the nail on the head here. Instead of arguing about whether _WE_ should or should not allow this or that combination, let's stick to documenting the protocol, and leave the policy up to the application. If NO_INTEGITY is negotiated, we need to know what the ESP packet looks like. (I'd say, elide the trailing field.) If NO_ENCRYPTION is negotiated, we need to know what the ESP packet looks like. (I'd say, no fields would change.) Let's stick to our mission, and not be sidetracked by policy. If we had followed the lead of the I_R_TF security WG, we'd never have had any progress.... Leave the research to the researchers, and let's keep our nose to the engineering grindstone. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Mon Apr 28 22:35:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA14826 for ipsec-outgoing; Mon, 28 Apr 1997 22:35:08 -0400 (EDT) Date: Mon, 28 Apr 97 16:07:37 GMT From: "William Allen Simpson" Message-ID: <5754.wsimpson@greendragon.com> To: ipsec@tis.com Subject: AH versus authentication-only ESP Sender: owner-ipsec@ex.tis.com Precedence: bulk > Date: Tue, 22 Apr 1997 16:26:42 -0400 > From: Stephen Kent > It's good to see an exmaple of the rationale behind the proposal. In > general, if I am tunneling traffic between two security gateways, why do I > need to protect the outer IP header? Would I not generally discard it upon > arrival? I'd prefer that Moskowitz (and Richardson) speak as to their own rationale. But my recollection is, there is a demonstrated trust relationship between the firewalls themselves, and between the end-points and the firewalls. The only protocol tag we have to identify these firewalls is the IP address. The SPI is coupled to the IP address. Therefore, the IP address needs to be protected. > The inner IP header is the real focus of protection. There is no > reason why I cannot multiplex the same scope of traffic in a tunnel with > ESP as I can with an AH tunnel, so I don't view that as a differentiator. > I am not sure that this is true. Depends on the trust relationship. If the firewall is proxying a trust relationship for the end-point, I don't think that the same tunnel keys would be used (differing SPIs). To put the shoe on the other foot, please demonstrate to us that there is _no_ use for _ever_ authenticating the source and destination of an IP datagram. If you cannot do that, then we still need AH. And if we still need AH, then we should simplify our _protocol_ implementations to use _one_ method for authentication-only datagrams. Meanwhile, as I noted in a (just written) previous message, this whole argument may be needless. Authentication-only ESP is impossible to prevent, as the key-management can simply negotiate a non-encryption algorithm. So, let's stick to bits on the wire. What would change in the ESP bits? I'd say, nothing. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Mon Apr 28 22:35:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA14828 for ipsec-outgoing; Mon, 28 Apr 1997 22:35:11 -0400 (EDT) Date: Mon, 28 Apr 1997 12:23:40 -0400 From: Norman Shulman X-Sender: norm@rafael.rnd.border.com To: Karen Seo cc: ipsec@tis.com, skent@bbn.com, clynn@bbn.com, nyuan@bbn.com Subject: Re: PMTU/DF issues In-Reply-To: <199704221942.PAA04915@relay.hq.tis.com> Message-Id: <97Apr28.121922edt.11651@janus.border.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Tue, 22 Apr 1997, Karen Seo wrote: > ========================================================================= > Appendix X -- Analysis/Discussion of PMTU/DF/Fragmentation Issues > > **************************************************************************** > Overall, the fragmentation/reassembly approach described above works > for all cases examined. > > The results for each of the 24 cases is shown below ("works" = will > work if system fragments after outbound IPSEC processing, reassembles > before inbound IPSEC processing). Notes indicate implementation > issues. > > b. Hosts (Bump-in-the-stack) -- put IPSEC between IP layer and > network drivers. In this case, the IPSEC module would have to > do something like one of the following for fragmentation and > reassembly. > - do the fragmentation/reassembly work itself and > send/receive the packet directly to/from the network > layer. In AH or ESP transport mode, this is fine. In > AH or ESP tunnel mode where the tunnel is to the > ultimate destination, this is fine. But in AH or ESP > tunnel modes where the tunnel end is different from > the ultimate destination and where the source host is > multi-homed, this approach could result in sub-optimal > routing because the IPSEC module may be unable to > obtain the information needed (LAN interface and > next-hop gateway) to direct the packet to the > appropriate network interface. This is not a problem > if the interface and next-hop gateway are the same for > the ultimate destination and for the tunnel end. But > if they are different, then IPSEC would need to know > the LAN interface and the next-hop gateway for the > tunnel end. Seems to me that if the interface and next-hop gateway are different for the ultimate destination and for the tunnel end, then the tunnel end is not a security gateway. > **************************************************************************** > > 3. Path MTU Discovery -- As mentioned earlier, "ICMP PMTU" refers to an > ICMP message used for Path MTU Discovery. > > A. The amount of information returned with the ICMP message is limited > and this affects what selectors are available to identify security > associations, originating hosts, etc. for use in further propagating > the PMTU information. > > The destination security gateway and SPI uniquely define a security > association which in turn defines a set of possible originating > hosts. At this point, SG1 could: > a. send the PMTU information to all the possible originating hosts. > This would not work well if the host list is a wild card or if > many/most of the hosts weren't sending to SG1; but it might work > if the SPI/destination/etc mapped to just one host. Seems to me that if a host wasn't sending to SG1 then it's not an intended recipient of this PMTU information. Am I missing something here? Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@border.com Fax 1 416 813 2001 From owner-ipsec Tue Apr 29 09:56:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA17394 for ipsec-outgoing; Tue, 29 Apr 1997 08:37:11 -0400 (EDT) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: <199704290153.SAA22730@kebe.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Apr 1997 08:31:26 -0400 To: Dan.McDonald@Eng.sun.com (Dan McDonald) From: Edward Lewis Subject: Re: Test... Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk At 9:53 PM -0400 4/28/97, Dan McDonald wrote: >Sorry 'bout this, but I haven't received any IPsec mail lately. > >Curious, >Dan We (TIS/host of the the list) have been having Internet connectivity problems since sometime over the weekend... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com Opinions expressed are property of my evil twin, not my employer. From owner-ipsec Tue Apr 29 14:02:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA19092 for ipsec-outgoing; Tue, 29 Apr 1997 14:00:38 -0400 (EDT) Date: Tue, 29 Apr 1997 09:02:34 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199704291302.JAA28064@earth.hpc.org> To: kent@bbn.com Cc: hugo@ee.technion.ac.il, ipsec@tis.com In-reply-to: Yourmessage Subject: Re: notes from developer's portion of IETF meeting Sender: owner-ipsec@ex.tis.com Precedence: bulk Yes, I think my note is consistent with yours, where I listed the conditions where I thought that ESP w/o integrity was OK, but then I expressed doubt as to the wisdom of leaving this judgment up to the individual user or system administrator, given that it is less than straightforward to analyze the safety of such a decision and that, with the exception of very low speed lines, the performance is not greatly impacted by requiring integrity. I could see having it be a property of the transform --- a transform designer can specify the null integrity algorithm if he knows that the encryption algorithm has built-in integrity --- but I don't find the DAP example compelling. Hilarie From owner-ipsec Tue Apr 29 14:05:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA19250 for ipsec-outgoing; Tue, 29 Apr 1997 14:05:11 -0400 (EDT) Message-Id: <3.0.1.32.19970429080056.00753230@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 29 Apr 1997 08:00:56 -0400 To: Dan.McDonald@Eng.sun.com (Dan McDonald) From: Rodney Thayer Subject: Re: Test... Cc: ipsec@tis.com In-Reply-To: <199704290153.SAA22730@kebe.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Gee you must be getting all sorts of work done! At 06:53 PM 4/28/97 -0700, you wrote: >Sorry 'bout this, but I haven't received any IPsec mail lately. > >Curious, >Dan > > Rodney Thayer +1 617 332 7292 Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA Fax: +1 617 332 7970 http://www.shore.net/~sable "Developers of communications software" From owner-ipsec Tue Apr 29 14:45:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA19892 for ipsec-outgoing; Tue, 29 Apr 1997 14:44:04 -0400 (EDT) To: IETF-Announce@ietf.org cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-esp-rc5-cbc-00.txt Date: Tue, 29 Apr 1997 11:42:50 -0400 Message-ID: <9704291142.aa01223@ietf.org> 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 : The ESP RC5-CBC Algorithm Author(s) : R. Pereira, R. Baldwin Filename : draft-ietf-ipsec-esp-rc5-cbc-00.txt Pages : 5 Date : 04/25/1997 This draft describes the RC5 block cipher algorithm as to be used with the IPSec Encapsulating Security Payload (ESP). 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-esp-rc5-cbc-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-rc5-cbc-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-esp-rc5-cbc-00.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19970425145805.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-rc5-cbc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-rc5-cbc-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970425145805.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Apr 29 19:59:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA21995 for ipsec-outgoing; Tue, 29 Apr 1997 19:56:34 -0400 (EDT) Date: Tue, 29 Apr 97 23:55:00 GMT From: "William Allen Simpson" Message-ID: <5765.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: notes from developer's portion of IETF meeting Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: ho@earth.hpc.org (Hilarie Orman) > with the exception of very low speed lines, the performance is not > greatly impacted by requiring integrity. I could see having it be a > property of the transform --- a transform designer can specify the > null integrity algorithm if he knows that the encryption algorithm has > built-in integrity --- but I don't find the DAP example compelling. > (sigh) Having lived through the argument between Cisco and NetStar over whether PPP over OC-3 (155 Mbps) needed 2 or 4 bytes of checksum (furtunately PPP will negotiate) -- welcome to the vendor world. People really _do_ care about performance on any speed of line. The argument is compelling to the implementors. And low speed is pretty much defined as less than T1 (1.5 Mbps) these days. ISDN 2B isn't cutting it anymore.... WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Wed Apr 30 00:31:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA23384 for ipsec-outgoing; Wed, 30 Apr 1997 00:26:51 -0400 (EDT) Message-Id: <199704300427.AAA24011@relay.hq.tis.com> Date: Wed, 30 Apr 97 0:29:53 EDT From: Karen Seo To: Norman Shulman cc: ipsec@tis.com Subject: Re: PMTU/DF issues Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Norm, >>Seems to me that if the interface and next-hop gateway are different >>for the ultimate destination and for the tunnel end, then the tunnel >>end is not a security gateway. You're right that the tunnel end (security gateway) is highly likely to be on the regular path to the ultimate destination. But there could also be more than one path to the destination, e.g., the host could be at an organization with 2 firewalls. And the path being used could involve the less commonly chosen firewall. > **************************************************************************** > > 3. Path MTU Discovery -- As mentioned earlier, "ICMP PMTU" refers to an > ICMP message used for Path MTU Discovery. > > A. The amount of information returned with the ICMP message is limited > and this affects what selectors are available to identify security > associations, originating hosts, etc. for use in further propagating > the PMTU information. > > The destination security gateway and SPI uniquely define a security > association which in turn defines a set of possible originating > hosts. At this point, SG1 could: > a. send the PMTU information to all the possible originating hosts. > This would not work well if the host list is a wild card or if > many/most of the hosts weren't sending to SG1; but it might work > if the SPI/destination/etc mapped to just one host. >>Seems to me that if a host wasn't sending to SG1 then it's not an >>intended recipient of this PMTU information. >> >>Am I missing something here? H1 =================== H3 \ | | / H0 -- SG1* ---- R1 ---- SG2* ---- R2 -- H5 / ^ | \ H2 |........| H4 Assuming I understand your point, you're correct.... Suppose that the security policy for SG1 is to use a single SA to SG2 for all the traffic between hosts H0, H1, and H2 and hosts H3, H4, and H5. Then suppose H0 sends traffic to H5 that causes R1 to send an ICMP PMTU message to SG1. If the PMTU message has only the SPI, SG1 will be able to look up the SA and find the list of possible hosts (H0, H1, H2); but SG1 will have no way to figure out that H0 sent the traffic that triggered the ICMP PMTU message. At this point, SG1 has the two choices outlined previously: a) send the PMTU information to all 3 hosts. As you observed, H1 and H2 aren't the intended recipients for the PMTU information and won't know what to do with it. b) hold the PMTU information until another too-big packet arrives and then use that packet and the PMTU information to construct a ICMP PMTU for the originating host (H0). Karen From owner-ipsec Wed Apr 30 02:32:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA23957 for ipsec-outgoing; Wed, 30 Apr 1997 02:30:57 -0400 (EDT) Message-Id: <199704300636.XAA09783@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Tue, 29 Apr 97 23:36:51 -0700 To: baldwin@RSA.COM, rpereira@TimeStep.com Subject: Questions/comments re draft-ietf-ipsec-esp-rc5-cbc-00.txt cc: ipsec@tis.com Reply-To: dennis.glatting@plaintalk.bellevue.wa.us Sender: owner-ipsec@ex.tis.com Precedence: bulk I have some questions and comments regarding draft-ietf-ipsec-esp-rc5-cbc-00.txt. The first question I have is why 40 bits? I am under the impression the IPsec wg, for political reasons, chose to exclude export weakened cipher usage. I am not familiar with RC5's status. Is it a trade secret like RC2? I see RSA has applied for a patent. Will implementaters have to license RC5 from RSA? If it need be licensed could that be a detriment to its wide-spread use in IPsec? I'm a bit confused about the following paragraph from the document. > 2.3 Payload > > RC5-CBC requires an explicit Initialization Vector (IV) of 8 octets > (64 bits) that immediately precedes the cipher-text in the payload. > A new IV must be pseudo-randomly generated for each packet and then > used to encrypt that plain-text. When decrypting, the first 8 > octets of the payload are used as a IV to decrypt the remaining > payload octets. > Those statements are really confusing. They say the IV precedes the cipher-text but then say first 8 octets of the payload (the SPI and sequence number?) are used to decrypt the rest. As Scoobe Doo says, Er? The CBC method seems a bit weird to me too. Is the IV XORed with each block? Regarding key material, why is the key material derived as stated in section 4 rather than slice and dice? -dpg From owner-ipsec Wed Apr 30 10:58:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27368 for ipsec-outgoing; Wed, 30 Apr 1997 10:57:02 -0400 (EDT) Date: Wed, 30 Apr 97 14:49:43 GMT From: "William Allen Simpson" Message-ID: <5769.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: PMTU/DF issues Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Karen Seo > a) send the PMTU information to all 3 hosts. As you > observed, H1 and H2 aren't the intended recipients > for the PMTU information and won't know what to do > with it. This would be the wrong thing to do. Be conservative in what you send. > b) hold the PMTU information until another too-big > packet arrives and then use that packet and the PMTU > information to construct a ICMP PMTU for the > originating host (H0). > This is what is described in RFC-1853: The router uses the ICMP messages it receives from the interior of a tunnel to update the soft state information for that tunnel. When subsequent datagrams arrive that would transit the tunnel, the router checks the soft state for the tunnel. If the datagram would violate the state of the tunnel (such as the MTU is greater than the tunnel MTU when Don't Fragment is set), the router sends an appropriate ICMP error message back to the originator, but also forwards the datagram into the tunnel. Forwarding the datagram despite returning the error message ensures that changes in tunnel state will be learned. Rather than putting all of this into the Architecture document, I'd think it would be more efficacious to update RFC-1853. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-ipsec Wed Apr 30 10:58:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA27367 for ipsec-outgoing; Wed, 30 Apr 1997 10:57:01 -0400 (EDT) Date: Wed, 30 Apr 1997 10:55:19 -0400 (EDT) From: Dave Mason Message-Id: <199704301455.KAA01980@darkstar.rv.tis.com> To: ipsec@tis.com, mjs@terisa.com, mss@tycho.ncsc.mil, sjt@epoch.ncsc.mil, wdmaugh@tycho.ncsc.mil Subject: isakmp-07.txt Cc: dmason@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Just nitpicking, but the paragraph on page 20 of draft-ietf-ipsec-isakmp-07.txt: >For uniformity, all SPIs are 8 octets long. When negotiating security >associations for security protocols that use 4-octet SPIs, the first four >octets will be used, and the last four will be zero. isn't in sync with section 3.5 which allows for variable length SPIs. Also note that the proposal payloads in the examples given in Section 4.1.1, use fixed (8 octets) sized SPI fields and do not include the SPI size field as specified in Section 3.5. -dave (dmason@tis.com) From owner-ipsec Wed Apr 30 11:24:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA27605 for ipsec-outgoing; Wed, 30 Apr 1997 11:23:37 -0400 (EDT) Message-ID: From: Roy Pereira To: "'baldwin@rsa.com'" , "'dennis.glatting@plaintalk.bellevue.wa.us'" Cc: "'ipsec@tis.com'" Subject: RE: Questions/comments re draft-ietf-ipsec-esp-rc5-cbc-00.txt Date: Wed, 30 Apr 1997 11:29:06 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk >I have some questions and comments regarding >draft-ietf-ipsec-esp-rc5-cbc-00.txt. > >The first question I have is why 40 bits? I am under the >impression the IPsec wg, for political reasons, chose to >exclude export weakened cipher usage. What this drafts states is that the key size may be as small as 40 bits. It is more of a flexibility issue than an export one. Policy will be able to reject any proposal that requests a smaller key size than it allows. >I'm a bit confused about the following paragraph from the >document. > >> 2.3 Payload >> >> RC5-CBC requires an explicit Initialization Vector (IV) of 8 octets >> (64 bits) that immediately precedes the cipher-text in the payload. >> A new IV must be pseudo-randomly generated for each packet and then >> used to encrypt that plain-text. When decrypting, the first 8 >> octets of the payload are used as a IV to decrypt the remaining >> payload octets. >> > >Those statements are really confusing. They say the IV >precedes the cipher-text but then say first 8 octets of the >payload (the SPI and sequence number?) are used to decrypt the >rest. As Scoobe Doo says, Er? The CBC method seems a bit weird to >me too. Is the IV XORed with each block? This draft relates to the upcoming ESP draft (draft-ietf-ipsec-new-esp-01). In that draft, the explicit IV has been taken out of the ESP 'template' and must be documented in the individual ESP algorithm drafts. Thus ESP starts off like: SPI (32 bits) Sequence Number (32 bits) Payload (variable) ...... So within the Payload we start off with a 64 bit IV followed by the cipher text. That explicit IV is then used to decrypt the cipher text. > >Regarding key material, why is the key material derived as >stated in section 4 rather than slice and dice? Section 4 does talk about 'slicing and dicing'. This is inline with what was discussed and agreed upon in Memphis. The specific algorithm would dictate how many bits of keying material it would require, so that ISAKMP (or any other higher layer) can provide it. Then the algorithm simply slices the key material into sections (x bits for the cipher key, y bits for the authentication key). > From owner-ipsec Wed Apr 30 11:47:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA27837 for ipsec-outgoing; Wed, 30 Apr 1997 11:46:40 -0400 (EDT) Message-Id: <199704301552.IAA09982@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Dennis Glatting Date: Wed, 30 Apr 97 08:52:52 -0700 To: Roy Pereira Subject: Re: Questions/comments re draft-ietf-ipsec-esp-rc5-cbc-00.txt cc: "'baldwin@rsa.com'" , "'ipsec@tis.com'" Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: Sender: owner-ipsec@ex.tis.com Precedence: bulk From: Roy Pereira Date: Wed, 30 Apr 1997 11:29:06 -0400 > >Regarding key material, why is the key material derived as > >stated in section 4 rather than slice and dice? > > Section 4 does talk about 'slicing and dicing'. This is inline > with what was discussed and agreed upon in Memphis. The > specific algorithm would dictate how many bits of keying > material it would require, so that ISAKMP (or any other higher > layer) can provide it. Then the algorithm simply slices the key > material into sections (x bits for the cipher key, y bits for the > authentication key). > I was unclear. I was referring to the Horowitz draft. I went back and reread previous wg e-mail. I read the developers decided the key management daemon will generate "enough" key material and the AH/ESP algorithms will slice it; however, it isn't clear to me how the key management daemon will generate it. I must reread the other drafts. -dpg From owner-ipsec Wed Apr 30 12:52:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA28272 for ipsec-outgoing; Wed, 30 Apr 1997 12:51:21 -0400 (EDT) Message-ID: <33677AEA.F7D23E48@newoak.com> Date: Wed, 30 Apr 1997 13:01:30 -0400 From: smamros@newoak.com (Shawn Mamros) X-Mailer: Mozilla 4.0b3 [en] (WinNT; I) MIME-Version: 1.0 To: ipsec@tis.com CC: smamros@newoak.com Subject: ISAKMP/Oakley pre-shared key issue X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk (I wish I had realized this one earlier...) A while back, we discussed the fact that the latest (-03) version of the ISAKMP/Oakley resolution draft now requires that one use Oakley Aggressive Mode whenever using pre-shared keys, if one plans on using IDs that aren't IP addresses. If I remember right, an idea was proposed to add a new ID type to the DOI draft which would allow an opaque ID to be used to find the proper key. This is all fine and good. However, this opens up something else that I hadn't realized until just now. In Aggressive Mode, HASH_R is transmitted in the clear. That isn't a problem by itself, but what is a problem is that the only "secret" used to derive HASH_R in the -03 draft is the pre-shared key itself (as part of SKEYID). Everything else is something that is transmitted in the clear between the two parties. This means that one can open up the whole exchange by doing a brute-force key search; moreover, one can then impersonate either party, assuming the key isn't changed. The previous version of the ISAKMP/Oakley resolution draft (-02) was not as vulnerable, because the Diffie-Hellman shared secret (g^xy) was also used to help derive HASH_R. (Of course, that version was vulnerable to the man-in-the-middle D-H attack that was discussed here just a short while ago; that was fixed by using the D-H public values in the hash calculations in the -03 draft. But g^xy is now left out, at least when using pre-shared keys.) It seems to me that this situation can be handled by adding g^xy to the derivation of SKEYID when using pre-shared keys, as follows: SKEYID = prf(pre-shared key, Ni | Nr | g^xy) Since signatures (and now public-key encryption, according to the notes from Memphis that were sent recently) both use g^xy to derive SKEYID, I would hope that this would not be too great of a change for the draft authors. And I can't see that this would weaken anything, if the other authentication methods use it, but I'm not a "real" cryptographer. Do the real cryptographers here believe that this change would be a good idea? -Shawn Mamros E-mail to: smamros@newoak.com From owner-ipsec Wed Apr 30 21:41:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA01608 for ipsec-outgoing; Wed, 30 Apr 1997 21:39:47 -0400 (EDT) Message-Id: <199705010140.VAA18887@relay.hq.tis.com> Date: Wed, 30 Apr 97 21:44:47 EDT From: Karen Seo To: wsimpson@greendragon.com cc: ipsec@tis.com Subject: Re: PMTU/DF issues Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, > b) hold the PMTU information until another too-big > packet arrives and then use that packet and the PMTU > information to construct a ICMP PMTU for the > originating host (H0). > >>This is what is described in RFC-1853: >> >> The router uses the ICMP messages it receives from the interior of a >> tunnel to update the soft state information for that tunnel. When >> subsequent datagrams arrive that would transit the tunnel, the router >> checks the soft state for the tunnel. If the datagram would violate >> the state of the tunnel (such as the MTU is greater than the tunnel >> MTU when Don't Fragment is set), the router sends an appropriate ICMP >> error message back to the originator, but also forwards the datagram >> into the tunnel. Forwarding the datagram despite returning the error >> message ensures that changes in tunnel state will be learned. >> >>Rather than putting all of this into the Architecture document, I'd >>think it would be more efficacious to update RFC-1853. Assuming that by "this" you mean the entire PMTU/DF discussion and appendix (as opposed to just the section you copied in your email).... Certainly referencing RFC-1853 seems appropriate. However, since PMTU/DF is only one of several IPSEC issues that are relevant to IPSEC tunneling and this decision, we'd like to discuss the other issues before deciding where to document them. For example, RFC-1853 addresses only IPv4 and we plan to discuss IPv4 and IPv6 tunneling. Thank you, Karen