Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id p1BMNn69005168; Fri, 11 Feb 2011 14:23:49 -0800 Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 6F3443E4082; Fri, 11 Feb 2011 22:24:03 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id a+O5ocqAl38L; Fri, 11 Feb 2011 22:24:03 +0000 (GMT) Received: from [10.87.48.6] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id EE48D3E407F; Fri, 11 Feb 2011 22:24:02 +0000 (GMT) Message-ID: <4D55B701.7020108@cs.tcd.ie> Date: Fri, 11 Feb 2011 22:24:01 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: DTN , DTN Security Discussion , "dtn-users@maillists.intel-research.net" References: <4D4BD4C6.3040900@cs.tcd.ie> In-Reply-To: <4D4BD4C6.3040900@cs.tcd.ie> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dtn-security] [dtn-interest] Migrating mailing list and wiki X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 22:23:50 -0000 Hi again, Just an FYI, we've now migrated the wiki to its new home. Please let Alex (cc'd) and I know if you spot anything odd or broken. All current write access etc should be just the same (mine worked anyway;-). More on the mailing list next week, but the current plan is to move to e.g. dtn-interest@irtf.org so when we're ready we'll subscribe all the current list members to the new list(s), send out a last message to each of the lists being migrated (see the To: line above) and then shut these lists. List archives (both old and new) will be hosted at the new list info site. Again, any issues there please let us know. Sorry that you'll have to adjust your filters, but there ya go. I hope that'll all happen next week. Regards, Stephen. On 04/02/11 10:28, Stephen Farrell wrote: > > Hi all, > > Due to some machine changes with the current infrastructure > we're planning to migrate the DTNRG related lists (dtn-interest, > dtn-security and dtn-users) to the IETF/IRTF infrastructure in > the next few weeks. That'll mean you'll need to change filters > etc. but everything else should be the same. > > We're also planning to move the wiki, which, all going well, > should just result in a little downtime. > > Once we're all set, we'll send another mail with the final > details. > > If there're any issues with the above please mail Kevin and > I, and also cc Alex McMahon (alex.mcmahon@cs.tcd.ie) who'll > be doing most of the real work involved. > > Regards, > Stephen. > > _______________________________________________ > dtn-interest mailing list > dtn-interest@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-interest > Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id p14DNQQK008770; Fri, 4 Feb 2011 05:23:26 -0800 Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0B8A921B0334; Fri, 4 Feb 2011 08:23:28 -0500 (EST) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 00ECA21B032B; Fri, 4 Feb 2011 08:23:28 -0500 (EST) Received: from IMCMBX2.MITRE.ORG ([129.83.29.209]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Fri, 4 Feb 2011 08:23:28 -0500 From: "Scott, Keith L." To: Shoaib Malik , "dtn-security@maillists.intel-research.net" Date: Fri, 4 Feb 2011 08:23:25 -0500 Thread-Topic: [dtn-security] hop-by-hop authentication Thread-Index: AcvEXnWrcJ7S3YnCRbaGxuptySQBSwADs6uw Message-ID: <0111C34BD897FD41841D60396F2AD3D307A7CF35F6@IMCMBX2.MITRE.ORG> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00B8_01CBC444.CB46DBF0" MIME-Version: 1.0 Cc: "dtn-interest@maillists.intel-research.net" Subject: Re: [dtn-security] hop-by-hop authentication X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 13:23:26 -0000 ------=_NextPart_000_00B8_01CBC444.CB46DBF0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00B9_01CBC444.CB46DBF0" ------=_NextPart_001_00B9_01CBC444.CB46DBF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The hop-by-hop authentication is designed to keep 'bogus' traffic out of the network by providing a mechanism to prevent un-authenticated sources from injecting it. Hop-by-hop security assumes that the appropriate keys and policy are in the network. You're right in that *if* a malicious node can forge a signature for a bundle and inject it into the network, then after the first hop there's nothing in the BAB machinery to restrict that bundle's movement (though other security policies that use non-single-hop mechanisms like the payload security block might be in place). The notion was that some networks may have very constrained, expensive, or critical links and that it would be desirable to deter someone who could connect to the network from being able to inject traffic that would cross those links, consuming resources. End-to-end security like IPSec doesn't do this, e.g., because the traffic isn't thrown away until the destination (after it's consumed resources on the critical link(s)). --keith From: dtn-security-bounces@maillists.intel-research.net [mailto:dtn-security-bounces@maillists.intel-research.net] On Behalf Of Shoaib Malik Sent: Friday, February 04, 2011 6:27 AM To: dtn-security@maillists.intel-research.net Cc: dtn-interest@maillists.intel-research.net Subject: [dtn-security] hop-by-hop authentication Hi All, I have a question about the hop-by-hop authentication in BSP.. On each hop, the receiving node validates the integrity of bundle and performs authentication of forwarder (source or intermediate forwarder)... What benefits we get from this process ? What level of trust we have to assume ? ... This security feature can only provide integrity of data and nothing more than that ? If a malicious node can sign the bundle and forward it, then the forwarder can verify the integrity but, still it will forward... In short, What are the assumptions on which BSP works ? .. many thanks.. kind regards, Shoaib ------=_NextPart_001_00B9_01CBC444.CB46DBF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The hop-by-hop authentication is designed to keep ‘bogus’ = traffic out of the network by providing a mechanism to prevent = un-authenticated sources from injecting it.  Hop-by-hop security = assumes that the appropriate keys and policy are in the network.  = You’re right in that *if* a malicious node can forge a = signature for a bundle and inject it into the network, then after the = first hop there’s nothing in the BAB machinery to restrict that = bundle’s movement (though other security policies that use = non-single-hop mechanisms like the payload security block might be in = place).

 

The notion was that some networks may have very constrained, = expensive, or critical links and that it would be desirable to deter = someone who could connect to the network from being able to inject = traffic that would cross those links, consuming resources.  = End-to-end security like IPSec doesn’t do this, e.g., because the = traffic isn’t thrown away until the destination (after it’s = consumed resources on the critical link(s)).

 

           &nbs= p;            = ;        = --keith

 

From:= = dtn-security-bounces@maillists.intel-research.net = [mailto:dtn-security-bounces@maillists.intel-research.net] On Behalf = Of Shoaib Malik
Sent: Friday, February 04, 2011 6:27 = AM
To: dtn-security@maillists.intel-research.net
Cc: = dtn-interest@maillists.intel-research.net
Subject: = [dtn-security] hop-by-hop authentication

 

Hi = All, 

I have a question about the hop-by-hop = authentication in BSP.. 

 

On each hop, the receiving = node validates the integrity of bundle and performs authentication of = forwarder (source or intermediate forwarder)... What benefits we get = from this process ? What level of trust we have to assume ? ... This = security feature can only provide integrity of data and nothing more = than that ? 

If a malicious node can sign the bundle and = forward it, then the forwarder can verify the integrity but, still it = will forward... 

 

In short, What are the = assumptions on which BSP works ? .. 

 

many = thanks.. 

 

kind = regards,

Shoaib

------=_NextPart_001_00B9_01CBC444.CB46DBF0-- ------=_NextPart_000_00B8_01CBC444.CB46DBF0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKtjCCA2Iw ggJKoAMCAQICAjaOMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMDkxMjA0MTIwNzE5WhcNMTEwNTI4MTIwNzE5WjBWMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEWMBQGCgmSJomT8ixkAQETBmtzY290dDEXMBUGA1UEAxMO U2NvdHQgS2VpdGggTC4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJQWehfO+W0A21I8sjg8 6n2E2JIs1nUbSYuSBTDUv2eUi2ubxA+ZcAFl7ThAsFwIKecWjKG1XkEoty0IYRavVwY/7iq93MuC CKvKP9AhgzU0aENaPu/d7Ch6tDda1EfklYAVXTGmvIor8Q1mAlqAtT76xwscNEJkcPHA4myTUMJb AgMBAAGjgbYwgbMwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQWBBSu9OuFWRi/9KVTm3I4y3KXBakg +jAfBgNVHSMEGDAWgBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRw Oi8vd3d3Lm1pdHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwGwYDVR0RBBQw EoEQa3Njb3R0QG1pdHJlLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAWfSQ+S85S0IlonyNhXRT7/Zj ms5MVzbH7fzU6gI7ByqamE/4X42/OoV39PRSt6mU12QJX7n9JdoqTVoj20UlL4OKwqaC/97kJSVY +tbn/z3vdqz7VwkcrzPSL5yj8BbTle3NVVLmFuUHaLDI4Zow0sz9ce5dxi5DzhQ1/YR9u+QzcsA0 GppavJwOgvfa6qbOG6nopX/HN9RGb+yhZ6MdMLcRPg3XGs/7p/63ee2OYvNNFR8REb6zXSj4mzXs 1NMBmaAFRqNKLVZBQAFJW1Lc3/Fl/n5a1ZpyrX7Vj7Qx7k68m+XIh0YLiQTgQqH8Z47hmofEwsVb 2Qq0hhMgbwIFDjCCA2QwggJMoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwWjESMBAGA1UEChMJbWl0 cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJDAiBgNVBAMTG01JVFJFIENv cnBvcmF0aW9uIFJvb3QgQ0EtMTAeFw0wNjA2MDEwNDAwMDBaFw0xODA2MDEwNDAwMDBaMFoxEjAQ BgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQwIgYDVQQD ExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCva1qWPZiEJv5vMtCbjt0cTu0Nbn15Q1cKqQBXKi8VSH9zZPmPxfWizJJ7JSqFJ5/sLUz3 NsnUVjpLYBdFcxNXnOLjXtmDPFOewm5T98NZc9wRRCiDzt4f8qsHFI19ShPiK3cN5UqtJf+i66QV LA1S6CNL6o2eGAsAl5WnxwOh2BfcWU5fNlHDVc9KKAlDDWpHjC2LLHAUbLP4ZzMIJKcLgLKFMtgM 2AEfaSHzmi7WUdUHRCtCblrF7qzPsy/jBLFrr8VcX+mb7saq95pEOilgcix0/naW7kJfM5ph7UBB +S1O/OhH+ZjQ4MjWnwE8A/YDrQx1OVLAOi29Bsho/l8lAgMBAAGjNTAzMBIGA1UdEwEB/wQIMAYB Af8CAQMwHQYDVR0OBBYEFMdwUQDYTf7kAdRolsU9n5qX/nQvMA0GCSqGSIb3DQEBBQUAA4IBAQAa +fVfCljimBlcfWwkfJXuXNKWun9xloFKjnq6SPGgAIKi5LUDil60a0NaNGoGSO3I1xzYt7ncayh2 1qXulcVTDFqubSJdv51aHTuJYcYUX72LN/gSq03UVLBCJzYm7ZLUlkb2YLo7xUeZ3coLFcT5AHR3 6kjG4cYHqXgH0liBl8jxpN0gwgaci4sgPLUj1w4t8zoKH+zxGFwXwTP/P+etQqiJZ5T00fLLm5kz 9mmnxxmmIvUGNdsCAhGhdnF24pcrR43LNgyOBJ9DPUHBNq3kUQRO48WBKxBxflOtKzsICx/HEtIA BcZn7deADHcY9spULZfBnQYdEpyz5tgh7Y2qMIID5DCCAsygAwIBAgIBBTANBgkqhkiG9w0BAQUF ADBaMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEk MCIGA1UEAxMbTUlUUkUgQ29ycG9yYXRpb24gUm9vdCBDQS0xMB4XDTA2MDYwMzE3MTMyMloXDTEy MDYwMzE3MTMyMlowXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBB dXRob3JpdHkxJzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMjwe1ZdEIKoELdLvENnbkbO3mVD54ZX5SjxTzFxhvoq hqSJmLOp32xT7J9KvBapJRbJv1BFdiSUN3O0q8H66nvQqwm1RYe+tTsWSO351FolGrDT9iDRtfWg H60PCKCbABLRsx3iGnEvjOQjeAtMn1AugqQWU3PWZXYy1Grbya+NOytYvu1p60bDFSoSAn4Jojv1 4lUfWHl8s3kahay8umLSQibiXdEEX8CrSkaXpOaFOuyM6+wpRw7TybO1Dk4zGAUtn0887QvsMDk6 evgN2WxMprkHAGUcJhpI1QXtkfDIl9ukdNiIoM/vdN2QC/+m6b8dA55K5UdlBa9SgRnwapkCAwEA AaOBsTCBrjASBgNVHRMBAf8ECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUh7QP SI1iM0LBLVEaSB7CnrsKsa0wHwYDVR0jBBgwFoAUx3BRANhN/uQB1GiWxT2fmpf+dC8wSAYDVR0f BEEwPzA9oDugOYY3aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL3Jvb3RjYTFfbWl0 cmVfb3JnLmNybDANBgkqhkiG9w0BAQUFAAOCAQEATW5u664p7N0iAj27Xl/akjdfkSQpaosf6cNy AHu7utCytFfY1WfRNmvnNDGYkqI3XMFOa18SNjiNsMCH+sFQaO+oyDnPiIkEZQvlfGGrRpqIm6j/ /Fgz85bnf1kAM5I61Np7ofCnciRvp9ZB/+u+9i262tgiJPJrvBcqXmgeT9riCc3RPjxqPNmYslOv NLpIifchelJhF7nIge+7RkAUcTJenj8yKwK0J3+PEpgYRQ+V2C62rnjohuxPgMw/fYoNTOlh3MVl 7adwyK1ahPw2a9eOjSWglqoPTaBNeHJqRJZZ6Vi7S55+VAWCfkAqM5m3tUiVzjsp2dFcTJxnYeza oDGCAr0wggK5AgEBMGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0 ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICNo4w CQYFKw4DAhoFAKCCAbAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTEwMjA0MTMyMzI1WjAjBgkqhkiG9w0BCQQxFgQUjTV9+3fCWQ+irDolz8BmpLoFfFcwZwYJKoZI hvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwcgYJKwYBBAGCNxAEMWUw YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEn MCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgI2jjB0BgsqhkiG9w0BCRAC CzFloGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3Jp dHkxJzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICNo4wDQYJKoZIhvcN AQEBBQAEgYByOprwkyCo2rBuKn2QYNEor7IFyZaXWEwocc20hyyLCJHnLTPDt8Q91/sbjNVDSxQ+ J0cZS60p27yRAzQIE5kXArCh04w0BU3hD3Y804vsfuBc4sHWjQkRTDDRm2GXVtiPhz7yokBYT+Th H4ihAs0mn9ub72kcwUczBGjXCX+M1gAAAAAAAA== ------=_NextPart_000_00B8_01CBC444.CB46DBF0-- Received: from mail-fx0-f41.google.com (mail-fx0-f41.google.com [209.85.161.41]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id p14BQUs9027413; Fri, 4 Feb 2011 03:26:30 -0800 Received: by fxm12 with SMTP id 12so2207786fxm.28 for ; Fri, 04 Feb 2011 03:26:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.247.15 with SMTP id z15mr7326699mur.56.1296818790917; Fri, 04 Feb 2011 03:26:30 -0800 (PST) Received: by 10.103.223.11 with HTTP; Fri, 4 Feb 2011 03:26:30 -0800 (PST) Date: Fri, 4 Feb 2011 11:26:30 +0000 Message-ID: From: Shoaib Malik To: dtn-security@maillists.intel-research.net Content-Type: multipart/alternative; boundary=0016364c43ed5ee7b4049b73276f Cc: dtn-interest@maillists.intel-research.net Subject: [dtn-security] hop-by-hop authentication X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 11:26:31 -0000 --0016364c43ed5ee7b4049b73276f Content-Type: text/plain; charset=ISO-8859-1 Hi All, I have a question about the hop-by-hop authentication in BSP.. On each hop, the receiving node validates the integrity of bundle and performs authentication of forwarder (source or intermediate forwarder)... What benefits we get from this process ? What level of trust we have to assume ? ... This security feature can only provide integrity of data and nothing more than that ? If a malicious node can sign the bundle and forward it, then the forwarder can verify the integrity but, still it will forward... In short, What are the assumptions on which BSP works ? .. many thanks.. kind regards, Shoaib --0016364c43ed5ee7b4049b73276f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi All,=A0
I have a question about the hop-by-hop authentication in BSP= ..=A0

On each hop, the receiving node validates th= e integrity of bundle and performs authentication of forwarder (source or i= ntermediate forwarder)... What benefits we get from this process ? What lev= el of trust we have to assume ? ... This security feature can only provide = integrity of data and nothing more than that ?=A0
If a malicious node can sign the bundle and forward it, then the forwa= rder can verify the integrity but, still it will forward...=A0
In short, What are the assumptions on which BSP works ? ..=A0<= /div>

many thanks..=A0

kind regards,=
Shoaib
--0016364c43ed5ee7b4049b73276f-- Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id p14ASMm5024457; Fri, 4 Feb 2011 02:28:23 -0800 Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B6A133E407E; Fri, 4 Feb 2011 10:28:23 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id ucY7nYRMLlGN; Fri, 4 Feb 2011 10:28:23 +0000 (GMT) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 175403E407C; Fri, 4 Feb 2011 10:28:22 +0000 (GMT) Message-ID: <4D4BD4C6.3040900@cs.tcd.ie> Date: Fri, 04 Feb 2011 10:28:22 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: DTN , DTN Security Discussion , "dtn-users@maillists.intel-research.net" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dtn-security] Migrating mailing list and wiki X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 10:28:23 -0000 Hi all, Due to some machine changes with the current infrastructure we're planning to migrate the DTNRG related lists (dtn-interest, dtn-security and dtn-users) to the IETF/IRTF infrastructure in the next few weeks. That'll mean you'll need to change filters etc. but everything else should be the same. We're also planning to move the wiki, which, all going well, should just result in a little downtime. Once we're all set, we'll send another mail with the final details. If there're any issues with the above please mail Kevin and I, and also cc Alex McMahon (alex.mcmahon@cs.tcd.ie) who'll be doing most of the real work involved. Regards, Stephen. Received: from HUB0.engr.sc.edu (hub0.engr.sc.edu [129.252.21.22]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id p13Ekqa9010255; Thu, 3 Feb 2011 06:46:53 -0800 Received: from MAIL.engr.sc.edu ([129.252.21.20]) by HUB0.engr.sc.edu ([129.252.21.22]) with mapi; Thu, 3 Feb 2011 09:46:54 -0500 From: "HUANG, CHIN-TSER" To: "dtn-security@maillists.intel-research.net" Date: Thu, 3 Feb 2011 09:42:14 -0500 Thread-Topic: [dtn-security] Security for DTN Thread-Index: AcvDE/Y1YQuFm7WLRfeVVayF84lWVQAnJaxq Message-ID: <037FDAC816CE034CAB1AD5F7321B32E301D0679BDF06@MAIL.engr.sc.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id p13Ekqa9010255 Cc: "dtn-interest@maillists.intel-research.net" Subject: Re: [dtn-security] Security for DTN X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 14:46:53 -0000 Hi Shoaib, Your assumptions, from the starting point, are confusing. First, if you are talking about physical confidentiality, it's always possible that N1, S, and perhaps another node N2, are all within each other's radio range at one moment. In this case, what do you mean by saying "there exists a confidential channel between N1 and S"? The transmission between N1 and S is also open to N2. Second, if you are talking about communication confidentiality, there cannot be any confidentiality of the message contents unless they have pre-established shared secret for encryption purpose, or they set up a shared secret on demand. But what's your assumption on that? My suggestion is that you think about these fundamental issues first before you proceed. Hope it helps and good luck, Chin-Tser -- Chin-Tser Huang Associate Professor Department of Computer Science and Engineering University of South Carolina Columbia, SC 29208 +1-803-777-4635 voice +1-803-777-3767 fax ________________________________________ From: dtn-security-bounces@maillists.intel-research.net [dtn-security-bounces@maillists.intel-research.net] On Behalf Of Shoaib Malik [shoaibmalik1981@gmail.com] Sent: Wednesday, February 02, 2011 3:00 PM To: dtn-security@maillists.intel-research.net Cc: dtn-interest@maillists.intel-research.net Subject: [dtn-security] Security for DTN hi, I am working on a secure DTN network. In the DTN network, Suppose a node, say N1, opportunistically becomes available to any other already existing node S, then at that time can we assume that there exist a confidential channel between N1 and S. In general, "Can we assume that there exist a confidential channel between each hop nodes, in a multi hop network". Is taking this assumption good or bad while working on security for DTN. regards, Shoaib Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id p13De0gj006804; Thu, 3 Feb 2011 05:40:00 -0800 Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 6B05BA8061; Thu, 3 Feb 2011 07:40:01 -0600 (CST) Received: from ndjshub05.ndc.nasa.gov (ndjshub05.ndc.nasa.gov [198.117.4.164]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id p13De1Yt020672; Thu, 3 Feb 2011 07:40:01 -0600 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub05.ndc.nasa.gov ([198.117.4.164]) with mapi; Thu, 3 Feb 2011 07:40:01 -0600 From: "Ivancic, William D. (GRC-RHN0)" To: Shoaib Malik Date: Thu, 3 Feb 2011 07:40:00 -0600 Thread-Topic: [dtn-security] Security for DTN Thread-Index: AcvDp9sNCfGXKlOZSem60A1pT20QRA== Message-ID: <0B27E624-2CD5-402D-97A1-243040983F0E@nasa.gov> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-02-03_06:2011-02-03, 2011-02-03, 1970-01-01 signatures=0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id p13De0gj006804 Cc: "dtn-security@maillists.intel-research.net" , "dtn-interest@maillists.intel-research.net" Subject: Re: [dtn-security] Security for DTN X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 13:40:00 -0000 Shoaib, >From the question, I believe you are new to network security. It is a painful subject that many do not understand well - at least in practical deployments. DTN is a network overlay. So, you have the security, or lack of security on each of the underlying networks (convergence layers) which may include IPv4, IPv6, CCSDS (google it), bluetooth, thumb drive policy, radio link security etcetera. In addition, you have DTN security. You can assume nothing on any of these links. DTN bundle authentication(between hop security) requires some type of policy configuration and most often, a shared key. Key distribution has not yet been addressed, nor has there been much work in policy. The best way to understand the above is to setup a four hop network and attempt to secure it. Assuming you are working on an IP network, if you have never setup IPsec, I suggest starting there. Secure the IP and wireless and then do the DTN. It will be difficult, but easier to learn the IP network and the concepts with translate to DTN. I suggest keeping the network fully connected to start. Once you get everything working, you can add disconnection. At which point you may decide to turn off IPsec as much of that may break. This is a lot of work, but when you are done, you will have a fairly decent understanding of security and why it is difficult to deploy in multi-organizational networks. Note, the vast amount of DTN research to date in the open community has been performed without security. - Will On Feb 2, 2011, at 3:00 PM, Shoaib Malik wrote: > hi, > I am working on a secure DTN network. > > In the DTN network, Suppose a node, say N1, opportunistically becomes available to any other already existing node S, then at that time can we assume that there exist a confidential channel between N1 and S. > In general, "Can we assume that there exist a confidential channel between each hop nodes, in a multi hop network". > > Is taking this assumption good or bad while working on security for DTN. > > regards, > Shoaib > _______________________________________________ > dtn-security mailing list > dtn-security@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-security ****************************** William D. Ivancic Phone 216-433-3494 Fax 216-433-8705 Networking Lab 216-433-2620 DTN Lab 216-433-2981 Mobile 440-503-4892 http://roland.grc.nasa.gov/~ivancic Received: from asmtpout016.mac.com (asmtpout016.mac.com [17.148.16.91]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id p12M4ocu024020; Wed, 2 Feb 2011 14:04:50 -0800 MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Received: from [192.168.1.98] (pool-71-178-36-205.washdc.fios.verizon.net [71.178.36.205]) by asmtp016.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LG0002TSG01NO00@asmtp016.mac.com>; Wed, 02 Feb 2011 14:04:51 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-02-02_09:2011-02-02, 2011-02-02, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1102020179 From: Peter Lovell To: Shoaib Malik , dtn-security@maillists.intel-research.net Date: Wed, 02 Feb 2011 17:04:48 -0500 Message-id: <20110202220448.1935347185@smtp.mac.com> In-reply-to: References: X-Mailer: CTM PowerMail version 6.0.6 build 4630 English (intel) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id p12M4ocu024020 Cc: dtn-interest@maillists.intel-research.net Subject: Re: [dtn-security] Security for DTN X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 22:04:50 -0000 On Wed, Feb 2, 2011, Shoaib Malik wrote: >hi,  >I am working on a secure DTN network.  > >In the DTN network, Suppose a node, say N1, opportunistically becomes >available to any other already existing node S, then at that time can we >assume that there exist a confidential channel between N1 and S.  >In general, "Can we assume that there exist a confidential channel >between each hop nodes, in a multi hop network".  > >Is taking this assumption good or bad while working on security for DTN.  > >regards, >Shoaib HI Shoaib, you can't assume that any particular node implements the security protocol, or any particular ciphersuite. There is no "automatic" confidential or secure channel - it depends entirely upon the deployment. Regards.....Peter Received: from mail-gx0-f169.google.com (mail-gx0-f169.google.com [209.85.161.169]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id p12KKEcN018617; Wed, 2 Feb 2011 12:20:14 -0800 Received: by gxk5 with SMTP id 5so171792gxk.28 for ; Wed, 02 Feb 2011 12:20:16 -0800 (PST) Received: by 10.100.201.6 with SMTP id y6mr5963477anf.1.1296678016288; Wed, 02 Feb 2011 12:20:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.120.12 with HTTP; Wed, 2 Feb 2011 12:19:56 -0800 (PST) In-Reply-To: References: From: Rohit Date: Wed, 2 Feb 2011 15:19:56 -0500 Message-ID: To: Shoaib Malik Content-Type: multipart/alternative; boundary=0016368e1aa18c86fa049b526073 Cc: dtn-security@maillists.intel-research.net, dtn-interest@maillists.intel-research.net Subject: Re: [dtn-security] [dtn-interest] Security for DTN X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 20:20:14 -0000 --0016368e1aa18c86fa049b526073 Content-Type: text/plain; charset=ISO-8859-1 We can consider it as initial secure-context establishment problem. I have recently come across a paper related to this topic. check the link below... http://www.ics.uci.edu/~jsolis/publications/dtn_compsac09.pdf I think the question you raised by itself is a problem to address. So taking it as an assumption really depends on the problem you are trying to address. I am completely new to security in DTN. There are lot of experts in this mailing list, who can give you better suggestion. Regards, Rohit Mullangi, Graduate Student, The University of Georgia, Athens GA. On Wed, Feb 2, 2011 at 3:00 PM, Shoaib Malik wrote: > hi, > I am working on a secure DTN network. > > In the DTN network, Suppose a node, say N1, opportunistically becomes > available to any other already existing node S, then at that time can we > assume that there exist a confidential channel between N1 and S. > In general, "Can we assume that there exist a confidential channel between > each hop nodes, in a multi hop network". > > Is taking this assumption good or bad while working on security for DTN. > > regards, > Shoaib > > _______________________________________________ > dtn-interest mailing list > dtn-interest@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-interest > > --0016368e1aa18c86fa049b526073 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We can consider it as initial secure-context establishment problem. I have = recently come across a paper related to this topic. check the link below...= =A0


I think the question you raised by itself is a probl= em to address. So taking it as an assumption really depends on the problem = you are trying to address.

I am=A0completely=A0new to security in DTN. There are l= ot of experts in this mailing list, who can give you better suggestion.

Regards,
Rohit Mullangi,
Graduate= Student,
The University of Georgia,
Athens GA.


On Wed, Feb 2, 2011 at 3:00 PM, Shoaib Malik <shoaibmalik1981= @gmail.com> wrote:
hi,=A0
I am working on a sec= ure DTN network.=A0

In the DTN network, Suppose a node,= say N1, opportunistically becomes available to any other already existing = node S, then at that time can we assume that there exist a confidential cha= nnel between N1 and S.=A0
In general, "Can we assume that there exist a confidential channel bet= ween each hop nodes, in a multi hop network".=A0

<= div>Is taking this assumption good or bad while working on security for DTN= .=A0

regards,
Shoaib

_______________________________________________
dtn-interest mailing list
dtn-interest@m= aillists.intel-research.net
http://maillists.intel-research.net/mailman/listinfo/d= tn-interest


--0016368e1aa18c86fa049b526073-- Received: from mail-ew0-f41.google.com (mail-ew0-f41.google.com [209.85.215.41]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id p12K0Vdv017575; Wed, 2 Feb 2011 12:00:31 -0800 Received: by ewy27 with SMTP id 27so292711ewy.28 for ; Wed, 02 Feb 2011 12:00:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.102.244.3 with SMTP id r3mr5102876muh.128.1296676832616; Wed, 02 Feb 2011 12:00:32 -0800 (PST) Received: by 10.103.223.11 with HTTP; Wed, 2 Feb 2011 12:00:32 -0800 (PST) Date: Wed, 2 Feb 2011 20:00:32 +0000 Message-ID: From: Shoaib Malik To: dtn-security@maillists.intel-research.net Content-Type: multipart/alternative; boundary=0016e649d994ff24c4049b5219e1 Cc: dtn-interest@maillists.intel-research.net Subject: [dtn-security] Security for DTN X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 20:00:32 -0000 --0016e649d994ff24c4049b5219e1 Content-Type: text/plain; charset=ISO-8859-1 hi, I am working on a secure DTN network. In the DTN network, Suppose a node, say N1, opportunistically becomes available to any other already existing node S, then at that time can we assume that there exist a confidential channel between N1 and S. In general, "Can we assume that there exist a confidential channel between each hop nodes, in a multi hop network". Is taking this assumption good or bad while working on security for DTN. regards, Shoaib --0016e649d994ff24c4049b5219e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi,=A0
I am working on a secure DTN network.=A0
In the DTN network, Suppose a node, say N1, opportunistically becom= es available to any other already existing node S, then at that time can we= assume that there exist a confidential channel between N1 and S.=A0
In general, "Can we assume that there exist a confidential channel bet= ween each hop nodes, in a multi hop network".=A0

<= div>Is taking this assumption good or bad while working on security for DTN= .=A0

regards,
Shoaib
--0016e649d994ff24c4049b5219e1--