From owner-ipsec Fri Aug 1 01:55:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA28528 for ipsec-outgoing; Fri, 1 Aug 1997 01:52:44 -0400 (EDT) Date: Fri, 1 Aug 1997 02:01:10 -0400 Message-Id: <199708010601.CAA18158@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: Calling the question: implicit vs. explicit IV Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Bob and I would like to call the question regarding implicit vs. explicit IV's. Given the tenor of the discussion on the list, we believe that we have rough consensus on using explicit IV's in the encryption algorithms used by ESP. However, I'd like to formally ask the working group to either agree or disagree with "the sense of the chairs". To review the issues at hand: Simpson has perhaps been the strongest proponent of using implicit IV's. His arguments in favor of doing this include * reducing the overhead of ESP by 8 bytes * avoiding a "covert channel" (because keying information could be leaked deliberately --- either with the knowledge of the user in the case of the "Clipper Chip", or without the knowledge of the user if you believe that the U.S. government could suborn U.S. manufacturers to leak keying information in the IV field; paranoia reigns....) * maintaining (partial) compatibility with RFC-1827, 1828, and 1829, because a the new ESP with a sequence number looks similar to RFC-1827 with a 32-bit IV. However, there have also been a number of people (Pereira, Adams, Simpson, Ts'o, Kent, Krawczyk) who have spoken in favor of an explicit IV. Ts'o has pointed out that the 8 byte overhead is lost in the noise compared to the other overheads involved (the ESP authenticator, the IP and TCP headers, etc.) A number of people (Kent, Ts'o, et. al) have pointed out that the compatibility is partial at best, the handling of the "sequence number", and whether wrapping is allowed or not changes; and RFC-1829 doesn't support the authenticator, and the compatibility hack assumes that you're not using RFC-1826-style 0-bit and 64-bit IV's. It's also the case that compared to the complexity of implementing ISAKMP/Oakley, and the rest of the IPSEC suite, the amount of effort to implement two variants (old/deprecated and new/recommended) of ESP, one which was RFC-1829 and the other implementing sequence numbers, explicit IV's, and authenticators, really isn't all that hard. The bulk of the code complexity is in the crypto algorithms anyway. Finally, Hugo Krawczyk pointed out that an implicit IV system was subject to a chosen plaintext attack which could be prevented by using an explicit IV. I am sure that there are other reasons that some could cite about how explicit might be better than implicit, or vice versa. However, I believe I have captured the most arguments on either side of the issue. Please send comments either in support or in opposition to the proposition which I advanced at the beginning of this e-mail note; namely, that we have rough consensus to use an explicit IV within the use of the encryption algorithsm with ESP. - Ted From owner-ipsec Fri Aug 1 06:08:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA29662 for ipsec-outgoing; Fri, 1 Aug 1997 06:06:10 -0400 (EDT) Message-Id: <3.0.2.32.19970801054626.007ec940@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Fri, 01 Aug 1997 05:46:26 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: Re: Calling the question: implicit vs. explicit IV In-Reply-To: <199708010601.CAA18158@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I support explicit IV's. The only point I would add to Ted's summary is that there is evidence that in some situations it is beneficial if not necessary for the IV to be explicitly present in the packet due to hardware of other crypto tool requirements. At 02:01 AM 8/1/97 -0400, you wrote: > >Bob and I would like to call the question regarding implicit >vs. explicit IV's. -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQA/AwUBM+GwcYwpVk/gvJfqEQLKogCguNeigXGRw9IvN7seyMyNttI99EIAoJ7Z fEJZl/cVKv0FnUsQwBWHweFO =EFf1 -----END PGP SIGNATURE----- From owner-ipsec Fri Aug 1 06:08:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA29668 for ipsec-outgoing; Fri, 1 Aug 1997 06:06:40 -0400 (EDT) Message-Id: <3.0.2.32.19970801060002.007efd10@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Fri, 01 Aug 1997 06:00:02 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: comments on the new DOI Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Just a couple of things... there's no Transform ID for ARCFOUR, and is someone actively looking at Triple IDEA? Transform ID Value ------------ ----- RESERVED 0 ESP_DES_IV64 1 ESP_DES 2 ESP_3DES 3 ESP_RC5 4 ESP_IDEA 5 ESP_CAST 6 ESP_BLOWFISH 7 ESP_3IDEA 8 ESP_DES_IV32 9 From owner-ipsec Fri Aug 1 08:29:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA00619 for ipsec-outgoing; Fri, 1 Aug 1997 08:25:47 -0400 (EDT) From: owner-ipsec@ex.tis.com Message-Id: <3.0.32.19970731193945.00767a08@mail.verisign.com> X-Sender: mmyers@mail.verisign.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 31 Jul 1997 19:39:46 -0600 To: ietf-pkix@tandem.com Subject: PKCS 7 + PKCS 10 Proposal Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by caladan.verisign.com id TAA26526 Sender: owner-ipsec@ex.tis.com Precedence: bulk All-- Back in San Jose and again in Memphis the PKIX WG expressed interest in considering the use of PKCS 7 and PKCS 10 for PKI administrative messaging. The draft below follows up on this topic from Memphis. The question naturally emerges: How does this relate to PKIX Part 3, considering that PKIX Part 3 accepted changes at the last IETF which accomodate PKCS 7 and PKCS 10? Carlisle and I today discussed the issues surrounding this question, in the context of the draft below. We concluded it proposes a reasonable approach towards leveraging the installed base of PKCS 7 capabilities.=20 To that end, I propose we consider this framework in Munich and determine if and how it should move forward. The authors also feel that this work merits attention within the IPSEC Working Group, hence it cross-posting to that list. Carlisle had the following specific observations: 1. The draft continues to promote the notion that one need only have a single key. 2. It provides no means to certify a D-H key. Recognizing that the WG has received a proposal to do so using PKCS 10 constructs, there still remains a problem of coordinating parameters between the client and the CA. 3. It does not adequately address the subscriber bootstrapping=20 problem. 4. More generally, the current draft clearly falls short of addressing the entire set of capabilities provided by Part 3. For each of these there exists a reasonable counter position. It's tempting to rebut each, but in the interest of brevity I will address only the last point, leaving the others to the list and Munich. To the last point, I would observe that the draft is intended to address only the most essential elements of a PKI service, with the thought in mind that additional work would be needed to expand upon these basic services. Lastly, I apologize to the members of both lists for missing the deadline and dumping this directly onto the lists. (Carlisle, if I've misrepresented your position, I'm sure you'll have no reservation whatsoever in correcting the public record!) --Mike Michael Myers VeriSign, Inc. mmyers@verisign.com (415) 429-3402 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^^^^^^^ PKIX Working Group Michael Myers (VeriSign) Internet Draft Alex Deacon (VeriSign) Xiaoyi Liu (Cisco) Internet Public Key Infrastructure 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time.=20 It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munari.oz.au Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 2. Abstract Part 3 of the Internet Public Key Infrastructure (PKIX Part 3) series of draft PKI standards defines an application-level protocol for use=20 between PKI clients and PKI service providers. While Part 3 amply addresses a robust set of PKI requirements, a need exists to more fully leverage existing implementa-tion investment in the PKCS7 security protocol and PKCS10 certification request specification. PKCS10 fails however to address the full range of requirements addressed by PKIX Part 3. This draft combines PKIX Part 3 concepts and PKCS10 in the context of PKCS7 security encapsulation to propose an alternative Certificate Management Protocol (CMP). 3. Protocol Overview 3.1 Transaction-Based Services A CMP Transaction is composed of the exchange of two or more messages between a CMP Server and a CMP Client. This interaction is best illustrated by the Certification Request transaction. The most complex variation involves certification requests arriving at a Server when the Server is operated in a manner that requires manual authentication of the certification request. The following figure illustrates the interactions. In this illustration, the client produces a certification request and transmits it to a Server config-ured for manual authentication. The Server immediately returns a response message that indicates the certification request is pending manual authentication. When a PENDING message is received for a certificate request it sent, the client periodically polls for the availability of the certificate. During the interval while a Certificate Request is pending manual authentication, an individual at the CA hosting the server is involved in authenticating the identification information contained in the request. When the certificate is available, the Server responds with a SUCCESS response message that contains the Client=92s certificate. (The authors recognize that polling is sub-optimal for secure enclaves of even modest scale. Future revisions of this draft will address Client state management logic that enables more efficient utilization of bandwidth in large scale situations.) Client Server | | |----- Certification Request ---->| | | |<<------- PENDING Response -------| | | |------------- Poll ------------->| | | |<<------- PENDING Response -------| | | |------------- Poll ------------->| | | |<<------- PENDING Response -------| | | |------------- Poll ------------->| | | |<<------- SUCCESS Response -------| All other CMP currently defined transactions complete with a single request and response interchange. These include an immediate SUCCESS response when the Server is configured for automatic authentication, and transactions to retrieve certificates and CRLs. Section 8 of this draft identifies areas where further work can be expected. 3.2 Transaction Synchronization Each CMP transaction is identified and tracked using a transaction identifier. Clients generate transaction identifiers and retain their state until the server responds with a message that closes the transaction. When the Server receives a message from a client, the transaction identifier is also retained in the Server while the request is being processed. During the processing of the request, if it is necessary that the client and server exchange messages regarding the state of the transaction, the transaction identifier is included in these intermediate messages. When the Server completes processing of a request, the transaction identifier is included in the response message to the Client. If a Client receives a message for which it has no retained transac-tion identifier, the message is discarded. 3.3 Replay Prevention The CMP incorporates a Sender and Recipient nonce for the purpose of replay prevention. Nonce values are random numbers. The message that initiates a transaction contains only a Sender nonce. The recipient of an initial message retains the Sender nonce and uses it as the value of Recipient nonce in the next message back to the transaction originator. The original recipient in turn generates its own Sender nonce and includes this in the response message as the value for Sender nonce. Upon receipt of intermediate messages, the recipient compares the value of the message=92s Recipient nonce against a local store of Sender nonces generated by the Recipient. If a match is not found, the message is rejected. If a match is found, the recipient retains the value of Sender nonce in the message for inclusion as Recipient nonce in any intermediate messages back to the message originator. The recipient also generates a new value for its Sender nonce and includes it as the value of message Sender nonce. Continuing with the Certification Request transaction example above, the following figure illustrates CMP nonce state management. The column labeled "Msg" corresponds to a message in the prior illustration. The "Client Retains" and "Server Retains" columns are logically { (the nonce I most recently sent you), (the nonce I most recently received from you) }. =20 The "Client Sends" and "Server Sends" columns correspond to the {sender nonce, recipient nonce} values in the message. Finally, the sequential values in the table are for illustrative purposes only. Msg Client Client Server Server Retains Sends Sends Retains |-----------------------------------------------------| |Request | {1,-} {1,-} | |-----------------------------------------------------| |PENDING | {2,1} {2,1} | |-----------------------------------------------------| |Poll | {3,2} {3,2} | |-----------------------------------------------------| |PENDING | {4,3} {4,3} | |-----------------------------------------------------| |Poll | {5,4} {5,4} | |-----------------------------------------------------| |PENDING | {6,5} {6,5} | |-----------------------------------------------------| |Poll | {7,6} {7,6} | |-----------------------------------------------------| |SUCCESS | {8,7} {8,7} | |-----------------------------------------------------| 3.4 Transport Model This specification makes no assumptions about the underlying transport mechanism. The use of PKCS 7 specifically is not meant to imply an email-based transport. A prototype of this protocol currently in operation demonstrates that HTTP is well suited to the CMP transaction model. 3.5 Security Encapsulation A CMP message is composed of a message body and one or more Service Indica-tors. CMP Service Indicators are encoded as a set of authenticated attributes of a PKCS7 SignedData construction. CMP message bodies are first encrypted to become EnvelopedData and then included as the content of SignedData. The message digest of the encrypted message body is then signed together with the Service Indicators. By separating the encryption and signing transformations, message handling decisions based on the signed service indicators can be determined prior to invoking security procedures specific to the message body.=20 The following figure illustrates the essential characteristics of a CMP message. Many interior details and fields have been omitted for clarity.=20 Not all of the indicated fields are present in every CMP message type. |---------------------------------------| |SIGNED DATA | |---------------------------------------| | content | | Message Encryption Key (MEK) | encrypted under Recipient=92s public | encrypted CMP message body | encrypted under MEK |---------------------------------------| | ORIGINATOR=92S CERTIFICATE | |---------------------------------------| | AUTHENTICATED ATTRIBUTES | | Hash of Content | | message type | indicates msg body syntax | transaction identifier | | transaction status | | sender nonce | | recipient nonce | |---------------------------------------| | Message Signature |produced using originator=92s private |---------------------------------------|operating on hash of AUTH. ATTR. 3.6 Message Body A CMP message encapsulated by PKCS7 syntax is constructed as follows.=20 The contentInfo field of a signedData type is populated with the envelopedData content type. The encryptedContent of this envelopedData may contain one of the following CMP message bodies: - PKCSReq -- Request for a certificate - CertRep -- Response to a certificate request - GetCertInitial -- A means to poll for a pending certification - GetCert -- A means to query for others=92 certificates - GetCRL -- A means to query for a CA=92s CRL(s) A PKCSReq message consists of a PKCS10 certificate signing request. It is sent from the client to the CA. As currently specified, the request shall contain the subject name, the subject public key and a ChallengePassword attribute. It may contain an optional ExtensionReq attribute used to indicate to the CA one or more certificate extensions.=20 Additional extensions to PKCS10 content should be anticipated as this draft standard evolves. A CertRep message is the CA=92s response to a PKCSReq, GetCertInitial or GetCert GetCRL. It may contain a certificate but always contains one or more Service Indicators. A GetCertInitial message is used to poll a CA for a requested certificate in the circumstance when the PKIStatus of prior CertRep message indicates PENDING. Clients may use a GetCert or GetCRL message to access a CA=92s repository of certificates or CRL(s) respectively. 3.7 Service Indicators Service indicators are included with a message body to form a complete CMP message. The SignerInfos portion of the signedData content type conveys additional information needed to complete the protocol. The authenticatedAt-tributes element of the SignerInfos syntax is used to identify an enveloped-Data content type carrying one of the following CMP service indicators: - transactionId - messageType - pkiStatus - failinfo - senderNonce - recipientNonce Each service element is uniquely identified by an OID that signals the syntax following the OID. CMP processing systems would first detect the service element OID and process the corresponding service indicator value prior to processing the message body. The transactionId service indicator identifies a given transaction. It is used between client and server to manage the state of an operation. The messageType service indicator identifies the syntax carried in the message body. The PKIStatus service indicator is used to convey information relevant to a requested operation. The failInfo service indicator conveys information relevant to the interpreta-tion of a failure condition. The senderNonce and recipientNonce service indicator can be used to provide application-level replay prevention. 4. Protocol Elements 4.1 PKCS7 Encapsulation The following syntax specifies the general content of CMP messages.=20 Required values for certain fields are specified as comments to selected protocol elements. For the purposes of interoperability, CMP-compliant applications shall implement these required values for the indicated protocol elements. Applications may also implement additional values for these fields to accommodate other operational environments. PKIMessage ContentInfo ::=3D SEQUENCE { contentType OBJECT IDENTIFIER -- {pkcs-7 2}, SignedData content [0] } -- data to be signed The data to be signed into a PKCS7 encapsulated CMP message shall be struc-tured as follows. With the exception of the response to a GetCRL request message, the optional CRL component of a signedData content type shall not be included in a CMP message. SignedData ::=3D SEQUENCE { version INTEGER, digestAlgorithms AlgorithmIdentifier, contentInfo SEQUENCE { contentType OBJECT IDENTIFIER -- {pkcs-7 3}, EnvelopedData content [0] } OPTIONAL -- encrypted message body certificate [0] Certificate, -- signer=92s certified public key signerInfos SignerInfos } -- contains Service Indicators The SignerInfos portion of SignedData carries one or more CMP Service Indicators. SignerInfo shall be composed as follows: SignerInfo ::=3D SEQUENCE { version INTEGER, issuerAndSerialNumber SEQUENCE { issuer Name,=20 serialNumber INTEGER } digestAlgorithm AlgorithmIdentifier, authenticatedAttributes SET OF Attributes, digestEncryptionAlgorithm AlgorithmIdentifier, encryptedDigest OCTET STRING } The value of authenticatedAttributes is hashed using the algorithm specified by digestAlgorithm, signed using the originator=92s private key corresponding to digestEncryptionAlgorithm, the result encoded as an OCTET STRING and assigned to the encryptedDigest field. Since PKCS 7 requires the presence of a digest of the message content in AuthenticatedAttributes, message content is indirectly bound to the signature through the digest of AuthenticatedAttributes. Specification of the syntax and semantics of the CMP service indicators that can be included as AuthenticatedAttributes are presented in section 4.3. Some CMP messages do not carry a contentInfo block in SignedData. These messages are composed as SignedData consisting of version, digestAlgorithm, certificate(s) and SignerInfo. When a CMP message conveys additional content, this content is conveyed as an EnvelopedData content type within the Con-tentInfo block of SignedData and is structured as follows. EnvelopedData ::=3D SEQUENCE { version INTEGER, recipientInfos SET OF SEQUENCE { version INTEGER, issuerAndSerialNumber SEQUENCE { issuer Name,=20 serialNumber INTEGER } keyEncryptionAlgorithm AlgorithmIdentifier, encryptedKey OCTET STRING } encryptedContentInfo SEQUENCE { contentType ContentType, contentEncryptionAlgorithm AlgorithmIdentifier, encryptedContent [0] IMPLICIT OCTET STRING } 4.2 Object Identifier Base The OIDs for CMP objects stem from the PKIX arc. PKIX Part 1 establishes the following value as the base of the PKIX object identifier space: pkix OBJECT IDENTIFIER ::=3D { 1 3 6 1 5 5 7 } Objects associated with PKIX Certificate Management Protocol are established under the following identifer space: pkix-cmp OBJECT IDENTIFIER ::=3D { pkix X } --Get with Tim Polk on=20 this 4.3 Use of Authenticated Attributes CMP Service Indicators are encoded as AuthenticatedAttributes within Signed-Data. In accordance with PKCS7, when included in a PKCS7 message, Authenticat-edAttributes must consist of at a minimum: - A PKCS #9 content-type attribute having as its value the content type of the ContentInfo value being signed. - A PKCS #9 message-digest attribute, having as its value the message digest of the content. For the first, CMP chooses to use the PKCS9 attribute OID ContentInfo to signal additional content interpretation information. This is the first in the SET OF Attributes defining CMP=92s AuthenticatedAttributes.=20 Following the ContentInfo OID, CMP includes the mandatory message digest attribute. In addition to this required syntax, CMP currently defines six authenticated attributes: Service Indicator OID Syntax ----------------- ------------- --------------- TransactionId pkix-cmp 1 PrintableString messageType pkix-cmp 2 PrintableString pkiStatus pkix-cmp 3 PrintableString failinfo pkix-cmp 4 PrintableString senderNonce pkix-cmp 5 OCTET STRING recipientNonce pkix-cmp 6 OCTET STRING The TransactionID, messageType, pkiStatus and failInfo service indicators are decimal values expressed as a string. The TransactionID Service Indicator uniquely identifies a transaction; it is used to match responses to requests. To be effective, its value must be unique within any reasonably chosen context. In the certificate enrollment transac-tion, this requirement may be met by producing a Certification Request transactionID using a hash on the end entity public key value. CMP Servers SHALL NOT rely upon NOR enforce this behavior. This attribute is required in all PKI messages. The messageType service indicator specifies the type of operation performed by the transaction. This attribute is required in all PKI message. The following message types defined: PKCSReq (19) -- Permits use of PKCS#10 certificate request CertRep (3) -- Response to certificate request=20 GetCertInitial (20) -- Certificate polling in manual enrollment GetCert (21) -- Retrieve a certificate GetCRL (22) -- Retrieve a CRL All response messages will include transaction status information which is defined as pkiStatus service indicator: SUCCESS (0) -- request successful FAILURE (2) -- request rejected PENDING (3) -- request pending This PKIStatus service indicator is required for all PKI messages. =20 If the status in the response is FAILURE, then the failinfo service indicator will contain one of the following failure reasons: BADALG (0) -- Unrecognized or unsupported algorithm ident BADMESSAGECHECK (1) -- integrity check failed BADREQUEST (2) -- transaction not permitted or supported BADTIME (3) -- Message time field was not sufficiently close -- to the system time BADCERTID (4) -- No certificate could be identified matching the -- provided criteria The attributes of senderNonce and recipientNonce are random numbers generated per transaction to prevent replay attack. This attribute is required for all PKI messages. In the first message of a transaction, no recipientNonce is transmitted; a senderNonce is instantiated by the message originator and retained for later reference. The recipient of a senderNonce reflects this value back to the originator as a recipientNonce and includes it=92s own senderNonce= .=20 Upon reciept by the transaction originator of this message, the originator compares the value of recipientNonce to its retained value.=20 If the values match, the message can be accepted for further security processing. The received value for senderNonce is also retained for inclusion in the next message associated with the same transaction. 4.4 Messages 4.4.1 PKCSReq Message Format Clients shall produce a PKCS10 message body containing an unambiguous identity and public key. The exact structure of this identity and the means by which it is determined is a matter of operational policy. PKCSReq CertificationRequest ::=3D SEQUENCE { certificationRequestInfo SEQUENCE { version INTEGER, subject Name, subjectPublicKeyInfo SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } attributes [0] IMPLICIT SET OF Attribute } signatureAlgorithm AlgorithmIdentifier,=20 signature BIT STRING } The client may incorporate one or more standard X.509 v3 extensions in the request as PKCS 9 attributes. This information shall be expressed in the Attributes field of a PKCSReq as a iteration of individual objects of the form EXTENSION as defined in X.509. CMP-compliant CAs are not required to be able to process every v3 X.509 extension transmitted, nor are they required to be able to process other, private extensions. However, in the circumstance when a CA denies the certification request due to the inability to handle a requested extension, the CA shall respond with a error that unambiguously identifies the error condition. Service Indicator OID Value ----------------- -------------------------- ----------------- contentType pkcs-9 3 messageDigest pkcs-9 4 =20 transaction-id pkix-cmp 1 messageType pkix-cmp 2 PKCSREQ senderNonce pkix-cmp 5 4.4.2 CertRep Clients receive CertRep messages in response to a prior PKCSReq message.=20 The response may be one of: --PENDING --SUCCESS --FAILURE The general structure of a CertRep message is as follows. An "inner" SignedData content type is encrypted and then encapsulated as EnvelopedData. This encapsulation becomes the contentInfo of an "outer" SignedData content type which is signed by the message originator. This final encapsulation is then passed on to the intended message=20 recipient. The figure below schematically illustrates the essential data structure relationships. Specific content will vary by context. Some fields omitted for clarity. |---------------------------------------| |SIGNED DATA | |---------------------------------------| | ENVELOPED DATA | | MEK | - encrypted under Client=92s public | encrypted content: | - encrypted under MEK | SIGNED DATA | - content varies |---------------------------------------| | ORIGINATOR=92S CERTIFICATE | |---------------------------------------| | AUTHENTICATED ATTRIBUTES | | Hash of Content | | message type |=20 | transaction identifier | | transaction status | | failure info | | sender nonce | | recipient nonce | |---------------------------------------| | MESSAGE SIGNATURE | - produced using CA=92s private key | | operating on hash of AUTH. ATTR. |---------------------------------------| 4.4.2.1 PENDING When the CA decides to manually authenticate the end entity, the CA returns CertRep with pkiStatus set to PENDING and proceeds to perform the required authentication. The PENDING CertRep message is a SignedData content type with no ContentInfo block. The SignerInfo block contains the following Authenticated Attributes as indicated: |---------------------------------------| |SIGNED DATA | |---------------------------------------| |---------------------------------------| | ORIGINATOR=92S CERTIFICATE | |---------------------------------------| | AUTHENTICATED ATTRIBUTES | | Hash of Content | | message type | - CERTREP | transaction identifier | - from prior request | transaction status | - PENDING | sender nonce | - prior client nonce | recipient nonce | - current server nonce |---------------------------------------| | Message Signature | - produced using CA=92s private key | | operating on hash of AUTH. ATTR. |---------------------------------------| 4.4.2.2 FAILURE CAs transmit a CertRep messages with a PKIStatus of FAILURE if the certifica-tion request or its subsequent processing fails to meet the requirements of the CA=92s practices. The message is a SignedData content type with no ContentInfo block. The SignerInfo block contains the following Authenticated Attributes as indicated: |---------------------------------------| |SIGNED DATA | |---------------------------------------| |---------------------------------------| | ORIGINATOR=92S CERTIFICATE | |---------------------------------------| | AUTHENTICATED ATTRIBUTES | | Hash of Content | | message type | - CERTREP | transaction identifier | - from prior request | transaction status | - FAILURE | failInfo | - reason code | sender nonce | - prior client nonce | recipient nonce | - current server nonce |---------------------------------------| | Message Signature | - produced using CA=92s private key | | operating on hash of AUTH. ATTR. |---------------------------------------| Failure reason codes are specified in Section 4.2. 4.4.2.3 SUCCESS response=20 When used to deliver a certificate, the Client=92s certificate shall be conveyed to the Client in the SignerInfo portion of a degenerate SignedData content type. This is encapsulated by an EnvelopedData content type which is in turn encapsulated by an outer SignedData. The outer SignedData is signed by the originator of the CertRep message. Schematically, the relationship among these elements is as follows (some interior details omitted for clarity): |---------------------------------------| |SIGNED DATA | |---------------------------------------| | ENVELOPED DATA | | MEK | - encrypted under Client=92s public | encrypted content: | - encrypted under MEK | SIGNED DATA | - degenerate, no content | Client=92s certificate | - includes client cert in SignerInfo |---------------------------------------| | ORIGINATOR=92S CERTIFICATE | |---------------------------------------| | AUTHENTICATED ATTRIBUTES | | Hash of Content | | message type | - CERTREP | transaction identifier | - from prior request | transaction status | - SUCCESS | sender nonce | - prior client nonce | recipient nonce | - current server nonce |---------------------------------------| | Message Signature | - produced using CA=92s private key | | operating on hash of AUTH. ATTR. |---------------------------------------| 4.4.3 GetCertInitial The GetCertInitial message is used to poll for the certificate associated with prior request if the response to that prior request was a CertRep message with a status of PENDING. Certificates are normally referenced using the CA DN and the certificate serial number. In this case however a certificate has not yet been issued. Thus the CA and Subject DNs are present in the message as a means to identify the requested certification. The following syntax shall be included as the message body: IssuerAndSubject ::=3D SEQUENCE { issuer Name, subject Name } |---------------------------------------| |SIGNED DATA | |---------------------------------------| | ENVELOPED DATA | | MEK | - encrypted under CA=92s public | encrypted content: | - encrypted under MEK | SIGNED DATA | - degenerate, no content |---------------------------------------| | ORIGINATOR=92S CERTIFICATE | |---------------------------------------| | AUTHENTICATED ATTRIBUTES | | Hash of Content | | message type | - GETCERTINITIAL | transaction identifier | - from previous request | sender nonce | - new | recipient nonce | - current server nonce |---------------------------------------| | Message Signature | - produced using Client=92s pvt key | | operating on hash of AUTH. ATTR. |---------------------------------------| 4.4.4 GetCRL This operation is used to retrieve CRLs from a CA=92s repository. It comple-ments PKIX Part 2 in that this function as specified is an integral component of CMP and thus forms a standalone solution to essential Certificate Management services. It assumes the target CA maintains one and only one CRL relative to a given private signing key. In order to provide Client a convenient means of determining the network address needed to acquire a CA=92s CRL, PKIX-compliant CMP Servers and Clients should be capable of producing and processing, respectively, the CRLDistributionPoints certificate extension. The CRLDistributionPoint shall contain a URL that Clients reference when directing a query for the CRL of a given certificate=92s Issuer. Alternatively, the Client may be pre-configured with the CMP Server=92s URL. |---------------------------------------| |SIGNED DATA | |---------------------------------------| | DATA | | GetCRL message body | |---------------------------------------| | ORIGINATOR=92S CERTIFICATE | |---------------------------------------| | AUTHENTICATED ATTRIBUTES | - See Appendix A for OIDs. | Hash of Content | - binds requestor to request | message type | - GETCRL | transaction identifier | - new transaction | sender nonce | - new sender nonce |---------------------------------------| | Message Signature | - produced using Client=92s pvt key | | operating on hash of AUTH. ATTR. |---------------------------------------| The GetCRL message body shall consist of the following syntax: GetCRL ::=3D SEQUENCE { issuerName Name, time GeneralizedTime } 4.4.5 GetCert When CMP Clients have no external configuration function to provide them the network address of a CA=92s Repository, CMP Clients may attempt the value for CRLDistributionPoints as the value for a CA=92s Repository generally. CMP Servers should be configured to provide this=20 capability. |---------------------------------------| |SIGNED DATA | |---------------------------------------| | DATA | | GetCert message body | |---------------------------------------| | ORIGINATOR=92S CERTIFICATE | |---------------------------------------| | AUTHENTICATED ATTRIBUTES | - See Appendix A for OIDs. | Hash of Content | - binds requestor to request | message type | - GETCRL | transaction identifier | - new transaction | sender nonce | - new sender nonce |---------------------------------------| | Message Signature | - produced using Client=92s pvt key | | operating on hash of AUTH. ATTR. |---------------------------------------| The GetCert message body shall consist of the following syntax: GetCert ::=3D SEQUENCE { issuerName Name, serialNumber INTEGER } 5. PKI Transactions 5.1 Client Requests Certification of a Public Key To obtain a certificate, a client creates a PKCS10 certificate signing request (CSR) and signs it using the private key corresponding to the public contained in the CSR. A content-encryption key is generated and the CSR encrypted under this key. The result is placed into the EncryptedContent portion of En-velopedData. The content encryption key is in turn encrypted under the public key of the recipient CA and included in the recipientInfo of envelopedData. The client next generates a transactionID and a 16-byte random number for senderNonce. The transactionID should be unique to guard against transaction replay. A good source of uniqueness is a hash of the public key contained in the CSR. Recipient CAs should make no assumptions about this structure of transactionId. PKCS7 requires that the signerInfo contain a issuerNameSerialNumber value; however for this transaction, the certificate has yet to be issued and therefore the serialNumber has not yet been assigned. Thus the issuerName and SerialNumber value in the signerInfo are set to NULL and zero, respectively.=20 Upon receipt of this message, the CA must first determine that the signature validates using the supplied public key, thereby proving possession of the private key. This check also provides integrity assurance. Given the nature of this particular message however, this check does not provide authentica-tion. Alternatively, for those who do not have the ability to alter the DER encoding of the PKCS7 message, (i.e. those using the toolkits such as TIPEM) the end entity may generate a self-signed certificate and use it to build the envelope PKCSReq message. In this self-signed certificate the subject DN and issuer DN should both be the DN which has been specified in the PKCS10 request. The serialNumber of this self-signed certificate should be zero. The client then constructs a SignedData object using the self-signed certifi-cate, with the transactionId, senderNonce and message digest as authenticated attributes. The attributes should be signed using the end entity=92s private key, completing the SignedData. If the operational relationship between the client and the CA requires manual identity confirmation, an operator must verify the end entity=92s request information in some out-of-band method before the request can be granted. Examples of this out-of band method may include calling someone on the phone to compare the hash values or via a pre-authenticated list of entities. In this manual case, the end entity will receive a CertRep message with status set to PENDING. If the end entity is not entitled to the key usage it requested (via ExtensionReq), the request should be rejected as part of the identity confirmation process. 5.1.1 Exception handling Errors can occur during the enrollment phase that cause requests to be placed in a partially fulfilled state from either the end entities or CA=92s perspec-tive. In such cases, the transactions must be "re-synchronized" according to the following rules: 5.1.1.1 End entity does not receive a response If a response to a PKCSReq is not received, the end entity should send GetCertInitial request to the server with the same transactionID as the original PKCSReq until a valid response is received or the number of retries has been exceeded. In the latter case, the transaction is marked as failed, and a new PKCSReq message will be sent to the CA with the same transaction ID as the previous (failed) PKCSReq. When the CA receives the new request, it will recognize that the new transaction has a pending equivalent and will "cancel" the previous transaction. 5.1.1.2 User cannot open enveloped message: Because the response is encrypted with the user=92s public key, this erro= r would only occur if the message or private key is corrupt. This should be treated as a protocol error and the user should request that the certificate be revoked through the manual revocation process. 5.1.1.3 User cannot verify CA signature: It may be issued from the CA=92s perspective, but was never successfully delivered to the user. The user should request that the certificate be revoked through the manual revocation process. 5.1.1.4 Other abnormal errors These are protocol errors where the user does not receive a response from the CA to complete the transaction. In general, the user should retry until it exceeds the retry limit, then "re-synchronize" by starting a new transaction with the same transactionID. When the CA sees this duplicate transaction, it should re-synchronize by canceling all equivalent pending transactions. A transaction is considered to be "equivalent" if it is the same message type from the same entity, and has the same transaction=20 ID. 5.2 End entity polls for its initial certificate If the status in the CertRep is PENDING, the end entity creates and transmits a GetCertInitial message. The encryptedContentInfo of this message contains the IssuerAndSubject data structure that refers to the end entity. The end entity repeats this request until the CertRep it receives has a status of SUCCESS or FAILURE. If the CA receives multiple GetCertInitial request from an end entity with the same transactionID it will simple process the request as normal. 5.3 Revocation=20 To revoke a certificate, the client communicates to the operator of the CA Management System. That is, a user will communicate the revocation to the CA operator, who will ask for the challenge phrase included in the original certification request to confirm the identity of the user.=20 Additional confirmation steps may be necessary to ensure that the revocation request is genuine and is the clear intent of the client to whom the certificate was issued. 6. Security Considerations 7. Author=92s Addresses Michael Myers VeriSign, Inc. Xiaoyi Liu Cisco Systems From owner-ipsec Fri Aug 1 10:33:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01372 for ipsec-outgoing; Fri, 1 Aug 1997 10:29:17 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199708010601.CAA18158@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 Aug 1997 10:34:42 -0400 To: ipsec@tis.com From: Stephen Kent Subject: Re: Calling the question: implicit vs. explicit IV Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted, I support use of an explicit IV with DES-CBC as the default encryption algorithm. Steve From owner-ipsec Fri Aug 1 11:51:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA01823 for ipsec-outgoing; Fri, 1 Aug 1997 11:49:16 -0400 (EDT) Message-Id: <199708011557.IAA29312@pita.cisco.com> To: "Theodore Y. Ts'o" cc: ipsec@tis.com Subject: Re: Calling the question: implicit vs. explicit IV In-reply-to: Your message of "Fri, 01 Aug 1997 02:01:10 EDT." <199708010601.CAA18158@dcl.MIT.EDU> Date: Fri, 01 Aug 1997 08:57:27 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk I would like to see only an explicit IV used for ESP. Derrell Piper cisco Systems From owner-ipsec Fri Aug 1 12:23:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA02098 for ipsec-outgoing; Fri, 1 Aug 1997 12:22:15 -0400 (EDT) Date: Fri, 1 Aug 97 14:32:52 GMT From: "William Allen Simpson" Message-ID: <6390.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Calling the question: derived vs. explicit IV Sender: owner-ipsec@ex.tis.com Precedence: bulk There were several inaccuracies in the summary, including the Subject (above). Rather than arguing about them, since most of them are attributed to me, I'll just repost them correctly. In favor of Derived: 1) Saves 8 bytes for every datagram. 2) Maintains complete backward compatibility with RFCs 1829 and 1851. All shipping implementations already support the derived IV. 3) Will reduce administrative and operational confusion. A change to explicit IV would "obsolete" thousands of fielded units, and create a user support nightmare. 4) Interoperable code will be more rapidly deployed. 5) Any change to explicit must show GREATER cryptographic strength. Derived has been show to give somewhat stronger protection of the first block than explicit. Estimates are from 2**7 to 2**16 depending on environment. 6) May avoid a "covert channel". This is mostly of interest to cryptographers trying to "prove" the security of a protocol. (This was actually mentioned by someone else on another list.) Using an explicit IV, keying information could be leaked deliberately -- either with the knowledge of the user in the case of the "Clipper Chip", or without the knowledge of the user if you believe that the U.S. government could suborn U.S. manufacturers to leak keying information in the IV field; paranoia reigns.... 7) Will allow us to move forward from Proposed to Draft Standard. ==== In favor of Explicit: 8) Having a separate field is less "complex" than deriving the field. 9) Some unknown hardware might require an explicit IV. ==== Arguments: #1 Some argue that in some future Internet where most datagrams are large and bandwidth is not an issue, 8 bytes is not much overhead. But, this is not true of the current Internet. The vast majority of datagrams are 40 bytes. The average size is 113 bytes. The median size is smaller. Also, since adding an Authenticator to ESP is not more secure than using AH, the only argument in favor of the Authenticator field is that it saves 8 bytes. If 8 bytes isn't a compelling argument, then the Authenticator field must be abandoned as well. #2 Some argue that backward compatibility is not an issue. RFCs 1829 and 1851 do not support an Authenticator. True, but the Authenticator is optional. AH is still used for the same function in those implementations. Support for AH is mandatory. RFCs 1829 and 1851 also have an explicit IV. True, but that explicit IV is _not_ compatible with the proposed explicit IV. Removing unused features is common when going from Proposed to Draft. RFCs 1829 and 1851 do not require the counter value to start at 1. True, but neither RFCs 1829 and 1851 nor the explicit drafts require anti-replay for manually configured implementations. No problem. #3 (no disagreement on list) #4 compared to the complexity of implementing ISAKMP/Oakley, and the rest of the IPSEC suite, the amount of effort to implement two variants (old/deprecated and new/recommended) of ESP, one which was RFC-1829 and the other implementing sequence numbers, explicit IV's, and authenticators, really isn't all that hard. The bulk of the code complexity is in the crypto algorithms anyway. True, but why add that complexity and extra interoperability testing? #5 Everyone agrees that there is an improvement in strength. Some do not agree than an improvement in strength that protects only the first block is worth extra effort. Others do not agree that such a small number of bits strength is "significant". The counter argument is that the first block is the weakest. Any improvement in strength is useful. And nobody has shown GREATER strength for explicit. #6 (no disagreement on list) #7 (no disagreement on list) Explicit will require the effort to cycle at Proposed Standard. #8 The differences in code have been posted to this list. The actual code difference is two lines: pullup(bpp,iv,4); ip->length -= 4; memcpy(iv+4,iv,4); memxor(iv+4,One_bits,4); versus: pullup(bpp,iv,8); ip->length -= 8; The complexity can be easily judged. #9 This raised its ugly head repeatedly over 4 years. No such hardware vendor has been found. It is very unlikely that such a vendor would appear in the future when they could not sell their wares for IPSec. #10 Hugo Krawczyk mentions a well-known chosen plaintext attack, where the first block is chosen. As far as I can tell, it does not apply to any IP Protocol header in existance, and is thus entirely theoretical and impractical. When this was raised many years ago, I proposed encrypting the SPI+SN in OFB mode, and using that as an IV. That would meet the pseudorandomly selected, protected from disclosure, and unpredictable criteria for "perfection" in cryptology nirvana. See Voydock and Kent (1983). Unfortunately, this WG said that was too slow and complex. Using the sequence number was a compromise. This theoretical attack cannot be prevented by using an explicit IV, especially when the IV is the ciphertext from the previous last block, as proposed by several on this list and as used in PPP. This attack was well-known and completely and competently rejected prior to publication of RFCs 1829 and 1851. #11 There is no technical rationale supporting a change to an explicit IV. ==== Given the tenor of discussion on the list, it is clear that DERIVED has the majority of proponents. Most folks just stated their preferences once. I counted recent messages from: Derived: 1) Me 2) "C. Harald Koch" 3) "ozan s. yigit" 4) Norman Shulman 5) "Angelos D. Keromytis" 6) Karl Fox Explicit: 1) Roy Pereira 2) Rodney Thayer 3) "Theodore Y. Ts'o" 4) Derrell Piper Fence-sitting: 1) mark@mentat.com (Marc Hasson) Fine, I really don't care which it is. 2) Steven Bellovin In other words, I don't care very much about explicit vs. implicit IVs for DES. I don't think it makes any difference at all. It may matter for other ciphers. 3) Stephen Kent ... The WG must decide on a default, MUST implement encryption algorithm and mode and that decision will weight space efficiency, confidentiality effectiveness, rekey frequency, and existing implementations in some fashion. This is a fairly complex set of factors to consider, so I don't assume it will be an easily objectifiable (did I really type that word?) decision. And since the overwhelming technical rationale is in favor of derived, I'd have to say anyone wanting explicit should make a very careful technical presentation. 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 Fri Aug 1 13:08:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA02435 for ipsec-outgoing; Fri, 1 Aug 1997 13:06:45 -0400 (EDT) Date: Fri, 1 Aug 1997 12:26:45 -0400 (EDT) Message-Id: <199708011626.MAA19255@carp.morningstar.com> From: Ben Rogers To: Derrell Piper Cc: "Theodore Y. Ts'o" , ipsec@tis.com Subject: Re: Calling the question: implicit vs. explicit IV In-Reply-To: <199708011557.IAA29312@pita.cisco.com> References: <199708010601.CAA18158@dcl.MIT.EDU> <199708011557.IAA29312@pita.cisco.com> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Derrell Piper writes: > I would like to see only an explicit IV used for ESP. Is there a consensus on whether we will mandate the contents of an explicit IV? If the contents are implementation dependent, then this doesn't seem to cause problems, but requiring them to be pseudo-random seems to needlessly add overhead for compliant implementations. ben From owner-ipsec Fri Aug 1 13:21:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA02528 for ipsec-outgoing; Fri, 1 Aug 1997 13:20:14 -0400 (EDT) Message-Id: <199708011720.NAA02528@portal.ex.tis.com> To: "William Allen Simpson" From: dharkins@bad.attitu.de Cc: ipsec@tis.com Subject: Re: Calling the question: derived vs. explicit IV In-Reply-To: Your message of "Fri, 01 Aug 1997 14:32:52 GMT." <6390.wsimpson@greendragon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 01 Aug 1997 10:26:27 -0700 Sender: owner-ipsec@ex.tis.com Precedence: bulk Add me to the list in favor of explicit IV. Dan. > Derived: > 1) Me > 2) "C. Harald Koch" > 3) "ozan s. yigit" > 4) Norman Shulman > 5) "Angelos D. Keromytis" > 6) Karl Fox > > Explicit: > 1) Roy Pereira > 2) Rodney Thayer > 3) "Theodore Y. Ts'o" > 4) Derrell Piper > > Fence-sitting: > 1) mark@mentat.com (Marc Hasson) > Fine, I really don't care which it is. > > 2) Steven Bellovin > In other words, I don't care very much about explicit vs. implicit IVs > for DES. I don't think it makes any difference at all. It may matter > for other ciphers. > > 3) Stephen Kent > ... The WG must decide on a > default, MUST implement encryption algorithm and mode and that decision > will weight space efficiency, confidentiality effectiveness, rekey > frequency, and existing implementations in some fashion. This is a fairly > complex set of factors to consider, so I don't assume it will be an easily > objectifiable (did I really type that word?) decision. From owner-ipsec Fri Aug 1 13:29:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA02606 for ipsec-outgoing; Fri, 1 Aug 1997 13:28:15 -0400 (EDT) Message-ID: From: Roy Pereira To: "'Derrell Piper'" , "'ben@Ascend.COM'" Cc: "'Theodore Y. Ts'o'" , "'ipsec@tis.com'" Subject: RE: Calling the question: implicit vs. explicit IV Date: Fri, 1 Aug 1997 13:45:54 -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 Agreed. How we derive the IV for each packet should be implementation dependant. Using pseudo-random values is quite expensive at the network level. I beleive that most of the new ESP algorithm drafts provide for this. >---------- >From: Ben Rogers[SMTP:ben@Ascend.COM] >Sent: Friday, August 01, 1997 12:26 PM >To: Derrell Piper >Cc: Theodore Y. Ts'o; ipsec@tis.com >Subject: Re: Calling the question: implicit vs. explicit IV > >Derrell Piper writes: >> I would like to see only an explicit IV used for ESP. > >Is there a consensus on whether we will mandate the contents of an >explicit IV? If the contents are implementation dependent, then this >doesn't seem to cause problems, but requiring them to be pseudo-random >seems to needlessly add overhead for compliant implementations. > > >ben > > > > From owner-ipsec Fri Aug 1 13:46:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA02747 for ipsec-outgoing; Fri, 1 Aug 1997 13:44:16 -0400 (EDT) Message-Id: <3.0.2.32.19970801134239.0083aa20@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Fri, 01 Aug 1997 13:42:39 -0400 To: ben@Ascend.COM (Ben Rogers) From: Rodney Thayer Subject: Re: Calling the question: implicit vs. explicit IV Cc: ipsec@tis.com In-Reply-To: <199708011626.MAA19255@carp.morningstar.com> References: <199708011557.IAA29312@pita.cisco.com> <199708010601.CAA18158@dcl.MIT.EDU> <199708011557.IAA29312@pita.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I believe there is a (cryptographic requirement) that the IV be somewhat random. I asked this on the list a while back, check the archive from about three weeks ago. At 12:26 PM 8/1/97 -0400, you wrote: >Derrell Piper writes: >> I would like to see only an explicit IV used for ESP. > >Is there a consensus on whether we will mandate the contents of an >explicit IV? If the contents are implementation dependent, then this >doesn't seem to cause problems, but requiring them to be pseudo-random >seems to needlessly add overhead for compliant implementations. > > >ben > > > > > From owner-ipsec Fri Aug 1 13:48:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA02765 for ipsec-outgoing; Fri, 1 Aug 1997 13:46:46 -0400 (EDT) Message-Id: <01BC9E82.C1081240@erussell-4.ftp.com> From: "Edward A. Russell" To: "'ipsec@tis.com'" Subject: RE: Calling the question: derived vs. explicit IV Date: Fri, 1 Aug 1997 13:56:46 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Add my vote for explicit IV to the list of vendors who have spent months testing interoperability with explicit IV and want a standard which stops moving. Edward Russell erussell@ftp.com From owner-ipsec Fri Aug 1 14:08:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA02894 for ipsec-outgoing; Fri, 1 Aug 1997 14:06:16 -0400 (EDT) Message-Id: To: ipsec@tis.com From: Bill Trost Subject: Mobile IP for FreeBSD from Portland State University MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <710.870458500.1@cloud.rain.com> Date: Fri, 01 Aug 1997 11:01:40 -0700 Sender: owner-ipsec@ex.tis.com Precedence: bulk Portland State University's newest release of Mobile IP for FreeBSD is now available. This release combines Mobile IP routing with IPSEC security. Mobile IP is a network protocol that allows hosts ("mobile nodes") to change their point of Internet connectivity without having to change their IP address. ftp://ftp.cs.pdx.edu/pub/mobile/mip-July97.tar.gz contains the release. It includes kernel sources based on FreeBSD 2.2.1 and PAO-970331, including ISA and PCMCIA WaveLAN drivers, source code for Mobile IP utilities and daemons, and binaries of all the user-level programs. Portions of the release are export controlled. They can only be downloaded by filling out a form at http://web.mit.edu/network/isakmp/isakmpform.html. New in this release: * IPSEC support within the Mobile IP daemons. All traffic between mobile nodes and their home agents may be encrypted, essentially creating a virtual private network. Foreign agents are not involved in the IPSEC security associations, but are tunneled over. In this release, encryption is supported only when the mobile node is at a foreign agent unless PSU's ad hoc mode; in that case, encryption may be used when the mobile node is at its home agent as well as at foreign agents. Also, foreign agents may require home agents to authenticate IPIP packets they send, preventing attackers from using foreign agents to circumvent a firewall. * Ported to FreeBSD 2.2.1. * Interoperability fixes from the interoperathon tests sponsored by FTP Inc. shortly before the Memphis IETF meeting. * Numerous bug fixes. Noteworthy properties of PSU's implementation in general: * Foreign agent switching based on WaveLAN signal strength (other link layer technologies are supported, but switching is less intelligent). * An optional replacement for ARP called "ad hoc" mode that eliminates ARP spoofing attacks. In this mode, logical networks are defined by a shared secret key, and every host regularly broadcasts its MAC->IP address binding. This mode also permit mobile nodes to communicate with each other directly, even if no foreign or home agents can be accessed. * Minimal kernel changes that provide basic, general-purpose mechanisms upon which Mobile IP daemons are implemented. * Foreign agents can have mobile security associations with both mobile nodes and home agents, as described in the RFC. * X-based user interface to monitor and control the mobile node. * Both multicast and broadcast agent advertisements. * ISA and PCMCIA WaveLAN drivers and applications to configure them. * NRL's IPSEC, ported to FreeBSD, with extensions to allow IPSEC security associations to be bound to routes. This allows virtual private networks to be created by simply configuring the routing table appropriately. From owner-ipsec Fri Aug 1 14:20:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA03031 for ipsec-outgoing; Fri, 1 Aug 1997 14:18:47 -0400 (EDT) Date: Fri, 1 Aug 1997 14:27:20 -0400 Message-Id: <199708011827.OAA18261@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "William Allen Simpson" Cc: ipsec@tis.com In-Reply-To: William Allen Simpson's message of Fri, 1 Aug 97 14:32:52 GMT, <6390.wsimpson@greendragon.com> Subject: Re: Calling the question: derived vs. explicit IV Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Fri, 1 Aug 97 14:32:52 GMT From: "William Allen Simpson" In favor of Derived: 2) Maintains complete backward compatibility with RFCs 1829 and 1851. All shipping implementations already support the derived IV. Not true. It is not _complete_ backwards compatibility. RFC 1829 support's no IV, 32-bit IV, and 64-bit IV. The compatibility you propose only works using RFC 1829-style 32-bit IV. In addition the handling of sequence number wrapping means that there is yet another compatibility issue. This can be solved having the ESP engine know something about whether the key management was manually done or not. However, that's an abstraction violation, and it certainly adds to the complexity of the implementation simply to have this "compatibility". 3) Will reduce administrative and operational confusion. A change to explicit IV would "obsolete" thousands of fielded units, and create a user support nightmare. No so. The fielded units do not support key management. The assumption which I'm making here is that manual keying will continue to use RFC 1829. The new units that support key management will support explicit IV's; if they choose to support manual keying for compatibility with said "thousands of fielded units" (and the market will decide whether or not that's necessary), they can simply support RFC 1829. It's not that much code to support both. 4) Interoperable code will be more rapidly deployed. The vendors who participated in the ANX interoperability demo were using explicit IV's. 5) Any change to explicit must show GREATER cryptographic strength. Derived has been show to give somewhat stronger protection of the first block than explicit. Estimates are from 2**7 to 2**16 depending on environment. Not true. We will be using an MAC to protect the packets against other attacks; this means that your posited attack of being able to modify the first block is simply not an issue. As far as Bill's counting of noses of who is for and who is against, there are a number of in his lists for which I haven't seen a clear statement on this position, and a number of people who have stated a position which he neglected to put on his lists. I am keeping track of messages sent both to the list and to me privately; however, I'd ask that folks send their preferences to the list, if at all possible. - Ted From owner-ipsec Fri Aug 1 14:23:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA03075 for ipsec-outgoing; Fri, 1 Aug 1997 14:22:15 -0400 (EDT) Message-ID: <01BC9E6C.C722BB50@Tastid.cisco.com> From: Rob Adams To: "ipsec@tis.com" Subject: RE: Calling the question: derived vs. explicit IV Date: Fri, 1 Aug 1997 11:19: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 Add me to the list of people supporting an explicit IV only. I agree with Mr. Rogers' comment that we shouldn't mandate what is in the IV. The two drafts I wrote, and I believe Roy's as well, suggest using the last block of the previous encryption pass. This is cheap and common. I only suggested that people use a pseudo-random value for the first pass... Ed said it best when he stated that he'd like to see ship what we've been testing for quite some time now. I do not believe we are "changing to" an explicit IV. I believe, if there is a change, it would be to derived IV. So I vote for sticking with explicit IV's. -Rob From owner-ipsec Fri Aug 1 14:32:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA03143 for ipsec-outgoing; Fri, 1 Aug 1997 14:31:16 -0400 (EDT) Message-Id: <199708011839.LAA15313@relay.hp.com> To: ipsec@tis.com Subject: Re: calling the question: derived vs. explicit Date: Fri, 01 Aug 1997 14:39:35 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk Chalk me up for preferring explicit IV.. From owner-ipsec Fri Aug 1 14:34:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA03174 for ipsec-outgoing; Fri, 1 Aug 1997 14:32:48 -0400 (EDT) From: Uri Blumenthal Message-Id: <9708011841.AA51302@v9n4fi0.watson.ibm.com> Subject: Re: Calling the question: derived vs. explicit IV To: ipsec@tis.com Date: Fri, 1 Aug 1997 14:41:06 -0400 (EDT) In-Reply-To: <199708011827.OAA18261@dcl.MIT.EDU> from "Theodore Y. Ts'o" at Aug 1, 97 02:27:20 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 Theodore Y. Ts'o says: > ................I am keeping track of > messages sent both to the list and to me privately; however, I'd ask > that folks send their preferences to the list, if at all possible. I'm for explicit IV. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec Fri Aug 1 14:37:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA03203 for ipsec-outgoing; Fri, 1 Aug 1997 14:35:46 -0400 (EDT) Message-ID: From: Roy Pereira To: "'IPSEC Mailing List'" Subject: FW: Calling the question: implicit vs. explicit IV Date: Fri, 1 Aug 1997 14:56:20 -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 vote for Explicit IV. > >The reasons? > >o I want one method for retrieving the IV from a packet no matter what >algorithm I'm using. Without a general method for CBC-mode block ciphers, >code complexity will bring in bugs. > >o The compatibility that derived IVs is suppose to give us, is BS. The >32-bit IV was a hack that should have been forgotten a long time ago. >Becides the current derived IV does not give us full compatibility. > >o Speed: We need speed down at the network interceptor level. Deriving an >IV takes a lot more time than just picking it up directly from the packet. > >o Space: An extra 8 bytes is nothing compared to the extra bytes that >ESP+auth adds in. > >o Flexibility: When (If) I do a RC5 implementation with 128 bit blocks, I >will need a 128 bit IV. I don't want to derive 16 bytes of IV. > o Current Implementations: All of the current implementations that we >tested with at all of the ANX bakeoffs used EXPLICIT IVs. From owner-ipsec Fri Aug 1 15:09:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA03351 for ipsec-outgoing; Fri, 1 Aug 1997 15:07:45 -0400 (EDT) Message-Id: <3.0.3.32.19970801151245.00c37210@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 01 Aug 1997 15:12:45 -0400 To: ipsec@tis.com From: Robert Moskowitz Subject: Proposed IPsec interop workshop Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Co-chair tipped back revealing customer hat. :) The AIAG is moving toward hopefully its last sponsering of an IPsec interoperability workshop. This workshop will concentrate on testing implementations of new-ESP using the DES-explicit-iv encryption and hmac-md5-96 authentication (other will be tested based on resources, I am sure). The IPsec tunnels will be get their keying material from Oakley exchanges based minimally on Oakley Main Mode auth 3 (RSA signature). The AIAG will be supplying a cross-certified PKI for the testing (ie implementations need to validate received certs in such and environment). These IPsec connections will have to demonstrate actual data transfers, minimally 5mb FTPs. Current discussions are pegging this workshop for the week of Sept 22nd in Ottawa CA. Any vendor in position to participate in such testing (please note the non-USA location) please contact me. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Fri Aug 1 15:46:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA03585 for ipsec-outgoing; Fri, 1 Aug 1997 15:44:47 -0400 (EDT) Date: Fri, 1 Aug 1997 12:51:49 -0800 From: Kevin Brock Subject: Re: Calling the question: implicit vs. explicit IV To: "Theodore Y. Ts'o" Cc: ipsec@tis.com X-Mailer: Z-Mail Pro 6.1 (Win32 - 021297), NetManage Inc. X-Priority: 3 (Normal) References: <199708011557.IAA29312@pita.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Sender: owner-ipsec@ex.tis.com Precedence: bulk One more vote for explicit IV. Kevin Brock brock@netmanage.com From owner-ipsec Fri Aug 1 16:00:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA03697 for ipsec-outgoing; Fri, 1 Aug 1997 15:59:18 -0400 (EDT) Message-Id: <199708011959.PAA03697@portal.ex.tis.com> X-Mailer: exmh version 2.0delta 6/3/97 To: "Theodore Y. Ts'o" cc: "William Allen Simpson" , ipsec@tis.com Subject: Re: Calling the question: derived vs. explicit IV Date: Fri, 1 Aug 1997 14:55:55 -0400 From: "ozan s. yigit" Sender: owner-ipsec@ex.tis.com Precedence: bulk in favor of derived. oz --- it is better to be dethpicable than to be dead. -- daffy duck From owner-ipsec Fri Aug 1 16:02:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA03705 for ipsec-outgoing; Fri, 1 Aug 1997 16:00:48 -0400 (EDT) Date: Fri, 1 Aug 1997 15:13:28 -0400 From: Norman Shulman X-Sender: norm@rafael.tornd.securecomputing.com To: "Theodore Y. Ts'o" cc: William Allen Simpson , ipsec@tis.com Subject: Re: Calling the question: derived vs. explicit IV In-Reply-To: <199708011827.OAA18261@dcl.MIT.EDU> Message-Id: <97Aug1.150844edt.11652@janus.tor.securecomputing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Fri, 1 Aug 1997, Theodore Y. Ts'o wrote: > Date: Fri, 1 Aug 97 14:32:52 GMT > From: "William Allen Simpson" > > In favor of Derived: > > 2) Maintains complete backward compatibility with RFCs 1829 and 1851. > All shipping implementations already support the derived IV. > > Not true. It is not _complete_ backwards compatibility. RFC 1829 > support's no IV, 32-bit IV, and 64-bit IV. The compatibility you > propose only works using RFC 1829-style 32-bit IV. > > In addition the handling of sequence number wrapping means that there is > yet another compatibility issue. This can be solved having the ESP > engine know something about whether the key management was manually done > or not. However, that's an abstraction violation, and it certainly adds > to the complexity of the implementation simply to have this > "compatibility". Using the current ESP draft in compatibility mode requires disabling the authentication service. When the authentication service is disabled, the draft requires disabling sequence number verification. Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@tor.securecomputing.com Fax 1 416 813 2001 From owner-ipsec Fri Aug 1 16:36:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA03900 for ipsec-outgoing; Fri, 1 Aug 1997 16:33:50 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <97Aug1.150844edt.11652@janus.tor.securecomputing.com> References: <199708011827.OAA18261@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 Aug 1997 16:36:27 -0400 To: Norman Shulman From: Stephen Kent Subject: Re: Calling the question: derived vs. explicit IV Cc: "Theodore Y. Ts'o" , William Allen Simpson , ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk At 3:13 PM -0400 8/1/97, Norman Shulman wrote: >On Fri, 1 Aug 1997, Theodore Y. Ts'o wrote: > >> Date: Fri, 1 Aug 97 14:32:52 GMT >> From: "William Allen Simpson" >> >> In favor of Derived: >> >> 2) Maintains complete backward compatibility with RFCs 1829 and 1851. >> All shipping implementations already support the derived IV. >> >> Not true. It is not _complete_ backwards compatibility. RFC 1829 >> support's no IV, 32-bit IV, and 64-bit IV. The compatibility you >> propose only works using RFC 1829-style 32-bit IV. >> >> In addition the handling of sequence number wrapping means that there is >> yet another compatibility issue. This can be solved having the ESP >> engine know something about whether the key management was manually done >> or not. However, that's an abstraction violation, and it certainly adds >> to the complexity of the implementation simply to have this >> "compatibility". > >Using the current ESP draft in compatibility mode requires disabling the >authentication service. When the authentication service is disabled, the draft >requires disabling sequence number verification. > >Norm True, but sequence number generation and overflow checking is always enabled at the sender, where the difference between a zero starting value and a random starting value is what causes some complexity. From owner-ipsec Fri Aug 1 18:09:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA04379 for ipsec-outgoing; Fri, 1 Aug 1997 18:04:47 -0400 (EDT) Message-ID: <0171F2F8F9E5D011A4D10060B03CFB44024227@scc-server3.semaphorecom.com> From: Mark Vondemkamp To: ipsec@tis.com Subject: RE: Calling the question: derived vs. explicit IV Date: Fri, 1 Aug 1997 15:17:56 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk I would like to see an explicit IV. Mark ------------------------------------------------------------------- Mark T. Vondemkamp Semaphore Communications Corporation 4000 Burton Drive Santa Clara, California 95054 http://www.semaphorecom.com Phone: 408-486-1603 Fax: 408-980-7769 Email: mark@semaphorecom.com ------------------------------------------------------------------- From owner-ipsec Fri Aug 1 18:39:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA04628 for ipsec-outgoing; Fri, 1 Aug 1997 18:37:17 -0400 (EDT) Message-Id: <199708012317.TAA04145@istari.sandelman.ottawa.on.ca> To: Bill Trost CC: ipsec@tis.com Subject: Re: (mobile-ip) Mobile IP for FreeBSD from Portland State University In-reply-to: Your message of "Fri, 01 Aug 1997 11:01:20 PDT." Date: Fri, 01 Aug 1997 19:17:51 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bill" == Bill Trost writes: Bill> Portland State University's newest release of Mobile IP for Bill> FreeBSD is now available. This release combines Mobile IP Bill> routing with IPSEC security. Which set of transforms? NRL below suggests RFC ones. ... Bill> Portions of the release are export controlled. They can Bill> only be downloaded by filling out a form at Bill> http://web.mit.edu/network/isakmp/isakmpform.html. Bill> * IPSEC support within the Mobile IP daemons. All traffic Bill> between mobile nodes and their home agents may be encrypted, Bill> essentially creating a virtual private network. Foreign Bill> agents are not involved in the IPSEC security associations, Bill> but are tunneled over. In this release, encryption is Bill> supported only when the mobile node is at a foreign agent Bill> unless PSU's ad hoc mode; in that case, encryption may be Bill> used when the mobile node is at its home agent as well as at Bill> foreign agents. Bill> Also, foreign agents may require home agents to authenticate Bill> IPIP packets they send, preventing attackers from using Bill> foreign agents to circumvent a firewall. ... Bill> * NRL's IPSEC, ported to FreeBSD, with extensions to allow Bill> IPSEC security associations to be bound to routes. This Bill> allows virtual private networks to be created by simply Bill> configuring the routing table appropriately. :!mcr!: | Network security programming, currently Michael Richardson | on contract with DataFellows F-Secure IPSec 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 iQB1AwUBM+JumKZpLyXYhL+BAQFsrgMAk9XT0WmhLCi8B5fr2juxsoYFcDCuWxAI 6T35C7fQiu5vUPbSumRtv46MrJGrD4Q+I28B4XF20Ip7es3q3Flr6Uw+u2W73jVT +ZXAi/xh8AnbRSei4QbvpMmniG3ox0VP =B6dc -----END PGP SIGNATURE----- From owner-ipsec Fri Aug 1 21:04:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA05378 for ipsec-outgoing; Fri, 1 Aug 1997 21:02:15 -0400 (EDT) Date: Sat, 2 Aug 97 00:49:44 GMT Daylight Time From: Ran Atkinson Subject: Re: Mobile IP for FreeBSD from Portland State University To: Bill Trost , ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Fri, 01 Aug 1997 11:01:40 -0700 Bill Trost wrote: > * NRL's IPSEC, ported to FreeBSD, with extensions to allow IPSEC security > associations to be bound to routes. This allows virtual private networks > to be created by simply configuring the routing table appropriately. EVERY release of NRL IPsec __already__ supported binding IPsec SAs to routes, so that is NOT a new extension. In fact, the original NRL codebase was tested at NRL in a VPN configuration and it worked fine. Those of us who wrote the original NRL code would _really_ appreciate it if Bill and others at PDX would drop that misleading claim. Dan McD did the NRL secure route code modification (in fairness to PDX folks, it was a bit obscurely coded in the earliest NRL releases) in one of the very few bits of IPsec code danmcd did at NRL (nearly all NRL ipsec code is from cmetz or rja). The PDX folks do secure routes differently than the NRL IPsec code does. Various other aspects of the NRL IPsec code were altered (e.g. The PDX code that I examined in Spring 97 had removed the feature that IPsec policy processing was isolated into one place -- ipsec_policy.c) -- so its not a straight port. Also, as of the Spring'97 PDX code, the NRL code inside was fairly ancient stuff, not one of the more recent NRL releases. If FreeBSD folks are interested only in IPsec, they might be more interested in porting one of the newer releases from NRL or working from some other freely distributable codebase. That all said, I hope various folks find the PDX code useful. Ran rja@inet.org From owner-ipsec Sat Aug 2 15:37:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA09711 for ipsec-outgoing; Sat, 2 Aug 1997 15:32:43 -0400 (EDT) Date: Sat, 2 Aug 1997 22:37:46 +0300 (IDT) From: Sara Bitan To: ipsec@tis.com Subject: RE: Calling the question: derived vs. explicit IV In-Reply-To: <0171F2F8F9E5D011A4D10060B03CFB44024227@scc-server3.semaphorecom.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Vote for explicit IV. I support Ed's argument. Sara Bitan | Voice: +972-3-645-5378 | Email: sarab@radguard.com RADGUARD, Ltd. | Fax: +972-3-648-0859 | www.radguard.com From owner-ipsec Mon Aug 4 08:15:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20241 for ipsec-outgoing; Mon, 4 Aug 1997 08:09:35 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org From: Internet-Drafts@ietf.org cc: ipsec@tis.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-simpson-esp-v2-00.txt Date: Sat, 02 Aug 1997 11:39:58 -0400 Message-ID: <9708021139.aa08461@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP Encapsulating Security Payload (ESP) for Implementors Author(s) : W. Simpson Filename : draft-simpson-esp-v2-00.txt Pages : 15 Date : 1997-08-01 This document describes a confidentiality mechanism for IP datagrams. Payload headers are encapsulated within an opaque envelope. Under some circumstances, authentication and integrity are optionally provided for IP datagrams. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-simpson-esp-v2-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-simpson-esp-v2-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-simpson-esp-v2-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: <19970801171813.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-simpson-esp-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-esp-v2-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970801171813.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Aug 4 08:36:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20420 for ipsec-outgoing; Mon, 4 Aug 1997 08:36:35 -0400 (EDT) Date: Mon, 4 Aug 1997 08:43:17 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199708041243.IAA12439@argon.ncsc.mil> To: ipsec@tis.com Subject: Re: Calling the question: derived vs. explicit IV X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: "Theodore Y. Ts'o" > > I am keeping track of > messages sent both to the list and to me privately; however, I'd ask > that folks send their preferences to the list, if at all possible. I expressed a preference for explicit IV privately simply to avoid me-too-ism. But in the interest of open debate, ... > From: Rob Adams > > Add me to the list of people supporting an explicit IV only. > > I agree with Mr. Rogers' comment that we shouldn't mandate what is in > the IV. The two drafts I wrote, and I believe Roy's as well, suggest > using the last block of the previous encryption pass. This is cheap > and common. I only suggested that people use a pseudo-random value > for the first pass... Ed said it best when he stated that he'd > like to see ship what we've been testing for quite some time now. I > do not believe we are "changing to" an explicit IV. I believe, if > there is a change, it would be to derived IV. So I vote for sticking > with explicit IV's. Me too. From owner-ipsec Mon Aug 4 11:20:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA21568 for ipsec-outgoing; Mon, 4 Aug 1997 11:20:04 -0400 (EDT) Date: Mon, 4 Aug 1997 11:20:37 -0400 (EDT) Message-Id: <199708041520.LAA21482@carp.morningstar.com> From: Ben Rogers To: ipsec@tis.com Subject: RE: Calling the question: derived vs. explicit IV In-Reply-To: <0171F2F8F9E5D011A4D10060B03CFB44024227@scc-server3.semaphorecom.com> References: <0171F2F8F9E5D011A4D10060B03CFB44024227@scc-server3.semaphorecom.com> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk I would prefer the derived IV. ben From owner-ipsec Mon Aug 4 11:54:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA21766 for ipsec-outgoing; Mon, 4 Aug 1997 11:54:39 -0400 (EDT) Date: Mon, 4 Aug 1997 09:02:18 -0700 Message-Id: <199708041602.JAA21654@gump.eng.ascend.com> From: Karl Fox To: "Theodore Y. Ts'o" Cc: ipsec@tis.com Subject: Re: Calling the question: derived vs. explicit IV In-Reply-To: <199708011827.OAA18261@dcl.MIT.EDU> References: <6390.wsimpson@greendragon.com> <199708011827.OAA18261@dcl.MIT.EDU> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ipsec@ex.tis.com Precedence: bulk Theodore Y. Ts'o writes: > As far as Bill's counting of noses of who is for and who is against, > there are a number of in his lists for which I haven't seen a clear > statement on this position, and a number of people who have stated a > position which he neglected to put on his lists. I am keeping track of > messages sent both to the list and to me privately; however, I'd ask > that folks send their preferences to the list, if at all possible. Please count me as being in favor of a derived IV. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 From owner-ipsec Mon Aug 4 11:55:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA21779 for ipsec-outgoing; Mon, 4 Aug 1997 11:55:08 -0400 (EDT) Date: Mon, 4 Aug 1997 19:00:38 +0300 (IDT) From: Dan Frommer To: ipsec@tis.com Cc: internet-drafts@ietf.org Subject: ID: draft-bitan-auth-des-mac-00.txt Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk IPSEC Working Group S.Bitan,RADGUARD Internet Draft D.Frommer,RADGUARD July 1997 The Use of DES-MAC within ESP and AH Status of This Memo This document is a submission to the IETF Internet Protocol Security (IPSEC) Working Group. Comments are solicited and should be addressed to the working group mailing list (ipsec@tis.com) or to the authors. This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts draft documents are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This draft describes the use of the DES-MAC algorithm [Kaufman95] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. DES-MAC[Kaufman95] is based on the DES encryption algorithm [FIPS-46, FIPS-46-1, FIPS-74, FIPS-81]. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a]. Internet Draft Page [1] Internet Draft DES-MAC Authenticator July 1997 Contents STATUS OF THIS MEMO .................................................1 ABSTRACT ............................................................1 1. INTRODUCTION .....................................................2 1.1 SPECIFICATION OF REQUIREMENTS .................................3 2. AUTHENTICATION ALGORITHM .........................................3 2.1 BLOCK SIZES AND PADDING ......................................3 2.2 PERFORMANCE ...................................................3 3. KEY SPECIFICATIONS ...............................................4 4. IV ...............................................................4 5. INTERACTION WITH THE ESP CIPHER MECHANISM ........................4 6. SECURITY CONSIDERATIONS ..........................................4 7. ACKNOWLEDEMENTS ..................................................5 8. REFERENCES .......................................................5 9. AUTHORS INFORMATION ..............................................6 1. Introduction This draft describes the use of the DES-MAC algorithm to provide authenticity within the context of the Encapsulating Security Payload [ESP] and the Authentication Header [AH]. The goal of this auth-des- mac is to ensure that the packet is authentic and that it was not modified in transit. DES-MAC [Kaufman95] is based on the DES [FIPS-46, FIPS-46-1, FIPS- 74, FIPS-81] encryption algorithm. Given a secret key, the last output block of a DES-CBC encryption of a message is used as the output of the DES-MAC algorithm for this message. Hence, DES-MAC is a secret key authentication algorithm. Data authentication and data integrity provided by DES-MAC are dependent upon the scope of the distribution Bitan,Frommer Page [2] Internet Draft DES-MAC Authenticator July 1997 of the secret key. If only the source and the destination know the DES-MAC key, this provides data origin authentication and data integrity for packets sent between the two parties. If the outputs of the DES-MAC computed by the two parties are identical, this proves that it has been computed by the source, and that the packet was not modified in transit. IPSEC implementations for high bandwidth networks, might fail to supply the required performance without using hardware implementations of encryption and authentication algorithms. DES hardware implementations are popular and easy to find. Currently there exist only a few hardware implementations for the other authentication mechanisms that appear in the IPSEC drafts (HMAC-SHA-1 and HMAC-MD5). Hence, when high performance is a requirement, DES-MAC authenticator is preferable to HMAC-SHA-1 or HMAC-MD5. This document assumes the reader is familiar with the terms and concepts in [RFC-1825], in [ESP], and in [AH]. This document follows the IPsec document framework described in [Framework]. 1.1 Specification of Requirements Interpret the keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document as described in [RFC-2119]. 2. Authentication Algorithm DES-MAC algorithm is based on the DES encryption algorithm [FIPS-46, FIPS-46-1, FIPS-74, FIPS-81]. The Message Authentication Code (MAC) of a certain message is the last output block of the DES CBC encryption of the message. The authentication function properties of DES-MAC are derived from the encryption function properties of the DES algorithm. 2.1 Block sizes and Padding Like DES, DES-MAC is a block algorithm. It operates on input blocks of size 64 bits. Hence, its input must be padded to form a multiple of 64 bits blocks. When used in [ESP] the payload data must be padded, to make a block size of 64 bits. The padding should be done according to conventions specified in [ESP]. The output of the DES-MAC algorithm is 64 bits long. Hence, the authentication data size in both ESP and AH is 64 bits. 2.2 Performance The DES-MAC performance is identical to that of the DES encryption algorithm. The DES algorithm is designed to perform well using hardware implementations. Commonly available DES hardware is considerably faster than software implementations on popular Bitan,Frommer Page [3] Internet Draft DES-MAC Authenticator July 1997 processors. There are hardware implementation of DES operating in 100 Mbps[Schneier]. The use of hardware allows a level of parallelism between the CPU and the DES hardware, especially important in security gateway implementations. Phil Karn had tuned DES-CBC software to achieve 10.45 Mbps with a 90 MHz Pentium, scaling to 15.9 Mbps with a 133 MHz Pentium. If DES-MAC is used in conjunction with DES-CBC cipher in ESP, the DES calculation of both integrity and confidentiality may be performed in parallel given the appropriate hardware. 3. Key Specifications Like DES-CBC, the key of DES-MAC is 64 bits long. Each byte has seven significant bits, the least significant bit is used as a parity bit. The keying material must be adjusted for parity as necessary. If the resulting key is a weak key, it must not be used. A list of DES weak and semi-weak keys can be found in [Schneier]. When used in ESP, in conjunction with the DES-CBC cipher, independent keys must be used for authentication and encryption (see [Kaufman95, p.91]). A Security Association using this transform must rekey within a lifetime of 2^32 bytes. 4. IV The DES-CBC algorithm requires an Initialization vector (IV). So does the DES-MAC algorithm. In this transform the IV is implicitly set to zero. A constant IV can be used, since the data in the ESP payload is encrypted, and in AH the replay protection guarantees that all the packets authenticated under the same SA are distinct. 5. Interaction with the ESP cipher mechanism When used in conjunction with the DES-CBC cipher, independent keys must be used [Kaufman95, p.91]. For performance reason, when hardware encryption and authentication is used, it might be wanted to use DES- CBC cipher and DES-MAC authenticator together in ESP. 6. Security considerations The strength of the DES-MAC transform relies of the strength of DES. The correctness of the specific DES implementation used. The correctness of the Security Association management, the key management and their implementations. The MAC produced by the DES-MAC algorithm is short relative to other authentication mechanisms. This fact makes it less resistant to various attacks. To overcome this problem, the Security Association and keys life time must be shorter. Bitan,Frommer Page [4] Internet Draft DES-MAC Authenticator July 1997 7. Acknowledements Portions of this document are derived from draft-ietf-ipsec-auth-hmac- md5-99-00.txt, by C. Madson and R. Glenn. The IPsec document framework is described in draft-ietf-doc-roadmap- 00.txt. The authors would like to thank Rodney Thayer, Ed Russel and all the Detroit bake-off participants. 8. References [AH] S. Kent, R. Atkinson, "IP Authentication Header", work in progress, July 97. [ESP] S. Kent, R. Atkinson, "IP Encapsulating Security Protocol (ESP)", work in progress, July 1997. [FIPS-46] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46, January 1977. [FIPS-46-1] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46-1, January 1988. [FIPS-74] US National Bureau of Standards, "Guidelines for Implementing and Using the Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 74, April 1981. [FIPS-81] US National Bureau of Standards, "DES Modes of Operation", Federal Information Processing Standard (FIPS) Publication 81, December 1980. [Framework] The IP Security Document Roadmap, RFC-xxxx. [Kaufman95] Kaufman, C., Perlman, R. and Speciner, M., "Network Security: Private Communication in a Public World", PTR Prentice Hall, Englewood Cliffs, New Jersey, 1995. ISBN 0-13-061466-1 [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate Requirement Levels", ftp://ds.internic.net/rfc/rfc2119.txt, March 1997 [Schneier] Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7 Bitan,Frommer Page [5] Internet Draft DES-MAC Authenticator July 1997 9. Authors Information Sara Bitan RADGUARD, Ltd. 24 Raoul-Wallenberg St. Tel Aviv 69719 Israel Telephone: +972-3-645-5378 Dan Frommer RADGUARD, Ltd. 24 Raoul-Wallenberg St. Tel Aviv 69719 Israel Telephone: +972-3-645-5396 Bitan,Frommer Page [6] From owner-ipsec Mon Aug 4 12:23:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA21976 for ipsec-outgoing; Mon, 4 Aug 1997 12:22:11 -0400 (EDT) Message-Id: <199708041632.MAA20619@relay.hq.tis.com> From: Bill Trost To: ipsec@tis.com Subject: Re: Mobile IP for FreeBSD from Portland State University In-reply-to: Your message of "Sat, 02 Aug 1997 00:49:44 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5038.870712235.1@widmer-g.mn.cs.pdx.edu> Date: Mon, 04 Aug 1997 09:30:35 -0700 Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran Atkinson writes: --- On Fri, 01 Aug 1997 11:01:40 -0700 Bill Trost wrote: > * NRL's IPSEC, ported to FreeBSD, with extensions to allow IPSEC > security associations to be bound to routes.... EVERY release of NRL IPsec __already__ supported binding IPsec SAs to routes, so that is NOT a new extension.... Those of us who wrote the original NRL code would _really_ appreciate it if Bill and others at PDX would drop that misleading claim. I have gone back and studied the NRL (alpha 3 -- yes, it's pretty old) code a bit, and what I see (correct me if I'm wrong (-: ) is that NRL's IPv6 code supports routes with security associations, but if only the IPv4 code is used, none of this functionality is available. The claim I made may be misleading, but it should be fixed, not dropped. Thanks for the correction. From owner-ipsec Mon Aug 4 16:26:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA23841 for ipsec-outgoing; Mon, 4 Aug 1997 16:24:39 -0400 (EDT) Date: Mon, 4 Aug 1997 16:32:24 -0400 (EDT) From: Dave Mason Message-Id: <199708042032.QAA14872@rubicon.rv.tis.com> To: ipsec@tis.com Subject: Re: Calling the question: derived vs. explicit IV Sender: owner-ipsec@ex.tis.com Precedence: bulk I vote for explicit IV. -dave From owner-ipsec Mon Aug 4 23:59:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA26423 for ipsec-outgoing; Mon, 4 Aug 1997 23:57:17 -0400 (EDT) Date: Tue, 5 Aug 97 03:55:41 GMT Daylight Time From: Ran Atkinson Subject: Re: Mobile IP for FreeBSD from Portland State University To: Bill Trost , ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199708041632.MAA20619@relay.hq.tis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill, Its also there for IPv4, just admittedly obscure in implementation in the early code releases. We actually _tested_ this code at NRL in September 1995 prior to handing the first code to Mike StJohns (our then ARPA PM). Email me/danmcd if you want the walk through on how it works. Regards, Ran rja@inet.org From owner-ipsec Tue Aug 5 02:38:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA27247 for ipsec-outgoing; Tue, 5 Aug 1997 02:35:44 -0400 (EDT) Date: Tue, 5 Aug 1997 09:44:02 +0300 From: motif@CheckPoint.COM (Moti Frances) Message-Id: <199708050644.JAA14809@gov.checkpoint.com> To: ipsec@tis.com Subject: Re: Calling the question: derived vs. explicit IV X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk I vote for explicit IV. Moti From owner-ipsec Tue Aug 5 08:48:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA29596 for ipsec-outgoing; Tue, 5 Aug 1997 08:43:48 -0400 (EDT) Message-Id: <3.0.3.32.19970805083658.00aec550@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 05 Aug 1997 08:36:58 -0400 To: ipsec@tis.com From: Robert Moskowitz Subject: ISAKMP performance numbers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk With the discussion some time back on ISAKMP performance, I approached one of the vendors that I knew was shipping a product with ISAKMP. RedCreek's product uses DSS sig, not RSA so some of the numbers MIGHT be different. From: Cary Hayward To: "'rgm3@chrysler.com'" Subject: RE: RedCreek Performance Answer Date: Mon, 4 Aug 1997 17:15:53 -0700 Bob: Yes this is publishable on the IPSec list. Answers on performance interspersed below. Cary caryh@redcreek.com ---------- From: Robert Moskowitz[SMTP:rgm3@chrysler.com] Sent: Friday, August 01, 1997 5:10 AM To: Cary Hayward Subject: Re: RedCreek Performance Answer At 06:13 PM 7/31/97 -0700, Cary Hayward wrote: Thanks Cary. Is this publishable on the IPsec list? >Cary: Getting back to you on the performance question. Here are the results: 1.5-2 seconds to build a secure association between two IPSec gateways, this includes standard network latencies. The gateways have 32 bit >Bob: Since there are network latencies included here, a number of SA setups could be going on parrallel. 10 simultaneous SAs will not take 150 sec, rather what? 60sec? >Cary: Our first set of answers were based on our experience between two Ravlin 10's. As you might imagine it is hard to test large numbers of simulaneous key exchanges, but we feel your supositions are correct. With small numbers of simulaneous SAs, we have found that the SA setup times to be non-linear; therefore, 75 seconds may be a solid discussion number in this scenerio. The obvious reasons for the non-linearity is network latencies and the fact that with a test of two gateways, each gateway would be idle (not performing public key operations) for over 50% of the time. >Cary: RISC processors rated at 30 MIPS. By comparision, a Pentium-166 would be approximately 10 times faster. Each SA set-up includes: > >Cary: Two 1024-bit DSS signature generations, >Cary: Four 1024-bit DSS signature verifies, >Cary: and four DH exponentiations for a total of fourteen 1024-bit exponentiations >Bob: Would RSA be faster or slower? What about Eliptic Curves instead of DH? >Cary: We think that RSA would essentially be the same as DH. This is because RSA uses the exponential value of 0x3 or 0x10001 for encryption, it will operate significantly faster than generalized DH. RSA decryption performance, however, would essentially be the same as DH. The result is that if you add in all the real overhead, (e.g. hashing, X.509 cert processing, random number generation, etc.) RSA based solutions would be about 50% to 70% faster than DH of equal modulus length. That said, we feel that with more optimization, DH can approach RSA in terms of performance. >Cary: We cannot comment on actual performance numbers for eliptic curves without further study, will report in after we take a look. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Tue Aug 5 09:16:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA29772 for ipsec-outgoing; Tue, 5 Aug 1997 09:15:48 -0400 (EDT) From: pcalhoun@usr.com Mime-Version: 1.0 Date: Tue, 5 Aug 1997 08:23:44 -0500 Message-ID: <3E72C1F0.3000@usr.com> To: ipsec@tis.com, Robert Moskowitz Subject: Re: ISAKMP performance numbers Content-Type: multipart/mixed; boundary="IMA.Boundary.721887078" Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.721887078 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part So that said, can we now officially state that there *is* a scaling issue? Please keep in mind that some boxes *will* have to handle around 50 SAs per second. PatC ______________________________ Reply Separator _________________________________ Subject: ISAKMP performance numbers Author: Robert Moskowitz at Internet Date: 8/5/97 8:36 AM With the discussion some time back on ISAKMP performance, I approached one of the vendors that I knew was shipping a product with ISAKMP. RedCreek's product uses DSS sig, not RSA so some of the numbers MIGHT be different. From: Cary Hayward To: "'rgm3@chrysler.com'" Subject: RE: RedCreek Performance Answer Date: Mon, 4 Aug 1997 17:15:53 -0700 Bob: Yes this is publishable on the IPSec list. Answers on performance interspersed below. Cary caryh@redcreek.com ---------- From: Robert Moskowitz[SMTP:rgm3@chrysler.com] Sent: Friday, August 01, 1997 5:10 AM To: Cary Hayward Subject: Re: RedCreek Performance Answer At 06:13 PM 7/31/97 -0700, Cary Hayward wrote: Thanks Cary. Is this publishable on the IPsec list? >Cary: Getting back to you on the performance question. Here are the results: 1.5-2 seconds to build a secure association between two IPSec gateways, this includes standard network latencies. The gateways have 32 bit >Bob: Since there are network latencies included here, a number of SA setups could be going on parrallel. 10 simultaneous SAs will not take 150 sec, rather what? 60sec? >Cary: Our first set of answers were based on our experience between two Ravlin 10's. As you might imagine it is hard to test large numbers of simulaneous key exchanges, but we feel your supositions are correct. With small numbers of simulaneous SAs, we have found that the SA setup times to be non-linear; therefore, 75 seconds may be a solid discussion number in this scenerio. The obvious reasons for the non-linearity is network latencies and the fact that with a test of two gateways, each gateway would be idle (not performing public key operations) for over 50% of the time. >Cary: RISC processors rated at 30 MIPS. By comparision, a Pentium-166 would be approximately 10 times faster. Each SA set-up includes: > >Cary: Two 1024-bit DSS signature generations, >Cary: Four 1024-bit DSS signature verifies, >Cary: and four DH exponentiations for a total of fourteen 1024-bit exponentiations >Bob: Would RSA be faster or slower? What about Eliptic Curves instead of DH? >Cary: We think that RSA would essentially be the same as DH. This is because RSA uses the exponential value of 0x3 or 0x10001 for encryption, it will operate significantly faster than generalized DH. RSA decryption performance, however, would essentially be the same as DH. The result is that if you add in all the real overhead, (e.g. hashing, X.509 cert processing, random number generation, etc.) RSA based solutions would be about 50% to 70% faster than DH of equal modulus length. That said, we feel that with more optimization, DH can approach RSA in terms of performance. >Cary: We cannot comment on actual performance numbers for eliptic curves without further study, will report in after we take a look. Robert Moskowitz Chrysler Corporation (810) 758-8212 --IMA.Boundary.721887078 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 (mailgate.usr.com) by robogate2.usr.com with SMTP (IMA Internet Exchange 2.02 Enterprise) id 3E727630; Tue, 5 Aug 97 08:15:16 -0500 Received: from portal.ex.tis.com by usr.com (8.7.5/3.1.090690-US Robotics) id HAA28378; Tue, 5 Aug 1997 07:52:25 -0500 (CDT) Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA29596 for ipsec-outgoing; Tue, 5 Aug 1997 08:43:48 -0400 (EDT) Message-Id: <3.0.3.32.19970805083658.00aec550@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 05 Aug 1997 08:36:58 -0400 To: ipsec@tis.com From: Robert Moskowitz Subject: ISAKMP performance numbers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.721887078-- From owner-ipsec Tue Aug 5 09:38:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA00048 for ipsec-outgoing; Tue, 5 Aug 1997 09:38:19 -0400 (EDT) Date: Tue, 5 Aug 1997 16:46:16 +0300 (EET DST) Message-Id: <199708051346.QAA12869@pilari.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Tero T. Mononen" Reply-To: tmo@ssh.fi To: ipsec@tis.com Subject: re; Calling the question: implicit vs. explicit IV In-Reply-To: <199708010601.CAA18158@dcl.MIT.EDU> References: <199708010601.CAA18158@dcl.MIT.EDU> X-Mailer: VM 6.22 under 19.15 XEmacs Lucid Organization: SSH Communications Security Oy, Espoo, Finland Sender: owner-ipsec@ex.tis.com Precedence: bulk I am in favor of explicit IV. -- Tero T. Mononen Ssh Communications Security Oy http://www.ssh.fi/ F-Secure Internet Security Solutions http://www.datafellows.com/f-secure/ From owner-ipsec Tue Aug 5 09:40:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA00066 for ipsec-outgoing; Tue, 5 Aug 1997 09:39:50 -0400 (EDT) Message-Id: <199708051347.GAA13168@pita.cisco.com> To: pcalhoun@usr.com cc: ipsec@tis.com, Robert Moskowitz Subject: Re: ISAKMP performance numbers In-reply-to: Your message of "Tue, 05 Aug 1997 08:23:44 CDT." <3E72C1F0.3000@usr.com> Date: Tue, 05 Aug 1997 06:47:37 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk PatC, Performance and scaling is a very tricky business. One person's bottleneck is another's market opportunity. Perhaps we should spend some energy as a group developing some semi-formal benchmarks for ISAKMP and IPSEC? Derrell From owner-ipsec Tue Aug 5 11:27:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00796 for ipsec-outgoing; Tue, 5 Aug 1997 11:25:54 -0400 (EDT) Date: Tue, 5 Aug 97 15:18:36 GMT Daylight Time From: Ran Atkinson Subject: Re: ISAKMP performance numbers To: pcalhoun@usr.com Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <3E72C1F0.3000@usr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Pat, There is not necessarily a scaling issue. You might have one in some products, but that doesn't mean that other folks will --- different products, different implementation approaches, etc. As someone else said, one person's scaling issue is another person's business opportunity. I still don't find your rate of claimed necessary new SAs/second to be credible, because the assumptions that got you there aren't congruent with the dialup numbers we see in the real world. I'm open minded, but the data in my hands just is not consistent with your assumptions. Moreover, other dialup vendors I work with don't necessarily agree with either your assumptions or your conclusion that there is an intrinsic problem. All that said, the IPsec WG has a history of getting side-tracked by side issues. Right now, (IMKHO) I'd like to see the WG focus on getting the current ESP/AH/ISAKMP/Oakley I-D set out as standards track RFCs. If folks want to focus on performance issues after the RFCs go out, that would be A Fine Thing (IMHO). Best wishes, Ran rja@inet.org From owner-ipsec Tue Aug 5 11:33:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00865 for ipsec-outgoing; Tue, 5 Aug 1997 11:32:58 -0400 (EDT) Message-ID: <33E74918.4C6A@fet.com> Date: Tue, 05 Aug 1997 08:39:04 -0700 From: "Scott G. Kelly" Organization: Furukawa Electric Technologies, Inc. X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: pcalhoun@usr.com CC: ipsec@tis.com, Robert Moskowitz Subject: Re: ISAKMP performance numbers References: <3E72C1F0.3000@usr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I try to post rarely, because I can't possibly see all sides of all issues with my limited bandwidth, and I hate making a fool of myself. However, I fail to see your point. Yes, there is overhead associated with security. Yes, if you want to handle large amounts of connection turnover, you will have problems doing that with a small box. So? Why is that our problem, as opposed to your design constraint? From owner-ipsec Tue Aug 5 12:11:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA01173 for ipsec-outgoing; Tue, 5 Aug 1997 12:10:53 -0400 (EDT) Message-Id: <199708051619.JAA04270@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: pcalhoun@usr.com Cc: ipsec@tis.com, Robert Moskowitz Subject: Re: ISAKMP performance numbers In-Reply-To: Your message of "Tue, 05 Aug 1997 08:23:44 CDT." <3E72C1F0.3000@usr.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Aug 1997 09:19:23 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk What we can officially state (which is what I stated last month) is that a Diffie-Hellman exchange with a reasonable modulus which is authenticated with, say, RSA signatures (that's sign, verify CA sig on cert, verify peer's sig-- or one sign, 2 verifies) with reasonably secure exponents IS NOT FREE! This has _nothing_ to do with ISAKMP. In the past you stated that your SAs would live for a year. Also that you weren't concerned about confidentiality, only "securing" the NAS to LNS link (I presume this means authentication). So, my question to you is: why do you want an ephemeral key? Why do you want to do ISAKMP? Why not just statically configure your NAS-to-LNS SAs and be done with it? Dan. > So that said, can we now officially state that there *is* a scaling > issue? Please keep in mind that some boxes *will* have to handle > around 50 SAs per second. > > PatC From owner-ipsec Tue Aug 5 12:17:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA01227 for ipsec-outgoing; Tue, 5 Aug 1997 12:17:25 -0400 (EDT) From: pcalhoun@usr.com Mime-Version: 1.0 Date: Tue, 5 Aug 1997 11:20:32 -0500 Message-ID: <3E756530.3000@usr.com> To: "Scott G. Kelly" Cc: ipsec@tis.com, Robert Moskowitz Subject: Re[2]: ISAKMP performance numbers Content-Type: multipart/mixed; boundary="IMA.Boundary.039897078" Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.039897078 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Well this is getting old, but I will re-iterate again! Consider a box that has to handle 1000 incoming lines. In the world of tunneling (a la L2TP) an SA is required for each tunnel peer. In the real world of roaming, with the number of customers terminating L2TP tunnels the chances of having more than one dial-up user being tunneled to a single L2TP server is very small. For each tunnel being established we need to setup an SA. I have seen the networks being run today, and with large density boxes (btw, this is NOT a small box) it is not uncommon to have 30+ calls come in at once. So, the e-mail that Bob forwarded to the mailing list showed an implementation that would take about 75 seconds to setup 10 SAs. Possibly you could enlighten me as to how a box which requires many simultaneous SAs to be setup as the example above can handle this? Please keep in mind that caching in the said box is NOT really possible due to memory constraints (it is an embedded box). If you do the math, you will figure out that caching all of the SAs over a period of 24 hours with that many calls certainly adds up pretty quickly. That said, I will now shut up and let the WG finish up on its current milestones. PatC ______________________________ Reply Separator _________________________________ Subject: Re: ISAKMP performance numbers Author: "Scott G. Kelly" at Internet Date: 8/5/97 8:39 AM I try to post rarely, because I can't possibly see all sides of all issues with my limited bandwidth, and I hate making a fool of myself. However, I fail to see your point. Yes, there is overhead associated with security. Yes, if you want to handle large amounts of connection turnover, you will have problems doing that with a small box. So? Why is that our problem, as opposed to your design constraint? --IMA.Boundary.039897078 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 (mailgate.usr.com) by robogate2.usr.com with SMTP (IMA Internet Exchange 2.02 Enterprise) id 3E74C490; Tue, 5 Aug 97 10:52:41 -0500 Received: from vogue.fet.com by usr.com (8.7.5/3.1.090690-US Robotics) id KAA06013; Tue, 5 Aug 1997 10:29:51 -0500 (CDT) Received: from vogue.fet.com (toro.fet.com [192.203.72.38]) by vogue.fet.com (8.6.12+2.5Wb7/3.4W202/15/96) with SMTP id IAA15996; Tue, 5 Aug 1997 08:41:15 -0700 Message-ID: <33E74918.4C6A@fet.com> Date: Tue, 05 Aug 1997 08:39:04 -0700 From: "Scott G. Kelly" Organization: Furukawa Electric Technologies, Inc. X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: pcalhoun@usr.com CC: ipsec@tis.com, Robert Moskowitz Subject: Re: ISAKMP performance numbers References: <3E72C1F0.3000@usr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --IMA.Boundary.039897078-- From owner-ipsec Tue Aug 5 13:55:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA01871 for ipsec-outgoing; Tue, 5 Aug 1997 13:53:23 -0400 (EDT) From: pcalhoun@usr.com Mime-Version: 1.0 Date: Tue, 5 Aug 1997 12:57:24 -0500 Message-ID: <3E76D1C0.3000@usr.com> To: Daniel Harkins Cc: ipsec@tis.com, Robert Moskowitz Subject: Re[2]: ISAKMP performance numbers Content-Type: multipart/mixed; boundary="IMA.Boundary.467408078" Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.467408078 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Because of the sheer number of boxes involved, and the number of organisations involved does not allow for static configuration. Ask Bon if he would be willing to use manual keying in his network! That and the fact that the L2TP now requires IPSEC (including ISAKMP). BTW, I stated that I would love to cache my SAs for a year, if it was possible. There are methods of doing this using a third party, and I had an e-mail which described how this would work (and I have not ruled out this possibility). PatC Now I am REALLY shutting up :) ______________________________ Reply Separator _________________________________ Subject: Re: ISAKMP performance numbers Author: Daniel Harkins at Internet Date: 8/5/97 9:19 AM What we can officially state (which is what I stated last month) is that a Diffie-Hellman exchange with a reasonable modulus which is authenticated with, say, RSA signatures (that's sign, verify CA sig on cert, verify peer's sig-- or one sign, 2 verifies) with reasonably secure exponents IS NOT FREE! This has _nothing_ to do with ISAKMP. In the past you stated that your SAs would live for a year. Also that you weren't concerned about confidentiality, only "securing" the NAS to LNS link (I presume this means authentication). So, my question to you is: why do you want an ephemeral key? Why do you want to do ISAKMP? Why not just statically configure your NAS-to-LNS SAs and be done with it? Dan. > So that said, can we now officially state that there *is* a scaling > issue? Please keep in mind that some boxes *will* have to handle > around 50 SAs per second. > > PatC --IMA.Boundary.467408078 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 (mailgate.usr.com) by robogate2.usr.com with SMTP (IMA Internet Exchange 2.02 Enterprise) id 3E755550; Tue, 5 Aug 97 11:31:17 -0500 Received: from airedale.cisco.com by usr.com (8.7.5/3.1.090690-US Robotics) id LAA08323; Tue, 5 Aug 1997 11:08:27 -0500 (CDT) Received: from dharkins-ss20 (dharkins-ss20.cisco.com [171.69.56.149]) by airedale.cisco.com (8.6.12/8.6.5) with ESMTP id JAA14778; Tue, 5 Aug 1997 09:19:24 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by dharkins-ss20 (8.6.8+c/CISCO.WS.1.1) with SMTP id JAA04270; Tue, 5 Aug 1997 09:19:23 -0700 Message-Id: <199708051619.JAA04270@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: pcalhoun@usr.com Cc: ipsec@tis.com, Robert Moskowitz Subject: Re: ISAKMP performance numbers In-Reply-To: Your message of "Tue, 05 Aug 1997 08:23:44 CDT." <3E72C1F0.3000@usr.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Aug 1997 09:19:23 -0700 From: Daniel Harkins --IMA.Boundary.467408078-- From owner-ipsec Tue Aug 5 15:40:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA02518 for ipsec-outgoing; Tue, 5 Aug 1997 15:37:56 -0400 (EDT) Message-Id: <3.0.3.32.19970805122158.00a56c80@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 05 Aug 1997 12:21:58 -0400 To: Karen Seo From: Robert Moskowitz Subject: Re: Internet Draft -- IPsec Architecture Cc: ipsec@tis.com, tytso@MIT.EDU, skent@bbn.com In-Reply-To: <199707311309.JAA22086@portal.ex.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk 3rd paragraph in 4.1: As noted above, two types of SAs are defined: transport mode and tunnel mode. A transport mode SA is a security association between two hosts. The security protocol header appears immediately after the IP header (and any options or extensions), and before any higher layer protocols (e.g., TCP or UDP). In the case of ESP, a tunnel ^^^^^^ Isn't this transport? mode SA provides security services only for these higher layer protocols, not for the IP header. In the case of AH, the protection is also extended to selected portions of the IP header (and options). For more details on the coverage afforded by AH, see the AH specification [KA97b]. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Tue Aug 5 23:12:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA04912 for ipsec-outgoing; Tue, 5 Aug 1997 23:09:28 -0400 (EDT) Date: Tue, 5 Aug 1997 23:18:12 -0400 Message-Id: <199708060318.XAA27431@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: DRAFT agenda Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk The following is a DRAFT agenda for our upcoming IPSEC working group meeting in Munich. Nothing is set in stone at this point, although you will note that we are very tight for time. If you need more time, or if you'd like to give a presentation and you're not yet on this list, let me know. Better yet, if you think you can do your presentation in less time time than what I alloted, *please* let me know. :-) Many thanks, - Ted IPSEC WG Agenda (0900-1130) 900-905 Introduction and agenda bashing (5 min) 905-920 Overview of Active wg Documents (15 min) 920-940 Review AH and ESP --- S. Kent (20 min) 940-945 DES MAC Transform --- S. Bitan (5 min) 945-955 ISAKMP Review --- D. Maughan (10 min) 955-1025 Review Architecture --- S. Kent (30 min) 1025-1035 Tool for (trust path?) topology maintainence -- S. Bitan (10 minutes) 1035-1045 Next generation cipher devices -- R. Thayer (10 min) 1045-1100 Virtual Private Networks -- N. Doraswamy (15 min) 1100-1110 Secure DHCP --- B. Patel (10 min) 1110-1130 IPSecond (Remaining issues to be handled after ipsec wg concludes its current set of work itmes) --- S. Bellovin (20 min) From owner-ipsec Wed Aug 6 07:52:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA07778 for ipsec-outgoing; Wed, 6 Aug 1997 07:49:24 -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-revised-enc-mode-01.txt Date: Tue, 05 Aug 1997 17:07:34 -0400 Message-ID: <9708051707.aa29448@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 : A revised encryption mode for ISAKMP/Oakley Author(s) : H. Krawczyk, P. Cheng, R. Canetti Filename : draft-ietf-ipsec-revised-enc-mode-01.txt Pages : 6 Date : 1997-08-05 The ISAKMP/Oakley document [HC97] describes a proposed standard for using the Oakley Key Exchange Protocol in conjunction with ISAKMP to obtain authenticated and secret keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI. The public-key encryption method of carrying out Phase 1 of the key exchange in the ISAKMP/Oakley document provides significant security advantages over the other alternatives and should be the method of choice in many implementations. Unfortunately, as currently described in [HC97] the method requires two public key encryption and decryption operations from both the Initiator and the Responder. The present document describes a small modification to this method. The resulting scheme requires only one public key encryption and decryption operation from each party, while maintaining (and even improving on) the strong security properties of the ISAKMP/Oakley public-key encryption mode. Remark: This document is NOT self-contained, it is intended as an addendum to the authentication methods defined in [HC97]. In particular, it uses notation and definitions of [HC97]. Thus, it is best read in conjunction with [HC97]. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-revised-enc-mode-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-revised-enc-mode-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-revised-enc-mode-01.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: <19970805164757.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-revised-enc-mode-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-revised-enc-mode-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805164757.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Aug 6 07:52:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA07799 for ipsec-outgoing; Wed, 6 Aug 1997 07:50:54 -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-vpn-00.txt Date: Tue, 05 Aug 1997 17:07:52 -0400 Message-ID: <9708051707.aa29639@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 : Implementation of Virtual Private Network (VPNs) with IP Security Author(s) : N. Doraswamy Filename : draft-ietf-ipsec-vpn-00.txt Pages : 5 Date : 1997-03-14 This document discusses methods for implementing Virtural Private Networks (VPN) with IP Security (IPSec). We discuss different scenarios in which VPN is implemented and the security implications for each of these scenarios. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-vpn-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-vpn-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-vpn-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: <19970805164119.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-vpn-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-vpn-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805164119.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Aug 6 08:18:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA08035 for ipsec-outgoing; Wed, 6 Aug 1997 08:16:54 -0400 (EDT) Message-Id: <3.0.3.32.19970806082011.009cdb20@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 06 Aug 1997 08:20:11 -0400 To: "Theodore Y. Ts'o" , ipsec@tis.com From: Robert Moskowitz Subject: Re: DRAFT agenda In-Reply-To: <199708060318.XAA27431@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:18 PM 8/5/97 -0400, Theodore Y. Ts'o wrote: > >1110-1130 IPSecond (Remaining issues to be handled after ipsec wg > concludes its current set of work itmes) --- This might be one of the better names out of the ietf, but it might be too confusing for people outside of our tight-knit group :) maybe IPsec/ond or IPsec-ond. or we can have a contest, winner gets a free 2048bit D-H key? Sorry, it was a long day yesterday evening! Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Aug 6 08:22:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA08052 for ipsec-outgoing; Wed, 6 Aug 1997 08:20:53 -0400 (EDT) Date: Wed, 6 Aug 1997 08:29:17 -0400 (EDT) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <3.0.3.32.19970805122158.00a56c80@dilbert.is.chrysler.com> References: <199707311309.JAA22086@portal.ex.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rgm3@chrysler.com From: Stephen Kent Subject: Re: Internet Draft -- IPsec Architecture Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bob, > > As noted above, two types of SAs are defined: transport mode and > tunnel mode. A transport mode SA is a security association between > two hosts. The security protocol header appears immediately after > the IP header (and any options or extensions), and before any higher > layer protocols (e.g., TCP or UDP). In the case of ESP, a tunnel > > ^^^^^^ >Isn't this transport? Yes, this is a typo and should be transport, not tunnel, mode. Steve From owner-ipsec Wed Aug 6 08:32:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA08150 for ipsec-outgoing; Wed, 6 Aug 1997 08:30:23 -0400 (EDT) Message-Id: <3.0.32.19970806133709.00710da8@127.0.0.1> X-Sender: smb@127.0.0.1 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 06 Aug 1997 13:37:14 -0400 To: rgm3@chrysler.com From: "Steven M. Bellovin" Subject: Re: DRAFT agenda Cc: "Theodore Y. Ts'o" , ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 08:20 AM 8/6/97 -0400, Robert Moskowitz wrote: >At 11:18 PM 8/5/97 -0400, Theodore Y. Ts'o wrote: >> >>1110-1130 IPSecond (Remaining issues to be handled after ipsec wg >> concludes its current set of work itmes) --- > >This might be one of the better names out of the ietf, but it might be too >confusing for people outside of our tight-knit group :) > >maybe IPsec/ond or IPsec-ond. or we can have a contest, winner gets a free >2048bit D-H key? I modeled it on poised->poisson.... From owner-ipsec Wed Aug 6 08:38:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA08244 for ipsec-outgoing; Wed, 6 Aug 1997 08:37:23 -0400 (EDT) Date: Wed, 6 Aug 1997 15:54:03 +0300 (EET DST) From: Helger Lipmaa X-Sender: helger@keeks To: ipsec@tis.com Subject: ESP authentication Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, several months ago there were drafts for combined ESPs like des-md5, but they have been deleted. Probably I have missed something, but does the WG have any plans to write new ones? Or is it more correct to use AH instead (we'd like to use strong transforms like idea-cbc + hmac-sha1), to follow the (not-yet-ready) standards? Helger From owner-ipsec Wed Aug 6 08:55:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA08315 for ipsec-outgoing; Wed, 6 Aug 1997 08:49:54 -0400 (EDT) Message-Id: <3.0.3.32.19970806085524.00b5ad10@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 06 Aug 1997 08:55:24 -0400 To: "Steven M. Bellovin" From: Robert Moskowitz Subject: Re: DRAFT agenda Cc: "Theodore Y. Ts'o" , ipsec@tis.com In-Reply-To: <3.0.32.19970806133709.00710da8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 01:37 PM 8/6/97 -0400, Steven M. Bellovin wrote: > >I modeled it on poised->poisson.... Ah, but that actually represented a growth progression! :) Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Aug 6 09:44:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA08731 for ipsec-outgoing; Wed, 6 Aug 1997 09:39:55 -0400 (EDT) Message-ID: To: dharkins@cisco.com Cc: ipsec@tis.com MIME-Version: 1.0 From: Michael Bungert Subject: Comments on ISAKMP/Oakley - 04 Date: Wed, 06 Aug 97 15:48:19 PDT Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, I have the following comments/questions on the new version of ISAKMP/Oakley: 1) Main and Aggressive Modes authenticated with public key encryption - On page 4 it is stated that PFS is provided for both keys and identities, but how do the modes authenticated with public key encryption provide PFS for the identities? - The initiator optionally sends HASH(1) to tell the responder which public key was used. Why doesn't the responder send a corresponding HASH when the initiator has more than one certificate? - Both initiator and responder encrypt nonces and identities (PubKey, PubKey) in two steps. An attacker could intercept the messages and insert the own identity. Currently, I don't know how to build a successful attack based on this 'weakness', but I propose to resolve this potential weakness by encrypting the concatenation (PubKey) instead. 2) The hash values HASH_I and HASH_R for authentication are computed over SAp, ... SAp is defined as the entire body of the SA payload offered by the initiator. Is it a misprint or why is HASH_R computed over the initiator and not over the responder SA payload? Michael From owner-ipsec Wed Aug 6 10:44:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA09354 for ipsec-outgoing; Wed, 6 Aug 1997 10:39:54 -0400 (EDT) Date: Wed, 6 Aug 97 13:57:43 GMT From: "William Allen Simpson" Message-ID: <6412.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: Calling the question: derived vs. explicit IV Sender: owner-ipsec@ex.tis.com Precedence: bulk I was disappointed with the factual inaccuracies, misleading and inconsistent statements in this co-chair's posting, and had requested a correction. But, none has been forthcoming. I also take umbrage at the personal attack in the last paragraph. I believe these inaccuracies poison the straw poll. Rather than arguing, I present the following questions: > Date: Fri, 1 Aug 1997 14:27:20 -0400 > From: "Theodore Y. Ts'o" > > Date: Fri, 1 Aug 97 14:32:52 GMT > From: "William Allen Simpson" > > In favor of Derived: > > 2) Maintains complete backward compatibility with RFCs 1829 and 1851. > All shipping implementations already support the derived IV. > > Not true. It is not _complete_ backwards compatibility. RFC 1829 > support's no IV, 32-bit IV, and 64-bit IV. The compatibility you > propose only works using RFC 1829-style 32-bit IV. > Please indicate the page and line in RFC-1829 which "support's" [sic] "no IV"? Please indicate which specific shipping vendor implementations of RFC-1829 do not support 32-bit derived IV, instead supporting only some other IV, preventing this from being _complete_ backward compatibility? > In addition the handling of sequence number wrapping means that there is > yet another compatibility issue. This can be solved having the ESP > engine know something about whether the key management was manually done > or not. However, that's an abstraction violation, and it certainly adds > to the complexity of the implementation simply to have this > "compatibility". > Please indicate where RFC-1829 supports "sequence number wrapping"? Please indicate where "sequence number wrapping" is required to be handled in draft-ipsec-ciph-des-derived? Please indicate where "sequence number wrapping" is required to be handled for manual keying in ESP? BTW, there is a MUST in the Kent ESP draft that is in error, as there is also no requirement for enforcement of anti-replay. The draft is self-inconsistent. As has been noted several times on this list. Of course, _all_ SPI managers need to know what key engine was used for configuration. Otherwise, it might try to trigger the automated engine when it had been manually keyed -- resulting in a security breach -- for DNS, DHCP, and other scenarios where the key must be manually administrated to avoid the chicken-and-egg problem. How _is_ your code coming along? > 3) Will reduce administrative and operational confusion. A change to > explicit IV would "obsolete" thousands of fielded units, and create > a user support nightmare. > > No so. The fielded units do not support key management. The assumption > which I'm making here is that manual keying will continue to use RFC > 1829. Are you saying that there will be two (or more) supported domains of interpretation, one for manual keying and another for Oakley/ISAKMP? Are you saying that it will be the official policy of the IETF that RFC-1829 and its successors will advance to Internet Standard as the method to use for manual keying? > The new units that support key management will support explicit > IV's; if they choose to support manual keying for compatibility with > said "thousands of fielded units" (and the market will decide whether or > not that's necessary), they can simply support RFC 1829. It's not that > much code to support both. > Are you saying that this "much code" does not add "to the complexity of the implementation" (your objection above)? How is this a consistent position? > 4) Interoperable code will be more rapidly deployed. > > The vendors who participated in the ANX interoperability demo were using > explicit IV's. > Were all ANX vendors using explicit IVs? Were all ANX vendors interoperable with RFC-1829 manual keying? How would such vendors "more rapidly" deploy interoperable code that is not interoperable with currently fielded implementations? (I was there, I happen to know the answers already.) > 5) Any change to explicit must show GREATER cryptographic strength. > > Derived has been show to give somewhat stronger protection of the > first block than explicit. Estimates are from 2**7 to 2**16 > depending on environment. > > Not true. We will be using an MAC to protect the packets against other > attacks; this means that your posited attack of being able to modify the > first block is simply not an issue. > Is a MAC required or optional? Is a MAC required in manual-keyed scenarios between two single user hosts? Is a MAC required in manual-keyed scenarios between a single user host and a multi-user host or firewall? > As far as Bill's counting of noses of who is for and who is against, > there are a number of in his lists for which I haven't seen a clear > statement on this position, and a number of people who have stated a > position which he neglected to put on his lists. I am keeping track of > messages sent both to the list and to me privately; however, I'd ask > that folks send their preferences to the list, if at all possible. > You question my integrity? I very carefully counted every message sent to the list in the previous two months. I did not count messages sent privately. They do not count. 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 Aug 6 11:17:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA09711 for ipsec-outgoing; Wed, 6 Aug 1997 11:12:56 -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-ietf-ipsec-revised-enc-mode-01.txt Date: Wed, 06 Aug 1997 10:50:31 -0400 Message-ID: <9708061050.aa09385@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 : A revised encryption mode for ISAKMP/Oakley Author(s) : H. Krawczyk, P. Cheng, R. Canetti Filename : draft-ietf-ipsec-revised-enc-mode-01.txt Pages : 6 Date : 1997-08-05 The ISAKMP/Oakley document [HC97] describes a proposed standard for using the Oakley Key Exchange Protocol in conjunction with ISAKMP to obtain authenticated and secret keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI. The public-key encryption method of carrying out Phase 1 of the key exchange in the ISAKMP/Oakley document provides significant security advantages over the other alternatives and should be the method of choice in many implementations. Unfortunately, as currently described in [HC97] the method requires two public key encryption and decryption operations from both the Initiator and the Responder. The present document describes a small modification to this method. The resulting scheme requires only one public key encryption and decryption operation from each party, while maintaining (and even improving on) the strong security properties of the ISAKMP/Oakley public-key encryption mode. Remark: This document is NOT self-contained, it is intended as an addendum to the authentication methods defined in [HC97]. In particular, it uses notation and definitions of [HC97]. Thus, it is best read in conjunction with [HC97]. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-revised-enc-mode-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-revised-enc-mode-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-revised-enc-mode-01.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: <19970806102459.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-revised-enc-mode-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-revised-enc-mode-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970806102459.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Aug 6 11:51:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA09928 for ipsec-outgoing; Wed, 6 Aug 1997 11:48:33 -0400 (EDT) Message-Id: <199708061556.IAA05799@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Michael Bungert Cc: ipsec@tis.com Subject: Re: Comments on ISAKMP/Oakley - 04 In-Reply-To: Your message of "Wed, 06 Aug 1997 15:48:19 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Aug 1997 08:56:57 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Michael, > I have the following comments/questions on the new version of > ISAKMP/Oakley: > > 1) Main and Aggressive Modes authenticated with public key > encryption > - On page 4 it is stated that PFS is provided for both keys and > identities, but how do the modes authenticated with public key > encryption provide PFS for the identities? Authentication with public key encryption doesn't provide PFS of the identities (but it can provide PFS of keys). The draft states that PFS of identities is "provided by this protocol." It doesn't state that every possible mode and authentication combination provides PFS. If you want PFS of identities don't use public key encryption to authenticate (and don't use aggressive mode). > - The initiator optionally sends HASH(1) to tell the responder > which public key was used. > Why doesn't the responder send a corresponding HASH > when the initiator has more than one certificate? Because the responder has already decrypted the initiator's identity and will use the public key from the certificate that corresponds to this identity to encrypt his response. > - Both initiator and responder encrypt nonces and identities > (PubKey, PubKey) in two steps. > An attacker could intercept the messages and insert > the own identity. Currently, I don't know how to build a > successful attack based on this 'weakness', but I propose to > resolve this potential weakness by encrypting the concatenation > (PubKey) instead. If he inserts his own identity then he is basically just initiating a new ISAKMP request to the responder. The fact that he's preventing another party from doing likewise is separate and no protocol can prevent that. (It's basically what a firewall does, prevent packets from reaching their intended destination). The thing is, the _real_ initiator (as opposed to the new initiator who is the "attacker") would never complete the exchange. He'd be left hanging. A real attack would make each side think everything is hunky-dory but leave the keys in the attacker's hands. This isn't happening. Note that there's typo in the public key authentication with aggressive mode example: the responder replies with PubKey_i, not PubKey_r. This, a few other things (mostly spelling mistakes), will be corrected shortly. > 2) The hash values HASH_I and HASH_R for authentication are > computed over SAp, ... > SAp is defined as the entire body of the SA payload offered > by the initiator. Is it a misprint or why is HASH_R computed > over the initiator and not over the responder SA payload? Forcing the responder to hash the initiator's original offer(s) prevents a man-in-the-middle attack. Imagine you want to communicate with some entity and [insert your favorite bogeyman here] wants to evesdrop on all conversations to that entity. You could make an offer that includes strong encryption (which may be preferred) and less-than-real-strong encryption (which may be the regrettable last choice). The bogeyman can modify your offer in flight to be a single offer of the less-than-real-strong encryption which he may have experience in cracking. The entity may regrettably agree; he would've preferred your other offers but he never received them. Neither you nor the entity know this occured. By having the responder include the entire suite of offers in the authenticating hash, this attack is prevented. regards, Dan. From owner-ipsec Wed Aug 6 13:08:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA10600 for ipsec-outgoing; Wed, 6 Aug 1997 13:05:04 -0400 (EDT) Message-ID: <0171F2F8F9E5D011A4D10060B03CFB449136@scc-server3.semaphorecom.com> From: Catherine Gibson To: "'ipsec'" Subject: New SPI when renegotiate keys? Date: Wed, 6 Aug 1997 10:18:13 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk I know when ISAKMP renegotiates a new key with a remote partner that the documentation says this creates a new SA. Does this new SA have to have a different SPI than the previous one? If so, why? Thanx, CJ CJ Gibson cjgibson@semaphorecom.com Semaphore Communications Corporation Santa Clara, CA From owner-ipsec Wed Aug 6 14:10:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA11060 for ipsec-outgoing; Wed, 6 Aug 1997 14:06:34 -0400 (EDT) Message-Id: <199708061815.LAA23595@grayling.erg.sri.com> Date: Wed, 6 Aug 1997 11:15:07 -0700 From: "Fred L. Templin" To: ipsec@tis.com Cc: templin@erg.sri.com Subject: Directions for ESP and AH? Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, I'm trying to understand current directions for the ESP and AH protocols, and I've read 'draft-ietf-ipsec-doc-roadmap-01.txt' (the "IP Security Document Roadmap") but I still have a few questions: 1) The IP Security Document Roadmap cites RFC 1825 as the reference for the "Security Architecture for the Internet Protocol", but it refers to two new documents (draft-ietf-ipsec-auth-header-01.txt and *-esp-v2-00.txt) for the IP Authentication Header and IP Encapsulating Security Payload (ESP), respectively. Is the intention that these two new draft documents will eventually obsolete RFC's 1826 and 1827, respectively, which already describe these protocols? 2) If yes to the above, what sort of interoperability considerations are being made for existing reference code (such as the NRL distribution) which implement RFC 1826 and 1827? 3) Are there plans for the development of an "official IPsec reference implementation" which will supercede earlier works such as NRL? If so, who will be involved in this work? Thanks in advance for your consideration of my questions, Fred templin@erg.sri.com From owner-ipsec Wed Aug 6 14:53:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA11333 for ipsec-outgoing; Wed, 6 Aug 1997 14:51:02 -0400 (EDT) Message-Id: <3.0.3.32.19970806145439.00bf8250@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 06 Aug 1997 14:54:39 -0400 To: "Fred L. Templin" , ipsec@tis.com From: Robert Moskowitz Subject: Re: Directions for ESP and AH? Cc: templin@erg.sri.com In-Reply-To: <199708061815.LAA23595@grayling.erg.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:15 AM 8/6/97 -0700, Fred L. Templin wrote: > > 1) The IP Security Document Roadmap cites RFC 1825 as the reference for > the "Security Architecture for the Internet Protocol", but it refers > to two new documents (draft-ietf-ipsec-auth-header-01.txt and > *-esp-v2-00.txt) for the IP Authentication Header and IP Encapsulating > Security Payload (ESP), respectively. Is the intention that these two > new draft documents will eventually obsolete RFC's 1826 and 1827, > respectively, which already describe these protocols? Back in Danvers, I believe, work started on obsoleting 1826 and 1827. The drafts you mention are very very close to what will be the new RFCs. Additionally, the replacement for 1825 is draft-ietf-ipsec-arch-sec-01.txt, posted to this list on Jul 30th. > 2) If yes to the above, what sort of interoperability considerations are > being made for existing reference code (such as the NRL distribution) > which implement RFC 1826 and 1827? This is part of the debate of implicit versus explicit IV for DES. First there ARE DOI #s for 1828 and 1829, the 'implementations' for 6 and 7. So an old implementation that ONLY adds Oakley and no new transforms MAY be able to interoperate with a new implementation that not only coded the new transforms but also the old. Note however, that many vendors have no plans to implement 1828 or 1829 with Oakley, leading to a migration away from the old transforms to the new. > 3) Are there plans for the development of an "official IPsec reference > implementation" which will supercede earlier works such as NRL? If > so, who will be involved in this work? No one has officially announced such a position. I have heard some rumours about some free code, but nothing that I can repeat. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Aug 6 15:06:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA11411 for ipsec-outgoing; Wed, 6 Aug 1997 15:03:34 -0400 (EDT) Message-ID: <33E8CC8F.41C6@cs.umass.edu> Date: Wed, 06 Aug 1997 15:12:15 -0400 From: Lewis McCarthy Organization: UMass-Amherst Theoretical Computer Science Group, X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha) MIME-Version: 1.0 To: IP Security List Subject: Re: Calling the question: derived vs. explicit IV References: <6412.wsimpson@greendragon.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill Simpson writes: > Derived has been show to give somewhat stronger protection of the > first block than explicit. Estimates are from 2**7 to 2**16 > depending on environment. Ted Ts'o writes: >>> Not true. We will be using an MAC to protect the packets against >>> other attacks; this means that your posited attack of being able to >>> modify the first block is simply not an issue. Bill: > Is a MAC required or optional? Regardless of whether a cryptographic MAC is in use or not, I agree with Steve Bellovin's earlier comments that a work factor increase from 0 to 65536 is not significant. I don't think it offers any practical cryptographic reason to prefer a derived (implicit?) IV to an explicit IV. The questions about which shipping products and current implementations support which IV schemes from which documents seem to be much more important considerations here. I'm not sure how to reconcile all the conflicting claims I've seen on the list, so I'm sitting on the fence. -Lewis From owner-ipsec Wed Aug 6 15:07:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA11424 for ipsec-outgoing; Wed, 6 Aug 1997 15:05:04 -0400 (EDT) Message-Id: <199708061905.PAA11424@portal.ex.tis.com> From: Carlisle Adams To: "'ietf-pkix@tandem.com'" , "'ipsec@tis.com'" Cc: "'mmyers@verisign.com'" Subject: RE: PKCS 7 + PKCS 10 Proposal Date: Wed, 6 Aug 1997 15:00:29 -0400 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 Hi, I have a number of major concerns with the proposal that was submitted to these lists recently, along with several serious, but less critical, concerns. I'll only mention the major ones here. >---------- >From: mmyers@verisign.com[SMTP:mmyers@verisign.com] >Sent: Thursday, July 31, 1997 9:39 PM >To: ietf-pkix@tandem.com >Cc: ipsec@tis.com >Subject: PKCS 7 + PKCS 10 Proposal > >All-- > > >Back in San Jose and again in Memphis the PKIX WG expressed interest in >considering the use of PKCS 7 and PKCS 10 for PKI administrative >messaging. The draft below follows up on this topic from Memphis. > > >The question naturally emerges: How does this relate to PKIX Part 3, >considering that PKIX Part 3 accepted changes at the last IETF which >accomodate PKCS 7 and PKCS 10? > > >(Carlisle, if I've misrepresented your position, I'm sure you'll have no >reservation whatsoever in correcting the public record!) Now that I'm back in town, I will take Mike up on his generous offer! :-) >Carlisle and I today discussed the issues surrounding this question, in >the context of the draft below. We concluded it proposes a reasonable >approach towards leveraging the installed base of PKCS 7 capabilities. >To that end, I propose we consider this framework in Munich and determine >if and how it should move forward. This puts a slightly more positive spin on my position than I think is warranted. What I actually concluded was that if you wanted to take advantage of the installed base of PKCS #7 and #10, this approach was probably about the best you could do. However, it has significant disadvantages and security problems and (at best) solves a limited subset of the required functionality for limited, very specific, environments. >The authors also feel that this work merits attention within the IPSEC >Working Group, hence it cross-posting to that list. > > > >Carlisle had the following specific observations: Let me re-word that slightly: "Carlisle had the following specific reservations with respect to the usefulness of this proposed protocol:" >1. The draft continues to promote the notion that one need only have a >single key. The draft does not simply promote the notion that one need only have a single key. Rather, it fundamentally relies on that notion. [See, for example, the first sentence of Section 5.1.1.2 which says, "Because the response is encrypted with the user's public key.... This is the response to the certification request, which (being a PKCS #10 request) was signed with the user's private key. One key pair for both signing and encryption. Didn't I hear a (loud) call from the group recently saying that DSA should be mandatory for the PKIX protocols and that RSA should be optional?] The impression I get from many, many quarters is that, collectively, we have (or should have) put this issue to rest by now. Of course there are a number of systems out there that operate as single-key systems for historical and backward-compatibility reasons. However, there is no valid argument for fundamentally building in a single-key assumption in new protocols that we propose. I suspect there will be no shortage of people who oppose this if we try to promote such a limited and flawed design. >2. It provides no means to certify a D-H key. Recognizing that the WG >has received a proposal to do so using PKCS 10 constructs, there still >remains a problem of coordinating parameters between the client and the >CA. It is not a "problem of coordinating parameters". It is that trying to force-fit D-H certification into PKCS #10 requires two things: (a) it requires that the CA has a D-H certificate for this purpose; and (b) it requires that the end entity be content to use the specific parameters in the CA's D-H certificate for its own D-H key pair. Condition (a) seems like an unnecessary extra burden to place on CAs, but this is not a serious problem. Condition (b), on the other hand, seems far too limiting for a general solution. If an end entity wants to create its own key pair it should be free to create it in any way it likes, for whatever purposes it likes, and get the resulting public key certified (subject to policy, etc.). >3. It does not adequately address the subscriber bootstrapping >problem. "Does not adequately address" is a little understated. It does not address this problem at all. In other words, there is no (cryptographically secure) way for a brand-new end entity to get initialized and begin functioning in the system. I don't want to sound extremist here, but this is not a small shortcoming. What you end up with in this proposal is an infrastructure full of certificates that you can't trust. [Note that the "most secure", manual mode, where a phone call is made and hashes are read out, is prone to user error. More significantly, it does not scale: requiring CA administrators to contact end users by telephone when organizations span multiple continents, time zones, and languages will prove challenging and will almost certainly lead to (at least the occasional) use of unauthenticated certificates. Since unauthenticated certificates cannot be distinguished from properly-authenticated certificates, you end up in a situation where you can't really trust any certificate.] >4. More generally, the current draft clearly falls short of addressing >the entire set of capabilities provided by Part 3. This point is worded exactly as I would wish, except that I might have started with "More importantly, ..." >For each of these there exists a reasonable counter position. It's >tempting to rebut each, but in the interest of brevity I will address >only the last point, leaving the others to the list and Munich. I would be interested in seeing the rebuttals, but I am not optimistic that they can be made to be convincing with respect to the actual needs for general certificate management protocols. >To the last point, I would observe that the draft is intended to address >only the most essential elements of a PKI service, with the thought in >mind that additional work would be needed to expand upon these basic >services. In other words, the plan seems to be to essentially re-do everything that has already been done in the past 1-1/2 to 2 years with PKIX-3. Mike has repeatedly said to me that a lot of effort and thinking has gone into PKIX-3 to construct a secure, general set of protocols for certificate management. Does it make sense to do this all again for this new proposal (and wait another 1-1/2 to 2 years to get something that is strong enough and general enough to be useful)? My personal feeling is, "No". Ultimately, what PKIX is all about is the definition and standardization of a Public-Key Infrastructure for the Internet. The proposal given here cannot (and does not) claim to build such an infrastructure. It may provide *some* of the necessary functionality for *some* environments (although I still worry about not being able to securely initialize entities), but this limited focus is clearly inadequate for an IPKI. Considering that this work has already been done in PKIX-3, and that it is ready to go to Working Group Last Call, it seems to me that the proposal given here may be suitable as a (standardized or proprietary) protocol in some other context, but not within the stated scope of the PKIX Working Group. -------------------------------------------- Carlisle Adams Entrust Technologies cadams@entrust.com -------------------------------------------- From owner-ipsec Wed Aug 6 16:00:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA11673 for ipsec-outgoing; Wed, 6 Aug 1997 15:55:33 -0400 (EDT) Message-Id: <3.0.3.32.19970806155031.00b3c6d0@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 06 Aug 1997 15:50:31 -0400 To: Carlisle Adams , "'ietf-pkix@tandem.com'" , "'ipsec@tis.com'" From: Robert Moskowitz Subject: RE: PKCS 7 + PKCS 10 Proposal Cc: "'mmyers@verisign.com'" In-Reply-To: <199708061905.PAA11424@portal.ex.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 03:00 PM 8/6/97 -0400, Carlisle Adams wrote: > >I have a number of major concerns with the proposal that was submitted >to these lists recently, along with several serious, but less critical, >concerns. I'll only mention the major ones here. Thank you, Carlisle for this analysis. > >The draft does not simply promote the notion that one need only have a >single key. Rather, it fundamentally relies on that notion. [See, for >example, the first sentence of Section 5.1.1.2 which says, "Because the >response is encrypted with the user's public key.... This is the >response to the certification request, which (being a PKCS #10 request) >was signed with the user's private key. One key pair for both signing >and encryption. Didn't I hear a (loud) call from the group recently >saying that DSA should be mandatory for the PKIX protocols and that RSA >should be optional?] In an environment where there is operationally only a need for an identity key (Oakley RSA Sig), is putting a requirement that there be an encrypting key to be used only for the 'registering' of the identity key valuable? Of course, this focuses my mind on the construct of Oakley RSA encrypt and the new Oakley enhanced RSA encrypt. Is its design based on a single key-pair RSA environment? And if so, what would a duo-key-pair RSA encrypt exchange look like? BTW, for systems that have an operational need for public key encryption (EMail as one), my position is that duo-key-pair is the right model, and single key-pair is fatally, legally flawed. >>2. It provides no means to certify a D-H key. Recognizing that the WG >>has received a proposal to do so using PKCS 10 constructs, there still >>remains a problem of coordinating parameters between the client and the >>CA. This is facinating and needs to be addressed. When will it impact IPsec? >>3. It does not adequately address the subscriber bootstrapping >>problem. > >"Does not adequately address" is a little understated. It does not >address this problem at all. In other words, there is no >(cryptographically secure) way for a brand-new end entity to get Important for scaling, as you point out. Better than current method of sending Email. Is leap-frogging possible within 3 months? >an IPKI. Considering that this work has already been done in PKIX-3, >and that it is ready to go to Working Group Last Call, it seems to me >that the proposal given here may be suitable as a (standardized or >proprietary) protocol in some other context, but not within the stated >scope of the PKIX Working Group. Is PKIX-3 (showing my lack of energy to cover it too) codeable? Are there any implimentations out there that we can see in action? When can we schedule an interoperablity workshop (is one needed?)? I've got some cars to build. Thank you all for the on-going education. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Aug 6 16:57:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA12029 for ipsec-outgoing; Wed, 6 Aug 1997 16:55:03 -0400 (EDT) From: Dan.McDonald@eng.sun.com (Dan McDonald) Message-Id: <199708062103.OAA20552@kebe.eng.sun.com> Subject: Corner-case question To: ipsec@tis.com Date: Wed, 6 Aug 1997 14:03:58 -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 Hello folks! I've a specific question about a corner-case involving router-to-host tunnels. Consider the following: A ==(IPsec through the internet)====== R ---------- Say host A is a host that reaches the protected network via an IPsec tunnel to router R. My question is: Is it possible/practical for R to have a single IP address, and the only way it is being "a router" is that it forwards packets tunnelled to it to its peers inside the protected network? (Remember, a router is a machine that forwards packets. That's the extent of the definition.) If the answer to my question is yes, there's a small can of worms that opens up regarding the routing tables on R (that exercise is left to the reader for now). If the answer to my question is no, there's a smaller policy question. I'll assume the answer to my question is no, so I'll pose the smaller policy question: Policy question: Assume R has two addresses, one with the prefix of the protected network (Rp), the other with a prefix that is reachable from the Internet (Ri). If A talks sends datagrams to Ri (as a destination), do they have to be tunnelled? Or do we assume R is smart enough to know that packets from Ri are to be trusted less than packets from Rp. I suspect we should assume that R is smart enough to know the difference between the two interfaces. Otherwise, besides complicating R's life, A's life becomes VERY complicated, if A is a machine that reaches the rest of the Internet (including Ri) through a default route. THIS can of worms is a similar one to the can of worms I left as an exercise to the reader. (BTW, if A wants to talk to R securely, it can either talk to Rp, or it can set up per-session IPsec to Ri.) I suspect my previous suspicions, NO (or at least not practical) to the first question, and NO (packets coming in on Ri can be clear, can't be trusted by themselves), are the "correct" answers. If not, we've a small can of worms we need to discuss involving routing and/or invasive policy. I think the ANX crowd may have thought about these, given Bob's penchant for laptops on the road. Perhaps Bob's VPN draft addresses this problem, but I haven't read that yet. Dan From owner-ipsec Wed Aug 6 17:05:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA12114 for ipsec-outgoing; Wed, 6 Aug 1997 17:04:02 -0400 (EDT) From: Dan.McDonald@eng.sun.com (Dan McDonald) Message-Id: <199708062112.OAA20585@kebe.eng.sun.com> Subject: Re: New SPI when renegotiate keys? To: cjgibson@semaphorecom.com (Catherine Gibson) Date: Wed, 6 Aug 1997 14:12:01 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <0171F2F8F9E5D011A4D10060B03CFB449136@scc-server3.semaphorecom.com> from "Catherine Gibson" at Aug 6, 97 10:18:13 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 know when ISAKMP renegotiates a new key with a remote partner that the > documentation says this creates a new SA. Does this new SA have to have > a different SPI than the previous one? I believe so. And if I'm wrong, I'd like to see my reasons for why countered. > If so, why? Because IP has no delivery guarantees, and changing the keys on an existing SA will scramble packets that arrive AFTER the rekeying, but were encrypted/authenticated BEFORE the rekeying. Hey, it's IP, anything can happen. Consider the following SA: A -> B, AH HMAC-MD5, SPI = 0x84001100, key = So I receive some packets for SA {B, 0x84001100}. Suddenly I perform an ISAKMP regnegotiation and change the key from to . But say before that happened, a packet left A. Let's say that the packet got caught in a routing loop while the ISAKMP exchange took place. Suddenly this old packet arrives at B, and the SA lookup succeeds. But now, the key is different so it won't authenticate. Dan From owner-ipsec Wed Aug 6 17:18:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA12190 for ipsec-outgoing; Wed, 6 Aug 1997 17:18:34 -0400 (EDT) Message-Id: <199708062126.RAA01084@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: Dan.McDonald@eng.sun.com (Dan McDonald) Cc: cjgibson@semaphorecom.com (Catherine Gibson), ipsec@tis.com Subject: Re: New SPI when renegotiate keys? In-Reply-To: Dan.McDonald's message of Wed, 06 Aug 1997 14:12:01 -0700. <199708062112.OAA20585@kebe.eng.sun.com> Date: Wed, 06 Aug 1997 17:26:40 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > > If so, why? > > Because IP has no delivery guarantees, and changing the keys on an existing > SA will scramble packets that arrive AFTER the rekeying, but were > encrypted/authenticated BEFORE the rekeying. Hey, it's IP, anything can > happen. > > Consider the following SA: > > A -> B, AH HMAC-MD5, SPI = 0x84001100, key = > > So I receive some packets for SA {B, 0x84001100}. Suddenly I perform an > ISAKMP regnegotiation and change the key from to . > > But say before that happened, a packet left A. Let's say that the packet got > caught in a routing loop while the ISAKMP exchange took place. Suddenly this > old packet arrives at B, and the SA lookup succeeds. But now, the key is > different so it won't authenticate. I agree 100% with this analysis.. In addition, I believe that most if not all significant properties of SA's need to be "immutable".. because any changes to SA's might be reordered around traffic to/from them.. - Bill From owner-ipsec Wed Aug 6 17:26:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA12253 for ipsec-outgoing; Wed, 6 Aug 1997 17:26:32 -0400 (EDT) Message-Id: <199708062126.RAA12253@portal.ex.tis.com> Date: Wed, 06 Aug 1997 14:38:10 +0100 From: Peter Williams X-Mailer: Mozilla 4.01 [en] (WinNT; U) MIME-Version: 1.0 To: Carlisle Adams CC: "'ietf-pkix@tandem.com'" , "'ipsec@tis.com'" Subject: Re: PKCS 7 + PKCS 10 Proposal X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk Carlisle Adams wrote: > The draft does not simply promote the notion that one need only have > a > single key. Rather, it fundamentally relies on that notion. [See, > for > example, the first sentence of Section 5.1.1.2 which says, "Because > the > response is encrypted with the user's public key.... This is the > response to the certification request, which (being a PKCS #10 > request) > was signed with the user's private key. One key pair for both signing > > and encryption. Didn't I hear a (loud) call from the group recently > saying that DSA should be mandatory for the PKIX protocols and that > RSA > should be optional?] > > The impression I get from many, many quarters is that, collectively, > we > have (or should have) put this issue to rest by now. Of course there > are a number of systems out there that operate as single-key systems > for > historical and backward-compatibility reasons. However, there is no > valid argument for fundamentally building in a single-key assumption > in > new protocols that we propose. I suspect there will be no shortage of > > people who oppose this if we try to promote such a limited and flawed > design. Im a little annoyed (a mild IETF level of rebuke!) as you know there is no such intent, as evidenced by your own companies actions. When we specified the S/MIME profile of PKCS7 ,we specifically decided that dual cert models (often proposed by Entrust) should not be excluded. To this end, Entrust endorsed PKCS7, knowing full well the protocol allows dual-cert solutions. I can point folks to your website for product information, if you like. When we specified the SET profile of PKCS7 we specifically decided that dual cert models (often proposed by Entrust) should not be excluded.... i When we specified the PKIX profile of PKCS7 to refine the options provided in PKIX-1 we specifically decided that dual cert models (often proposed by Entrust) ... When we established the PKIX-1 profile, we all specifically allowed operational management domains to choose how many certs and keys they want to administer. PKIX WG scope endorsed RFC 1422 ( a single key design) and one must not forget this assumption of need to enable domains to do as they wish. S/MIME is working currently fine with some domains having two keys, other having one key. Lets users choose freely, and without pressure. Anything is better than everyone being forced to buy a product from a single vendor, or developers being forced to buy the same toolkit, or be subject to a trademark regime! Even RSA does not have any of those properties! From owner-ipsec Wed Aug 6 18:14:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA12547 for ipsec-outgoing; Wed, 6 Aug 1997 18:12:35 -0400 (EDT) Message-Id: <199708062217.SAA13669@coredump.cis.upenn.edu> To: Dan.McDonald@eng.sun.com (Dan McDonald) cc: ipsec@tis.com Subject: Re: Corner-case question In-reply-to: Your message of "Wed, 06 Aug 1997 14:03:58 PDT." <199708062103.OAA20552@kebe.eng.sun.com> Date: Wed, 06 Aug 1997 18:17:29 EDT From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In message <199708062103.OAA20552@kebe.eng.sun.com>, Dan McDonald writes: > > A ==(IPsec through the internet)====== R ---------- > > and the only way it is being "a router" is that it forwards > packets tunnelled to it to its peers inside the protected > network? (Remember, a router is a machine that forwards > packets. That's the extent of the definition.) If you mean technologically possible, it is; i've been doing this for quite a while in fact. R is my workstation in the lab and A is my laptop at home. The only difference is that the protected network (the lab net) is not all that protected anyway. >If the answer to my question is yes, there's a small can of worms that opens >up regarding the routing tables on R (that exercise is left to the reader for >now). Not sure what the problem you're refering to is; if it's how you manage the routing tables of the hosts in the protected net, read bellow. If it's not that, then please explain. I used ARP to solve the problem i know; the only change i had to do to the workstation was to suppress ICMP Redirects if the destination address in the packet is one for which it advertised an ARP entry. That patch is rather trivial (assuming a BSD derived net stack). Of course, what i am doing might be a bit different from what you have in mind. - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBM+j3+L0pBjh2h1kFAQEx9gP+KIw9BHx0+Y4pL2/b21oJPAEUPDxPKANc ABnpDrxBc07A2GN/FzVABTTn4Y+N82SLPPXsogNtHuDrb7tzqGTMFlflN7inGEJJ 9DJjI1CmGpzn2EAK2nmr9zURvytJskxwDtAbY+vZlzUotQ1UiAG1y1Chp1moji2d skySk3Tojrg= =js1c -----END PGP SIGNATURE----- From owner-ipsec Wed Aug 6 18:34:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA12685 for ipsec-outgoing; Wed, 6 Aug 1997 18:33:04 -0400 (EDT) From: Dan.McDonald@eng.sun.com (Dan McDonald) Message-Id: <199708062241.PAA20666@kebe.eng.sun.com> Subject: Re: Corner-case question To: ben@Ascend.COM Date: Wed, 6 Aug 1997 15:41:57 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <199708062132.RAA28821@carp.morningstar.com> from "Ben Rogers" at Aug 6, 97 05:32:34 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 > Are you having problems with a specific implementation not being flexible > enough to handle this? It's not a question of flexibility, it's a question of performing what are a TON of gyrations to handle a corner case. Lemme spell it out. Let's go back to my picture: > > A ==(IPsec through the internet)====== R ---------- Let's assume that R has one IP address. Let's look at what we want to accomplish: R recieves a packet: src=B, dst=A, next-hdr=TCP R wants to transmit: src=R, dst=A, next-hdr=ESP So how do I get from what I receive to what I transmit? Let's look at the different policy approaches: If I have per-route policy, I have routing tables that look like: Dest interface gw properties ==== ========= == ========== Int. Network le0 int. R1 gateway My subnet le0 link on-link default le0 int. R2 gateway A le0 int. R2 tunnel-mode to A, gateway So I receive the B->A packet, I look up its route, and then tunnel it. I now have the R->A packet. I look up its route, and then tunnel it. I now have the R->A packet.... So a naive implementaiton will loop. Let's add some smarts. How 'bout if the source address is mine, then I don't tunnel. Okay, this means if I talk to A, I talk to A in the clear. So what about the bad guy inside my net who sends a cleartext packet to A by changing the source address to R? It may be only one datagram, and the returning packets will go to R and be dumped, etc., but one forged datagram coming from outside could be a problem. Okay, so I check that it wasn't recieved off the wire.... The same can be said for checking policy before routing lookups (which means two routing lookups more-or-less.) I didn't say it was tough to figure out, what I did say was that it's a can of worms. The above checking is long and painful, and will slow things down. Perhaps it's the price I must pay for total security. If that's the case, then that's a legitimate answer to my questions. Dan From owner-ipsec Wed Aug 6 19:00:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA12801 for ipsec-outgoing; Wed, 6 Aug 1997 18:58:33 -0400 (EDT) From: Dan.McDonald@eng.sun.com (Dan McDonald) Message-Id: <199708062307.QAA20742@kebe.eng.sun.com> Subject: Re: Corner-case question To: ben@Ascend.COM Date: Wed, 6 Aug 1997 16:07:10 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <199708062251.SAA29503@carp.morningstar.com> from "Ben Rogers" at Aug 6, 97 06:51:54 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 > > If I have per-route policy, I have routing tables that look like: > ^^^^^^^^^^^^^^^^ -- read "specific implementation" Ahhh, okay. But I did say the same problem could occur otherwise. Anyway... > If you allow any machines outside your network to contact your > encrytping gateway without security, how can you claim to have any > security at all (much less total security)? Apart from the obvious bypass required for key mgmt., that encrypting gateway *may* serve many purposes. It may be the small company's web server, DNS server, anonymous FTP drop point, AND the encrypting firewall. That machine can be contacted in the clear (i.e. as a host), but to get to anything ELSE on that net, I have to have the inbound packets be secured. That's not unreasonable to expect. I also specifically said (and if I didn't, I apologize) that it's a single-address machine for my example, therefore it has ONE point of network attachment. To have ONE point of attachment means I'd have to tell the router that goes to the outside that for my internal network all inbound packets go through my box. It's a bit of a convoluted example, but I think my question has been answered satisfactorily. Dan From owner-ipsec Wed Aug 6 20:34:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA13383 for ipsec-outgoing; Wed, 6 Aug 1997 20:33:04 -0400 (EDT) Date: Wed, 6 Aug 1997 17:38:31 -0700 (PDT) From: Vipul Gupta Reply-To: Vipul Gupta Subject: Re: Corner-case question To: ben@Ascend.COM, Dan.McDonald@eng.sun.com Cc: ipsec@tis.com, Vipul.Gupta@eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: eMS+oKbUdHXjzBSQn/inIA== X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Dan.McDonald@Eng (Dan McDonald) > Let's go back to my picture: > > > > A ==(IPsec through the internet)====== R ---------- > > Let's assume that R has one IP address. Let's look at what we want to > accomplish: > > R recieves a packet: > > src=B, dst=A, next-hdr=TCP > > R wants to transmit: > > src=R, dst=A, next-hdr=ESP > > So how do I get from what I receive to what I transmit? Let's look at the > different policy approaches: > > If I have per-route policy, I have routing tables that look like: > > Dest interface gw properties > ==== ========= == ========== > Int. Network le0 int. R1 gateway > My subnet le0 link on-link > default le0 int. R2 gateway > A le0 int. R2 tunnel-mode to A, gateway > > So I receive the B->A packet, I look up its route, and then tunnel it. I now > have the R->A packet. I look up its route, and then tunnel it. I now have > the R->A packet.... So a naive implementaiton will loop. Let's add some > smarts. How 'bout if the source address is mine, then I don't tunnel. Okay, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > this means if I talk to A, I talk to A in the clear. So what about the bad > guy inside my net who sends a cleartext packet to A by changing the source > address to R? It may be only one datagram, and the returning packets will go > to R and be dumped, etc., but one forged datagram coming from outside could > be a problem. Okay, so I check that it wasn't recieved off the wire.... Would it help to modify the rule as follows: if the source address is mine *and* the packet has already been processed by IPSEC then don't tunnel again - vipul From owner-ipsec Wed Aug 6 20:44:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA13484 for ipsec-outgoing; Wed, 6 Aug 1997 20:44:34 -0400 (EDT) Message-Id: <3.0.1.32.19970806203001.008815e0@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 06 Aug 1997 20:30:01 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: draft references in roadmap In-Reply-To: <3.0.3.32.19970806145439.00bf8250@dilbert.is.chrysler.com> References: <199708061815.LAA23595@grayling.erg.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 02:54 PM 8/6/97 -0400, you wrote: >At 11:15 AM 8/6/97 -0700, Fred L. Templin wrote: >> >> 1) The IP Security Document Roadmap cites RFC 1825 as the reference for >> the "Security Architecture for the Internet Protocol", but it refers >> to two new documents (draft-ietf-ipsec-auth-header-01.txt and >> *-esp-v2-00.txt) for the IP Authentication Header and IP Encapsulating >> Security Payload (ESP), respectively. Is the intention that these two >> new draft documents will eventually obsolete RFC's 1826 and 1827, >> respectively, which already describe these protocols? Draft construction rules require that only RFC's, and NOT other drafts, be mentioned in references. That is why we used the device of adding "acknowledgements" to get the draft names out there. Some thought this would not look terribly clear. Now I guess you see why :-) From owner-ipsec Wed Aug 6 20:59:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA13597 for ipsec-outgoing; Wed, 6 Aug 1997 20:59:03 -0400 (EDT) Date: Thu, 7 Aug 97 00:56:10 GMT Daylight Time From: Ran Atkinson Subject: Re: Directions for ESP and AH? To: "Fred L. Templin" , ipsec@tis.com Cc: templin@erg.sri.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199708061815.LAA23595@grayling.erg.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Fred, While I can't (and don't) speak for the current NRL gang, there is still active IPsec development underway at NRL and I anticipate ongoing releases from NRL for the next while. I would not be surprised to see a future version of the NRL code support the new transforms (once those become stable and appear in RFC form). I'm also aware of at least 2 independent IPsec efforts for Linux. A lot of developers are waiting for the "new" transform specs to appear as RFCs before starting serious coding on them. That said, there is no requirement in the IETF for a reference implementation and the existing NRL code, while useful for some folks, is NOT the only freely distributable implementation out there. Ran rja@inet.org From owner-ipsec Wed Aug 6 21:59:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA13966 for ipsec-outgoing; Wed, 6 Aug 1997 21:58:36 -0400 (EDT) Date: Thu, 7 Aug 97 01:23:07 GMT Daylight Time From: Ran Atkinson Subject: Explicit IV vs. Implicit IV To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk All, I believe that an explicit IV is the better approach for use with ESP. I've read and considered the arguments and think explicit IV is generally preferable. One argument I find sufficient: I know of several confidentiality algorithms that _require_ that explicit IVs be used. I don't recall any confidentiality algorithm that _requires_ an "implicit" IV. The ability to support any algorithm with standard, default format, ESP is a sufficient argument, IMHO. Algorithm-independence of AH and ESP formats was always a clear design goal for IPsec, which also speaks to this argument. Note that the other arguments in aggregate independently persuade me to prefer that the default format for ESP use an explicit IV. IMHO, Ran rja@inet.org From owner-ipsec Thu Aug 7 06:42:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA16570 for ipsec-outgoing; Thu, 7 Aug 1997 06:40:31 -0400 (EDT) Date: Wed, 6 Aug 1997 17:32:34 -0400 (EDT) Message-Id: <199708062132.RAA28821@carp.morningstar.com> From: Ben Rogers To: Dan.McDonald@eng.sun.com (Dan McDonald) Cc: ipsec@tis.com Subject: Corner-case question In-Reply-To: <199708062103.OAA20552@kebe.eng.sun.com> References: <199708062103.OAA20552@kebe.eng.sun.com> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan McDonald writes: > Hello folks! > > I've a specific question about a corner-case involving router-to-host > tunnels. Consider the following: > > A ==(IPsec through the internet)====== R ---------- > > Say host A is a host that reaches the protected network via an IPsec tunnel > to router R. > > My question is: Is it possible/practical for R to have a single IP address, > and the only way it is being "a router" is that it forwards > packets tunnelled to it to its peers inside the protected > network? (Remember, a router is a machine that forwards > packets. That's the extent of the definition.) > > If the answer to my question is yes, there's a small can of worms that opens > up regarding the routing tables on R (that exercise is left to the reader for > now). This reader seems to be too ignorant to figure this one out. Are you having problems with a specific implementation not being flexible enough to handle this? ben From owner-ipsec Thu Aug 7 06:48:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA16652 for ipsec-outgoing; Thu, 7 Aug 1997 06:48:01 -0400 (EDT) Message-Id: <199708071048.GAA16652@portal.ex.tis.com> From: Carlisle Adams To: "'Peter Williams'" Cc: "'ietf-pkix@tandem.com'" , "'ipsec@tis.com'" Subject: RE: PKCS 7 + PKCS 10 Proposal Date: Wed, 6 Aug 1997 17:57:57 -0400 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 Peter, >---------- >From: Peter Williams[SMTP:peter@verisign.com] >Sent: Wednesday, August 06, 1997 9:38 AM >To: Carlisle Adams >Cc: 'ietf-pkix@tandem.com'; 'ipsec@tis.com' >Subject: Re: PKCS 7 + PKCS 10 Proposal > >Carlisle Adams wrote: > >> The draft does not simply promote the notion that one need only have a >> single key. Rather, it fundamentally relies on that notion. [See, for >> example, the first sentence of Section 5.1.1.2 which says, "Because the >> response is encrypted with the user's public key.... This is the >> response to the certification request, which (being a PKCS #10 request) >> was signed with the user's private key. One key pair for both signing >> and encryption. > >Im a little annoyed (a mild IETF level of rebuke!) as you >know there is no such intent, as evidenced by your own companies >actions. > >When we specified the S/MIME profile of PKCS7 ,we specifically >decided that dual cert models (often proposed by Entrust) should >not be excluded. To this end, Entrust endorsed PKCS7, knowing >full well the protocol allows dual-cert solutions. I can point >folks to your website for product information, if you like. Since the last thing anyone would want to do is to annoy you, let me highlight what I said (and what I did not say). I did *not* say that PKCS #7 excludes the dual-key model. We all know that it allows single-key and dual-key models. What I *did* say, however, was that this specific proposal fundamentally relies on a single-key model, as evidenced quite clearly by the quote I gave from Section 5.1.1.2. Yes, this proposal is based on PKCS #7, but it does not allow the richness of PKCS #7 in this respect because it assumes that a single key pair can be used for signing and encryption. Can we both agree with this without either party getting annoyed? -------------------------------------------- Carlisle Adams Entrust Technologies cadams@entrust.com -------------------------------------------- P.S., Any time you feel compelled to point folks to our web site for product information, feel free to go ahead and do so. From owner-ipsec Thu Aug 7 06:52:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA16726 for ipsec-outgoing; Thu, 7 Aug 1997 06:52:01 -0400 (EDT) Date: Thu, 7 Aug 1997 06:52:01 -0400 (EDT) Message-Id: <199708071052.GAA16726@portal.ex.tis.com> From: Ben Rogers To: Dan.McDonald@eng.sun.com (Dan McDonald) Cc: ben@Ascend.COM, ipsec@tis.com Subject: Re: Corner-case question In-Reply-To: <199708062241.PAA20666@kebe.eng.sun.com> References: <199708062132.RAA28821@carp.morningstar.com> <199708062241.PAA20666@kebe.eng.sun.com> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan McDonald writes: > > Are you having problems with a specific implementation not being flexible > > enough to handle this? > > It's not a question of flexibility, it's a question of performing what are a > TON of gyrations to handle a corner case. Lemme spell it out. > If I have per-route policy, I have routing tables that look like: ^^^^^^^^^^^^^^^^ -- read "specific implementation" > Let's add some > smarts. How 'bout if the source address is mine, then I don't tunnel. Okay, > this means if I talk to A, I talk to A in the clear. > I didn't say it was tough to figure out, what I did say was that it's a can > of worms. The above checking is long and painful, and will slow things down. > Perhaps it's the price I must pay for total security. If that's the case, > then that's a legitimate answer to my questions. If you allow any machines outside your network to contact your encrytping gateway without security, how can you claim to have any security at all (much less total security)? It seems if you require that communication to be encrypted as well, you'd be able to get the job done with fewer hoops to jump through, and you'd protect yourself more nearly adequately. ben From owner-ipsec Thu Aug 7 06:53:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA16749 for ipsec-outgoing; Thu, 7 Aug 1997 06:53:30 -0400 (EDT) Date: Thu, 7 Aug 1997 06:53:30 -0400 (EDT) Message-Id: <199708071053.GAA16749@portal.ex.tis.com> From: Ben Rogers To: Dan.McDonald@eng.sun.com (Dan McDonald) Cc: ipsec@tis.com Subject: Re: Corner-case question In-Reply-To: <199708062307.QAA20742@kebe.eng.sun.com> References: <199708062251.SAA29503@carp.morningstar.com> <199708062307.QAA20742@kebe.eng.sun.com> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan McDonald writes: > > > If I have per-route policy, I have routing tables that look like: > > ^^^^^^^^^^^^^^^^ -- read "specific implementation" > > Ahhh, okay. But I did say the same problem could occur otherwise. > Anyway... > > > If you allow any machines outside your network to contact your > > encrytping gateway without security, how can you claim to have any > > security at all (much less total security)? > > Apart from the obvious bypass required for key mgmt., that encrypting gateway > *may* serve many purposes. It may be the small company's web server, DNS > server, anonymous FTP drop point, AND the encrypting firewall. That machine > can be contacted in the clear (i.e. as a host), but to get to anything ELSE > on that net, I have to have the inbound packets be secured. That's not > unreasonable to expect. Ahh... Sounds like you're beginning to do the work of a firewall, so I have no problems in thinking that you will need to jump through some extra hoops and/or have a little more bulky implementation. Think of the extra code as your firewall code... :) > I also specifically said (and if I didn't, I apologize) that it's a > single-address machine for my example, therefore it has ONE point of network > attachment. To have ONE point of attachment means I'd have to tell the > router that goes to the outside that for my internal network all inbound > packets go through my box. Hmm... Again, this makes a bit more sense. I'm used to the one address/multiple interface paradigm that many routers support. In that case, where packets are forced to go through the box with no strange routing, then you really have no problems. But, if your interfaces need to be one-to-one with IP addresses, then its a whole different question. ben From owner-ipsec Thu Aug 7 11:00:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA18833 for ipsec-outgoing; Thu, 7 Aug 1997 10:57:35 -0400 (EDT) Message-Id: <3.0.3.32.19970807110426.00ad37d0@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 07 Aug 1997 11:04:26 -0400 To: Dan.McDonald@eng.sun.com (Dan McDonald), ipsec@tis.com From: Robert Moskowitz Subject: Re: Corner-case question In-Reply-To: <199708062103.OAA20552@kebe.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 02:03 PM 8/6/97 -0700, Dan McDonald wrote: > >I've a specific question about a corner-case involving router-to-host >tunnels. Consider the following: > > A ==(IPsec through the internet)====== R ---------- > >Say host A is a host that reaches the protected network via an IPsec tunnel >to router R. > >My question is: Is it possible/practical for R to have a single IP address, > and the only way it is being "a router" is that it forwards > packets tunnelled to it to its peers inside the protected > network? (Remember, a router is a machine that forwards > packets. That's the extent of the definition.) > As you all know, I have paced many a hall pondering senarios like this. My VPN draft does not seem to be coming out, so I will post it to this list soon if I do not get it into a URL... Meanwhile the answer is a guarded YES. Provided: A can resolve all DNS names in the protected network to addresses in that network. A 'knows' that it MUST set up an IPsec tunnel through R for those addresses. Hosts on the protected network will route packets destine to A via R. This can be done with one tunnel between A and R or a tunnel per host on the protected network (I perfer the latter). It works as follows: A does a lookup on host.foo.com and gets a valid A record. A policy on A says, "to this address (range) you must establish an IPsec tunnel to R and push the packets through it." A establishes a tunnel to R and (source-destination of A and R) and sends packets through the tunnel with source-destination of A and host. R has no trouble delivering the un-tunneled packets to the host. The host responds back to A, and these packets arrive at R. R observes that the destination is A, and it has an SA to A, so it stuffs the packet within the tunnel. Done. Now one way to automate the policy is with my proposed TX record. Given the following DNS entries: host.foo.com IN A 209.69.80.34 *.foo.com IN TX r.foo.com r.foo.com IN A 209.69.80.33 The lookup on host.foo.com returns both the A and the TX record (we hope!). The TX record results in a second lookup for r.foo.com, and the rest follows. Note that DNSSEC MUST be used to protect these records.... Does this work for you? Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Thu Aug 7 11:10:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA18914 for ipsec-outgoing; Thu, 7 Aug 1997 11:10:32 -0400 (EDT) Message-Id: <3.0.3.32.19970807111722.00ac0190@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 07 Aug 1997 11:17:22 -0400 To: Dan.McDonald@eng.sun.com (Dan McDonald), ipsec@tis.com From: Robert Moskowitz Subject: Re: Corner-case question In-Reply-To: <3.0.3.32.19970807110426.00ad37d0@dilbert.is.chrysler.com> References: <199708062103.OAA20552@kebe.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:04 AM 8/7/97 -0400, Robert Moskowitz wrote: > >Provided: > >A can resolve all DNS names in the protected network to addresses in that >network. > >A 'knows' that it MUST set up an IPsec tunnel through R for those addresses. BTW, note that R need not be the route of a regular packet from A to Host, just must be for Host to A! ARGH!!!! Chorkle. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Thu Aug 7 12:20:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA19535 for ipsec-outgoing; Thu, 7 Aug 1997 12:20:03 -0400 (EDT) Date: Thu, 7 Aug 1997 12:28:02 -0400 Message-Id: <199708071628.MAA27780@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "William Allen Simpson" Cc: ipsec@tis.com In-Reply-To: William Allen Simpson's message of Wed, 6 Aug 97 13:57:43 GMT, <6412.wsimpson@greendragon.com> Subject: Re: Calling the question: derived vs. explicit IV Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Wed, 6 Aug 97 13:57:43 GMT From: "William Allen Simpson" > In addition the handling of sequence number wrapping means that there is > yet another compatibility issue. This can be solved having the ESP > engine know something about whether the key management was manually done > or not. However, that's an abstraction violation, and it certainly adds > to the complexity of the implementation simply to have this > "compatibility". Please indicate where RFC-1829 supports "sequence number wrapping"? RFC-1829 doesn't. However, new implementations --- the ones which we are trying to get out the door and shipping quickly --- will have to deal with sequence number wrapping if we're worried about RFC-1829 compatibility, since for manual keying your draft specifies that the sequence number starts at some random point (and wraps), whereas for automatic keying, the sequence number starts at zero, and doesn't wrap. > No so. The fielded units do not support key management. The assumption > which I'm making here is that manual keying will continue to use RFC > 1829. Are you saying that there will be two (or more) supported domains of interpretation, one for manual keying and another for Oakley/ISAKMP? DOI is a ISAKMP term. As such, it doesn't make sense for manual keying. Are you saying that it will be the official policy of the IETF that RFC-1829 and its successors will advance to Internet Standard as the method to use for manual keying? That depends on whether there is any vendor and market interest in manual keying and backwards compatibility with the old boxes. I have been told that most vendors what to get away from manual keying as fast as they can. If there's no interest in manual keying, then we can let RFC-1829 either (a) not advance, or (b) go to historic. That however, is not a matter that this working group needs to decide now. > 5) Any change to explicit must show GREATER cryptographic strength. > > Derived has been show to give somewhat stronger protection of the > first block than explicit. Estimates are from 2**7 to 2**16 > depending on environment. > > Not true. We will be using an MAC to protect the packets against other > attacks; this means that your posited attack of being able to modify the > first block is simply not an issue. Is a MAC required or optional? The MAC is optional; however, if it isn't there, then obviously data integrity wasn't required or important. If data integrity is a requirement, then you should be using a MAC. - Ted From owner-ipsec Thu Aug 7 16:39:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA21358 for ipsec-outgoing; Thu, 7 Aug 1997 16:38:10 -0400 (EDT) Message-Id: <3.0.1.32.19970807164546.007ccaa0@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 07 Aug 1997 16:45:46 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: Moskowitz/Doraswamy VPN Draft URL Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk It's on the server: From owner-ipsec Thu Aug 7 16:51:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA21441 for ipsec-outgoing; Thu, 7 Aug 1997 16:51:06 -0400 (EDT) Message-Id: <3.0.3.32.19970807165825.00984c70@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 07 Aug 1997 16:58:25 -0400 To: Rodney Thayer , ipsec@tis.com From: Robert Moskowitz Subject: Re: Moskowitz/Doraswamy VPN Draft URL In-Reply-To: <3.0.1.32.19970807164546.007ccaa0@pop3.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 04:45 PM 8/7/97 -0400, Rodney Thayer wrote: >It's on the server: > >-vpn-00.txt> > And I am already writing a whole VPN architecture section. Maybe if I offload my brain, this headache will go away :) All of you have a successful time in Munich. Somehow or other I will get on the Mbone and join you friday that way..... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Thu Aug 7 18:25:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA21951 for ipsec-outgoing; Thu, 7 Aug 1997 18:23:26 -0400 (EDT) Date: Thu, 7 Aug 97 21:40:03 GMT From: "William Allen Simpson" Message-ID: <6424.wsimpson@greendragon.com> To: ipsec@tis.com Subject: Re: Calling the question: derived vs. explicit IV Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: "Theodore Y. Ts'o" > Please indicate where RFC-1829 supports "sequence number wrapping"? > > RFC-1829 doesn't. However, new implementations --- the ones which we > are trying to get out the door and shipping quickly --- will have to > deal with sequence number wrapping if we're worried about RFC-1829 > compatibility, since for manual keying your draft specifies that the > sequence number starts at some random point (and wraps), whereas for > automatic keying, the sequence number starts at zero, and doesn't wrap. > I don't understand. Is there some assumption in your answer that sequence numbers starting at one (not zero) would somehow never wrap for manual keying? Exactly what protocol mechanism is proposed for manual keying to prevent this from happening? > > No so. The fielded units do not support key management. The assumption > > which I'm making here is that manual keying will continue to use RFC > > 1829. > > Are you saying that there will be two (or more) supported domains of > interpretation, one for manual keying and another for Oakley/ISAKMP? > > DOI is a ISAKMP term. As such, it doesn't make sense for manual keying. > OK, "universes" is the term used earlier by Moskowitz. And your next answer appears to indicate that yes, when there is vendor and market interest in manual keying, it will be a different "universe", and it will continue to be compatible with RFC-1829 and -1851. > Are you saying that it will be the official policy of the IETF that > RFC-1829 and its successors will advance to Internet Standard as the > method to use for manual keying? > > That depends on whether there is any vendor and market interest in > manual keying and backwards compatibility with the old boxes. I have > been told that most vendors what to get away from manual keying as fast > as they can. If there's no interest in manual keying, then we can let > RFC-1829 either (a) not advance, or (b) go to historic. That however, > is not a matter that this working group needs to decide now. > I'm confused by your answer. It's not? It was my thought, and the thought of others with whom I have corresponded, that your postings were introducing incompatibility with RFC-1829 and -1851 for manual keying. Manual keying is an absolute requirement in numerous situations. For example, chicken and egg problems with otherwise insecure distributed configuration of security parameters. In my view, this entire question revolves around choosing the best technical solution for manual configuration of DES and 3DES. And thus, compatibility with RFC-1829 and -1851. This straw poll is only talking about IVs within the DOI of Oakley/ISAKMP? I already have the sentence: Alternative IV generation techniques MAY be specified when dynami- cally configured via a key management protocol. In which case, why not simply add a few sentences to ISAKMP-DOI saying that an explicit IV is used? > Is a MAC required or optional? > > The MAC is optional; however, if it isn't there, then obviously data > integrity wasn't required or important. If data integrity is a > requirement, then you should be using a MAC. > Since the MAC is optional, then anti-replay is optional. As the current drafts assume. And if anti-replay is optional, then sequence number checking is optional, too. As the current drafts assume. In short, we have arrived at the opposite assumption about sequence number wrapping.... 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 Thu Aug 7 18:57:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA22178 for ipsec-outgoing; Thu, 7 Aug 1997 18:55:35 -0400 (EDT) Message-ID: <33EA5447.385F@fet.com> Date: Thu, 07 Aug 1997 16:03:35 -0700 From: "Scott G. Kelly" Organization: Furukawa Electric Technologies, Inc. X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: William Allen Simpson CC: ipsec@tis.com Subject: Re: Calling the question: derived vs. explicit IV References: <6424.wsimpson@greendragon.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk William Allen Simpson wrote: > > > From: "Theodore Y. Ts'o" > > Are you saying that there will be two (or more) supported domains of > > interpretation, one for manual keying and another for Oakley/ISAKMP? > > > > DOI is a ISAKMP term. As such, it doesn't make sense for manual keying. > > This is an aside to your discussion: why doesn't DOI refer to manual SA configuration and keying? I'm currently doing some design work for a router that will initially support manual SA's and keys (and will continue to do so even after ISAKMP is integrated into the system), and while DOI is moot at this point since there's only one, it seems to me that open design principles call for putting in hooks for future DOI's, even for the manual config. Am I missing something? I though DOI was a IPsec term... > OK, "universes" is the term used earlier by Moskowitz. > > And your next answer appears to indicate that yes, when there is vendor > and market interest in manual keying, it will be a different "universe", > and it will continue to be compatible with RFC-1829 and -1851. > > > Are you saying that it will be the official policy of the IETF that > > RFC-1829 and its successors will advance to Internet Standard as the > > method to use for manual keying? > > > > That depends on whether there is any vendor and market interest in > > manual keying and backwards compatibility with the old boxes. I have > > been told that most vendors what to get away from manual keying as fast > > as they can. If there's no interest in manual keying, then we can let > > RFC-1829 either (a) not advance, or (b) go to historic. That however, > > is not a matter that this working group needs to decide now. > > > I'm confused by your answer. It's not? > > It was my thought, and the thought of others with whom I have > corresponded, that your postings were introducing incompatibility with > RFC-1829 and -1851 for manual keying. > > Manual keying is an absolute requirement in numerous situations. For > example, chicken and egg problems with otherwise insecure distributed > configuration of security parameters. > > In my view, this entire question revolves around choosing the best > technical solution for manual configuration of DES and 3DES. And thus, > compatibility with RFC-1829 and -1851. > > This straw poll is only talking about IVs within the DOI of > Oakley/ISAKMP? > > I already have the sentence: > > Alternative IV generation techniques MAY be specified when dynami- > cally configured via a key management protocol. > > In which case, why not simply add a few sentences to ISAKMP-DOI saying > that an explicit IV is used? > > > Is a MAC required or optional? > > > > The MAC is optional; however, if it isn't there, then obviously data > > integrity wasn't required or important. If data integrity is a > > requirement, then you should be using a MAC. > > > Since the MAC is optional, then anti-replay is optional. As the current > drafts assume. > > And if anti-replay is optional, then sequence number checking is > optional, too. As the current drafts assume. > > In short, we have arrived at the opposite assumption about sequence > number wrapping.... > > 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 Thu Aug 7 20:33:21 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA22679 for ipsec-outgoing; Thu, 7 Aug 1997 20:31:05 -0400 (EDT) Date: Fri, 8 Aug 97 00:17:19 GMT Daylight Time From: Ran Atkinson Subject: Re: Calling the question: derived vs. explicit IV To: "Scott G. Kelly" Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <33EA5447.385F@fet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Thu, 07 Aug 1997 16:03:35 -0700 "Scott G. Kelly" wrote: > This is an aside to your discussion: why doesn't DOI refer to manual SA > configuration and keying? While the data elements within the IPsec DOI might well exist in manually configured IPsec SAs, the IPsec DOI is a component of the ISAKMP protocol. > Am I missing something? > I though DOI was a IPsec term... "DOI" is an ISAKMP term. Aside from that, the term "IPsec" is fairly nebulous at present. It sometimes means "ESP and AH" and other times means "ESP and AH as used with certain algorithms" and yet other times means "ESP and AH as used with certain algorithms, plus ISAKMP/Oakley key management". I try to avoid using the term "IPsec" nowadays because it is imprecise and hence confusing. ISAKMP is applicable to networking protocols other than IPsec. If one considers a router, one could easily imagine the following additional DOIs: RIPv2 DOI for ISAKMP (to dynamically manage RIPv2 cryptographic authentication, currently configured manually). OSPFv2 DOI for ISAKMP (to dynamically manage OSPFv2 cryptographic authentication, currently configured manually). As it happens, work on both of the above documents is well underway, but missed the I-D cutoff before Munich. I imagine they will appear online not long after Munich. The IESG would need to decide which WG those routing DOI drafts would belong in if standardised, but I would imagine they would be put into the RIPv2 WG and OSPFv2 WG, respectively. The development of cryptographic authentication for routing protocols has historically been done in the applicable routing protocol WG, hence my speculation. There has also been at least hallway conversation at past IETF meetings about creating an "SSH DOI for ISAKMP" for use with the increasingly popular "Secure SHell" application. There has also been discussion about adding an "RSVP DOI for ISAKMP" to configure SAs for the RSVP integrity object. I don't know where those items stand. Asking the respective WG chairs (for SECSH and RSVP) might be a starting point for any curious people. Ran rja@inet.org From owner-ipsec Fri Aug 8 07:35:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA26362 for ipsec-outgoing; Fri, 8 Aug 1997 07:32:08 -0400 (EDT) Date: Fri, 8 Aug 1997 07:32:08 -0400 (EDT) From: owner-ipsec@ex.tis.com From: Carlisle Adams To: "'Peter Williams'" Cc: "'ietf-pkix@tandem.com'" , "'ipsec@tis.com'" Subject: RE: PKCS 7 + PKCS 10 Proposal Date: Thu, 7 Aug 1997 17:44:52 -0400 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@portal.ex.tis.com Precedence: bulk Hi, I posted the following reply yesterday but haven't seen it show up on the PKIX list yet, so I wondered if it got lost somewhere. In any case, here we go again... >---------- >From: Carlisle Adams >Sent: Wednesday, August 06, 1997 5:57 PM >To: 'Peter Williams' >Cc: 'ietf-pkix@tandem.com'; 'ipsec@tis.com' >Subject: RE: PKCS 7 + PKCS 10 Proposal > >Peter, > >---------- >From: Peter Williams[SMTP:peter@verisign.com] >Sent: Wednesday, August 06, 1997 9:38 AM >To: Carlisle Adams >Cc: 'ietf-pkix@tandem.com'; 'ipsec@tis.com' >Subject: Re: PKCS 7 + PKCS 10 Proposal > >Carlisle Adams wrote: > >> The draft does not simply promote the notion that one need only have a >> single key. Rather, it fundamentally relies on that notion. [See, for >> example, the first sentence of Section 5.1.1.2 which says, "Because the >> response is encrypted with the user's public key.... This is the >> response to the certification request, which (being a PKCS #10 request) >> was signed with the user's private key. One key pair for both signing >> and encryption. > >Im a little annoyed (a mild IETF level of rebuke!) as you >know there is no such intent, as evidenced by your own companies >actions. > >When we specified the S/MIME profile of PKCS7 ,we specifically >decided that dual cert models (often proposed by Entrust) should >not be excluded. To this end, Entrust endorsed PKCS7, knowing >full well the protocol allows dual-cert solutions. I can point >folks to your website for product information, if you like. > >Since the last thing anyone would want to do is to annoy you, let me >highlight what I said (and what I did not say). I did *not* say that PKCS #7 >excludes the dual-key model. We all know that it allows single-key and >dual-key models. What I *did* say, however, was that this specific proposal >fundamentally relies on a single-key model, as evidenced quite clearly by the >quote I gave from Section 5.1.1.2. Yes, this proposal is based on PKCS #7, >but it does not allow the richness of PKCS #7 in this respect because it >assumes that a single key pair can be used for signing and encryption. > >Can we both agree with this without either party getting annoyed? > > >-------------------------------------------- >Carlisle Adams >Entrust Technologies >cadams@entrust.com >-------------------------------------------- > >P.S., Any time you feel compelled to point folks to our web site for product >information, feel free to go ahead and do so. > > From owner-ipsec Fri Aug 8 11:29:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA28246 for ipsec-outgoing; Fri, 8 Aug 1997 11:27:22 -0400 (EDT) Message-ID: <33EB3CC1.D1F@fet.com> Date: Fri, 08 Aug 1997 08:35:29 -0700 From: "Scott G. Kelly" Organization: Furukawa Electric Technologies, Inc. X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: Ran Atkinson CC: ipsec@tis.com Subject: Re: Calling the question: derived vs. explicit IV References: <33EA5447.385F@fet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran Atkinson wrote: > > --- On Thu, 07 Aug 1997 16:03:35 -0700 "Scott G. Kelly" wrote: > > > This is an aside to your discussion: why doesn't DOI refer to manual SA > > configuration and keying? > > While the data elements within the IPsec DOI might well exist in manually > configured IPsec SAs, the IPsec DOI is a component of the ISAKMP protocol. Not trying to be quarrelsome, just trying to understand: DOI *does* apply to manually configured SA's, right? I mean, it's reasonable to say that someone might someday manually configure concurrent SA's which apply to different DOI's, right? > > > Am I missing something? > > I though DOI was a IPsec term... > > "DOI" is an ISAKMP term. Agreed. I should never have said it was an 'IPsec term'. What I should have said it this: even though DOI is rightly occurs in the ISAKMP context, it refers to SA's, i.e. 'domain of interpretation' w.r.t. the SA begin defined. Hence, DOI is not irrelevant to manual SA configuration. Scott From owner-ipsec Fri Aug 8 12:06:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA28552 for ipsec-outgoing; Fri, 8 Aug 1997 12:06:29 -0400 (EDT) Message-ID: <33EB3FC7.67BB@fet.com> Date: Fri, 08 Aug 1997 08:48:23 -0700 From: "Scott G. Kelly" Organization: Furukawa Electric Technologies, Inc. X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: Ran Atkinson CC: ipsec@tis.com Subject: Re: Calling the question: derived vs. explicit IV References: <33EA5447.385F@fet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran Atkinson wrote: > > --- On Thu, 07 Aug 1997 16:03:35 -0700 "Scott G. Kelly" wrote: > > > This is an aside to your discussion: why doesn't DOI refer to manual SA > > configuration and keying? > > While the data elements within the IPsec DOI might well exist in manually > configured IPsec SAs, the IPsec DOI is a component of the ISAKMP protocol. This is a follow-up to my last post to clarify a few things. Also, I apologize for any confusion caused by the various typos - I'll proofread this and any further posts *before* posting. Additional clarifications: I'm saying DOI may apply to manually configured SA's. This follows from two assumptions: (1) Manually configured SA's will continue to be useful even after someone has implemented ISAKMP, i.e. ISAKMP overhead is not justifiable in all configurations, and even when ISAKMP implementations proliferate, there will still be manual SA configuration. (2) A system employing manual SA configuration may require the capability to simultaneously utilize SA's in separate DOI's. In that case, the SPD entries will have different formats/contents. Hence, DOI applies to manual configuration of SA's. Scott From owner-ipsec Fri Aug 8 12:17:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA28611 for ipsec-outgoing; Fri, 8 Aug 1997 12:16:59 -0400 (EDT) Message-Id: <3.0.3.32.19970808122438.00a37210@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 08 Aug 1997 12:24:38 -0400 To: "Scott G. Kelly" , Ran Atkinson From: Robert Moskowitz Subject: Re: Calling the question: derived vs. explicit IV Cc: ipsec@tis.com In-Reply-To: <33EB3CC1.D1F@fet.com> References: <33EA5447.385F@fet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 08:35 AM 8/8/97 -0700, Scott G. Kelly wrote: > >Not trying to be quarrelsome, just trying to understand: DOI *does* >apply to manually configured SA's, right? I mean, it's reasonable to say >that someone might someday manually configure concurrent SA's which >apply to different DOI's, right? Let's see here. At about 17,500' level, SAs drive the encryption/authentication algorithms and are one of the by-products of a KMP. The KMP might be two people on keyboards and phones (ie manual). There have been 4 KMPs discussed in this workgroup: Manual Photuris SKIP ISAKMP/Oakley A KMP that can be used for things other than just IPsec, SHOULD have a DOI. ISAKMP/Oakley does. I suppose that someone could write a DOI for manual. >> "DOI" is an ISAKMP term. > >Agreed. I should never have said it was an 'IPsec term'. What I should >have said it this: even though DOI is rightly occurs in the ISAKMP >context, it refers to SA's, i.e. 'domain of interpretation' w.r.t. the >SA begin defined. Hence, DOI is not irrelevant to manual SA >configuration. The ISAKMP/Oakley DOI for IPsec is irrelevant wrt to manual SA configuration. It least in my reading of it. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Fri Aug 8 12:35:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA28760 for ipsec-outgoing; Fri, 8 Aug 1997 12:34:32 -0400 (EDT) Message-Id: <3.0.3.32.19970808124150.00a324f0@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 08 Aug 1997 12:41:50 -0400 To: "Scott G. Kelly" , Ran Atkinson From: Robert Moskowitz Subject: Re: Calling the question: derived vs. explicit IV Cc: ipsec@tis.com In-Reply-To: <33EB3FC7.67BB@fet.com> References: <33EA5447.385F@fet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 08:48 AM 8/8/97 -0700, Scott G. Kelly wrote: > >I'm saying DOI may apply to manually configured SA's. This follows from >two assumptions: (1) Manually configured SA's will continue to be useful >even after someone has implemented ISAKMP, i.e. ISAKMP overhead is not >justifiable in all configurations, and even when ISAKMP implementations >proliferate, there will still be manual SA configuration. (2) A system >employing manual SA configuration may require the capability to >simultaneously utilize SA's in separate DOI's. In that case, the SPD >entries will have different formats/contents. Hence, DOI applies to >manual configuration of SA's. Ah ha! IMHO, if you view that the KMP drives the security, then you may have to look at things in this light. But if the security REQUESTS action by the KMP, then this is unnecessary. Some policy decides what KMP to use. It could be, try ISAKMP/Oakley. If that doesn't work, try this manual key. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Fri Aug 8 13:05:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA28945 for ipsec-outgoing; Fri, 8 Aug 1997 13:05:31 -0400 (EDT) Message-Id: <3.0.1.32.19970808130913.00803870@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 08 Aug 1997 13:09:13 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: Re: key management schemes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I believe it's FIVE. There is also "externally generated keys entered 'manually' into IPsec", a/k/a out-of-band keying and several other names. In other words, machinery, but machinery discussed outside the scope of this WG. >From: Robert Moskowitz >There have been 4 KMPs discussed in this workgroup: > >Manual >Photuris >SKIP >ISAKMP/Oakley From owner-ipsec Fri Aug 8 13:44:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA29170 for ipsec-outgoing; Fri, 8 Aug 1997 13:43:30 -0400 (EDT) Date: Fri, 8 Aug 1997 13:50:49 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199708081750.NAA16264@argon.ncsc.mil> To: ietf-pkix@tandem.com, ipsec@tis.com Subject: RE: PKCS 7 + PKCS 10 Proposal X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > > From: mmyers@verisign.com[SMTP:mmyers@verisign.com] > > > >To the last point, I would observe that the draft is intended to address > >only the most essential elements of a PKI service, with the thought in > >mind that additional work would be needed to expand upon these basic > >services. What would this additional work entail? * The addition of features not currently addressed by the draft which are already addressed by the existing PKIX-3? * Modification of the protocol to track development of PKCS #7? I note that the draft (section 3.6) uses the signedData and envelopedData constructs, so it is apparently based on version 1.5 of PKCS7. PKCS7 version 2.0 combines these and several other constructs into two generic items - IntegrityProtectionInfo and EncryptionInfo. Will your proposal stick with the old PKCS7 to allow the installed base of code to continue to be used, or will it use current PKCS7, maintaining synchronism with S/MIME but requiring new code development? If new code is required, why shouldn't it be based on PKIX-3? > From: Carlisle Adams > > In other words, the plan seems to be to essentially re-do everything > that has already been done in the past 1-1/2 to 2 years with PKIX-3. > Mike has repeatedly said to me that a lot of effort and thinking has > gone into PKIX-3 to construct a secure, general set of protocols for > certificate management. Does it make sense to do this all again for > this new proposal (and wait another 1-1/2 to 2 years to get something > that is strong enough and general enough to be useful)? My personal > feeling is, "No". > > Ultimately, what PKIX is all about is the definition and standardization > of a Public-Key Infrastructure for the Internet. The proposal given > here cannot (and does not) claim to build such an infrastructure. It > may provide *some* of the necessary functionality for *some* > environments (although I still worry about not being able to securely > initialize entities), but this limited focus is clearly inadequate for > an IPKI. Considering that this work has already been done in PKIX-3, > and that it is ready to go to Working Group Last Call, it seems to me > that the proposal given here may be suitable as a (standardized or > proprietary) protocol in some other context, but not within the stated > scope of the PKIX Working Group. I agree completely with this summary. It is perfectly reasonable for PKI providers to continue to use and support a suboptimal but working legacy protocol for as long as there is a market for it. This doesn't require any action by the IETF - just do it. But it is not reasonable for PKIX to devote resources to standardizing a partial solution when a well-specified complete solution has already gone through the long process and is ready to proceed to Proposed Standard. > From: Robert Moskowitz > > Is PKIX-3 (showing my lack of energy to cover it too) codeable? Are > there any implimentations out there that we can see in action? It is certainly codeable. PKIX-3 bears a striking resemblance to the MISSI Management Protocol (MMP), which provides certificate and key life-cycle support, audit, and additional Government-specific functionality related to the initialization of Fortezza(R) cards. MMP is running today (and has been for several years) in BBN (GTE) and Motorola products - if you stripped out all the non-certificate-related messages you would have something that looks pretty similar to PKIX-3. From owner-ipsec Fri Aug 8 13:54:07 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA29250 for ipsec-outgoing; Fri, 8 Aug 1997 13:54:00 -0400 (EDT) Message-Id: <199708081801.OAA22747@raptor.research.att.com> To: ipsec@tis.com Subject: new/pending/delayed work items Date: Fri, 08 Aug 1997 14:01:16 -0400 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk As you all know by now, we're trying to wrap up the basic work of the ipsec group. I'm trying to put together a list of other related issues -- things we've delayed, new ideas, etc. I'm interested in any suggestions. --Steve Bellovin From owner-ipsec Fri Aug 8 14:00:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA29273 for ipsec-outgoing; Fri, 8 Aug 1997 14:00:30 -0400 (EDT) Message-ID: <33EB60A2.217A@fet.com> Date: Fri, 08 Aug 1997 11:08:34 -0700 From: "Scott G. Kelly" Organization: Furukawa Electric Technologies, Inc. X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: [Fwd: Re: Calling the question: derived vs. explicit IV] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Scott G. Kelly wrote: > > Robert Moskowitz wrote: > > > > Let's see here. At about 17,500' level, SAs drive the > > encryption/authentication algorithms and are one of the by-products of a > > KMP. The KMP might be two people on keyboards and phones (ie manual). > > > > There have been 4 KMPs discussed in this workgroup: > > > > Manual > > Photuris > > SKIP > > ISAKMP/Oakley > > > > A KMP that can be used for things other than just IPsec, SHOULD have a DOI. > > ISAKMP/Oakley does. I suppose that someone could write a DOI for manual. > > > > Three comments: > > (1) Part of the confusion here is due to unfortunate naming choices. The > KMP in ISAKMP is not the same as the KMP you're using to refer to key > exchange (management?) protocols. Furthermore, ISAKMP does not define a > 'key management' protocol in the strict sense, or if it does, that > certainly is not clear from the documents posted to date. It defines a > 'security association management protocol', which has the added feature > of providing a framework within which key exchange/management mechanisms > may be selected and encapsulated. > > It might be too much to hope that we can clean up some of this confusing > terminology before going to RFC's, but I hold that hope nonetheless. > > (2) Given that clarification, SA's are not the byproduct of KMP's; > rather, they are the byproduct of a security policy. In fact, they are > an instance of the application of a security policy to a particular > datastream. > > (3) Again, according to the drafts currently posted at ietf.org, the > only documented DOI in existence is for IP security within the ISAKMP > framework. Or am I missing something? > > > > > The ISAKMP/Oakley DOI for IPsec is irrelevant wrt to manual SA > > configuration. It least in my reading of it. > > As indicated in (3) above, I can't find any reference in the documents > to the ISAKMP/Oakley DOI. As far as I can ascertain, there is no such > critter; the only defined DOI (so far) is for IP security within the > ISAKMP framework. And again, I am not trying to be belligerent or smug; > I only began studying the IPsec documents about a month ago, and I don't > know anywhere near as much about this as many of you do. However, one of > the real challenges in trying to get up to speed has been in wading > through all the unfortunate language being used, language which just > fosters confusion. These documents and protocols have far reaching > implications and ramifications; the utmost care should be exercised in > arriving at design decisions, including naming conventions. > > Scott From owner-ipsec Fri Aug 8 14:06:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA29350 for ipsec-outgoing; Fri, 8 Aug 1997 14:06:31 -0400 (EDT) Message-ID: <33EB620D.2D9A@fet.com> Date: Fri, 08 Aug 1997 11:14:37 -0700 From: "Scott G. Kelly" Organization: Furukawa Electric Technologies, Inc. X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: [Fwd: Re: Calling the question: derived vs. explicit IV] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Scott G. Kelly wrote: > > Robert Moskowitz wrote: > > > > > >> "DOI" is an ISAKMP term. > > > > > >Agreed. I should never have said it was an 'IPsec term'. What I should > > >have said it this: even though DOI is rightly occurs in the ISAKMP > > >context, it refers to SA's, i.e. 'domain of interpretation' w.r.t. the > > >SA begin defined. Hence, DOI is not irrelevant to manual SA > > >configuration. > > > > The ISAKMP/Oakley DOI for IPsec is irrelevant wrt to manual SA > > configuration. It least in my reading of it. > > > > I'm becoming more confused now. The 'ISAKMP/Oakley DOI for IPsec'? The > only DOI I am currently aware of is the IP DOI for ISAKMP. Here's the > relevant text from draft-ietf-ipsec-ipsec-doi-02.txt: > > Within ISAKMP, a Domain of Interpretation is used to group related > protocols using ISAKMP to negotiate security associations. Security > protocols sharing a DOI choose security protocol and cryptographic > transforms from a common namespace and share key exchange protocol > > As Ran correctly pointed out (I think), DOI is an ISAKMP term. As I've > said in earlier posts, my bandwidth is limited; I haven't read all the > drafts, and I don't remember all the details in the ones I have read. > Are there drafts I should read which would straighten out my > misconceptions here? > > Thanks, > > Scott From owner-ipsec Fri Aug 8 14:16:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA29423 for ipsec-outgoing; Fri, 8 Aug 1997 14:16:29 -0400 (EDT) Date: Fri, 8 Aug 1997 14:25:07 -0400 Message-Id: <199708081825.OAA06134@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "Scott G. Kelly" Cc: Ran Atkinson , ipsec@tis.com In-Reply-To: Scott G. Kelly's message of Fri, 08 Aug 1997 08:35:29 -0700, <33EB3CC1.D1F@fet.com> Subject: Re: Calling the question: derived vs. explicit IV Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Fri, 08 Aug 1997 08:35:29 -0700 From: "Scott G. Kelly" Not trying to be quarrelsome, just trying to understand: DOI *does* apply to manually configured SA's, right? I mean, it's reasonable to say that someone might someday manually configure concurrent SA's which apply to different DOI's, right? I think there's a major misunderstanding about what the term DOI means. A particular DOI defines the messages and exchanges used in the ISAKMP protocol. As such, if you're not using ISAKMP, you can't be using "DOI" in the ISAKMP context. I think you're trying to talk about something completely different; perhaps it would be helpful if you could precisely define the term which you're trying to use? We can then either come up with the proper term, or if one doesn't exist, we can invent one. :-) But I think the major difficulty is that what you mean by "DOI" isn't is not the same as the definition of DOI as used by the ISAKMP protocol. As such, this is bound to cause endless confusion which can be headed off at the pass by defining our terms carefully at the outset. - Ted From owner-ipsec Fri Aug 8 14:49:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA29588 for ipsec-outgoing; Fri, 8 Aug 1997 14:47:03 -0400 (EDT) Message-ID: <33EB6BA6.728D@fet.com> Date: Fri, 08 Aug 1997 11:55:34 -0700 From: "Scott G. Kelly" Organization: Furukawa Electric Technologies, Inc. X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: "Theodore Y. Ts'o" CC: ipsec@tis.com Subject: Re: Calling the question: derived vs. explicit IV References: <199708081825.OAA06134@dcl.MIT.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Theodore Y. Ts'o wrote: > I think there's a major misunderstanding about what the term DOI means. > A particular DOI defines the messages and exchanges used in the ISAKMP > protocol. As such, if you're not using ISAKMP, you can't be using "DOI" > in the ISAKMP context. > > I think you're trying to talk about something completely different; > perhaps it would be helpful if you could precisely define the term which > you're trying to use? We can then either come up with the proper term, > or if one doesn't exist, we can invent one. :-) > Yes, perhaps this is correct. In terms of my references to DOI w.r.t. SA configuration (manual or otherwise) I'm thinking of the interpretation constraints which shape the format and content of security policy database entries. My current design for manual SA configuration utilizes a SPD (I didn't call it that before reading the recent [IPSEC-ARCH] posting), and in preparing the design I am allowing for future SA configuration which might provide security over different network layers, or might use different (perhaps as yet unimagined) security schemes. I have been using the term 'DOI' to distinguish between these different entry types, i.e. the domain-of-interpretation is the selector for the format/content interpretation. I've just been looking at the DOI document, and see where this (that is, my) interpretation is confused. My apologies for any confusion I've caused... Scott From owner-ipsec Fri Aug 8 17:25:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA00824 for ipsec-outgoing; Fri, 8 Aug 1997 17:23:02 -0400 (EDT) From: Xiaoyi Liu Message-Id: <199708082131.OAA26301@stilton.cisco.com> Subject: PKI draft based on PKCS#10 and PKCS#7 To: ipsec@tis.com Date: Fri, 8 Aug 1997 14:31:57 -0700 (PDT) Cc: xliu@cisco.com (Xiaoyi Liu) 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 Recently, there are several issues raised for the certificate management protocol based on PKCS#7 and PKCS#10. We like to address those issues here and open a discussion. 1) The draft does not cover all the functions required for a certificate management protocol. The most important functions of a certificate management protocol, the enrollment operations, have been designed, implemented and tested, and these are what we feel the most important pieces needed to get a functional PKI solution into the marketplace in the very near future. It is also clear that, the proposed protocol does not precluse other functionality required of certificate management protocols. It is open ended and extensible. We believe the proposed draft has its merit not only because it proposes a solution to the existing certificate enrollment problem, but also because it leverages the existing PKCS#7 and PKCS#10 technology and can be developed in a relatively short time with the existing toolkit. It is certainly our direction to futher improve the protocol, based on the standard requirement and the actual customer experience. 2) The draft does not address effectively the authentication between the end entity and the CA. There are different models to carry out the authentication between the end entity and the CA. The customers should be given the choices to make their decision. In the current draft, the authentication between the end entity and the CA is specified as out-of-band manual authentication, which is one kind of model which satisfies certain customer need. However, there is no restriction to integrate other authentication model into the protocol. It is important to note that, since we are discussing the authentication at the bootstrapping phase, out-of-band operation is required for any proposed method at different stage. 3) The draft proposes a single key system It is true the draft at the current state utilize a single key system. However, PKCS#7 is a protocol which does not exclude the dual-key system. We are working at various solutions which can expand the current protocol to handle the dual-key system. Xiaoyi Liu, Cisco System From owner-ipsec Fri Aug 8 19:48:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA01627 for ipsec-outgoing; Fri, 8 Aug 1997 19:47:02 -0400 (EDT) Message-Id: <199708082355.QAA25964@grayling.erg.sri.com> Date: Fri, 8 Aug 1997 16:55:26 -0700 From: "Fred L. Templin" To: ipsec@tis.com Cc: templin@erg.sri.com Subject: Question on authentication coverage in ESP... Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Please forgive me if this has already been discussed, but I notice from reading draft-ietf-ipsec-v2-00.txt that the authentication coverage for ESP does NOT extend into the immutable fields of the IP header and options, as is the case for AH (see pp. 4,8,9 of the ESP draft). I like the idea of providing authentication coverage for the immutable IP header fields in AH; is there a reason this isn't done in ESP? Thanks, Fred templin@erg.sri.com From owner-ipsec Fri Aug 8 23:03:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA02445 for ipsec-outgoing; Fri, 8 Aug 1997 23:02:32 -0400 (EDT) Date: Sat, 9 Aug 97 02:51:43 GMT Daylight Time From: Ran Atkinson Subject: Re: DOI terminology question To: "Scott G. Kelly" Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <33EB3CC1.D1F@fet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Fri, 08 Aug 1997 08:35:29 -0700 "Scott G. Kelly" wrote: > Not trying to be quarrelsome, just trying to understand: DOI *does* > apply to manually configured SA's, right? I mean, it's reasonable to say > that someone might someday manually configure concurrent SA's which > apply to different DOI's, right? Your terminology is perhaps confusing, so I would recommend seeking a more clear terminology. As Ted suggests, defining terms is perhaps useful. (Towards that end: SA == Security Association :-) In the more common definition, the "IPsec DOI" _only_ applies to ISAKMP. The definition of a minimal conforming "IPsec SA" is formally made in RFC-1825. Please do not mistake the "IPsec DOI" as being the formal definition of an IPsec SA. The "IPsec DOI" document happens to have a set of attributes that map to the minimal items of an SA (which is formally defined by RFC-1825) and also a set of additional items not required by RFC-1825. An IPsec SA created via some other method (e.g. Photuris or manual configuration) MUST conform with the minimal requirements specified in RFC-1825, but need not have any attribute beyond those required by RFC-1825. If one has a RIPv2 SA and an OSPFv2 SA, one normally refers to these as different kinds of SAs. One does not normally use the term "DOI" to distinguish between or among them. > Agreed. I should never have said it was an 'IPsec term'. What I should > have said it this: even though DOI is rightly occurs in the ISAKMP > context, it refers to SA's, i.e. 'domain of interpretation' w.r.t. the > SA begin defined. Hence, DOI is not irrelevant to manual SA > configuration. The "DOI" is _only_ applicable to ISAKMP (or some other multi-application KMP) and does _not_ apply to manually created SAs. Aside: I personally find the term "SPD" as used in the new drafts to be somewhat confusing. However, I think that the logical "SPD" might correspond to the ipsec_policy.c module of the NRL codebase. I'm not too sure. Ran rja@inet.org From owner-ipsec Sun Aug 10 09:28:47 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA10197 for ipsec-outgoing; Sun, 10 Aug 1997 09:22:14 -0400 (EDT) Message-Id: <199708101332.JAA29916@relay.hq.tis.com> Date: Sun, 10 Aug 97 9:28:35 EDT From: Charles Lynn To: Dan McDonald cc: Koji Imada - je4owb/2 , ipsec@tis.com, ipng@sunroof.eng.sun.com Subject: Re: IPv6 Destination options extension header position. Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, Thanks for your feedback on the issue of placement of the Destination Options header. The position before the Routing Header was omitted, I feel to reduce distractions. However, it has instead pointed out the need for an explanation of the rationale that resulted in the original diagram. The requirements stated in RFC 1883 Section "4.1 Extension Header Order", i.e., "IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet, except for the Hop-by-Hop Options header which is restricted to appear immediately after an IPv6 header only. Nonetheless, it is strongly advised that sources of IPv6 packets adhere to the above recommended order until and unless subsequent specifications revise that recommendation." Thus the recommendation that the Destination Options header appear in only two places (before the Routing Header and before the upper-layer header) is to be used until a subsequent specifications revises that recommendation. That is what the AH/ESP drafts were trying to reflect. The extension headers are processed in the order that they appear. Extension headers are generally orthogonal, except, potentially, in the case of the Destination Options (and Hop-by-Hop Options) header(s). As an example not related to IPSec, a destination option is being defined that will divorce the IP addresses in the IP header from the tokens used to perform demultiplexing at the transport layer. This has utility, e.g., to preserve a long duration connection when a system's addresses are dynamically changed. It may also be used to support migratory processes, etc. A similar argument may be made for the IPSec headers, as they, too, have bound (user/application) security to IP addresses. Consider a destination option that has the semantics of "change the source and destination IP addresses, for all subsequent processing, to SRC and DST. Use this option before an AH/ESP header would effectively change the SA that is referenced by the SPI, since an SA is identified by the triple . The placement of the Destination Options header carrying this option cannot be after the AH/ESP header (as that would lead to use of the wrong SA and (if the secrets are any good) the discard of the packet). One wouldn't want it before the Routing Header, as there is no need for it to be processed at each hop in the source route (in addition to potentially causing mis-delivery of the packet). This functionality may be useful in the context of multihomed hosts (that do not forward packets), migratory processes, redundant servers, evolution of the routing system, or, as was mentioned on one of the mailing lists recently, for use with NAT boxes that change between IP header versions 4 and 6, and IP addresses. I feel we should remind folks that things keep evolving, and some of the directions that that evolution might be taken, so that they don't unnecessarily constrain their implementations (short cuts) in ways that might prove to be a burden to the whole system later on. The bottom line for implementors is to be aware that not everything has been invented yet. It should have little real impact on systems that do not implement such an option. So how much space should we devote in the specs for it? Do you think it should be mentioned at all? We should certainly consider the security implications of such an option, but given that changing the option presents the same level of difficulty of attack to an adversary as, e.g., changing the IP destination address itself (or any bit that is protected by an integrity mechanism), I suspect that it would not introduce disproportional vulnerabilities. Consequently, I think that the "right diagram" would be something like: +------------+-------------------+---------------------+------+-----+------+ | Orig IP v4 | hop-by-hop, dest, | some combination of | dest | | | | or v6 hdr | routing, frag. | dest opt*, AH, ESP | opt* | TCP | Data | +------------+-------------------+---------------------+------+-----+------+ |<------------- authenticated by AH except for mutable fields ------------>| * = if present, could be before AH, after AH, or both To borrow your text, the above replacement text better illustrates (IMHO) AH placement in an IP datagram than does the current text. Charlie From owner-ipsec Sun Aug 10 09:33:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA10243 for ipsec-outgoing; Sun, 10 Aug 1997 09:32:13 -0400 (EDT) Message-Id: <199708101343.JAA29980@relay.hq.tis.com> Date: Sun, 10 Aug 97 9:39:52 EDT From: Charles Lynn To: ipsec@tis.com, ipng@sunroof.eng.sun.com Subject: Question on Extension Header Order Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, I noticed that the recommended order of extension headers shown in section 4.1 has changed from IPv6 header Hop-by-Hop Options header Destination Options header (note 1) Routing header Fragment header Authentication header (note 2) Encapsulating Security Payload header (note 2) Destination Options header (note 3) upper-layer header in RFC 1883 to IPv6 header Hop-by-Hop Options header Destination Options header (note 1) Routing header Fragment header Encapsulating Security Payload header (note 2) Authentication header (note 2) Destination Options header (note 3) upper-layer header in the draft. My question is why the order of the Authentication header and the Encapsulating Security Payload header were switched. My understanding of the direction of the IPSec WG leads me to conclude that either order may appear, based on the security policy being implemented, and that the order in RFC 1883 would be the order most often encountered. I suggest changing note 2 to: note 2: the order of the two security headers is based on security policy. Additional recommendations regarding the relative order of the Authentication and Encapsulating Security Payload headers are given in [draft-ietf-ipsec-arch-sec-01.txt], Charlie From owner-ipsec Sun Aug 10 10:07:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA10350 for ipsec-outgoing; Sun, 10 Aug 1997 10:06:44 -0400 (EDT) Message-Id: <199708101415.HAA07884@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Steven Bellovin Cc: ipsec@tis.com Subject: Re: new/pending/delayed work items In-Reply-To: Your message of "Fri, 08 Aug 1997 14:01:16 EDT." <199708081801.OAA22747@raptor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 10 Aug 1997 07:15:08 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk I think we need to revisit the router discovery problem. There had been discussion of adding a KX record to (secure) DNS to identity the router(s) one needs to establish SAs with in order to reach a particular destination. Also multicast KMP is an issue that needs solving. Dan. > As you all know by now, we're trying to wrap up the basic work of > the ipsec group. I'm trying to put together a list of other related > issues -- things we've delayed, new ideas, etc. I'm interested in > any suggestions. From owner-ipsec Sun Aug 10 12:18:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA10775 for ipsec-outgoing; Sun, 10 Aug 1997 12:17:45 -0400 (EDT) Date: Sun, 10 Aug 97 16:12:15 GMT Daylight Time From: Ran Atkinson Subject: Re: new/pending/delayed work items To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199708101415.HAA07884@dharkins-ss20> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk All, The KX record specification is online under "draft-atkinson-*". As the draft itself notes, it is not currently being proposed for standards-track status. The KX spec seems a bit outside the charter of the IPsec WG to me, but I'm happy to listen to any comments folks might have on the draft. As to multicast key management, I fully agree its very important. My two cents would be that progress might best be served by creating a separate WG to extend ISAKMP to support multicast key distribution. That would permit the IPsec WG to focus on its near-term objectives of getting revised versions of ESP/AH and initial versions of ISAKMP/Oakley out the door, while also permitting a focused effort on the multicast key distribution problem. IMHO, a large part of the historical problems with the IPsec WG have related to an initial charter that was overly broad. The recent trend in most IETF WGs is to have a much more narrow and focused charter than IPsec currently has. I suspect progress might be optimised by setting up a few narrowly focused follow-on WGs to IPsec rather than continuing IPsec as is and adding new work items. Regards, Ran rja@inet.org From owner-ipsec Sun Aug 10 12:25:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA10819 for ipsec-outgoing; Sun, 10 Aug 1997 12:25:13 -0400 (EDT) Date: Sun, 10 Aug 97 16:20:42 GMT Daylight Time From: Ran Atkinson Subject: Re: Question on Extension Header Order To: ipng@sunroof.eng.sun.com, ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199708101343.JAA29980@relay.hq.tis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Charles Lynn made an important observation. To followup... In IPv6-land, I believe that IPsec AH should appear before (outside) ESP. If one desires both integrity/authentication and confidentiality on data contained by IPsec ESP, then one should use an ESP transform that incorporates those features. [1] IPsec AH inside ESP is incapable of providing the intended protections (namely: to protect the invariant fields of the IPv6 header in addition to the upper-protocol data). To the extent that the current IPsec drafts do not say this, I believe those drafts would be technically flawed. I would be interested in hearing what other IPv6 IPsec implementers believe, if there are any other IPv6 IPsec implementers. Ran rja@inet.org [1] Because of the published attack in [Bellovin96], I personally am of the opinion that ESP should _always_ require an integrated strong integrity/authentication mechanism. From owner-ipsec Sun Aug 10 14:20:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA11310 for ipsec-outgoing; Sun, 10 Aug 1997 14:20:13 -0400 (EDT) Message-Id: <199708101906.PAA02797@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: new/pending/delayed work items In-reply-to: Your message of "Sun, 10 Aug 1997 16:12:15 EST." Date: Sun, 10 Aug 1997 15:06:46 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Ran" == Ran Atkinson writes: Ran> more narrow and focused charter than IPsec currently has. I Ran> suspect progress might be optimised by setting up a few Ran> narrowly focused follow-on WGs to IPsec rather than Ran> continuing IPsec as is and adding new work items. I absolutely agree. I think of Steve's time on Friday to be for the purpose of making a list of things that are outstanding. From that list, BOFs can be held in Washington to hammer out a sufficiently clear charter. :!mcr!: | Network security programming, currently Michael Richardson | on contract with DataFellows F-Secure IPSec 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 iQB1AwUBM+4RQ6ZpLyXYhL+BAQGr1gL/eeZUESCF/bE9al49Y+TdzHzvZxYPkHJ0 OnbtzA2uuwdVc6yDkhlpRHgd0Cybd02uJUsTUCgYt4zHVjXs9w69L9XVMi+lMARD IyiotUbCwOPVpZJ9XZA3si5bplwl7j15 =UJPf -----END PGP SIGNATURE----- From owner-ipsec Sun Aug 10 15:40:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA11614 for ipsec-outgoing; Sun, 10 Aug 1997 15:39:12 -0400 (EDT) Message-Id: <199708101944.PAA08126@raptor.research.att.com> To: "Michael C. Richardson" cc: ipsec@tis.com Subject: Re: new/pending/delayed work items Date: Sun, 10 Aug 1997 15:44:35 -0400 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Ran" == Ran Atkinson writes: Ran> more narrow and focused charter than IPsec currently has. I Ran> suspect progress might be optimised by setting up a few Ran> narrowly focused follow-on WGs to IPsec rather than Ran> continuing IPsec as is and adding new work items. I absolutely agree. I think of Steve's time on Friday to be for the purpose of making a list of things that are outstanding. From that list, BOFs can be held in Washington to hammer out a sufficiently clear charter. Yup. Let's first figure out what it is we need to do. Then we can figure out the right organizational structure. To be sure, my own bias is that the current ipsec group should focus on the basic issues necessary to get ipsec deployed *now*. I think that the advanced issues should be the subject of one -- or more -- new groups. (This is why I've been using the name 'ipsecond'.) From owner-ipsec Sun Aug 10 15:40:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA11635 for ipsec-outgoing; Sun, 10 Aug 1997 15:40:12 -0400 (EDT) Message-Id: <97Aug10.154833edt.11665@janus.tor.securecomputing.com> to: ipsec@tis.com Subject: Re: Calling the question: derived vs. explicit IV From: "C. Harald Koch" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3567.871242507.1@rafael.tornd.securecomputing.com> Date: Sun, 10 Aug 1997 15:48:27 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk I'm firmly in the "I don't care, as long as we get interoperability" camp, Despite my being listed as a supporter of derived in Bill's message. My co-workers are allowed to disgree with me, though. :-) -- Harald Koch From owner-ipsec Sun Aug 10 21:00:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA13020 for ipsec-outgoing; Sun, 10 Aug 1997 20:57:42 -0400 (EDT) Date: Sun, 10 Aug 1997 21:06:04 -0400 From: Ran Canetti Message-Id: <9708110106.AA35346@ornavella.watson.ibm.com> To: ipsec@tis.com, smb@research.att.com Subject: Re: new/pending/delayed work items Sender: owner-ipsec@ex.tis.com Precedence: bulk I agree with Dan and Ran that extending IPSEC to deal with multicast is an important work item. I strongly support forming a separate working group for secure multicast. It is certainly a wide, important, and unsolved enough work item. To demonstrate the complexity of secure multicast (and to invoke some thought :), let me list a number of questions that have to be answered in the design process. These questions will greatly affect how the solution/s will look like, both from cryptographic and systemic points of view. (The list is just a random sample, there are many more issues.) 1. Do we want to have a "multicast group center" with cryptographic capabilities? Do we want/expect the group members to trust this center? Alternatively, do we want that the trust be distributed among several entities? 2. Do we want group access control? If so, who will run it? 3. Do we want the group members to be able to verify the identity of the source of a message? Or is it enough that we know that the message was sent from some group-member? 4. Do we want groups where only one member can authenticate/encrypt its messages and the others can only verify/decrypt? 5. Do we want to trust the group members to keep their keys secret? If we don't, then do we want the group members (or the group center) to be able to detect the source of a leakage? 6. Do we want the routers to take part in the cryptographic responsibilities of multicast (since they have multicast group information anyway), or do we want only group-members to deal with that? Also, do we want dedicated servers? I suspect that we will eventually want several types of multicast groups, characterized by different sets of answers to the above questions (as well as many others). A first goal of a secure multicast working group should be to prioritize, and settle on one (or a small number of) multicast group types to start working on. Ran Canetti Ran BTW, I also support forming a dedicated group for secure multicast. It is certainly a wide, important, and unsolved enough work item. From owner-ipsec Mon Aug 11 12:33:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA18450 for ipsec-outgoing; Mon, 11 Aug 1997 12:14:44 -0400 (EDT) Date: Sun, 10 Aug 97 17:14:41 GMT From: William Allen Simpson Message-ID: <6430.wsimpson@greendragon.com> To: ietf@ietf.org CC: gtld-discuss@gtld-mou.org Subject: Re: Internet Governance Source-Info: From (or Sender) name not authenticated. Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Jeff Williams > I am not sure why you loath the cc: to the IETF list, but that is of > little matter in the grander scope of things I feel. Because the IETF list is about governing the IETF (and to a certain extent, the IAB and IRTF), not the Internet. Because the DNS is not the Internet, it is only one small part of the technical and operational problems of the Internet. Because we have already appointed very capable representatives to the IAHC nee PoC, who individually showed dedication, honor and integrity, and made one of the most incredible personal sacrifices of any effort that I have seen in a decade of Internet experience. Because, even while we may disagree with some of the specific results, we know and trust our representatives, and are profoundly grateful that they took up the burden on our behalf. Because we know enough not to trust anyone who clearly doesn't yet have a clue about the tao of the IETF. Because we hate clueless off-topic multi-list posting. 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 Aug 12 13:50:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA27400 for ipsec-outgoing; Tue, 12 Aug 1997 13:43:58 -0400 (EDT) Message-ID: <33F0A2D2.9351E1BE@newoak.com> Date: Tue, 12 Aug 1997 13:52:18 -0400 From: smamros@newoak.com (Shawn Mamros) X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: DOI draft question/request X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk A while back (mid-March), there was some discussion about the possibility of adding an Identification Type named ID_KEY to the list in section 4.6.2.1 of the DOI draft. This ID type would be an "opaque blob" that would aid those who needed to use Aggressive Mode to supply an ID which would be used to select a pre-shared key (when using that form of authentication), while still providing some protection (or at least obfuscation) for the identity. (I've included a couple of relevant messages from that discussion at the bottom of this message.) I notice that the latest DOI draft does not contain this ID type. Would it be possible to add it at this late date? Thanks for your consideration... -Shawn Mamros E-mail to: smamros@newoak.com begin quoted text-------------------------------------------------- Message-ID: <332EF66B.7701@newoak.com> Date: Tue, 18 Mar 1997 15:09:15 -0500 From: smamros@newoak.com (Shawn Mamros) X-Mailer: Mozilla 4.0b2 (WinNT; I) MIME-Version: 1.0 To: HUGO@watson.ibm.com CC: dharkins@cisco.com, PAU@watson.ibm.com, piper@cisco.com, ipsec@tis.com, smamros@newoak.com Subject: Re: Comment on the ISAKMP/Oakley resolution draft (pre-shared) X-Priority: 3 (Normal) References: <199703172324.SAA50747@mailhub1.watson.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk After thinking about the issue some more and discussing it with my coworkers, we're willing to go with the workaround proposed by Pau-Chen, Dan and Hugo (i.e., using an opaque identifier in Oakley Aggressive Mode to find the correct pre-shared key). Thanks for the suggestion, guys... One possibility that Hugo mentioned in one of his messages: > In order to accomodate this key identifier one needs an > "Identifiction Type Value" as defined in the Ipsec DOI > (draft-ietf-ipsec-ipsec-doi-02.txt). > This can be one of the "private" values to be agrred upon by the > communicating parties, or we could have a type value (say 7) added in > that draft for "ID_KEY". > If there is no opposition to do so I would suggest this mininal editorial > change to the DOI draft. Ideally, I too would like to see an "official" value designated in the DOI draft, if it's possible. But I'm willing to live with a private value if we have to... -Shawn Mamros E-mail to: smamros@newoak.com Message-Id: <199703182022.MAA09677@fluffy.cisco.com> To: smamros@newoak.com (Shawn Mamros) cc: HUGO@watson.ibm.com, dharkins@cisco.com, PAU@watson.ibm.com, piper@cisco.com, ipsec@tis.com Subject: Re: Comment on the ISAKMP/Oakley resolution draft (pre-shared) In-reply-to: Your message of "Tue, 18 Mar 1997 15:09:15 EST." <332EF66B.7701@newoak.com> Date: Tue, 18 Mar 1997 12:22:16 -0800 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk This seems like a worthwhile addition. I'll post an updated IPSEC DOI before the Memphis deadline. I have one other attribute that needs to be added ("Key Length" for variable length ciphers like RC5). Derrell end quoted text---------------------------------------------------- From owner-ipsec Wed Aug 13 05:04:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA02373 for ipsec-outgoing; Wed, 13 Aug 1997 05:03:26 -0400 (EDT) Message-Id: <199708130912.CAA18934@pita.cisco.com> To: smamros@newoak.com (Shawn Mamros) cc: ipsec@tis.com Subject: Re: DOI draft question/request In-reply-to: Your message of "Tue, 12 Aug 1997 13:52:18 EDT." <33F0A2D2.9351E1BE@newoak.com> Date: Wed, 13 Aug 1997 02:12:10 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk Ah, yes! I tried to find this thread when I was updating the DOI for Munich because I had it in my todo list, but I've changed mail systems too many times in the last couple of months and I couldn't find the mail. I figured if it was important whoever wanted it would let me know... :-) I'm expecting to release another update after this week, I will add it then. Derrell From owner-ipsec Wed Aug 13 06:46:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA02863 for ipsec-outgoing; Wed, 13 Aug 1997 06:45:28 -0400 (EDT) From: "William Douglas Maughan." Message-Id: <199708131054.GAA27275@topdog.cs.umbc.edu> Subject: Re: new/pending/delayed work items To: ipsec@tis.com Date: Wed, 13 Aug 1997 06:54:11 -0400 (EDT) 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 co-workers have submitted an I-D (intended to be an Informational RFC) as a starting point for multicast key management. The draft is: draft-wallner-key-arch-00.txt It's probably worth looking at for starters. Cheers. Doug Maughan From owner-ipsec Wed Aug 13 07:20:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA03146 for ipsec-outgoing; Wed, 13 Aug 1997 07:19:55 -0400 (EDT) Message-Id: <199708131119.HAA03146@portal.ex.tis.com> To: Charles Lynn Cc: ipsec@tis.com, ipng@sunroof.eng.sun.com, deering@cisco.com Subject: Re: (IPng 4316) Question on Extension Header Order In-reply-to: clynn@bbn.com's message of Sun, 10 Aug 97 09:39:52 -0500. <199708101340.GAA18089@saturn.Sun.COM> Date: Wed, 13 Aug 97 01:58:56 PDT From: Steve Deering Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Charles Lynn > > I noticed that the recommended order of extension headers shown in section > 4.1 has changed... My question is why the order of the Authentication > header and the Encapsulating Security Payload header were switched. Because I got confused. The new ESP draft (draft-ietf-ipsec-esp-v2-00.txt) says on page 8, 2nd paragraph, that the ESP header should precede the AH header, so I concluded that the ipsec wg had changed their recommended order. When I went looking for the ipsec architecture draft to find out what the real story was, all I found was draft-ietf-ipsec-arch-sec-01.txt which contains only the note saying that that draft has expired. I now see that the new AH draft (draft-ietf-ipsec-auth-header-01.txt) says on page 6, 3rd paragraph, that the AH header should precede the ESP header, so the AH and ESP documents appear to be contradictory (looks like a simple editing error, when moving text from one document to the other). It is still the case that there is no ipsec-arch document in the internet- drafts directory. I guess the editors missed the pre-IETF drafts deadline. I have been informed that a new arch draft was posted to the ipsec list, but that doesn't help those of us ipngwg folks who are not on the ipsec list. Anyway, from reading the new ESP draft, it looks like the ipsec wg prefers receivers to do authentication first, then decryption, in the case where both functions are bundled into ESP. So I would guess that, in the unbundled case (i.e., separate AH and ESP headers), AH should normally precede ESP, as you suggest. So, unless I hear otherwise, I will undo the change I made in the new IPv6 draft. (Though it certainly seems counter- intuitive to me: after all, it's the integrity of the plaintext that a receiver cares about, not the integrity of the gibberish.) > I suggest changing note 2 to: > > note 2: the order of the two security headers is based on > security policy. Additional recommendations > regarding the relative order of the Authentication > and Encapsulating Security Payload headers are given > in [draft-ietf-ipsec-arch-sec-01.txt], I'll consider this change once I have a chance to read the ipsec-arch draft, to see what it actually says. (Actually, a friendly ipsec-er emailed me a copy of that document yesterday, but I've been too busy at IETF to read it yet.) Steve From owner-ipsec Wed Aug 13 15:26:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA06252 for ipsec-outgoing; Wed, 13 Aug 1997 15:19:33 -0400 (EDT) Message-ID: <33F20AC3.D205472B@newoak.com> Date: Wed, 13 Aug 1997 15:28:03 -0400 From: smamros@newoak.com (Shawn Mamros) X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: ipsec@tis.com CC: smamros@newoak.com Subject: ISAKMP/Oakley resolution draft question X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk In the latest (-04) version of the ISAKMP/Oakley resolution draft, the last message of Aggressive Mode (regardless of the authentication method) is always unencrypted. This seems to counter the base ISAKMP (-08) draft, where the last message of Aggressive Mode is encrypted. But there is some text in section 5 of the resolution draft (at the top of page 7) which seems to justify the lack of encryption. Is this correct? If so, then how does one calculate the IV required for the first Quick Mode message after using Aggressive Mode, given that there will be no CBC output block from phase 1 (see appendix B)? Thanks in advance... -Shawn Mamros E-mail to: smamros@newoak.com From owner-ipsec Wed Aug 13 15:37:22 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA06402 for ipsec-outgoing; Wed, 13 Aug 1997 15:36:33 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199708131119.HAA03146@portal.ex.tis.com> References: clynn@bbn.com's message of Sun, 10 Aug 97 09:39:52 -0500. <199708101340.GAA18089@saturn.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 13 Aug 1997 15:36:36 -0500 To: Steve Deering From: Stephen Kent Subject: Re: (IPng 4316) Question on Extension Header Order Cc: Charles Lynn , ipsec@tis.com, ipng@sunroof.eng.sun.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, The Architecture Document was submitted "approximately" on time, e.g., no more than 5 minutes late. Since we've seen a lot of documents being posted long after the deadline, I suspect ours just fell through the cracks. Just to be sure, we copied it to the list, so the WG members have had it for a couple of weeks, but the rest of the community has not. I apologize for the confusion. We'll fix the editing error in ESP. Yes, when both encryption and authenticaion are peformed in ESP, the encryption is done first, then the authentication. This allows for parellelism at the receiver and alos allows for faster rejection of various sorts of denial of service attacks. If AH and ESP and both employed in transport mode, AH is the outer header, i.e., the first security protocol above IP, and ESP would follow AH. Here the rationale for the positioning is even stronger, since ESP is an encapsulation protocol and thus AH inside of ESP does not work well. Steve From owner-ipsec Thu Aug 14 23:19:00 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA17059 for ipsec-outgoing; Thu, 14 Aug 1997 23:11:43 -0400 (EDT) From: Cheryl Madson Message-Id: <199708150321.UAA18310@trix.cisco.com> Subject: ESP/AH draft comments To: ipsec@tis.com Date: Thu, 14 Aug 1997 20:21:04 -0700 (PDT) Cc: cmadson@cisco.com (Cheryl Madson) 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 So I don't need to drag paper around on vacation... ESP 1. Section 2, diagram. Why does the "Confid. Coverage" have a star? 2. Section 2.1: I've always found it easier to state that an SPI is uniquely identified by the tuple (dest addr, security prot, spi). 3. I think we should get rid of the references to the special cases for debugging. The couple of instances we have is either too many or two few -- why do we *just* have these? 4. Padding: make very clear that the "default" means what to do (MUST) if cipher doc doesn't give one; in this case the sender must perform the default processing. 5. My working definition of transport mode has been: the crypto peers are both the same as the endpoints for the "original" IP datagram. Tunnel mode is when they both aren't the same. I've heard sentiment that a so-called security gateway should allow transport mode connections to/from itself to an IPSEC host/another gw. I'm personally somewhat neutral, but we should resolve this. 6. Section 3.1, paragraph 2. I ferverently hope ESP won't come before AH in transport mode. 7. I'd asked this question before, but I don't remember the response: If replay detection is a facility to protect the *receiver*, why is the only auditable event one where the *sender* detects that it has sent too many packets on the current SA? In the old Hughes draft, it spelled out that the receiver would detect rollover and treat as the serious event it was. I don't think it makes sense for the sender to log (it should have been worrying about getting a new SA in place); and we have no indication of a replay rollover failure as detected by the receiver (if it's still really possible to do this with zero-relative counters). 8. Section 3.3.1: Text should be made consistant with the AH spec. 9. Section 3.2.3: make discussion of packet encryption more parallel to the discussion of packet decryption. The narrative is "more different" than is warranted. AH draft: Several comments from above apply here as well. 1. 3.3.1. I don't understand the discussion about "appears to be an IP fragment". I also don't know why it's discussed here, and not in the ESP draft as well. What are we protecting against here that we need a special check/audit event for this case (such that an ICV wouldn't catch a reassembly error, for example)? - C From owner-ipsec Fri Aug 15 04:03:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA18399 for ipsec-outgoing; Fri, 15 Aug 1997 04:02:15 -0400 (EDT) Date: Fri, 15 Aug 1997 04:10:59 -0400 Message-Id: <199708150810.EAA18449@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: operator@foresyte.com Cc: ipsec@tis.com, rgm3@chrysler.com In-Reply-To: operator's message of Thu, 14 Aug 1997 17:40:29 -0700, <33F3A57D.CBA464D4@foresyte.com> Subject: Re: Where is IPDOI document? Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Thu, 14 Aug 1997 17:40:29 -0700 From: operator Hi, Where can I find the "The Internet IP Security Domain of Interpretation" document by Derrell Piper?? It is referenced by many IPSEC draft document. James, The latest revision DOI document was sent to the IETF Secretariat just shortly before the blackout period for the Munich IETF meeting. As a result, it's not yet in the I-D directories yet. So it's in the secretariat's queue, but it won't get published until they get back from Munich next week. The DOI document was also cc'ed to the ipsec wg mailing list. James, since apparently you didn't get it, I'll forward you a copy under separate cover. - Ted From owner-ipsec Fri Aug 15 08:39:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA19751 for ipsec-outgoing; Fri, 15 Aug 1997 08:35:42 -0400 (EDT) Message-Id: <199708151235.IAA19751@portal.ex.tis.com> Date: Thu, 14 Aug 1997 17:40:29 -0700 From: operator Reply-To: operator@foresyte.com Organization: Foresyte Tech X-Mailer: Mozilla 4.01 [en] (Win95; U) MIME-Version: 1.0 To: ipsec@tis.com CC: tytso@MIT.EDU, rgm3@chrysler.com Subject: Where is IPDOI document? X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Where can I find the "The Internet IP Security Domain of Interpretation" document by Derrell Piper?? It is referenced by many IPSEC draft document. Thanks very much for any help! //James Chang operator@foresyte.com From owner-ipsec Sat Aug 16 16:57:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA29611 for ipsec-outgoing; Sat, 16 Aug 1997 16:47:16 -0400 (EDT) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199708150321.UAA18310@trix.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 16 Aug 1997 16:51:41 -0500 To: Cheryl Madson From: Stephen Kent Subject: Re: ESP/AH draft comments Cc: ipsec@tis.com, Cheryl Madson Sender: owner-ipsec@ex.tis.com Precedence: bulk Cheryl, >ESP > >1. Section 2, diagram. Why does the "Confid. Coverage" have a star? The asterisk referes to the diagram "footnote". >2. Section 2.1: I've always found it easier to state that an SPI is >uniquely identified by the tuple (dest addr, security prot, spi). That's a good, concise way to express the notion. We can adopt that terminology here and in the other documents as well. >3. I think we should get rid of the references to the special cases >for debugging. The couple of instances we have is either too many or >two few -- why do we *just* have these? This is partly a holdover from the previous drafts, but also a clarification that was discussed on the list, where there was agreement that an SPI of 0 MUST not be transmitted. Since we earlier say that 1-255 are reserved, it begs the question as to the status of 0, so I think we need to say something, either here or in the arch doc. >4. Padding: make very clear that the "default" means what to do (MUST) >if cipher doc doesn't give one; in this case the sender must perform the >default processing. We can add the term "MUST" to this text to emphasize this. >5. My working definition of transport mode has been: the crypto peers >are both the same as the endpoints for the "original" IP datagram. >Tunnel mode is when they both aren't the same. > >I've heard sentiment that a so-called security gateway should allow >transport mode connections to/from itself to an IPSEC host/another >gw. I'm personally somewhat neutral, but we should resolve this. One might argue that two hosts could establish a tunnel mode ESP SA between them to provide better traffic flow security than would be offered by a transport mdode ESP SA, so I am reluctant to define the difference between tunnel and transport mode as you suggest. A transport mode SA to a GW would be OK if the gateway was the destination, e.g., a secured Telnet session for managing the gateway. But otherwise a transport mode SA should not be made to a gateway. >6. Section 3.1, paragraph 2. I ferverently hope ESP won't come before >AH in transport mode. You and me both :-). Steve Deering also noticed that typo and sent mail to the list about it on Wednesday. >7. I'd asked this question before, but I don't remember the response: >If replay detection is a facility to protect the *receiver*, why is the >only auditable event one where the *sender* detects that it has sent too >many packets on the current SA? In the old Hughes draft, it spelled out >that the receiver would detect rollover and treat as the serious event it >was. I don't think it makes sense for the sender to log (it should have >been worrying about getting a new SA in place); and we have no indication >of a replay rollover failure as detected by the receiver (if it's still >really possible to do this with zero-relative counters). Sequence counter comparisons are not pefromed using modular arithmetic. The receiver would regard receipt of of a packet with a "cycled" sequence number as being less than the window and thus would reject the packet as a replay, auditing the event. No special check is needed, right? >8. Section 3.3.1: Text should be made consistant with the AH spec. Yes, we will make the text parallel that of AH. >9. Section 3.2.3: make discussion of packet encryption more parallel to >the discussion of packet decryption. The narrative is "more different" >than is warranted. We will revisit the two discussions and make them more parallel. >AH draft: >1. 3.3.1. I don't understand the discussion about "appears to be an IP >fragment". I also don't know why it's discussed here, and not in the >ESP draft as well. What are we protecting against here that we need a >special check/audit event for this case (such that an ICV wouldn't catch >a reassembly error, for example)? Your're right that the documents diverge in the discussion of inbound processing; I suspect this is a holdover from the originals. There is an equivalent requirement to reject fragments for both AH and ESP inbound processing, consistent with the prohibition against IPSEC (transport mode) processing being applied to fragments. So long as the software is working properly we ought not encounter fragements. However, it's not unreasonable to include an explicit check for that and so we can make the discussion of reassembly in the two documents parallel. Steve From owner-ipsec Sat Aug 16 18:18:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA00113 for ipsec-outgoing; Sat, 16 Aug 1997 18:13:16 -0400 (EDT) Date: Sat, 16 Aug 97 21:56:54 GMT Daylight Time From: Ran Atkinson Subject: Re: ESP/AH draft comments To: IPsec WG X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Sat, 16 Aug 1997 16:51:41 -0500 Stephen Kent wrote: On the topic of SAs, I have also long used the terminology that: "An IPsec Security Association is uniquely identified by the Destination IP Address, SPI, and Security Protocol triple." The underlying ambiguity about whether the Security Protocol was part of the identification criteria was my editorial error in the original RFCs, which I had attempted to clarify in last Fall's posted I-Ds. Mea Culpa. > >3. I think we should get rid of the references to the special cases > >for debugging. The couple of instances we have is either too many or > >two few -- why do we *just* have these? > > This is partly a holdover from the previous drafts, but also a > clarification that was discussed on the list, where there was agreement > that an SPI of 0 MUST not be transmitted. Since we earlier say that 1-255 > are reserved, it begs the question as to the status of 0, so I think we > need to say something, either here or in the arch doc. Proposed replacement text about the case of SPI 0: " The SPI value of zero (0) is permanently reserved for implementation-specific use and MUST NOT be sent on the wire. For example, a key management API implementation MAY use the zero SPI value to mean "No Security Association Exists" in the context of the IPsec implementation requesting that its key management entity establish a new IPsec Security Association." I think that more clearly indicates both the interoperability issue (never send SPI of zero) and gives a reasonable illustration of one possible implementation-specific use (without constraining any particular implementation). I know that we found it incredibly useful as implementers to have the zero value be reserved to mean "No SA exists", not only in Key Management API space but also more generally in other bits of implementation-specific code. I've heard from several other implementers that they have also found this useful. Removing that restriction now will make existing conforming implementations suddenly non-conforming, which seems highly undesirable. > >5. My working definition of transport mode has been: the crypto peers > >are both the same as the endpoints for the "original" IP datagram. > >Tunnel mode is when they both aren't the same. > > > >I've heard sentiment that a so-called security gateway should allow > >transport mode connections to/from itself to an IPSEC host/another > >gw. I'm personally somewhat neutral, but we should resolve this. > > One might argue that two hosts could establish a tunnel mode ESP SA between > them to provide better traffic flow security than would be offered by a > transport mdode ESP SA, so I am reluctant to define the difference between > tunnel and transport mode as you suggest. A transport mode SA to a GW > would be OK if the gateway was the destination, e.g., a secured Telnet > session for managing the gateway. But otherwise a transport mode SA should > not be made to a gateway. I fully concur with Steve here. In particular, there are a number of situations in which a pair of hosts that both implement IPsec might (by local policy) wish to create an ESP tunnel between them rather than using ESP transport-mode. Current host implementations generally support this capability, so it would seem counterproductive to eliminate that feature. Also, I agree that a transport-mode sessions ought to be used as he describes. Ran rja@inet.org From owner-ipsec Mon Aug 18 11:14:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA13145 for ipsec-outgoing; Mon, 18 Aug 1997 11:07:11 -0400 (EDT) Message-Id: <2.2.32.19970818151654.00684130@pop.erols.com> X-Sender: tbartee@pop.erols.com (Unverified) X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Aug 1997 11:16:54 -0400 To: ipsec@tis.com From: Thomas Bartee Subject: SAs and SPIs Sender: owner-ipsec@ex.tis.com Precedence: bulk Those of us watching and working with IPSEC and the relevant IETF mail have recently received a number of epistles on the subject of SAs and SPIs. I think Scott Kelley's questions (as yet unanswered) are particularly enlightening (he is from Furukawa.) Similarly, the Atkinsons, Simpson, Kent, Palamber exchanges (the definitions and historical overview resemble a famous Japanese movie which presented the same event viewed by several people. Who can identify this film?) In any case, the exchanges, while enlightening, don't give examples of usage (theoretical or made up ones would be OK.) The SA-SPI pair remains "numbers" leaving us with what logicians call a continuous deferral since in our world everything is numbers.) Also, the question of what actual implementations have in them seems to be open. In order to help with this question can I offer a typical corporate situation and ask how this would be handled (the answer, "with numbers", will not do.) Let us suppose Amgen wants to use IPSEC to control and protect its transmitted and received messages. Within Amgen are a number of projects and the results and data associated with each project need to be protected from outside competitors. Also Amgen employees working on one project only in selected cases are allowed to receive results from other projects. There are managers at several levels who have access to varying parts of the developments. There is also a personnel dept., a medical dept., and a payroll-financial dept. In addition, Amgen has research arrangements with five other biotech firms which work on several of the projects and there is some communication possible between several of them as well as with the relevant Amgen projects. Now, how are the SPI-SA combinations set up to handle this traffic and how are they (dynamically) controlled? Is there a methodology associated with this? Like others on the IPSEC-IETF infoline, I eagerly await a response to the questions in this area. T.C. Bartee ----------------------------------------------- Thomas Q. Bartee The MITRE Corporation Mail Stop W967 1820 Dolley Madison Boulevard McLean, VA 22102 Telephone: (703) 883-7849 E-mail: tbartee@mitre.org From owner-ipsec Mon Aug 18 13:51:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA14390 for ipsec-outgoing; Mon, 18 Aug 1997 13:48:43 -0400 (EDT) Date: Mon, 18 Aug 1997 13:59:09 -0400 Message-Id: <199708181759.NAA02243@brill.shiva.com> From: John Shriver To: tbartee@pop.erols.com CC: ipsec@tis.com In-reply-to: <2.2.32.19970818151654.00684130@pop.erols.com> (message from Thomas Bartee on Mon, 18 Aug 1997 11:16:54 -0400) Subject: Re: SAs and SPIs Sender: owner-ipsec@ex.tis.com Precedence: bulk What you are asking about is NOT what IPSec is about. You are asking about multi-level security. That's about labeling everything with a security level. It's about distrust between the members of the same organization. See the National Computer Security Center "Orange Book". Of see section 25.2 of Schneier's "Applied Cryptography", which gives an introduction. Also, see the RFC's on the IP Security Option. IPsec is primarily about protection from external predators. Not from internal ones. Certainly, anyone paranoid to the Orange Book level would have unique SA's for every transport connection. But, they need to be on C2 or B2 secure systems before IPsec will add any security. (This is not to say that there's isn't plenty of handwaving around the "security policy negotiation" that is envisioned in ISAKMP/Oakley. From owner-ipsec Mon Aug 18 14:17:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA14606 for ipsec-outgoing; Mon, 18 Aug 1997 14:16:11 -0400 (EDT) Message-Id: <3.0.1.32.19970819022209.00866770@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 19 Aug 1997 02:22:09 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: Re: SAs and SPIs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk If we were only worrying about "external predators" we would only need tunnel mode, not transport mode, and I think there is a lot of interest in transport mode. For example there are people who want multiple layers of security so that, e.g., one could have department-level security. Also, it was explicitly pointed out at the IPsec meeting last Friday that connection-level IPsec is a requirement for parts of the community. >From: John Shriver >IPsec is primarily about protection from external predators. Not from >internal ones. > >Certainly, anyone paranoid to the Orange Book level would have unique >SA's for every transport connection. But, they need to be on C2 or B2 >secure systems before IPsec will add any security. From owner-ipsec Mon Aug 18 14:23:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA14692 for ipsec-outgoing; Mon, 18 Aug 1997 14:21:40 -0400 (EDT) Date: Mon, 18 Aug 1997 14:29:03 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199708181829.OAA24822@argon.ncsc.mil> To: ipsec@tis.com Subject: Re: SAs and SPIs X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: John Shriver > > What you are asking about is NOT what IPSec is about. > > You are asking about multi-level security. That's about labeling > everything with a security level. It's about distrust between the > members of the same organization. See the National Computer Security > Center "Orange Book". Of see section 25.2 of Schneier's "Applied > Cryptography", which gives an introduction. Also, see the RFC's on > the IP Security Option. > > IPsec is primarily about protection from external predators. Not from > internal ones. I'm sure the new co-chair of the IPsec working group would be surprised to hear your assertion. Either that, or I'd be *really* surprised to learn that the entire community of auto industry manufacturers and suppliers regards each member of the community as a fully-trusted "insider"! From owner-ipsec Mon Aug 18 16:45:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA15631 for ipsec-outgoing; Mon, 18 Aug 1997 16:44:47 -0400 (EDT) Message-ID: <33F8B642.70D7@fet.com> Date: Mon, 18 Aug 1997 13:53:22 -0700 From: "Scott G. Kelly" Organization: Furukawa Electric Technologies, Inc. X-Mailer: Mozilla 3.03 (Win95; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: lengths of some specifiers Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Call me a stickler for consistency, but I'm a little baffled: why do we require 2 octets to represent SA attributes which are unlikely to ever require more than a few elements of enumeration, (e.g. key/sa lifetypes, replay protection), yet define something so prolific as encryption or hashing tranforms with only one octet? Won't we be sorry if we don't allocate 2 octets for these? Scott From owner-ipsec Mon Aug 18 17:29:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA15833 for ipsec-outgoing; Mon, 18 Aug 1997 17:28:49 -0400 (EDT) Message-ID: <33F8C091.4B68@fet.com> Date: Mon, 18 Aug 1997 14:37:21 -0700 From: "Scott G. Kelly" Organization: Furukawa Electric Technologies, Inc. X-Mailer: Mozilla 3.03 (Win95; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: Re: lengths of some specifiers References: <33F8B642.70D7@fet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Scott G. Kelly wrote: > > Call me a stickler for consistency, but I'm a little baffled: why do we > require 2 octets to represent SA attributes which are unlikely to ever > require more than a few elements of enumeration, (e.g. key/sa lifetypes, > replay protection), yet define something so prolific as encryption or > hashing tranforms with only one octet? Won't we be sorry if we don't > allocate 2 octets for these? > I should also have noted that we're apparently doing the same thing with the security protocol identifier (ESP/AH). I could be convinced that we should let the others go at one octet (even though it seems inconsistent) since they are defined on a per-protocol basis, but leaving the security proto ID at one octet seems short-sighted... Scott From owner-ipsec Mon Aug 18 17:38:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA15886 for ipsec-outgoing; Mon, 18 Aug 1997 17:38:48 -0400 (EDT) Date: Mon, 18 Aug 1997 17:49:38 -0400 Message-Id: <199708182149.RAA02445@brill.shiva.com> From: John Shriver To: dpkemp@missi.ncsc.mil CC: ipsec@tis.com In-reply-to: <199708181829.OAA24822@argon.ncsc.mil> (dpkemp@missi.ncsc.mil) Subject: Re: SAs and SPIs Sender: owner-ipsec@ex.tis.com Precedence: bulk [Hmm, I see that one must speak very carefully and precisely on this list. I figured I was safely educated after reading all of the 1977 postings. Well, you only earn your wings in the IETF by getting them singed...] My first response was obviously too absolute. Or maybe too glib? I didn't make it clear that supporting the IP features for MLS (IPSO, CIPSO) are an important part of IPsec, which is obvious from the I-D's. Or, maybe I misread the intent of Thomas' message? But, if: Amgen employees working on one project only in selected cases are allowed to receive results from other projects. To me, first you have to solve that problem on one shared computer. I think that takes B2 or C2 security at that level. (I don't remember which is stricter: I'll assume B2 from here. I'm sure David knows, given his ncsc.mil e-mail address!) Then, you add IP security labeling to extend that to connections between two B2 secure computers over a non-tappable network. (Say hardware link encryption.) Then, finally, you add IPsec AH and/or ESP to make that connection secure on a tappable network. That's the layering I see. I think that IPsec, AH, ESP, and ISAKMP/Oakley are fundamentally about making a given network connection secure. They are not about ensuring that the data passed over that connection is the data that user is allowed to pass to the peer. (If I'm wrong on this, Randall's description of the Security Policy Database is going to grow...) Obviously, they must dovetail into the existing protocols and extensions that have been developed for TCP/IP to solve that problem. Or, is Thomas' message about inadequate integration between the needs of MLS (IP security option) and IPsec? It's possible that that is the case, that's not an area I've paid much attention to! Thomas? Have I mis-interpreted you? From owner-ipsec Mon Aug 18 18:27:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA16183 for ipsec-outgoing; Mon, 18 Aug 1997 18:27:17 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <33F8C091.4B68@fet.com> References: <33F8B642.70D7@fet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Aug 1997 18:35:25 -0400 To: "Scott G. Kelly" From: Stephen Kent Subject: Re: lengths of some specifiers Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Scott, The protocol ID size for IPsec was determined by the size of the next protocol field in IP, i.e., 8 bits. We had long discussions about the SPI size on the list several years ago and decided to go with 32 bits to allow allocation of multicast SPIs in a separate part of the space, without trying to be bit-wise and alignment-foolish. Given the current fondness for 32-bit and 64-bit aligned data structures, the SPI size also makes sense. Steve From owner-ipsec Mon Aug 18 18:31:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA16211 for ipsec-outgoing; Mon, 18 Aug 1997 18:31:47 -0400 (EDT) Message-Id: <199708182240.PAA12359@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: ipsec@tis.com Subject: replay revisited Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Aug 1997 15:40:31 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk I would like to again bring up the subject of replay prevention in the current (July 21st, 1997) AH and ESP drafts. I do this not because I "lost the argument" but because I feel the issue was not resolved. Mere response to a point does not settle an issue. Consider this a call for a straw poll. After a suitable period of time and debate the co-chairs can call a halt and render a decision either way. It is my contention that replay is for the benefit of the recipient of a packet and is purely a local policy matter. That contention causes me to take issue with three points in section 3.3.3 of ESP draft (and the similar verbage in the AH draft). 1. when using a KMP to establish SAs the receiver should notify the transmitter that it is doing replay protection and what the window size is. 2. window size must be a multiple of 32. 3. when using a window size other than the default of 64 the receiver must notify the transmitter during SA negotiation. (Note that this seems to contradict preceding verbage which says that a window size of 32 is MUST and 64 is SHOULD, but the number itself is not the point of contention). Issues one and three require capability in ISAKMP/Oakley which is currently not there. There is no way to inform ISAKMP peers of any aspect of replay. Issue two is also something that I don't think needs to be part of the protocol specification. If I choose to use a processor with a non-standard word size (e.g. I believe a decsystem 20 is a 36 bit machine) for my new IPSec-compliant toaster I see no reason to prohibit me from using a replay window which matches its word size (on the contrary I see an obvious benefit in doing so). Also, if I'm masochistic-- or just plain stupid-- and choose to implement a window size of 47 bits I see no reason to render an otherwise conformant implementation non-conformant. It would be more reasonable to strongly advise the use of window sizes which are a multiple of the word size of the processor of the box on which the code runs and also to strongly recommend against use of window sizes lower than 32 bits. The argument in favor of the above three points is that it aids in debugging. My response to this is that if such debugging is done in a vacuum one must always assume that the recipient is doing sequence number verification. If he is not then the problem obviously lies elsewhere. If such debugging is not done in a vacuum and the other party is contacted in some way (a simple phone call, checking an IPSec MIB, etc.) to help determine the cause then there is no reason to send this extra information (note I'm all in favor of including replay window information in a MIB). There is also the contention that it's simple to just add the appropriate attributes and accompanying verbage to the DOI to allow ISAKMP to satisfy these requirements. (Note though that it's also simple-- perhaps more simple-- to just strike the problematic text). This would change a significant point in the ISAKMP/Oakley exchange. We'd always operated on the notion that a responder in the exchange can not add or remove attributes from a SA offer. This prevents a man-in-the-middle attack. Of course we could also add verbage to the ISAKMP/Oakley draft expressly allowing *only* the new replay attributes to be added or removed but this now makes the change more complicated both in text added to drafts and modifications to code which is already interoperable. The more complicated code is the more prone to bugs it is and bugs in security protocols can be catastrophic. I think it's important to weigh the benefits of change against this possibility. In the case of the contentious text in the AH and ESP document I see absolutely no benefit. It really is much simpler to just strike the text from the AH and ESP drafts and add the aforementioned text suggesting window sizes be multiples of processor word size and not be less than 32 bits. Please let your opinion be known. regards, Dan. From owner-ipsec Mon Aug 18 18:35:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA16255 for ipsec-outgoing; Mon, 18 Aug 1997 18:35:47 -0400 (EDT) Message-ID: <33F8D039.68C@fet.com> Date: Mon, 18 Aug 1997 15:44:09 -0700 From: "Scott G. Kelly" Organization: Furukawa Electric Technologies, Inc. X-Mailer: Mozilla 3.03 (Win95; U) MIME-Version: 1.0 To: Stephen Kent CC: ipsec@tis.com Subject: Re: lengths of some specifiers References: <33F8B642.70D7@fet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Kent wrote: > > Scott, > > The protocol ID size for IPsec was determined by the size of the > next protocol field in IP, i.e., 8 bits. We had long discussions about the > SPI size on the list several years ago and decided to go with 32 bits to > allow allocation of multicast SPIs in a separate part of the space, without > trying to be bit-wise and alignment-foolish. Given the current fondness > for 32-bit and 64-bit aligned data structures, the SPI size also makes > sense. > > Steve I don't know if you're responding to my whole stream-of-consciousness posting (3 posts, I promise I won't do it again) or just the one post, but it looks like all of them. So, let me see if I understand correctly in that light: the SA attributes are given 2 octets for alignment, while the proto ID's were given 1 octet for IPv4 consistency? Scott From owner-ipsec Mon Aug 18 18:52:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA16329 for ipsec-outgoing; Mon, 18 Aug 1997 18:51:47 -0400 (EDT) Message-ID: From: Roy Pereira To: "'ipsec@tis.com'" , "'Daniel Harkins'" Subject: RE: replay revisited Date: Mon, 18 Aug 1997 19:05:52 -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 We took out the replay attribute in ISAKMP for a purpose and I don't wish to see it back again. We also did away with replay size negotiation (or notification) a longer time ago, and I really don't want to see that back again. >---------- >From: Daniel Harkins[SMTP:dharkins@cisco.com] >Sent: Monday, August 18, 1997 6:40 PM >To: ipsec@tis.com >Subject: replay revisited > > I would like to again bring up the subject of replay prevention in the >current (July 21st, 1997) AH and ESP drafts. I do this not because I "lost >the argument" but because I feel the issue was not resolved. Mere response >to a point does not settle an issue. Consider this a call for a straw poll. >After a suitable period of time and debate the co-chairs can call a halt >and render a decision either way. > > It is my contention that replay is for the benefit of the recipient of >a packet and is purely a local policy matter. That contention causes me >to take issue with three points in section 3.3.3 of ESP draft (and the >similar verbage in the AH draft). > > 1. when using a KMP to establish SAs the receiver should notify > the transmitter that it is doing replay protection and > what the window size is. > > 2. window size must be a multiple of 32. > > 3. when using a window size other than the default of 64 the > receiver must notify the transmitter during SA negotiation. > (Note that this seems to contradict preceding verbage which > says that a window size of 32 is MUST and 64 is SHOULD, but > the number itself is not the point of contention). > > Issues one and three require capability in ISAKMP/Oakley which is currently >not there. There is no way to inform ISAKMP peers of any aspect of replay. > Issue two is also something that I don't think needs to be part of the >protocol specification. If I choose to use a processor with a non-standard >word size (e.g. I believe a decsystem 20 is a 36 bit machine) for my new >IPSec-compliant toaster I see no reason to prohibit me from using a replay >window which matches its word size (on the contrary I see an obvious benefit >in doing so). Also, if I'm masochistic-- or just plain stupid-- and choose >to implement a window size of 47 bits I see no reason to render an otherwise >conformant implementation non-conformant. > It would be more reasonable to strongly advise the use of window sizes >which are a multiple of the word size of the processor of the box on which >the code runs and also to strongly recommend against use of window sizes >lower than 32 bits. > > The argument in favor of the above three points is that it aids in >debugging. My response to this is that if such debugging is done in a vacuum >one must always assume that the recipient is doing sequence number >verification. >If he is not then the problem obviously lies elsewhere. If such debugging >is not done in a vacuum and the other party is contacted in some way (a >simple >phone call, checking an IPSec MIB, etc.) to help determine the cause then >there is no reason to send this extra information (note I'm all in favor of >including replay window information in a MIB). > > There is also the contention that it's simple to just add the appropriate >attributes and accompanying verbage to the DOI to allow ISAKMP to satisfy >these requirements. (Note though that it's also simple-- perhaps more >simple-- >to just strike the problematic text). This would change a significant point >in the ISAKMP/Oakley exchange. We'd always operated on the notion that >a responder in the exchange can not add or remove attributes from a SA offer. >This prevents a man-in-the-middle attack. Of course we could also add verbage >to the ISAKMP/Oakley draft expressly allowing *only* the new replay >attributes >to be added or removed but this now makes the change more complicated both in >text added to drafts and modifications to code which is already >interoperable. > The more complicated code is the more prone to bugs it is and bugs in >security protocols can be catastrophic. I think it's important to weigh the >benefits of change against this possibility. In the case of the contentious >text in the AH and ESP document I see absolutely no benefit. It really is >much >simpler to just strike the text from the AH and ESP drafts and add the >aforementioned text suggesting window sizes be multiples of processor word >size and not be less than 32 bits. > > Please let your opinion be known. > > regards, > > Dan. > > From owner-ipsec Mon Aug 18 19:39:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA16504 for ipsec-outgoing; Mon, 18 Aug 1997 19:38:18 -0400 (EDT) Message-Id: <199708190003.UAA24249@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: replay revisited In-reply-to: Your message of "Mon, 18 Aug 1997 19:05:52 EDT." Date: Mon, 18 Aug 1997 20:03:44 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Roy" == Roy Pereira writes: Roy> We took out the replay attribute in ISAKMP for a purpose and Roy> I don't wish to see it back again. We also did away with Roy> replay size negotiation (or notification) a longer time ago, Roy> and I really don't want to see that back again. Agreed. Let's excise the relevant comments from the ESP/AH drafts. >> ---------- From: Daniel Harkins[SMTP:dharkins@cisco.com] Sent: >> Monday, August 18, 1997 6:40 PM To: ipsec@tis.com Subject: >> replay revisited I think we'll have to excise your: X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 in September, since it doesn't let you edit your responses :-) :!mcr!: | Network security programming, currently Michael Richardson | on contract with DataFellows F-Secure IPSec 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 iQB1AwUBM/ji3qZpLyXYhL+BAQE8/AMAtqZAVUT2pjuowJ8kLPcDRkZIpaI7GS1S PxnnOJq8KINtxyrr/oP1xB9pz8mShVML9T1K9mgCFjPUqjCjcyu3OL7pC9hHi9Kg DdgqYQV1DmFaA7WwglSgqkFSzNVlQYd/ =a2bq -----END PGP SIGNATURE----- From owner-ipsec Mon Aug 18 21:04:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA17001 for ipsec-outgoing; Mon, 18 Aug 1997 21:03:17 -0400 (EDT) Message-Id: <3.0.1.32.19970819090911.008848a0@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 19 Aug 1997 09:09:11 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: replay revisited Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk It has occured to me that the term 'window size' kept making me think of acknowledgement windows. But this isn't an acknowledgement window. There is no concept of the sender somehow sending a few packets and then "waiting for permission to send more" as they would in some sort of flow control situation. All the processing logic of the receiver is self-contained, inside the receiver. Therefore, I believe there is no technical reason for the receiver to tell the sender their 'replay history length' (I propose this as a clearer term) and in fact there is no reason the Replay History Length need be a multiple of 32, 64, or anything else. There might be some sort of cryptographic safety issue, in which case it would be appropriate for a comment to be made, with explanation, as to a requirement for minimum Replay History Length. I believe a suggestion was made in Memphis that it has been found that live Internet traffic can get as far as 40 or so packets out of sync (i.e. packet (n+40) arriving before packet (n) and if that is so then I guess we want to SUGGEST a minimum Replay History Length of 40 (which a wise and lazy programmer on a 32-bit architecture platform would implement as 64, I bet.) >X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol >To: ipsec@tis.com >Subject: replay revisited >Date: Mon, 18 Aug 1997 15:40:31 -0700 >From: Daniel Harkins >Sender: owner-ipsec@ex.tis.com > > I would like to again bring up the subject of replay prevention in the >current (July 21st, 1997) AH and ESP drafts. I do this not because I "lost >the argument" but because I feel the issue was not resolved. Mere response >to a point does not settle an issue. Consider this a call for a straw poll. >After a suitable period of time and debate the co-chairs can call a halt >and render a decision either way. > > It is my contention that replay is for the benefit of the recipient of >a packet and is purely a local policy matter. That contention causes me >to take issue with three points in section 3.3.3 of ESP draft (and the >similar verbage in the AH draft). > > 1. when using a KMP to establish SAs the receiver should notify > the transmitter that it is doing replay protection and > what the window size is. > > 2. window size must be a multiple of 32. > > 3. when using a window size other than the default of 64 the > receiver must notify the transmitter during SA negotiation. > (Note that this seems to contradict preceding verbage which > says that a window size of 32 is MUST and 64 is SHOULD, but > the number itself is not the point of contention). > > Issues one and three require capability in ISAKMP/Oakley which is currently >not there. There is no way to inform ISAKMP peers of any aspect of replay. > Issue two is also something that I don't think needs to be part of the >protocol specification. If I choose to use a processor with a non-standard >word size (e.g. I believe a decsystem 20 is a 36 bit machine) for my new >IPSec-compliant toaster I see no reason to prohibit me from using a replay >window which matches its word size (on the contrary I see an obvious benefit >in doing so). Also, if I'm masochistic-- or just plain stupid-- and choose >to implement a window size of 47 bits I see no reason to render an otherwise >conformant implementation non-conformant. > It would be more reasonable to strongly advise the use of window sizes >which are a multiple of the word size of the processor of the box on which >the code runs and also to strongly recommend against use of window sizes >lower than 32 bits. > > The argument in favor of the above three points is that it aids in >debugging. My response to this is that if such debugging is done in a vacuum >one must always assume that the recipient is doing sequence number verification. >If he is not then the problem obviously lies elsewhere. If such debugging >is not done in a vacuum and the other party is contacted in some way (a simple >phone call, checking an IPSec MIB, etc.) to help determine the cause then >there is no reason to send this extra information (note I'm all in favor of >including replay window information in a MIB). > > There is also the contention that it's simple to just add the appropriate >attributes and accompanying verbage to the DOI to allow ISAKMP to satisfy >these requirements. (Note though that it's also simple-- perhaps more simple-- >to just strike the problematic text). This would change a significant point >in the ISAKMP/Oakley exchange. We'd always operated on the notion that >a responder in the exchange can not add or remove attributes from a SA offer. >This prevents a man-in-the-middle attack. Of course we could also add verbage >to the ISAKMP/Oakley draft expressly allowing *only* the new replay attributes >to be added or removed but this now makes the change more complicated both in >text added to drafts and modifications to code which is already interoperable. > The more complicated code is the more prone to bugs it is and bugs in >security protocols can be catastrophic. I think it's important to weigh the >benefits of change against this possibility. In the case of the contentious >text in the AH and ESP document I see absolutely no benefit. It really is much >simpler to just strike the text from the AH and ESP drafts and add the >aforementioned text suggesting window sizes be multiples of processor word >size and not be less than 32 bits. > > Please let your opinion be known. > > regards, > > Dan. > > > From owner-ipsec Mon Aug 18 21:27:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA17115 for ipsec-outgoing; Mon, 18 Aug 1997 21:26:50 -0400 (EDT) Date: Tue, 19 Aug 97 01:00:50 GMT Daylight Time From: Ran Atkinson Subject: Re: SAs and SPIs To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <2.2.32.19970818151654.00684130@pop.erols.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Mon, 18 Aug 1997 11:16:54 -0400 Thomas Bartee wrote: There are portions of Tom's original note that I simply do not grok. Hence, I'll not attempt to discuss those portions of his note. I'm happy to listen and happy to be educated, but I don't know how to respond meaningfully when I don't understand the question. (Mind, I sometimes have trouble responding meaningfully even when I _do_ understand the question on the floor. :-) :-) > Let us suppose Amgen wants to use IPSEC to control and > protect its transmitted and received messages. Within Amgen are a number of > projects and the results and data associated with each project need to be > protected from outside competitors. Also Amgen employees working on one > project only in selected cases are allowed to receive results from other > projects. There are managers at several levels who have access to varying > parts of the developments. There is also a personnel dept., a medical > dept., and a payroll-financial dept. In addition, Amgen has research > arrangements with five other biotech firms which work on several of the > projects and there is some communication possible between several of them as > well as with the relevant Amgen projects. The above describes a security policy at a high level. The IETF IPsec specs are designed to support a wide variety of different kinds of policy, but the IETF does not mandate any particular security policy. > Now, how are the SPI-SA combinations set up to handle this traffic > and how are they (dynamically) controlled? Mechanistically, one could state that Key Management ("ISAKMP/Oakley plus the IPsec DOI for ISAKMP" probably being the best example instance of Key Management) negotiates the security parameters and creates the IPsec Security Associations as necessary. If the question is about mechanism for setting up SAs, this is the answer (and reading the relevant drafts is the logical next step if one wants to understand the gory details) Less mechanistically, the question above is perhaps considered to mean "How does AMGEN's security policy (whatever it happens to be) get implemented ?". If this is the question, the answer is that an IPsec/ISAKMP/Oakley/DOI implementation ought to have some configuration parameters for the administrator of the system that the IPsec/ISAKMP/Oakley/DOI implementation is running on. The details of that configuration is intrinsically an implementation-specific thing, not a matter of IETF protocols. (ASIDE: The IPsec DOI for ISAKMP has a reasonably complete set of items that can be negotiated if desired; I'm not aware of any major deficiencies in the DOI draft currently online at ftp://ds.internic.net/internet-drafts; I believe that the PF_KEYv2 draft can express at least everything in the IPsec DOI for ISAKMP draft. NB: PF_KEYv2 is not an IETF thingy since its an API spec. The IETF doesn't standardise APIs.). If one considers the situation where all this happens to be running on an MLS UNIX box (B1 or better), then one can imagine that the security policy is driven by (1) the Bell-LaPadula algorithms hardcoded into the Trusted Computing Base and (2) the sensitivity/integrity labels associated with objects in the system. As that TCB wanted to create network sessions, it could use PF_KEYv2 to request/acquire new IPsec SAs from Key Management. It could use the PF_KEYv2 attributes to express the security properties needed for the desired IPsec SAs. Those in turn could be expressed/negotiated securely to/with the remote end via ISAKMP/Oakley. At that end, the KM entity could use PF_KEYv2 to add the appropriate IPsec SAs into that TCB. Now ISAKMP needs to have authentication to prevent man-in-the-middle attacks; of course this is already designed-in. Consider that PK certificates could be used for this purpose and that those certificates could have information (signed by a trusted party) about what kinds of data may be communicated with the identity bound to that certificate. Although not especially a fan of X.509, it seems clear to me that X.509 certificates can contain lots of different kinds of data. > Is there a methodology associated with this? Unclear antecedent "this". Not sure what you mean. Please clarify. NB: For reference, the examples I give above are JUST examples. One could easily imagine different situations, with different security policies, that would be equally legitimate applications for IPsec/ISAKMP/Oakley/DOI technology. Not all IPsec DOI attributes are necessary for all IPsec SAs, either. Ran rja@inet.org From owner-ipsec Tue Aug 19 07:20:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA20283 for ipsec-outgoing; Tue, 19 Aug 1997 07:18:14 -0400 (EDT) Message-Id: <9708182111.AA08669@ditto.tlogic.com> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.1mach v148) X-Nextstep-Mailer: Mail 4.1mach (Enhance 2.0b6) Date: Mon, 18 Aug 97 17:11:18 -0400 Subject: IPSEC and NAT To: ipsec@tis.com From: David Aylesworth Reply-to: dave@tlogic.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Has there been any discussion on using IPSEC in conjuction with Network Address Translation devices? In particular, I'm having problems using Sun's SKIP Source Release 1.0 on a host behind an Ascend P-50 that's doing address translation. Any suggestions would be appreciated. -Dave David Aylesworth Technologic, Inc david.aylesworth@tlogic.com 770/522-0222 x228 From owner-ipsec Tue Aug 19 07:30:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA20423 for ipsec-outgoing; Tue, 19 Aug 1997 07:30:18 -0400 (EDT) Message-Id: <199708191136.HAA04781@raptor.research.att.com> To: dave@tlogic.com cc: ipsec@tis.com Subject: Re: IPSEC and NAT Date: Tue, 19 Aug 1997 07:36:45 -0400 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk Has there been any discussion on using IPSEC in conjuction with Network Address Translation devices? In particular, I'm having problems using Sun's SKIP Source Release 1.0 on a host behind an Ascend P-50 that's doing address translation. Any suggestions would be appreciated. The subject came up at the NAT BoF at the Munich IETF meeting last week. Basically, you can't do IPSEC through a NAT box. You have to terminate the security association at the NAT box, and -- if you want -- create a new security association from the box to the end system. The point is simple: IPSEC guards against tampering with the packet, and NAT boxes by definition tinker with at least the addresses. From owner-ipsec Tue Aug 19 07:47:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA20582 for ipsec-outgoing; Tue, 19 Aug 1997 07:47:17 -0400 (EDT) Date: Tue, 19 Aug 1997 07:47:17 -0400 (EDT) Message-Id: <199708191147.HAA20582@portal.ex.tis.com> From: Ly Loi WAA07116 for ipsec@tis.com; Mon, 18 Aug 1997 22:09:13 -0700 (PDT) Message-Id: <199708190509.WAA07116@snow.NSD.3Com.COM> Subject: Re: replay revisited To: ipsec@tis.com Date: Mon, 18 Aug 97 22:09:12 PDT In-Reply-To: <199708182240.PAA12359@dharkins-ss20>; from "Daniel Harkins" at Aug 18, 97 3:40 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk I apologize in advance if this has already been covered in previous email exchanges but why isn't replay protection at the receiving end a MUST in non-manual keying situations? If someone goes as far as encrypting data for security purposes, he may as well also protect himself against replay which does not require much processing power compared to encryption. I do not see much benefit to issue 3 either unless knowing the window size allows the sender to take corrective measures during the same SA. - Ly > > I would like to again bring up the subject of replay prevention in the > current (July 21st, 1997) AH and ESP drafts. I do this not because I "lost > the argument" but because I feel the issue was not resolved. Mere response > to a point does not settle an issue. Consider this a call for a straw poll. > After a suitable period of time and debate the co-chairs can call a halt > and render a decision either way. > > It is my contention that replay is for the benefit of the recipient of > a packet and is purely a local policy matter. That contention causes me > to take issue with three points in section 3.3.3 of ESP draft (and the > similar verbage in the AH draft). > > 1. when using a KMP to establish SAs the receiver should notify > the transmitter that it is doing replay protection and > what the window size is. > > 2. window size must be a multiple of 32. > > 3. when using a window size other than the default of 64 the > receiver must notify the transmitter during SA negotiation. > (Note that this seems to contradict preceding verbage which > says that a window size of 32 is MUST and 64 is SHOULD, but > the number itself is not the point of contention). > > Issues one and three require capability in ISAKMP/Oakley which is currently > not there. There is no way to inform ISAKMP peers of any aspect of replay. > Issue two is also something that I don't think needs to be part of the > protocol specification. If I choose to use a processor with a non-standard > word size (e.g. I believe a decsystem 20 is a 36 bit machine) for my new > IPSec-compliant toaster I see no reason to prohibit me from using a replay > window which matches its word size (on the contrary I see an obvious benefit > in doing so). Also, if I'm masochistic-- or just plain stupid-- and choose > to implement a window size of 47 bits I see no reason to render an otherwise > conformant implementation non-conformant. > It would be more reasonable to strongly advise the use of window sizes > which are a multiple of the word size of the processor of the box on which > the code runs and also to strongly recommend against use of window sizes > lower than 32 bits. > > The argument in favor of the above three points is that it aids in > debugging. My response to this is that if such debugging is done in a vacuum > one must always assume that the recipient is doing sequence number verification. > If he is not then the problem obviously lies elsewhere. If such debugging > is not done in a vacuum and the other party is contacted in some way (a simple > phone call, checking an IPSec MIB, etc.) to help determine the cause then > there is no reason to send this extra information (note I'm all in favor of > including replay window information in a MIB). > > There is also the contention that it's simple to just add the appropriate > attributes and accompanying verbage to the DOI to allow ISAKMP to satisfy > these requirements. (Note though that it's also simple-- perhaps more simple-- > to just strike the problematic text). This would change a significant point > in the ISAKMP/Oakley exchange. We'd always operated on the notion that > a responder in the exchange can not add or remove attributes from a SA offer. > This prevents a man-in-the-middle attack. Of course we could also add verbage > to the ISAKMP/Oakley draft expressly allowing *only* the new replay attributes > to be added or removed but this now makes the change more complicated both in > text added to drafts and modifications to code which is already interoperable. > The more complicated code is the more prone to bugs it is and bugs in > security protocols can be catastrophic. I think it's important to weigh the > benefits of change against this possibility. In the case of the contentious > text in the AH and ESP document I see absolutely no benefit. It really is much > simpler to just strike the text from the AH and ESP drafts and add the > aforementioned text suggesting window sizes be multiples of processor word > size and not be less than 32 bits. > > Please let your opinion be known. > > regards, > > Dan. > From owner-ipsec Tue Aug 19 07:58:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA20673 for ipsec-outgoing; Tue, 19 Aug 1997 07:58:18 -0400 (EDT) Message-Id: <3.0.3.32.19970819080645.00ae2b40@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 19 Aug 1997 08:06:45 -0400 To: dave@tlogic.com, ipsec@tis.com From: Robert Moskowitz Subject: Re: IPSEC and NAT In-Reply-To: <9708182111.AA08669@ditto.tlogic.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 05:11 PM 8/18/97 -0400, David Aylesworth wrote: >Has there been any discussion on using IPSEC in conjuction with Network >Address Translation devices? In particular, I'm having problems using Sun's >SKIP Source Release 1.0 on a host behind an Ascend P-50 that's doing address >translation. > I have done extensive review of address translation and IPsec. I am preparing an Internet draft covering 16 different NAT senarios for network to network and 4 senarios with 3 road warrior variants for single system to network NAT. All of these only address a single IPsec tunnel. I have YET to tackle multiple tunnels in this format, which I believe will be VERY important. One thing at a time... A number of people have seen my senarios and I have not gotten any negatives on them. As Steve mentioned, the translation occurs before the packet enter the tunnel or after they emerge. I hsve learned that many IPsec vendors cannot 'couple' their IPsec and NAT functions together. I suspect that this will change quickly. This is one of the important items I want to see tested at the upcoming AIAG sponsered IPsec workshop, as NAT is a real world reality (from a co-author of RFC 1918). Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Tue Aug 19 08:15:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20797 for ipsec-outgoing; Tue, 19 Aug 1997 08:14:47 -0400 (EDT) Message-Id: <3.0.1.32.19970819202151.00876e00@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 19 Aug 1997 20:21:51 -0400 To: Ly Loi From: Rodney Thayer Subject: Re: Cc: ipsec@tis.com In-Reply-To: <199708191147.HAA20582@portal.ex.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I believe current consensus is that replay is mandatory to implement for an automatically keyed situation and mandatory to not attempt in a manual keyed situation. [by automatic I mean ISAKMP, by manual I really mean MANUAL, i.e. human intervention and/or static configuration, not "out of band"] At 07:47 AM 8/19/97 -0400, you wrote: >I apologize in advance if this has already been covered >in previous email exchanges but why isn't replay protection >at the receiving end a MUST in non-manual keying situations? From owner-ipsec Tue Aug 19 08:39:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20920 for ipsec-outgoing; Tue, 19 Aug 1997 08:37:48 -0400 (EDT) Message-ID: <33F99B76.2146@erols.com> Date: Tue, 19 Aug 1997 09:11:18 -0400 From: John Horton Reply-To: jehorton@erols.com X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: Ran Atkinson CC: ipsec@tis.com Subject: Re: SAs and SPIs References: <2.2.32.19970818151654.00684130@pop.erols.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran Atkinson wrote: > > Let us suppose Amgen wants to use IPSEC to control and > > protect its transmitted and received messages. Within Amgen are a number of > > projects and the results and data associated with each project need to be > > protected from outside competitors. Also Amgen employees working on one > > project only in selected cases are allowed to receive results from other > > projects. There are managers at several levels who have access to varying > > parts of the developments. There is also a personnel dept., a medical > > dept., and a payroll-financial dept. In addition, Amgen has research > > arrangements with five other biotech firms which work on several of the > > projects and there is some communication possible between several of them as > > well as with the relevant Amgen projects. > > The above describes a security policy at a high level. The IETF IPsec specs > are designed to support a wide variety of different kinds of policy, but the > IETF does not mandate any particular security policy. > > > Now, how are the SPI-SA combinations set up to handle this traffic > > and how are they (dynamically) controlled? I hesitate to jump in here, but here goes. We have what appears to me to be those that talk about implementing security policy, and those that are looking for a description of how the use of IPSEC compliant products will support an implementation in a scenario as described above. The way I read Mr. Bartee's message is that he is looking to ascertain if there is a design and implementation mechanism within the IPSEC RFCs that will provide a feature in products to give security personnel and system administrators the capability to establish "security domains" ( I can feel the backlash from the use of the word domain ;-) ) within an organization that prevents the establishment of SPI-SA combinations and secure data communications between designated groups/departments. If I have missed the mark, my apologies for cluttering up the mailbox of the group. Regards, John Horton From owner-ipsec Tue Aug 19 08:40:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20935 for ipsec-outgoing; Tue, 19 Aug 1997 08:40:18 -0400 (EDT) Message-Id: <3.0.3.32.19970819084834.00b23100@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 19 Aug 1997 08:48:34 -0400 To: ipsec@tis.com From: Robert Moskowitz Subject: Ottawa IPsec Interoperablity Meeting - Sept 22nd Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk The AIAG and Timestep will run an IPsec Interoperablity Meeting (the word 'meeting' is important for customs, 'I am attending a meeting in Ottawa, these systems are needed for my participation at the meeting') in Ottawa Canada, September 22 - 25, 1997. The meeting will be held at Newbridge's campus, providing the participants with excellent testing facilities. Timestep has checked with their External Affairs group and have assured me that there is no problem for US companies to bring their security code into Canada, do development, and return it to the US. I do not know about other countries. The purpose of this workshop is to: Advance the state of IPsec products Ensure product availablity for the automotive industry's ANX project Three activities will occur during this week: Testing of IPsec and Oakley Interoperablity against a function matrix. Validation of X.509 certificates against a cross-certified PKI. VPN senario testing. Documents will follow shortly for all three of these. Vendors are challenged to participate in all of these activities, as favorable results are expected of any vendor that will want to sell to the automotive industry. Each participating vendor will get their own network for testing. Thus Timestep has requested a responable count of participants soon for resource planning. The number of rooms used at Ottawa will be determined by the number of participants. They will be grouped by the type of testing they are planning on doing. Non-testing particpants are also welcomed. But we need to limit them to those that either will be of real assistance to the testers, or need to get real close to the work for their own implementation of IPsec. All non-testing participants will be put into one room on one network. Please send your emails about participation to me at rgm3@chrysler.com. Include in the subject OTTAWA IPSEC so that my Eudora Pro will drop it into a mailbox where I will not miss it! Robert Moskowitz Chrysler Corporation (810) 758-8212 Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Tue Aug 19 09:12:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA21110 for ipsec-outgoing; Tue, 19 Aug 1997 09:11:51 -0400 (EDT) From: hsw@columbia.sparta.com (Howard Weiss) Message-Id: <9708191321.AA03146@katahdin.columbia.sparta.com> Subject: Re: IPSEC and NAT To: smb@research.att.com (Steven Bellovin) Date: Tue, 19 Aug 1997 09:21:11 -0400 (EDT) Cc: dave@tlogic.com, ipsec@tis.com In-Reply-To: <199708191136.HAA04781@raptor.research.att.com> from "Steven Bellovin" at Aug 19, 97 07:36:45 am Organization: SPARTA Inc. (Secure Systems Engineering Division) Usmail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046 Phone: (410) 381-9400 x201 Fax: (410) 381-5559 X-Mailer: ELM [version 2.4PL24 PGP3 ALPHA] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Has there been any discussion on using IPSEC in conjuction > with Network Address Translation devices? In particular, I'm > having problems using Sun's SKIP Source Release 1.0 on a host > behind an Ascend P-50 that's doing address translation. > > Any suggestions would be appreciated. > > The subject came up at the NAT BoF at the Munich IETF meeting last week. > Basically, you can't do IPSEC through a NAT box. You have to terminate > the security association at the NAT box, and -- if you want -- create > a new security association from the box to the end system. > > The point is simple: IPSEC guards against tampering with the packet, > and NAT boxes by definition tinker with at least the addresses. > Couldn't one tunnel through a NAT? -- ___________________________________________________________________ | | |Howard Weiss phone (410) 381-9400 x201 | |SPARTA, Inc. (301) 621-8145 x201 (DC) | |9861 Broken Land Parkway, suite 300 fax: (410) 381-5559 | |Columbia, MD 21046 email: hsw@columbia.sparta.com | |___________________________________________________________________| From owner-ipsec Tue Aug 19 09:56:38 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA21397 for ipsec-outgoing; Tue, 19 Aug 1997 09:55:26 -0400 (EDT) Message-Id: <3.0.3.32.19970819100244.00b6ddd0@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 19 Aug 1997 10:02:44 -0400 To: hsw@columbia.sparta.com (Howard Weiss), smb@research.att.com (Steven Bellovin) From: Robert Moskowitz Subject: Re: IPSEC and NAT Cc: dave@tlogic.com, ipsec@tis.com In-Reply-To: <9708191321.AA03146@katahdin.columbia.sparta.com> References: <199708191136.HAA04781@raptor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 09:21 AM 8/19/97 -0400, Howard Weiss wrote: > >Couldn't one tunnel through a NAT? Well, yes. Then the NAT will only see the outer envelope addresses. The inner envelope addresses will be unaltered (yeah, I know, 'if it is AH only'...). This might be good. It might be disasterous. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Tue Aug 19 09:59:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA21465 for ipsec-outgoing; Tue, 19 Aug 1997 09:59:52 -0400 (EDT) From: pcalhoun@usr.com Mime-Version: 1.0 Date: Tue, 19 Aug 1997 08:51:50 -0500 Message-ID: <3F9AB5E0.3000@usr.com> To: smb@research.att.com (Steven Bellovin), hsw@columbia.sparta.com (Howard Weiss) Cc: dave@tlogic.com, ipsec@tis.com Subject: Re[2]: IPSEC and NAT Content-Type: multipart/mixed; boundary="IMA.Boundary.053000278" Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.053000278 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part The problem you run into is that the initiator of the packet is changed by the NAT. For those of you who do not know what NAT does, it is very simple. Imagine a box which has ONE valid Internet address on one side, and a whole private network on the other (say NET10). When a packet is initiated on the private network, the NAT changes the address to it's public address, and changes the port number to one that is currently un-used by the NAT (it also records the port number to reference the real initiator of the packet's address and port). It then sends out the packet to the internet. Once the packet is received by the target host, it would assume that it needs to setup an SA with the NAT instead of with a host with a private address (which has been changed by the NAT). Since the NAT was not the initiator of the ISAKMP exchange there is alot of confusion. One REALLY STUPID way of doing it is to share the private/public keys between the host and the NAT (I DO NOT RECCOMEND YOU TO DO THIS AT HOME). An alternative is for the NAT to run in tunnel mode on behalf of the initiator (but this assumes that the initiator trusts the NAT, which it probably does not). So, this is the problem. I am anxious to hear of some solutions to get around this limitation. PatC PS: For the record, I also dislike writing protocols around NAT. ______________________________ Reply Separator _________________________________ Subject: Re: IPSEC and NAT Author: hsw@columbia.sparta.com (Howard Weiss) at Internet Date: 8/19/97 9:21 AM > > Has there been any discussion on using IPSEC in conjuction > with Network Address Translation devices? In particular, I'm > having problems using Sun's SKIP Source Release 1.0 on a host > behind an Ascend P-50 that's doing address translation. > > Any suggestions would be appreciated. > > The subject came up at the NAT BoF at the Munich IETF meeting last week. > Basically, you can't do IPSEC through a NAT box. You have to terminate > the security association at the NAT box, and -- if you want -- create > a new security association from the box to the end system. > > The point is simple: IPSEC guards against tampering with the packet, > and NAT boxes by definition tinker with at least the addresses. > Couldn't one tunnel through a NAT? -- ___________________________________________________________________ | | |Howard Weiss phone (410) 381-9400 x201 | |SPARTA, Inc. (301) 621-8145 x201 (DC) | |9861 Broken Land Parkway, suite 300 fax: (410) 381-5559 | |Columbia, MD 21046 email: hsw@columbia.sparta.com | |___________________________________________________________________| --IMA.Boundary.053000278 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 (mailgate.usr.com) by robogate2.usr.com with SMTP (IMA Internet Exchange 2.02 Enterprise) id 3F9A1280; Tue, 19 Aug 97 08:35:36 -0500 Received: from portal.ex.tis.com by usr.com (8.7.5/3.1.090690-US Robotics) id IAA00016; Tue, 19 Aug 1997 08:12:29 -0500 (CDT) Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA21110 for ipsec-outgoing; Tue, 19 Aug 1997 09:11:51 -0400 (EDT) From: hsw@columbia.sparta.com (Howard Weiss) Message-Id: <9708191321.AA03146@katahdin.columbia.sparta.com> Subject: Re: IPSEC and NAT To: smb@research.att.com (Steven Bellovin) Date: Tue, 19 Aug 1997 09:21:11 -0400 (EDT) Cc: dave@tlogic.com, ipsec@tis.com In-Reply-To: <199708191136.HAA04781@raptor.research.att.com> from "Steven Bellovin" at Aug 19, 97 07:36:45 am Organization: SPARTA Inc. (Secure Systems Engineering Division) Usmail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046 Phone: (410) 381-9400 x201 Fax: (410) 381-5559 X-Mailer: ELM [version 2.4PL24 PGP3 ALPHA] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.053000278-- From owner-ipsec Tue Aug 19 10:17:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA21584 for ipsec-outgoing; Tue, 19 Aug 1997 10:16:55 -0400 (EDT) Message-Id: <3.0.3.32.19970819102424.00bdb100@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 19 Aug 1997 10:24:24 -0400 To: pcalhoun@usr.com, smb@research.att.com (Steven Bellovin), hsw@columbia.sparta.com (Howard Weiss) From: Robert Moskowitz Subject: Re: Re[2]: IPSEC and NAT Cc: dave@tlogic.com, ipsec@tis.com In-Reply-To: <3F9AB5E0.3000@usr.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 08:51 AM 8/19/97 -0500, pcalhoun@usr.com wrote: > > One REALLY STUPID way of doing it is to share the private/public keys > between the host and the NAT (I DO NOT RECCOMEND YOU TO DO THIS AT > HOME). An alternative is for the NAT to run in tunnel mode on behalf > of the initiator (but this assumes that the initiator trusts the NAT, > which it probably does not). I really got to do some writing today :) But there are a couple of items I will address here. First off, until IPsec is deployed at hosts and we come to agreement on 'chaining' and/or 'nesting' IPsec tunnels and/or transports, systems behind gateways MUST trust the gateways and gateways MUST trust gateways in proxying these activities. It is probably badness to get into a mode of placing host certificates on gateways. You might as well only use IP addresses for now and work on further deploying IPsec asap. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Tue Aug 19 10:20:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA21624 for ipsec-outgoing; Tue, 19 Aug 1997 10:20:24 -0400 (EDT) From: hsw@columbia.sparta.com (Howard Weiss) Message-Id: <9708191428.AA03292@katahdin.columbia.sparta.com> Subject: Re: Re[2]: IPSEC and NAT To: pcalhoun@usr.com Date: Tue, 19 Aug 1997 10:28:54 -0400 (EDT) Cc: smb@research.att.com, dave@tlogic.com, ipsec@tis.com In-Reply-To: <3F9AB5E0.3000@usr.com> from "pcalhoun@usr.com" at Aug 19, 97 08:51:50 am Organization: SPARTA Inc. (Secure Systems Engineering Division) Usmail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046 Phone: (410) 381-9400 x201 Fax: (410) 381-5559 X-Mailer: ELM [version 2.4PL24 PGP3 ALPHA] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > Once the packet is received by the target host, it would assume that > it needs to setup an SA with the NAT instead of with a host with a > private address (which has been changed by the NAT). Since the NAT was > not the initiator of the ISAKMP exchange there is alot of confusion. > One REALLY STUPID way of doing it is to share the private/public keys > between the host and the NAT (I DO NOT RECCOMEND YOU TO DO THIS AT > HOME). An alternative is for the NAT to run in tunnel mode on behalf > of the initiator (but this assumes that the initiator trusts the NAT, > which it probably does not). But isn't this the same problem as when a Security Gateway sits in front of a protected enclave on non-IPSEC aware hosts? Is the SA between the end-systems or between the Gateway and an end-system (or between two Gateways)? This also plays into one of the "IPSecond useful" items as spelled out by Steve Bellovin last Friday - dynamic discovery of IPSEC topologies. The answer may be that for a installation using IPSEC, it should not use an off-the-shelf NAT box but rather an IPSEC-aware security gateway (e.g., an IPSEC firewall that also does NAT). -- ___________________________________________________________________ | | |Howard Weiss phone (410) 381-9400 x201 | |SPARTA, Inc. (301) 621-8145 x201 (DC) | |9861 Broken Land Parkway, suite 300 fax: (410) 381-5559 | |Columbia, MD 21046 email: hsw@columbia.sparta.com | |___________________________________________________________________| From owner-ipsec Tue Aug 19 10:40:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA21744 for ipsec-outgoing; Tue, 19 Aug 1997 10:39:54 -0400 (EDT) From: bmanning@isi.edu Posted-Date: Tue, 19 Aug 1997 07:46:13 -0700 (PDT) Message-Id: <199708191446.AA19938@zed.isi.edu> Subject: Re: Re[2]: IPSEC and NAT To: rgm3@chrysler.com Date: Tue, 19 Aug 1997 07:46:13 -0700 (PDT) Cc: pcalhoun@usr.com, smb@research.att.com, hsw@columbia.sparta.com, dave@tlogic.com, ipsec@tis.com In-Reply-To: <3.0.3.32.19970819102424.00bdb100@pop3hub.is.chrysler.com> from "Robert Moskowitz" at Aug 19, 97 10:24:24 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 > > One REALLY STUPID way of doing it is to share the private/public keys > > between the host and the NAT (I DO NOT RECCOMEND YOU TO DO THIS AT > > HOME). An alternative is for the NAT to run in tunnel mode on behalf > > of the initiator (but this assumes that the initiator trusts the NAT, > > which it probably does not). > > I really got to do some writing today :) But there are a couple of items I > will address here. First off, until IPsec is deployed at hosts and we come > to agreement on 'chaining' and/or 'nesting' IPsec tunnels and/or > transports, systems behind gateways MUST trust the gateways and gateways > MUST trust gateways in proxying these activities. > > It is probably badness to get into a mode of placing host certificates on > gateways. You might as well only use IP addresses for now and work on > further deploying IPsec asap. > > > Robert Moskowitz > Chrysler Corporation > (810) 758-8212 Er, what happens when the NAT gets its IP addresses dynamically? Or worse, when the system is untethered and does the very interesting multihop thing in conjunction with dynamic renumbering? More tersely, how to maintain the IP/IP secure association when the more persistant internet identifier is the domain name?.... (this is not specifically germain to the list discussion, so please feel free to ignore these comments for now.) --bill From owner-ipsec Tue Aug 19 10:42:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA21792 for ipsec-outgoing; Tue, 19 Aug 1997 10:42:24 -0400 (EDT) From: hsw@columbia.sparta.com (Howard Weiss) Message-Id: <9708191451.AA03374@katahdin.columbia.sparta.com> Subject: Re: SAs and SPIs To: jas@shiva.com (John Shriver) Date: Tue, 19 Aug 1997 10:51:13 -0400 (EDT) Cc: dpkemp@missi.ncsc.mil, ipsec@tis.com In-Reply-To: <199708182149.RAA02445@brill.shiva.com> from "John Shriver" at Aug 18, 97 05:49:38 pm Organization: SPARTA Inc. (Secure Systems Engineering Division) Usmail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046 Phone: (410) 381-9400 x201 Fax: (410) 381-5559 X-Mailer: ELM [version 2.4PL24 PGP3 ALPHA] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > But, if: > > Amgen employees working on one project only in selected cases are > allowed to receive results from other projects. > > To me, first you have to solve that problem on one shared computer. I > think that takes B2 or C2 security at that level. (I don't remember > which is stricter: I'll assume B2 from here. I'm sure David knows, > given his ncsc.mil e-mail address!) B2 requires more security mechanisms and requires an identifiable entity that is referred to as a "reference monitor" or "security kernel." What I don't understand is why you think that this must be solved on a single, shared computer? MLS has it heritage in the ability to intermix users with varying clearances and information of varying sensitivities on the same, single time-sharing system. However, now with client-server architectures, as Sun says, "The network is the computer." The "network-centric" notion is of a network trusted computing base where each workstation may be multilevel secure in that it may handle multiple levels of data depending on who is logged in at what level(s). And the file servers will handle everything simultaneously - but no users are "logged" directly onto the server. > Then, you add IP security labeling to extend that to connections > between two B2 secure computers over a non-tappable network. (Say > hardware link encryption.) And these B2 computers could be workstations - not just mini's or mainframes. > Then, finally, you add IPsec AH and/or ESP to make that connection > secure on a tappable network. > > That's the layering I see. > > > I think that IPsec, AH, ESP, and ISAKMP/Oakley are fundamentally about > making a given network connection secure. They are not about ensuring > that the data passed over that connection is the data that user is > allowed to pass to the peer. (If I'm wrong on this, Randall's > description of the Security Policy Database is going to grow...) But the KM is all about this. Why would two end-systems negotiate keys if they are not allowed to talk to one another. If I've got sensitive data on my system, I don't want some system in the kiosk at Safeway to be able to negotiate an SA with me to be able to obtain my sensitive data (even if it will be protected while in transit across the murky, unsafe network!). Remember, the ISAKMP-DOI spells out the use of a security label. The most recent IPSEC architecture talks about selectors for use in establishing SAs - and one of those selectors is an optional label. Also, the original architecture doc always required per-user level keying - not just machine to machine keying. One could easily extrapolate that the user-to-user keying would be based on a security policy which might enforce classification level, company proprietary information, need-to-know, etc. > Obviously, they must dovetail into the existing protocols and > extensions that have been developed for TCP/IP to solve that problem. > > > Or, is Thomas' message about inadequate integration between the needs > of MLS (IP security option) and IPsec? It's possible that that is the > case, that's not an area I've paid much attention to! Thomas? Have I > mis-interpreted you? > -- ___________________________________________________________________ | | |Howard Weiss phone (410) 381-9400 x201 | |SPARTA, Inc. (301) 621-8145 x201 (DC) | |9861 Broken Land Parkway, suite 300 fax: (410) 381-5559 | |Columbia, MD 21046 email: hsw@columbia.sparta.com | |___________________________________________________________________| From owner-ipsec Tue Aug 19 11:32:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA22115 for ipsec-outgoing; Tue, 19 Aug 1997 11:29:24 -0400 (EDT) Message-Id: <3.0.3.32.19970819113046.00b22b70@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 19 Aug 1997 11:30:46 -0400 To: hsw@columbia.sparta.com (Howard Weiss), pcalhoun@usr.com From: Robert Moskowitz Subject: Re: Re[2]: IPSEC and NAT Cc: smb@research.att.com, dave@tlogic.com, ipsec@tis.com In-Reply-To: <9708191428.AA03292@katahdin.columbia.sparta.com> References: <3F9AB5E0.3000@usr.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:28 AM 8/19/97 -0400, Howard Weiss wrote: > >But isn't this the same problem as when a Security Gateway sits in >front of a protected enclave on non-IPSEC aware hosts? Is the SA >between the end-systems or between the Gateway and an end-system (or >between two Gateways)? This also plays into one of the "IPSecond >useful" items as spelled out by Steve Bellovin last Friday - >dynamic discovery of IPSEC topologies. My plan is to expect an SA pair for each host-to-host situation. This is valuable for each gateway to control policy. >The answer may be that for a installation using IPSEC, it should not >use an off-the-shelf NAT box but rather an IPSEC-aware security >gateway (e.g., an IPSEC firewall that also does NAT). Exactly what I expect. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Tue Aug 19 11:34:01 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA22159 for ipsec-outgoing; Tue, 19 Aug 1997 11:33:53 -0400 (EDT) Message-ID: <01BCAC7B.53326DE0.adams@cisco.com> From: Rob Adams To: "'Roy Pereira'" , "'ipsec@tis.com'" , "'Daniel Harkins'" Subject: RE: replay revisited Date: Mon, 18 Aug 1997 19:42:59 -0700 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-ipsec@ex.tis.com Precedence: bulk I agree with Roy and Dan... I don't think I need to add anything else.. -Rob -----Original Message----- From: Roy Pereira [SMTP:rpereira@TimeStep.com] Sent: Monday, August 18, 1997 4:06 PM To: 'ipsec@tis.com'; 'Daniel Harkins' Subject: RE: replay revisited We took out the replay attribute in ISAKMP for a purpose and I don't wish to see it back again. We also did away with replay size negotiation (or notification) a longer time ago, and I really don't want to see that back again. >---------- >From: Daniel Harkins[SMTP:dharkins@cisco.com] >Sent: Monday, August 18, 1997 6:40 PM >To: ipsec@tis.com >Subject: replay revisited > > I would like to again bring up the subject of replay prevention in the >current (July 21st, 1997) AH and ESP drafts. I do this not because I "lost >the argument" but because I feel the issue was not resolved. Mere response >to a point does not settle an issue. Consider this a call for a straw poll. >After a suitable period of time and debate the co-chairs can call a halt >and render a decision either way. > > It is my contention that replay is for the benefit of the recipient of >a packet and is purely a local policy matter. That contention causes me >to take issue with three points in section 3.3.3 of ESP draft (and the >similar verbage in the AH draft). > > 1. when using a KMP to establish SAs the receiver should notify > the transmitter that it is doing replay protection and > what the window size is. > > 2. window size must be a multiple of 32. > > 3. when using a window size other than the default of 64 the > receiver must notify the transmitter during SA negotiation. > (Note that this seems to contradict preceding verbage which > says that a window size of 32 is MUST and 64 is SHOULD, but > the number itself is not the point of contention). > > Issues one and three require capability in ISAKMP/Oakley which is currently >not there. There is no way to inform ISAKMP peers of any aspect of replay. > Issue two is also something that I don't think needs to be part of the >protocol specification. If I choose to use a processor with a non-standard >word size (e.g. I believe a decsystem 20 is a 36 bit machine) for my new >IPSec-compliant toaster I see no reason to prohibit me from using a replay >window which matches its word size (on the contrary I see an obvious benefit >in doing so). Also, if I'm masochistic-- or just plain stupid-- and choose >to implement a window size of 47 bits I see no reason to render an otherwise >conformant implementation non-conformant. > It would be more reasonable to strongly advise the use of window sizes >which are a multiple of the word size of the processor of the box on which >the code runs and also to strongly recommend against use of window sizes >lower than 32 bits. > > The argument in favor of the above three points is that it aids in >debugging. My response to this is that if such debugging is done in a vacuum >one must always assume that the recipient is doing sequence number >verification. >If he is not then the problem obviously lies elsewhere. If such debugging >is not done in a vacuum and the other party is contacted in some way (a >simple >phone call, checking an IPSec MIB, etc.) to help determine the cause then >there is no reason to send this extra information (note I'm all in favor of >including replay window information in a MIB). > > There is also the contention that it's simple to just add the appropriate >attributes and accompanying verbage to the DOI to allow ISAKMP to satisfy >these requirements. (Note though that it's also simple-- perhaps more >simple-- >to just strike the problematic text). This would change a significant point >in the ISAKMP/Oakley exchange. We'd always operated on the notion that >a responder in the exchange can not add or remove attributes from a SA offer. >This prevents a man-in-the-middle attack. Of course we could also add verbage >to the ISAKMP/Oakley draft expressly allowing *only* the new replay >attributes >to be added or removed but this now makes the change more complicated both in >text added to drafts and modifications to code which is already >interoperable. > The more complicated code is the more prone to bugs it is and bugs in >security protocols can be catastrophic. I think it's important to weigh the >benefits of change against this possibility. In the case of the contentious >text in the AH and ESP document I see absolutely no benefit. It really is >much >simpler to just strike the text from the AH and ESP drafts and add the >aforementioned text suggesting window sizes be multiples of processor word >size and not be less than 32 bits. > > Please let your opinion be known. > > regards, > > Dan. > From owner-ipsec Tue Aug 19 12:15:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA22522 for ipsec-outgoing; Tue, 19 Aug 1997 12:14:55 -0400 (EDT) Message-Id: <199708191640.MAA26963@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: comments on ISAKMP-07/08 diagrams Date: Tue, 19 Aug 1997 12:40:20 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I was doing a tcpdump module for ISAKMP packets (yes, I realize they are encrypted) and discovered that I didn't understand the diagrams in the ISAKMP draft. Why are the bits numbered that way? Okay, it makes some sense for ethernet, since the bits appear on the wire in that way, but most diagrams don't show things that way in the big-endian network byte order world... Or did I just miss the text that explains this. If the bit numbering is left as is, perhaps an "M" could be put int the MSB positions? :!mcr!: | Network security programming, currently Michael Richardson | on contract with DataFellows F-Secure IPSec 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 iQB1AwUBM/nMbqZpLyXYhL+BAQE9jQL/VuUdPKWFkQSSa/cCoKuX+mS8bb/2nRTW VjtDssNYaS0692JnSBa/t22yxXO+8slqY7Ti3obo1sDbgw46w//y3j/qn2qsEKz1 o0RIMJaUaEKZFarbSBNgoriGwztOIzEW =EOmk -----END PGP SIGNATURE----- From owner-ipsec Tue Aug 19 12:53:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA22812 for ipsec-outgoing; Tue, 19 Aug 1997 12:52:25 -0400 (EDT) From: Ly Loi Message-Id: <199708191655.AA14067@boteti.NSD.3Com.COM> Subject: Re: To: rodney@sabletech.com (Rodney Thayer) Date: Tue, 19 Aug 97 9:55:13 PDT Cc: ipsec@tis.com In-Reply-To: <3.0.1.32.19970819202151.00876e00@pop3.pn.com>; from "Rodney Thayer" at Aug 19, 97 8:21 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk Is this for sure? then may be the consensus was reached after the publication of the July ESP and AH drafts because both drafts currently state: "Processing of the Sequence Number field is at the discretion of the receiver, i.e., the sender MUST always transmit this field, but the receiver need not act upont it ..." Now, if the receiver MUST protect against replay attacks (e.g. the ESP/AH drafts will be updated to state so?), then from an implementation point of view, I think the receiver should perform some kind of adaptive algorithm which dynamically adjust the window size as needed. For example, if too many packets are discarded because they fall to the "left edge" of the window, it will increase the window size. In other words, the window size need not be a fixed value. If the receiver MUST perform replay protection and takes corrective measures as too many non-duplicate pkts get dropped, the sender need not know the window size. - Ly > > I believe current consensus is that replay is mandatory to implement for an > automatically keyed situation and mandatory to not attempt in a manual > keyed situation. > > [by automatic I mean ISAKMP, by manual I really mean MANUAL, i.e. human > intervention and/or static configuration, not "out of band"] > > At 07:47 AM 8/19/97 -0400, you wrote: > >I apologize in advance if this has already been covered > >in previous email exchanges but why isn't replay protection > >at the receiving end a MUST in non-manual keying situations? > From owner-ipsec Tue Aug 19 12:57:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA22850 for ipsec-outgoing; Tue, 19 Aug 1997 12:57:25 -0400 (EDT) Date: Tue, 19 Aug 1997 13:08:05 -0400 Message-Id: <199708191708.NAA03798@brill.shiva.com> From: John Shriver To: hsw@columbia.sparta.com CC: dpkemp@missi.ncsc.mil, ipsec@tis.com In-reply-to: <9708191451.AA03374@katahdin.columbia.sparta.com> (hsw@columbia.sparta.com) Subject: Re: SAs and SPIs Sender: owner-ipsec@ex.tis.com Precedence: bulk From: hsw@columbia.sparta.com (Howard Weiss) To: jas@shiva.com (John Shriver) Date: Tue, 19 Aug 1997 10:51:13 -0400 (EDT) [...] > > I think that IPsec, AH, ESP, and ISAKMP/Oakley are fundamentally about > making a given network connection secure. They are not about ensuring > that the data passed over that connection is the data that user is > allowed to pass to the peer. (If I'm wrong on this, Randall's > description of the Security Policy Database is going to grow...) But the KM is all about this. Why would two end-systems negotiate keys if they are not allowed to talk to one another. But, let's suppose that we have ISAKMP/Oakley, and PKIX public keys for the users. Suppose that we think we can solve the problem by each system's ISAKMP daemon having a configured access control list by X.509 usernames. (Not a bad idea.) But that still doesn't solve the proposed problem. User A is in groups 1 and 2. User B is in group 1, user C is in group 2. What is to keep user A from taking a group 1 secret from B, and transferring it to group 2 via C. The same old MLS compartment problem. Unless you assume that any user in more than one security group is trusted, limiting SA's is not sufficient to provide the desired security. The secrets must be labeled, and that labeling preserved across the network. I suppose that since the system will enforce that data received on a connection uses the right SA's, you could implicitly label the SA and the socket, and not have to use the IP Security Option. If I've got sensitive data on my system, I don't want some system in the kiosk at Safeway to be able to negotiate an SA with me to be able to obtain my sensitive data (even if it will be protected while in transit across the murky, unsafe network!). Well, that already in the SPD. You can have a security policy of "no SA's" for a range of IP addresses (like all outside your company). This is explicit -- the "discard" result. Remember, the ISAKMP-DOI spells out the use of a security label. The most recent IPSEC architecture talks about selectors for use in establishing SAs - and one of those selectors is an optional label. As I expected. I presume it's an IP-style one. Also, the original architecture doc always required per-user level keying - not just machine to machine keying. One could easily extrapolate that the user-to-user keying would be based on a security policy which might enforce classification level, company proprietary information, need-to-know, etc. Well, you can do something, as I noted above, but it will not be the same as MLS without MLS systems everywhere. Remember, even if the machine is single-user, that user may have information from seperate compartments. They still need that level of MLS. From owner-ipsec Tue Aug 19 13:31:50 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA23260 for ipsec-outgoing; Tue, 19 Aug 1997 13:31:25 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <33F8D039.68C@fet.com> References: <33F8B642.70D7@fet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Aug 1997 13:27:50 -0400 To: "Scott G. Kelly" From: Stephen Kent Subject: Re: lengths of some specifiers Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk At 3:44 PM -0700 8/18/97, Scott G. Kelly wrote: >I don't know if you're responding to my whole stream-of-consciousness >posting (3 posts, I promise I won't do it again) or just the one post, >but it looks like all of them. So, let me see if I understand correctly >in that light: the SA attributes are given 2 octets for alignment, while >the proto ID's were given 1 octet for IPv4 consistency? > I was not commenting on the ISAKMP encoding of SA attributes, just the AH and ESP field sizes, as I am the editor of these documents. Steve From owner-ipsec Tue Aug 19 15:34:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA24114 for ipsec-outgoing; Tue, 19 Aug 1997 15:32:55 -0400 (EDT) Message-Id: <3.0.3.32.19970819154105.00aa6a50@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 19 Aug 1997 15:41:05 -0400 To: ipsec@tis.com From: Robert Moskowitz Subject: Ottawa IPsec Interoperablity Meeting - Sept 22nd Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Request for detail information: I have received a number of acks. Timestep and I have discussed logistics and there are a few items I need: # of attendees Postal mailing address Special equipment (or services) requirements We wish to have an Aug 26th cutoff for intent to participate, so please get your acks into me with a subject of OTTAWA IPSEC. In the past we have provided a handful of Sun systems and SVGA monitors. We will ATTEMPT to do this again, but I need to get a list. Also for the Sun systems, specify the number of interfaces (I assume 2). We will provide TFTP and DNS servers. We are also planning on a laserjet available via LPR. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Tue Aug 19 16:27:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24517 for ipsec-outgoing; Tue, 19 Aug 1997 16:27:31 -0400 (EDT) Message-Id: <9708192036.AA02305@hpcc103.corp.hp.com> To: ipsec@tis.com Subject: Re: IPSEC and NAT Reply-To: yanfali@corp.hp.com Date: Tue, 19 Aug 1997 13:36:18 -0700 From: Yan-Fa LI Sender: owner-ipsec@ex.tis.com Precedence: bulk A couple of questions to wiser minds, but... Why do NAT in a central location ? One of the things I really dislike about NAT is that sometimes it has to get involved at the application layer to fix certain protocols, e.g. FTP. This slows everything down if the IPSec/NAT has to snoop every packet looking for TCP port 21 and PORT strings. Isn't the IPSec gateway complex enough without introducing NAT ? Why not push the problem out to the individual hosts ? Have the hosts have virtual network interfaces that appear to be on the Internal/Virtual network, just like PPP. This avoids many of the inherent problems of NAT. I remember that Bellovin and Cheswick wrote a paper on just this idea some years ago. Just my $0.02 Y ___________________________________________________________________ | Bio-Routing: | Electronic Connectivity: | | | | | Yan-Fa LI (TIS TR) | Phone: ( +1 ) - 415 424 3680 | | Hewlett-Packard Company | Fax: ( +1 ) - 415 424 3632 | | Mail Stop: 20CX | | | 3000 Hanover Street, | Telnet: 424 - 3680 | | Palo Alto, CA 94304 | Email: yanfali@corp.hp.com | | USA | | |____________________________|______________________________________| From owner-ipsec Tue Aug 19 16:33:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24573 for ipsec-outgoing; Tue, 19 Aug 1997 16:32:57 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199708182240.PAA12359@dharkins-ss20> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Aug 1997 15:52:29 -0400 To: Daniel Harkins From: Stephen Kent Subject: Re: replay revisited Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, > It is my contention that replay is for the benefit of the recipient of >a packet and is purely a local policy matter. That contention causes me >to take issue with three points in section 3.3.3 of ESP draft (and the >similar verbage in the AH draft). > > 1. when using a KMP to establish SAs the receiver should notify > the transmitter that it is doing replay protection and > what the window size is. > > 2. window size must be a multiple of 32. > > 3. when using a window size other than the default of 64 the > receiver must notify the transmitter during SA negotiation. > (Note that this seems to contradict preceding verbage which > says that a window size of 32 is MUST and 64 is SHOULD, but > the number itself is not the point of contention). > > Issues one and three require capability in ISAKMP/Oakley which is currently >not there. There is no way to inform ISAKMP peers of any aspect of replay. Yes, ISAKMP/OAKLEY does not currently support this facility, just as it does not support SAs that have a granularity finer that IP address pairs. In talking with Derrell Piper, the DOI document editor, at the Munich meeting I got the impression that this change would be easy, but I defer to Derrell on this point. > Issue two is also something that I don't think needs to be part of the >protocol specification. If I choose to use a processor with a non-standard >word size (e.g. I believe a decsystem 20 is a 36 bit machine) for my new >IPSec-compliant toaster I see no reason to prohibit me from using a replay >window which matches its word size (on the contrary I see an obvious benefit >in doing so). Also, if I'm masochistic-- or just plain stupid-- and choose >to implement a window size of 47 bits I see no reason to render an otherwise >conformant implementation non-conformant. > > It would be more reasonable to strongly advise the use of window sizes >which are a multiple of the word size of the processor of the box on which >the code runs and also to strongly recommend against use of window sizes >lower than 32 bits. The requirement for a window size that is a multiple of 32 is motivated purely by ease of implementation concerns. A couple of years ago I suggested using a bit mask to track received packets within the window, to allay concerns over the implementation costs of supporting anti-replay. Jim Hughes provided sample code for doing this in his I-Ds, demonstrating that the general notion worked efficiently. Since CPU registers tend to be 32 or 64 bits in length, it was suggested (by Bob Moskowitz?) that the integral multiple of 32 was an appropriate constraint on window sizes. However, I agree that a word size multiple is appropriate, and the multiple of 32 accommodates modren processors with either 32 or 64 bit architectures. You're right, the old DEC-20 is at a disadvantage here and the WG needs to decide if that's acceptable, or not. Finally, the current draft, at Bob Moskowitz's suggestion, calls for a default window size of 64, with 32 as a minimum. > The argument in favor of the above three points is that it aids in >debugging. My response to this is that if such debugging is done in a vacuum >one must always assume that the recipient is doing sequence number >verification. >If he is not then the problem obviously lies elsewhere. If such debugging >is not done in a vacuum and the other party is contacted in some way (a >simple >phone call, checking an IPSec MIB, etc.) to help determine the cause then >there is no reason to send this extra information (note I'm all in favor of >including replay window information in a MIB). Cheryl Madson pointed out in Munich that the sender needs to know whether sequence number cycling is a fatal, auditable error, or not. The only reason that cycling should trigger such a response is if the receiver is enforcing anti-replay. This argues that the receiver must notify the sender of its intent to enforce anti-replay for an SA. I thought the focus of our argument was whether the receiver needed to inform the sender of the window size, in the cases when anti-replay was in effect. The argument I have made was that without such information, the sender has a harder time trying to trouble shoot if there are connection problems. Consider a user connecting to some sort of (non-HTTP) server. If the user has problems, the user will contact his help desk, which then will try to isolate the problem. The folks responsible for the IPsec implementation at the far end may not be readily available (e.g., bacuse of time zone differences) or may not be suitably motivated to quickly assit in identifying the problem. Thus I have advocated making as much info as possible available at the sender's IPsec implementation to facilitate such trouble shooting. It is not clear that the info in the MIB at the receiver's end would be readable by the management folks at the sender's end, so the alternative is being able to get realtime assistance from folks at the receiver's end. For the reasons cited above, and others, this may not always be practical or expedient. > There is also the contention that it's simple to just add the appropriate >attributes and accompanying verbage to the DOI to allow ISAKMP to satisfy >these requirements. (Note though that it's also simple-- perhaps more simple-- >to just strike the problematic text). This would change a significant point >in the ISAKMP/Oakley exchange. We'd always operated on the notion that >a responder in the exchange can not add or remove attributes from a SA offer. >This prevents a man-in-the-middle attack. Of course we could also add verbage >to the ISAKMP/Oakley draft expressly allowing *only* the new replay attributes >to be added or removed but this now makes the change more complicated both in >text added to drafts and modifications to code which is already interoperable. > The more complicated code is the more prone to bugs it is and bugs in >security protocols can be catastrophic. I think it's important to weigh the >benefits of change against this possibility. In the case of the contentious >text in the AH and ESP document I see absolutely no benefit. It really is >much >simpler to just strike the text from the AH and ESP drafts and add the >aforementioned text suggesting window sizes be multiples of processor word >size and not be less than 32 bits. I defer to Derrell as to how easy or hard it is to accommodate this feature, as noted above. We both agree that simpler code is potentially more secure, but providing for good management support also is a laudable goal. The best argument I have heard in favor of not reporting window size was the suggestion Christian made at the meeting, i.e., the possibility of allowing dynamic window sizes based on observed packet drop rates. This is clearly a much fancier approach to window management that we have ever diuscussed in the WG. Moreover, upon futther reflection, it seems very susceptible to denial of service attacks. Specifically, I can replay packets that are likely to be outside of the current window. You can reject them out of hand, or you can validate them and decide that they might be legitimate but oustide of the window, and thus decide to enlarge the window. As the window grows larger than the word/register size, its management becomes more expensive, for every packet received (since one must shift multi-word quantities if there are any gaps in the received packet space, something an atacker may be able to effect by selective deletion). In generalk I would suspect than other approaches to dynamic window management would encounter similar performance penalties, although I certainly can't prove this conjecture. So, on the assumption that simple window management is less prone to error than complex window management, and on the assumption that fault isolation should be facilitated if the complexity costs are not very great, I still recommend reporting the size of the window selected by the receiver. Note that there still appears to be a need for the receiver to notify the sender if the receiver has enabled anti-replay, for the reason cited above (the sender counter overflow error response). Steve From owner-ipsec Tue Aug 19 16:50:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24686 for ipsec-outgoing; Tue, 19 Aug 1997 16:49:55 -0400 (EDT) Message-Id: <3.0.3.32.19970819164757.00ab9470@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 19 Aug 1997 16:47:57 -0400 To: yanfali@corp.hp.com, ipsec@tis.com From: Robert Moskowitz Subject: Re: IPSEC and NAT In-Reply-To: <9708192036.AA02305@hpcc103.corp.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 01:36 PM 8/19/97 -0700, Yan-Fa LI wrote: > >A couple of questions to wiser minds, but... More likely war weary. >Why do NAT in a central location ? One of the things I really dislike >about NAT is that sometimes it has to get involved at the application >layer to fix certain protocols, e.g. FTP. This slows everything down >if the IPSec/NAT has to snoop every packet looking for TCP port 21 and >PORT strings. Isn't the IPSec gateway complex enough without >introducing NAT ? Well you can run it on 2 systems, back to back... >Why not push the problem out to the individual hosts ? Have the hosts >have virtual network interfaces that appear to be on the >Internal/Virtual network, just like PPP. This avoids many of the >inherent problems of NAT. I remember that Bellovin and Cheswick wrote a >paper on just this idea some years ago. Depends. I am writing it up. Having a &^*&)*& of a time formating it nicely, I may punt so I can get it out tomorrow. BTW, I cannot cover all possible hacks. I am not covering things like IP-in-IP tunnels from the router behind the IPsec gateway to the router in front of the host to get around some of the challenges..... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Tue Aug 19 16:59:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24750 for ipsec-outgoing; Tue, 19 Aug 1997 16:58:55 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.1.32.19970819202151.00876e00@pop3.pn.com> References: <199708191147.HAA20582@portal.ex.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Aug 1997 16:46:21 -0400 To: Rodney Thayer From: Stephen Kent Subject: Re: Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney, At 8:21 PM -0400 8/19/97, Rodney Thayer wrote: >I believe current consensus is that replay is mandatory to implement for an >automatically keyed situation and mandatory to not attempt in a manual >keyed situation. > >[by automatic I mean ISAKMP, by manual I really mean MANUAL, i.e. human >intervention and/or static configuration, not "out of band"] > The current drafts only state that anti-replay must not be used for manually keyed SAs; they do not state the converse. I don't recall any WG discussion calling for mandatory use of anti-replay for automatically keyed SAs. However, if we did adopt that stance, it would remove the base requirement for a receiver to advise a sender if anti-replay were enabled at the receiver. Steve From owner-ipsec Tue Aug 19 17:49:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA24979 for ipsec-outgoing; Tue, 19 Aug 1997 17:47:56 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199708191708.NAA03798@brill.shiva.com> References: <9708191451.AA03374@katahdin.columbia.sparta.com> (hsw@columbia.sparta.com) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Aug 1997 17:52:35 -0400 To: John Shriver From: Stephen Kent Subject: Re: SAs and SPIs Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk John, There is a blank section of the architecture document that addresses the MLS issue, more generically described as information flow security models. It is possible to make use of IPsec to support such models, but we are probably going to defer the details to another document, to facilitate faster completion of the current document. However, the general approach would be roughly as follows: - include security authorization info in certificates, so that the authorized processing ranges for each user/host/net is available. this can include hierarchic and non-hierarchic authorizations. - expand the SPD to include references to the sensitivity labels associated with the users/hosts/nets, as a means of expressing data flow access controls - use the authorization info from the certificates as an input to the SA management procedure, along with the SPD, to establish sensitivity ranges for each SA - hosts authorized to process data at multiple levels (compartments, etc.) can use separate SAs for different levels, with implicit labelling for each SA. Steve From owner-ipsec Tue Aug 19 18:17:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA25142 for ipsec-outgoing; Tue, 19 Aug 1997 18:15:26 -0400 (EDT) Date: Tue, 19 Aug 1997 15:22:37 -0700 Message-Id: <199708192222.PAA20706@gump.eng.ascend.com> From: Karl Fox To: yanfali@corp.hp.com Cc: ipsec@tis.com Subject: Re: IPSEC and NAT In-Reply-To: <9708192036.AA02305@hpcc103.corp.hp.com> References: <9708192036.AA02305@hpcc103.corp.hp.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ipsec@ex.tis.com Precedence: bulk Yan-Fa LI writes: > Why not push the problem out to the individual hosts ? Have the hosts > have virtual network interfaces that appear to be on the > Internal/Virtual network, just like PPP. This avoids many of the > inherent problems of NAT. I remember that Bellovin and Cheswick wrote a > paper on just this idea some years ago. Because NAT-in-a-box requires one currently available box, while doing the virtual network interface on every desktop requires currently unavailable software on every desktop. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 From owner-ipsec Tue Aug 19 18:38:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA25240 for ipsec-outgoing; Tue, 19 Aug 1997 18:36:55 -0400 (EDT) Message-Id: <3.0.3.32.19970819154553.00ad9410@ibeam.intel.com> X-Sender: dchouina@ibeam.intel.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 19 Aug 1997 15:45:53 -0700 To: ipsec@tis.com From: Dave Chouinard Subject: Re: IPSEC and NAT In-Reply-To: <199708192222.PAA20706@gump.eng.ascend.com> References: <9708192036.AA02305@hpcc103.corp.hp.com> <9708192036.AA02305@hpcc103.corp.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 03:22 PM 8/19/97 -0700, Karl Fox wrote: >Yan-Fa LI writes: >> Why not push the problem out to the individual hosts ? Have the hosts >> have virtual network interfaces that appear to be on the >> Internal/Virtual network, just like PPP. This avoids many of the >> inherent problems of NAT. I remember that Bellovin and Cheswick wrote a >> paper on just this idea some years ago. > >Because NAT-in-a-box requires one currently available box, while doing >the virtual network interface on every desktop requires currently >unavailable software on every desktop. >-- I believe the real reason is that, in many cases, NAT firewalls are configured to assign addresses "on the fly" as an internal host makes an outgoing connection. Hence, the internal host is unaware that 1.) the NAT firewall exists at all and, 2.) that it has picked an IP address on the outside of the firewall to represent the internal host for the time of the connection. It would seem for this virtual interface concept to work (like PPP), there would need to be a dynamic way to get the temporary IP address assigned to a given host, which would involve some protocol between the host and the firewall. However, since the goal of the NAT firewall is to be transparent to the host, there is currently no defined way of doing such a thing. =========================================================================== Dave Chouinard (Please note that all opinions expressed here are Intel Architecture Labs mine and are not necessarily shared by Intel) dchouinard@ibeam.intel.com (503)264-7481 *** Public key available by request *** Key fingerprint =88 35 F6 22 71 54 5E 98 0B D7 12 B6 3C 73 43 4E From owner-ipsec Tue Aug 19 21:06:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA25997 for ipsec-outgoing; Tue, 19 Aug 1997 21:03:56 -0400 (EDT) Message-Id: <9708200112.AA05990@hpcc103.corp.hp.com> To: Dave Chouinard Cc: ipsec@tis.com Subject: Re: IPSEC and NAT In-Reply-To: Your message of Tue, 19 Aug 1997 15:45:53 -0700. <3.0.3.32.19970819154553.00ad9410@ibeam.intel.com> Date: Tue, 19 Aug 1997 18:12:56 -0700 From: Yan-Fa LI Sender: owner-ipsec@ex.tis.com Precedence: bulk Dave Chouinard Wrote: > At 03:22 PM 8/19/97 -0700, Karl Fox wrote: > >Yan-Fa LI writes: > >> Why not push the problem out to the individual hosts ? Have the hosts > >> have virtual network interfaces that appear to be on the > >> Internal/Virtual network, just like PPP. This avoids many of the > >> inherent problems of NAT. I remember that Bellovin and Cheswick wrote a > >> paper on just this idea some years ago. > > > >Because NAT-in-a-box requires one currently available box, while doing > >the virtual network interface on every desktop requires currently > >unavailable software on every desktop. > >-- > > > I believe the real reason is that, in many cases, NAT firewalls are > configured to assign addresses "on the fly" as an internal host makes an > outgoing connection. Hence, the internal host is unaware that 1.) the NAT > firewall exists at all and, 2.) that it has picked an IP address on the > outside of the firewall to represent the internal host for the time of the > connection. > > It would seem for this virtual interface concept to work (like PPP), there > would need to be a dynamic way to get the temporary IP address assigned to > a given host, which would involve some protocol between the host and the > firewall. However, since the goal of the NAT firewall is to be transparent > to the host, there is currently no defined way of doing such a thing. > Very good point. One of things I always punt on for this particular part of my idea is that there isn't actually a protocol for an encryption server device to negotiate this information with an encryption client. However, some workable protocols are around such as LT2P and PPTP point to the right way of doing this. Sincerely, Yan ___________________________________________________________________ | Bio-Routing: | Electronic Connectivity: | | | | | Yan-Fa LI (CNS PAR) | Phone: ( +1 ) - 415 424 3680 | | Hewlett-Packard Company | Fax: ( +1 ) - 415 424 3632 | | Mail Stop: 20CX | | | 3000 Hanover Street, | Telnet: 424 - 3680 | | Palo Alto, CA 94304 | Email: yanfali@corp.hp.com | | USA | | |____________________________|______________________________________| My views do not necessarily represent those of the Hewlett Packard Company and should be taken with a large dose of salt or whatever passes for sodium in your neck of the woods/universe/continuum/etc... ___________________________________________________________________ From owner-ipsec Wed Aug 20 06:23:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA28666 for ipsec-outgoing; Wed, 20 Aug 1997 06:19:27 -0400 (EDT) From: Tim Bass (IETF) Message-Id: <199708201027.GAA03314@linux.silkroad.com> Subject: Re: IPSEC and NAT To: ipsec@tis.com Date: Wed, 20 Aug 1997 06:27:28 -0400 (EDT) In-Reply-To: <9708200112.AA05990@hpcc103.corp.hp.com> from "Yan-Fa LI" at Aug 19, 97 06:12:56 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk After following this thread with great interest, it appears that IPSEC has marginalized NAT. If this in indeed the case, this is 'not a good thing', IHMO. NAT is an important 'fact of life' which need to be considered as a requirement which IPSEC should embrace. Could someone explain why NAT appears to be out of the IPSEC requirements radar screen? Thanks, Tim +--------------------------------------------------------------------------+ | Tim Bass | #include | | Technical Director | for(beer=100;beer>1;beer++){ | | SAIC | take_one_down(); | | Center for Information Protection | pass_it_around(); | | | } | | | back_ to_work(); /*never reached */| +--------------------------------------------------------------------------+ From owner-ipsec Wed Aug 20 07:03:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA28901 for ipsec-outgoing; Wed, 20 Aug 1997 07:01:59 -0400 (EDT) Message-Id: <3.0.3.32.19970820070811.00a95100@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 20 Aug 1997 07:08:11 -0400 To: Tim Bass (IETF) , ipsec@tis.com From: Robert Moskowitz Subject: Re: IPSEC and NAT In-Reply-To: <199708201027.GAA03314@linux.silkroad.com> References: <9708200112.AA05990@hpcc103.corp.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 06:27 AM 8/20/97 -0400, IETF wrote: > >After following this thread with great interest, it appears that IPSEC >has marginalized NAT. If this in indeed the case, this is 'not a good >thing', IHMO. NAT is an important 'fact of life' which need to be >considered as a requirement which IPSEC should embrace. > >Could someone explain why NAT appears to be out of the IPSEC requirements >radar screen? Tim, this is one of your IPsec co-chairs speaking. IPsec is about securing IP packets. NAT is about fiddling with IP packet headers, and in some cases data content. Thus they are going in opposite directions. IPsec makes VPNs possible between two networks in ways not considered before due to 'saftey' reasons. This accentuates NAT issues. IPsec is a communication 'pipe'. A good designer will not find that IPsec has 'marginalized' NAT, rather, it has increased the applications for NAT, and defined places where NAT COULD be performed. IPsec on end-points MAY eliminate much of the NAT concerns created by IPsec on gateways, but I still need to walk around the building a dozen times more before I can write that one up :) NAT IS out of scope for the IPsec wg; not in our charter. HOWEVER, being good IETFers, we will spend the time to scope out the inpact of IPsec and NAT and then see what work needs to be done. Stay tune, I should get the 1st cut over to Rodney this morning and then we will post the URL. I will also send it on the ID for publishing, but that will lag a bit. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Aug 20 07:14:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA28983 for ipsec-outgoing; Wed, 20 Aug 1997 07:12:26 -0400 (EDT) Message-Id: <199708201119.HAA29509@raptor.research.att.com> To: Tim Bass (IETF) cc: ipsec@tis.com Subject: Re: IPSEC and NAT Date: Wed, 20 Aug 1997 07:19:12 -0400 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk After following this thread with great interest, it appears that IPSEC has marginalized NAT. If this in indeed the case, this is 'not a good thing', IHMO. NAT is an important 'fact of life' which need to be considered as a requirement which IPSEC should embrace. Could someone explain why NAT appears to be out of the IPSEC requirements radar screen? Because they're inherently incompatible. NAT is not just incompatible with IPSEC, but with many other forms of cryptography as well, such as SSL and GSS-API (how can you scan an FTP session for PORT commands if it's encrypted?) and DNSSEC (how can you diddle addresses of a signed record?). That said, one can (as noted) terminate the IPSEC session at the NAT box, just as one can terminate IPSEC at other forms of firewall. But there's not really any other way of getting around the basic contradiction -- NAT boxes are all about inspecting and changing packets, and cryptography is all about protecting packets from inspection and modification. From owner-ipsec Wed Aug 20 07:16:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA28996 for ipsec-outgoing; Wed, 20 Aug 1997 07:14:54 -0400 (EDT) Message-Id: <199708201122.HAA29840@raptor.research.att.com> To: rgm3@chrysler.com cc: Tim Bass (IETF) , ipsec@tis.com Subject: Re: IPSEC and NAT Date: Wed, 20 Aug 1997 07:22:49 -0400 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk NAT IS out of scope for the IPsec wg; not in our charter. HOWEVER, being good IETFers, we will spend the time to scope out the inpact of IPsec and NAT and then see what work needs to be done. For folks who weren't in Munich -- I spoke at the ipsec slot on remaining work items. My recommendation is that a new group (which I've dubbed ipsecond) be formed to take over some of the complex issues. One that I explicitly listed was complex topology discovery, which most definitely does include NAT boxes. For now, though, NAT boxes are just another form of firewall, and you'll either have to deploy a bump-in-the-wire ipsec box outboard of your NAT, or lean on your vendor to integrate the two. From owner-ipsec Wed Aug 20 07:48:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA29220 for ipsec-outgoing; Wed, 20 Aug 1997 07:46:25 -0400 (EDT) Message-ID: <33FA5C79.7F211E9E@bellsouth.net> Date: Tue, 19 Aug 1997 22:54:49 -0400 From: David Aylesworth Reply-To: dave@tlogic.com Organization: Technologic, Inc. X-Mailer: Mozilla 4.01 [en] (Win95; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: Re: SKIP and NAT X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Thanks for all the helpful replies (basically telling me this can't work!). I think though, that this isn't a very unusual situation. Here's the details: The SKIP gateway is a firewall (with a private IP address) that goes through an Ascend ISDN router to connect to an ISP which assigns an IP address dynamically. In this configuration, the Ascend box translates all outgoing packets to the dynamic IP address and translates incoming packets to the last internal address that it saw (always the firewall's in this case). When I first tried to configure SKIP on the firewall to encrypt traffic to another SKIP host (running Elvis+), the remote SKIP complained of authentication failures when pinged (no surprise). I turned off the authentication headers, then the remote SKIP accepted the ICMP echo request from the translated address, but tried to send the echo reply to the original address unencrypted (no surprise here either). So I configured the remote SKIP to use the dynamic address as a tunnel address for packets destined to the firewall's fixed private address. Now the echo replies are encrypted, sent to the dynamic Ascend address, translated by the Ascend to the firewall's address, and sent to the firewall. The firewall receives them and SKIP seems to decode the packets, but the packet filter sitting above SKIP on the firewall complains that the packets have a protocol field of 0! I wonder if this is a "feature" of IPSEC, or a "bug" in Sun SKIP. It was suggested that the SKIP implementation may intentionally rewrite IP headers with protocol 0 as a way to ensure that a "bad" packet gets discarded. I will have to research this further. Thanks, Dave David Aylesworth Technologic, Inc. dave@tlogic.com From owner-ipsec Wed Aug 20 08:58:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA29676 for ipsec-outgoing; Wed, 20 Aug 1997 08:56:55 -0400 (EDT) Message-Id: <3.0.1.32.19970820090134.007cd3b0@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 20 Aug 1997 09:01:34 -0400 To: ietf@linux.silkroad.com From: Rodney Thayer Subject: Re: IPSEC and NAT Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk >From an implementor's view, NAT and IPsec are solving different problems. I don't feel like IPsec is ignoring NAT, but the nature of the two does mean it's more than a trivial task to apply a combination of the technologies. I consider it a *feature* that we have IPsec (relatively) stable enough that we all have time to think about NAT. The development of technically sound and cryptographically safe combinations of NAT and IPsec will take some work, and is an opportunity for the vendor community and the standards community to solve some interesting problems. Trust me, I'm not ignoring NAT. I have customers bugging me to work on it... >To: rgm3@chrysler.com >cc: Tim Bass (IETF) , ipsec@tis.com >Subject: Re: IPSEC and NAT >Date: Wed, 20 Aug 1997 07:22:49 -0400 >From: Steven Bellovin >Sender: owner-ipsec@ex.tis.com > > NAT IS out of scope for the IPsec wg; not in our charter. > HOWEVER, being good IETFers, we will spend the time to scope > out the inpact of IPsec and NAT and then see what work needs > to be done. > >For folks who weren't in Munich -- I spoke at the ipsec slot on remaining >work items. My recommendation is that a new group (which I've dubbed >ipsecond) be formed to take over some of the complex issues. One that >I explicitly listed was complex topology discovery, which most definitely >does include NAT boxes. For now, though, NAT boxes are just another form >of firewall, and you'll either have to deploy a bump-in-the-wire ipsec >box outboard of your NAT, or lean on your vendor to integrate the two. > > From owner-ipsec Wed Aug 20 08:58:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA29665 for ipsec-outgoing; Wed, 20 Aug 1997 08:55:56 -0400 (EDT) Message-Id: <3.0.1.32.19970820085258.007cdaa0@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 20 Aug 1997 08:52:58 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: comments on replay processing Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk [In response to Steve Kent's observation that I may have recalled the WG discussion inacurately, I originally was going to go back and check the archives to find my error, but then I decided it would be more productive to simply state my opinion. I'm *not* trying to change anything here, so if I've messed up something relative to the current draft set, it's my error.] For Receiver Sequence Number Processing, I think that what we should have is: 1. receiver extracts sequence number from the packet 2.1 if sequence number is NOT within the current expected range then 2.2 take action because a replay attack may be underway else 2.3 life goes on Now I don't think the 'action' at step 2.2 is standardized in the draft, I think it's a local implementation issue. One might delete the SA, call out the Marines, dump core and halt, output a mild message to the operator console, output an SNMP Trap, etc. etc. I specifically don't think the 'action' is required to include any feedback to the sender. Therefore, I don't think there is any way the sender is aware of receiver replay processing. This includes any knowledge of what the receiver's replay history size is. Furthermore I don't think there is anything the sender could do about it. Since there is no feedback in the 'normal' case and no feedback in the case of an asynchronously deleted SA, I don't see what reaction, negative or positive, the sender can have. I think the receiver should always implement replay checking. If we think this is a safety thing, then we should require it. I don't think the issue is whether or not we can wiggle the DOI by adding another parameter number. The issue with ISAKMP is that adding an interaction increases the complexity of an already complex situation and I don't think we should be doing that. Furthermore, whether my opinion is something people agree with or not I don't think we should be modifying the ISAKMP message traffic at this stage in the document process -- I think this is a fine item to put on the "Useful but not Criticial Path" list. From owner-ipsec Wed Aug 20 09:02:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA29736 for ipsec-outgoing; Wed, 20 Aug 1997 09:01:27 -0400 (EDT) Date: Wed, 20 Aug 1997 09:08:58 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199708201308.JAA27461@argon.ncsc.mil> To: ipsec@tis.com Subject: Re: anti-replay notification X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Stephen Kent > > The current drafts only state that anti-replay must not be used for > manually keyed SAs; they do not state the converse. I don't recall any WG > discussion calling for mandatory use of anti-replay for automatically keyed > SAs. However, if we did adopt that stance, it would remove the base > requirement for a receiver to advise a sender if anti-replay were enabled > at the receiver. If, for automatically-keyed SA's, anti-replay may be used, then why not just require the sender to behave conservatively and assume that it is always being used. I.e. never cycle the counter, and don't require AR notification. That would have the same effect as making anti-replay mandatory (force rekeying before overflow), but would not force thin receivers to implement AR just for the sake of compliance with the spec. Even if AR notification is simple to add to ISAKMP, it's just one more detail to code, one more complication to the spec, one more option to analyze. Philosophically, I lean toward not negotiating things unless there's a strong benefit to doing so. In this case, the benefit (allowing SAs to last beyond counter cycling if the receiver is not doing AR checking) is vanishingly small. The debugging benefits of AR window size notification also seem pretty slim, but I'll defer to the folks with actual implementation/testing experience to settle that point. From owner-ipsec Wed Aug 20 09:16:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA29879 for ipsec-outgoing; Wed, 20 Aug 1997 09:14:55 -0400 (EDT) From: pcalhoun@usr.com Mime-Version: 1.0 Date: Wed, 20 Aug 1997 08:12:50 -0500 Message-ID: <3FAF2750.3000@usr.com> To: ipsec@tis.com, Yan-Fa LI Subject: Re[2]: IPSEC and NAT Content-Type: multipart/mixed; boundary="IMA.Boundary.580480278" Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.580480278 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part But doesn't this assume that the host has both a private AND a public address? The reason for NAT is that a network lives on a network using a private addressing scheme. PatC ______________________________ Reply Separator _________________________________ Subject: Re: IPSEC and NAT Author: Yan-Fa LI at Internet Date: 8/19/97 1:36 PM A couple of questions to wiser minds, but... Why do NAT in a central location ? One of the things I really dislike about NAT is that sometimes it has to get involved at the application layer to fix certain protocols, e.g. FTP. This slows everything down if the IPSec/NAT has to snoop every packet looking for TCP port 21 and PORT strings. Isn't the IPSec gateway complex enough without introducing NAT ? Why not push the problem out to the individual hosts ? Have the hosts have virtual network interfaces that appear to be on the Internal/Virtual network, just like PPP. This avoids many of the inherent problems of NAT. I remember that Bellovin and Cheswick wrote a paper on just this idea some years ago. Just my $0.02 Y ___________________________________________________________________ | Bio-Routing: | Electronic Connectivity: | | | | | Yan-Fa LI (TIS TR) | Phone: ( +1 ) - 415 424 3680 | | Hewlett-Packard Company | Fax: ( +1 ) - 415 424 3632 | | Mail Stop: 20CX | | | 3000 Hanover Street, | Telnet: 424 - 3680 | | Palo Alto, CA 94304 | Email: yanfali@corp.hp.com | | USA | | |____________________________|______________________________________| --IMA.Boundary.580480278 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 (mailgate.usr.com) by robogate2.usr.com with SMTP (IMA Internet Exchange 2.02 Enterprise) id 3FA078B0; Tue, 19 Aug 97 15:52:28 -0500 Received: from portal.ex.tis.com by usr.com (8.7.5/3.1.090690-US Robotics) id PAA22049; Tue, 19 Aug 1997 15:29:16 -0500 (CDT) Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA24517 for ipsec-outgoing; Tue, 19 Aug 1997 16:27:31 -0400 (EDT) Message-Id: <9708192036.AA02305@hpcc103.corp.hp.com> To: ipsec@tis.com Subject: Re: IPSEC and NAT Reply-To: yanfali@corp.hp.com Date: Tue, 19 Aug 1997 13:36:18 -0700 From: Yan-Fa LI Sender: owner-ipsec@ex.tis.com Precedence: bulk --IMA.Boundary.580480278-- From owner-ipsec Wed Aug 20 10:20:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA00401 for ipsec-outgoing; Wed, 20 Aug 1997 10:18:32 -0400 (EDT) Message-Id: <3.0.32.19970820104510.009aade0@pop.rv.tis.com> X-Sender: wei@pop.rv.tis.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 20 Aug 1997 10:45:11 -0400 To: dave@tlogic.com From: Wei Xu Subject: Re: SKIP and NAT Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:54 PM 8/19/97 -0400, David Aylesworth wrote: >Thanks for all the helpful replies (basically telling me this can't >work!). I think though, that this isn't a very unusual situation. >Here's the details: > >The SKIP gateway is a firewall (with a private IP address) that goes >through an Ascend ISDN router to connect to an ISP which assigns an IP >address dynamically. In this configuration, the Ascend box translates >all outgoing packets to the dynamic IP address and translates incoming >packets to the last internal address that it saw (always the firewall's >in this case). > >When I first tried to configure SKIP on the firewall to encrypt traffic >to another SKIP host (running Elvis+), the remote SKIP complained of >authentication failures when pinged (no surprise). I turned off the >authentication headers, then the remote SKIP accepted the ICMP echo >request from the translated address, but tried to send the echo reply to >the original address unencrypted (no surprise here either). So I >configured the remote SKIP to use the dynamic address as a tunnel >address for packets destined to the firewall's fixed private address. >Now the echo replies are encrypted, sent to the dynamic Ascend address, >translated by the Ascend to the firewall's address, and sent to the >firewall. The firewall receives them and SKIP seems to decode the >packets, but the packet filter sitting above SKIP on the firewall >complains that the packets have a protocol field of 0! > >I wonder if this is a "feature" of IPSEC, or a "bug" in Sun SKIP. It >was suggested that the SKIP implementation may intentionally rewrite IP >headers with protocol 0 as a way to ensure that a "bad" packet gets >discarded. I will have to research this further. Looks to me. SKIP don't understand IP protocol 50 and 51 which is IPSec specific. During the translation SKIP puts protocol 0 to indicate un-recorganized IP packets. Wei Trusted Information Systems, Inc. > >Thanks, >Dave > >David Aylesworth >Technologic, Inc. >dave@tlogic.com > > > > > > From owner-ipsec Wed Aug 20 10:28:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA00533 for ipsec-outgoing; Wed, 20 Aug 1997 10:26:31 -0400 (EDT) From: Tim Bass (IETF) Message-Id: <199708201434.KAA00430@linux.silkroad.com> Subject: Re: IPSEC and NAT To: ipsec@tis.com Date: Wed, 20 Aug 1997 10:34:14 -0400 (EDT) In-Reply-To: <199708201122.HAA29840@raptor.research.att.com> from "Steven Bellovin" at Aug 20, 97 07:22:49 am X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Two interesting points were made, one related to NAT and one related to cryptography, which beg further disussion. Hence, I'll make these small arguments in hope the topic is appropriate to IPSEC WG: (1) Cryptography is about techniques to insure confidentality, integrity, non-repudiation, authentication, (all the basics we all know and love :) for messaging. Bulk encryption does this by 'not fiddling with bits' as one described in a reply. However, it is not clear, IMHO, that this model is a necessary requirement for IPSEC. Is IPSEC just an IP 'centric bulkish' encryption :) Hmmmm. (2) NAT is more than 'just a firewall technology'. It is a generalized method of translating IP address and its roots were in IP routing scalability issues (right?) and many use NAT as a basic tool for IP address space management. Having touched on (1,2) above, one could develop a rational argument that IPSEC should be designed to work with NAT, not orthogonal to NAT, because NAT has become a basic fact of life in both IP Firewalls and IP address space management. One the other hand, one could argue differently :) My closing thoughts are these, and correct me if I am wrong; doing address translation integrated into IPSEC is 'too difficult' or 'too much work' for the IPSEC to consider. Or, is it more like 'if IPSEC WG builds hooks for NAT' then the precedence has been set for 'more and more IPSEC requirements and accomodations'. Thanks for the time on the 'floor' :) V/R, Tim From owner-ipsec Wed Aug 20 10:46:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA00643 for ipsec-outgoing; Wed, 20 Aug 1997 10:44:35 -0400 (EDT) Date: Wed, 20 Aug 97 14:31:17 GMT Daylight Time From: Ran Atkinson Subject: Re: SKIP and NAT To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <3.0.32.19970820104510.009aade0@pop.rv.tis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Wed, 20 Aug 1997 10:45:11 -0400 Wei Xu wrote: > >I wonder if this is a "feature" of IPSEC, or a "bug" in Sun SKIP. It > >was suggested that the SKIP implementation may intentionally rewrite IP > >headers with protocol 0 as a way to ensure that a "bad" packet gets > >discarded. I will have to research this further. > > Looks to me. SKIP don't understand IP protocol 50 and 51 which is IPSec > specific. During the translation SKIP puts protocol 0 to indicate > un-recorganized IP packets. Most versions of "SKIP the product" from Sun do not normally use "SKIP the KM protocol proposal for ESP/AH" made by Sun to the IETF. In particular, older versions of "SKIP the product" do not use or understand IPsec ESP/AH at all. Given the availability of real IPsec from multiple vendors (as was obvious at Interop last May in LV), it isn't clear to me why anyone in the real world would want to purchase/deploy any proprietary encryption scheme. Certainly I won't be doing so (We have IPsec in limited deployment now in a commercial environment). Since SKIP isn't IPsec, I suppose this note is off-topic so I'll probably not comment further. Ran rja@inet.org From owner-ipsec Wed Aug 20 10:56:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA00729 for ipsec-outgoing; Wed, 20 Aug 1997 10:55:03 -0400 (EDT) Date: Wed, 20 Aug 97 14:45:04 GMT Daylight Time From: Ran Atkinson Subject: Re: IPSEC and NAT To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199708201434.KAA00430@linux.silkroad.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Wed, 20 Aug 1997 10:34:14 -0400 (EDT) Tim Bass wrote: > Two interesting points were made, one related to NAT > and one related to cryptography, which beg further disussion. > Hence, I'll make these small arguments in hope the > topic is appropriate to IPSEC WG: > > (1) Cryptography is about techniques to insure confidentality, > integrity, non-repudiation, authentication, (all the basics > we all know and love :) for messaging. Bulk encryption does > this by 'not fiddling with bits' as one described in a reply. > However, it is not clear, IMHO, that this model is a necessary > requirement for IPSEC. Is IPSEC just an IP 'centric bulkish' > encryption :) Hmmmm. Cases other than "bulk encryption" (e.g. AH with RFC-1828 end-to-end authentication) provide end-to-end protections against a packet being altered in transit. The "end-to-end" property is important and was explicitly part of the goal/charter of IPsec (dating back to 1991). So your assertion (1) above is imprecise at best. > (2) NAT is more than 'just a firewall technology'. It is a generalized > method of translating IP address and its roots were in IP routing > scalability issues (right?) and many use NAT as a basic tool > for IP address space management. Again, I'm not comfortable with your level of precision. NAT is not a firewall technology -- its an dynamic address translation technology. Address translation by itself has no interesting security properties and little to do with firewalls. DHCP is a good example of basic tool for IP address space management. > Having touched on (1,2) above, one could develop a rational argument that > IPSEC should be designed to work with NAT, not orthogonal to NAT, because > NAT has become a basic fact of life in both IP Firewalls and IP address > space management. One the other hand, one could argue differently :) Given faulty premises, even flawless logic might not reach an accurate and precise conclusion. > My closing thoughts are these, and correct me if I am wrong; doing address > translation integrated into IPSEC is 'too difficult' or 'too much work' > for the IPSEC to consider. Or, is it more like 'if IPSEC WG builds > hooks for NAT' then the precedence has been set for 'more and more > IPSEC requirements and accomodations'. No. IPsec provides an "end-to-end" security service, not a "hop-by-hop" security service. NAT inteferes with the ability of many security protocols (smb has cited several examples) to provide "end-to-end" security. The end-to-end security property is necessary and must not be lost. That said, _NAT_ implementations can and should be tweaked to accomodate IPsec. There are a number of methods for this that have already been discussed on this list. I suspect that major router vendors that ship both technologies would make those changes so that they can sell more product. I believe it would be constructive to pause this thread until Bob Moscowitz has a fair chance of getting some of his thoughts on NAT+IPsec out into a broader view. :-) Ran rja@inet.org From owner-ipsec Wed Aug 20 12:25:51 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA01227 for ipsec-outgoing; Wed, 20 Aug 1997 12:20:34 -0400 (EDT) Message-Id: <3.0.3.32.19970820122751.00b6f7a0@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 20 Aug 1997 12:27:51 -0400 To: ipsec@tis.com From: Robert Moskowitz Subject: IPsec VPN and NAT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MIME-Autoconverted: from 8bit to quoted-printable by odhubpr1-nf0.oddc.chrysler.com id MAA21458 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id MAA01224 Sender: owner-ipsec@ex.tis.com Precedence: bulk I appologise to those not interested on this list for this posting. The FTP server that we had for such things seems to be down, maybe permanently. Here is my first cut at cutting together a number of writings into an ID on IPsec VPNs and NAT. It addresses only simple IPsec tunnels (gateways and remotes). Advanced IPsec tunnels (chained and/or nested with host participation) will require more thought. Please read and comment in general (or detail!). I will get this off friday morning with whatever changes make sense to the ID address.... Internet Engineering Task Force R. Moskowitz Internet Draft Chrysler Corporation Expires in six months August 19, 1997 Network Address Translation issues with IPsec Status of this Memo This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts draft documents are valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This document looks at a number of issues surrounding the need for network address translation (NAT) when IPsec is used to create virtual private networks (NAT). This document only looks at simple VPNs. That is VPNs consisting of a single IPsec tunnel as compared to VPNs consisting of ‘chained’ and/or ‘nested’ IPsec tunnels and/or transports. R. Moskowitz [Page 1] Internet Draft NAT issues with IPsec August 20, 1997 Table of Contents 1. Introduction..............................................2 1.1 Specification of Requirements..........................3 2. Network classifications...................................3 2.1 Remote systems.........................................3 3. Network to Network VPN scenarios..........................3 3.1 Scenario 1: A -> A.....................................4 3.2 Scenario 2: A -> B.....................................4 3.3 Scenario 3: A -> C.....................................4 3.4 Scenario 4: A -> D.....................................5 3.5 Scenario 5: B -> A.....................................5 3.6 Scenario 6: B -> B.....................................6 3.7 Scenario 7: B -> C.....................................6 3.8 Scenario 8: B -> D.....................................7 3.9 Scenario 9: C -> A.....................................7 3.10 Scenario 10: C -> B...................................8 3.11 Scenario 11: C -> C...................................8 3.12 Scenario 12: C -> D...................................9 3.13 Scenario 13: D -> A...................................9 3.14 Scenario 14: D -> B..................................10 3.15 Scenario 15: D -> C..................................11 3.16 Scenario 16: D -> D..................................11 4. Remote to Network VPN Scenarios..........................12 4.1 Scenario 1: R -> A....................................12 4.2 Scenario 2: R -> B....................................13 4.3 Scenario 3: R -> C....................................13 4.4 Scenario 4: R -> D....................................13 5. Security Considerations..................................14 6. References...............................................14 7. Acknowledgments..........................................14 8. Author's Addresses.......................................15 1. Introduction This document this document looks into the need of performing network address translation on IPsec gateways and remote hosts. It is assumed that the reader is familiar with the terms and concepts described in the "Security Architecture for the Internet Protocol" [Atkinson95] and "IP Encapsulating Security Payload (ESP)" [Kent97] documents. The reader also needs to be familiar with private addresses (rfc 1918), and Network Address Translation. R. Moskowitz [Page 2] Internet Draft NAT issues with IPsec August 20, 1997 1.1 Specification of Requirements The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document are to be interpreted as described in [Bradner97]. 2. Network classifications It is possible to group all networks into 4 classes. There are: A) Globally routable addresses (either from NIC or provider) with default routing to single IPsec gateway. B) Private addressing (RFC1918) internally, with default routing to a single IPsec gateway. C) Globally routable addresses (either from NIC or provider) without default routing and single gateway, or with multiple IPsec gateways (multiple gateways break default routing). D) Private addressing (RFC1918) internally, without default routing and single gateway, or with multiple IPsec gateways. 2.1 Remote systems Remote systems will present their own issues. A remote system might be independent of the network it wishes to communicate with. It might be a ‘road warrior’, or off-site user from the network. This distinction is important. 3. Network to Network VPN scenarios The nature of the network types, in terms of addresses, makes the network to network issues non-symmetric. That is a host from an B network as the source system to host in a C network is different from a C host to a B host. Thus all sixteen combinations need to be examined. In all of the scenarios, the network on the left is the source network and the one on the right is the destination. For brevity purposes, the following abbreviations are used in this section: SN Source Network R. Moskowitz [Page 3] Internet Draft NAT issues with IPsec August 20, 1997 DN Destination Network AA Alternative Action C Consideration 3.1 Scenario 1: A -> A SN Policy on what destination addresses use what tunnel endpoint. (Optional) Policy on what source addresses are allowed to tunnel. Oakley Quick Mode ID MUST be the source address. DN Policy on what source addresses are allowed in. (Optional) refinement on what source addresses are allowed to what host. Oakley Quick Mode ID CAN be the tunnel endpoint address. 3.2 Scenario 2: A -> B SN Policy on what destination addresses use what tunnel endpoint. (Optional) Policy on what source addresses are allowed to tunnel. Oakley Quick Mode ID MUST be the source address. DN Static mapping of internal server address to public address. Public DNS entry for above public address. NAT for above mapping. Policy on what source addresses are allowed in. (Optional) refinement on what source addresses are allowed to what host. Oakley Quick Mode ID CAN be the tunnel endpoint address. 3.3 Scenario 3: A -> C SN Policy on what destination addresses use what tunnel endpoint. Note that different addresses in a network COULD terminate at different gateways. (Optional) Policy on what source addresses are allowed to tunnel. Oakley Quick Mode ID MUST be the source address. R. Moskowitz [Page 4] Internet Draft NAT issues with IPsec August 20, 1997 DN Pool of internal addresses available for dynamic address mapping of inbound source address and outbound destination address Policy on what source addresses are allowed in. (Optional) refinement on what source addresses are allowed to what host. Oakley Quick Mode ID SHOULD be the internal assigned address. 3.4 Scenario 4: A -> D SN Policy on what destination addresses use what tunnel endpoint. Note that different addresses in a network COULD terminate at different gateways. (Optional) Policy on what source addresses are allowed to tunnel. Oakley Quick Mode ID MUST be the source address. DN Static mapping of internal server address to public address. Public DNS entry for above public address. NAT for above mapping. Pool of internal addresses available for dynamic address mapping of inbound source address and outbound destination address Policy on what source addresses are allowed in. (Optional) refinement on what source addresses are allowed to what host. Oakley Quick Mode ID SHOULD be the internal assigned address. 3.5 Scenario 5: B -> A SN Pool of external addresses available for dynamic address mapping of outbound source address and inbound destination address Policy on what destination addresses use what tunnel endpoint. (Optional) Policy on what source addresses are allowed to tunnel. Oakley Quick Mode ID MUST be real source address. DN Policy on what source addresses are allowed in. R. Moskowitz [Page 5] Internet Draft NAT issues with IPsec August 20, 1997 (Optional) refinement on what source addresses are allowed to what host. Oakley Quick Mode ID CAN be the tunnel endpoint address. 3.6 Scenario 6: B -> B SN Pool of external addresses available for dynamic address mapping of outbound source address and inbound destination address Policy on what destination addresses use what tunnel endpoint. (Optional) Policy on what source addresses are allowed to tunnel. Oakley Quick Mode ID MUST be real source address. DN Static mapping of internal server address to public address. Public DNS entry for above public address. NAT for above mapping. Policy on what source addresses are allowed in. (Optional) refinement on what source addresses are allowed to what host. Oakley Quick Mode ID CAN be the tunnel endpoint address. 3.7 Scenario 7: B -> C SN Pool of external addresses available for dynamic address mapping of outbound source address and inbound destination address Policy on what destination addresses use what tunnel endpoint. (Optional) Policy on what source addresses are allowed to tunnel. Oakley Quick Mode ID MUST be real source address. DN Pool of internal addresses available for dynamic address mapping of inbound source address and outbound destination address Policy on what source addresses are allowed in. (Optional) refinement on what source addresses are allowed to what host. Oakley Quick Mode ID SHOULD be the internal assigned address. R. Moskowitz [Page 6] Internet Draft NAT issues with IPsec August 20, 1997 AA The QM ID from the destination network can be used by the source network as the source address for its NAT. Then the destination gateway does not need to do the NAT function. 3.8 Scenario 8: B -> D SN Pool of external addresses available for dynamic address mapping of outbound source address and inbound destination address Policy on what destination addresses use what tunnel endpoint. (Optional) Policy on what source addresses are allowed to tunnel. Oakley Quick Mode ID MUST be real source address. DN Static mapping of internal server address to public address. Public DNS entry for above public address. NAT for above mapping. Pool of internal addresses available for dynamic address mapping of inbound source address and outbound destination address Policy on what source addresses are allowed in. (Optional) refinement on what source addresses are allowed to what host. Oakley Quick Mode ID SHOULD be the internal assigned address. 3.9 Scenario 9: C -> A SN Pool of internal addresses available for dynamic address mapping of outbound destination address and inbound source address DNS mapping of destination address to internal address. Policy on what destination addresses use what tunnel endpoint. (Optional) Policy on what source addresses are allowed to tunnel. Oakley Quick Mode ID MUST be source address. DN Policy on what source addresses are allowed in. (Optional) refinement on what source addresses are allowed to what host. R. Moskowitz [Page 7] Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Aug 20 12:43:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA01388 for ipsec-outgoing; Wed, 20 Aug 1997 12:43:33 -0400 (EDT) Message-Id: <3.0.3.32.19970820125105.00ac4130@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 20 Aug 1997 12:51:05 -0400 To: ipsec@tis.com From: Robert Moskowitz Subject: Re: IPsec VPN and NAT In-Reply-To: <3.0.3.32.19970820122751.00b6f7a0@pop3hub.is.chrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 12:27 PM 8/20/97 -0400, Robert Moskowitz wrote: something when wrong. There are 15 pages to this thing. Will post again... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Aug 20 12:46:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA01401 for ipsec-outgoing; Wed, 20 Aug 1997 12:46:03 -0400 (EDT) Message-Id: <3.0.3.32.19970820125413.00b0d470@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 20 Aug 1997 12:54:13 -0400 To: ipsec@tis.com From: Robert Moskowitz Subject: IPsec VPN and NAT - again Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MIME-Autoconverted: from 8bit to quoted-printable by odhubpr1-nf0.oddc.chrysler.com id MAA23321 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id MAA01398 Sender: owner-ipsec@ex.tis.com Precedence: bulk I appologise to those not interested on this list for this posting. The FTP server that we had for such things seems to be down, maybe permanently. Here is my first cut at cutting together a number of writings into an ID on IPsec VPNs and NAT. It addresses only simple IPsec tunnels (gateways and remotes). Advanced IPsec tunnels (chained and/or nested with host participation) will require more thought. Please read and comment in general (or detail!). I will get this off friday morning with whatever changes make sense to the ID address.... Internet Engineering Task Force R. Moskowitz Internet Draft Chrysler Corporation Expires in six months August 19, 1997 Network Address Translation issues with IPsec Status of this Memo This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts draft documents are valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This document looks at a number of issues surrounding the need for network address translation (NAT) when IPsec is used to create virtual private networks (NAT). This document only looks at simple VPNs. That is VPNs consisting of a single IPsec tunnel as compared to VPNs consisting of ‘chained’ and/or ‘nested’ IPsec tunnels and/or transports. R. Moskowitz [Page 1] Internet Draft NAT issues with IPsec August 20, 1997 Table of Contents 1. Introduction..............................................2 1.1 Specification of Requirements..........................2 2. Network classifications...................................3 2.1 Remote systems.........................................3 3. Network to Network VPN scenarios..........................3 3.1 Scenario 1: A -> A.....................................4 3.2 Scenario 2: A -> B.....................................4 3.3 Scenario 3: A -> C.....................................4 3.4 Scenario 4: A -> D.....................................5 3.5 Scenario 5: B -> A.....................................5 3.6 Scenario 6: B -> B.....................................6 3.7 Scenario 7: B -> C.....................................6 3.8 Scenario 8: B -> D.....................................7 3.9 Scenario 9: C -> A.....................................7 3.10 Scenario 10: C -> B...................................8 3.11 Scenario 11: C -> C...................................8 3.12 Scenario 12: C -> D...................................9 3.13 Scenario 13: D -> A...................................9 3.14 Scenario 14: D -> B..................................10 3.15 Scenario 15: D -> C..................................10 3.16 Scenario 16: D -> D..................................11 4. Remote to Network VPN Scenarios..........................12 4.1 Scenario 1: R -> A....................................12 4.2 Scenario 2: R -> B....................................12 4.3 Scenario 3: R -> C....................................13 4.4 Scenario 4: R -> D....................................13 5. Security Considerations..................................14 6. References...............................................14 7. Acknowledgments..........................................14 8. Author's Addresses.......................................15 1. Introduction This document this document looks into the need of performing network address translation on IPsec gateways and remote hosts. It is assumed that the reader is familiar with the terms and concepts described in the "Security Architecture for the Internet Protocol" [Atkinson95] and "IP Encapsulating Security Payload (ESP)" [Kent97] documents. The reader also needs to be familiar with private addresses (rfc 1918), and Network Address Translation. R. Moskowitz [Page 2] Internet Draft NAT issues with IPsec August 20, 1997 1.1 Specification of Requirements The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document are to be interpreted as described in [Bradner97]. 2. Network classifications It is possible to group all networks into 4 classes. There are: A) Globally routable addresses (either from NIC or provider) with default routing to single IPsec gateway. B) Private addressing (RFC1918) internally, with default routing to a single IPsec gateway. C) Globally routable addresses (either from NIC or provider) without default routing and single gateway, or with multiple IPsec gateways (multiple gateways break default routing). D) Private addressing (RFC1918) internally, without default routing and single gateway, or with multiple IPsec gateways. 2.1 Remote systems Remote systems will present their own issues. A remote system might be independent of the network it wishes to communicate with. It might be a ‘road warrior’, or off-site user from the network. This distinction is important. 3. Network to Network VPN scenarios The nature of the network types, in terms of addresses, makes the network to network issues non-symmetric. That is a host from an B network as the source system to host in a C network is different from a C host to a B host. Thus all sixteen combinations need to be examined. In all of the scenarios, the network on the left is the source network and the one on the right is the destination. For brevity purposes, the following abbreviations are used in this section: SN Source Network R. Moskowitz [Page 3] Internet Draft NAT issues with IPsec August 20, 1997 DN Destination Network AA Alternative Action C Consideration 3.1 Scenario 1: A -> A SN Policy on what destination addresses use what tunnel endpoint. (Optional) Policy on what source addresses are allowed to tunnel. Oakley Quick Mode ID MUST be the source address. DN Policy on what source addresses are allowed in. (Optional) refinement on what source addresses are allowed to what host. Oakley Quick Mode ID CAN be the tunnel endpoint address. 3.2 Scenario 2: A -> B SN Policy on what destination addresses use what tunnel endpoint. (Optional) Policy on what source addresses are allowed to tunnel. Oakley Quick Mode ID MUST be the source address. DN Static mapping of internal server address to public address. Public DNS entry for above public address. NAT for above mapping. Policy on what source addresses are allowed in. (Optional) refinement on what source addresses are allowed to what host. Oakley Quick Mode ID CAN be the tunnel endpoint address. 3.3 Scenario 3: A -> C SN Policy on what destination addresses use what tunnel endpoint. Note that different addresses in a network COULD terminate at different gateways. (Optional) Policy on what source addresses are allowed to tunnel. Oakley Quick Mode ID MUST be the source address. R. Moskowitz [Page 4] Internet Draft NAT issues with IPsec August 20, 1997 DN Pool of internal addresses available for dynamic address mapping of inbound source address and outbound destination address Policy on what source addresses are allowed in. (Optional) refinement on what source addresses are allowed to what host. Oakley Quick Mode ID SHOULD be the internal assigned address. 3.4 Scenario 4: A -> D SN Policy on what destination addresses use what tunnel endpoint. Note that different addresses in a network COULD terminate at different gateways. (Optional) Policy on what source addresses are allowed to tunnel. Oakley Quick Mode ID MUST be the source address. DN Static mapping of internal server address to public address. Public DNS entry for above public address. NAT for above mapping. Pool of internal addresses available for dynamic address mapping of inbound source address and outbound destination address Policy on what source addresses are allowed in. (Optional) refinement on what source addresses are allowed to what host. Oakley Quick Mode ID SHOULD be the internal assigned address. 3.5 Scenario 5: B -> A SN Pool of external addresses available for dynamic address mapping of outbound source address and inbound destination address Policy on what destination addresses use what tunnel endpoint. (Optional) Policy on what source addresses are allowed to tunnel. Oakley Quick Mode ID MUST be real source address. DN Policy on what source addresses are allowed in. R. Moskowitz [Page 5] Internet Draft NAT issues with IPsec August 20, 1997 (Optional) refinement on what source addresses are allowed to what host. Oakley Quick Mode ID CAN be the tunnel endpoint address. 3.6 Scenario 6: B -> B SN Pool of external addresses available for dynamic address mapping of outbound source address and inbound destination address Policy on what destination addresses use what tunnel endpoint. (Optional) Policy on what source addresses are allowed to tunnel. Oakley Quick Mode ID MUST be real source address. DN Static mapping of internal server address to public address. Public DNS entry for above public address. NAT for above mapping. Policy on what source addresses are allowed in. (Optional) refinement on what source addresses are allowed to what host. Oakley Quick Mode ID CAN be the tunnel endpoint address. 3.7 Scenario 7: B -> C SN Pool of external addresses available for dynamic address mapping of outbound source address and inbound destination address Policy on what destination addresses use what tunnel endpoint. (Optional) Policy on what source addresses are allowed to tunnel. Oakley Quick Mode ID MUST be real source address. DN Pool of internal addresses available for dynamic address mapping of inbound source address and outbound destination address Policy on what source addresses are allowed in. (Optional) refinement on what source addresses are allowed to what host. Oakley Quick Mode ID SHOULD be the internal assigned address. R. Moskowitz [Page 6] Internet Draft NAT issues with IPsec August 20, 1997 AA The QM ID from the destination network can be used by the source network as the source address for its NAT. Then the destination gateway does not need to do the NAT function. 3.8 Scenario 8: B -> D SN Pool of external addresses available for dynamic address mapping of outbound source address and inbound destination address Policy on what destination addresses use what tunnel endpoint. (Optional) Policy on what source addresses are allowed to tunnel. Oakley Quick Mode ID MUST be real source address. DN Static mapping of internal server address to public address. Public DNS entry for above public address. NAT for above mapping. Pool of internal addresses available for dynamic address mapping of inbound source address and outbound destination address Policy on what source addresses are allowed in. (Optional) refinement on what source addresses are allowed to what host. Oakley Quick Mode ID SHOULD be the internal assigned address. 3.9 Scenario 9: C -> A SN Pool of internal addresses available for dynamic address mapping of outbound destination address and inbound source address DNS mapping of destination address to internal address. Policy on what destination addresses use what tunnel endpoint. (Optional) Policy on what source addresses are allowed to tunnel. Oakley Quick Mode ID MUST be source address. DN Policy on what source addresses are allowed in. (Optional) refinement on what source addresses are allowed to what host. R. Moskowitz [Page 7] Internet Draft NAT issues with IPsec August 20, 1997 Oakley Quick Mode ID CAN be the tunnel endpoint address. 3.10 Scenario 10: C -> B SN Pool of internal addresses available for dynamic address mapping of outbound destination address and inbound source address DNS mapping of destination address to internal address. Policy on what destination addresses use what tunnel endpoint. (Optional) Policy on what source addresses are allowed to tunnel. Oakley Quick Mode ID MUST be source address. DN Static mapping of internal server address to public address. Public DNS entry for above public address. NAT for above mapping. Policy on what source addresses are allowed in. (Optional) refinement on what source addresses are allowed to what host. Oakley Quick Mode ID CAN be the tunnel endpoint address. C The destination address from C to B gets mapped twice. There is no apparent way to get information the source gateway of the real address in B to simplify this. 3.11 Scenario 11: C -> C SN Pool of internal addresses available for dynamic address mapping of outbound destination address and inbound source address DNS mapping of destination address to internal address. Policy on what destination addresses use what tunnel endpoint. (Optional) Policy on what source addresses are allowed to tunnel. Oakley Quick Mode ID MUST be source address. DN Pool of internal addresses available for dynamic address mapping of inbound source address and outbound destination address R. Moskowitz [Page 8] Internet Draft NAT issues with IPsec August 20, 1997 Policy on what source addresses are allowed in. (Optional) refinement on what source addresses are allowed to what host. Oakley Quick Mode ID SHOULD be the internal assigned address. 3.12 Scenario 12: C -> D SN Pool of internal addresses available for dynamic address mapping of outbound destination address and inbound source address DNS mapping of destination address to internal address. Policy on what destination addresses use what tunnel endpoint. (Optional) Policy on what source addresses are allowed to tunnel. Oakley Quick Mode ID MUST be source address. DN Static mapping of internal server address to public address. Public DNS entry for above public address. NAT for above mapping. Pool of internal addresses available for dynamic address mapping of inbound source address and outbound destination address Policy on what source addresses are allowed in. (Optional) refinement on what source addresses are allowed to what host. Oakley Quick Mode ID SHOULD be the internal assigned address. AA The QM ID from the destination network can be used by the source network as the source address for its NAT. Then the destination gateway does not need to do the NAT function. 3.13 Scenario 13: D -> A SN Pool of internal addresses available for dynamic address mapping of outbound destination address and inbound source address DNS mapping of destination address to internal address. Pool of external addresses available for dynamic address mapping of outbound source address and inbound destination address R. Moskowitz [Page 9] Internet Draft NAT issues with IPsec August 20, 1997 Policy on what destination addresses use what tunnel endpoint. (Optional) Policy on what source addresses are allowed to tunnel. Oakley Quick Mode ID MUST be source address. DN Policy on what source addresses are allowed in. (Optional) refinement on what source addresses are allowed to what host. Oakley Quick Mode ID CAN be the tunnel endpoint address. 3.14 Scenario 14: D -> B SN Pool of internal addresses available for dynamic address mapping of outbound destination address and inbound source address DNS mapping of destination address to internal address. Pool of external addresses available for dynamic address mapping of outbound source address and inbound destination address Policy on what destination addresses use what tunnel endpoint. (Optional) Policy on what source addresses are allowed to tunnel. Oakley Quick Mode ID MUST be source address. DN Static mapping of internal server address to public address. Public DNS entry for above public address. NAT for above mapping. Policy on what source addresses are allowed in. (Optional) refinement on what source addresses are allowed to what host. Oakley Quick Mode ID CAN be the tunnel endpoint address. C The destination address from D to B gets mapped twice. There is no appearent way to get information the source gateway of the real address in B to simplify this. R. Moskowitz [Page 10] Internet Draft NAT issues with IPsec August 20, 1997 3.15 Scenario 15: D -> C SN Pool of internal addresses available for dynamic address mapping of outbound destination address and inbound source address DNS mapping of destination address to internal address. Pool of external addresses available for dynamic address mapping of outbound source address and inbound destination address Policy on what destination addresses use what tunnel endpoint. (Optional) Policy on what source addresses are allowed to tunnel. Oakley Quick Mode ID MUST be source address. DN Pool of internal addresses available for dynamic address mapping of inbound source address and outbound destination address Policy on what source addresses are allowed in. (Optional) refinement on what source addresses are allowed to what host. Oakley Quick Mode ID SHOULD be the internal assigned address. AA The QM ID from the destination network can be used by the source network as the source address for its NAT. Then the destination gateway does not need to do the NAT function. 3.16 Scenario 16: D -> D SN Pool of internal addresses available for dynamic address mapping of outbound destination address and inbound source address DNS mapping of destination address to internal address. Pool of external addresses available for dynamic address mapping of outbound source address and inbound destination address Policy on what destination addresses use what tunnel endpoint. (Optional) Policy on what source addresses are allowed to tunnel. Oakley Quick Mode ID MUST be source address. DN Static mapping of internal server address to public address. R. Moskowitz [Page 11] Internet Draft NAT issues with IPsec August 20, 1997 Public DNS entry for above public address. NAT for above mapping. Pool of internal addresses available for dynamic address mapping of inbound source address and outbound destination address Policy on what source addresses are allowed in. (Optional) refinement on what source addresses are allowed to what host. Oakley Quick Mode ID SHOULD be the internal assigned address. AA The QM ID from the destination network can be used by the source network as the source address for its NAT. Then the destination gateway does not need to do the NAT function. 4. Remote to Network VPN Scenarios The remote system, for the most part, can be considered like a type A network. There are a few caveats, making for some differences, as there is only one public address available to the remote system. The road warrior is mentioned as a variant of the remote system. Thus there are four combinations to examine. For brevity purposes, the following abbreviations are used in this section: SN Source Network DN Destination Network RW Road Warrior 4.1 Scenario 1: R -> A SN Policy on what destination addresses use what tunnel endpoint. Oakley Quick Mode ID MUST be the source address. DN (Optional) Policy on what source addresses are allowed in. Oakley Quick Mode ID CAN be the tunnel endpoint address. R. Moskowitz [Page 12] Internet Draft NAT issues with IPsec August 20, 1997 4.2 Scenario 2: R -> B SN Policy on what destination addresses use what tunnel endpoint. Oakley Quick Mode ID MUST be the source address. DN Static mapping of internal server address to public address. Public DNS entry for above public address. NAT for above mapping. (Optional) Policy on what source addresses are allowed in. Oakley Quick Mode ID CAN be the tunnel endpoint address. RW DNS is the destination network's internal DNS. Thus no external addresses are needed. 4.3 Scenario 3: R -> C SN Policy on what destination addresses use what tunnel endpoint. Note that different addresses in a network COULD terminate at different gateways. Oakley Quick Mode ID MUST be the source address. DN Pool of internal addresses available for dynamic address mapping of inbound source address and outbound destination address (Optional) Policy on what source addresses are allowed in. Oakley Quick Mode ID SHOULD be the internal assigned address. RW DNS is the destination network's internal DNS. The road warrior can use the address from the destination network's QM ID as the source address, thus effecting the address translation. 4.4 Scenario 4: R -> D SN Policy on what destination addresses use what tunnel endpoint. Note that different addresses in a network COULD terminate at different gateways. Oakley Quick Mode ID MUST be the source address. R. Moskowitz [Page 13] Internet Draft NAT issues with IPsec August 20, 1997 DN Static mapping of internal server address to public address. Public DNS entry for above public address. NAT for above mapping. Pool of internal addresses available for dynamic address mapping of inbound source address and outbound destination address (Optional) Policy on what source addresses are allowed in. Oakley Quick Mode ID SHOULD be the internal assigned address. RW DNS is the destination network's internal DNS. Thus no external addresses are needed. The road warrior can use the address from the destination network's QM ID as the source address, thus effecting the address translation. 5. Security Considerations Network address translation, in conjunction with IPsec makes some large assumptions of trust. Intermediate systems are changing IP addresses on behalf of other systems. This is done, based on configurations set up, frequently be people in partnered organizations. There is no apparent way to validate the validity of these changes. Only when IPsec is used end to end might any address changes be validated. 6. References [Atkinson95] Atkinson, R., "Security Architecture for the Internet Protocol", draft-ietf-ipsec-arch-sec-01 [Bradner97] Bradner, S., "Key words for use in RFCs to indicate Requirement Levels", RFC2119, March 1997 [Kent97] Kent, S., Atkinson, R., "IP Encapsulating Security Payload (ESP)", draft-ietf-ipsec-new-esp-01 7. Acknowledgments This document is based on discussions with Ran Atkinson, Naganand Doraswamy, Frank Kastenholz, Michael Richardson, and Rodney Thayer, along with a host of others at the IPsec workshops hosted by the Automotive Industry Action Group (AIAG). R. Moskowitz [Page 14] Internet Draft NAT issues with IPsec August 20, 1997 8. Author's Addresses Robert Moskowitz rgm@chrysler.com Chrysler Corporation R. Moskowitz [Page 15] Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Aug 20 13:19:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA01662 for ipsec-outgoing; Wed, 20 Aug 1997 13:19:03 -0400 (EDT) Message-Id: <3.0.32.19970820102909.0095f160@192.43.161.2> X-Sender: jburke@192.43.161.2 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 20 Aug 1997 10:29:09 -0700 To: ipsec@tis.com From: John Burke Subject: Re: anti-replay notification Cc: jburke@cylink.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I find this argument convincing: At 09:08 AM 8/20/97 -0400, dpkemp@missi.ncsc.mil (David P. Kemp) wrote: >> From: Stephen Kent [ ... ] >If, for automatically-keyed SA's, anti-replay may be used, then why not >just require the sender to behave conservatively and assume that it is >always being used. I.e. never cycle the counter, and don't require AR >notification. > >That would have the same effect as making anti-replay mandatory (force >rekeying before overflow), but would not force thin receivers to implement >AR just for the sake of compliance with the spec. > >Even if AR notification is simple to add to ISAKMP, it's just one more >detail to code, one more complication to the spec, one more >option to analyze. Philosophically, I lean toward not negotiating things >unless there's a strong benefit to doing so. In this case, the benefit [ ... ] 1. Consider what it means to the sender, if the receiver might notify the sender it is implementing Anti-Replay: The Initiator has an optional ability to keep sending without checking the counter coming near rollover, but, if it gets notice of AR, then it is going to check the counter and rekey, near rollover at the latest. Why would anyone implement ability to not check the counter, while including the option to yes check it and do re-key? As for manual rekey, I believe everyone is in agreement that the sender which did manual rekey knows that this is the case, and of course can't re-key, so this is a separate case not relevant to the with-Key-Management case. 2. Heads up! The proposal that the receiver notifies the sender about Replay checking, implies the ISAKMP Responder might send the Anti-Replay attribute in response when not sent by the Initiator. I think it has been the principle in ISAKMP/Oakley, so far, that a Responder returns an SA with an attribute list that includes all attributes in one offered transform, none changed, none added; I believe many have expressed this on this list. To the contrary I do remember, that some have suggested lifetimes can be negotiated downward, but as I remember this was not generally agreed to, and some responded stating this no-changes principle. So I think the "no changed attributes" principle has stood so far, but please correct me, anyone who understands otherwise. We're not opposed to negotiated attributes here; it always seemed strange to me to rule out a priori all negotiation, when some, like lifetime, are obvious and not problematic. But people presumably have implemented on this no-change basis and now would have to alter such logic. To me this suggests that such a change at this late date is not worth trouble in altering the drafts, nor in implementors racing to get another complication included for coming interoperability tests, when many are near a working standard implementation. John Burke jburke@cylink.com From owner-ipsec Wed Aug 20 14:28:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA02113 for ipsec-outgoing; Wed, 20 Aug 1997 14:26:03 -0400 (EDT) Message-Id: <199708201834.LAA23582@pita.cisco.com> To: John Burke cc: ipsec@tis.com Subject: Re: anti-replay notification In-reply-to: Your message of "Wed, 20 Aug 1997 10:29:09 PDT." <3.0.32.19970820102909.0095f160@192.43.161.2> Date: Wed, 20 Aug 1997 11:34:43 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk John et al, You're right about the "no changed attributes" principal. The current proposal would necessitate an exception for a Replay Window attribute which would have to be (asymetrically) returned by the responder. I also believe that this adds unnecesssary complexity for little benefit. I'm of the group who feel that anti-replay should be mandated when using dynamic keying and that the anti-replay window size need not be specified in our documents. It just seems obvious to me that the size of the replay window is host implementation dependent. We don't have to mandate that it be 64-bits or a multiple of 32-bits. We should just be recommending that. So, here's what I think this comes down to... Does anyone have any serious examples, other than for manual keying, of situations where not enforcing anti-replay would make sense in an environment where you have ISAKMP/Oakley and the current AH/ESP? If not, then I would like to see anti-replay made mandatory for dynamic keying before we submit the current AH/ESP drafts to the IESG. RE: lifetime The lifetime attribute is a different animal. What the IPSEC DOI intends to do is to define what happens when conflicting lifetimes are specified -- each side chooses the most restrictive lifetime(s). However, this doesn't require asymetric or conflicting attributes in the proposals. Each side knows what they offered and what the other side wanted and they each pick the lower value(s). This is very different from the anti-replay response. Derrell From owner-ipsec Wed Aug 20 16:25:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA02842 for ipsec-outgoing; Wed, 20 Aug 1997 16:24:05 -0400 (EDT) Date: Wed, 20 Aug 1997 15:25:23 -0400 From: Norman Shulman X-Sender: norm@rafael.tornd.securecomputing.com To: Derrell Piper cc: John Burke , ipsec@tis.com Subject: Re: anti-replay notification In-Reply-To: <199708201834.LAA23582@pita.cisco.com> Message-Id: <97Aug20.152540edt.11652@janus.tor.securecomputing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Wed, 20 Aug 1997, Derrell Piper wrote: > I'm of the group who feel that anti-replay should be mandated when using > dynamic keying and that the anti-replay window size need not be specified > in our documents. It just seems obvious to me that the size of the replay > window is host implementation dependent. We don't have to mandate that it > be 64-bits or a multiple of 32-bits. We should just be recommending that. > > So, here's what I think this comes down to... Does anyone have any serious > examples, other than for manual keying, of situations where not enforcing > anti-replay would make sense in an environment where you have ISAKMP/Oakley > and the current AH/ESP? If not, then I would like to see anti-replay made > mandatory for dynamic keying before we submit the current AH/ESP drafts to > the IESG. According to the current ESP draft, This service MUST NOT be enabled unless the authentication service also is enabled for the SA, since otherwise the Sequence Number field has not been integrity protected. So making anti-replay mandatory would also make authentication mandatory. Norm Norman Shulman Secure Computing Canada Systems Developer Tel 1 416 813 2075 norm@tor.securecomputing.com Fax 1 416 813 2001 From owner-ipsec Wed Aug 20 16:40:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA02936 for ipsec-outgoing; Wed, 20 Aug 1997 16:40:03 -0400 (EDT) Message-Id: <199708202049.NAA26034@pita.cisco.com> To: Norman Shulman cc: John Burke , ipsec@tis.com Subject: Re: anti-replay notification In-reply-to: Your message of "Wed, 20 Aug 1997 15:25:23 EDT." <97Aug20.152540edt.11652@janus.tor.securecomputing.com> Date: Wed, 20 Aug 1997 13:49:06 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk Norm, Okay, mandatory if using dynamic keying and authentication is selected... I'm certainly not suggesting that anti-replay be decoupled from authentication for ESP. Derrell From owner-ipsec Wed Aug 20 18:01:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA03461 for ipsec-outgoing; Wed, 20 Aug 1997 18:00:32 -0400 (EDT) Message-Id: <199708202209.PAA27812@pita.cisco.com> To: ipsec@tis.com Subject: manual keying and IPSEC conformance Date: Wed, 20 Aug 1997 15:09:31 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, It was suggested to me at the Munich meeting that it might be useful to bring this issue up on the list. So, here goes... The current AH and ESP drafts state that manual keying is a MUST implement. This evolved from the earliest versions of these documents, which pre-dated any agreed upon dynamic key management protocol (i.e. ISAKMP/Oakley). (This was a long time ago, much too long, as we are all painfully aware...) This requirement implies that an IPSEC host implementation which supports only ISAKMP/Oakley using the current AH and ESP drafts (anti-replay or not... :-), but without manual keying, would not be considered a conformant IPSEC implementation. Is this what we really want -- manual keying with an optional-to-implement key management protocol? I'll also point out that our directive from Jeff from last fall states that ISAKMP/Oakley is mandatory-to-implement for IPv6 IPSEC [1]. Should it not be the same for IPv4? My customers tell me that they don't want to have anything to do with manual keying. That's why we're investing in ISAKMP/Oakley. Is it really the desire of this working group to force me to include something that is insecure and that my customers don't want to buy? One obvious suggestion is to state that one must implement either ISAKMP/Oakley or manual keying. Another is to just require ISAKMP/Oakley, as in IPv6. The former isn't the greatest from an interoperability standpoint, but I believe that environments with a mix of manual keying and dynamic keying are rather unlikely to exist in the first place. Practically speaking, dynamic key management is going to be a prerequisite for any large-scale deployment of IPSEC. What's the sense of the rest of the group? Derrell [1] http://www.sandelman.ottawa.on.ca/ipsec/1996/09/msg00096.html From owner-ipsec Wed Aug 20 18:44:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA03684 for ipsec-outgoing; Wed, 20 Aug 1997 18:43:34 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199708202209.PAA27812@pita.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Aug 1997 18:45:54 -0400 To: Derrell Piper From: Stephen Kent Subject: Re: manual keying and IPSEC conformance Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk I concur with Derrell's suggestion to not mandate support for manual keying. Given the widespread use of ISAKMP in products under development, it seems much less critical that when this requirement was originally adopted over two years ago. Steve From owner-ipsec Wed Aug 20 18:44:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA03685 for ipsec-outgoing; Wed, 20 Aug 1997 18:43:35 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199708202049.NAA26034@pita.cisco.com> References: Your message of "Wed, 20 Aug 1997 15:25:23 EDT." <97Aug20.152540edt.11652@janus.tor.securecomputing.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Aug 1997 18:42:55 -0400 To: Derrell Piper From: Stephen Kent Subject: Re: anti-replay notification Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Derrell, We started with the issue of whether the receiver needs to tell the sender what size window is being used for anti-replay purposes, if it is being used. To avoid this notification complexity, it was suggested that anti-replay always be used if automated keying is being done. Then it was noted that it makes no sense to do anti-replay without authentication, so the solution is to always mandate authentication. What a slippery slope we have here. We had previously agreed that authentication was not a required service, e.g., if AH were used in conjunction with ESP. I should observe that, at the Munich meeting, Derrell and I discussed the option of a NULL authentication algorithm to make the ISAKMP message syntax more niform in the absence of real authentication for ESP. If the suggestion is to mandate authentication for all automatically keyed ESP SAs, and to allow the NULL authentication algorithm, then the performance hit won't be so bad ... :-)! But can we explain this to the greater IETF community with a straight face? Steve From owner-ipsec Wed Aug 20 18:49:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA03719 for ipsec-outgoing; Wed, 20 Aug 1997 18:49:03 -0400 (EDT) From: Dan.McDonald@Eng.Sun.Com (Dan McDonald) Message-Id: <199708202257.PAA26798@kebe.eng.sun.com> Subject: Re: manual keying and IPSEC conformance To: ipsec@tis.com Date: Wed, 20 Aug 1997 15:57:46 -0700 (PDT) In-Reply-To: <199708202209.PAA27812@pita.cisco.com> from "Derrell Piper" at Aug 20, 97 03:09:31 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 > The current AH and ESP drafts state that manual keying is a MUST implement. > This evolved from the earliest versions of these documents, which pre-dated > any agreed upon dynamic key management protocol (i.e. ISAKMP/Oakley). > (This was a long time ago, much too long, as we are all painfully aware...) Yep. It was a good idea then, and it's a good idea now. > This requirement implies that an IPSEC host implementation which supports > only ISAKMP/Oakley using the current AH and ESP drafts (anti-replay or > not... :-), but without manual keying, would not be considered a conformant > IPSEC implementation. That _is_ correct. > Is this what we really want -- manual keying with an optional-to-implement > key management protocol? I want manual keying. Quite honestly, I want a mandatory key mgmt. protocol as well, but there were decisions that were made. Ask Jeff Schiller about said decisions. Ask the IPsec working group chairs at the time about said decisions. They had to do what they had to do. > I'll also point out that our directive from Jeff from last fall states that > ISAKMP/Oakley is mandatory-to-implement for IPv6 IPSEC [1]. Should it not > be the same for IPv4? I actually agree with you in the belief that ISAKMP/Oakley should be required for IPv4. I believe the reason it wasn't explicitly stated as such was to save someone's face and not annoy certain people more than they had been annoyed (or perhaps been annoying) already. > My customers tell me that they don't want to have anything to do with > manual keying. Some of mine feel differently about manual keying. Some of mine want to use other KM schemes too, and/or experiment with them as well. Without a manual keying interface, you cannot experiment (AFAIK) with different KM protocols. Do we want GKMP, or some other multicast protocol to show up eventually? How 'bout customers who want to use KDC technology? IPsec was designed to be INDEPENDENT OF THE FOLLOWING THINGS: 1.) Indivdual policies 2.) Key managment 3.) Algorithms Taking away manual keying weakens the independence of the IPsec architecture. And the independence of the IPsec architecture is its greatest strength. > That's why we're investing in ISAKMP/Oakley. Is it really the desire of > this working group to force me to include something that is insecure and > that my customers don't want to buy? The insecurity of manual keying is only as insecure as the person doing the manual keying. And my customers DO want to buy it. Sorry, one vendor's customer base (no matter how large/small/etc.) doesn't cut it. > One obvious suggestion is to state that one must implement either > ISAKMP/Oakley or manual keying. Another is to just require ISAKMP/Oakley, > as in IPv6. BTW, IPv6 ALSO requires manual keying. So if you want v4's requirements to be like v6's, you'd be requiring manual keying and ISAKMP/Oakley for v4. > Practically speaking, dynamic key management is going to be a prerequisite > for any large-scale deployment of IPSEC. Yep, which is why I agree with the part about mandating ISAKMP for IPv4. Removing manual keying, however, gains us NOTHING and costs us in flexibility and hand-twiddling that some customers want. > What's the sense of the rest of the group? Good question. Dan From owner-ipsec Wed Aug 20 18:54:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA03764 for ipsec-outgoing; Wed, 20 Aug 1997 18:54:02 -0400 (EDT) Message-Id: <199708202258.SAA16167@coredump.cis.upenn.edu> To: Dan.McDonald@Eng.Sun.Com (Dan McDonald) cc: ipsec@tis.com Subject: Re: manual keying and IPSEC conformance In-reply-to: Your message of "Wed, 20 Aug 1997 15:57:46 PDT." <199708202257.PAA26798@kebe.eng.sun.com> Date: Wed, 20 Aug 1997 18:58:28 EDT From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I fully agree with Dan's answer on the subject. Manual keying should remain a requirement for all conforming IPSEC implementations. - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBM/t2k70pBjh2h1kFAQHbEQP/X4yBPdti/m+1IJZR4DQzMDPo8a1sM4xw YtH7c0cVDCKeilmkvK6UyCGQiYur/lZfDvfkKwBB/KQOVcrM31WZoeCWCs3YzRWY Y6SHtLmQS1eL1tkCXKxJ6dfU2XWoURK76eAKIWrJiIsza0LcWB8yk82iibaelxBP lCleSbwNjz8= =a1zS -----END PGP SIGNATURE----- From owner-ipsec Wed Aug 20 19:02:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA03810 for ipsec-outgoing; Wed, 20 Aug 1997 19:01:05 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199708201308.JAA27461@argon.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Aug 1997 19:09:09 -0400 To: "David P. Kemp" From: Stephen Kent Subject: Re: anti-replay notification Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk David, > >If, for automatically-keyed SA's, anti-replay may be used, then why not >just require the sender to behave conservatively and assume that it is >always being used. I.e. never cycle the counter, and don't require AR >notification. That is excatly what the specs require, i.e., the sender always increments the counter and sends a sequence number. Cheryl pointed out how checking for counter overflow at the sender causes a problem for manually keyed SAs (where anti-replay must not be used), so the simple solution I proposed was to supress the counter overflow error in the case of a manually-keyed SA. A more general solution is to supress overflow checking for any SA for which AR is not enabled. That further motivates having the receiver notify the sender if AR is enabled. >That would have the same effect as making anti-replay mandatory (force >rekeying before overflow), but would not force thin receivers to implement >AR just for the sake of compliance with the spec. An abiliity to support AR is mandatory, but its use is optional on a per-SA basis, under the unilateral control of the receiver. >Even if AR notification is simple to add to ISAKMP, it's just one more >detail to code, one more complication to the spec, one more >option to analyze. Philosophically, I lean toward not negotiating things >unless there's a strong benefit to doing so. In this case, the benefit >(allowing SAs to last beyond counter cycling if the receiver is not >doing AR checking) is vanishingly small. The specs do not call for AR negotiation, just notification of use of AR, plus window size. As noted earlier, if we don't notify the sender that AR is enabled, then we can't supress sender checking for overflow in a more uniform fashion. >The debugging benefits of AR window size notification also seem pretty >slim, but I'll defer to the folks with actual implementation/testing >experience to settle that point. Actually, neither implementation nor testing experience is relevant here. What is relevant is operational experience in debugging network problems, especially from a single end of a data path, in an operational environment. We don't have any significant data on this in the context of IPsec, but some folks (perhaps not subscribers on this list) do have such experience. My interactions with folks at our ISP, who do a lot of single-ended debugging of problems, motivates the suggestion for the AR window size notification, at least in part. Steve From owner-ipsec Wed Aug 20 19:02:08 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA03811 for ipsec-outgoing; Wed, 20 Aug 1997 19:01:06 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.1.32.19970820085258.007cdaa0@pop3.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Aug 1997 18:59:55 -0400 To: Rodney Thayer From: Stephen Kent Subject: Re: comments on replay processing Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney, >For Receiver Sequence Number Processing, I think that what we should have is: > >1. receiver extracts sequence number from the packet >2.1 if sequence number is NOT within the current expected range > then >2.2 take action because a replay attack may be underway > else >2.3 life goes on > >Now I don't think the 'action' at step 2.2 is standardized in the draft, I >think it's a local implementation issue. One might delete the SA, call out >the Marines, dump core and halt, output a mild message to the operator >console, output an SNMP Trap, etc. etc. > >I specifically don't think the 'action' is required to include any feedback >to the sender. Therefore, I don't think there is any way the sender is >aware of receiver replay processing. This includes any knowledge of what the >receiver's replay history size is. Furthermore I don't think there is >anything >the sender could do about it. Since there is no feedback in the 'normal' case >and no feedback in the case of an asynchronously deleted SA, I don't see what >reaction, negative or positive, the sender can have. I think the receiver >should >always implement replay checking. If we think this is a safety thing, then we >should require it. Ah and ESP call for auditing the event but recommend not taking any action that could be exploited as a denial of service opportunity. So these specs are not completely silent on the subject of what action to take. The sender may very well have feedback if legitimate packets are being dropped, e.g., if TCP is being used retransmissions will indicate packet loss, but not tell us where the loss occurred. Having knowledge of the receive window size might help in this fault isolation, as I mentioned before. Steve From owner-ipsec Wed Aug 20 20:46:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA04378 for ipsec-outgoing; Wed, 20 Aug 1997 20:45:03 -0400 (EDT) From: fyeung@fyeung8.netific.com (Francis Yeung) Message-Id: <9708210101.AA13495@fyeung8.netific.com> Subject: Re: manual keying and IPSEC conformance To: angelos@dsl.cis.upenn.edu (Angelos D. Keromytis) Date: Wed, 20 Aug 1997 18:01:04 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <199708202258.SAA16167@coredump.cis.upenn.edu> from "Angelos D. Keromytis" at Aug 20, 97 06:58:28 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 > Greetings, Me too. Manual keying should remain a requirement. IPSEC should be independent from KM. Francis > -----BEGIN PGP SIGNED MESSAGE----- > > > I fully agree with Dan's answer on the subject. Manual keying should > remain a requirement for all conforming IPSEC implementations. > - -Angelos > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.3i > Charset: noconv > Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface > > iQCVAwUBM/t2k70pBjh2h1kFAQHbEQP/X4yBPdti/m+1IJZR4DQzMDPo8a1sM4xw > YtH7c0cVDCKeilmkvK6UyCGQiYur/lZfDvfkKwBB/KQOVcrM31WZoeCWCs3YzRWY > Y6SHtLmQS1eL1tkCXKxJ6dfU2XWoURK76eAKIWrJiIsza0LcWB8yk82iibaelxBP > lCleSbwNjz8= > =a1zS > -----END PGP SIGNATURE----- > > > From owner-ipsec Wed Aug 20 21:31:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA04629 for ipsec-outgoing; Wed, 20 Aug 1997 21:30:31 -0400 (EDT) Message-Id: <3.0.1.32.19970820210751.00806a00@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 20 Aug 1997 21:07:51 -0400 To: Stephen Kent From: Rodney Thayer Subject: Re: anti-replay notification Cc: ipsec@tis.com In-Reply-To: References: <199708202049.NAA26034@pita.cisco.com> <97Aug20.152540edt.11652@janus.tor.securecomputing.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I would rather explain how pigs can fly than explain why we are again delaying IPsec. At 06:42 PM 8/20/97 -0400, you wrote: > But can we explain this to the > greater IETF community with a straight face? From owner-ipsec Wed Aug 20 21:31:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA04651 for ipsec-outgoing; Wed, 20 Aug 1997 21:31:02 -0400 (EDT) Message-Id: <3.0.1.32.19970820211253.0082c1a0@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 20 Aug 1997 21:12:53 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: Re: manual keying and IPSEC conformance Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk [much text to and from Dan McDonald will not be retransmitted here, but rather paraphrased...] I want in addition to ISAKMP. In the vernacular, the is called manual keying. I'd rather call it OUT OF BAND keying. This includes: humans typing in keys other key management schemes future IPsec[,++] WG key management schemes I have implementations where I want "manual" keying. So I'd rather manual stay, and ISAKMP stay. I'm speaking mostly V4 but V6 too, sometime. From owner-ipsec Wed Aug 20 23:52:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA05154 for ipsec-outgoing; Wed, 20 Aug 1997 23:49:31 -0400 (EDT) Date: Thu, 21 Aug 97 03:27:37 GMT Daylight Time From: Ran Atkinson Subject: Re: manual keying and IPSEC conformance To: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <3.0.1.32.19970820211253.0082c1a0@pop3.pn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, I'm (potentially at least :-) a customer of Derrell's. I do want to continue to mandate that manual key management continue to be must-implement for conformance to the specifications. We use manual key distribution in some environments. There exist some real world Internet environments where manual key distribution is really the best overall operational approach. I confess that I really liked that the comment from someone else about the architecture being designed to quite clearly decouple: Security Policy Key Management Algorithms Fundamentally, manual key distribution (e.g. via a Marine or other armed courier :-) is probably the only _really_ secure KM game in town. Its also the only thing that works today for multicast traffic [1]. Its the only known way to provide for secure bootstrapping of IPv6 nodes [2]. It isn't hard to implement manual key distribution even if not all the customers want to actually use it. Those customers who don't want to use it, don't have to. That all said, I think it would be A Very Fine thing if ISAKMP/Oakley were also MUST implement for IPv4 IPsec systems. Having the option of using automated key management cannot be anything but goodness. Widespread availability of a common key management protocol is also clearly a win. The market is clearly moving towards ISAKMP/Oakley (e.g. vendors at Interop in LV in May 1997) anyway. Now ISAKMP/Oakley _does_ require that the end parties be authenticated using some form of signed public key (perhaps from Secure DNS or X.509 certs). The past history of the IETF and the Internet is that certificate heirarchies are operationally hard to setup, maintain, and use. One of the reasons that PEM is not widely deployed today for encrypted email is that PEM relied on the availability of a (not yet existing) public key certificate heirarchy. DNSSEC is not yet widely available in running code (the stuff currently in BIND doesn't verify any of the signatures, so it isn't secure in current form). The DNSSEC WG is considering changes to the DNSSEC packet format, which might delay DNSSEC further. In the X.509 arena there are MANY folks in the CA business competing with each other, but cross-certification is not yet an element of the real world. What if I want to talk with user FOO, but I use CA==X, FOO uses CA==Y where (Y!=X) and (X,Y don't cross certify each other) -- result, no secure packets. I don't want IPsec to become dependent on something that in turn depends on the availabilty of any amount of PK infrastructure. I think a PK infrastructure would be A Very Fine Thing; I just don't want IPsec deployment to depend upon it. Ran rja@inet.org [1] Some form of scalable multicast key distribution might well be standardised eventually, but it isn't close to being ready today. [2] An important reason that IPv6 junked ARP and went with Neighbor Discovery was that AH+manual keying provided a mechanism for fully authenticated bootstrap of an IPv6 network (with all its nodes). No form of automated keying can provide this because automated key management doesn't work until the network is up ("automated" in the sense of travelling via some IP packet :-). From owner-ipsec Thu Aug 21 07:25:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA07297 for ipsec-outgoing; Thu, 21 Aug 1997 07:22:30 -0400 (EDT) From: Ly Loi Message-Id: <199708210023.RAA11599@snow.NSD.3Com.COM> Subject: Re: anti-replay notification To: kent@bbn.com (Stephen Kent) Date: Wed, 20 Aug 97 17:23:16 PDT Cc: piper@cisco.com, ipsec@tis.com In-Reply-To: ; from "Stephen Kent" at Aug 20, 97 6:42 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk > Then it was noted that it makes no sense to do anti-replay without > authentication, so the solution is to always mandate authentication. Steve, not necessarily. Another solution is to mandate anti-replay when authentication is on. In other words, in the non-manual keying case, anti-replay and authentication are always used together (if auth is on, anti-replay must be on; if one wants anti-replay, one must have auth). - Ly > > Derrell, > > We started with the issue of whether the receiver needs to tell the > sender what size window is being used for anti-replay purposes, if it is > being used. To avoid this notification complexity, it was suggested that > anti-replay always be used if automated keying is being done. Then it was > noted that it makes no sense to do anti-replay without authentication, so > the solution is to always mandate authentication. What a slippery slope we > have here. We had previously agreed that authentication was not a required > service, e.g., if AH were used in conjunction with ESP. > > I should observe that, at the Munich meeting, Derrell and I > discussed the option of a NULL authentication algorithm to make the ISAKMP > message syntax more niform in the absence of real authentication for ESP. > If the suggestion is to mandate authentication for all automatically keyed > ESP SAs, and to allow the NULL authentication algorithm, then the > performance hit won't be so bad ... :-)! But can we explain this to the > greater IETF community with a straight face? > > Steve > > From owner-ipsec Thu Aug 21 09:13:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA08000 for ipsec-outgoing; Thu, 21 Aug 1997 09:09:30 -0400 (EDT) Date: Thu, 21 Aug 1997 09:16:54 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199708211316.JAA28913@argon.ncsc.mil> To: ipsec@tis.com Subject: Re: manual keying and IPSEC conformance X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk I agree with the several suggestions to make ISAKMP a mandatory part of IPsec for IPv4. And I agree with Dan's rationale for continuing to keep manual keying as a mandatory requirement. The only flaw with this scheme was pointed out by Rodney Thayer's distinction between "really manual" and "some other KMP plugged into the manual keying interface". If we are going to prohibit Anti-Replay for manual keying, it should be explicitly stated that it is only prohibited for "manual keying requiring human intervention for rekey". I don't know if there are any other requirements which depend on manual vs. automatic. If so, they should all be clearly stated as such, so that all KMPs are treated as automatic keying for purposes of interpreting the requirements. From owner-ipsec Thu Aug 21 10:26:02 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA08503 for ipsec-outgoing; Thu, 21 Aug 1997 10:23:29 -0400 (EDT) Date: Thu, 21 Aug 1997 10:31:12 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199708211431.KAA28964@argon.ncsc.mil> To: ipsec@tis.com Subject: Re: manual keying and IPSEC conformance Cc: ietf-pkix@tandem.com X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > From: Ran Atkinson > > In the X.509 arena there are MANY folks in the CA business competing with > each other, but cross-certification is not yet an element of the real world. > What if I want to talk with user FOO, but I use CA==X, FOO uses CA==Y > where (Y!=X) and (X,Y don't cross certify each other) -- result, no secure packets. This is a common misperception about X.509. The ISO/ITU X.509 standard has always explicitly supported arbitrary trust chaining paths (a.k.a. "web-of-trust") but, perhaps due to the PEM experience, most IETF'ers seem to regard X.509 as requiring strict single-rooted or cross-certified multiply-rooted hierarchies. Kudos to the SPKI folks for making explicit the notion that trust chains always begin at the verifier. The PKIX folks perhaps should add some verbiage that makes it clearer that the verifier can choose to trust whomever it wants. That verbiage shouldn't be necessary, but there is apparently a huge PEM legacy-of-perception that needs to be erased. In the IPsec case, if Ran "uses" (has a certificate issued by) CA==X, and FOO has a certificate from CA==Y, there is not necessarily a problem. As long as Ran's machine has a Ran-issued cert for CA==Y stating that Ran trusts Y to certify IPsec nodes (perhaps with name space or policy constraints), then there is no need for X and Y to be cross certified. More generally, each administrative domain would have a single root public key, each node within the domain would trust *only* that root key, and the domain root would certify *all* CAs which are to be trusted by nodes within the domain. The same mechanism is used to address the privilege side of the compartmented information problem that was recently brought up. (The other side of the problem is data labelling.) From owner-ipsec Thu Aug 21 11:49:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA08930 for ipsec-outgoing; Thu, 21 Aug 1997 11:48:01 -0400 (EDT) Message-ID: <33FC6528.4A2C@fet.com> Date: Thu, 21 Aug 1997 08:56:24 -0700 From: "Scott G. Kelly" Organization: Furukawa Electric Technologies, Inc. X-Mailer: Mozilla 3.03 (Win95; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: Re: rush to get spec out References: <199708202049.NAA26034@pita.cisco.com> <97Aug20.152540edt.11652@janus.tor.securecomputing.com> <3.0.1.32.19970820210751.00806a00@pop3.pn.com> <33FC5EA3.8F5@fet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Rodney Thayer wrote: > > I would rather explain how pigs can fly than explain why we are again > delaying IPsec. > I'd just like to toss a comment out, and qualify it by saying that it doesn't necessarily apply to the issue this reply was addressed to, so much as to the tone of this reply. That said, here's my comment: Avoiding further delay in moving the specification forward should *not* be a justification for bad design decisions. There are some components of the collective referred to as IPsec which will *not* be amenable to change later. Now is the time to fix problems in these areas, regardless of politics, current convenience, etc. Scott From owner-ipsec Thu Aug 21 12:17:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA09127 for ipsec-outgoing; Thu, 21 Aug 1997 12:17:01 -0400 (EDT) Message-ID: <01BCAE13.BA0172C0.adams@cisco.com> From: Rob Adams To: "'Dan McDonald'" , "ipsec@tis.com" Subject: RE: manual keying and IPSEC conformance Date: Thu, 21 Aug 1997 09:19:40 -0700 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan brought up some good points.. But the major one, I think was that removing manual keying weakens IPSEC's independence from key management. I'm not sure I agree with this.. As long as the interface exists for placing security associations in the kernel, IPSEC is independent, correct? This doesn't imply that I have to provide all the tools and instructions for manually placing keys in my kernel. I really don't like the idea of being required to support placing keys manually in the kernel and I'm not sure this actually belongs in a protocol specification in the first place... I'd support removing the manual keying stipulation from the documents. -Rob From owner-ipsec Thu Aug 21 14:16:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA09839 for ipsec-outgoing; Thu, 21 Aug 1997 14:13:31 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199708210023.RAA11599@snow.NSD.3Com.COM> References: ; from "Stephen Kent" at Aug 20, 97 6:42 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Aug 1997 10:38:18 -0400 To: Ly Loi From: Stephen Kent Subject: Re: anti-replay notification Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Ly, >> Then it was noted that it makes no sense to do anti-replay without >> authentication, so the solution is to always mandate authentication. > >Steve, not necessarily. Another solution is to mandate anti-replay when >authentication is on. In other words, in the non-manual keying case, >anti-replay and authentication are always used together (if auth is >on, anti-replay must be on; if one wants anti-replay, one must have >auth). Yes, the more precise characterization of what I was trying to say is "always require authentication for non-manually keyed SAs." However, the conclusions I stated are still true, i.e., it is not always appropriate to mandate autentication in ESP and it seems especially silly to do so because of this particular cascade of effects from the initial disagreement over anti-replay window sizes. Several folks have noted that it would be out of character for ISAKMP to respond with an AR window size, due to asymmetry in the negotiation exchange. However, the simplier case of having the receiver notify the sender that the receiver is enabling AR at all, would seem to be easily accommodated. Why can't the sender propose use of AR by the receiver (purely as a construct to maintain symmetry) and then the receiver can accept or reject that pro forma proposal as a way of signalling whether the receiver has enabled AR? Steve From owner-ipsec Thu Aug 21 17:31:56 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA10824 for ipsec-outgoing; Thu, 21 Aug 1997 17:30:32 -0400 (EDT) Message-ID: From: Roy Pereira To: "'Dan.McDonald@Eng.Sun.Com'" , "'Angelos D. Keromytis'" Cc: "'ipsec@tis.com'" Subject: RE: manual keying and IPSEC conformance Date: Thu, 21 Aug 1997 17:46:17 -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 If we keep manual keying as a MUST, then any implementation that does not implement manual keying will be considered not IPSec-compliant. I do not agree with this. I know that most of our clients do not want a back door like manual keying in their security product. >---------- >From: Angelos D. Keromytis[SMTP:angelos@dsl.cis.upenn.edu] >Sent: Wednesday, August 20, 1997 6:58 PM >To: Dan.McDonald@Eng.Sun.Com >Cc: ipsec@tis.com >Subject: Re: manual keying and IPSEC conformance > >-----BEGIN PGP SIGNED MESSAGE----- > > >I fully agree with Dan's answer on the subject. Manual keying should >remain a requirement for all conforming IPSEC implementations. >- -Angelos > >-----BEGIN PGP SIGNATURE----- >Version: 2.6.3i >Charset: noconv >Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface > >iQCVAwUBM/t2k70pBjh2h1kFAQHbEQP/X4yBPdti/m+1IJZR4DQzMDPo8a1sM4xw >YtH7c0cVDCKeilmkvK6UyCGQiYur/lZfDvfkKwBB/KQOVcrM31WZoeCWCs3YzRWY >Y6SHtLmQS1eL1tkCXKxJ6dfU2XWoURK76eAKIWrJiIsza0LcWB8yk82iibaelxBP >lCleSbwNjz8= >=a1zS >-----END PGP SIGNATURE----- > From owner-ipsec Thu Aug 21 17:43:39 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA10915 for ipsec-outgoing; Thu, 21 Aug 1997 17:43:31 -0400 (EDT) Message-Id: <2.2.32.19970821215251.006b8f6c@pop.erols.com> X-Sender: tbartee@pop.erols.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 21 Aug 1997 17:52:51 -0400 To: ipsec@tis.com From: Thomas Bartee Subject: SAs and SPIs Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id RAA10912 Sender: owner-ipsec@ex.tis.com Precedence: bulk The subject of SA-SPI methodology and if it can be used to satisfy current demands from business for security is clearly of interest to IPSEC. It is good to see the quality and quantity of the correspondence on SA-SPI usage. There have been several questions to me asking for some more details. (The Security Intellectual of the Week Award clearly goes to Ozan S. Yigit at Secure Computing for identifying Kurosawa's Rashomon. Good shot.) 1. Let's return to SA-SPIs. First, the demand for security by businesses is very large. I suspect to have more than limited acceptance it will be necessary for IPSEC products to satisfy the demand for operating procedures which will enable businesses to not weaken their current operating procedures if they transfer communications to the Net. The practices I wrote about are very real and widespread. For example, I designed some production control equipment for a small corporation. The system was in a locked room where only selected employees had the key. Other employees, even those working in the same area, were not allowed access. This corporation made special electronics components for a number of manufacturers and also plastic products for several larger corporations, including a major camera manufacturer. (For example, they made plastic film containers for a major camera manufacturer. Employees in this operation were physically separated from the other employees.) Correspondences between the small corporation and the larger ones they did business with, was carefully controlled and engineering drawings, production data, etc. were carefully transmitted either by courier or by registered, certified mail. I also did work for a camera manufacturer where film development operations were divided into separated projects that were carefully separated from camera development. Engineering documents travelling from department to department were signed in and out and transmissions to subcontractors were registered and signed for at the receiving end. These practices are widespread. My experiences with EGG, Raytheon, and a host of others were similar. Recently I had some correspondence with a biotech company where employees in one development section were physically separated from other employees. All inter-corporate communications were carefully controlled and also the members of this division were warned to not betray progress (or the lack of it) by appearing very happy (or sad) when passing other employees. It is hard to believe that in the long run Ford will be happy if GM (also on the Auto Industry Net, see Dave Kemp for a good comment) can access Ford key material related to correspondence with parts suppliers, consulting firms on development projects, etc. Remember, Ford, Chrysler, and GM are international corporations. The extent to which their branches will want to use the net for subcontractor and branch-to-branch communication will be largely dependent on the users' confidence in the security of the system. Usage will also depend on the ease with which secure subnetworks can be implemented, and taken down. Do not think large corporations are bound to a single LAN with one or more WAN connections. Flexibility and the ability to accommodate changing corporate structures (remember, they reorganize) and to establish and take down secure communications channels to subcontractors will bear heavily on the success of the IPSEC effort. Rodney Thayer's comments are suggestive of what I think the actual situation is. 2. NSA trained security analysts (I include anyone with a set of coloring books) have built in mental associations that are immediately triggered when the communications situation is more complex than the Dick wants to talk to Jane and Henry wants to listen in or interrupt. Any more complicated situation is swept under a large rug labeled MLS. Then another synapse is triggered and we start hearing about B2, B1, C1, etc. These are interesting concepts and the fact we can use terms B2, C2,… without worrying that others will not understand shows the pervasive effect of the color orange on book readers (clearly there aren't enough books with orange covers. Also, can anyone name a film with orange in the title?) The digression into B2-land in SA-SPI comments is interesting but it seems to me that we are here concerned with IP security and its usefulness in protecting communications. If employee X has access to data on project A and project B and he wants to give it to someone, he can. His transmission can be by Internet, but also by mail, telephone, meetings in a bar etc. Breaking computers into compartments using a kernel is a worthwhile future endeavor, but let us stick to the subject at hand, which is protecting information on the Internet. The comments by Howie Weiss are first rate on this subject, by the way. 3. The note from Steve Kent to John Shriver is very well put together. I am pleased to note that he has carefully hedged the term MLS and is also careful to qualify the use of the term MLS and Security Levels by alluding to compartments, etc. Compartments and releases are the important things, even for government usage. While the Military makes heavy use of the categories Secret, Confidential, Top Secret, etc, which probably offer the few examples of a pure hierarchical security situation, most of the Government operates at a single level (controlled by NIST) and the Intelligence operations almost all consist of compartments, all at a single level (i.e., not multi-level but compartmented.) One of the points of my Amgen example was to show commercial data is "compartmented" in the often-used vernacular. (Steve knows this and so do Ran Atkinson and others who have written comments.) The point is that security structures are not that complex and can be accommodated with careful design, but this design step must be taken and not deferred. Steve's comments should be carefully read by all. Ran Atkinson also has placed his weighty oar in the stream. I think John Horton's comments on his comments and my offering are very clear and also worth reading. Horton's use of the word domain bothers me but his basic idea is very clear. A good shot (but what is the organization alluded to?) Returning to Atkinsons' note, I worry about pushing clear operational requirements into a big box called security policy and then deferring discussion of how given "policies" might be implemented. From what I can see commercial concerns operate with pretty much the same policy (always remember levels can be shoveled into compartments.) Atkinson, who is obviously very knowledgeable, gives a nice listing of presently existing relevant documents and some ideas on how they could be used. He also brings up Bell-LaPadula and lattice theory springs into our minds (I taught lattice theory at Harvard with the late and great mathematician Garrett Birkhoff, who is regarded as the father of lattice theory, for several years. I am sympathetic to this but am afraid it is a diversion here.) He also mentions labels and these I suspect are important, particularly considering the legal aspects of secure communications. 4. The looked-for methodology and an example of the usage of this methodology have not yet appeared. Perhaps Steve Kent's assessment is right. I am not the Thomas Q. Bartee of MITRE whose address was on an early submission. He is my son. I had the e-mail ready to go in Friday. Saturday night he used the computer (after midnight, I was asleep) and placed his name and address in a Eudora feature which then attached his name to my work when I pushed the send button Monday morning. I may threaten him with B2. I am Thomas C. Bartee. From owner-ipsec Thu Aug 21 17:44:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA10928 for ipsec-outgoing; Thu, 21 Aug 1997 17:44:02 -0400 (EDT) From: Dan.McDonald@Eng.Sun.Com (Dan McDonald) Message-Id: <199708212152.OAA12341@kebe.eng.sun.com> Subject: Re: manual keying and IPSEC conformance To: rpereira@TimeStep.com (Roy Pereira) Date: Thu, 21 Aug 1997 14:52:50 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: from "Roy Pereira" at Aug 21, 97 05:46:17 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 know that most of our clients do not want a back door like manual > keying in their security product. One thing I have a terrible time understanding is why people think manual keying will make their systems LESS secure. The only gain in security you get by disabling manual keying is STO, and that's because your adversary has to somehow gain access to the machine state by other means than a manual keying interface. I'm not saying manual keying should be an operation open to every user on a system, at every privilege level. It's most definitely a privilege; root-level on UNIX, and requiring its own privilege class on an MLS system. And if you're on a system that has only one privilege level (PC of some kind), then machine state is probably not difficult to obtain anyway. If anything, manual keying is the only truly secure method of key exchange. Two ultra-paranoid parties figure out in a locked room what the key is, they go home and _manually_ add it to their respective systems, which they have locked up and guarded with shotguns, dogs, etc. The problem reduces to the key strength of the algorithm in question. Now granted, the current suite of algorithms and key exchanges are such that the strength of the key exchange dominates the strength of the algorithms being used, but that doesn't have to be the case. Hell, I may want to use 2048-bit El Gamal on my traffic w/o having to secure it with a 4096 exchange. Sure it'll be slow, but it'll definitely be secure. --- On another note, thanks to those who pointed out that there is a difference between manual keying, and hooks for other KM schemes. In my haste to get out my first note, I failed to make that distinction. Noting that distinction, however, I will say that if you have hooks for other key mgmt. schemes, it shouldn't be too terribly painful to use the same hooks to attach some sort of user-interface to your SADB/Key-Engine/etc. Even if your hooks are inside a protection boundary, a shim that crosses that protection boundary shouldn't be difficult to construct. I offer the BSD Routing Socket, and that the route(8) command in BSD is just a command-line interface to said routing socket, as an example. Dan From owner-ipsec Thu Aug 21 17:55:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA10980 for ipsec-outgoing; Thu, 21 Aug 1997 17:55:01 -0400 (EDT) Message-ID: From: Roy Pereira To: Roy Pereira , "'Dan.McDonald@eng.Sun.COM'" Cc: "'ipsec@tis.com'" Subject: RE: manual keying and IPSEC conformance Date: Thu, 21 Aug 1997 18:10:49 -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 Perhaps "back door" was too strong of a statement, but manual keying might present a security risk if an uninformed user set it up incorrectly. We must make some form of KM is a MUST for interoperabilities sake, and if you do not do so with ISAKMP, then we must manual keying a MUST. My point though, was that I do believe that an implementation that does not support manual keying (either turns it off, or doesn't even have the code for it) should still be considered IPSec-compliant. >---------- >From: Dan.McDonald@eng.Sun.COM[SMTP:Dan.McDonald@eng.Sun.COM] >Sent: Thursday, August 21, 1997 5:52 PM >To: Roy Pereira >Cc: ipsec@tis.com >Subject: Re: manual keying and IPSEC conformance > > >> I know that most of our clients do not want a back door like manual >> keying in their security product. > >One thing I have a terrible time understanding is why people think manual >keying will make their systems LESS secure. The only gain in security you >get by disabling manual keying is STO, and that's because your adversary has >to somehow gain access to the machine state by other means than a manual >keying interface. > >I'm not saying manual keying should be an operation open to every user on a >system, at every privilege level. It's most definitely a privilege; >root-level on UNIX, and requiring its own privilege class on an MLS system. >And if you're on a system that has only one privilege level (PC of some >kind), then machine state is probably not difficult to obtain anyway. > >If anything, manual keying is the only truly secure method of key exchange. >Two ultra-paranoid parties figure out in a locked room what the key is, they >go home and _manually_ add it to their respective systems, which they have >locked up and guarded with shotguns, dogs, etc. The problem reduces to the >key strength of the algorithm in question. > >Now granted, the current suite of algorithms and key exchanges are such that >the strength of the key exchange dominates the strength of the algorithms >being used, but that doesn't have to be the case. Hell, I may want to use >2048-bit El Gamal on my traffic w/o having to secure it with a 4096 exchange. >Sure it'll be slow, but it'll definitely be secure. > >--- > >On another note, thanks to those who pointed out that there is a difference >between manual keying, and hooks for other KM schemes. In my haste to get >out my first note, I failed to make that distinction. > >Noting that distinction, however, I will say that if you have hooks for other >key mgmt. schemes, it shouldn't be too terribly painful to use the same hooks >to attach some sort of user-interface to your SADB/Key-Engine/etc. Even if >your hooks are inside a protection boundary, a shim that crosses that >protection boundary shouldn't be difficult to construct. > >I offer the BSD Routing Socket, and that the route(8) command in BSD is just >a command-line interface to said routing socket, as an example. > >Dan > From owner-ipsec Thu Aug 21 18:58:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA11343 for ipsec-outgoing; Thu, 21 Aug 1997 18:57:00 -0400 (EDT) Message-Id: <199708212301.TAA21878@coredump.cis.upenn.edu> To: Roy Pereira cc: "'Dan.McDonald@eng.Sun.COM'" , "'ipsec@tis.com'" Subject: Re: manual keying and IPSEC conformance In-reply-to: Your message of "Thu, 21 Aug 1997 18:10:49 EDT." Date: Thu, 21 Aug 1997 19:01:14 EDT From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In message , Roy Pereira writes: >Perhaps "back door" was too strong of a statement, but manual keying >might present a security risk if an uninformed user set it up >incorrectly. Nothing in the world can protect you if your priviledged users are uninformed (well, maybe MLS). - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBM/zIur0pBjh2h1kFAQGubgP/eUSxzW2qPHpfvYY0jHC43+Y8JHfNi6t6 Ewuu2BgqcJI3WpqWr1ClM+4tX/gaV6BxIqCs3ZnojqNcSjz4mgdD7ECV4PYAveKr UNGL5KDkzNAg7SKrjqHMJDG394G4JroRVCgn7AfK7LfrlffSxbhhABNIzlCdLRqO 9FAUiBdeh2E= =pSS8 -----END PGP SIGNATURE----- From owner-ipsec Thu Aug 21 19:01:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA11363 for ipsec-outgoing; Thu, 21 Aug 1997 19:01:01 -0400 (EDT) Message-Id: <199708212309.QAA14896@pita.cisco.com> To: Stephen Kent cc: Ly Loi , ipsec@tis.com Subject: Re: anti-replay notification In-reply-to: Your message of "Thu, 21 Aug 1997 10:38:18 EDT." Date: Thu, 21 Aug 1997 16:09:54 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk >Why can't the sender propose use of AR by the receiver >(purely as a construct to maintain symmetry) and then the receiver can >accept or reject that pro forma proposal as a way of signalling whether the >receiver has enabled AR? Steve, If the intent is to communicate the receiver's actual window size back to the initiator, this wouldn't work because the initiator would have to know/guess what window size the receiver would want to choose. In ISAKMP, the destination only chooses from the initiator's SA proposals. The responder does not, himself, propose... You could offer a set of replay window sizes, in multiples of 32, but this would expand the SA proposal list multiplicitively by "n", where "n" were the number of replay window sizes you'd offer. Even if you were interested only in knowing whether the responder had selected AR, you'd still expand the proposals by 2. It would make more sense to define AR as "different" and special-case the replay window size attribute on one or both sides. This additional complexity is, however, why I want to mandate use of anti-replay for dynamic keying with authentication (AH or ESP-auth). Derrell From owner-ipsec Thu Aug 21 19:23:33 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA11475 for ipsec-outgoing; Thu, 21 Aug 1997 19:22:03 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199708212309.QAA14896@pita.cisco.com> References: Your message of "Thu, 21 Aug 1997 10:38:18 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Aug 1997 19:32:46 -0400 To: Derrell Piper From: Stephen Kent Subject: Re: anti-replay notification Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Derrell, >If the intent is to communicate the receiver's actual window size back to >the initiator, this wouldn't work because the initiator would have to >know/guess what window size the receiver would want to choose. In ISAKMP, >the destination only chooses from the initiator's SA proposals. The >responder does not, himself, propose... That was not the intent and it was not what I said. What I said was: "Why can't the sender propose use of AR by the receiver (purely as a construct to maintain symmetry) and then the receiver can accept or reject that pro forma proposal as a way of signalling whether the>receiver has enabled AR?" This refers only to the responder signalling whether AR is enabled for the SA, NOT signalling the size of the window. Your response indicates that this more modest approach would work and it does not sound complicated. >You could offer a set of replay window sizes, in multiples of 32, but this >would expand the SA proposal list multiplicitively by "n", where "n" were >the number of replay window sizes you'd offer. Even if you were interested >only in knowing whether the responder had selected AR, you'd still expand >the proposals by 2. It would make more sense to define AR as "different" >and special-case the replay window size attribute on one or both sides. This would be practical if the range of window sizes were small, e.g., 32, 64, 96 and 128. However my message did not suggest that because the number of proposals could grow large if there was not agreement on the window size range. Steve From owner-ipsec Thu Aug 21 19:49:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA11562 for ipsec-outgoing; Thu, 21 Aug 1997 19:48:02 -0400 (EDT) Message-Id: <199708212357.QAA15795@pita.cisco.com> To: Stephen Kent cc: ipsec@tis.com Subject: Re: anti-replay notification In-reply-to: Your message of "Thu, 21 Aug 1997 19:32:46 EDT." Date: Thu, 21 Aug 1997 16:57:17 -0700 From: Derrell Piper Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, >That was not the intent and it was not what I said. What I said was: > >"Why can't the sender propose use of AR by the receiver >(purely as a construct to maintain symmetry) and then the receiver can >accept or reject that pro forma proposal as a way of signalling whether >the>receiver has enabled AR?" Forgive me if I mistated the intent. The current AH and ESP documents do state that that is the intent though, do they not? [current text below] >This refers only to the responder signalling whether AR is enabled for the >SA, NOT signalling the size of the window. Your response indicates that >this more modest approach would work and it does not sound complicated. This will work at the expense, on the wire, of requiring that each SA proposal be more than twice as large (in bytes) as it would otherwise be without "negotiated" AR. I agree that it's not overly complicated. So where are we on this issue? The current text in AH and ESP says: If an SA establishment protocol such as Oakley/ISAKMP [sic] is employed, then the receiver SHOULD notify the transmitter, during SA establishment, if the receiver will provide anti-replay protection and SHOULD inform the transmitter of the window size. ...yet we're now discussing a simple boolean indication -- whether or not the responder chose AR, not what window size they selected. I'd like to see us try to come to closure on this issue by tomorrow. We have more interesting fish to fry. >This would be practical if the range of window sizes were small, e.g., 32, >64, 96 and 128. However my message did not suggest that because the number >of proposals could grow large if there was not agreement on the window size >range. I didn't think that would be a good way to do this either... Derrell From owner-ipsec Thu Aug 21 20:52:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA11856 for ipsec-outgoing; Thu, 21 Aug 1997 20:51:30 -0400 (EDT) Date: Fri, 22 Aug 97 00:49:38 GMT Daylight Time From: Ran Atkinson Subject: RE: manual keying and IPSEC conformance To: Roy Pereira Cc: "'ipsec@tis.com'" X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Thu, 21 Aug 1997 17:46:17 -0400 Roy Pereira wrote: > I know that most of our clients do not want a back door like manual > keying in their security product. ---------------End of Original Message----------------- For my definition of "back door", manual keying is NOT a back door. Manual keying does NOT imply any kind of security reduction. Sooo, could you please define "back door" in your terms so I understand what you're saying ??? If you think manual keying reduces security, please explain in detail. I'm sure I'm not following something here... Ran From owner-ipsec Thu Aug 21 21:15:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA11981 for ipsec-outgoing; Thu, 21 Aug 1997 21:15:01 -0400 (EDT) Message-Id: <199708220122.VAA03781@postal.research.att.com> To: Ran Atkinson cc: Roy Pereira , "'ipsec@tis.com'" Subject: Re: manual keying and IPSEC conformance Date: Thu, 21 Aug 1997 21:22:33 -0400 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk Although I prefer use of ISAKMP, I feel that manual keying is important to have, for several reasons. First, there's the need for backup. Key management is a more delicate business -- certificates may be unavailable, the daemon may be in a bad mood, etc. In a sense, this is an analog to the 'bypass' switch on older crypto boxes, such as BLACKER. Second, there's the firewall problem. ISAKMP is UDP-based, which makes it hard to relay through firewalls. In some environments, manual keying may be preferable to opening a hole in the firewall for ISAKMP communications. (As an aside, the ISAKMP draft notes this problem. I suggest that the draft be amended to include a note suggesting that implementations include an option to use a fix, user-specified port number for all ISAKMP packets. Port 500 is used to receive messages, but a daemon that wishes to initiate communications with a remote ISAKMP may prefer to use a different port.) Third, and most serious, I can think of one environment where manual keying may be necessary because ISAKMP doesn't scale: large-scale network management platforms. A workstation that is managing thousands of hubs, CSUs, routers, etc., will need to negotiate and cache thousands of security associations. A single shared key may be preferable. From owner-ipsec Thu Aug 21 22:01:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA12196 for ipsec-outgoing; Thu, 21 Aug 1997 22:00:00 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 21 Aug 1997 19:08:23 -0700 From: Eugene Chang To: ipsec@tis.com Subject: IPSEC or ISAKMP TEST TOOLS Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: owner-ipsec@ex.tis.com Precedence: bulk I was wondering if there are any public or commerical (IE. for sale) IPSEC or ISAKMP test tools out there. For the purposes of testing the security and performance of an install system. Thankyou. From owner-ipsec Fri Aug 22 07:07:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA14912 for ipsec-outgoing; Fri, 22 Aug 1997 07:05:58 -0400 (EDT) Message-Id: <3.0.3.32.19970822071156.00cd23a0@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 22 Aug 1997 07:11:56 -0400 To: ipsec@tis.com From: Robert Moskowitz Subject: IPsec product progress Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk If anyone will be in Detroit next week tues-thurs and can make it to AutoTech, we will be having a live demonstration of IPsec products interoperating. Things are touch and go. We have had routing and hardware problems that have significantly delayed us. We do have 5 vendors here and on monday I will know exactly what to whom we will be demonstrating real automotive applications secured with IPsec. All of the products are configured for the current ESP DES-CBC explicit and AH HMAC-MD5. Oakley is handling session establishment. We did not get the hardware for the CA in time to set up certificates, so we are using pre-shared keys. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Fri Aug 22 10:00:27 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA16279 for ipsec-outgoing; Fri, 22 Aug 1997 09:57:36 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199708212357.QAA15795@pita.cisco.com> References: Your message of "Thu, 21 Aug 1997 19:32:46 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Aug 1997 10:04:13 -0400 To: Derrell Piper From: Stephen Kent Subject: Re: anti-replay notification Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Derrell, Yes, the AH and ESP specs call for AR window size notification by the receiver to the sender. I was addressing the more narrow question of AR notification, in the text you explicitly cited, because the discussion had drifted into the more general issue of "why notify at all, let's just always do AR, and authentication, ..." As for closing the discussion, my recollection was that Ted said he was going to revisit the archives to resolve this, but then Dan seems to have prempted that by reopening the discussion on the list. Certainly the half-dozen folks who have participated in Dan's straw poll over the last 3 days have expressed an overwhelming opposition to window size notification. But then the discussion drifted into broader suggestions of changes to more aspects of ESP, as I detailed in a previous message. When WG chairs have called for polls, they usually run longer than 3 days, so, I'll defer to the WG co-chairs to decide when the question has been decided. Steve From owner-ipsec Fri Aug 22 11:15:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA16788 for ipsec-outgoing; Fri, 22 Aug 1997 11:12:43 -0400 (EDT) Message-Id: <3.0.1.32.19970822111938.007f3ae0@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 22 Aug 1997 11:19:38 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: RE: manual keying and IPSEC conformance Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk How is manual keying any more or less of a risk than pre-shared secrets in ISAKMP? [I know how I answer this, I am wondering what others think...] From owner-ipsec Fri Aug 22 11:21:11 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA16830 for ipsec-outgoing; Fri, 22 Aug 1997 11:19:41 -0400 (EDT) Message-Id: <199708221528.IAA15537@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: Re: replay revisited In-Reply-To: Your message of "Tue, 19 Aug 1997 15:52:29 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Aug 1997 08:28:23 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, > > It would be more reasonable to strongly advise the use of window sizes > >which are a multiple of the word size of the processor of the box on which > >the code runs and also to strongly recommend against use of window sizes > >lower than 32 bits. > > The requirement for a window size that is a multiple of 32 is motivated > purely by ease of implementation concerns. A couple of years ago I > suggested using a bit mask to track received packets within the window, to > allay concerns over the implementation costs of supporting anti-replay. > Jim Hughes provided sample code for doing this in his I-Ds, demonstrating > that the general notion worked efficiently. Since CPU registers tend to be > 32 or 64 bits in length, it was suggested (by Bob Moskowitz?) that the > integral multiple of 32 was an appropriate constraint on window sizes. > However, I agree that a word size multiple is appropriate, and the multiple > of 32 accommodates modren processors with either 32 or 64 bit > architectures. You're right, the old DEC-20 is at a disadvantage here and > the WG needs to decide if that's acceptable, or not. Finally, the current > draft, at Bob Moskowitz's suggestion, calls for a default window size of > 64, with 32 as a minimum. Mandating ease of implementation seems silly. It's obvious why the multiple of 32 was selected and I'm sure all implementations are doing something analagous to Hughes' sample code (if they didn't just cut-and-paste it directly into their build). So, it's not an issue of whether the WG should decide if the dec20 is an acceptable processor on which to run IPSec, it's an issue of whether the WG should either mandate certain processors or mandate that weirdos (like the dec20) be inefficient-- which is contrary to the whole reason the problematic text was added in the first place! Come on, just strike the text and replace it with a mention that window sizes should be a multiple of word sizes and should be greater than 32. > I thought the focus of our argument was whether the receiver needed to > inform the sender of the window size, in the cases when anti-replay was in > effect. The argument I have made was that without such information, the > sender has a harder time trying to trouble shoot if there are connection > problems. Consider a user connecting to some sort of (non-HTTP) server. > If the user has problems, the user will contact his help desk, which then > will try to isolate the problem. Pardon my cynicism but the first thing out of the mouth of the help desk will be: "are you using the same keys?" not "is he checking the sequence number and what's his window size?" The transmitter always sends it and must always assume it is being checked in a troubleshooting situation. Perhaps if you could come up with a problem that can only be diagnosed by having definite knowledge of whether the other party is checking the sequence number I might be convinced that this is needed. It seems like a nonessential piece of information the help desk will file away as they start traceroute (or playing tetris). Dan. From owner-ipsec Fri Aug 22 12:55:03 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA17381 for ipsec-outgoing; Fri, 22 Aug 1997 12:52:42 -0400 (EDT) Message-Id: <199708221652.MAA17381@portal.ex.tis.com> X-Mailer: Novell GroupWise 4.1 Date: Fri, 22 Aug 1997 10:49:16 -0600 From: Mike Smith To: dpkemp@missi.ncsc.mil, ipsec@tis.com Cc: ietf-pkix@tandem.com Subject: Re: manual keying and IPSEC conformance Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: owner-ipsec@ex.tis.com Precedence: bulk "Trust chains Always begin at the verifier". In a situation where a corporation has established (or outsourced) a CA function, the "verifiers" would be in the trust hierarchy of the corporation, not at the individual. I believe that the corporate CA would be the entity specifying or allowing THEIR trust to be extended to extrnal entities (such as authorized vendors' CAs, etc.) Michael >>> David P. Kemp 08/21/97 08:31AM >>> > From: Ran Atkinson > > In the X.509 arena there are MANY folks in the CA business competing with > each other, but cross-certification is not yet an element of the real world. > What if I want to talk with user FOO, but I use CA==X, FOO uses CA==Y > where (Y!=X) and (X,Y don't cross certify each other) -- result, no secure packets. This is a common misperception about X.509. The ISO/ITU X.509 standard has always explicitly supported arbitrary trust chaining paths (a.k.a. "web-of-trust") but, perhaps due to the PEM experience, most IETF'ers seem to regard X.509 as requiring strict single-rooted or cross-certified multiply-rooted hierarchies. Kudos to the SPKI folks for making explicit the notion that trust chains always begin at the verifier. The PKIX folks perhaps should add some verbiage that makes it clearer that the verifier can choose to trust whomever it wants. That verbiage shouldn't be necessary, but there is apparently a huge PEM legacy-of-perception that needs to be erased. In the IPsec case, if Ran "uses" (has a certificate issued by) CA==X, and FOO has a certificate from CA==Y, there is not necessarily a problem. As long as Ran's machine has a Ran-issued cert for CA==Y stating that Ran trusts Y to certify IPsec nodes (perhaps with name space or policy constraints), then there is no need for X and Y to be cross certified. More generally, each administrative domain would have a single root public key, each node within the domain would trust *only* that root key, and the domain root would certify *all* CAs which are to be trusted by nodes within the domain. The same mechanism is used to address the privilege side of the compartmented information problem that was recently brought up. (The other side of the problem is data labelling.) ! ! ! ! From owner-ipsec Fri Aug 22 13:56:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA17832 for ipsec-outgoing; Fri, 22 Aug 1997 13:53:42 -0400 (EDT) Date: Fri, 22 Aug 1997 12:57:11 -0500 (CDT) From: "Brian M. Thomas" X-Full-Name: Brian M. Thomas Message-Id: <199708221757.MAA22860@entropy.sbc.com> To: mfsmith@zionsbank.com, ietf-pkix@tandem.com, ipsec@tis.com Subject: Re: manual keying and IPSEC conformance X-Sun-Charset: US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk The verifier is the entity making the trust decision. Truly enough, it must decide in accordance with the corporate policy, as expressed by the corporate CA. However, the dumb little program doesn't have any way of knowing that the expression of that policy it works with is valid, absent some verifiable assertion of the fact. The only key the program can trust ultimately is its own. The verifier is therefore the root of the trust chain. This is true whether the trust is implicit, via a configuration file or the compiling in of the CA's key (as in your example), or explicit, via a certificate. The analogy to the human world is direct. If my signature on a document is binding on the corporation, I am under obligation to follow the policies of the corporation in signing it. However, there is no way to force me to follow policies in my signing of documents; only to punish me if I don't. I still must choose to trust whomever the corporate decision-makers say they trust, even though your point is valid in that they have extended trust to me to act in accordance with their wishes. brian Brian Thomas, CISSP - Distributed Systems Architect bt0008@entropy.sbc.com Southwestern Bell bthomas@primary.net One Bell Center, Room 34G3 Tel: 314 235 3141 St. Louis, MO 63101 Fax: 314 235 0162 From owner-ipsec Fri Aug 22 14:04:12 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA17894 for ipsec-outgoing; Fri, 22 Aug 1997 14:02:43 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199708150321.UAA18310@trix.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Aug 1997 14:10:31 -0400 To: Cheryl Madson From: Stephen Kent Subject: Re: ESP/AH draft comments Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Cheryl, In looking back on your comments, I realize that my response to one of them was based on a misreading of the text. You said: >ESP > >2. Section 2.1: I've always found it easier to state that an SPI is >uniquely identified by the tuple (dest addr, security prot, spi). > I read this to be "an SA is uniquely identified by ..." even though you wrote "an SPI is uniquely identified by ..." The former is a nice concise way to express the way we identify an SA, the latter is odd as it states that a value is uniquely identified by a triple consisting of that value plus two others. We'll reword the section in question, but it won't use the exact terminology you suggested. Steve From owner-ipsec Fri Aug 22 17:09:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA19027 for ipsec-outgoing; Fri, 22 Aug 1997 17:04:44 -0400 (EDT) Message-Id: <199708222113.RAA00438@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: hsw@columbia.sparta.com (Howard Weiss) Cc: smb@research.att.com (Steven Bellovin), dave@tlogic.com, ipsec@tis.com Subject: Re: IPSEC and NAT In-Reply-To: hsw's message of Tue, 19 Aug 1997 09:21:11 -0400. <9708191321.AA03146@katahdin.columbia.sparta.com> Date: Fri, 22 Aug 1997 17:13:25 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > > The point is simple: IPSEC guards against tampering with the packet, > > and NAT boxes by definition tinker with at least the addresses. > > > > Couldn't one tunnel through a NAT? I am not anywhere near as optimistic as Bob about whether we can make IPSEC and NAT play nice with each other. It's not immediately clear what this means, because NAT is a way to bridge between multiple routing/addressing domains. By tunnelling through, you're (pardon the Ghostbusters analogy) "crossing the streams". are the addresses on the "inside" of the tunnel from one domain, or the other? or do they form a third addressing domain? Are you going to force NAT functionality into the systems on each end of the tunnel (and one end may well be the "road warrior") so that they can deal with address collisions between the local "real" network and the tunnel? How do you distinguish between addressing domains at the socket/API layer on an end system? How do you make this manageable? It seems like an awful lot of work to do to accomodate a technology which completely breaks just about every single system/protocol I've worked on in the past 10 years. - Bill From owner-ipsec Fri Aug 22 22:03:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA20225 for ipsec-outgoing; Fri, 22 Aug 1997 22:01:14 -0400 (EDT) Date: Fri, 22 Aug 1997 22:08:35 -0400 Message-Id: <199708230208.WAA20531@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Cc: Sara Bitan , wdm@epoch.ncsc.mil (W. Douglas Maughan), "Baiju V. Patel" , Naganand Doraswamy Subject: Draft IPSec working group minutes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi all, I've just recently gotten back from Europe (I spent a few extra days of vacation visiting a friend in Belgium). As a result, I'm still trying to catch up on back-email at this point, for those of you who may have been wondering why I haven't chimed in on the mailing list in a while. As promised, I have been doing some research on past wg discussions on the anti-replay issue --- I'll be writing up something on that shortly. Enclosed please find the draft IPSEC working group minutes from the Munich meeting. Many thanks to Rodney for volunteering to be the scribe! These minutes can be found on the web, at: http://web.mit.edu/tytso/www/ipsec/munich The HTML version includes links to the slides (in postscript form) for those presentations where I've already received electronic versions of the slides. As a reminder to those who gave presentations, please send me copies of your slides in electronic form. (If I haven't received your slides yet, I've included you as an explicit cc on this message.) Thanks!! Please review these minutes for accuracy; if you think a particular section should be clarified, please submit proposed replacement text which you feel is more accurate. In roughly a week I plan to be sending the official wg minutes to the IETF secretariat. - Ted IETF Munich IPsec Working Group Meeting Minutes Moderator: Ted Ts'o , WG Co-Chair Scribe: Rodney Thayer The WG met on Friday at the IETF meeting in Munich. Approximately 120 people attended. This was MBONE broadcast. The Agenda was: - Agenda Bashing - Introduction - Active WG Documents - AH and ESP Review - DES MAC Presentation - ISAKMP Review - Architecture Review - Trust Path Topology Presentation - VPN Presentation - Secure DHCP Presentation - IPsec Followon Presentation Active WG Documents - Ted Ts'o Ted presented the list of documents, all 29 of them. This includes top-level, encryption, authentication, key management, and some obsolete Internet Drafts. This does include some that have received little feedback, such as the ISAKMP optimization proposal, and the WG was encouraged to make sure people have reviewed the documents. It was pointed out that there are too many drafts, and we should somehow cut down the number. There was a discussion about what can be advanced, the answer was that some sort of consistent set of documents has to be advanced together so that people can get context when they read them. AH and ESP Review - Steve Kent Steve Kent reviewed the AH and ESP documents. These together with the Architecture document and the (default, referenced) ESP Cipher and Authentication drafts would make up the minimal set that can be advanced. There was a discussion of window size, which has carried forward to the mailing list. There was some discussion about mutable fields being zero and not some predicted value. There was discussion about sequence number roll-over if manually keyed (conclusion: ignore rollover) There was mention that the defaults are now DES/CBC, HMAC-MD5(?), and 64 packet replay window. DES MAC Presentation - Sara Bitan This was a proposal to use DES as a MAC algorithm -- do a separate DES operation and use the last DES block (64 bits) as the MAC value. A draft has been written and submitted. The motivation is that you can get DES chips, Authentication algorithms are slow and auth chips are hard to buy (a consideration outside the US) ISAKMP Review - Doug Maughan Doug Maughan presented the current ISAKMP (V8) draft. There was some discussion about field alignment and padding. IPSec Architecture Review - Steve Kent Steve Kent went over the current draft of the Architecture doucment. There was discussion about 'selectors' (an old section in the document which has received little comment), IPv6 'Class', DOI vs. Architecture inconsistencies. There was discussion about whether ESP should be mandatory for IPv4. A modest amount of Multicast discussion was volunteered to be added to the document. Topology Discovery - Sara Bitan Sara Bitan presented a proposal for topology discovery using secure paths among routers. Virtual Private Networks - Naganand Doraswamy Naganand presented a proposal on VPN scenarios using IPsec, with a proposal to add a "TX" DNS record type. There was discussion on whether ICMP could be used, or other schemes. Secure DHCP - B. Patel B. Patel did a presentation on how to use DHCP in a secure manner with Ipsec, based on a two stage procedure using two DHCP servers, one untrusted and one trusted. IPsec Followon - Steve Bellovin Steve Bellovin presented his view of what has to happen next with IPsec, dividing things into "critical path", "Useful", and "Hard" items. The only thing left on the critical path is a MIB. There was discussion that there needs to be more somewhere about how applications can use IPsec. From owner-ipsec Fri Aug 22 23:44:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA20554 for ipsec-outgoing; Fri, 22 Aug 1997 23:40:42 -0400 (EDT) Message-Id: <199708230352.XAA16321@relay.hq.tis.com> Date: Fri, 22 Aug 97 23:45:39 EDT From: Karen Seo To: ipsec@tis.com Subject: order/nesting of IPsec headers (transport mode) Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, Recent email has raised the question of what order/nesting of IPsec headers should be supported in transport mode. In general, we've been assuming that ONLY the combinations of IPsec headers listed as 1-3 below should occur in transport mode. ("above" = higher in the protocol stack, "below" = lower in the protocol stack. So, for example, TCP is "above" IP): 1. AH only 2. ESP only 3. ESP above AH (i.e., in the outbound direction, do ESP processing, then do AH processing) What is the sense of this community with regard to other combinations, e.g.,: 4. AH above ESP (i.e., authenticate first, then encrypt) 5. AH above AH 6. ESP above ESP 7. AH above AH above ESP 8. AH above ESP above AH 9. etc. Should support for any of these be mandated? allowed? forbidden? Thank you, Karen From owner-ipsec Sat Aug 23 11:59:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA23671 for ipsec-outgoing; Sat, 23 Aug 1997 11:56:12 -0400 (EDT) Message-Id: <199708231601.MAA00407@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: order/nesting of IPsec headers (transport mode) In-reply-to: Your message of "Fri, 22 Aug 1997 23:45:39 EDT." <199708230352.XAA16321@relay.hq.tis.com> Date: Sat, 23 Aug 1997 12:00:58 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Karen" == Karen Seo writes: Karen> Folks, Karen> Recent email has raised the question of what order/nesting Karen> of IPsec headers should be supported in transport mode. In Karen> general, we've been assuming that ONLY the combinations of I think this has been covered ad nauseum on the list already, but not recently. I grep'ed for "ip-ah-ip" and found this: http://www.sandelman.ottawa.on.ca/ipsec/1996/12/msg00075.html I looked in my archives again, and didn't the original discussion that I remember. I did find a message from saying that I had previously looked through the archives for such a reference... I'd still like to have the archives of the list from prior to February 1996.... I think it might make a nice book. Does someone have the archives? Bill? Ran? Karen> 4. AH above ESP (i.e., authenticate first, then Karen> encrypt) 5. AH above AH 6. ESP above ESP 7. AH above AH Karen> above ESP 8. AH above ESP above AH 9. etc. An AH must always be preceeded by an IP, so #4, #5, #7 and #8 are not quite correct, but one understands the intention. ESP above ESP (with no invening IP) is allowed, and may be a way to get stronger encryption with only DES. Or it may just mean that people that can export DES but not more get in trouble. Otherwise, these are just layers of tunnel mode. This is most likely to happen when the layers are added by different gateways. My impression is that we've had lots of discussion about this in the VPN drafts. :!mcr!: | Network security programming, currently Michael Richardson | on contract with DataFellows F-Secure IPSec 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 iQB1AwUBM/8JM6ZpLyXYhL+BAQElvwL+PaoNHgYtAKUc46nwCqoA+6g9k6kL0Hj6 cj8ZgyjezwpCW3ehOgPlhZxeBJhwQvJteBMYlBPO1RV8SfODNLzv0XSFnebgLtxe 3FDFk1cdOfe3vIEJrvI33NM1I5VFq0Pc =5vJS -----END PGP SIGNATURE----- From owner-ipsec Sat Aug 23 12:13:43 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA23752 for ipsec-outgoing; Sat, 23 Aug 1997 12:12:12 -0400 (EDT) Message-Id: <199708231618.MAA00530@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: order/nesting of IPsec headers (transport mode) In-reply-to: Your message of "Sat, 23 Aug 1997 12:00:58 EDT." <199708231601.MAA00407@istari.sandelman.ottawa.on.ca> Date: Sat, 23 Aug 1997 12:18:37 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Michael" == Michael C Richardson writes: Michael> discussion that I remember. I did find a message from ^me^ Michael> I'd still like to have the archives of the list from Michael> prior to February 1996.... I think it might make a nice Michael> book. Before anyone gets upset about this, I omitted the :-) here. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBM/8NW6ZpLyXYhL+BAQFMRwL/a6CYdPy3gFCyISlTcyIgULE7q3iWPlvx QkKXFT5LXVI7FuBP5gVf7ZH67NjsG4h5M2YkTCgRlWS81BSkbjP1UgmaauRmt3/9 ZApVwVl1fCDJpF4pLC7ooLd+P+TXkVHI =kJ+b -----END PGP SIGNATURE----- From owner-ipsec Sat Aug 23 22:30:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA26253 for ipsec-outgoing; Sat, 23 Aug 1997 22:22:43 -0400 (EDT) Date: Sat, 23 Aug 1997 22:31:29 -0400 Message-Id: <199708240231.WAA20780@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: A few observations about the replay issue Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk As I promised, I've spent some time doing some research on past wg discussion on the replay issue. As some of you may recall, this is not the first time that we've had extensive discussion about this issue. We also discussed this issue extensively in Febuary through May of this year. As might be expected, we went round and around many of the same issues that have been brought up recently. One of the last messages back in May on this subject was written by Dan Harkins in response to a proposal made by Steve Kent. This message was dated Wed, 14 May 1997 17:10:50 -0700: >To: Stephen Kent >Cc: ipsec@tis.com >Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt >In-Reply-To: Your message of "Tue, 13 May 1997 21:05:44 EDT." > >Date: Wed, 14 May 1997 17:10:50 -0700 >From: Daniel Harkins > > Steve, > >> Nonetheless, I propose the following compromise. Have the sender always >> transmit the AR counter, thus preserving the 8-byte AH alignment when using >> the default auth data size of 12 bytes. Allow the receiver to determine, >> unilaterally, whether to check the AR counter, and to do so against a >> window size chosen byb the receiver. Make 32 the default window size, and >> allow for large window sizes, in multiples of 32. However, have the >> receiver notify the sender of the selected window size (if any) as part of >> the SA negotiation. This simplifies the negotiation since only the >> receiver needs tell the sender of the former's selected window size, but >> now the sender has specific info about the security service parameters >> empoyed on the SA. >> >> This differs from the implementors' agreement only in the last detail. >> Hopefully it does not introduce significant complexity (the receiver need >> only declare a constant response if it's election of AR is constant) in the >> code. > > If I understand this correctly, the initiator of the KMP can choose to >add this attribute to his security suite offering to inform the responder of >his AR window size. He can also choose not to send it and the default is >assumed by the responder. Likewise, the responder can choose to send this >attribute back describing his AR window size regardless of whether the >initiator sent one (and the attribute value the initiator sends has no >bearing on the value the responder sends). In other words, this is not a >negotiable attribute; it is an informational attribute. If that understanding >isn't correct ignore the rest of this email but please straighten me out, > > While complexity isn't introduced, something else is. We'd always understood >that the responder in the KMP would either accept or reject a proposed suite >of services in its entirety and not change anything in the offer or add >anything that wasn't in the offer. This changes that. > Granted, it's a simple change and a check for "didn't add anything or change >anything-- except for replay window size" is pretty easy, but I want the WG >to realize this change is being proposed before a show of hands. IPsec SA >negotiation takes place under the protection of the ISAKMP SA so I don't think >this is opening up a security hole. > > In the way I understand this compromise, I'm fine with it. > > regards, > > Dan. There were two other responses to Steve's proposal; one by Bill Sommerfeld, and one from Steve Bellovin, which I include below: >In-Reply-To: kent's message of Tue, 13 May 1997 21:05:44 -0400. > >Date: Wed, 14 May 1997 16:17:07 -0400 >From: Bill Sommerfeld > >> Nonetheless, I propose the following compromise..... [text elided] > >Seems like a reasonable compromise. It should not require significant >code for the sender to ignore the additional attribute; the receiver >need only send it if it supports variable replay window sizes (and >thus already has significant additional complexity); and, if the >receiver erroneously omits the attribute but does support >larger-than-default windows, you can still interoperate. > >The attribute should be defined as "replay window *at least* this >large" > > - Bill >Date: Wed, 14 May 1997 01:55:55 +0000 >To: Stephen Kent >From: "Steven M. Bellovin" >Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt > >At 09:05 PM 5/13/97 -0400, Stephen Kent wrote: >> >>Nonetheless, I propose the following compromise..... [text elided] > >While I'm still not convinced that the receiver need say anything -- >there are many more parameters one could send for fault isolation, such >as TCP timer parameters and various queue length limits -- this is >probably a reasonable compromise. I do feel fairly strongly that the AR >field should always be present.... [text elided] There were no other responses on the mailing list. I can see how some might have concluded that we had reached consensus, although given the relatively few people (in relationship to the number who had been participating on this thread for the past few months), it certainly was a relatively weak show of consensus via silence on the part of most of the participants. More recently, there has been a lot of people taking issue with precisely the point raised by Dan back in May --- namely, that changing the ISAKMP packets to allow the receiver to inject an attribute that wasn't part of the original proposed attribute set was unclean and complex in its own way. As before, Steve Kent appears to be the main person argueing for this feature, and the basis of his arguments is that it would make debugging easier. Personally, I find myself siding with Steve Bellovin in that it's not clear that this one parameter by itself would be all that useful. Especially when you consider that implementations may decide not to log the information about the replay window size, at which point it really doesn't by the user anything anyway. It's also not clear to me that most ISP help desk personnel would have even the fastest clue how to use this information. I have another potential compromise which I think might answer everyone's expressed concerns to date. What if we were to remove any mention of the replay window size from the ISAKMP negotiations, but rather made this something which could be queried via SNMP? Would that make everyone happen? We don't have to make any changes to the attribute negotiation semantics, and for those who really think that it would be helpful in debugging failed ipsec connections, programs will be able to query the other host using SNMP. What do people think? - Ted From owner-ipsec Sun Aug 24 15:38:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA00263 for ipsec-outgoing; Sun, 24 Aug 1997 15:31:10 -0400 (EDT) Message-Id: <199708241934.PAA12760@coredump.cis.upenn.edu> To: Karen Seo cc: ipsec@tis.com Subject: Re: order/nesting of IPsec headers (transport mode) In-reply-to: Your message of "Fri, 22 Aug 1997 23:45:39 EDT." <199708230352.XAA16321@relay.hq.tis.com> Date: Sun, 24 Aug 1997 15:34:59 EDT From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- IMO, anything should be allowed. I see no reason to restrict combinations of ESP and AH. Cheers, - -Angelos -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNACM470pBjh2h1kFAQEreQP+JbWieflRo2J2nAm9tAfLPN9+GeTH8BLV QLhrk+EX77iar1zvDFUjp9vMzp5JHrEmiKmXDMj40l8d0xrBhZTOWUu7f3yOBfKR cJvnloFMo5TONCnMu1mFVFd1yZ9D+bmwSEnWpDK7VB0OdzUU2Yw0kp8evVIxFdWN sWrITlXKqXs= =AqKM -----END PGP SIGNATURE----- From owner-ipsec Mon Aug 25 06:32:09 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA04743 for ipsec-outgoing; Mon, 25 Aug 1997 06:24:07 -0400 (EDT) Message-Id: <3.0.1.32.19970825061952.00819990@pop3.pn.com> X-PGP-Key: X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 25 Aug 1997 06:19:52 -0400 To: ipsec@tis.com From: Rodney Thayer Subject: order/nesting of IPsec headers (transport mode) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk 1. Due to the use of tunneling technologies such as GRE I can imagine a legitimate case like this: AH...AH...ESP This would be caused by GRE packets travelling from one PPTP device to another inside a network that requires AH on all nodes. It's transport mode because it uses GRE. The whole packet would be IPv4...AH...AH...AH...ESP...GRE... 2. I thought the IPv6 folks had text in their specs that said any valid 'next protocol' value was allowed. 3. I recall 1825 said any combination was valid. Was there a list discussion on why this should have changed? Clearly a fixed set of any size is simpler than an unlimited set, but what were the reasons for changing the document? >Date: Fri, 22 Aug 97 23:45:39 EDT >From: Karen Seo >To: ipsec@tis.com >Subject: order/nesting of IPsec headers (transport mode) >Sender: owner-ipsec@ex.tis.com > >Folks, > >Recent email has raised the question of what order/nesting of IPsec >headers should be supported in transport mode. In general, we've been >assuming that ONLY the combinations of IPsec headers listed as 1-3 below >should occur in transport mode. ("above" = higher in the protocol >stack, "below" = lower in the protocol stack. So, for example, TCP is >"above" IP): > > 1. AH only > 2. ESP only > 3. ESP above AH (i.e., in the outbound direction, do ESP processing, > then do AH processing) > >What is the sense of this community with regard to other combinations, >e.g.,: > > 4. AH above ESP (i.e., authenticate first, then encrypt) > 5. AH above AH > 6. ESP above ESP > 7. AH above AH above ESP > 8. AH above ESP above AH > 9. etc. > >Should support for any of these be mandated? allowed? forbidden? > >Thank you, >Karen > > > > From owner-ipsec Mon Aug 25 09:04:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA05697 for ipsec-outgoing; Mon, 25 Aug 1997 09:02:35 -0400 (EDT) From: owner-ipsec@ex.tis.com Message-Id: <199708251302.JAA05697@portal.ex.tis.com> Subject: Re: order/nesting of IPsec headers (transport mode) To: kseo@bbn.com (Karen Seo) Date: Fri, 22 Aug 97 22:03:45 PDT Cc: ipsec@tis.com In-Reply-To: <199708230352.XAA16321@relay.hq.tis.com>; from "Karen Seo" at Aug 22, 97 11:45 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk Karen, I think any one of the other combinations should be mandated ONLY if there's a genuine application need for it out there in the market. My preference is to let the vendors have the flexibility to choose what combinations to offer their customers. Forbidding a combination would be a shame if a customer were to ask for a specific combination and the vendor were willing to provide it. I'm assuming interoperability wouldn't be an issue. - Ly > > Folks, > > Recent email has raised the question of what order/nesting of IPsec > headers should be supported in transport mode. In general, we've been > assuming that ONLY the combinations of IPsec headers listed as 1-3 below > should occur in transport mode. ("above" = higher in the protocol > stack, "below" = lower in the protocol stack. So, for example, TCP is > "above" IP): > > 1. AH only > 2. ESP only > 3. ESP above AH (i.e., in the outbound direction, do ESP processing, > then do AH processing) > > What is the sense of this community with regard to other combinations, > e.g.,: > > 4. AH above ESP (i.e., authenticate first, then encrypt) > 5. AH above AH > 6. ESP above ESP > 7. AH above AH above ESP > 8. AH above ESP above AH > 9. etc. > > Should support for any of these be mandated? allowed? forbidden? > > Thank you, > Karen > > From owner-ipsec Mon Aug 25 09:46:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA06133 for ipsec-outgoing; Mon, 25 Aug 1997 09:45:16 -0400 (EDT) Posted-Date: Mon, 25 Aug 1997 09:27:54 -0400 (EDT) Message-Id: <3.0.32.19970825093010.009ee334@bl-mail1.corpeast.baynetworks.com> X-Sender: ndoraswa_pop@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 25 Aug 1997 09:30:15 -0400 To: Stephen Kent , Derrell Piper From: Naganand Doraswamy Subject: Re: anti-replay notification Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, > > Yes, the AH and ESP specs call for AR window size notification by >the receiver to the sender. I was addressing the more narrow question of >AR notification, in the text you explicitly cited, because the discussion >had drifted into the more general issue of "why notify at all, let's just >always do AR, and authentication, ..." > We always say that doing ESP in the absence of some intergriy protection is not safe. I am not sure I understand what the issue is with requiring that we always do AR. We can say that for manual keys/SA, there is no replay protection and for dynamic SA's replay is always performed but is not advertised. I also beleive that it not necessary for receiver to advertise its replay window size. Thanks, --Naganand ----------------------------------------------------------------- Naganand Doraswamy (508)916-1323 (O) Bay Architecture Lab (508)670-8153 (Fax) 3 Federal St, Mail Stop BL3-04 Billerica, MA 01821 From owner-ipsec Mon Aug 25 09:59:40 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA06299 for ipsec-outgoing; Mon, 25 Aug 1997 09:58:14 -0400 (EDT) Message-Id: <199708251358.JAA06299@portal.ex.tis.com> Date: Sun, 24 Aug 1997 16:47:34 -0400 From: Dwight Arthur X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: Mike Smith CC: ipsec@tis.com, ietf-pkix@tandem.com Subject: Re: manual keying and IPSEC conformance X-Priority: 3 (Normal) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Mike Smith wrote: > > "Trust chains Always begin at the verifier". In a situation where a > corporation has established (or outsourced) a CA function, the > "verifiers" would be in the trust hierarchy of the corporation, not at > the individual. I believe that the corporate CA would be the entity > specifying or allowing THEIR trust to be extended to extrnal entities > (such as authorized vendors' CAs, etc.) > > Michael > > >>> David P. Kemp 08/21/97 08:31AM >>> > > From: Ran Atkinson > > > > In the X.509 arena there are MANY folks in the CA business competing > with > > each other, but cross-certification is not yet an element of the > real world. > > What if I want to talk with user FOO, but I use CA==X, FOO uses > CA==Y > > where (Y!=X) and (X,Y don't cross certify each other) -- result, no > secure packets. > > This is a common misperception about X.509. The ISO/ITU X.509 > standard > has always explicitly supported arbitrary trust chaining paths (a.k.a. > "web-of-trust") but, perhaps due to the PEM experience, most IETF'ers > seem to regard X.509 as requiring strict single-rooted or > cross-certified multiply-rooted hierarchies. > > Kudos to the SPKI folks for making explicit the notion that trust > chains > always begin at the verifier. The PKIX folks perhaps should add some > verbiage that makes it clearer that the verifier can choose to trust > whomever it wants. That verbiage shouldn't be necessary, but there is > apparently a huge PEM legacy-of-perception that needs to be erased. > > In the IPsec case, if Ran "uses" (has a certificate issued by) CA==X, > and FOO has a certificate from CA==Y, there is not necessarily a > problem. > As long as Ran's machine has a Ran-issued cert for CA==Y > stating that Ran trusts Y to certify IPsec nodes (perhaps with > name space or policy constraints), then there is no need for X and Y > to be cross certified. > > More generally, each administrative domain would have a single > root public key, each node within the domain would trust *only* that > root key, and the domain root would certify *all* CAs which are to be > trusted by nodes within the domain. The same mechanism is used to > address the privilege side of the compartmented information problem > that was recently brought up. (The other side of the problem is > data labelling.) > > The American Bar Association is discussing nine models of PKI, including "open pki" where all trust chains lead to a CA doing business with the public, like Verisign or Thawte, "closed pki" where my CA issues certs that are usable only in my systems (eg Bank X certs usable only to access Bank X accounts via Bank X websites) and "membership pki" which I think is close to what Mike is discussing. From owner-ipsec Mon Aug 25 13:59:06 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA07593 for ipsec-outgoing; Mon, 25 Aug 1997 13:55:21 -0400 (EDT) Message-Id: <3.0.32.19970825110347.009b1100@192.43.161.2> X-Sender: jburke@192.43.161.2 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 25 Aug 1997 11:03:48 -0700 To: ipsec@tis.com From: John Burke Subject: Re: anti-replay notification Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Thanks to Ted Ts'o for the summary of history on what list participants did and did not say about anti-replay and notification of same in a KMP. >From this it appears that, back in May, Steve Kent alone was actively pushing for the notification of window size to be present in KMP, and there were a few responses "well, if that's what gets decided it will be all right with me". And everyone seems to agree the one cogent argument in favor is, it might aid debugging. I notice for one thing that a Replay-Window-Size attribute did not get included in the next ISAKMP draft nor the companion IPSEC DOI (both in July). So at this point the issue includes: that the proposal is to introduce another attribute into the ISAKMP or DOI drafts, likely raising controversy if anything at all is said about what values are allowed or recommended and thus stretching this already too-long process out longer, further trying the patience of the waiting user community (what does Bob Moskowitz's AIAG think about all this?). Considering the only argument is "help in debugging", and other people call this a vague notion and still others suggest it is ill-founded, the arguments why we should make changes to ISAKMP and the DOI doc at this late date seem thoroughly underwhelming. - John Burke From owner-ipsec Mon Aug 25 14:19:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA07761 for ipsec-outgoing; Mon, 25 Aug 1997 14:17:51 -0400 (EDT) Message-Id: <3.0.32.19970825112607.0095f100@192.43.161.2> X-Sender: jburke@192.43.161.2 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 25 Aug 1997 11:26:08 -0700 To: ipsec@tis.com From: John Burke Subject: Re: anti-replay notification Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Am I right in believing people are missing something in the discussion about notification of the replay window, at least in ISAKMP? ISAKMP currently sets up only a single agreed SA, which is then used bidirectionally by both partners. So both parties are receivers; so if we require the receiver notify the sender of its Anti-Replay window size, then both parties have to do it. The proposal does still imply, that the values of the window sent in each direction have to be allowed to be different. - John Burke From owner-ipsec Mon Aug 25 15:37:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA08099 for ipsec-outgoing; Mon, 25 Aug 1997 15:33:21 -0400 (EDT) Message-Id: <199708251940.PAA01614@relay.rv.tis.com> Date: Mon, 25 Aug 97 15:38:30 EDT From: Charles Lynn To: Karen Seo cc: ipsec@tis.com Subject: Re: order/nesting of IPsec headers (transport mode) Sender: owner-ipsec@ex.tis.com Precedence: bulk I think that the question is really two questions humped together, and that the answer(s) depend on which question one is really answering. First, on the originating side, I agree that 1 thru 3 are reasonable, i.e., An implementation MUST be able to generate the following combinations of AH and ESP headers: AH only, ESP only, and ESP above AH (i.e., in the outbound direction, do ESP processing, then do AH processing). Those implementation which choose to support other combinations MAY do so. When doing so, an implementation MUST appear to have inserted the AH or ESP headers one at a time, from "top" to "bottom". Note that this restriction is only significant for AH processing, where it means that the AH ICV computation must not cover any "lower" AH or ESP headers (that will be (logically) inserted later). Note further that this means that the value in the "Next Header" field in the extension header before AH (ignoring any AH or ESP yet to be inserted) would be "AH" for the AH ICV computation, then changed when the next lower AH or ESP header is inserted (and the IP length field updated to include the new header). As others have said, I do not think that any combination should be prohibited at the receiver. This is consistent with the current IPv6 specification. Consequently, An implementation SHOULD be able to receive any combination of nested AH or ESP headers. Each header should be processed, from "bottom" to "top", as follows. The header should be processed according to the protocol, AH or ESP, and then (logically) removed from the packet, before proceeding to the next extension header. Note that when the header is removed, the "Next Header" field in the extension header preceeding the one being removed will be changed to the value in the "Next Header" field of the AH or ESP being removed. For example if ESP proceeds AH at the receiver, ESP would be processed on the packet: +--------------------+--------------------+--------------------+---+--------+ |IP, Next Header: ESP|ESP, Next Header: AH|AH, Next Header: TCP|TCP|ESP trlr| +--------------------+--------------------+--------------------+---+--------+ When ESP processing is complete, the ESP header would be removed and AH processed on the remaining portion of the packet. +--------------------+ +--------------------+---+ |IP, Next Header: AH*| |AH, Next Header: TCP|TCP| +--------------------+ +--------------------+---+ Note the change in the Next Header field of the IP header from ESP to AH*. The reason for the procedures given above is to make things work when a sender is using a hybrid stack, and the separate implementations, e.g., bump in the wire and an imbedded or user space implementation, and the two are not aware of the presence of the other. In case it is not obvious, "removed" does NOT mean treaded as being zeros. (While some might think that this is "too complicated", I do not think it is from an implementation perspective. It probably means that my text needs some wordsmithing. :-) While the question was specifically directed at transport mode, I think that the same answers should apply to tunnel mode, as the choice of where policy gets implemented should be left to the customers. Charlie From owner-ipsec Mon Aug 25 20:00:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA09503 for ipsec-outgoing; Mon, 25 Aug 1997 19:57:53 -0400 (EDT) Date: Mon, 25 Aug 1997 20:06:55 -0400 Message-Id: <199708260006.UAA21135@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Bill Sommerfeld Cc: hsw@columbia.sparta.com, smb@research.att.com, dave@tlogic.com, ipsec@tis.com In-Reply-To: Bill Sommerfeld's message of Fri, 22 Aug 1997 17:13:25 -0400, <199708222113.RAA00438@thunk.ch.apollo.hp.com> Subject: Re: IPSEC and NAT Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Fri, 22 Aug 1997 17:13:25 -0400 From: Bill Sommerfeld It's not immediately clear what this means, because NAT is a way to bridge between multiple routing/addressing domains. By tunnelling through, you're (pardon the Ghostbusters analogy) "crossing the streams". are the addresses on the "inside" of the tunnel from one domain, or the other? or do they form a third addressing domain? All very good questions. All I can say is that Bob's solution requires making fundamental changes in how TCP/IP applications work. Programs have to make a DNS query to a new type, the "TX" RR, which points them at another DNS server port on the security router, where they make another TX RR qiery. The router then makes its own DNS "TX" resolutions to talk to the other router --- which is also running a specialized DNS server --- so the two of them can figure out who needs to do what kind of NAT translation before encapsulating and encrypting the packets. (Apologizes to Bob if I'm not describing the latest version of his proposal. I am merely trying to get across a general sense of the kinds of kludges you need in order to support NAT.) It seems like an awful lot of work to do to accomodate a technology which completely breaks just about every single system/protocol I've worked on in the past 10 years. Unfortunately, there's a huge number of companies that very foolishly invested a large amount of money in NAT boxes, for better or for worse, and the auto industry in particular is apparently committed to spend millions to perpetuate this architectural eyesore, because apparently would be far more expensive to undo this mistake. In any case, NAT is far outside the scope of this working group --- although wishing that the problem will go away won't make it so, especially if there's enough money in the market places forcing vendors to invent solutions that accomodates this fundamentally broken technology. - Ted From owner-ipsec Mon Aug 25 20:23:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA09670 for ipsec-outgoing; Mon, 25 Aug 1997 20:23:21 -0400 (EDT) From: Dan.McDonald@Eng.Sun.Com (Dan McDonald) Message-Id: <199708260032.RAA12717@kebe.eng.sun.com> Subject: Re: IPSEC and NAT To: tytso@MIT.EDU (Theodore Y. Ts'o) Date: Mon, 25 Aug 1997 17:32:18 -0700 (PDT) Cc: ipsec@tis.com In-Reply-To: <199708260006.UAA21135@dcl.MIT.EDU> from "Theodore Y. Ts'o" at Aug 25, 97 08:06: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 > Unfortunately, there's a huge number of companies that very foolishly > invested a large amount of money in NAT boxes, for better or for worse, > and the auto industry in particular is apparently committed to spend > millions to perpetuate this architectural eyesore, because apparently > would be far more expensive to undo this mistake. > > In any case, NAT is far outside the scope of this working group --- > although wishing that the problem will go away won't make it so, > especially if there's enough money in the market places forcing vendors > to invent solutions that accomodates this fundamentally broken > technology. I could make some choice comments here about NAT being what happens when we don't deploy the _right_ solution (IMHO the right solution is IPv6, or any IPng) quickly enough. I could also say that I hope we (and I cheerfully include myself in "we") don't make the same mistake w.r.t. being too slow to deploy the _right_ solution. Dan From owner-ipsec Mon Aug 25 20:46:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA09791 for ipsec-outgoing; Mon, 25 Aug 1997 20:45:51 -0400 (EDT) Message-Id: <199708260053.UAA14660@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: order/nesting of IPsec headers (transport mode) In-reply-to: Your message of "Mon, 25 Aug 1997 15:38:30 EDT." <199708251940.PAA01614@relay.rv.tis.com> Date: Mon, 25 Aug 1997 20:53:30 -0400 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Charles" == Charles Lynn writes: Charles> I think that the question is really two questions humped Charles> together, and that the answer(s) depend on which question Charles> one is really answering. Charles> First, on the originating side, I agree that 1 thru 3 are Charles> reasonable, i.e., I agree with your thought, and thank you for including a detailed explanation of processing. Charles> As others have said, I do not think that any combination Charles> should be prohibited at the receiver. This is consistent Charles> with the current IPv6 specification. Consequently, One should note that an implementation may refuse to *negotiate* this kind of a transform. Our kernel could be configured to support these kinds of transforms, but our key manager will not do so. David Wagner had some comments (privately to me I think) that ESP(des)-ESP(des) was in fact no stronger than a single round of DES due to the amount of known text. Charles> The reason for the procedures given above is to make Charles> things work when a sender is using a hybrid stack, and Charles> the separate implementations, e.g., bump in the wire and Charles> an imbedded or user space implementation, and the two are Charles> not aware of the presence of the other. There are some deep key mgmt issues which suggest to me that this won't work at this time. However, they are "merely" key management things, and can be solved in userland rather than requiring kernel changes. Charles> While the question was specifically directed at transport Charles> mode, I think that the same answers should apply to Charles> tunnel mode, as the choice of where policy gets Charles> implemented should be left to the customers. :!mcr!: | Network security programming, currently Michael Richardson | on contract with DataFellows F-Secure IPSec 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 iQB1AwUBNAIpBKZpLyXYhL+BAQHE+gL6Ar9A/fxpna51+eAW39F455s2oPq4AQBF zFL303gsjbFUAEc3bvlzFs4XjD/rUnvJZpIxzj301tzXIXYFUxMHXy4TP3jjCzwT rAo5DVwM8yDV4W6HZ7i76VKaBNjw8kGE =kqFl -----END PGP SIGNATURE----- From owner-ipsec Tue Aug 26 01:37:35 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA11136 for ipsec-outgoing; Tue, 26 Aug 1997 01:35:49 -0400 (EDT) Message-Id: <199708260547.BAA01760@relay.hq.tis.com> Date: Tue, 26 Aug 97 1:33:52 EDT From: Karen Seo To: ipsec@tis.com Subject: Re: order/nesting of IPsec headers (transport mode) Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, Thank you for the feedback so far. Some clarification.... As stated in my initial message, we were originally wondering about what kinds of nesting were relevant for *transport* mode. Because only hosts do transport mode, this meant that any application of IPsec headers is done by the end systems, not by successive security gateways, etc. So what we really wanted was your input on the relevance of support for complex nestings of IPsec headers as applied by a *single box*, not successive boxes. In line with this, if the IPsec headers are being applied by a single box, then there won't be an IP header with each IPsec header -- I really did mean the cases 4-8 as typed but didn't show the original IP header. NOTE: This question came up with the host/transport case but as pointed out by Charlie Lynn applies to nested tunnel headers too if they're applied by a *single box*. Thanks again, Karen From owner-ipsec Tue Aug 26 07:52:18 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA13266 for ipsec-outgoing; Tue, 26 Aug 1997 07:45:53 -0400 (EDT) From: hsw@columbia.sparta.com (Howard Weiss) Message-Id: <9708261154.AA07398@katahdin.columbia.sparta.com> Subject: Re: IPSEC and NAT To: Dan.McDonald@Eng.Sun.Com (Dan McDonald) Date: Tue, 26 Aug 1997 07:54:30 -0400 (EDT) Cc: tytso@MIT.EDU, ipsec@tis.com In-Reply-To: <199708260032.RAA12717@kebe.eng.sun.com> from "Dan McDonald" at Aug 25, 97 05:32:18 pm Organization: SPARTA Inc. (Secure Systems Engineering Division) Usmail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046 Phone: (410) 381-9400 x201 Fax: (410) 381-5559 X-Mailer: ELM [version 2.4PL24 PGP3 ALPHA] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > Unfortunately, there's a huge number of companies that very foolishly > > invested a large amount of money in NAT boxes, for better or for worse, > > and the auto industry in particular is apparently committed to spend > > millions to perpetuate this architectural eyesore, because apparently > > would be far more expensive to undo this mistake. I could not agree more that NAT is an architecture kludge. But we've been there before (anyone remember ARPAnet IMP port expanders?). And, coming from a personal experience of *almost* having to renumber an entire corporate structure when we switched Internet providers, using internal-only addresses that never have to be changed regardless of ISP, IPvX, CIDR, etc has its appeal to the end-use. > > In any case, NAT is far outside the scope of this working group --- > > although wishing that the problem will go away won't make it so, > > especially if there's enough money in the market places forcing vendors > > to invent solutions that accomodates this fundamentally broken > > technology. > > I could make some choice comments here about NAT being what happens when we > don't deploy the _right_ solution (IMHO the right solution is IPv6, or any > IPng) quickly enough. Absolutely! However (and not to bring up the renumbering issue(s) again), it is really a royal pain to renumber an entire organization and so the solution must also take into account that we have enough addresses to cover every pipe valve in the world and therefore would never have to renumber. > I could also say that I hope we (and I cheerfully include myself in "we") > don't make the same mistake w.r.t. being too slow to deploy the _right_ > solution. > > Dan > Hear, hear! Howie -- ___________________________________________________________________ | | |Howard Weiss phone (410) 381-9400 x201 | |SPARTA, Inc. (301) 621-8145 x201 (DC) | |9861 Broken Land Parkway, suite 300 fax: (410) 381-5559 | |Columbia, MD 21046 email: hsw@columbia.sparta.com | |___________________________________________________________________| From owner-ipsec Tue Aug 26 11:12:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA15053 for ipsec-outgoing; Tue, 26 Aug 1997 11:12:25 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199708240231.WAA20780@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Aug 1997 17:24:19 -0500 To: "Theodore Y. Ts'o" From: Stephen Kent Subject: Re: A few observations about the replay issue Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Ted, I'm willing to adopt with your suggested compromise. The docucuments will be revised to reflect that the receiver notifies the sender whether AR is enabled for each SA (using the technique Derrell mentioned earlier, so as to preserve the ISAKMP negotiation symmetry), but there will be no mechanism for the receiver to notify of the AR window size. The MIB for AH and ESP will include window size. The MIB author will need to discuss the read/write constraints for this entry. That leaves the question of what the documents should say about the receive window size. We no longer need to advertize it, so that removes one motivation for standardizing allowed window sizes. However, one can still argue that a minimum size should be specified, to avoid the problems that can arise if very small window sizes are adopted. (Recall the confusion over adopting a window size of 1 as a default .) Based on the current specs, a minimum of 32 would be mandated, with a recommended minimum of 64. Any probolems with that? Steve From owner-ipsec Tue Aug 26 11:12:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA15052 for ipsec-outgoing; Tue, 26 Aug 1997 11:12:24 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.32.19970825093010.009ee334@bl-mail1.corpeast.baynetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Aug 1997 16:12:51 -0500 To: Naganand Doraswamy From: Stephen Kent Subject: Re: anti-replay notification Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Naganand, >We always say that doing ESP in the absence of some intergriy protection is >not safe. I am not sure I understand what the issue is with requiring that >we always do AR. We can say that for manual keys/SA, there is no replay >protection and for dynamic SA's replay is always performed but is not >advertised. I also beleive that it not necessary for receiver to advertise >its replay window size. A previous message pointed out that use of AH and ESP (e.g., in transport mode) is an alternative means of having authentication for the payload, so mandating authentcation for ESP is unduly restrictive. Steve From owner-ipsec Tue Aug 26 11:12:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA15016 for ipsec-outgoing; Tue, 26 Aug 1997 11:11:52 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199708231601.MAA00407@istari.sandelman.ottawa.on.ca> References: Your message of "Fri, 22 Aug 1997 23:45:39 EDT." <199708230352.XAA16321@relay.hq.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Aug 1997 16:09:49 -0500 To: ipsec@tis.com From: Stephen Kent Subject: Re: order/nesting of IPsec headers (transport mode) Sender: owner-ipsec@ex.tis.com Precedence: bulk This message responds to messages from several folks in response to Karen's message: Mike- If you persue Karen's note again, you'll notice that all of the examples were cast on the context of transport mode, not tunnel mode, so some of your observations re nesting are not applicable. I also have been of the mind that AH must always immediately follow IP (modulo intervening IPv6 headers), but from several of the other responses, not everyone has the same model. Hence the need to raise this issue. Angelos- The main issue here is what MUST a compliant implementaion support, both in terms of inbound and outbound header configurations. If one were to require support for arbitrary combinations of headers, this will increase the complexity of implementations, and of the management interfaces needed to be able to express the varried combinations. An intermediate position it to mandate support for some minimal combinations (as Karem suggested), but allow use of more elaborate combinations. However, this creates opportunities for non-interoperability, e.g., allowing for special case combinations that may work only if the same vendor's implementations are employed at each endpoint. Rodeny- Note that AH and ESP are defined as extension headers in the IPv6 context. IPv6 states that no more than one instance of an extension header (other than destination options) shall be generated by a host. That would say that duplicate AH instances as you describe are inappropriate, at least in the IPv6 context. Admittedly, the IPv6 spec later goes on to argue that hosts should accept the duplicate extension headers that it earlier proscribed! I tend to view this as a failure of the standardes process ;-). You asked if there had been discussion on the list, since 1825 did not restrict combinations, and why did we need to change what 1825 said. The answer is that 1825 did not spell out many architectural details and that's why we're generating a new architecture document. Ran's last I-D in November did include text dealing with this issue, but no feedback was received on that draft. The IPv6 spec does call for an ordering of AH and ESP (which is currently backwards, but will be fixed), so that WG thinks such an ordering is appropriate to spell out. Implementors have consistently argued for minimizing complexity in IPSEC; restricting the ordering and nesting of headers, at least in terms of what MUST be supported, is clearly in the vein. Steve From owner-ipsec Tue Aug 26 11:26:36 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA15151 for ipsec-outgoing; Tue, 26 Aug 1997 11:26:22 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.32.19970825110347.009b1100@192.43.161.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Aug 1997 11:20:56 -0500 To: John Burke From: Stephen Kent Subject: Re: anti-replay notification Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk John, I am told by the author that an anti-replay window size negotiation appeared in the previous draft of the DOI, but was removed after the Memphois meeting, where the implementors in attendance decided it was not needed. Steve From owner-ipsec Tue Aug 26 11:44:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA15271 for ipsec-outgoing; Tue, 26 Aug 1997 11:43:51 -0400 (EDT) Message-ID: <3402FBD1.5A9C@fet.com> Date: Tue, 26 Aug 1997 08:52:49 -0700 From: "Scott G. Kelly" Organization: Furukawa Electric Technologies, Inc. X-Mailer: Mozilla 3.03 (Win95; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: Re: IPSEC and NAT and the BIG PICTURE References: <199708260032.RAA12717@kebe.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan McDonald wrote: > > I could make some choice comments here about NAT being what happens when we > don't deploy the _right_ solution (IMHO the right solution is IPv6, or any > IPng) quickly enough. > I could also say that I hope we (and I cheerfully include myself in "we") > don't make the same mistake w.r.t. being too slow to deploy the _right_ > solution. > Again, I am replying to one particular post, but I am not replying in particular to that post; this is for all the posts which imply that this spec should have been finished yesterday. I will counter Dan's comments by saying that NAT provides a working mechanism which resolves a number of problems resulting from short-sighted design/implementation decisions. Having risked angering those who made the decisions, I will add that I recognize that they simply did not foresee the Internet that we know today - I don't think anyone did. Again, at the risk of incurring the wrath of many, I choose an unpopular stance: if this specification is rushed, you will find innumerable 'eyesore kludges' in the not-too-distant future resulting from oversights in this design process. If we really wish to maximize design speed without sacrificing the quality of this specification, everyone needs to recognize and agree with the following observation: This is *not* primarily about any company's individual financial concern; this is about the world's communications infrastructure. The convenience of XYZ Corp. really should have no bearing on this process, and when design problems are noted, the inconvenience incurred by any entity in changing their implementation simply should not be a consideration. From owner-ipsec Tue Aug 26 12:41:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA15661 for ipsec-outgoing; Tue, 26 Aug 1997 12:40:24 -0400 (EDT) Message-Id: <199708261649.JAA17374@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Stephen Kent Cc: "Theodore Y. Ts'o" , ipsec@tis.com Subject: Re: A few observations about the replay issue In-Reply-To: Your message of "Mon, 25 Aug 1997 17:24:19 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Aug 1997 09:49:31 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, I'm having deja-vu all over again. Of the 8 or 10 or so people to voice an opinion on receiver notification of replay you are the only person to want it. Derrell's response to your technique to shoehorn notification into ISAKMP mentioned that it would work "at the expense, on the wire, of requiring that each SA proposal be more than twice as large (in bytes) as it would otherwise be without 'negotiated' AR". That's hardly an endorcement. I'm really baffled by your insistance on retaining this text. That there is no WG support for it (excluding yourself) and there is WG opposition to it (also excluding myself) makes it even more baffling. But since we're in the spirit of compromise let me suggest one to settle this. The current Arch draft mentions: "If an SA establishment protocol such as Oakley/ISAKMP [sic] is employed, then the receiver SHOULD notify the transmitter, during SA establishment...." I trust that SHOULD is remaining a SHOULD and not becoming a MUST. The real way for a receiver in ISAKMP to notify the transmitter of anything is via a notify message. So, what should be done is to not have replay be an attribute of the SA negotiation process (and thus unnecessarily burden that process) but to make a new notify message type of "REPLAY". If either side is doing replay then they SHOULD send this notify message which contains the SPI of the SA in question. How does that sound? Dan. > I'm willing to adopt with your suggested compromise. The > docucuments will be revised to reflect that the receiver notifies the > sender whether AR is enabled for each SA (using the technique Derrell > mentioned earlier, so as to preserve the ISAKMP negotiation symmetry), but > there will be no mechanism for the receiver to notify of the AR window > size. The MIB for AH and ESP will include window size. The MIB author > will need to discuss the read/write constraints for this entry. > > That leaves the question of what the documents should say about the > receive window size. We no longer need to advertize it, so that removes > one motivation for standardizing allowed window sizes. However, one can > still argue that a minimum size should be specified, to avoid the problems > that can arise if very small window sizes are adopted. (Recall the > confusion over adopting a window size of 1 as a default .) Based on the > current specs, a minimum of 32 would be mandated, with a recommended > minimum of 64. Any probolems with that? From owner-ipsec Tue Aug 26 14:14:23 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA16342 for ipsec-outgoing; Tue, 26 Aug 1997 14:10:55 -0400 (EDT) From: Tim Bass (IETF) Message-Id: <199708261817.OAA09690@linux.silkroad.com> Subject: Re: IPSEC and NAT and the BIG PICTURE To: ipsec@tis.com Date: Tue, 26 Aug 1997 14:17:01 -0400 (EDT) In-Reply-To: <3402FBD1.5A9C@fet.com> from "Scott G. Kelly" at Aug 26, 97 08:52:49 am X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Scott> I will counter Dan's comments by saying that NAT provides a working Scott> mechanism which resolves a number of problems resulting from Scott> short-sighted design/implementation decisions. Having risked angering Scott> those who made the decisions, I will add that I recognize that they Scott> simply did not foresee the Internet that we know today - I don't think Scott> anyone did. Scott, It's okay. There is a peer-reviewed paper in the recent Jul/Aug issue of IEEE Network Magazine about the subject you are discussing. (sorry to toot my horn, but i wrote the darn thing .......) IMHO, this WG is not the place to discuss scalability issues with IP routing, CIDR, or NAT. IPSEC, again IMHO, should work with 'the state of how things are' not, again IMHO, the state of how things could be and should have been with regard to route scalability issues. This issue was, and continues, to be a very difficult issue in the IETF. The facts are, Network Address Translation is here to stay for a long time, there is no 'save the world' super-scaleable exterior routing protocol on the reality radar screen that will be implemented in the near future. IPSEC would do a 'very good thing' if flags, hooks, and glue were considered for networks with NAT. I have not read the recent RFCs, but I have always assumed that IPSEC covered an encryption option that provided for NAT and other possible header modifications, protocol proxies, etc. Funny, someone mentioned NAT was a kludge! Hell, most of the Internet development is a kludge of some sort :) Having a kludgy internet is a feature, not a bug, and part of the success of TCP/IP. Best Regards, Tim From owner-ipsec Tue Aug 26 16:22:45 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA16986 for ipsec-outgoing; Tue, 26 Aug 1997 16:19:31 -0400 (EDT) Message-Id: <199708262028.QAA00332@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: Tim Bass (IETF) Cc: ipsec@tis.com Subject: Re: IPSEC and NAT and the BIG PICTURE In-Reply-To: ietf's message of Tue, 26 Aug 1997 14:17:01 -0400. <199708261817.OAA09690@linux.silkroad.com> Date: Tue, 26 Aug 1997 16:28:21 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk Here's a succinct way to describe the main problem with NAT vs. security protocols (ipsec, kerberos, dnssec, ...) It's possible to do end-to-end security in the presence of NAT. It's also possible to use addresses as data in the presence of NAT -- the NAT box just has to rewrite the addresses. However, it's not possible to use end-to-end secure protocols which carry addresses as data... it's this combination of features which cannot possibly work. - Bill From owner-ipsec Wed Aug 27 06:33:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA21315 for ipsec-outgoing; Wed, 27 Aug 1997 06:29:04 -0400 (EDT) Message-Id: <3.0.3.32.19970827063725.0331e780@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 27 Aug 1997 06:37:25 -0400 To: "Theodore Y. Ts'o" , Bill Sommerfeld From: Robert Moskowitz Subject: Re: IPSEC and NAT Cc: hsw@columbia.sparta.com, smb@research.att.com, dave@tlogic.com, ipsec@tis.com In-Reply-To: <199708260006.UAA21135@dcl.MIT.EDU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 08:06 PM 8/25/97 -0400, Theodore Y. Ts'o wrote: > >Unfortunately, there's a huge number of companies that very foolishly >invested a large amount of money in NAT boxes, for better or for worse, >and the auto industry in particular is apparently committed to spend >millions to perpetuate this architectural eyesore, because apparently >would be far more expensive to undo this mistake. Ted, I wish it were so simple. I am one of the co-authors of 1918. In fact I was the principle instigator for it at the Huston IETF. I have countless suppliers that just could not get enough address space. We blew it with IPv6; too little too late. Then there is the routing complexity. I need several paths out of my company, and the routing expertise to do that is too expensive. The issues are very complex. You live (basically) on one nice campus. I have dozens of sites to help support. If I had IPsec and Ipv6 when we started ramping up in '91 things would be a lot different. Got to hop into the car and get over to AutoTech. Things are going well enough; we have 'learned' a lot. And, yes, NAT is outside of this workgroup's scope, but it is important that the discussion start here, just like compression started here. IPsec changes the playing field and we have to go back and re-work many things. Who is ready to tackle IPsec and Class of service??????? Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Wed Aug 27 06:55:28 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA21430 for ipsec-outgoing; Wed, 27 Aug 1997 06:55:06 -0400 (EDT) Message-Id: <3.0.3.32.19970827070415.007d75f0@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 27 Aug 1997 07:04:15 -0400 To: rgm3@chrysler.com From: Paul Ferguson Subject: Re: IPSEC and NAT Cc: ipsec@tis.com In-Reply-To: <3.0.3.32.19970827063725.0331e780@pop3hub.is.chrysler.com> References: <199708260006.UAA21135@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 06:37 AM 8/27/97 -0400, Robert Moskowitz wrote: > >Who is ready to tackle IPsec and Class of service??????? > Shouldn't be a problem, since IPsec doesn't munge the IP Precedence bits. If you haven't been following the discussion over in intserv, and missed the intserv differentiated service meeting in Munich, this has been an ongoing discussion on how to provide differing levels of service -- something 'looser' than RSVP and state maintenance. There is strong consensus that a 'drop preference' can be implemented using something like the IP Precedence bits in conjunction with a weighted congestion avoidance mechanism in the network core, so that when congestion does occur in the network, you basically get differing levels of best effort -- someone's traffic will get dropped before someone else's. Outside of the scope of IPSec, I know, but you asked. :-) - paul From owner-ipsec Wed Aug 27 13:10:37 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA24073 for ipsec-outgoing; Wed, 27 Aug 1997 13:03:48 -0400 (EDT) Date: Wed, 27 Aug 1997 13:12:56 -0400 From: "Waterhouse, Richard" Subject: draft-ietf-ipsec-isakmp-08.txt 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 I have three ISAKMP questions where I can't find clear answers in the ISAKMP draft. 1. I see no requirement to set the 6 unused bits of the Flags field of the Message Header to a specific value. I therefore assume they can be set to either 0 or 1. 2. Situation is said to be variable length. That presumably means it can be defined to be of zero length, i.e., not be present, if therre is only one situation defined in the DOI. 3. The length of the SPI field during Phase 1 negotiation is unclear when the 0 value is used. Can it be 32 bits; or since cookies can also be included in the field, for consistency must it be 64. I am assuming the latter. My context is that of a DOI other than the [IPDOI]. However it is possible that an [IPDOI] implementation may someday receive the first message of my DOI's SA Establishment exchange. I am assuming that because I use a different DOI value in the SA Payload an [IPDOI] implementation will behave as in Section 5.4 receiving entity #1, though I should also note that in my Message Header the Exchange Type will have a value corresponding to DOI Specific Use. From owner-ipsec Wed Aug 27 13:25:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA24312 for ipsec-outgoing; Wed, 27 Aug 1997 13:23:48 -0400 (EDT) Message-Id: <199708271732.NAA00583@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: Derrell Piper Cc: ipsec@tis.com Subject: Re: manual keying and IPSEC conformance In-Reply-To: piper's message of Wed, 20 Aug 1997 15:09:31 -0700. <199708202209.PAA27812@pita.cisco.com> Date: Wed, 27 Aug 1997 13:32:53 -0400 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk Sorry for the late reply on this issue; I've been significantly behind on my mail. I'm afraid I disagree. While I do not think manual keying will be used in significant ways in large-scale production networks, I think that until we have a *lot* more experience with isakmp we need to keep it in as a backup mode of operation. While my customers may not think they want it or may be confused about whether or not it's a "security hole" (at worst, it's more rope the user can use to hang themselves.. and it's nowhere near as dangerous as many other things..), I know that I definitely want it in there so that if two isakmp's absolutely fail to talk I have a better fallback around than sending in the clear. - Bill From owner-ipsec Wed Aug 27 13:35:26 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA24362 for ipsec-outgoing; Wed, 27 Aug 1997 13:33:47 -0400 (EDT) Date: Wed, 27 Aug 1997 13:42:28 -0400 Message-Id: <199708271742.NAA13789@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: rgm3@chrysler.com Cc: ipsec@tis.com In-Reply-To: Robert Moskowitz's message of Wed, 27 Aug 1997 06:37:25 -0400, <3.0.3.32.19970827063725.0331e780@pop3hub.is.chrysler.com> Subject: Re: IPSEC and NAT Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Granted, the issues are very complex, and I very much understand that at the time, NAT's may have seemed to be a cheaper alternative than fighting the address space battles. And I recognize that NAT's did not arise out of a vacuum, either. I will observe, though, that while NAT's may have appeared to be the cheaper solution initially, the total bill for the NAT "solution" has yet to be totalled up. Interactions with IPSEC is just one such example of an additional cost of NAT's. (And let us be clear that it is a cost imposed by NAT's, not by IPSEC, as it is the NAT boxes which broke a fundamental property of the Internet architecture.) - Ted From owner-ipsec Wed Aug 27 13:43:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA24425 for ipsec-outgoing; Wed, 27 Aug 1997 13:41:17 -0400 (EDT) Message-Id: <3.0.3.32.19970827094843.00ac23b0@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 27 Aug 1997 09:48:43 -0400 To: ipsec@tis.com From: Robert Moskowitz Subject: Ottawa IPsec Interoperablity Meeting - Sept 22nd Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk First, for any vendor/person that has informed me of intending to participate in the 'meeting', please subscribe to the anx-sec list. I will be announcing aspects of the testing there, so as not to add meeting and testing administratia to this list. Subscribe by sending a message to: majordomo@dot.netrex.net in the body of the message have: subscribe anx-sec This is a closed list, and I have to approve the subscription. If your email address does not clearly identify you and your company, send me a separate message to avoid delays. Timestep has reserved rooms, but only until Sept 1st! So get your reservations in to: Quality Hotel: 290 Rideau St. Ottawa, Ontario K1N 5Y3 Phone: 1-800-228-5151 30 Rooms $81.00/night Lord Elgin Hotel 100 Elgin Street Ottawa, Ontario K1P 5K8 Phone: 1-800-267-4298 10 Rooms Single/Double Rate: $99.00/night Howard Johnson Hotel 140 Slater Street Ottawa, Ontario K1P 5H6 Phone: 1-800-446-4656 Rate: $72.00 Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Thu Aug 28 00:35:15 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA27869 for ipsec-outgoing; Thu, 28 Aug 1997 00:32:21 -0400 (EDT) Date: Thu, 28 Aug 1997 04:41:28 GMT Message-Id: <199708280441.EAA29737@intruder.crd.yokogawa.co.jp> From: Ne To: ipsec@tis.com Subject: Re: order/nesting of IPsec headers (transport mode) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Mailer: mnews [version 1.19PL2] 1996-01/26(Fri) Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi there. I have some question from the draft-ietf-ipsec-arch-sec-01.txt which e-mailed on 30 July. When we apply the IPSEC to the following packet, [IP1][upper] There are all pattern of SA in following, which are indicated by the draft-ietf-ipsec-arch-sec-01.txt e-mailed on 30 July, Only transport mode [IP1][AH][upper] [IP1][ESP][upper] Only tunnel mode [IP2][AH][IP1][upper] [IP2][ESP][IP1][upper] Combined transport mode of AH and ESP, "Transport adjacency" [IP1][AH][ESP][upper] Combined tunnel mode of ESP and AH, "Iterated tunneling" [IPn][AH or ESP][IPn-1][AH or ESP][...][IP2][AH or ESP][IP1][upper] Combined transport mode of AH or ESP, and "Iterated tunneling" [IPn][AH or ESP][IPn-1][AH or ESP][...][IP2][AH or ESP][IP1][AH or ESP][upper] Combined "Transport adjacency" and "Iterated tunneling" [IPn][AH or ESP][IPn-1][AH or ESP][...][IP2][AH or ESP][IP1][AH][ESP][XPORT] Is that all ? The next, Is there a pattern of bundle SA as following, ? [IP2][AH][ESP][IP1][upper] * [upper] is the upper layer protocol If certainly, is that constructed two tunnel mode of both AH and ESP that are terminated at same destination ? Regards. P.S. Thank you for your help and sorry for my bad english ========================================================== Shoichi Sakane TEL : +81-0423-33-6209 E-Mail: sakane@cct.dcl.co.jp FAX : +81-0423-52-6102 Information & Communication Technology Center Yokogawa Digital Computer Corporation, Tokyo, JAPAN From owner-ipsec Thu Aug 28 07:49:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA00275 for ipsec-outgoing; Thu, 28 Aug 1997 07:47:21 -0400 (EDT) Message-Id: <199708281156.UAA14843@aries.ascend.co.jp> To: ipsec@tis.com Subject: Is tunnel IP address included in SA? From: Motonori Shindo X-Mailer: Mew version 1.70 on Emacs 19.28.2 / Mule 2.3 X-PGP-fingerprint: 06 B0 B1 A4 06 C1 6A 14 63 C0 D7 18 01 CD D9 83 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 28 Aug 1997 20:56:34 +0900 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Please let me ask some very primitive questions. Let's suppose the following network: | | PC1 -+ +- PC2 | (Internet) | +-- R1 --- ......... --- R2 ----+ | | Assume that R1 and R2 can do IPsec while PC1 and PC2 can't. PC1 sends an IP datagram to PC2. In this case, (1) R1 has to have an SA associated with PC2, right? (2) Must AH and ESP be handled in tunnel mode? (3) How can one figure out the tunnel IP address for a paticular destination address? Is Tunnel IP address included in SA? Any advise will be appreciated. ===================================== Motonori Shindo Systems Engineer Ascend Communications Japan K.K. email: mshindo@ascend.co.jp TEL: +81-3-5325-7306 ===================================== From owner-ipsec Thu Aug 28 09:49:49 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA01113 for ipsec-outgoing; Thu, 28 Aug 1997 09:48:51 -0400 (EDT) To: IETF-Announce@ietf.org From: Internet-Drafts@ietf.org cc: mobile-ip@smallworks.com, ipsec@tis.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-montenegro-tsp-00.txt Date: Thu, 28 Aug 1997 09:18:35 -0400 Message-ID: <9708280918.aa06076@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Tunnel Set-up Protocol (TSP) Author(s) : G. Montenegro Filename : draft-montenegro-tsp-00.txt Pages : 19 Date : 26-Aug-97 Remote access over the internet and IP mobility are currently being addressed as two separate problems. The L2TP specification is defining a protocol, or rather a tunnel control mechanism to solve the remote access problem. On the other hand, the Mobile IP working group has been solving the mobility problem. Nevertheless, the same solution applies to both problems, namely, tunneling. This document defines a Tunnel Set-up Protocol (TSP) that solves both problems using a common approach. TSP is heavily based on the control messages defined by Mobile IP. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-montenegro-tsp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-montenegro-tsp-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-montenegro-tsp-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: <19970826112743.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-montenegro-tsp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-montenegro-tsp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970826112743.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu Aug 28 11:57:31 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA02137 for ipsec-outgoing; Thu, 28 Aug 1997 11:56:01 -0400 (EDT) Message-Id: <199708281604.JAA18658@dharkins-ss20> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Motonori Shindo Cc: ipsec@tis.com Subject: Re: Is tunnel IP address included in SA? In-Reply-To: Your message of "Thu, 28 Aug 1997 20:56:34 +0900." <199708281156.UAA14843@aries.ascend.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 28 Aug 1997 09:04:47 -0700 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Motonori, > Let's suppose the following network: > > | | > PC1 -+ +- PC2 > | (Internet) | > +-- R1 --- ......... --- R2 ----+ > | | > > Assume that R1 and R2 can do IPsec while PC1 and PC2 can't. PC1 sends > an IP datagram to PC2. > > In this case, > > (1) R1 has to have an SA associated with PC2, right? No, if PC2 doesn't do IPSec then the tunnel endpoint is R2. R1 and R2 share SAs. > (2) Must AH and ESP be handled in tunnel mode? Yes. > (3) How can one figure out the tunnel IP address for a paticular > destination address? Is Tunnel IP address included in SA? If you're using ISAKMP/Oakley to negotiate the SAs the identities are passed in the Quick Mode exchange. Note that the actual identity depends on the configuration of R1. R1 could use proxy IDs with subnet 1 (where PC1 resides) and subnet 2 (where PC2) resides; he could use the actual IP addresses of PC1 and PC2; or, he could use even more granularity-- he could use the actual IP address and also specifiy the protocol and port of the service that PC1 is attempting on PC2. As I said, it all depends on the config on R1 but it's possible to say that all telnet sessions from PC1 to PC2 get a unique SA, all ftp's from a host on subnet 1 to a host on subnet 2 share another, and everybody else shares a "catch-all" SA. Dan. From owner-ipsec Thu Aug 28 13:20:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA02757 for ipsec-outgoing; Thu, 28 Aug 1997 13:16:03 -0400 (EDT) Message-Id: <3.0.3.32.19970828105327.00aca630@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 28 Aug 1997 10:53:27 -0400 To: "Theodore Y. Ts'o" From: Robert Moskowitz Subject: Re: IPSEC and NAT Cc: ipsec@tis.com In-Reply-To: <199708271742.NAA13789@dcl.MIT.EDU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 01:42 PM 8/27/97 -0400, Theodore Y. Ts'o wrote: > >Interactions with IPSEC is just one such example of an additional cost >of NAT's. (And let us be clear that it is a cost imposed by NAT's, not >by IPSEC, as it is the NAT boxes which broke a fundamental property of >the Internet architecture.) Even given rully routable addresses, there are sever problems with routing. Let's say that You and I wish to communicate securely over the public portion of our connection, ie from your desk to my gateway. Since I have lots of IPsec gateways all over the company, all with different Internet access, there is an interesting challenge of how the packets will make it back to the appropriate gateway from my system. Now I could use source routing within my network. The gateway could add the appropriate source routing information so that my system would send the packet back. But then do I want to allow source routing within my network? Is this 'safe networking' or playing it a little too fast and loose (btw my network support colleagues will know that I have flipped if I ask for internal source routing). Alternatively I dould do dynamic route announcement at the /32 level, or can I? Let's say that not only are you communicating with me that would go through our Outer Drive gateway, but also to a manufacturing engineer over at the Jefferson Rd plant (senior Jeeps) through the gateway over at Dodge City. How do I get the packets back to the proper gateway? I would have to block the propagation of the route. No, this would be an administration nightmare; where do I block what? So dynamic route announcements are out. Source routing may be unwise. What is left? NAT is left. I change the source address of the packet as it leaves the tunnel, before it gets dropped on my network. Such a packet will have not no problem getting back to appropriate gateway. Each gateway would need a pool of addresses on the private size based on the number of concurrent remote systems that the gateway can support. But hey, I've got 32 B networks in 1918! Lots of addresses to burn. Of course, if I had IPsec on those internal systems and we knew how to chain IPsec tunnels, I also fix the routing problem. Well maybe; if both systems use the same 1918 network, there could be some interesting IP kernel challenges (and what if they have the same address!). This is why I am very interested in what I call 'advanced VPN'. Chained IPsec tunnels with potentially a nested IPsec transport. Attention Karen and Steve, I will be submitting my nesting order requirements shortly; been busy with AutoTech. This methodology obviates the routing challenge. So Ted, Tim, the rest of you. IPsec and even NAT is not my problem. My (and so many corporations) problem is a routing problem. IPsec aggrevates it by interducing foreign addresses to our routing domain. BGP4 is a bit much to take on, and perhaps it is not so much the answer. Is IDPR or NIMROD the answer. Oh, btw, Chrysler does have a BGP3 backbone, one of the few companies to take this path for managing routes in our internal internet. PS. I will have to add to my IPsec-vpn-nat ID a source route option to Network types C and D as the destination networks.... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Thu Aug 28 13:20:19 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA02785 for ipsec-outgoing; Thu, 28 Aug 1997 13:16:33 -0400 (EDT) Message-Id: <3.0.3.32.19970828110131.00aca630@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 28 Aug 1997 11:01:31 -0400 To: Paul Ferguson , Charles Lynn From: Robert Moskowitz Subject: Re: IPSEC and NAT Cc: ipsec@tis.com In-Reply-To: <3.0.3.32.19970827070415.007d75f0@lint.cisco.com> References: <3.0.3.32.19970827063725.0331e780@pop3hub.is.chrysler.com> <199708260006.UAA21135@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 07:04 AM 8/27/97 -0400, Paul Ferguson wrote: Actually, I was one of the proposers of using the precedence bits at Memphis; and I am sure that it came up before. However, you can't do enough with 3 bits, IMHO. This might be the greatest driver to IPv6, or at least IPv4 in secure IPv6 tunnels! IPv6 with things like Flow ID should have enough exposed fields to to class of service. BTW, how is this for a totally backward view of IPngtran? >At 06:37 AM 8/27/97 -0400, Robert Moskowitz wrote: > >> >>Who is ready to tackle IPsec and Class of service??????? >> > >Shouldn't be a problem, since IPsec doesn't munge the IP Precedence >bits. If you haven't been following the discussion over in intserv, >and missed the intserv differentiated service meeting in Munich, this >has been an ongoing discussion on how to provide differing levels of >service -- something 'looser' than RSVP and state maintenance. There >is strong consensus that a 'drop preference' can be implemented using >something like the IP Precedence bits in conjunction with a weighted >congestion avoidance mechanism in the network core, so that when >congestion does occur in the network, you basically get differing >levels of best effort -- someone's traffic will get dropped before >someone else's. > >Outside of the scope of IPSec, I know, but you asked. :-) > >- paul > > > Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Thu Aug 28 14:10:58 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA03121 for ipsec-outgoing; Thu, 28 Aug 1997 14:09:08 -0400 (EDT) Message-Id: <3.0.3.32.19970828141804.0085dc70@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 28 Aug 1997 14:18:04 -0400 To: rgm3@chrysler.com From: Paul Ferguson Subject: Re: IPSEC and NAT Cc: ipsec@tis.com In-Reply-To: <3.0.3.32.19970828110131.00aca630@dilbert.is.chrysler.com> References: <3.0.3.32.19970827070415.007d75f0@lint.cisco.com> <3.0.3.32.19970827063725.0331e780@pop3hub.is.chrysler.com> <199708260006.UAA21135@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 11:01 AM 8/28/97 -0400, Robert Moskowitz wrote: >At 07:04 AM 8/27/97 -0400, Paul Ferguson wrote: > >Actually, I was one of the proposers of using the precedence bits at >Memphis; and I am sure that it came up before. However, you can't do >enough with 3 bits, IMHO. This might be the greatest driver to IPv6, or at >least IPv4 in secure IPv6 tunnels! IPv6 with things like Flow ID should >have enough exposed fields to to class of service. > >BTW, how is this for a totally backward view of IPngtran? > Bob, Empirical evidence indicates that service providers do not want, nor need, more than eight levels of differentiation. In fact, most of them simply want two, at least initially (traditional best-effort and 'premium'). - paul From owner-ipsec Thu Aug 28 20:16:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA05083 for ipsec-outgoing; Thu, 28 Aug 1997 20:14:38 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199708261649.JAA17374@dharkins-ss20> References: Your message of "Mon, 25 Aug 1997 17:24:19 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 28 Aug 1997 19:39:06 -0500 To: Daniel Harkins From: Stephen Kent Subject: Re: A few observations about the replay issue Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, > I'm having deja-vu all over again. I presume the first instance of deja vu you refer to is mid-May message Ted posted recently, in which you agreed to the text that currently appears in the AH and ESP drafts :-). > Of the 8 or 10 or so people to voice an opinion on receiver notification >of replay you are the only person to want it. Derrell's response to your >technique to shoehorn notification into ISAKMP mentioned that it would >work "at the expense, on the wire, of requiring that each SA proposal be >more than twice as large (in bytes) as it would otherwise be without >'negotiated' AR". That's hardly an endorcement. A series of messages have been exchanged on the general topic of receiver notification, incluidng both basic notification and window size notification. Most of the messages argued against the latter aspect of the current drafts, fewer against the former. WG members other than I noted the implications of not providing any notification, which could lead to mandating authentication for all ESP SAs, even ones where AH was also being used. This strongly argues in favor of retaining receiver notification. I don't question your claim that the addition of this data would double the proposal size, but I think that's a misleading characterization. Given the amount of data being passed in ISAKMP messages, e.g., certificates, this notification data is pretty small. > > I'm really baffled by your insistance on retaining this text. That there >is no WG support for it (excluding yourself) and there is WG opposition to >it (also excluding myself) makes it even more baffling. I don't agree with your characterization of WG support re this aspect of the specs. As I noted above, most people expressed support for removal of the size notification, and provided rationales for this position. However, later discussion of the problems that would result if no notification were provided did not result, in my opinion, in a clear WG consensus to make that change. > But since we're in the spirit of compromise let me suggest one to settle >this. The current Arch draft mentions: > > "If an SA establishment protocol such as Oakley/ISAKMP [sic] is > employed, then the receiver SHOULD notify the transmitter, during SA > establishment...." > >I trust that SHOULD is remaining a SHOULD and not becoming a MUST. The real >way for a receiver in ISAKMP to notify the transmitter of anything is via >a notify message. So, what should be done is to not have replay be an >attribute of the SA negotiation process (and thus unnecessarily burden >that process) but to make a new notify message type of "REPLAY". If either >side is doing replay then they SHOULD send this notify message which contains >the SPI of the SA in question. > > How does that sound? I appreciate the spirit of compromise expressed here and my only concern is the following, based on the issue that Cheryl raised in Munich. Consider the situation where the receiver fails to notify the sender that AR is enabled, (the requirement is a SHOULD, not a MUST) and thus the sender does not check for sequence counter overflow. If the sender transmits 2**32 packets, then the receiver will begin rejecting packets, but the sender will not know why. I expect that the sender will eventually give up and create a new SA, but it seems a pity to create this problem. When we wrote the current text, I believe that we made this a SHOULD, vs. a MUST, largely because of the requirement for window size notification. Since we're dropping that aspect of the notification, that motivation for the requirement level no longer exists. Why do you feel strongly about having this be a SHOULD, vs. a MUST? Steve From owner-ipsec Thu Aug 28 20:16:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA05090 for ipsec-outgoing; Thu, 28 Aug 1997 20:15:07 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199708281156.UAA14843@aries.ascend.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 28 Aug 1997 20:02:27 -0500 To: Motonori Shindo From: Stephen Kent Subject: Re: Is tunnel IP address included in SA? Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Motonori, >Please let me ask some very primitive questions. > >Let's suppose the following network: > > | | > PC1 -+ +- PC2 > | (Internet) | > +-- R1 --- ......... --- R2 ----+ > | | > >Assume that R1 and R2 can do IPsec while PC1 and PC2 can't. PC1 sends >an IP datagram to PC2. > >In this case, > > (1) R1 has to have an SA associated with PC2, right? Ther has to be an SA from R1 to R2 over which traffic from PC1 to PC2 can be carried. > (2) Must AH and ESP be handled in tunnel mode? Yes, all SAs involving a gateway must be tunnel mode SAs > (3) How can one figure out the tunnel IP address for a paticular > destination address? Is Tunnel IP address included in SA? Good question! We require manual configuration initially, and defer automated forms of discovery for R2 to a later document. Steve From owner-ipsec Thu Aug 28 22:05:30 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA05686 for ipsec-outgoing; Thu, 28 Aug 1997 22:04:38 -0400 (EDT) Message-Id: <199708290212.WAA19250@relay.rv.tis.com> Date: Thu, 28 Aug 97 22:07:09 EDT From: Charles Lynn To: ipsec@tis.com Subject: Re: A few observations about the replay issue Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, In thinking about the issues and tradeoffs, a new (to me :-) issue came up. What do we really mean by "manual configuration". Reading between the lines seems to indicate that some folks might use the "manual API" with some non-ISAKMP key management protocol. If this is the case, and it seems like a reasonable way to connect other key management protocols to the system, then the question arises of whether anti-replay must not be used with things installed using the "manual API", or whether we need a way to indicate "really manual" or "automatic, non-ISAKMP" in the API. (Or alternatively, a way to say "cannot use anti-replay with this SA"). If such a mechanism were to exist (what have the implementors done?), then we could use the following rules. At sender and receiver, The anti-replay field is always present. The anti-replay counter is initialized to zero when the SA is created. At sender, For each packet to be sent, the counter is incremented by one. If the SA does not have the "cannot use anti-replay with this SA" flag set, and the counter is zero, an error event has occurred, drop the packet. Otherwise, place the incremented counter in the packet and ... send it. At receiver, For each packet received, if the "cannot use anti-replay with this SA" flag set, ignore the anti-replay field. Otherwise, perform anti-replay processing -- window check, etc. Would this set of rules satisfy everyone's requirements? Note that these rules do not require any notification from the receiver to the sender to work, but does require that any SAs that do not have the "cannot use anti- replay with this SA" flag set are restricted to sending no more than 2**32 - 1 packets before "rekeying". When we say "rekey" do we mean that a SA with a new SPI is created? To make rollover work, it seems like one would either need two SAs, with different SPIs, or else a single SA with two keys and an anti-replay counter associated with each key. Is this an implementor's choice, or does the architecture doc need to mandate which way must be implemented? Any comments? Charlie From owner-ipsec Thu Aug 28 22:32:32 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA05812 for ipsec-outgoing; Thu, 28 Aug 1997 22:32:08 -0400 (EDT) Message-Id: <97Aug28.224059edt.11650@janus.tor.securecomputing.com> To: Charles Lynn cc: ipsec@tis.com Subject: Re: A few observations about the replay issue References: <199708290212.WAA19250@relay.rv.tis.com> In-reply-to: Your message of "Thu, 28 Aug 1997 22:07:09 -0400". <199708290212.WAA19250@relay.rv.tis.com> From: "C. Harald Koch" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13618.872822476.1@rafael.tornd.securecomputing.com> Date: Thu, 28 Aug 1997 22:41:16 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199708290212.WAA19250@relay.rv.tis.com>, Charles Lynn writes: > > In thinking about the issues and tradeoffs, a new (to me :-) issue came > up. What do we really mean by "manual configuration". Reading between > the lines seems to indicate that some folks might use the "manual API" > with some non-ISAKMP key management protocol. I've always interpreted manual as "requiring some sort of human intervention". You seem to be interpreting it as "not ISAKMP". It was/is a design goal of IPsec to distinctly layer packet munging, key management, and certificate processing. This means that the packet munging layer shouldn't know (or care) what KMP was used, only that manual keys must be treated differently. Note that this means that sending session keys in encrypted PGP e-mail messages is an automatic KMP iff the messages are decrypted and keys downloaded without the human. > When we say "rekey" do we mean that a SA with a new SPI is > created? To make rollover work, it seems like one would either > need two SAs, with different SPIs, or else a single SA with two > keys and an anti-replay counter associated with each key. > Is this an implementor's choice, or does the architecture doc > need to mandate which way must be implemented? New key == New SA (and new SPI). -- Harald Koch From owner-ipsec Thu Aug 28 22:38:46 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA05836 for ipsec-outgoing; Thu, 28 Aug 1997 22:38:37 -0400 (EDT) Message-Id: <97Aug28.224704edt.11650@janus.tor.securecomputing.com> To: Stephen Kent cc: Daniel Harkins , ipsec@tis.com Subject: Re: A few observations about the replay issue References: Your message of "Mon, 25 Aug 1997 17:24:19 CDT." In-reply-to: kent's message of "Thu, 28 Aug 1997 20:39:06 -0400". From: "C. Harald Koch" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13728.872822839.1@rafael.tornd.securecomputing.com> Date: Thu, 28 Aug 1997 22:47:19 -0400 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message , Stephen Kent writes: > > Consider > the situation where the receiver fails to notify the sender that AR is > enabled, (the requirement is a SHOULD, not a MUST) and thus the sender does > not check for sequence counter overflow. If the sender transmits 2**32 > packets, then the receiver will begin rejecting packets, but the sender > will not know why. We've gone to a lot of trouble to include sequence numbers and replay protection into the protocol specs. I should *expect* AR to be turned on given its emphasis in the new specs. So, If the sender rolls its sequence number, and the remote end starts rejecting packets, the sender has an *excellent* idea why. -- Harald From owner-ipsec Thu Aug 28 23:09:53 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA05953 for ipsec-outgoing; Thu, 28 Aug 1997 23:07:38 -0400 (EDT) Message-Id: <199708290316.MAA26925@aries.ascend.co.jp> To: ipsec@tis.com Cc: dharkins@cisco.com, ewong@zk3.dec.com, kent@bbn.com Subject: Re: Is tunnel IP address included in SA? From: Motonori Shindo In-Reply-To: Your message of "Thu, 28 Aug 1997 09:04:47 -0700" References: <199708281604.JAA18658@dharkins-ss20> X-Mailer: Mew version 1.70 on Emacs 19.28.2 / Mule 2.3 X-PGP-fingerprint: 06 B0 B1 A4 06 C1 6A 14 63 C0 D7 18 01 CD D9 83 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 29 Aug 1997 12:16:52 +0900 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Thanks for all who responded to my question. Now I understand how SAs are established. There seems to be several ways to find the tunnel IP address for a particular destination IP address. (1) DNS TX record (2) ISAKMP/Oakley (or other KMPs) (3) an implementatin-specific way to determine what destination IP address corresponds to what tunnel IP address. Probably in manual fashion. I think that (2) is the way to go ultimately, but at the early stage of the deployment of IPsec, (1) or (3) seems to be feasible. Is there any known implementation that is using (1) approach? Does curent BIND (8.X?) support this RR? Now I am wondering why people chose the way like this. I guess the way I initially come up with isn't that bad. That is, (4) To have one SA for each final destination IP address and such an SA have a corresponding tunnel IP address. This approach is considered to be one of the variant of (3) approach, but the way to have an SA is different. For example, | | PC1 -+ +- PC21 | (Internet) | +-- R1 --- ......... --- R2 ----+ | . | . +- PC22 R3 | | ----+---+-- PC3 In the figure above, PC1 sends datagarams to PC21, PC22, and PC3. Then, R1 should have three SAs like, SA1 : destIP = PC21, SPI(AH, keyed-MD5, MD5key=xxxxx, tunnelIP= R2) SA2 : destIP = PC22, SPI(ESP, DES-CBC, DESkey=yyyyy, tunnelIP= R2) SA3 : destIP = PC3, SPI(AH, keyed-MD5, key=zzz, tunnelIP= R3) This approach eliminates the need to resolve the tunnel IP address for each destination IP address by making a tunnel IP address be a part of SA information. Any comments? ===================================== Motonori Shindo Systems Engineer Ascend Communications Japan K.K. email: mshindo@ascend.co.jp TEL: +81-3-5325-7306 ===================================== From owner-ipsec Thu Aug 28 23:54:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA06135 for ipsec-outgoing; Thu, 28 Aug 1997 23:54:08 -0400 (EDT) Message-Id: <199708290401.AAA20051@relay.rv.tis.com> Date: Thu, 28 Aug 97 23:57:43 EDT From: Karen Seo To: Ne cc: ipsec@tis.com Subject: Re: order/nesting of IPsec headers (transport mode) Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, >>...When we apply the IPSEC to the following packet, >> >> [IP1][upper] >> >>There are all pattern of SA in following, which are indicated by >>the draft-ietf-ipsec-arch-sec-01.txt e-mailed on 30 July, >> >> Only transport mode >> [IP1][AH][upper] >> [IP1][ESP][upper] >> >> Only tunnel mode >> [IP2][AH][IP1][upper] >> [IP2][ESP][IP1][upper] >> >> Combined transport mode of AH and ESP, "Transport adjacency" >> [IP1][AH][ESP][upper] >> >> Combined tunnel mode of ESP and AH, "Iterated tunneling" >> [IPn][AH or ESP][IPn-1][AH or ESP][...][IP2][AH or ESP][IP1][upper] >> >> Combined transport mode of AH or ESP, and "Iterated tunneling" >> [IPn][AH or ESP][IPn-1][AH or ESP][...][IP2][AH or ESP][IP1][AH or ESP][upper] >> >> Combined "Transport adjacency" and "Iterated tunneling" >> [IPn][AH or ESP][IPn-1][AH or ESP][...][IP2][AH or ESP][IP1][AH][ESP][XPORT] >> >>Is that all ? Yes. You have listed those combinations of SAs that we believed the community had agreed were needed as a minimum set. However, as indicated in other email and your question below, there are other combinations that are possible and we have raised the question as to whether support for them should be allowed and/or mandated. >>The next, Is there a pattern of bundle SA as following, ? >> >> [IP2][AH][ESP][IP1][upper] >> >> * [upper] is the upper layer protocol >> >>If certainly, is that constructed two tunnel mode of both AH and ESP >>that are terminated at same destination ? Yes. This is an example of 2 tunnel headers applied by the same box (host or security gateway). NOTE: In theory, it's also possible for a single host to apply more than the 2 tunnel headers: [IP2][AH or ESP][AH or ESP][...][AH or ESP][IP1][upper] or to apply more than the 2 transport headers: [IP1][AH or ESP][AH or ESP][...][AH or ESP][upper]. >>P.S. Thank you for your help and sorry for my bad english I only wish my original email had been as clear :-). Thank you, Karen From owner-ipsec Fri Aug 29 06:18:41 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id GAA07961 for ipsec-outgoing; Fri, 29 Aug 1997 06:16:36 -0400 (EDT) Date: Fri, 29 Aug 1997 10:25:40 GMT Message-Id: <199708291025.KAA02585@intruder.crd.yokogawa.co.jp> From: Ne To: kseo@bbn.com Cc: ipsec@tis.com Subject: Re: order/nesting of IPsec headers (transport mode) In-Reply-To: Your message of Thu, 28 Aug 97 23:57:43 EDT. <199708290401.AAA20051@relay.rv.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Mailer: mnews [version 1.19PL2] 1996-01/26(Fri) Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, kseo: NOTE: In theory, it's also possible for a single host to apply kseo: more than the 2 tunnel headers: kseo: kseo: [IP2][AH or ESP][AH or ESP][...][AH or ESP][IP1][upper] kseo: kseo: or to apply more than the 2 transport headers: kseo: kseo: [IP1][AH or ESP][AH or ESP][...][AH or ESP][upper]. It is good implement that all combination of SA is able to supported, and configured freely, may be. I'm implementing security protocol into the kernel of BSD/OS2.1. After all, I have supported varius combination of SA except following pattern, [IP][ESP][AH][upper] This pattern is not significant. Instead, following should be employed, I think. [IP][ESP][upper] Thank you for your comments. P.S. I want to have a good command of English ... ;-( ========================================================== Shoichi Sakane TEL : +81-0423-33-6209 E-Mail: sakane@cct.dcl.co.jp FAX : +81-0423-52-6102 Information & Communication Technology Center Yokogawa Digital Computer Corporation, Tokyo, JAPAN From owner-ipsec Fri Aug 29 08:03:17 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA08583 for ipsec-outgoing; Fri, 29 Aug 1997 08:01:34 -0400 (EDT) Date: Fri, 29 Aug 97 11:54:23 GMT Daylight Time From: Ran Atkinson Subject: Re: A few observations about the replay issue To: Charles Lynn , ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199708290212.WAA19250@relay.rv.tis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Thu, 28 Aug 97 22:07:09 EDT Charles Lynn wrote: [I'm quite deliberately sidestepping the anti-replay part of this thread. rja] > When we say "rekey" do we mean that a SA with a new SPI is > created? Yes. This has _always_ been the meaning. In some sense, the term is unfortunate because some have heard that term and misunderstood that one could simply change the key with an existing SA. The "use the same SA and same SPI but change the crypto key only" approach does not work because IP datagrams can be (and routinely are) delivered out of order. > To make rollover work, it seems like one would either > need two SAs, with different SPIs, or else a single SA with two > keys and an anti-replay counter associated with each key. One needs two SAs ("old" and "new"), each with a different SPI at the time of rollover. To handle rollover, there will need to be some (non-zero) time period where both SAs are valid on the receiver (necessary to handle the IP packets delivered slightly out of order case). > Is this an implementor's choice, or does the architecture doc > need to mandate which way must be implemented? I'm not sure what the question above is asking... Things that are NOT implementer's choice are: 1) "rekey" means to establish a replacement IPsec SA with its own (different) SPI value. 2) To implement rollover, the implementation must possess 2 separate IPsec SAs (each with its own different SPI) at the moment of rollover. Ran rja@inet.org From owner-ipsec Fri Aug 29 08:13:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA08668 for ipsec-outgoing; Fri, 29 Aug 1997 08:13:39 -0400 (EDT) Date: Fri, 29 Aug 97 12:03:40 GMT Daylight Time From: Ran Atkinson Subject: Re: Is tunnel IP address included in SA? To: ipsec@tis.com, Motonori Shindo Cc: dharkins@cisco.com, ewong@zk3.dec.com, kent@bbn.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199708290316.MAA26925@aries.ascend.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk --- On Fri, 29 Aug 1997 12:16:52 +0900 Motonori Shindo wrote: > There seems to be several ways to find the tunnel IP address for a > particular destination IP address. > > (1) DNS TX record > > (2) ISAKMP/Oakley (or other KMPs) > > (3) an implementatin-specific way to determine what destination IP > address corresponds to what tunnel IP address. Probably in manual > fashion. Whether or not one likes the KX (Note: KX != TX) record notion, there is some text in draft-rfced-info-atkinson-kx-*.txt about Proxy KM that might be useful to consider. In particular, if one is trying to setup a secure ESP tunnel for a destination that does not implement IPsec itself, it is unlikely that the same destination will be implementing ISAKMP/Oakley to facilitate approach (3). However, in a world of Secure DNS, it would be straight-forward to use the KX record for the intended destination to indicate the node that is authorised to handle KM on behalf of the destination node. At that point, normal ISAKMP/Oakley (or other KM protocol) can do the rest of the work to setup the needed ESP tunnel SA. > I think that (2) is the way to go ultimately, but at the early stage > of the deployment of IPsec, (1) or (3) seems to be feasible. Is there > any known implementation that is using (1) approach? Does curent BIND > (8.X?) support this RR? I don't know about TX. KX record has been implemented in BIND (though not by Paul) and is deployed in certain IP-based networks, but it is not clear to me whether that implementation is widely available. > Now I am wondering why people chose the way like this. I guess the way > I initially come up with isn't that bad. That is, > > (4) To have one SA for each final destination IP address and such an > SA have a corresponding tunnel IP address. I am not sure what you are saying. Do you mean that an SA should have: Source Identity Source Proxy Identity (currently generally called Proxy Identity) Destination Identity Destination Proxy Identity ??? The Source Proxy Identity (and validation of it at receive time) is _necessary_ to prevent use of tunnel-mode IPsec to implement spoofing attacks. > This approach is considered to be one of the variant of (3) approach, > but the way to have an SA is different. For example, > > > | | > PC1 -+ +- PC21 > | (Internet) | > +-- R1 --- ......... --- R2 ----+ > | . | > . +- PC22 > R3 | > | > ----+---+-- > PC3 > > In the figure above, PC1 sends datagarams to PC21, PC22, and > PC3. Then, R1 should have three SAs like, > > SA1 : destIP = PC21, SPI(AH, keyed-MD5, MD5key=xxxxx, tunnelIP= R2) > SA2 : destIP = PC22, SPI(ESP, DES-CBC, DESkey=yyyyy, tunnelIP= R2) > SA3 : destIP = PC3, SPI(AH, keyed-MD5, key=zzz, tunnelIP= R3) > > This approach eliminates the need to resolve the tunnel IP address for > each destination IP address by making a tunnel IP address be a part of > SA information. > > Any comments? How does the Tunnel IP address get into the SA in the first place ? It seems like one MUST resolve it _before_ putting it into the SA. Ran rja@inet.org From owner-ipsec Fri Aug 29 12:24:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA10136 for ipsec-outgoing; Fri, 29 Aug 1997 12:21:59 -0400 (EDT) Message-ID: <3406F93E.74F6@fet.com> Date: Fri, 29 Aug 1997 09:30:54 -0700 From: "Scott G. Kelly" Organization: Furukawa Electric Technologies, Inc. X-Mailer: Mozilla 3.03 (Win95; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: Re: Is tunnel IP address... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Ran Atkinson wrote: > > --- On Fri, 29 Aug 1997 12:16:52 +0900 Motonori Shindo wrote: > > > There seems to be several ways to find the tunnel IP address for a > > particular destination IP address. > How does the Tunnel IP address get into the SA in the first place ? > It seems like one MUST resolve it _before_ putting it into the SA. > > Ran > rja@inet.org I'm guessing that he (Shindo) doesn't really mean the SA - I think he means the database entry used to *construct* the SA. The last architecture document refers to the proxy ip address in this SPD entry, and that's what you can use to differentiate SA requirements in this situation. From owner-ipsec Fri Aug 29 20:33:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA12627 for ipsec-outgoing; Fri, 29 Aug 1997 20:30:31 -0400 (EDT) Message-Id: <3.0.32.19970829173858.009799d0@192.43.161.2> X-Sender: jburke@192.43.161.2 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 29 Aug 1997 17:38:59 -0700 To: ipsec@tis.com, dharkins@cisco.com From: John Burke Subject: BAD_ID_RANGE Notification per Oakley Cc: jburke@cylink.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Oakley ver-04 still contains this text (in 5.4 Phase 2 - Quick Mode, a couple of paragraphs from the end, immediately before the description of negotiating multiple SA's): [ .. ]If an ID range (see Appendix A of [Pip96]) is not acceptable (for example, the specified subnet is too large) a BAD_ID_RANGE notify message followed by an acceptible ID range, in an ID payload, MUST be sent. Someone pointed out on the list a while ago that the provisions for notification of bad address are no longer in the ISAKMP spec. Is this "MUST" in Oakley meant to stand or should we expect it to go away? - John Burke, Cylink, Sunnyvale, CA