[Openswan Users] Users Digest, Vol 90, Issue 10

Marco Berizzi pupilla at hotmail.com
Thu May 12 11:42:38 EDT 2011


si, ho tastiere sono pieno

----------------------------------------
From: users-request at openswan.org
Subject: Users Digest, Vol 90, Issue 10
To: users at openswan.org
Date: Thu, 12 May 2011 10:44:06 -0400


Send Users mailing list submissions to
        users at openswan.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.openswan.org/mailman/listinfo/users
or, via email, send a message with subject or body 'help' to
        users-request at openswan.org

You can reach the person managing the list at
        users-owner at openswan.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Users digest..."


--Forwarded Message Attachment--
From: paul at xelerance.com
CC: users at openswan.org
To: fupings at gmail.com
Date: Wed, 11 May 2011 13:18:01 -0400
Subject: Re: [Openswan Users] aggresive mode


On Wed, 11 May 2011, Ping Fu wrote:

> I'm a new learner of openswan and I want to create a connection
> between two virtual machine using aggressive mode. but I failed for a
> lot of times, I'm wondering if anyone can give me a hand, thanks!

You should never use aggressive mode or pfs=no between openswan machines.

If the machines are in the same subnet, you might want to try type=%direct

Paul

> the ipsec.config I use is as followed:
> conn net-to-net
>               left=192.168.0.121
>               #leftsubnet=192.168.2.0/24
>               leftid=@leftserver.localdomain
>               leftrsasigkey=0sAQNznQrsOjrFeoinjMlR20gTu4U+cxUGTeCi4VI97Y4IOblUyPBpQvT3A0npNCJEE/oFXCy5eW5ewv/Py6ImVHyvueDaX+0yP6fFQlLmI8jozk0KvPnjQyyo436YKGhPtfY1u6Zw/s+S9DvJcExwnTlavsULtPefkBVIZuluh6nE5GGDZdQwz8TM5g7zd4eDNTmPw2NiKJTXBgf0bhZFWOh9532G08TFTqf8EWmX/v5PrHyDhPoeRhYVDB8OIIHj6a7fa35XhHLk+wus0+4Mxl2nGKLOQ/7baIeWkNrM4iBm92TloM7xT+JoUEXRDJeyiUUB6LZxgomRRQs2f9YcqSLlVlPaoiuag7vFeg/5bimt7LSb
>               right=192.168.0.174
>               #rightsubnet=192.168.3.0/24
>               rightid=@rightserver.localdomain
>               rightrsasigkey=0sAQOueOcvGZkVHG7IShGikd+MgtKV9BQBeA3NP2CcbLGo7HS+s4JTLK2YP1XIyA+JD7r8j4YyBqGqrrHdMDyAjDOKIgkT2z+X2GZKHdL3NQVmAszipSLgvwYZ8RRQD/APU4AZuHfKBOiEjSrSZUjK0vM/C2cOObZp9skaLd7QgAGuuhfUwWLkwMJurZUDtRxZVNX4OfwbSFhcS3UO3qhkcaMg+0hAnWmb3en8l7hvnsRiUlXfbXBn1pmowWE5JUQ6fsjkunA/1VSiu1ixQf66otBqvXZDg/m+X3Ay1Vn0+3c5zGnX8ckbNHGWbiHdhDbLexZmXRLqXTQkBHdXFoXLaWnKzTctx1mj0hQG7wzfVDdpFNW1
>               auto=add
>               authby=secret
>               type=tunnel
>               keyexchange=ike
>               auth=esp
>               pfs=no
>               ike=3des-md5-modp2048
>               ikelifetime="28800"
>               esp=3des-md5-96
>               keylife="3600"
>               aggrmode=yes
>               rekey=yes
>
> the ipsec.secrets file is
>
> @leftserver.localdomain: RSA  {
>       # RSA 2192 bits   localhost.localdomain   Tue Apr 12 04:35:04 2011
>       # for signatures only, UNSAFE FOR ENCRYPTION
>       #pubkey=0sAQNznQrsOjrFeoinjMlR20gTu4U+cxUGTeCi4VI97Y4IOblUyPBpQvT3A0npNCJEE/oFXCy5eW5ewv/Py6ImVHyvueDaX+0yP6fFQlLmI8jozk0KvPnjQyyo436YKGhPtfY1u6Zw/s+S9DvJcExwnTlavsULtPefkBVIZuluh6nE5GGDZdQwz8TM5g7zd4eDNTmPw2NiKJTXBgf0bhZFWOh9532G08TFTqf8EWmX/v5PrHyDhPoeRhYVDB8OIIHj6a7fa35XhHLk+wus0+4Mxl2nGKLOQ/7baIeWkNrM4iBm92TloM7xT+JoUEXRDJeyiUUB6LZxgomRRQs2f9YcqSLlVlPaoiuag7vFeg/5bimt7LSb
>       Modulus: 0x739d0aec3a3ac57a88a78cc951db4813bb853e7315064de0a2e1523ded8e0839b954c8f06942f4f70349e934224413fa055c2cb9796e5ec2ffcfcba226547cafb9e0da5fed323fa7c54252e623c8e8ce4d0abcf9e3432ca8e37e9828684fb5f635bba670fecf92f43bc9704c709d395abec50bb4f79f90154866e96e87a9c4e4618365d430cfc4cce60ef377878335398fc363622894d70607f46e164558e87de77d86d3c4c54ea7fc116997fefe4fac7c8384fa1e4616150c1f0e2081e3e9aedf6b7e578472e4fb0bacd3ee0cc65da718a2ce43fedb68879690dacce22066f764e5a0cef14fe2685045d10c97b2894501e8b671828991450b367fd61ca922e55653daa22b9a83bbc57a0ff96e29adecb49b
>       PublicExponent: 0x03
>       # everything after this point is secret
>       PrivateExponent:
> 0x1344d7275f09cb946c1beccc384f36adf49635132e2bb7a5707ae30a524256b4498e217d66e07e292b36fc335b0b58a9ab8f5cc9943d0fcb2aa2a1f05bb8bf729efacf0ffcddb546a0e063265b4c26cd0cd71f7efb35dcc6d095195c11629e53b39f46682a77edd35f4c3d6212c4dee47520d748d3efed58e1667c3d169c4b7b6595e64e0822a0ccd0c86d6b7f5a35def8f3c43e7ce4f1cf85218ceb8c7a01d3565b76c81c91179301b35f7aa366696ef986be0d279becb949dbe8728d9f4e2aa4cc64fec4241ba0aa785d73aea4420e66adf745d20d7842c71d38ee60220c43193cea2187f6d2c2d2e3818c120f3b67e10ae22b8609168f6fe68b6cb0a8aa9b54936f94f1fab4a18d6e256580a2b0613f43
>       Prime1: 0xc982c39b3eb2d48393fba672e2f54de1ebb6dbc9b8f96bb95b5590576a805b285220d25e06ae99e24773b6f078335a9f30e4e5703c06fe141a72c4aab44b5f3e84dd8c5c4182b99cfd25e4ace145eb2895ee226e301b714b6d45301130d86a8e0b11f1cdf4ea54024c8c38cebf376fbc3d44ad0bf433153e26193a8d290bdc4da416d8d56109a22443
>       Prime2: 0x92e02ef0273f2b3678ce44c85436db073f69b530c3e41e27fd6892c1f440dac98b0be5cc912878c1139cf440265662b1c6b68bbfec0db0ee86ad9a40e5f3d7ce55c5ab98ab4e971391dcbc65a9510bc34b9714332401f3820aded5b056196cd0e5b5d25d623a81b95add338f93d278af91f69cecc0f02c1cb923e9f2913c16274118bf94f8820314c9
>       Exponent1: 0x86572d1229cc8dad0d526ef741f8de969d2492867b50f27b92390ae4f1aae77036c08c3eaf1f114184f7cf4afacce714cb4343a02804a962bc4c831c78323f7f033e5d92d6572668a8c3edc8962e9cc5b9496c497567a0dcf3837560cb3af1b407614bdea346e2ac330825df2a24f52828d8735d4d77637ec410d1b370b292de6d64908e40b116c2d7
>       Exponent2: 0x61eac9f56f7f72245089833038249204d4f12375d7ed696ffe45b72bf82b3c865cb299330b705080b7bdf82ac43997212f245d2a9d5e75f459c91180994d3a898e83c7bb1cdf0f62613dd2ee70e0b2823264b82218014d015c948e758ebb9de09923e19396d1abd0e73e225fb7e1a5ca614f134880a01d687b6d46a1b6280ec4d6107fb8a5ac020ddb
>       Coefficient: 0xa160a64ddbb69b4452924de819bd61ec226d52b7924bcf162649dd871d8f74bccff05ea943c8cc03366d4da826d25453742d648c4c0cf83375132804147571a638fd1bed6846472fee2e9d3709ea64b4ef46ab5c8c02efb15bbba975bcfaca227241ead20aeee098dae39a46586f0f6fbcd408cb512cc89343e5ad510e970072e7c1e2fbcc460dbb47
>       }
>
> Best Regards!
> Lin
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>



--Forwarded Message Attachment--
From: fupings at gmail.com
CC: users at openswan.org
To: paul at xelerance.com
Date: Thu, 12 May 2011 10:28:48 +0800
Subject: Re: [Openswan Users] aggresive mode


Hi Paul

thanks for your reply. I just want to realize aggressive mode to meet
experiment requirement.

I'm a little confused about your words that I can try type=%direct
because %direct seems unacceptable for param "type".

I configure the connection according the instruction on
http://wiki.openswan.org/index.php/Openswan/Aggrmode  but fail. I'm
wondering where does the problem lies. thanks!

Best Regards!
Lin

On Thu, May 12, 2011 at 1:18 AM, Paul Wouters  wrote:
> On Wed, 11 May 2011, Ping Fu wrote:
>
>> I'm a new learner of openswan and I want to create a connection
>> between two virtual machine using aggressive mode. but I failed for a
>> lot of times, I'm wondering if anyone can give me a hand, thanks!
>
> You should never use aggressive mode or pfs=no between openswan machines.
>
> If the machines are in the same subnet, you might want to try type=%direct
>
> Paul
>
>> the ipsec.config I use is as followed:
>> conn net-to-net
>>                left=192.168.0.121
>>                #leftsubnet=192.168.2.0/24
>>                leftid=@leftserver.localdomain
>>
>>  leftrsasigkey=0sAQNznQrsOjrFeoinjMlR20gTu4U+cxUGTeCi4VI97Y4IOblUyPBpQvT3A0npNCJEE/oFXCy5eW5ewv/Py6ImVHyvueDaX+0yP6fFQlLmI8jozk0KvPnjQyyo436YKGhPtfY1u6Zw/s+S9DvJcExwnTlavsULtPefkBVIZuluh6nE5GGDZdQwz8TM5g7zd4eDNTmPw2NiKJTXBgf0bhZFWOh9532G08TFTqf8EWmX/v5PrHyDhPoeRhYVDB8OIIHj6a7fa35XhHLk+wus0+4Mxl2nGKLOQ/7baIeWkNrM4iBm92TloM7xT+JoUEXRDJeyiUUB6LZxgomRRQs2f9YcqSLlVlPaoiuag7vFeg/5bimt7LSb
>>                right=192.168.0.174
>>                #rightsubnet=192.168.3.0/24
>>                rightid=@rightserver.localdomain
>>
>>  rightrsasigkey=0sAQOueOcvGZkVHG7IShGikd+MgtKV9BQBeA3NP2CcbLGo7HS+s4JTLK2YP1XIyA+JD7r8j4YyBqGqrrHdMDyAjDOKIgkT2z+X2GZKHdL3NQVmAszipSLgvwYZ8RRQD/APU4AZuHfKBOiEjSrSZUjK0vM/C2cOObZp9skaLd7QgAGuuhfUwWLkwMJurZUDtRxZVNX4OfwbSFhcS3UO3qhkcaMg+0hAnWmb3en8l7hvnsRiUlXfbXBn1pmowWE5JUQ6fsjkunA/1VSiu1ixQf66otBqvXZDg/m+X3Ay1Vn0+3c5zGnX8ckbNHGWbiHdhDbLexZmXRLqXTQkBHdXFoXLaWnKzTctx1mj0hQG7wzfVDdpFNW1
>>                auto=add
>>                authby=secret
>>                type=tunnel
>>                keyexchange=ike
>>                auth=esp
>>                pfs=no
>>                ike=3des-md5-modp2048
>>                ikelifetime="28800"
>>                esp=3des-md5-96
>>                keylife="3600"
>>                aggrmode=yes
>>                rekey=yes
>>
>> the ipsec.secrets file is
>>
>> @leftserver.localdomain: RSA    {
>>        # RSA 2192 bits   localhost.localdomain   Tue Apr 12 04:35:04 2011
>>        # for signatures only, UNSAFE FOR ENCRYPTION
>>
>>  #pubkey=0sAQNznQrsOjrFeoinjMlR20gTu4U+cxUGTeCi4VI97Y4IOblUyPBpQvT3A0npNCJEE/oFXCy5eW5ewv/Py6ImVHyvueDaX+0yP6fFQlLmI8jozk0KvPnjQyyo436YKGhPtfY1u6Zw/s+S9DvJcExwnTlavsULtPefkBVIZuluh6nE5GGDZdQwz8TM5g7zd4eDNTmPw2NiKJTXBgf0bhZFWOh9532G08TFTqf8EWmX/v5PrHyDhPoeRhYVDB8OIIHj6a7fa35XhHLk+wus0+4Mxl2nGKLOQ/7baIeWkNrM4iBm92TloM7xT+JoUEXRDJeyiUUB6LZxgomRRQs2f9YcqSLlVlPaoiuag7vFeg/5bimt7LSb
>>        Modulus:
>> 0x739d0aec3a3ac57a88a78cc951db4813bb853e7315064de0a2e1523ded8e0839b954c8f06942f4f70349e934224413fa055c2cb9796e5ec2ffcfcba226547cafb9e0da5fed323fa7c54252e623c8e8ce4d0abcf9e3432ca8e37e9828684fb5f635bba670fecf92f43bc9704c709d395abec50bb4f79f90154866e96e87a9c4e4618365d430cfc4cce60ef377878335398fc363622894d70607f46e164558e87de77d86d3c4c54ea7fc116997fefe4fac7c8384fa1e4616150c1f0e2081e3e9aedf6b7e578472e4fb0bacd3ee0cc65da718a2ce43fedb68879690dacce22066f764e5a0cef14fe2685045d10c97b2894501e8b671828991450b367fd61ca922e55653daa22b9a83bbc57a0ff96e29adecb49b
>>        PublicExponent: 0x03
>>        # everything after this point is secret
>>        PrivateExponent:
>>
>> 0x1344d7275f09cb946c1beccc384f36adf49635132e2bb7a5707ae30a524256b4498e217d66e07e292b36fc335b0b58a9ab8f5cc9943d0fcb2aa2a1f05bb8bf729efacf0ffcddb546a0e063265b4c26cd0cd71f7efb35dcc6d095195c11629e53b39f46682a77edd35f4c3d6212c4dee47520d748d3efed58e1667c3d169c4b7b6595e64e0822a0ccd0c86d6b7f5a35def8f3c43e7ce4f1cf85218ceb8c7a01d3565b76c81c91179301b35f7aa366696ef986be0d279becb949dbe8728d9f4e2aa4cc64fec4241ba0aa785d73aea4420e66adf745d20d7842c71d38ee60220c43193cea2187f6d2c2d2e3818c120f3b67e10ae22b8609168f6fe68b6cb0a8aa9b54936f94f1fab4a18d6e256580a2b0613f43
>>        Prime1:
>> 0xc982c39b3eb2d48393fba672e2f54de1ebb6dbc9b8f96bb95b5590576a805b285220d25e06ae99e24773b6f078335a9f30e4e5703c06fe141a72c4aab44b5f3e84dd8c5c4182b99cfd25e4ace145eb2895ee226e301b714b6d45301130d86a8e0b11f1cdf4ea54024c8c38cebf376fbc3d44ad0bf433153e26193a8d290bdc4da416d8d56109a22443
>>        Prime2:
>> 0x92e02ef0273f2b3678ce44c85436db073f69b530c3e41e27fd6892c1f440dac98b0be5cc912878c1139cf440265662b1c6b68bbfec0db0ee86ad9a40e5f3d7ce55c5ab98ab4e971391dcbc65a9510bc34b9714332401f3820aded5b056196cd0e5b5d25d623a81b95add338f93d278af91f69cecc0f02c1cb923e9f2913c16274118bf94f8820314c9
>>        Exponent1:
>> 0x86572d1229cc8dad0d526ef741f8de969d2492867b50f27b92390ae4f1aae77036c08c3eaf1f114184f7cf4afacce714cb4343a02804a962bc4c831c78323f7f033e5d92d6572668a8c3edc8962e9cc5b9496c497567a0dcf3837560cb3af1b407614bdea346e2ac330825df2a24f52828d8735d4d77637ec410d1b370b292de6d64908e40b116c2d7
>>        Exponent2:
>> 0x61eac9f56f7f72245089833038249204d4f12375d7ed696ffe45b72bf82b3c865cb299330b705080b7bdf82ac43997212f245d2a9d5e75f459c91180994d3a898e83c7bb1cdf0f62613dd2ee70e0b2823264b82218014d015c948e758ebb9de09923e19396d1abd0e73e225fb7e1a5ca614f134880a01d687b6d46a1b6280ec4d6107fb8a5ac020ddb
>>        Coefficient:
>> 0xa160a64ddbb69b4452924de819bd61ec226d52b7924bcf162649dd871d8f74bccff05ea943c8cc03366d4da826d25453742d648c4c0cf83375132804147571a638fd1bed6846472fee2e9d3709ea64b4ef46ab5c8c02efb15bbba975bcfaca227241ead20aeee098dae39a46586f0f6fbcd408cb512cc89343e5ad510e970072e7c1e2fbcc460dbb47
>>        }
>>
>> Best Regards!
>> Lin
>> _______________________________________________
>> Users at openswan.org
>> http://lists.openswan.org/mailman/listinfo/users
>> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
>> Building and Integrating Virtual Private Networks with Openswan:
>> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>>
>



--Forwarded Message Attachment--
From: chenja at avaya.com
To: users at openswan.org; paul at xelerance.com
Date: Thu, 12 May 2011 10:32:37 -0400
Subject: [Openswan Users] Openswan IPSec




Hi Paul and all,



I’m using openswan-2.6.21_53 from redhat. I don’t know much about openswan design, but I have to answer if openswan meets all these requirements. Can you please help me? Appreciate you help.

The system shall only support the following erroneous messages associated with a certificate request:


III


* Invalid Key  [James: yes]


* Invalid ID     [James: ?]


* Invalid certificate encoding [James: ?]


* Invalid certificate [James: yes]


* Certificate type unsupported [James: ?]


* Invalid CA [James: ?]


* Invalid hash [James: ?]


* Authentication failed [James: yes]


* Invalid signature [James: yes]


* Certificate unavailable [James: ?]




Path Development and Path Processing:


1)      Applications supporting relying party processes must be capable of developing a certificate path and processing the path (The path development process produces a sequence of certificates that connect a given end-entity certificate to a trust point).


I



Path Development:


1)      Applications should construct paths automatically without involvement of a human. [James: ?]


II



Path Processing :


1)      Applications should reject a path where an included certificate expired between the effective date and the current date unless the application is re-verifying a signature that was verified at an earlier date when none of the involved certificates were expired [James: ?]


II


2)      When an application must validate a path involving expired certificates, the application must check the status of using CRLs issued after the effective date but prior to the expiration of a currently expired certificate and should use the most current CRL preceding a certificate’s expiration.[James: ?]


I


3)     Applications must perform the following major steps for path processing for each certificate in the chain:


I


•        Verifying certificate signatures. This verification shall use the certificate issuer’s public key. [James: yes.]


I


•        Ensuring effective date falls within the certificate’s validity period. [James: yes.]


•        Ensuring certificate use is consistent with extensions.[James: ?]


•        Ensuring the validity of certificates through a status check. The following section will address status checking.



Certificate Status Checking:


1)     If using CRL for certificate status check, applications shall perform the following steps for each certificate being validated (target certificate):


I


•        Verify the signature on the CRL. This verification requires developing and processing a certificate path establishing that the target certificate’s issuer trusted the CRL issuer to issue CRLs. [James: openswan checks the issuer's signature of the crl]


•        Verify that the CRL has not expired if the target certificate has not expired.[James: yes.] A CRL is expired if the current date is after the CRL’s next update field value. (See above paragraph regarding paths with expired certificates.)[James:?] If the target certificate has expired, verify that the CRL’s issue date follows the effective date and precedes the certificate’s expiration date.[James: ?]


•        Search the list of revoked certificates to determine that the target certificate either is not included or its revocation date is after the effective date. [James: yes.]




Extension Processing:[James: ?]


1)      Applications shall ensure that the intended use of the certificate is consistent with the extensions.


I


2)     Applications must process the critical extensions and should process non-critical extensions.


I


3)     Applications shall ensure that in the Key Usage extension in the end-entity certificate:


I


     •        The digital signature bit is set for authentication uses.


     •        The non-repudiation bit is set for non-repudiation uses.


     •        The key encipherment bit or the data encipherment bit is set for encryption uses depending on whether keys or data are to be encrypted.


4)     Applications shall ensure that for certificates other the Root CA in the Key Usage extension:


I


     •        The Certificate Signature bit is set in the certificate containing the public key used to sign the next certificate in the chain.


     •        The CRL Signature bit is set in the certificate containing the public key used to sign a CRL.


5)     Applications shall ensure that Basic Constraints extension is true in the certificate containing a public key used to sign a subsequent certificate in the path.


I






Thanks,

James


 		 	   		  


More information about the Users mailing list