From nobody Fri Aug 1 06:08:55 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C931A0AFF for ; Fri, 1 Aug 2014 06:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vencyVTx_FFD for ; Fri, 1 Aug 2014 06:08:48 -0700 (PDT) Received: from mailscan1.extendcp.co.uk (mailscan21.extendcp.co.uk [176.32.226.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8C4C1A0383 for ; Fri, 1 Aug 2014 06:08:47 -0700 (PDT) Received: from lb1.hi.local ([10.0.1.197] helo=mailscan2.extendcp.co.uk) by mailscan-g67.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1XDCZi-0002tq-Cs for ace@ietf.org; Fri, 01 Aug 2014 14:08:46 +0100 Received: from lb1.hi.local ([10.0.1.197] helo=mail41.extendcp.co.uk) by mailscan2.extendcp.co.uk with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1XDCZf-0007b4-PK for ace@ietf.org; Fri, 01 Aug 2014 14:08:46 +0100 Received: from host86-177-71-244.range86-177.btcentralplus.com ([86.177.71.244] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1XDCZe-0004zs-V9 for ace@ietf.org; Fri, 01 Aug 2014 14:08:43 +0100 Message-ID: <53DB9156.5090200@gridmerge.com> Date: Fri, 01 Aug 2014 14:08:38 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: ace@ietf.org References: <53CD27D3.1010709@gmx.net> <53DB12A2.90209@gmail.com> In-Reply-To: <53DB12A2.90209@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090207090602090802040108" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: http://mailarchive.ietf.org/arch/msg/ace/WdlaPQ7JHAMcZCBtiqheQ2fBss0 Subject: Re: [Ace] Call for adoption on draft-seitz-ace-usecases-01 ("ACE Use Cases") X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 13:08:53 -0000 This is a cryptographically signed message in MIME format. --------------ms090207090602090802040108 Content-Type: multipart/alternative; boundary="------------010102020806020805000109" This is a multi-part message in MIME format. --------------010102020806020805000109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Rene, I think you're missing the point of use cases. A use case is a depiction = of a real world scenario. What you describe below are the models and=20 patterns which can be interpreted from use cases. That is separate and=20 should be treated as such. Therefore I do support adoption of the document but I do also think=20 there is value in trying to solicit a larger and wider set of use cases=20 to add to the document, focusing on e.g, "bananas" as opposed to "devices= ". Robert On 01/08/2014 5:08 AM, Rene Struik wrote: > Dear colleagues: > > I participated in the ACE discussions in Toronto last week, read=20 > draft-seitz-ace-usecases-01, and saw the email discussions that ensued = > since the meeting. > > Unfortunately, I cannot support adopting the use case draft in its=20 > current form. > > I think it is far from ready to be a fruitful base for incremental=20 > improvements as a WG document. Moreover, there seems to be quite some=20 > disagreement as to whether certain use cases (discussed on the mailing = > list over the last few days, but mostly not in the draft) are=20 > considered inside scope of this working group. > > We should not simply adopt a draft, just because it is there. It also=20 > should have sufficient merit to have a chance progressing to an=20 > informational RFC or document that otherwise would guide the=20 > development of an authorization and authentication solution as a=20 > proposed standard. Right now, I feel it does not have these qualities. > > I would provide a more succinct description of use cases that capture=20 > security-relevant events, including the following: > 1) change of network composition: new kid on the block; temporary=20 > (repair) or permanently (disposed) decommissioned device; temporary or = > permanent network union, resp. partitioning; > 2) change of roles of devices: new role assigned to device; role=20 > retracted from device; assignment of meta-roles and retraction hereof; = > roles based on global policies, resp. local decisions; > 3) initialization or roles of devices and evolution hereof during=20 > lifecycle of devices and networks, all the way from conception (e.g.,=20 > chip manufacturing) to system integration, etc. (e.g., change of=20 > ownership/control, logical/procedural transfer operation), to=20 > operational use, replacement, disposition. > > I would also go into more details as to what might be different with=20 > constrained networks. Simply allocating a single third-party device to = > do arbitrage may not do the job, since delegation of computational or=20 > storage cost may be offset by communication cost, energy consumption,=20 > and denial of service risk. One should support both peer-to-peer=20 > (localized) and outsourced ("cloud based", if one wishes) scenarios. > > I would also pay lots of attention to distinction between homogeneous=20 > and heterogeneous trust domain scenarios. After all, one should=20 > facilitate "mix and match" scenarios, where devices may be procured=20 > from multiple vendors, that may not know each other and, even if they=20 > would, not trust each other. Having any presumption that manufacturers = > should do secret handshakes for their devices to be able to=20 > communicate securely may hamper significantly deployment in ease of=20 > use manner and never bring the full potential of internet of things=20 > forward. Moreover, it could stifle innovation, since baking in=20 > pre-established relationships may force the hand of contractual=20 > parties in favor of vested interests and the bigger party. > > Use cases should focus on both consumer and non-consumer style=20 > scenarios and include, industrial control, critical infrastructure,=20 > etc. I am happy to contribute to use cases that incorporate the above=20 > feedback and that borrow from experience gained in discussions with=20 > industrial control and other wireless sensor standardization groups,=20 > covering both security, ease of use, and ease of deployment and=20 > provisioning, over the last 5-10 years. > > Lastly, it would be good to take the viewpoint as to what=20 > functionalities are required and emphasize slghtly less those=20 > constraints that may become less of an issue over time (e.g., those in = > the digital vs. the analog domain). As we heard during the ACE session = > in Toronto, lots of crypto can be considered (or can soon be=20 > considered) a commodity for low-hanging fruit applications one may=20 > wish to target. > > What is needed in the end is a design incorporating the right type of=20 > crypto primitives and protocols and a language that expresses device=20 > roles and meta-roles that can be conveyed over the air. Design then=20 > centers around which crypto, which protocols, which roles, how to=20 > express things, which granularity, etc. This would, of course, be part = > of the design of the solution and not part of the use cases, but=20 > certainly relates to requirements (if one wishes to tie this in with=20 > use cases). > > Best regards, Rene > > On 7/21/2014 10:46 AM, Hannes Tschofenig wrote: >> Hi all, >> >> we have a milestone for a use case document in ACe and >> draft-seitz-ace-usecases is a promising candidate for this milestone. >> >> This email is a call for adoption for draft-seitz-ace-usecases-01. >> >> Please respond if you support, or object to, the adoption of this >> document as the basis for this work item. Deadline for your response: >> 31. July 2014 >> >> Ciao >> Hannes & Kepeng >> >> >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace > > > --=20 > email:rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --------------010102020806020805000109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Rene,

I think you're missing the point of use cases. A use case is a depiction of a real world scenario. What you describe below are the models and patterns which can be interpreted from use cases. That is separate and should be treated as such.

Therefore I do support adoption of the document but I do also think there is value in trying to solicit a larger and wider set of use cases to add to the document, focusing on e.g, "bananas" as opposed to "devices".

Robert

On 01/08/2014 5:08 AM, Rene Struik wrote:
Dear colleagues:

I participated in the ACE discussions in Toronto last week, read draft-seitz-ace-usecases-01, and saw the email discussions that ensued since the meeting.

Unfortunately, I cannot support adopting the use case draft in its current form.

I think it is far from ready to be a fruitful base for incremental improvements as a WG document. Moreover, there seems to be quite some disagreement as to whether certain use cases (discussed on the mailing list over the last few days, but mostly not in the draft) are considered inside scope of this working group.

We should not simply adopt a draft, just because it is there. It also should have sufficient merit to have a chance progressing to an informational RFC or document that otherwise would guide the development of an authorization and authentication solution as a proposed standard. Right now, I feel it does not have these qualities.

I would provide a more succinct description of use cases that capture security-relevant events, including the following:
1) change of network composition: new kid on the block; temporary (repair) or permanently (disposed) decommissioned device; temporary or permanent network union, resp. partitioning;
2) change of roles of devices: new role assigned to device; role retracted from device; assignment of meta-roles and retraction hereof; roles based on global policies, resp. local decisions; 3) initialization or roles of devices and evolution hereof during lifecycle of devices and networks, all the way from conception (e.g., chip manufacturing) to system integration, etc. (e.g., change of ownership/control, logical/procedural transfer operation), to operational use, replacement, disposition.

I would also go into more details as to what might be different with constrained networks. Simply allocating a single third-party device to do arbitrage may not do the job, since delegation of computational or storage cost may be offset by communication cost, energy consumption, and denial of service risk. One should support both peer-to-peer (localized) and outsourced ("cloud based", if one wishes) scenarios.

I would also pay lots of attention to distinction between homogeneous and heterogeneous trust domain scenarios. After all, one should facilitate "mix and match" scenarios, where devices may be procured from multiple vendors, that may not know each other and, even if they would, not trust each other. Having any presumption that manufacturers should do secret handshakes for their devices to be able to communicate securely may hamper significantly deployment in ease of use manner and never bring the full potential of internet of things forward. Moreover, it could stifle innovation, since baking in pre-established relationships may force the hand of contractual parties in favor of vested interests and the bigger party.

Use cases should focus on both consumer and non-consumer style scenarios and include, industrial control, critical infrastructure, etc. I am happy to contribute to use cases that incorporate the above feedback and that borrow from experience gained in discussions with industrial control and other wireless sensor standardization groups, covering both security, ease of use, and ease of deployment and provisioning, over the last 5-10 years.

Lastly, it would be good to take the viewpoint as to what functionalities are required and emphasize slghtly less those constraints that may become less of an issue over time (e.g., those in the digital vs. the analog domain). As we heard during the ACE session in Toronto, lots of crypto can be considered (or can soon be considered) a commodity for low-hanging fruit applications one may wish to target.

What is needed in the end is a design incorporating the right type of crypto primitives and protocols and a language that expresses device roles and meta-roles that can be conveyed over the air. Design then centers around which crypto, which protocols, which roles, how to express things, which granularity, etc. This would, of course, be part of the design of the solution and not part of the use cases, but certainly relates to requirements (if one wishes to tie this in with use cases).

Best regards, Rene

On 7/21/2014 10:46 AM, Hannes Tschofenig wrote:
Hi all,

we have a milestone for a use case document in ACe and
draft-seitz-ace-usecases is a promising candidate for this milestone.

This email is a call for adoption for draft-seitz-ace-usecases-01.

Please respond if you support, or object to, the adoption of this
document as the basis for this work item. Deadline for your response:
31. July 2014

Ciao
Hannes & Kepeng




_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listin=
fo/ace



--=20
email: rstruik.ext@gmail.com | Skype: rst=
ruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


_______________________________________________
Ace mailing list
Ace@ie=
tf.org
https://www.ietf.org/mailman/listinfo/ace

--------------010102020806020805000109-- --------------ms090207090602090802040108 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNDA4MDExMzA4MzhaMCMGCSqGSIb3DQEJBDEWBBTAf6WoBlrNYIqTYEncjEdVHuxPHDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAJ9AKS5MTlT+BFwWRqBa30jFJ3kLqf/WGXNz1dfJwBaAwMjh PlaD/mVyDoJsji3oz8j86gPQOWrYdKMi5KYbzdyV6wKHxtUVYu9Xou6aXw66IY2gFfjoYjt5 rc5/2fOB+7xL3K79XVMZBFaN8gNpJsdNUJvVjmxig+FhrkTA0zkq9N37oz9szTFevdPxwuLi gX0GtgLv5NywpD7Lb3UWmSF0ty7OcV6Ck9bMNschadgZtQPV6mMfTZ2AxXIpNbHaSXsWbLGM 3OuvhBvfY3a6VjHbVeXeWpuxrxhtNCgGA3+WY6zpTgIfolJt9hrSUTE6WaBj++Lg1WriiCzR PzI0h9wAAAAAAAA= --------------ms090207090602090802040108-- From nobody Fri Aug 1 06:21:02 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF4F1A8BB1 for ; Fri, 1 Aug 2014 06:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.653 X-Spam-Level: ** X-Spam-Status: No, score=2.653 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_06_12=1.543, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udcU8rMeCMMN for ; Fri, 1 Aug 2014 06:20:59 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF5B1A854D for ; Fri, 1 Aug 2014 06:20:59 -0700 (PDT) Received: from sandelman.ca (unknown [209.87.249.16]) by relay.sandelman.ca (Postfix) with ESMTPS id CC9D7220BD for ; Fri, 1 Aug 2014 09:20:58 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 50792CA0E3 for ; Fri, 1 Aug 2014 01:35:39 -0400 (EDT) From: Michael Richardson To: "ace\@ietf.org" In-reply-to: References: <516f38cfa4474c658ca133629a118250@BLUPR03MB309.namprd03.prod.outlook.com> <3194.1406753341@sandelman.ca> Comments: In-reply-to Carsten Bormann message dated "Thu, 31 Jul 2014 13:44:59 +0200." X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.4.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 01 Aug 2014 01:35:39 -0400 Message-ID: <14810.1406871339@sandelman.ca> Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ace/Vp4br0LOujFuisMKGRXToGalWrE Subject: Re: [Ace] Use Case draft X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 13:21:01 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable {at the risk of repeating myself and boring everyone} Carsten Bormann wrote: >>> 2) Secret provisioning is another important problem to >>> solve. Scenario is : I bring home my new thermostat and want to >>> associate it with my account, how is it paired? > ACE needs to enable this. (And it may want to work without requiring > the concept of =E2=80=9Caccount=E2=80=9D.) The initial method of pai= ring or whatever > is out of scope (being able to keep it here is one of the points of t= he > differentiation between AM and AS). My take is that the pairing of the thermostat with the AM is out of scope. Once paired, the process by which the AM helps the thermostat talk to the furnace or AC or your Mike's Wife's Phone (Henceforth: MWP) is in scope. >>> Later when I sell my house, how to I transfer ownership of the >>> thermostat? The most common pattern seems to >>=20 >> Out of scope for ACE at this time. > Ownership transfer is an important authorization use case. (The more > interesting question, how do you forcibly gain ownership for the > contents of a foreclosed home, is way out of scope, though.) On the day your house transfer closes, you arrange to disclose your keys (yes, your private house keys) to the new owner, probably via your lawyer. Probably these are the keys used by the AM/AS to talk to the constrained devices, not the ones on your phone. The new owner uses either the existi= ng AM/AS (after a factory default), or a replacement AM/AS to rekey the entire network, same as you would change the tumblers on your house. As for foreclosure, the banks will presumably want things escrowed to them, just as they insist that I have life insurance as a condition of my mortgage. (and will happily sell that to me if I'm stupid) >> See UCAN BOF. > I don=E2=80=99t think UCAN discusses ownership transfer. If there are certificates from manufacturer to owner as part of the network ownership claim that UCAN envisions, then ownership transfer amounts to adding another layer in a certificate chain. There are various ways to do this, with different properties. But, that relationship is about bootstrapping the C/AM pairing, and is out = of scope for ACE. >>> 2) If somebody sides a malicious "puck" device under my door, what >>> keeps it from joining the other things in the home and attacking the >>> house. > If the ACE protocols are not secure against this I have no idea > whatsoever what we are trying to do. (It=E2=80=99s not exactly a =E2= =80=9Cuse case=E2=80=9D in > the classical sense; maybe we should be explicit about misuse cases a= nd > threats in general.) There are three threats for the puck. 1) the puck successfully joins the network and tries to do things to existing devices. ACE is all about securing this. 2) the puck tries to join the network; but the network refuses. Not in scope for ACE. 3) the puck presents itself as the network to other (new?) devices, a= nd tries to get them to join it's network, possibly MiTM them. Also out of scope. >>> 3) If I have guests and I want to give control of some parts of my >>> home, how is that done? Use of proximity is one interesting idea I'= ve >>> heard here, if you are in my house you can turn lights on and off. > Again, ACE needs to enable this. The method of proximity/in-perimeter > detection is out of scope. If there is a proximity sensor, then it might act as a sort of RS, AS or AM, which may provide an ACE format ticket that indicates the C is proximate, and presenting this ticket to another RS (the light), might be enough to control it. The protocol by which the proximity sensor pairs with you (determines your proximity) is probably out of scope, the result of the pairing should be in scope. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJT2ycpAAoJEKD0KQ7Gj3P22h4IAJ1RRg+gvvF5D7n9VN+cbRrP 0DibaVHtkBrkbLM3Om2AiRGP9+ODwRUbgm2kiQJ0IV0gZuhrV2Z9V+wGAZIGRgrI mrU7B2R2S9QbUC47G56bYu0dnahmv4dTlZcJ1yjZG12HmHYcG5qLgb0PwGPARJgJ XwLa4DrgJwXHY+slI7nZQLGqVw1IfQ2FVDhwP+Hs5bnG5jrCGDy+1xWGcDZF+D/4 /P5NK0xsQsUJ/fObRQk5PtaEAwpd43AjdKJM80Xfw9C0awHh7BtD9/1C48duQGN2 ojLPzz+F9uboYkArfQCP3hyen10wA2UNduTnGDN4Dkfq8HlUzckddwNqGPshrpU= =S/tE -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 1 06:39:53 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE4D1ABB35 for ; Fri, 1 Aug 2014 06:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnDFnosMCmm5 for ; Fri, 1 Aug 2014 06:39:48 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF7E1A0024 for ; Fri, 1 Aug 2014 06:39:48 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id at20so5720152iec.8 for ; Fri, 01 Aug 2014 06:39:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=qE9j/RMy65bXXOKcFtrDacMSpOmbAkZ0j6+oPJeRqpo=; b=DKdGstu604CBxOh1/nJXinVqEkjnx5Or1rxk+FIRSIUIS/2glj42AcHbbqAKM5Dz0Z Jg9M6MoaYSpHpqQu6A9wR1U9xQ1rDxGLyFJlCyS4tib/+4FyYAnGcUx24wsHNOSxDVCq SRuLp0PbTIUT+D5kiA5Sf3HYL/TXcQEPkHEFv8BLu/g8RHYqzO+LrYe7RZ9/Xi05OJTG f6DA8JV2SEqhny8sQ7ehYuph+2N80SGUWEynHJlc80KIU5y8hp8RekmHowiL7AhFf6ub /EA8S3n78UM9tPFPiowq8fx+OTMp4v+PiCiJn6LNXvXnKAlE1xP+CC6gy2M7xd75aFLr zMLQ== X-Received: by 10.50.13.102 with SMTP id g6mr8008828igc.20.1406900387924; Fri, 01 Aug 2014 06:39:47 -0700 (PDT) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.118.107]) by mx.google.com with ESMTPSA id d4sm10376233igc.5.2014.08.01.06.39.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Aug 2014 06:39:47 -0700 (PDT) Message-ID: <53DB989E.3060006@gmail.com> Date: Fri, 01 Aug 2014 09:39:42 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: robert.cragie@gridmerge.com, ace@ietf.org References: <53CD27D3.1010709@gmx.net> <53DB12A2.90209@gmail.com> <53DB9156.5090200@gridmerge.com> In-Reply-To: <53DB9156.5090200@gridmerge.com> Content-Type: multipart/alternative; boundary="------------090801040601050600010109" Archived-At: http://mailarchive.ietf.org/arch/msg/ace/53vU55qoSz1KZQHNQgHQczwRqyM Subject: Re: [Ace] Call for adoption on draft-seitz-ace-usecases-01 ("ACE Use Cases") X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 13:39:52 -0000 This is a multi-part message in MIME format. --------------090801040601050600010109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Robert: Describing use case more abstractly than others does not suddenly make these no use cases (as you seem to suggest). See below, if this is more concrete to you. Ad #1) below: a) I want to be able to add a device to my network (new kid on the block); this can be temporarily (e.g., friend has access to printer while visiting, but not after) or permanently (add new stick-on-window temperature meter to home control system). b) I want to replace a malfunctioning device, e.g., pressure pump has to go to repair shop (temporary decommissioning) or ditch a broken one (permanent decommissioning); c) I have a complete subsystem (skid) I want to add to a network on an oil platform (union), resp. want to sell off a subsystem or logically split a network/system into two (partitioning). Ad #2) below: a) I want my remote control to control a new gadget (new role assigned to device); I want to remove the capability of this remote control (retract from device); b) etc., etc. The draft needs a major rewrite to accommodate this all in a succinct manner. Hence, my "no vote". Again, having a draft on the shelf does not by itself make it worthy of adoption as a WG document as is. {BTW - during the draft charter discussion, one of the co-editors, Steffi Gerdes, agreed with earlier suggestion to have use case draft milestone for adoption in December, see http://www.ietf.org/mail-archive/web/ace/current/msg00632.html. It was unclear why this was changed (it came out of the blue)} Rene == I would provide a more succinct description of use cases that capture security-relevant events, including the following: 1) change of network composition: new kid on the block; temporary (repair) or permanently (disposed) decommissioned device; temporary or permanent network union, resp. partitioning; 2) change of roles of devices: new role assigned to device; role retracted from device; assignment of meta-roles and retraction hereof; roles based on global policies, resp. local decisions; 3) initialization or roles of devices and evolution hereof during lifecycle of devices and networks, all the way from conception (e.g., chip manufacturing) to system integration, etc. (e.g., change of ownership/control, logical/procedural transfer operation), to operational use, replacement, disposition. On 8/1/2014 9:08 AM, Robert Cragie wrote: > Rene, > > I think you're missing the point of use cases. A use case is a > depiction of a real world scenario. What you describe below are the > models and patterns which can be interpreted from use cases. That is > separate and should be treated as such. > > Therefore I do support adoption of the document but I do also think > there is value in trying to solicit a larger and wider set of use > cases to add to the document, focusing on e.g, "bananas" as opposed to > "devices". > > Robert > > On 01/08/2014 5:08 AM, Rene Struik wrote: >> Dear colleagues: >> >> I participated in the ACE discussions in Toronto last week, read >> draft-seitz-ace-usecases-01, and saw the email discussions that >> ensued since the meeting. >> >> Unfortunately, I cannot support adopting the use case draft in its >> current form. >> >> I think it is far from ready to be a fruitful base for incremental >> improvements as a WG document. Moreover, there seems to be quite some >> disagreement as to whether certain use cases (discussed on the >> mailing list over the last few days, but mostly not in the draft) are >> considered inside scope of this working group. >> >> We should not simply adopt a draft, just because it is there. It also >> should have sufficient merit to have a chance progressing to an >> informational RFC or document that otherwise would guide the >> development of an authorization and authentication solution as a >> proposed standard. Right now, I feel it does not have these qualities. >> >> I would provide a more succinct description of use cases that capture >> security-relevant events, including the following: >> 1) change of network composition: new kid on the block; temporary >> (repair) or permanently (disposed) decommissioned device; temporary >> or permanent network union, resp. partitioning; >> 2) change of roles of devices: new role assigned to device; role >> retracted from device; assignment of meta-roles and retraction >> hereof; roles based on global policies, resp. local decisions; >> 3) initialization or roles of devices and evolution hereof during >> lifecycle of devices and networks, all the way from conception (e.g., >> chip manufacturing) to system integration, etc. (e.g., change of >> ownership/control, logical/procedural transfer operation), to >> operational use, replacement, disposition. >> >> I would also go into more details as to what might be different with >> constrained networks. Simply allocating a single third-party device >> to do arbitrage may not do the job, since delegation of computational >> or storage cost may be offset by communication cost, energy >> consumption, and denial of service risk. One should support both >> peer-to-peer (localized) and outsourced ("cloud based", if one >> wishes) scenarios. >> >> I would also pay lots of attention to distinction between homogeneous >> and heterogeneous trust domain scenarios. After all, one should >> facilitate "mix and match" scenarios, where devices may be procured >> from multiple vendors, that may not know each other and, even if they >> would, not trust each other. Having any presumption that >> manufacturers should do secret handshakes for their devices to be >> able to communicate securely may hamper significantly deployment in >> ease of use manner and never bring the full potential of internet of >> things forward. Moreover, it could stifle innovation, since baking in >> pre-established relationships may force the hand of contractual >> parties in favor of vested interests and the bigger party. >> >> Use cases should focus on both consumer and non-consumer style >> scenarios and include, industrial control, critical infrastructure, >> etc. I am happy to contribute to use cases that incorporate the above >> feedback and that borrow from experience gained in discussions with >> industrial control and other wireless sensor standardization groups, >> covering both security, ease of use, and ease of deployment and >> provisioning, over the last 5-10 years. >> >> Lastly, it would be good to take the viewpoint as to what >> functionalities are required and emphasize slghtly less those >> constraints that may become less of an issue over time (e.g., those >> in the digital vs. the analog domain). As we heard during the ACE >> session in Toronto, lots of crypto can be considered (or can soon be >> considered) a commodity for low-hanging fruit applications one may >> wish to target. >> >> What is needed in the end is a design incorporating the right type of >> crypto primitives and protocols and a language that expresses device >> roles and meta-roles that can be conveyed over the air. Design then >> centers around which crypto, which protocols, which roles, how to >> express things, which granularity, etc. This would, of course, be >> part of the design of the solution and not part of the use cases, but >> certainly relates to requirements (if one wishes to tie this in with >> use cases). >> >> Best regards, Rene >> >> On 7/21/2014 10:46 AM, Hannes Tschofenig wrote: >>> Hi all, >>> >>> we have a milestone for a use case document in ACe and >>> draft-seitz-ace-usecases is a promising candidate for this milestone. >>> >>> This email is a call for adoption for draft-seitz-ace-usecases-01. >>> >>> Please respond if you support, or object to, the adoption of this >>> document as the basis for this work item. Deadline for your response: >>> 31. July 2014 >>> >>> Ciao >>> Hannes & Kepeng >>> >>> >>> >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >> >> >> -- >> email:rstruik.ext@gmail.com | Skype: rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >> >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------090801040601050600010109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Robert:

Describing use case more abstractly than others does not suddenly make these no use cases (as you seem to suggest). See below, if this is more concrete to you.

Ad #1) below:
a) I want to be able to add a device to my network (new kid on the block);
this can be temporarily (e.g., friend has access to printer while visiting, but not after) or permanently (add new stick-on-window temperature meter to home control system).
b) I want to replace a malfunctioning device, e.g., pressure pump has to go to repair shop (temporary decommissioning) or ditch a broken one (permanent decommissioning);
c) I have a complete subsystem (skid) I want to add to a network on an oil platform (union), resp. want to sell off a subsystem or logically split a network/system into two (partitioning).

Ad #2) below:
a) I want my remote control to control a new gadget (new role assigned to device); I want to remove the capability of this remote control (retract from device);
b) etc., etc.

The draft needs a major rewrite to accommodate this all in a succinct manner. Hence, my "no vote". Again, having a draft on the shelf does not by itself make it worthy of adoption as a WG document as is.

{BTW - during the draft charter discussion, one of the co-editors, Steffi Gerdes, agreed with earlier suggestion to have use case draft milestone for adoption in December, see
http://www.ietf.org/mail-archive/web/ace/current/msg00632.html. It was unclear why this was changed (it came out of the blue)}

Rene

==
I would provide a more succinct description of use cases that capture security-relevant events, including the following:
1) change of network composition: new kid on the block; temporary (repair) or permanently (disposed) decommissioned device; temporary or permanent network union, resp. partitioning;
2) change of roles of devices: new role assigned to device; role retracted from device; assignment of meta-roles and retraction hereof; roles based on global policies, resp. local decisions;
3) initialization or roles of devices and evolution hereof during lifecycle of devices and networks, all the way from conception (e.g., chip manufacturing) to system integration, etc. (e.g., change of ownership/control, logical/procedural transfer operation), to operational use, replacement, disposition.

On 8/1/2014 9:08 AM, Robert Cragie wrote:
Rene,

I think you're missing the point of use cases. A use case is a depiction of a real world scenario. What you describe below are the models and patterns which can be interpreted from use cases. That is separate and should be treated as such.

Therefore I do support adoption of the document but I do also think there is value in trying to solicit a larger and wider set of use cases to add to the document, focusing on e.g, "bananas" as opposed to "devices".

Robert

On 01/08/2014 5:08 AM, Rene Struik wrote:
Dear colleagues:

I participated in the ACE discussions in Toronto last week, read draft-seitz-ace-usecases-01, and saw the email discussions that ensued since the meeting.

Unfortunately, I cannot support adopting the use case draft in its current form.

I think it is far from ready to be a fruitful base for incremental improvements as a WG document. Moreover, there seems to be quite some disagreement as to whether certain use cases (discussed on the mailing list over the last few days, but mostly not in the draft) are considered inside scope of this working group.

We should not simply adopt a draft, just because it is there. It also should have sufficient merit to have a chance progressing to an informational RFC or document that otherwise would guide the development of an authorization and authentication solution as a proposed standard. Right now, I feel it does not have these qualities.

I would provide a more succinct description of use cases that capture security-relevant events, including the following:
1) change of network composition: new kid on the block; temporary (repair) or permanently (disposed) decommissioned device; temporary or permanent network union, resp. partitioning;
2) change of roles of devices: new role assigned to device; role retracted from device; assignment of meta-roles and retraction hereof; roles based on global policies, resp. local decisions;
3) initialization or roles of devices and evolution hereof during lifecycle of devices and networks, all the way from conception (e.g., chip manufacturing) to system integration, etc. (e.g., change of ownership/control, logical/procedural transfer operation), to operational use, replacement, disposition.

I would also go into more details as to what might be different with constrained networks. Simply allocating a single third-party device to do arbitrage may not do the job, since delegation of computational or storage cost may be offset by communication cost, energy consumption, and denial of service risk. One should support both peer-to-peer (localized) and outsourced ("cloud based", if one wishes) scenarios.

I would also pay lots of attention to distinction between homogeneous and heterogeneous trust domain scenarios. After all, one should facilitate "mix and match" scenarios, where devices may be procured from multiple vendors, that may not know each other and, even if they would, not trust each other. Having any presumption that manufacturers should do secret handshakes for their devices to be able to communicate securely may hamper significantly deployment in ease of use manner and never bring the full potential of internet of things forward. Moreover, it could stifle innovation, since baking in pre-established relationships may force the hand of contractual parties in favor of vested interests and the bigger party.

Use cases should focus on both consumer and non-consumer style scenarios and include, industrial control, critical infrastructure, etc. I am happy to contribute to use cases that incorporate the above feedback and that borrow from experience gained in discussions with industrial control and other wireless sensor standardization groups, covering both security, ease of use, and ease of deployment and provisioning, over the last 5-10 years.

Lastly, it would be good to take the viewpoint as to what functionalities are required and emphasize slghtly less those constraints that may become less of an issue over time (e.g., those in the digital vs. the analog domain). As we heard during the ACE session in Toronto, lots of crypto can be considered (or can soon be considered) a commodity for low-hanging fruit applications one may wish to target.

What is needed in the end is a design incorporating the right type of crypto primitives and protocols and a language that expresses device roles and meta-roles that can be conveyed over the air. Design then centers around which crypto, which protocols, which roles, how to express things, which granularity, etc. This would, of course, be part of the design of the solution and not part of the use cases, but certainly relates to requirements (if one wishes to tie this in with use cases).

Best regards, Rene

On 7/21/2014 10:46 AM, Hannes Tschofenig wrote:
Hi all,

we have a milestone for a use case document in ACe and
draft-seitz-ace-usecases is a promising candidate for this milestone.

This email is a call for adoption for draft-seitz-ace-usecases-01.

Please respond if you support, or object to, the adoption of this
document as the basis for this work item. Deadline for your response:
31. July 2014

Ciao
Hannes & Kepeng




_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace




_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------090801040601050600010109-- From nobody Fri Aug 1 07:31:22 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4821A005F for ; Fri, 1 Aug 2014 07:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOCu59exYOmu for ; Fri, 1 Aug 2014 07:31:16 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F34A21A005E for ; Fri, 1 Aug 2014 07:31:15 -0700 (PDT) Received: by mail-ig0-f180.google.com with SMTP id l13so1655635iga.7 for ; Fri, 01 Aug 2014 07:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=XAvae0x01aAyigwaQit3NmpzrgH43P4ERQDe0IrHAjE=; b=kOXn6+fxl70TguVxa4P9FHILb6QCq8fDjVC4p+ps+z3+xnvXCHcovKf/KcZlno4r2p W7w+R3LzvTdvYnIjF3I5swwmWSEOwibLW8hrCZzwwg7wN3f8PgXSRs7ihl4mGqbJHHDD zRKZCidt/Kp8uLqU1cvtZ49CiOYDj+uXeabWVBmB82DFwA1bsHcXL2Xs5aURHU9k38pN 2Y/2i/sM7v3/4Jj0EwW2++vyU07t5zNST9F6riROIslxBIR0NqTbEeddzO/QvIHOuRbW 8VIZAewbOPthdLhZTIE6s8EzIQUNnZeyHVdvm0foLgv0hPl4abuR5rvHH6egqrM4mexF eVlA== X-Received: by 10.50.33.73 with SMTP id p9mr8300336igi.24.1406903475444; Fri, 01 Aug 2014 07:31:15 -0700 (PDT) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.118.107]) by mx.google.com with ESMTPSA id ga11sm10818331igd.8.2014.08.01.07.31.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Aug 2014 07:31:14 -0700 (PDT) Message-ID: <53DBA4AD.9060702@gmail.com> Date: Fri, 01 Aug 2014 10:31:09 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Michael Richardson , "ace@ietf.org" References: <516f38cfa4474c658ca133629a118250@BLUPR03MB309.namprd03.prod.outlook.com> <3194.1406753341@sandelman.ca> <14810.1406871339@sandelman.ca> In-Reply-To: <14810.1406871339@sandelman.ca> Content-Type: multipart/alternative; boundary="------------070004090105040005080802" Archived-At: http://mailarchive.ietf.org/arch/msg/ace/chIGMOTQIaP-kumCj-fi4muutw0 Subject: Re: [Ace] Use Case draft X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 14:31:20 -0000 This is a multi-part message in MIME format. --------------070004090105040005080802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 8/1/2014 1:35 AM, Michael Richardson wrote: > {at the risk of repeating myself and boring everyone} > > Carsten Bormann wrote: > >>> 2) Secret provisioning is another important problem to > >>> solve. Scenario is : I bring home my new thermostat and want to > >>> associate it with my account, how is it paired? > > > ACE needs to enable this. (And it may want to work without requiring > > the concept of "account".) The initial method of pairing or whatever > > is out of scope (being able to keep it here is one of the points of the > > differentiation between AM and AS). > > My take is that the pairing of the thermostat with the AM is out of scope. > Once paired, the process by which the AM helps the thermostat talk to the > furnace or AC or your Mike's Wife's Phone (Henceforth: MWP) is in scope. RS>> Addressing authorization for the entire trust lifecycle, rather than for the trust lifecycle minus initial provisioning, seems to be easier. Conceptually, it is also a somewhat artificial divide, but also practically it may result in local optimizations that are not necessarily globally close to optimal (and worst case may not work). < >>> Later when I sell my house, how to I transfer ownership of the > >>> thermostat? The most common pattern seems to > >> > >> Out of scope for ACE at this time. > > > Ownership transfer is an important authorization use case. (The more > > interesting question, how do you forcibly gain ownership for the > > contents of a foreclosed home, is way out of scope, though.) > > On the day your house transfer closes, you arrange to disclose your keys > (yes, your private house keys) to the new owner, probably via your lawyer. > Probably these are the keys used by the AM/AS to talk to the constrained > devices, not the ones on your phone. The new owner uses either the existing > AM/AS (after a factory default), or a replacement AM/AS to rekey the entire > network, same as you would change the tumblers on your house. > RS>> If private keys are never exposed outside a device, ownership transfer may only involve a change to *public* configuration tables (what I would term "role to device mappings"), at least if one uses public key based techniques. These could simply be propagated over the network. Not sure why one would need to introduce another employment vehicle for lawyers, notaries, and legal departments and add cost where almost zero-cost seems possible. < As for foreclosure, the banks will presumably want things escrowed to them, > just as they insist that I have life insurance as a condition of my > mortgage. (and will happily sell that to me if I'm stupid) RS>> If one defines a master controller, who has the authority to re-configure settings, in case of unwilling former home owners, this could be addressed. This falls into the same category as "click here if you forgot your password", but with some more policies (so as to provide checks and balances) around this. < >> See UCAN BOF. > > > I don't think UCAN discusses ownership transfer. > > If there are certificates from manufacturer to owner as part of the network > ownership claim that UCAN envisions, then ownership transfer amounts to > adding another layer in a certificate chain. RS>> Not sure I understand this. This seems to suggest that certificate chains would encode the entire history of device ownership. In my mind, one should be able to logically transition ownership roles, whereby one can completely cut ties with the past (use case: installer is done with configuring network of lights in hotel lobby and should be "forgotten" entirely once the job is done and also logically be cut off moving forward). < There are various ways to do > this, with different properties. > But, that relationship is about bootstrapping the C/AM pairing, and is out of > scope for ACE. > > >>> 2) If somebody sides a malicious "puck" device under my door, what > >>> keeps it from joining the other things in the home and attacking the > >>> house. > > > If the ACE protocols are not secure against this I have no idea > > whatsoever what we are trying to do. (It's not exactly a "use case" in > > the classical sense; maybe we should be explicit about misuse cases and > > threats in general.) > > There are three threats for the puck. > 1) the puck successfully joins the network and tries to do things to > existing devices. ACE is all about securing this. > 2) the puck tries to join the network; but the network refuses. Not in > scope for ACE. RS>> Still, this is simply an authorization decision by a recipient device somewhere in the network, not that different from other authorization decisions. < 3) the puck presents itself as the network to other (new?) devices, and > tries to get them to join it's network, possibly MiTM them. > Also out of scope. > > >>> 3) If I have guests and I want to give control of some parts of my > >>> home, how is that done? Use of proximity is one interesting idea I've > >>> heard here, if you are in my house you can turn lights on and off. > > > Again, ACE needs to enable this. The method of proximity/in-perimeter > > detection is out of scope. RS>> Here, authorization is based on contextual information, similar to time of day of message receipt (here: observed purported location). < > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------070004090105040005080802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 8/1/2014 1:35 AM, Michael Richardson wrote:
{at the risk of repeating myself and boring everyone}

Carsten Bormann <cabo@tzi.org> wrote:
    >>> 2) Secret provisioning is another important problem to
    >>> solve. Scenario is : I bring home my new thermostat and want to
    >>> associate it with my account, how is it paired?

    > ACE needs to enable this.  (And it may want to work without requiring
    > the concept of “account”.)  The initial method of pairing or whatever
    > is out of scope (being able to keep it here is one of the points of the
    > differentiation between AM and AS).

My take is that the pairing of the thermostat with the AM is out of scope.
Once paired, the process by which the AM helps the thermostat talk to the
furnace or AC or your Mike's Wife's Phone (Henceforth: MWP) is in scope.
RS>>
Addressing authorization for the entire trust lifecycle, rather than for the trust lifecycle minus initial provisioning, seems to be easier. Conceptually, it is also a somewhat artificial divide, but also practically it may result in local optimizations that are not necessarily globally close to optimal (and worst case may not work).
<<RS
    >>> Later when I sell my house, how to I transfer ownership of the
    >>> thermostat? The most common pattern seems to
    >> 
    >> Out of scope for ACE at this time.

    > Ownership transfer is an important authorization use case.  (The more
    > interesting question, how do you forcibly gain ownership for the
    > contents of a foreclosed home, is way out of scope, though.)

On the day your house transfer closes, you arrange to disclose your keys
(yes, your private house keys) to the new owner, probably via your lawyer.
Probably these are the keys used by the AM/AS to talk to the constrained
devices, not the ones on your phone.   The new owner uses either the existing
AM/AS (after a factory default), or a replacement AM/AS to rekey the entire
network, same as you would change the tumblers on your house.
RS>>
If private keys are never exposed outside a device, ownership transfer may only involve a change to *public* configuration tables (what I would term "role to device mappings"), at least if one uses public key based techniques. These could simply be propagated over the network. Not sure why one would need to introduce another employment vehicle for lawyers, notaries, and legal departments and add cost where almost zero-cost seems possible.
<<RS 
As for foreclosure, the banks will presumably want things escrowed to them,
just as they insist that I have life insurance as a condition of my
mortgage. (and will happily sell that to me if I'm stupid)
RS>>
If one defines a master controller, who has the authority to re-configure settings, in case of unwilling former home owners, this could be addressed. This falls into the same category as "click here if you forgot your password", but with some more policies (so as to provide checks and balances) around this.
<<RS
    >> See UCAN BOF.

    > I don’t think UCAN discusses ownership transfer.

If there are certificates from manufacturer to owner as part of the network
ownership claim that UCAN envisions, then ownership transfer amounts to
adding another layer in a certificate chain.
RS>>
Not sure I understand this. This seems to suggest that certificate chains would encode the entire history of device ownership. In my mind, one should be able to logically transition ownership roles, whereby one can completely cut ties with the past (use case: installer is done with configuring network of lights in hotel lobby and should be "forgotten" entirely once the job is done and also logically be cut off moving forward).
<<RS
There are various ways to do
this, with different properties.
But, that relationship is about bootstrapping the C/AM pairing, and is out of
scope for ACE.

    >>> 2) If somebody sides a malicious "puck" device under my door, what
    >>> keeps it from joining the other things in the home and attacking the
    >>> house.

    > If the ACE protocols are not secure against this I have no idea
    > whatsoever what we are trying to do.  (It’s not exactly a “use case” in
    > the classical sense; maybe we should be explicit about misuse cases and
    > threats in general.)

There are three threats for the puck.
      1) the puck successfully joins the network and tries to do things to
         existing devices.  ACE is all about securing this.
      2) the puck tries to join the network; but the network refuses. Not in
         scope for ACE.
RS>>
Still, this is simply an authorization decision by a recipient device somewhere in the network, not that different from other authorization decisions.
<<RS
      3) the puck presents itself as the network to other (new?) devices, and
         tries to get them to join it's network, possibly MiTM them.
         Also out of scope.

    >>> 3) If I have guests and I want to give control of some parts of my
    >>> home, how is that done? Use of proximity is one interesting idea I've
    >>> heard here, if you are in my house you can turn lights on and off.

    > Again, ACE needs to enable this.  The method of proximity/in-perimeter
    > detection is out of scope.
RS>>
Here, authorization is based on contextual information, similar to time of day of message receipt (here: observed purported location).
<<RS

If there is a proximity sensor, then it might act as a sort of RS, AS or AM, which may provide an ACE format ticket that indicates the C is proximate, and presenting this ticket to another RS (the light), might be enough to control it. The protocol by which the proximity sensor pairs with you (determines your proximity) is probably out of scope, the result of the pairing should be in scope. 


_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------070004090105040005080802-- From nobody Fri Aug 1 12:07:17 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1CF1B28AF for ; Fri, 1 Aug 2014 12:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noCb35a3yfBZ for ; Fri, 1 Aug 2014 12:07:10 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48D351B28B9 for ; Fri, 1 Aug 2014 12:07:10 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id q107so6432894qgd.14 for ; Fri, 01 Aug 2014 12:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AEoCjgbmd97ixlHBZSq3KggWR548+pXmXnA0g47bK2c=; b=FL2CxQtqKV9ACxdWHNcU6uyXINPLhXxWXrZgOevxiGVrQrAMMseZirJyg7kQGyU5qH n5PVM2mOhWkGTAThnL2pkXUATsaXxu7OlOllBNrlogVMD6TFGw1DCFOESDBk2vym4Y9N kLqPmtrN3afNTu5Czp5fmviFXoqbPEKlMCi6xEu/5lG4K/D7e7nQl1LFI66hY9IGVPTl s+VqxCtFdlieF0aLQFlPuumnp29gxmvQBMvhB4NqxL1YfSfBt1V4BPplbyVogBOZ5kK4 6yiaHt/3484tSrbZH/gIk0dEG2DU+q5Xms2LSWC1g05gsLUhLSRGfLyIbEQ/a/CYmL1o Zyqw== X-Received: by 10.224.88.129 with SMTP id a1mr12661749qam.23.1406920028864; Fri, 01 Aug 2014 12:07:08 -0700 (PDT) Received: from [10.44.53.210] (mobile-198-228-195-065.mycingular.net. [198.228.195.65]) by mx.google.com with ESMTPSA id y8sm16442540qaf.33.2014.08.01.12.06.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Aug 2014 12:07:07 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-09829071-8128-42CD-AD18-AD4058EA5702 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D167) In-Reply-To: <53DB989E.3060006@gmail.com> Date: Fri, 1 Aug 2014 15:06:53 -0400 Content-Transfer-Encoding: 7bit Message-Id: <7FC2CFA4-8300-4939-82DE-27FD8F07D1F0@gmail.com> References: <53CD27D3.1010709@gmx.net> <53DB12A2.90209@gmail.com> <53DB9156.5090200@gridmerge.com> <53DB989E.3060006@gmail.com> To: Rene Struik Archived-At: http://mailarchive.ietf.org/arch/msg/ace/vZQdVq31YqkFKcUtOIZD7CFgexU Cc: "robert.cragie@gridmerge.com" , "ace@ietf.org" Subject: Re: [Ace] Call for adoption on draft-seitz-ace-usecases-01 ("ACE Use Cases") X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 19:07:14 -0000 --Apple-Mail-09829071-8128-42CD-AD18-AD4058EA5702 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Rene, Sent from my iPhone > On Aug 1, 2014, at 9:39 AM, Rene Struik wrote: >=20 > Hi Robert: >=20 > Describing use case more abstractly than others does not suddenly make the= se no use cases (as you seem to suggest). See below, if this is more concret= e to you. >=20 > Ad #1) below: > a) I want to be able to add a device to my network (new kid on the block);= =20 > this can be temporarily (e.g., friend has access to printer while visiting= , but not after) or permanently (add new stick-on-window temperature meter t= o home control system). > b) I want to replace a malfunctioning device, e.g., pressure pump has to g= o to repair shop (temporary decommissioning) or ditch a broken one (permanen= t decommissioning); > c) I have a complete subsystem (skid) I want to add to a network on an oil= platform (union), resp. want to sell off a subsystem or logically split a n= etwork/system into two (partitioning). >=20 > Ad #2) below: > a) I want my remote control to control a new gadget (new role assigned to d= evice); I want to remove the capability of this remote control (retract from= device); > b) etc., etc. >=20 > The draft needs a major rewrite to accommodate this all in a succinct mann= er. Hence, my "no vote". Again, having a draft on the shelf does not by itse= lf make it worthy of adoption as a WG document as is.=20 >=20 > {BTW - during the draft charter discussion, one of the co-editors, Steffi G= erdes, agreed with earlier suggestion to have use case draft milestone for a= doption in December, see > http://www.ietf.org/mail-archive/web/ace/current/msg00632.html. It was unc= lear why this was changed (it came out of the blue)} The change happened during the IESG review, a result of past experience. Wi= th other WGs, if the use cases and other formative work takes too long, the W= G looses steam and potentially interest from the developers who would normal= ly kick in once this base work is complete. If you want to submit an alternate draft, please do it soon to provide a cho= ice or the WG can build on and modify this one. Regards, Kathleen >=20 > Rene >=20 > =3D=3D > I would provide a more succinct description of use cases that capture secu= rity-relevant events, including the following: > 1) change of network composition: new kid on the block; temporary (repair)= or permanently (disposed) decommissioned device; temporary or permanent net= work union, resp. partitioning; > 2) change of roles of devices: new role assigned to device; role retracted= from device; assignment of meta-roles and retraction hereof; roles based on= global policies, resp. local decisions; > 3) initialization or roles of devices and evolution hereof during lifecycl= e of devices and networks, all the way from conception (e.g., chip manufactu= ring) to system integration, etc. (e.g., change of ownership/control, logica= l/procedural transfer operation), to operational use, replacement, dispositi= on. >=20 >> On 8/1/2014 9:08 AM, Robert Cragie wrote: >> Rene, >>=20 >> I think you're missing the point of use cases. A use case is a depiction o= f a real world scenario. What you describe below are the models and patterns= which can be interpreted from use cases. That is separate and should be tre= ated as such. >>=20 >> Therefore I do support adoption of the document but I do also think there= is value in trying to solicit a larger and wider set of use cases to add to= the document, focusing on e.g, "bananas" as opposed to "devices". >>=20 >> Robert >>=20 >>> On 01/08/2014 5:08 AM, Rene Struik wrote: >>> Dear colleagues: >>>=20 >>> I participated in the ACE discussions in Toronto last week, re= ad draft-seitz-ace-usecases-01, and saw the email discussions that ensued si= nce the meeting. >>>=20 >>> Unfortunately, I cannot support adopting the use case draft in its curre= nt form. >>>=20 >>> I think it is far from ready to be a fruitful base for incremental impro= vements as a WG document. Moreover, there seems to be quite some disagreemen= t as to whether certain use cases (discussed on the mailing list over the la= st few days, but mostly not in the draft) are considered inside scope of thi= s working group. >>>=20 >>> We should not simply adopt a draft, just because it is there. It also sh= ould have sufficient merit to have a chance progressing to an informational R= FC or document that otherwise would guide the development of an authorizatio= n and authentication solution as a proposed standard. Right now, I feel it d= oes not have these qualities. >>>=20 >>> I would provide a more succinct description of use cases that capture se= curity-relevant events, including the following: >>> 1) change of network composition: new kid on the block; temporary (repai= r) or permanently (disposed) decommissioned device; temporary or permanent n= etwork union, resp. partitioning; >>> 2) change of roles of devices: new role assigned to device; role retract= ed from device; assignment of meta-roles and retraction hereof; roles based o= n global policies, resp. local decisions; >>> 3) initialization or roles of devices and evolution hereof during lifecy= cle of devices and networks, all the way from conception (e.g., chip manufac= turing) to system integration, etc. (e.g., change of ownership/control, logi= cal/procedural transfer operation), to operational use, replacement, disposi= tion. >>>=20 >>> I would also go into more details as to what might be different with con= strained networks. Simply allocating a single third-party device to do arbit= rage may not do the job, since delegation of computational or storage cost m= ay be offset by communication cost, energy consumption, and denial of servic= e risk. One should support both peer-to-peer (localized) and outsourced ("cl= oud based", if one wishes) scenarios. >>>=20 >>> I would also pay lots of attention to distinction between homogeneous an= d heterogeneous trust domain scenarios. After all, one should facilitate "mi= x and match" scenarios, where devices may be procured from multiple vendors,= that may not know each other and, even if they would, not trust each other.= Having any presumption that manufacturers should do secret handshakes for t= heir devices to be able to communicate securely may hamper significantly dep= loyment in ease of use manner and never bring the full potential of internet= of things forward. Moreover, it could stifle innovation, since baking in pr= e-established relationships may force the hand of contractual parties in fav= or of vested interests and the bigger party. >>>=20 >>> Use cases should focus on both consumer and non-consumer style scenarios= and include, industrial control, critical infrastructure, etc. I am happy t= o contribute to use cases that incorporate the above feedback and that borro= w from experience gained in discussions with industrial control and other wi= reless sensor standardization groups, covering both security, ease of use, a= nd ease of deployment and provisioning, over the last 5-10 years. >>>=20 >>> Lastly, it would be good to take the viewpoint as to what functionalitie= s are required and emphasize slghtly less those constraints that may become l= ess of an issue over time (e.g., those in the digital vs. the analog domain)= . As we heard during the ACE session in Toronto, lots of crypto can be consi= dered (or can soon be considered) a commodity for low-hanging fruit applicat= ions one may wish to target. >>>=20 >>> What is needed in the end is a design incorporating the right type of cr= ypto primitives and protocols and a language that expresses device roles and= meta-roles that can be conveyed over the air. Design then centers= around which crypto, which protocols, which roles, how to express things, w= hich granularity, etc. This would, of course, be part of the design of the s= olution and not part of the use cases, but certainly relates to requirements= (if one wishes to tie this in with use cases). >>>=20 >>> Best regards, Rene >>>=20 >>>> On 7/21/2014 10:46 AM, Hannes Tschofenig wrote: >>>> Hi all, >>>>=20 >>>> we have a milestone for a use case document in ACe and >>>> draft-seitz-ace-usecases is a promising candidate for this milestone. >>>>=20 >>>> This email is a call for adoption for draft-seitz-ace-usecases-01. >>>>=20 >>>> Please respond if you support, or object to, the adoption of this >>>> document as the basis for this work item. Deadline for your response: >>>> 31. July 2014 >>>>=20 >>>> Ciao >>>> Hannes & Kepeng >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Ace mailing list >>>> Ace@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ace >>>=20 >>>=20 >>> --=20 >>> email: rstruik.ext@gmail.com | Skype: rstruik >>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>>=20 >>>=20 >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >>=20 >>=20 >>=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >=20 >=20 > --=20 > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --Apple-Mail-09829071-8128-42CD-AD18-AD4058EA5702 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi Rene,

Sent from my iPhone

On Aug 1, 2014, at 9:39 AM, Rene Struik <rstruik.ext@gmail.com> wrote:

Hi Robert:

Describing use case more abstractly than others does not suddenly make these no use cases (as you seem to suggest). See below, if this is more concrete to you.

Ad #1) below:
a) I want to be able to add a device to my network (new kid on the block);
this can be temporarily (e.g., friend has access to printer while visiting, but not after) or permanently (add new stick-on-window temperature meter to home control system).
b) I want to replace a malfunctioning device, e.g., pressure pump has to go to repair shop (temporary decommissioning) or ditch a broken one (permanent decommissioning);
c) I have a complete subsystem (skid) I want to add to a network on an oil platform (union), resp. want to sell off a subsystem or logically split a network/system into two (partitioning).

Ad #2) below:
a) I want my remote control to control a new gadget (new role assigned to device); I want to remove the capability of this remote control (retract from device);
b) etc., etc.

The draft needs a major rewrite to accommodate this all in a succinct manner. Hence, my "no vote". Again, having a draft on the shelf does not by itself make it worthy of adoption as a WG document as is.

{BTW - during the draft charter discussion, one of the co-editors, Steffi Gerdes, agreed with earlier suggestion to have use case draft milestone for adoption in December, see
http://www.ietf.org/mail-archive/web/ace/current/msg00632.html. It was unclear why this was changed (it came out of the blue)}

The change happened during the IESG review, a result of past experience.  With other WGs, if the use cases and other formative work takes too long, the WG looses steam and potentially interest from the developers who would normally kick in once this base work is complete.

If you want to submit an alternate draft, please do it soon to provide a choice or the WG can build on and modify this one.

Regards,
Kathleen


Rene

==
I would provide a more succinct description of use cases that capture security-relevant events, including the following:
1) change of network composition: new kid on the block; temporary (repair) or permanently (disposed) decommissioned device; temporary or permanent network union, resp. partitioning;
2) change of roles of devices: new role assigned to device; role retracted from device; assignment of meta-roles and retraction hereof; roles based on global policies, resp. local decisions;
3) initialization or roles of devices and evolution hereof during lifecycle of devices and networks, all the way from conception (e.g., chip manufacturing) to system integration, etc. (e.g., change of ownership/control, logical/procedural transfer operation), to operational use, replacement, disposition.

On 8/1/2014 9:08 AM, Robert Cragie wrote:
Rene,

I think you're missing the point of use cases. A use case is a depiction of a real world scenario. What you describe below are the models and patterns which can be interpreted from use cases. That is separate and should be treated as such.

Therefore I do support adoption of the document but I do also think there is value in trying to solicit a larger and wider set of use cases to add to the document, focusing on e.g, "bananas" as opposed to "devices".

Robert

On 01/08/2014 5:08 AM, Rene Struik wrote:
Dear colleagues:

I participated in the ACE discussions in Toronto last week, read draft-seitz-ace-usecases-01, and saw the email discussions that ensued since the meeting.

Unfortunately, I cannot support adopting the use case draft in its current form.

I think it is far from ready to be a fruitful base for incremental improvements as a WG document. Moreover, there seems to be quite some disagreement as to whether certain use cases (discussed on the mailing list over the last few days, but mostly not in the draft) are considered inside scope of this working group.

We should not simply adopt a draft, just because it is there. It also should have sufficient merit to have a chance progressing to an informational RFC or document that otherwise would guide the development of an authorization and authentication solution as a proposed standard. Right now, I feel it does not have these qualities.

I would provide a more succinct description of use cases that capture security-relevant events, including the following:
1) change of network composition: new kid on the block; temporary (repair) or permanently (disposed) decommissioned device; temporary or permanent network union, resp. partitioning;
2) change of roles of devices: new role assigned to device; role retracted from device; assignment of meta-roles and retraction hereof; roles based on global policies, resp. local decisions;
3) initialization or roles of devices and evolution hereof during lifecycle of devices and networks, all the way from conception (e.g., chip manufacturing) to system integration, etc. (e.g., change of ownership/control, logical/procedural transfer operation), to operational use, replacement, disposition.

I would also go into more details as to what might be different with constrained networks. Simply allocating a single third-party device to do arbitrage may not do the job, since delegation of computational or storage cost may be offset by communication cost, energy consumption, and denial of service risk. One should support both peer-to-peer (localized) and outsourced ("cloud based", if one wishes) scenarios.

I would also pay lots of attention to distinction between homogeneous and heterogeneous trust domain scenarios. After all, one should facilitate "mix and match" scenarios, where devices may be procured from multiple vendors, that may not know each other and, even if they would, not trust each other. Having any presumption that manufacturers should do secret handshakes for their devices to be able to communicate securely may hamper significantly deployment in ease of use manner and never bring the full potential of internet of things forward. Moreover, it could stifle innovation, since baking in pre-established relationships may force the hand of contractual parties in favor of vested interests and the bigger party.

Use cases should focus on both consumer and non-consumer style scenarios and include, industrial control, critical infrastructure, etc. I am happy to contribute to use cases that incorporate the above feedback and that borrow from experience gained in discussions with industrial control and other wireless sensor standardization groups, covering both security, ease of use, and ease of deployment and provisioning, over the last 5-10 years.

Lastly, it would be good to take the viewpoint as to what functionalities are required and emphasize slghtly less those constraints that may become less of an issue over time (e.g., those in the digital vs. the analog domain). As we heard during the ACE session in Toronto, lots of crypto can be considered (or can soon be considered) a commodity for low-hanging fruit applications one may wish to target.

What is needed in the end is a design incorporating the right type of crypto primitives and protocols and a language that expresses device roles and meta-roles that can be conveyed over the air. Design then centers around which crypto, which protocols, which roles, how to express things, which granularity, etc. This would, of course, be part of the design of the solution and not part of the use cases, but certainly relates to requirements (if one wishes to tie this in with use cases).

Best regards, Rene

On 7/21/2014 10:46 AM, Hannes Tschofenig wrote:
Hi all,

we have a milestone for a use case document in ACe and
draft-seitz-ace-usecases is a promising candidate for this milestone.

This email is a call for adoption for draft-seitz-ace-usecases-01.

Please respond if you support, or object to, the adoption of this
document as the basis for this work item. Deadline for your response:
31. July 2014

Ciao
Hannes & Kepeng




_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace




_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--Apple-Mail-09829071-8128-42CD-AD18-AD4058EA5702-- From nobody Fri Aug 1 14:35:09 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A391A008B for ; Fri, 1 Aug 2014 14:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GER2kv-5x7iH for ; Fri, 1 Aug 2014 14:35:04 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0186.outbound.protection.outlook.com [207.46.163.186]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 813951A0084 for ; Fri, 1 Aug 2014 14:35:04 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) with Microsoft SMTP Server (TLS) id 15.0.995.11; Fri, 1 Aug 2014 21:35:02 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.0995.011; Fri, 1 Aug 2014 21:35:02 +0000 From: Anthony Nadalin To: Michael Richardson , "ace@ietf.org" Thread-Topic: [Ace] Use Case draft Thread-Index: AQHPqqK4PP7lvKFDAkeF8MQZPzEln5u2sW2AgACP2uCAAG9cgIABK+AggAA9mYCAAPpVgIABKySAgAEK65A= Date: Fri, 1 Aug 2014 21:35:00 +0000 Message-ID: References: <516f38cfa4474c658ca133629a118250@BLUPR03MB309.namprd03.prod.outlook.com> <3194.1406753341@sandelman.ca> <14810.1406871339@sandelman.ca> In-Reply-To: <14810.1406871339@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::3] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 029097202E x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(24454002)(189002)(199002)(377454003)(51704005)(13464003)(31966008)(74662001)(83072002)(92566001)(54356999)(74502001)(19580405001)(4396001)(50986999)(101416001)(105586002)(80022001)(81542001)(74316001)(107046002)(86362001)(81342001)(85852003)(20776003)(95666004)(76482001)(106116001)(79102001)(76176999)(87936001)(46102001)(19580395003)(76576001)(33646002)(106356001)(107886001)(77982001)(99286002)(83322001)(21056001)(2656002)(99396002)(85306004)(93886004)(64706001)(42262001)(24736002)(3826002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB309; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/ace/_0Wu64Xx0PvA3npK1n1lLQIZNhE Subject: Re: [Ace] Use Case draft X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 21:35:07 -0000 SSdtIG5vdCBzdXJlIHdoeSB5b3UgYXJlIHNheWluZyB0aGVzZSBhcmUgb3V0IG9mIHNjb3BlICh0 aGVzZSBtYXkgbm90IGJlIHdoYXQgeW91IHdhbnQpLCBhcyB0aGUgY2hhcnRlciBkb2VzIG5vdCBy dWxlIHRoZXNlIG91dCwgdGhlIHVzZSBjYXNlcyBjYW4gZ28gYmV5b25kIHdoYXQgdGhlIFdHIGhh cyBmb3IgaXRzIDFzdCBzZXQgb2YgZGVsaXZlcmFibGVzIGFzIGEgYnJvYWQgc2V0IG9mIHVzZSBj YXNlcyBoZWxwcyBndWlkZSB0aGUgV0cgZm9yd2FyZC4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IEFjZSBbbWFpbHRvOmFjZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgTWljaGFlbCBSaWNoYXJkc29uDQpTZW50OiBUaHVyc2RheSwgSnVseSAzMSwgMjAxNCAxMDoz NiBQTQ0KVG86IGFjZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtBY2VdIFVzZSBDYXNlIGRyYWZ0 DQoNCg0Ke2F0IHRoZSByaXNrIG9mIHJlcGVhdGluZyBteXNlbGYgYW5kIGJvcmluZyBldmVyeW9u ZX0NCg0KQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+IHdyb3RlOg0KICAgID4+PiAyKSBT ZWNyZXQgcHJvdmlzaW9uaW5nIGlzIGFub3RoZXIgaW1wb3J0YW50IHByb2JsZW0gdG8NCiAgICA+ Pj4gc29sdmUuIFNjZW5hcmlvIGlzIDogSSBicmluZyBob21lIG15IG5ldyB0aGVybW9zdGF0IGFu ZCB3YW50IHRvDQogICAgPj4+IGFzc29jaWF0ZSBpdCB3aXRoIG15IGFjY291bnQsIGhvdyBpcyBp dCBwYWlyZWQ/DQoNCiAgICA+IEFDRSBuZWVkcyB0byBlbmFibGUgdGhpcy4gIChBbmQgaXQgbWF5 IHdhbnQgdG8gd29yayB3aXRob3V0IHJlcXVpcmluZw0KICAgID4gdGhlIGNvbmNlcHQgb2Yg4oCc YWNjb3VudOKAnS4pICBUaGUgaW5pdGlhbCBtZXRob2Qgb2YgcGFpcmluZyBvciB3aGF0ZXZlcg0K ICAgID4gaXMgb3V0IG9mIHNjb3BlIChiZWluZyBhYmxlIHRvIGtlZXAgaXQgaGVyZSBpcyBvbmUg b2YgdGhlIHBvaW50cyBvZiB0aGUNCiAgICA+IGRpZmZlcmVudGlhdGlvbiBiZXR3ZWVuIEFNIGFu ZCBBUykuDQoNCk15IHRha2UgaXMgdGhhdCB0aGUgcGFpcmluZyBvZiB0aGUgdGhlcm1vc3RhdCB3 aXRoIHRoZSBBTSBpcyBvdXQgb2Ygc2NvcGUuDQpPbmNlIHBhaXJlZCwgdGhlIHByb2Nlc3MgYnkg d2hpY2ggdGhlIEFNIGhlbHBzIHRoZSB0aGVybW9zdGF0IHRhbGsgdG8gdGhlIGZ1cm5hY2Ugb3Ig QUMgb3IgeW91ciBNaWtlJ3MgV2lmZSdzIFBob25lIChIZW5jZWZvcnRoOiBNV1ApIGlzIGluIHNj b3BlLg0KDQogICAgPj4+IExhdGVyIHdoZW4gSSBzZWxsIG15IGhvdXNlLCBob3cgdG8gSSB0cmFu c2ZlciBvd25lcnNoaXAgb2YgdGhlDQogICAgPj4+IHRoZXJtb3N0YXQ/IFRoZSBtb3N0IGNvbW1v biBwYXR0ZXJuIHNlZW1zIHRvDQogICAgPj4gDQogICAgPj4gT3V0IG9mIHNjb3BlIGZvciBBQ0Ug YXQgdGhpcyB0aW1lLg0KDQogICAgPiBPd25lcnNoaXAgdHJhbnNmZXIgaXMgYW4gaW1wb3J0YW50 IGF1dGhvcml6YXRpb24gdXNlIGNhc2UuICAoVGhlIG1vcmUNCiAgICA+IGludGVyZXN0aW5nIHF1 ZXN0aW9uLCBob3cgZG8geW91IGZvcmNpYmx5IGdhaW4gb3duZXJzaGlwIGZvciB0aGUNCiAgICA+ IGNvbnRlbnRzIG9mIGEgZm9yZWNsb3NlZCBob21lLCBpcyB3YXkgb3V0IG9mIHNjb3BlLCB0aG91 Z2guKQ0KDQpPbiB0aGUgZGF5IHlvdXIgaG91c2UgdHJhbnNmZXIgY2xvc2VzLCB5b3UgYXJyYW5n ZSB0byBkaXNjbG9zZSB5b3VyIGtleXMgKHllcywgeW91ciBwcml2YXRlIGhvdXNlIGtleXMpIHRv IHRoZSBuZXcgb3duZXIsIHByb2JhYmx5IHZpYSB5b3VyIGxhd3llci4NClByb2JhYmx5IHRoZXNl IGFyZSB0aGUga2V5cyB1c2VkIGJ5IHRoZSBBTS9BUyB0byB0YWxrIHRvIHRoZSBjb25zdHJhaW5l ZA0KZGV2aWNlcywgbm90IHRoZSBvbmVzIG9uIHlvdXIgcGhvbmUuICAgVGhlIG5ldyBvd25lciB1 c2VzIGVpdGhlciB0aGUgZXhpc3RpbmcNCkFNL0FTIChhZnRlciBhIGZhY3RvcnkgZGVmYXVsdCks IG9yIGEgcmVwbGFjZW1lbnQgQU0vQVMgdG8gcmVrZXkgdGhlIGVudGlyZSBuZXR3b3JrLCBzYW1l IGFzIHlvdSB3b3VsZCBjaGFuZ2UgdGhlIHR1bWJsZXJzIG9uIHlvdXIgaG91c2UuDQoNCkFzIGZv ciBmb3JlY2xvc3VyZSwgdGhlIGJhbmtzIHdpbGwgcHJlc3VtYWJseSB3YW50IHRoaW5ncyBlc2Ny b3dlZCB0byB0aGVtLCBqdXN0IGFzIHRoZXkgaW5zaXN0IHRoYXQgSSBoYXZlIGxpZmUgaW5zdXJh bmNlIGFzIGEgY29uZGl0aW9uIG9mIG15IG1vcnRnYWdlLiAoYW5kIHdpbGwgaGFwcGlseSBzZWxs IHRoYXQgdG8gbWUgaWYgSSdtIHN0dXBpZCkNCg0KICAgID4+IFNlZSBVQ0FOIEJPRi4NCg0KICAg ID4gSSBkb27igJl0IHRoaW5rIFVDQU4gZGlzY3Vzc2VzIG93bmVyc2hpcCB0cmFuc2Zlci4NCg0K SWYgdGhlcmUgYXJlIGNlcnRpZmljYXRlcyBmcm9tIG1hbnVmYWN0dXJlciB0byBvd25lciBhcyBw YXJ0IG9mIHRoZSBuZXR3b3JrIG93bmVyc2hpcCBjbGFpbSB0aGF0IFVDQU4gZW52aXNpb25zLCB0 aGVuIG93bmVyc2hpcCB0cmFuc2ZlciBhbW91bnRzIHRvIGFkZGluZyBhbm90aGVyIGxheWVyIGlu IGEgY2VydGlmaWNhdGUgY2hhaW4uICBUaGVyZSBhcmUgdmFyaW91cyB3YXlzIHRvIGRvIHRoaXMs IHdpdGggZGlmZmVyZW50IHByb3BlcnRpZXMuDQpCdXQsIHRoYXQgcmVsYXRpb25zaGlwIGlzIGFi b3V0IGJvb3RzdHJhcHBpbmcgdGhlIEMvQU0gcGFpcmluZywgYW5kIGlzIG91dCBvZiBzY29wZSBm b3IgQUNFLg0KDQogICAgPj4+IDIpIElmIHNvbWVib2R5IHNpZGVzIGEgbWFsaWNpb3VzICJwdWNr IiBkZXZpY2UgdW5kZXIgbXkgZG9vciwgd2hhdA0KICAgID4+PiBrZWVwcyBpdCBmcm9tIGpvaW5p bmcgdGhlIG90aGVyIHRoaW5ncyBpbiB0aGUgaG9tZSBhbmQgYXR0YWNraW5nIHRoZQ0KICAgID4+ PiBob3VzZS4NCg0KICAgID4gSWYgdGhlIEFDRSBwcm90b2NvbHMgYXJlIG5vdCBzZWN1cmUgYWdh aW5zdCB0aGlzIEkgaGF2ZSBubyBpZGVhDQogICAgPiB3aGF0c29ldmVyIHdoYXQgd2UgYXJlIHRy eWluZyB0byBkby4gIChJdOKAmXMgbm90IGV4YWN0bHkgYSDigJx1c2UgY2FzZeKAnSBpbg0KICAg ID4gdGhlIGNsYXNzaWNhbCBzZW5zZTsgbWF5YmUgd2Ugc2hvdWxkIGJlIGV4cGxpY2l0IGFib3V0 IG1pc3VzZSBjYXNlcyBhbmQNCiAgICA+IHRocmVhdHMgaW4gZ2VuZXJhbC4pDQoNClRoZXJlIGFy ZSB0aHJlZSB0aHJlYXRzIGZvciB0aGUgcHVjay4NCiAgICAgIDEpIHRoZSBwdWNrIHN1Y2Nlc3Nm dWxseSBqb2lucyB0aGUgbmV0d29yayBhbmQgdHJpZXMgdG8gZG8gdGhpbmdzIHRvDQogICAgICAg ICBleGlzdGluZyBkZXZpY2VzLiAgQUNFIGlzIGFsbCBhYm91dCBzZWN1cmluZyB0aGlzLg0KICAg ICAgMikgdGhlIHB1Y2sgdHJpZXMgdG8gam9pbiB0aGUgbmV0d29yazsgYnV0IHRoZSBuZXR3b3Jr IHJlZnVzZXMuIE5vdCBpbg0KICAgICAgICAgc2NvcGUgZm9yIEFDRS4NCiAgICAgIDMpIHRoZSBw dWNrIHByZXNlbnRzIGl0c2VsZiBhcyB0aGUgbmV0d29yayB0byBvdGhlciAobmV3PykgZGV2aWNl cywgYW5kDQogICAgICAgICB0cmllcyB0byBnZXQgdGhlbSB0byBqb2luIGl0J3MgbmV0d29yaywg cG9zc2libHkgTWlUTSB0aGVtLg0KICAgICAgICAgQWxzbyBvdXQgb2Ygc2NvcGUuDQoNCiAgICA+ Pj4gMykgSWYgSSBoYXZlIGd1ZXN0cyBhbmQgSSB3YW50IHRvIGdpdmUgY29udHJvbCBvZiBzb21l IHBhcnRzIG9mIG15DQogICAgPj4+IGhvbWUsIGhvdyBpcyB0aGF0IGRvbmU/IFVzZSBvZiBwcm94 aW1pdHkgaXMgb25lIGludGVyZXN0aW5nIGlkZWEgSSd2ZQ0KICAgID4+PiBoZWFyZCBoZXJlLCBp ZiB5b3UgYXJlIGluIG15IGhvdXNlIHlvdSBjYW4gdHVybiBsaWdodHMgb24gYW5kIG9mZi4NCg0K ICAgID4gQWdhaW4sIEFDRSBuZWVkcyB0byBlbmFibGUgdGhpcy4gIFRoZSBtZXRob2Qgb2YgcHJv eGltaXR5L2luLXBlcmltZXRlcg0KICAgID4gZGV0ZWN0aW9uIGlzIG91dCBvZiBzY29wZS4NCg0K SWYgdGhlcmUgaXMgYSBwcm94aW1pdHkgc2Vuc29yLCB0aGVuIGl0IG1pZ2h0IGFjdCBhcyBhIHNv cnQgb2YgUlMsIEFTIG9yIEFNLCB3aGljaCBtYXkgcHJvdmlkZSBhbiBBQ0UgZm9ybWF0IHRpY2tl dCB0aGF0IGluZGljYXRlcyB0aGUgQyBpcyBwcm94aW1hdGUsIGFuZCBwcmVzZW50aW5nIHRoaXMg dGlja2V0IHRvIGFub3RoZXIgUlMgKHRoZSBsaWdodCksIG1pZ2h0IGJlIGVub3VnaCB0byBjb250 cm9sIGl0LiAgVGhlIHByb3RvY29sIGJ5IHdoaWNoIHRoZSBwcm94aW1pdHkgc2Vuc29yIHBhaXJz IHdpdGggeW91IChkZXRlcm1pbmVzIHlvdXIgcHJveGltaXR5KSBpcyBwcm9iYWJseSBvdXQgb2Yg c2NvcGUsICB0aGUgcmVzdWx0IG9mIHRoZSBwYWlyaW5nIHNob3VsZCBiZSBpbiBzY29wZS4NCg0K LS0NCk1pY2hhZWwgUmljaGFyZHNvbg0KLW9uIHRoZSByb2FkLQ0KDQoNCg== From nobody Sat Aug 2 13:45:04 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE651B2991 for ; Sat, 2 Aug 2014 13:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjJXuD6lrSRK for ; Sat, 2 Aug 2014 13:45:00 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73A781B2990 for ; Sat, 2 Aug 2014 13:45:00 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4E0E82002A; Sat, 2 Aug 2014 16:47:16 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A7BB5638D9; Sat, 2 Aug 2014 16:44:59 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9115B638D7; Sat, 2 Aug 2014 16:44:59 -0400 (EDT) From: Michael Richardson To: Rene Struik In-Reply-To: <53DB989E.3060006@gmail.com> References: <53CD27D3.1010709@gmx.net> <53DB12A2.90209@gmail.com> <53DB9156.5090200@gridmerge.com> <53DB989E.3060006@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ace/fZBgFw02wsGMCOF72Je8Tm16lPU Cc: robert.cragie@gridmerge.com, ace@ietf.org Subject: Re: [Ace] Call for adoption on draft-seitz-ace-usecases-01 ("ACE Use Cases") X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2014 20:45:02 -0000 --=-=-= Rene Struik wrote: > Ad #1) below: a) I want to be able to add a device to my network (new > kid on the block); this can be temporarily (e.g., friend has access to All of this (joining network, leaving, initial pairing with non-constrained node) was agreed to be out of scope for ACE (at this time: a recharter could change that in the future). -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU91NxYCLcPvd0N1lAQKNRggAmvUkmB/acd7KSiSTyYObFvLuDJ60BFCb GRqGuhi3+2pBb+HRBaf5OzvTx5+cE7Ngu8IjXtxNkl74ntrEm+8J1ye8oYvpmYVM Ez98uoWQ+5s0w+Xx+bS7oJJQzxmg3pYBV+Y8Z78VovXwpVgysvLWpkoAQP7stU4J 95pfoHJwbJPtncCpuZoUskvdFjdEK7QEVyUMmVyy79MF0PNdZiol94ArNQcEQVJ4 J4H5pfIb52gXIRZgyQ7sRCvsU8LLjuzj9y4+vX1Gc7Dmrs43hMCyqbrE6eqdFCNq GyLeU6Bmtj1ygFQmYoX5IWd5bY6JlQHl6KTSphUVZzeWJ1UqFzQ6Aw== =6SmZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Aug 2 14:25:25 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0391B29C7 for ; Sat, 2 Aug 2014 14:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9Z1K9n5x4qP for ; Sat, 2 Aug 2014 14:25:21 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE2E31B2999 for ; Sat, 2 Aug 2014 14:25:21 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 630122002A for ; Sat, 2 Aug 2014 17:27:37 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A4526638D9; Sat, 2 Aug 2014 17:25:20 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8737E638D7 for ; Sat, 2 Aug 2014 17:25:20 -0400 (EDT) From: Michael Richardson To: "ace\@ietf.org" In-Reply-To: <53DBA4AD.9060702@gmail.com> References: <516f38cfa4474c658ca133629a118250@BLUPR03MB309.namprd03.prod.outlook.com> <3194.1406753341@sandelman.ca> <14810.1406871339@sandelman.ca> <53DBA4AD.9060702@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ace/GhCXDbThtInbaxAJTqHRigQITMg Subject: Re: [Ace] Use Case draft X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2014 21:25:23 -0000 --=-=-= Rene Struik wrote: > If private keys are never exposed outside a device, ownership transfer > may only involve a change to *public* configuration tables (what I > would term "role to device mappings"), at least if one uses public key > based techniques. These could simply be propagated over the > network. Not sure why one would need to introduce another employment > vehicle for lawyers, notaries, and legal departments and add cost where > almost zero-cost seems possible. 802.1AR provides for both replacing the private key or replacing just the public certificate. > Not sure I understand this. This seems to suggest that certificate > chains would encode the entire history of device ownership. In my mind, That is one option: it permits everything to be done offline, and without any of the original owners being involve, or having a veto. A second option is for each owner to change the certificate after receiving the device. A third option is for the original vendor to re-issue a new certificate to the new owner. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU91XPYCLcPvd0N1lAQItkQgAli7fqkMPbVzh7/ulNPkY7vVpItdrW44k bYlv9ijzR1+VwSfpvRD46HJbSZipchI989wY5DKOub5hgld7wywi7aPDTB8WgSIw lhVQD+ldyFik/QoSIdlXwPX1jbI5Z98tSo1LC4+Z1T29LDGsmtuePlf5HZHZsXwR x4l0pAOHyiUs0g+Z/b8IuDR0egeR7wlBiHTuttIrO9gPWO/nLj9DQ420BeatL8R0 8tVDzkouYrLx1m+1cx7y4JDc1LLtS1SmRoWm4igzwuSXFeCpPs6QQ8IZRp2UrSp0 qszlxw6JIoXCd+01jBapoaPIvBiNRq3nqTJRIl1aWuLe4zmhTAlyiQ== =FC5E -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Aug 2 14:28:40 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2691B29CD for ; Sat, 2 Aug 2014 14:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-PIS5xbX04U for ; Sat, 2 Aug 2014 14:28:38 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 480081B29CC for ; Sat, 2 Aug 2014 14:28:38 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4373D2002A; Sat, 2 Aug 2014 17:30:54 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 87912638D9; Sat, 2 Aug 2014 17:28:37 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6ED70638D7; Sat, 2 Aug 2014 17:28:37 -0400 (EDT) From: Michael Richardson To: Anthony Nadalin In-Reply-To: References: <516f38cfa4474c658ca133629a118250@BLUPR03MB309.namprd03.prod.outlook.com> <3194.1406753341@sandelman.ca> <14810.1406871339@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ace/26JEdd9dxgg87dgqFkR-9BdYgo8 Cc: "ace@ietf.org" Subject: Re: [Ace] Use Case draft X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2014 21:28:39 -0000 --=-=-= Anthony Nadalin wrote: > I'm not sure why you are saying these are out of scope (these may not > be what you want), as the charter does not rule these out, the use > cases can go beyond what the WG has for its 1st set of deliverables as > a broad set of use cases helps guide the WG forward. If it makes the use case more understandable, great. Solving those problems is presently out of scope. (Note: I'm actually really interested in solving these problems, but I think we need to not get bogged down in the join problem until later) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU91YAoCLcPvd0N1lAQIhtAf/YILhnOC5+A6jKuOmmFj8ZLvjRMFCc5Tk BfGA48YRgKZhdOAJgg4kVWknPItj+RqEl4ziNOLByOzmSKnvGgIyi0dAJyDDVXNq R6LOZMCm43o/fM5DWEfLdqixUuJgnwnASqFC2JX6VuaUW6Wp6ALQwWnqb8YueJGD z1AsvDXBN5+JxBwitlFewfs2IWBuGzuVi/7LEMG1Elp67xGCpkSh/B1Z4HHkXsaq +vEcsOoLam5i9f0/pw8g6ryIOTHl6TORwR588e89nnjzkyPBuQJ5NgJ+O7Fn0Qax oNTpTpzBubIKPPl6P5Sy0qWi412Iol42J9OUxh9iTcGD0hjiXAzGeg== =A9i5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 5 05:39:31 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC111A01A8 for ; Tue, 5 Aug 2014 05:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4uB3kb61VZh for ; Tue, 5 Aug 2014 05:39:26 -0700 (PDT) Received: from mailscan1.extendcp.co.uk (mailscan12.extendcp.co.uk [79.170.45.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8957D1A0188 for ; Tue, 5 Aug 2014 05:39:25 -0700 (PDT) Received: from lb1.hi.local ([10.0.1.197] helo=mailscan2.extendcp.co.uk) by mailscan-g66.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1XEe1T-0003Bk-49 for ace@ietf.org; Tue, 05 Aug 2014 13:39:23 +0100 Received: from lb1.hi.local ([10.0.1.197] helo=mail41.extendcp.co.uk) by mailscan2.extendcp.co.uk with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1XEe1Q-0007mq-K6 for ace@ietf.org; Tue, 05 Aug 2014 13:39:23 +0100 Received: from host86-147-27-73.range86-147.btcentralplus.com ([86.147.27.73] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1XEe1P-0008QP-Lo for ace@ietf.org; Tue, 05 Aug 2014 13:39:20 +0100 Message-ID: <53E0D075.1080008@gridmerge.com> Date: Tue, 05 Aug 2014 13:39:17 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: ace@ietf.org References: <53CD27D3.1010709@gmx.net> <53DB12A2.90209@gmail.com> <53DB9156.5090200@gridmerge.com> <53DB989E.3060006@gmail.com> In-Reply-To: <53DB989E.3060006@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000603010105080707090009" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: http://mailarchive.ietf.org/arch/msg/ace/7teDxdGtHKKOz3dusNfZIK8ElGM Subject: Re: [Ace] Call for adoption on draft-seitz-ace-usecases-01 ("ACE Use Cases") X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 12:39:31 -0000 This is a cryptographically signed message in MIME format. --------------ms000603010105080707090009 Content-Type: multipart/alternative; boundary="------------070201010000010703090501" This is a multi-part message in MIME format. --------------070201010000010703090501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Rene, The way I view use cases is more along the lines as written in e.g.=20 http://www.visual-paradigm.com/tutorials/writingeffectiveusecase.jsp,=20 hence my comment (note I am not promoting Visual Paradigm, it was the=20 first relevant article I came across). Therefore, as a collection of=20 examples in different application areas, I think the use case document=20 as written works well. As mentioned, I also think it could be extended=20 and you have made some of your examples more specific, which I think=20 would work for inclusion in this document. I think others which have=20 been highlighted in the mailing list would also be useful, for example=20 the peer-to-peer in-home use cases in Anthony Nadalin's e-mail (Wed, 30=20 Jul 2014 17:42:28 +0000). If I have any comment on the use case document, it would be to remove or = alter Section 3, as it starts to make assumptions about architecture=20 without going through any obvious analysis to distil this architecture=20 from the use cases. However, on the wider question of the usefulness re. use cases: I would=20 concur that too much time can be spent on use cases to the detriment of=20 reaching the charter goal. IMHO, it is usually expedient to use a=20 "bottom-up" approach in conjunction with the "top down" approach of use=20 cases, though these two approaches should be distinguishable in the=20 process. The bottom-up approach assumes architectures and possible=20 protocols based on assessment of existing implementation and then=20 testing them for suitability against the use cases. Regarding existing=20 protocols, initially it is less "how can we use it?", more "what can we=20 apply from it?"; the difference may seem subtle but it is important. On=20 the same token, that doesn't rule out using an existing protocol=20 subsequently if it meets the requirements. This approach also does not=20 preclude work from starting if the use case document is not finished. Robert On 01/08/2014 2:39 PM, Rene Struik wrote: > Hi Robert: > > Describing use case more abstractly than others does not suddenly make = > these no use cases (as you seem to suggest). See below, if this is=20 > more concrete to you. > > Ad #1) below: > a) I want to be able to add a device to my network (new kid on the=20 > block); > this can be temporarily (e.g., friend has access to printer while=20 > visiting, but not after) or permanently (add new stick-on-window=20 > temperature meter to home control system). > b) I want to replace a malfunctioning device, e.g., pressure pump has=20 > to go to repair shop (temporary decommissioning) or ditch a broken one = > (permanent decommissioning); > c) I have a complete subsystem (skid) I want to add to a network on an = > oil platform (union), resp. want to sell off a subsystem or logically=20 > split a network/system into two (partitioning). > > Ad #2) below: > a) I want my remote control to control a new gadget (new role assigned = > to device); I want to remove the capability of this remote control=20 > (retract from device); > b) etc., etc. > > The draft needs a major rewrite to accommodate this all in a succinct=20 > manner. Hence, my "no vote". Again, having a draft on the shelf does=20 > not by itself make it worthy of adoption as a WG document as is. > > {BTW - during the draft charter discussion, one of the co-editors,=20 > Steffi Gerdes, agreed with earlier suggestion to have use case draft=20 > milestone for adoption in December, see > http://www.ietf.org/mail-archive/web/ace/current/msg00632.html. It was = > unclear why this was changed (it came out of the blue)} > > Rene > > =3D=3D > I would provide a more succinct description of use cases that capture=20 > security-relevant events, including the following: > 1) change of network composition: new kid on the block; temporary=20 > (repair) or permanently (disposed) decommissioned device; temporary or = > permanent network union, resp. partitioning; > 2) change of roles of devices: new role assigned to device; role=20 > retracted from device; assignment of meta-roles and retraction hereof; = > roles based on global policies, resp. local decisions; > 3) initialization or roles of devices and evolution hereof during=20 > lifecycle of devices and networks, all the way from conception (e.g.,=20 > chip manufacturing) to system integration, etc. (e.g., change of=20 > ownership/control, logical/procedural transfer operation), to=20 > operational use, replacement, disposition. > > On 8/1/2014 9:08 AM, Robert Cragie wrote: >> Rene, >> >> I think you're missing the point of use cases. A use case is a=20 >> depiction of a real world scenario. What you describe below are the=20 >> models and patterns which can be interpreted from use cases. That is=20 >> separate and should be treated as such. >> >> Therefore I do support adoption of the document but I do also think=20 >> there is value in trying to solicit a larger and wider set of use=20 >> cases to add to the document, focusing on e.g, "bananas" as opposed=20 >> to "devices". >> >> Robert >> >> On 01/08/2014 5:08 AM, Rene Struik wrote: >>> Dear colleagues: >>> >>> I participated in the ACE discussions in Toronto last week, read=20 >>> draft-seitz-ace-usecases-01, and saw the email discussions that=20 >>> ensued since the meeting. >>> >>> Unfortunately, I cannot support adopting the use case draft in its=20 >>> current form. >>> >>> I think it is far from ready to be a fruitful base for incremental=20 >>> improvements as a WG document. Moreover, there seems to be quite=20 >>> some disagreement as to whether certain use cases (discussed on the=20 >>> mailing list over the last few days, but mostly not in the draft)=20 >>> are considered inside scope of this working group. >>> >>> We should not simply adopt a draft, just because it is there. It=20 >>> also should have sufficient merit to have a chance progressing to an = >>> informational RFC or document that otherwise would guide the=20 >>> development of an authorization and authentication solution as a=20 >>> proposed standard. Right now, I feel it does not have these qualities= =2E >>> >>> I would provide a more succinct description of use cases that=20 >>> capture security-relevant events, including the following: >>> 1) change of network composition: new kid on the block; temporary=20 >>> (repair) or permanently (disposed) decommissioned device; temporary=20 >>> or permanent network union, resp. partitioning; >>> 2) change of roles of devices: new role assigned to device; role=20 >>> retracted from device; assignment of meta-roles and retraction=20 >>> hereof; roles based on global policies, resp. local decisions; >>> 3) initialization or roles of devices and evolution hereof during=20 >>> lifecycle of devices and networks, all the way from conception=20 >>> (e.g., chip manufacturing) to system integration, etc. (e.g., change = >>> of ownership/control, logical/procedural transfer operation), to=20 >>> operational use, replacement, disposition. >>> >>> I would also go into more details as to what might be different with = >>> constrained networks. Simply allocating a single third-party device=20 >>> to do arbitrage may not do the job, since delegation of=20 >>> computational or storage cost may be offset by communication cost,=20 >>> energy consumption, and denial of service risk. One should support=20 >>> both peer-to-peer (localized) and outsourced ("cloud based", if one=20 >>> wishes) scenarios. >>> >>> I would also pay lots of attention to distinction between=20 >>> homogeneous and heterogeneous trust domain scenarios. After all, one = >>> should facilitate "mix and match" scenarios, where devices may be=20 >>> procured from multiple vendors, that may not know each other and,=20 >>> even if they would, not trust each other. Having any presumption=20 >>> that manufacturers should do secret handshakes for their devices to=20 >>> be able to communicate securely may hamper significantly deployment=20 >>> in ease of use manner and never bring the full potential of internet = >>> of things forward. Moreover, it could stifle innovation, since=20 >>> baking in pre-established relationships may force the hand of=20 >>> contractual parties in favor of vested interests and the bigger party= =2E >>> >>> Use cases should focus on both consumer and non-consumer style=20 >>> scenarios and include, industrial control, critical infrastructure,=20 >>> etc. I am happy to contribute to use cases that incorporate the=20 >>> above feedback and that borrow from experience gained in discussions = >>> with industrial control and other wireless sensor standardization=20 >>> groups, covering both security, ease of use, and ease of deployment=20 >>> and provisioning, over the last 5-10 years. >>> >>> Lastly, it would be good to take the viewpoint as to what=20 >>> functionalities are required and emphasize slghtly less those=20 >>> constraints that may become less of an issue over time (e.g., those=20 >>> in the digital vs. the analog domain). As we heard during the ACE=20 >>> session in Toronto, lots of crypto can be considered (or can soon be = >>> considered) a commodity for low-hanging fruit applications one may=20 >>> wish to target. >>> >>> What is needed in the end is a design incorporating the right type=20 >>> of crypto primitives and protocols and a language that expresses=20 >>> device roles and meta-roles that can be conveyed over the air.=20 >>> Design then centers around which crypto, which protocols, which=20 >>> roles, how to express things, which granularity, etc. This would, of = >>> course, be part of the design of the solution and not part of the=20 >>> use cases, but certainly relates to requirements (if one wishes to=20 >>> tie this in with use cases). >>> >>> Best regards, Rene >>> >>> On 7/21/2014 10:46 AM, Hannes Tschofenig wrote: >>>> Hi all, >>>> >>>> we have a milestone for a use case document in ACe and >>>> draft-seitz-ace-usecases is a promising candidate for this milestone= =2E >>>> >>>> This email is a call for adoption for draft-seitz-ace-usecases-01. >>>> >>>> Please respond if you support, or object to, the adoption of this >>>> document as the basis for this work item. Deadline for your response= : >>>> 31. July 2014 >>>> >>>> Ciao >>>> Hannes & Kepeng >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ace mailing list >>>> Ace@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ace >>> >>> >>> --=20 >>> email:rstruik.ext@gmail.com | Skype: rstruik >>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>> >>> >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >> >> >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace > > > --=20 > email:rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --------------070201010000010703090501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Rene,

The way I view use cases is more along the lines as written in e.g. http://www.visual-paradigm.com/tutorials/writingeffectiveusecase.jsp= , hence my comment (note I am not promoting Visual Paradigm, it was the first relevant article I came across). Therefore, as a collection of examples in different application areas, I think the use case document as written works well. As mentioned, I also think it could be extended and you have made some of your examples more specific, which I think would work for inclusion in this document. I think others which have been highlighted in the mailing list would also be useful, for example the peer-to-peer in-home use cases in Anthony Nadalin's e-mail (Wed, 30 Jul 2014 17:42:28 +0000).

If I have any comment on the use case document, it would be to remove or alter Section 3, as it starts to make assumptions about architecture without going through any obvious analysis to distil this architecture from the use cases.

However, on the wider question of the usefulness re. use cases: I would concur that too much time can be spent on use cases to the detriment of reaching the charter goal. IMHO, it is usually expedient to use a "bottom-up" approach in conjunction with the "top down" approach of use cases, though these two approaches should be distinguishable in the process. The bottom-up approach assumes architectures and possible protocols based on assessment of existing implementation and then testing them for suitability against the use cases. Regarding existing protocols, initially it is less "how can we use it?", more "what can we apply from it?"; the difference may seem subtle but it is important. On the same token, that doesn't rule out using an existing protocol subsequently if it meets the requirements. This approach also does not preclude work from starting if the use case document is not finished.

Robert

On 01/08/2014 2:39 PM, Rene Struik wrote:
Hi Robert:

Describing use case more abstractly than others does not suddenly make these no use cases (as you seem to suggest). See below, if this is more concrete to you.

Ad #1) below:
a) I want to be able to add a device to my network (new kid on the block);
this can be temporarily (e.g., friend has access to printer while visiting, but not after) or permanently (add new stick-on-window temperature meter to home control system).
b) I want to replace a malfunctioning device, e.g., pressure pump has to go to repair shop (temporary decommissioning) or ditch a broken one (permanent decommissioning);
c) I have a complete subsystem (skid) I want to add to a network on an oil platform (union), resp. want to sell off a subsystem or logically split a network/system into two (partitioning).

Ad #2) below:
a) I want my remote control to control a new gadget (new role assigned to device); I want to remove the capability of this remote control (retract from device);
b) etc., etc.

The draft needs a major rewrite to accommodate this all in a succinct manner. Hence, my "no vote". Again, having a draft on the shelf does not by itself make it worthy of adoption as a WG document as is.

{BTW - during the draft charter discussion, one of the co-editors, Steffi Gerdes, agreed with earlier suggestion to have use case draft milestone for adoption in December, see
http://www.ietf.org/mail-archive/web/ace/current/msg00632.html. It was unclear why this was changed (it came out of the blue)}
Rene

=3D=3D
I would provide a more succinct description of use cases that capture security-relevant events, including the following:
1) change of network composition: new kid on the block; temporary (repair) or permanently (disposed) decommissioned device; temporary or permanent network union, resp. partitioning;
2) change of roles of devices: new role assigned to device; role retracted from device; assignment of meta-roles and retraction hereof; roles based on global policies, resp. local decisions; 3) initialization or roles of devices and evolution hereof during lifecycle of devices and networks, all the way from conception (e.g., chip manufacturing) to system integration, etc. (e.g., change of ownership/control, logical/procedural transfer operation), to operational use, replacement, disposition.

On 8/1/2014 9:08 AM, Robert Cragie wrote:
Rene,

I think you're missing the point of use cases. A use case is a depiction of a real world scenario. What you describe below are the models and patterns which can be interpreted from use cases. That is separate and should be treated as such.

Therefore I do support adoption of the document but I do also think there is value in trying to solicit a larger and wider set of use cases to add to the document, focusing on e.g, "bananas" as opposed to "devices".

Robert

On 01/08/2014 5:08 AM, Rene Struik= wrote:
Dear colleagues:

I participated in the ACE discussions in Toronto last week, read draft-seitz-ace-usecases-01, and saw the email discussions that ensued since the meeting.

Unfortunately, I cannot support adopting the use case draft in its current form.

I think it is far from ready to be a fruitful base for incremental improvements as a WG document. Moreover, there seems to be quite some disagreement as to whether certain use cases (discussed on the mailing list over the last few days, but mostly not in the draft) are considered inside scope of this working group.

We should not simply adopt a draft, just because it is there. It also should have sufficient merit to have a chance progressing to an informational RFC or document that otherwise would guide the development of an authorization and authentication solution as a proposed standard. Right now, I feel it does not have these qualities.

I would provide a more succinct description of use cases that capture security-relevant events, including the following:
1) change of network composition: new kid on the block; temporary (repair) or permanently (disposed) decommissioned device; temporary or permanent network union, resp. partitioning;
2) change of roles of devices: new role assigned to device; role retracted from device; assignment of meta-roles and retraction hereof; roles based on global policies, resp. local decisions;
3) initialization or roles of devices and evolution hereof during lifecycle of devices and networks, all the way from conception (e.g., chip manufacturing) to system integration, etc. (e.g., change of ownership/control, logical/procedural transfer operation), to operational use, replacement, disposition.

I would also go into more details as to what might be different with constrained networks. Simply allocating a single third-party device to do arbitrage may not do the job, since delegation of computational or storage cost may be offset by communication cost, energy consumption, and denial of service risk. One should support both peer-to-peer (localized) and outsourced ("cloud based", if one wishes) scenarios.

I would also pay lots of attention to distinction between homogeneous and heterogeneous trust domain scenarios. After all, one should facilitate "mix and match" scenarios, where devices may be procured from multiple vendors, that may not know each other and, even if they would, not trust each other. Having any presumption that manufacturers should do secret handshakes for their devices to be able to communicate securely may hamper significantly deployment in ease of use manner and never bring the full potential of internet of things forward. Moreover, it could stifle innovation, since baking in pre-established relationships may force the hand of contractual parties in favor of vested interests and the bigger party.

Use cases should focus on both consumer and non-consumer style scenarios and include, industrial control, critical infrastructure, etc. I am happy to contribute to use cases that incorporate the above feedback and that borrow from experience gained in discussions with industrial control and other wireless sensor standardization groups, covering both security, ease of use, and ease of deployment and provisioning, over the last 5-10 years.

Lastly, it would be good to take the viewpoint as to what functionalities are required and emphasize slghtly less those constraints that may become less of an issue over time (e.g., those in the digital vs. the analog domain). As we heard during the ACE session in Toronto, lots of crypto can be considered (or can soon be considered) a commodity for low-hanging fruit applications one may wish to target.

What is needed in the end is a design incorporating the right type of crypto primitives and protocols and a language that expresses device roles and meta-roles that can be conveyed over the air. Design then centers around which crypto, which protocols, which roles, how to express things, which granularity, etc. This would, of course, be part of the design of the solution and not part of the use cases, but certainly relates to requirements (if one wishes to tie this in with use cases).

Best regards, Rene

On 7/21/2014 10:46 AM, Hannes Tschofenig wrote:
Hi all,

we have a milestone for a use case document in ACe and
draft-seitz-ace-usecases is a promising candidate for this milestone.

This email is a call for adoption for draft-seitz-ace-usecases-01.

Please respond if you support, or object to, the adoption of this
document as the basis for this work item. Deadline for your response:
31. July 2014

Ciao
Hannes & Kepeng




______________________________________________=
_
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listin=
fo/ace



--=20
email: rstruik.ext@gmail.com | Skype: rst=
ruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listin=
fo/ace




_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listin=
fo/ace



--=20
email: rstruik.ext@gmail.com | Skype: rst=
ruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


_______________________________________________
Ace mailing list
Ace@ie=
tf.org
https://www.ietf.org/mailman/listinfo/ace

--------------070201010000010703090501-- --------------ms000603010105080707090009 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNDA4MDUxMjM5MTdaMCMGCSqGSIb3DQEJBDEWBBR58bOthb9KirUsABrfXcpLAeMs5DBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAA/UWa+YCveMdKGw/gxvqYf3VVpa9eqHQw9VwfwO+2i70iWA nWyOGePCBnd1hEH/Q9a82DK/oCpAvHIapk+FnsZ5e4lPLQYNmazR9m2x2fRtjFtcnjKtoo3n t0SmntDgYfI9pChg+uyUPxce+f/94J8znJev7eGdajKAgb4t1EL2z5tFGSfDnKQUM/ZtFR7q Hb/11Tl/CXF/gxCxdCbbwdieXOnO3636xiHqKqCiGFgNzgLn409UB/nuHgYAsTeupO90Wios xLfeDHr3QRni4WgRWl1zpg9uGT6pyGI+BPzs3WliCNTwLKReGkaVnQ3ClL4wSVhQF1Vn714J uD8jKOUAAAAAAAA= --------------ms000603010105080707090009-- From nobody Mon Aug 11 20:49:56 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFF41A0271 for ; Mon, 11 Aug 2014 20:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0aEeHW3tbAK for ; Mon, 11 Aug 2014 20:49:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FFC41A0051 for ; Mon, 11 Aug 2014 20:49:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLD17940; Tue, 12 Aug 2014 03:49:50 +0000 (GMT) Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Aug 2014 04:49:48 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.44]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.03.0158.001; Tue, 12 Aug 2014 11:49:42 +0800 From: "Hedanping (Ana)" To: "ace@ietf.org" Thread-Topic: About secure relay of authentication and authroization messages Thread-Index: Ac+14HKaNsIvXfkCR+GMdpE7gBKO3A== Date: Tue, 12 Aug 2014 03:49:42 +0000 Message-ID: <77FA386512F0D748BC7C02C36EB1106D8D4164@szxeml557-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.95.23] Content-Type: multipart/alternative; boundary="_000_77FA386512F0D748BC7C02C36EB1106D8D4164szxeml557mbschina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/Zf7OcJLK4PAiHObZpnrTrtFUCks Subject: [Ace] About secure relay of authentication and authroization messages X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 03:49:54 -0000 --_000_77FA386512F0D748BC7C02C36EB1106D8D4164szxeml557mbschina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, There is an issue that I am not sure whether it is suitable for a draft: sh= ould we consider secure relay of the Authentication and authorization (AA) = messages to protect relay elements along the relay path? DTLS relay and PANA relay have been proposed, however the relay elements si= mply relays the AA messages to the server. To avoid DOS attack, the they li= mit the frequency and maximum number of times to relay the AA requests. In constraint environment, the relay elements might be energy constrained d= evices. If a malicious client intends to exhaust the relay elements' power = by frequently sending AA requests with forged IPs or IDs, is there any coun= termeasure to this issue? Do we need to consider this issue in ACE WG? Regards, Danping --_000_77FA386512F0D748BC7C02C36EB1106D8D4164szxeml557mbschina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

There is an issue that I am not= sure whether it is suitable for a draft: should we consider secure relay o= f the Authentication and authorization (AA) messages to protect relay eleme= nts along the relay path?

 

DTLS relay and PANA relay have = been proposed, however the relay elements simply relays the AA messages to = the server. To avoid DOS attack, the they limit the frequency and maximum n= umber of times to relay the AA requests.

 

In constraint environment, the = relay elements might be energy constrained devices. If a malicious client i= ntends to exhaust the relay elements’ power by frequently sending AA = requests with forged IPs or IDs, is there any countermeasure to this issue? Do we need to consider this issue in ACE= WG?

Regards,

Danping

--_000_77FA386512F0D748BC7C02C36EB1106D8D4164szxeml557mbschina_-- From nobody Tue Aug 12 01:20:53 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB9A1A0790 for ; Tue, 12 Aug 2014 01:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaU8p2RE33mO for ; Tue, 12 Aug 2014 01:20:45 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0014.outbound.protection.outlook.com [213.199.154.14]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93D8F1A0787 for ; Tue, 12 Aug 2014 01:20:43 -0700 (PDT) Received: from DB3PR04CA006.eurprd04.prod.outlook.com (10.242.134.26) by DB3PR04MB0635.eurprd04.prod.outlook.com (25.160.45.149) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Tue, 12 Aug 2014 08:20:39 +0000 Received: from AM1FFO11FD015.protection.gbl (2a01:111:f400:7e00::192) by DB3PR04CA006.outlook.office365.com (2a01:111:e400:9814::26) with Microsoft SMTP Server (TLS) id 15.0.1005.10 via Frontend Transport; Tue, 12 Aug 2014 08:20:39 +0000 Received: from mail.philips.com (206.191.240.52) by AM1FFO11FD015.mail.protection.outlook.com (10.174.64.93) with Microsoft SMTP Server (TLS) id 15.0.1010.11 via Frontend Transport; Tue, 12 Aug 2014 08:20:38 +0000 Received: from DBXPRD9003MB059.MGDPHG.emi.philips.com ([169.254.7.111]) by DBXPRD9003HT001.MGDPHG.emi.philips.com ([141.251.25.206]) with mapi id 14.16.0466.000; Tue, 12 Aug 2014 08:20:37 +0000 From: "Kumar, Sandeep" To: "Hedanping (Ana)" , "ace@ietf.org" Thread-Topic: [Ace] About secure relay of authentication and authroization messages Thread-Index: Ac+14HKaNsIvXfkCR+GMdpE7gBKO3AAJOfvQ Date: Tue, 12 Aug 2014 08:20:36 +0000 Message-ID: References: <77FA386512F0D748BC7C02C36EB1106D8D4164@szxeml557-mbs.china.huawei.com> In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D8D4164@szxeml557-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.108] Content-Type: multipart/alternative; boundary="_000_BE6D13F6A4554947952B39008B0DC0153E809F78DBXPRD9003MB059_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:206.191.240.52; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(428002)(85714005)(55904004)(57704003)(377454003)(189002)(199003)(85306004)(21056001)(4396001)(104016003)(84326002)(99396002)(33656002)(15975445006)(19300405004)(66066001)(95666004)(80022001)(81156004)(105586002)(106466001)(84676001)(77096002)(85852003)(101416001)(512954002)(20776003)(86362001)(2656002)(31966008)(74662001)(15202345003)(71186001)(79102001)(77982001)(76482001)(55846006)(92726001)(16236675004)(46102001)(92566001)(107886001)(76176999)(69596002)(87936001)(50986999)(19625215002)(97736001)(6806004)(107046002)(19580405001)(68736004)(83072002)(74502001)(54356999)(81542001)(83322001)(19580395003)(2501001)(567094001); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR04MB0635; H:mail.philips.com; FPR:; MLV:sfv; PTR:ErrorRetry; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 0301360BF5 Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is 206.191.240.52) smtp.mailfrom=sandeep.kumar@philips.com; X-OriginatorOrg: philips.com Archived-At: http://mailarchive.ietf.org/arch/msg/ace/O6C809fsdTIT_0accugGXxiOJrQ Subject: Re: [Ace] About secure relay of authentication and authroization messages X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 08:20:49 -0000 --_000_BE6D13F6A4554947952B39008B0DC0153E809F78DBXPRD9003MB059_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Danping I think ACE is at a very early stage that it is better to first solve the p= roblem without the relay path. At a later stage, the relay path can be adde= d for scenarios that might need them and ofcourse DoS protection will be an= important issue to consider then. Do you have any specific solutions to so= lve the problem? If the DoS protection solution depends heavily on the AA d= ata then imho it should be solved in ACE. Regards Sandeep From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hedanping (Ana) Sent: Tuesday, August 12, 2014 5:50 AM To: ace@ietf.org Subject: [Ace] About secure relay of authentication and authroization messa= ges Hi, There is an issue that I am not sure whether it is suitable for a draft: sh= ould we consider secure relay of the Authentication and authorization (AA) = messages to protect relay elements along the relay path? DTLS relay and PANA relay have been proposed, however the relay elements si= mply relays the AA messages to the server. To avoid DOS attack, the they li= mit the frequency and maximum number of times to relay the AA requests. In constraint environment, the relay elements might be energy constrained d= evices. If a malicious client intends to exhaust the relay elements' power = by frequently sending AA requests with forged IPs or IDs, is there any coun= termeasure to this issue? Do we need to consider this issue in ACE WG? Regards, Danping ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_BE6D13F6A4554947952B39008B0DC0153E809F78DBXPRD9003MB059_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Da= nping

=  

I thi= nk ACE is at a very early stage that it is better to first solve the proble= m without the relay path. At a later stage, the relay path can be added for= scenarios that might need them and ofcourse DoS protection will be an important issue to consider then. Do yo= u have any specific solutions to solve the problem? If the DoS protection s= olution depends heavily on the AA data then imho it should be solved in ACE= .

=  

Regar= ds

Sande= ep  

=  

From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hedanping (Ana)
Sent: Tuesday, August 12, 2014 5:50 AM
To: ace@ietf.org
Subject: [Ace] About secure relay of authentication and authroizatio= n messages

 =

Hi, =

There is = an issue that I am not sure whether it is suitable for a draft: should we c= onsider secure relay of the Authentication and authorization (AA) messages = to protect relay elements along the relay path?

&nbs= p;

DTLS rela= y and PANA relay have been proposed, however the relay elements simply rela= ys the AA messages to the server. To avoid DOS attack, the they limit the f= requency and maximum number of times to relay the AA requests.

&nbs= p;

In constr= aint environment, the relay elements might be energy constrained devices. I= f a malicious client intends to exhaust the relay elements’ power by = frequently sending AA requests with forged IPs or IDs, is there any countermeasure to this issue? Do we need to consi= der this issue in ACE WG?

&nbs= p;

Regards,<= o:p>

Danping


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_BE6D13F6A4554947952B39008B0DC0153E809F78DBXPRD9003MB059_-- From nobody Tue Aug 12 17:58:09 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357AD1A6EF8 for ; Tue, 12 Aug 2014 17:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwY2l4phezME for ; Tue, 12 Aug 2014 17:58:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB7231A0AD9 for ; Tue, 12 Aug 2014 17:58:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIE44151; Wed, 13 Aug 2014 00:58:01 +0000 (GMT) Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 Aug 2014 01:58:00 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.44]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.03.0158.001; Wed, 13 Aug 2014 08:57:56 +0800 From: "Hedanping (Ana)" To: "Kumar, Sandeep" , "ace@ietf.org" Thread-Topic: [Ace] About secure relay of authentication and authroization messages Thread-Index: AQHPtpGd1jSZboQ4OUmhg7LIrnqs+A== Date: Wed, 13 Aug 2014 00:57:55 +0000 Message-ID: <77FA386512F0D748BC7C02C36EB1106D8D4220@szxeml557-mbs.china.huawei.com> References: <77FA386512F0D748BC7C02C36EB1106D8D4164@szxeml557-mbs.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.95.23] Content-Type: multipart/alternative; boundary="_000_77FA386512F0D748BC7C02C36EB1106D8D4220szxeml557mbschina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/TW7Dx68NPImkA9X4KrMwlY5VkCg Subject: Re: [Ace] About secure relay of authentication and authroization messages X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 00:58:07 -0000 --_000_77FA386512F0D748BC7C02C36EB1106D8D4220szxeml557mbschina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sandeep, Thanks for the information and also thank you for showing interest in this = issue. The assumption is that, during the AA procedure, there are AA messages exch= anged between the C and RS, which are not directly connected. To solve DOS = attack, I roughly have a solution in mind: A relay key/certificate is needed. There might exist more than one RE along= the path between C and RS. The first RE in the path checks whether C holds= a valid certificate or a pre-shared relay key. If verified, the AA message= s from C are relayed normally. Otherwise, the AA messages from C are ignore= d. Regards, Danping From: Kumar, Sandeep [mailto:sandeep.kumar@philips.com] Sent: Tuesday, August 12, 2014 4:21 PM To: Hedanping (Ana); ace@ietf.org Subject: RE: [Ace] About secure relay of authentication and authroization m= essages Hi Danping I think ACE is at a very early stage that it is better to first solve the p= roblem without the relay path. At a later stage, the relay path can be adde= d for scenarios that might need them and ofcourse DoS protection will be an= important issue to consider then. Do you have any specific solutions to so= lve the problem? If the DoS protection solution depends heavily on the AA d= ata then imho it should be solved in ACE. Regards Sandeep From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hedanping (Ana) Sent: Tuesday, August 12, 2014 5:50 AM To: ace@ietf.org Subject: [Ace] About secure relay of authentication and authroization messa= ges Hi, There is an issue that I am not sure whether it is suitable for a draft: sh= ould we consider secure relay of the Authentication and authorization (AA) = messages to protect relay elements along the relay path? DTLS relay and PANA relay have been proposed, however the relay elements si= mply relays the AA messages to the server. To avoid DOS attack, the they li= mit the frequency and maximum number of times to relay the AA requests. In constraint environment, the relay elements might be energy constrained d= evices. If a malicious client intends to exhaust the relay elements' power = by frequently sending AA requests with forged IPs or IDs, is there any coun= termeasure to this issue? Do we need to consider this issue in ACE WG? Regards, Danping ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_77FA386512F0D748BC7C02C36EB1106D8D4220szxeml557mbschina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sand= eep,

Thanks = for the information and also thank you for showing interest in this issue.<= o:p>

The ass= umption is that, during the AA procedure, there are AA messages exchanged b= etween the C and RS, which are not directly connected. To solve DOS attack,= I roughly have a solution in mind:

=  

= A relay key/certificate is nee= ded. There might exist more than one RE along the path between C and RS. Th= e first RE in the path checks whether C holds a valid certificate or a pre-shared relay key. If verified, the AA m= essages from C are relayed normally. Otherwise, the AA messages from C are = ignored.

=  

Regards= ,

Danping=

From: Kumar, Sande= ep [mailto:sandeep.kumar@philips.com]
Sent: Tuesday, August 12, 2014 4:21 PM
To: Hedanping (Ana); ace@ietf.org
Subject: RE: [Ace] About secure relay of authentication and authroiz= ation messages

 

Hi Danping

 

I think ACE is at a very early stage that it is better to first s= olve the problem without the relay path. At a later stage, the relay path c= an be added for scenarios that might need them and ofcourse DoS protection will be an important issue to consider th= en. Do you have any specific solutions to solve the problem? If the DoS pro= tection solution depends heavily on the AA data then imho it should be solv= ed in ACE.

 

Regards

Sandeep  

 

From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hedanping (Ana)
Sent: Tuesday, August 12, 2014 5:50 AM
To: ace@ietf.org
Subject: [Ace] About secure relay of authentication and authroizatio= n messages

 

Hi,

There is an issue that I am not= sure whether it is suitable for a draft: should we consider secure relay o= f the Authentication and authorization (AA) messages to protect relay eleme= nts along the relay path?

 

DTLS relay and PANA relay have = been proposed, however the relay elements simply relays the AA messages to = the server. To avoid DOS attack, the they limit the frequency and maximum n= umber of times to relay the AA requests.

 

In constraint environment, the = relay elements might be energy constrained devices. If a malicious client i= ntends to exhaust the relay elements’ power by frequently sending AA = requests with forged IPs or IDs, is there any countermeasure to this issue? Do we need to consider this issue in ACE= WG?

 

Regards,

Danping

 

The information contained in this message may be = confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recip= ient, you are hereby notified that any use, forwarding, dissemination, or r= eproduction of this message is strictly prohibited and may be unlawful. If = you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the o= riginal message.

--_000_77FA386512F0D748BC7C02C36EB1106D8D4220szxeml557mbschina_-- From nobody Tue Aug 12 18:24:32 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91C51A6F88 for ; Tue, 12 Aug 2014 18:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UB839uLpo1fp for ; Tue, 12 Aug 2014 18:24:27 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 992B81A6F85 for ; Tue, 12 Aug 2014 18:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s7D1OCaM020609; Wed, 13 Aug 2014 03:24:12 +0200 (CEST) Received: from [192.168.217.145] (p54890709.dip0.t-ipconnect.de [84.137.7.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4A22170; Wed, 13 Aug 2014 03:24:11 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D8D4220@szxeml557-mbs.china.huawei.com> Date: Wed, 13 Aug 2014 03:24:10 +0200 X-Mao-Original-Outgoing-Id: 429585849.987935-84a50ccbacab6caed105fd8bd6c673a0 Content-Transfer-Encoding: quoted-printable Message-Id: References: <77FA386512F0D748BC7C02C36EB1106D8D4164@szxeml557-mbs.china.huawei.com> <77FA386512F0D748BC7C02C36EB1106D8D4220@szxeml557-mbs.china.huawei.com> To: "Hedanping (Ana)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/GJiga6Nk0ZPIzLqnwISrqHJ2Bhc Cc: "Kumar, Sandeep" , "ace@ietf.org" Subject: Re: [Ace] About secure relay of authentication and authroization messages X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 01:24:29 -0000 On 13 Aug 2014, at 02:57, Hedanping (Ana) = wrote: > C and RS, which are not directly connected I=92m confused by this: They sure are, via IP. (ACE is not about network access control, where you often have to run = the authorization *before* sending IP packets.) But maybe I=92m misunderstanding your point. Gr=FC=DFe, Carsten From nobody Tue Aug 12 19:30:11 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461781A6F36 for ; Tue, 12 Aug 2014 19:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L719BoPgwCQ1 for ; Tue, 12 Aug 2014 19:30:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA20E1A6FCA for ; Tue, 12 Aug 2014 19:30:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIE49057; Wed, 13 Aug 2014 02:30:07 +0000 (GMT) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 Aug 2014 03:30:06 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.44]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Wed, 13 Aug 2014 10:30:03 +0800 From: "Hedanping (Ana)" To: Carsten Bormann Thread-Topic: [Ace] About secure relay of authentication and authroization messages Thread-Index: AQHPtpGd1jSZboQ4OUmhg7LIrnqs+JvNN1EAgACOGvA= Date: Wed, 13 Aug 2014 02:30:03 +0000 Message-ID: <77FA386512F0D748BC7C02C36EB1106D8D426A@szxeml557-mbs.china.huawei.com> References: <77FA386512F0D748BC7C02C36EB1106D8D4164@szxeml557-mbs.china.huawei.com> <77FA386512F0D748BC7C02C36EB1106D8D4220@szxeml557-mbs.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.95.23] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/xknLr0lNUVPPCK0h68cbaA-7GbQ Cc: "Kumar, Sandeep" , "ace@ietf.org" Subject: Re: [Ace] About secure relay of authentication and authroization messages X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 02:30:10 -0000 Hi Carsten, I agree that C got the right to access the network, thereafter it has the I= P to communicate. My concern is: C and RS might not always be the neighbors of each other due to weak wirele= ss signal or topology design (imagine a energy constrained WSN with ad-hoc = feature), thus packets between them should be relayed by nodes (Relay Eleme= nts) along the path, which is determined by a certain routing protocol. Fur= thermore, the Relay Elements are likely to be constraint devices, thus the = battery resource and packet buffer will be consumed due to relay packet for= C.=20 Regards, Danping -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: Wednesday, August 13, 2014 9:24 AM To: Hedanping (Ana) Cc: Kumar, Sandeep; ace@ietf.org Subject: Re: [Ace] About secure relay of authentication and authroization m= essages On 13 Aug 2014, at 02:57, Hedanping (Ana) wrote: > C and RS, which are not directly connected I'm confused by this: They sure are, via IP. (ACE is not about network access control, where you often have to run the a= uthorization *before* sending IP packets.) But maybe I'm misunderstanding y= our point. Gr=FC=DFe, Carsten From nobody Wed Aug 13 00:23:51 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522DB1A7016 for ; Wed, 13 Aug 2014 00:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYLY6EB53f8o for ; Wed, 13 Aug 2014 00:23:44 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0011.outbound.protection.outlook.com [213.199.154.11]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 218B81A08D8 for ; Wed, 13 Aug 2014 00:23:44 -0700 (PDT) Received: from DBXPR04CA003.eurprd04.prod.outlook.com (10.255.191.151) by AM2PR04MB0626.eurprd04.prod.outlook.com (25.160.32.152) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Wed, 13 Aug 2014 07:23:34 +0000 Received: from DB3FFO11FD036.protection.gbl (2a01:111:f400:7e04::170) by DBXPR04CA003.outlook.office365.com (2a01:111:e400:9800::23) with Microsoft SMTP Server (TLS) id 15.0.1005.10 via Frontend Transport; Wed, 13 Aug 2014 07:23:34 +0000 Received: from mail.philips.com (206.191.240.52) by DB3FFO11FD036.mail.protection.outlook.com (10.47.217.67) with Microsoft SMTP Server (TLS) id 15.0.1010.11 via Frontend Transport; Wed, 13 Aug 2014 07:23:33 +0000 Received: from DBXPRD9003MB059.MGDPHG.emi.philips.com ([169.254.7.111]) by DBXPRD9003HT001.MGDPHG.emi.philips.com ([141.251.25.206]) with mapi id 14.16.0466.000; Wed, 13 Aug 2014 07:23:32 +0000 From: "Kumar, Sandeep" To: "Hedanping (Ana)" , "ace@ietf.org" Thread-Topic: [Ace] About secure relay of authentication and authroization messages Thread-Index: AQHPtpGlKy5nWFOgdEybsuyAlYWAlJvOIILw Date: Wed, 13 Aug 2014 07:23:31 +0000 Message-ID: References: <77FA386512F0D748BC7C02C36EB1106D8D4164@szxeml557-mbs.china.huawei.com> <77FA386512F0D748BC7C02C36EB1106D8D4220@szxeml557-mbs.china.huawei.com> In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D8D4220@szxeml557-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.108] Content-Type: multipart/alternative; boundary="_000_BE6D13F6A4554947952B39008B0DC0153E80A5FEDBXPRD9003MB059_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:206.191.240.52; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(979002)(428002)(55904004)(85714005)(51914003)(57704003)(13604004)(377454003)(374574003)(189002)(199003)(20776003)(97736001)(31966008)(77982001)(79102001)(85306004)(81342001)(87936001)(76176999)(99396002)(50986999)(19300405004)(512954002)(81542001)(74502001)(74662001)(44976005)(71186001)(15202345003)(33656002)(92566001)(19580395003)(81156004)(106466001)(66066001)(15975445006)(46102001)(76482001)(107886001)(55846006)(4396001)(107046002)(104016003)(101416001)(77096002)(19580405001)(83072002)(85852003)(64706001)(106116001)(69596002)(68736004)(54356999)(80022001)(95666004)(83322001)(84676001)(6806004)(92726001)(19625215002)(2656002)(84326002)(16236675004)(105586002)(86362001)(21056001)(2501001)(567094001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:; SCL:1; SRVR:AM2PR04MB0626; H:mail.philips.com; FPR:; MLV:ovrnspm; PTR:ErrorRetry; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 0302D4F392 Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is 206.191.240.52) smtp.mailfrom=sandeep.kumar@philips.com; X-OriginatorOrg: philips.com Archived-At: http://mailarchive.ietf.org/arch/msg/ace/jCu-xNw9-Bo9HDF_RTYrDa9ehOE Subject: Re: [Ace] About secure relay of authentication and authroization messages X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 07:23:48 -0000 --_000_BE6D13F6A4554947952B39008B0DC0153E80A5FEDBXPRD9003MB059_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI Danping According to your solution "The first RE in the path checks whether C holds= a valid certificate or a pre-shared relay key" which itself is an authenti= cation/authorization decision. Infact it sounds more like an AA decision to= first access the one-hop relay and then an AA decision to access the RS. W= ould it not be simple to consider the relay to be an RS which is one-hop aw= ay and use the not-yet-designed ACE solution for the first-hop too. Regards Sandeep From: Hedanping (Ana) [mailto:ana.hedanping@huawei.com] Sent: Wednesday, August 13, 2014 2:58 AM To: Kumar, Sandeep; ace@ietf.org Subject: RE: [Ace] About secure relay of authentication and authroization m= essages Hi Sandeep, Thanks for the information and also thank you for showing interest in this = issue. The assumption is that, during the AA procedure, there are AA messages exch= anged between the C and RS, which are not directly connected. To solve DOS = attack, I roughly have a solution in mind: A relay key/certificate is needed. There might exist more than one RE along= the path between C and RS. The first RE in the path checks whether C holds= a valid certificate or a pre-shared relay key. If verified, the AA message= s from C are relayed normally. Otherwise, the AA messages from C are ignore= d. Regards, Danping From: Kumar, Sandeep [mailto:sandeep.kumar@philips.com] Sent: Tuesday, August 12, 2014 4:21 PM To: Hedanping (Ana); ace@ietf.org Subject: RE: [Ace] About secure relay of authentication and authroization m= essages Hi Danping I think ACE is at a very early stage that it is better to first solve the p= roblem without the relay path. At a later stage, the relay path can be adde= d for scenarios that might need them and ofcourse DoS protection will be an= important issue to consider then. Do you have any specific solutions to so= lve the problem? If the DoS protection solution depends heavily on the AA d= ata then imho it should be solved in ACE. Regards Sandeep From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hedanping (Ana) Sent: Tuesday, August 12, 2014 5:50 AM To: ace@ietf.org Subject: [Ace] About secure relay of authentication and authroization messa= ges Hi, There is an issue that I am not sure whether it is suitable for a draft: sh= ould we consider secure relay of the Authentication and authorization (AA) = messages to protect relay elements along the relay path? DTLS relay and PANA relay have been proposed, however the relay elements si= mply relays the AA messages to the server. To avoid DOS attack, the they li= mit the frequency and maximum number of times to relay the AA requests. In constraint environment, the relay elements might be energy constrained d= evices. If a malicious client intends to exhaust the relay elements' power = by frequently sending AA requests with forged IPs or IDs, is there any coun= termeasure to this issue? Do we need to consider this issue in ACE WG? Regards, Danping ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_BE6D13F6A4554947952B39008B0DC0153E80A5FEDBXPRD9003MB059_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

HI Da= nping

=  

Accor= ding to your solution “The first RE in the path checks whether C holds a valid c= ertificate or a pre-shared relay key” which itself is an authentication/authorization decision. Infact it sounds more = like an AA decision to first access the one-hop relay and then an AA decisi= on to access the RS. Would it not be simple to consider the relay to be an = RS which is one-hop away and use the not-yet-designed ACE solution for the first-hop too.=

 

Regards

Sandeep

=  

From: Hedanping (Ana) [mailto:ana.hedanping@huaw= ei.com]
Sent: Wednesday, August 13, 2014 2:58 AM
To: Kumar, Sandeep; ace@ietf.org
Subject: RE: [Ace] About secure relay of authentication and authroiz= ation messages

 =

Hi Sandeep,

Thanks for the information and also thank you for showing interest in = this issue.

The assumption is that, during the AA procedure, there are AA messages= exchanged between the C and RS, which are not directly connected. To solve= DOS attack, I roughly have a solution in mind:

<= span style=3D"color:#1F497D;mso-fareast-language:ZH-CN"> 

<= span style=3D"color:#1F497D;mso-fareast-language:ZH-CN">A relay key/certifi= cate is needed. There might exist more than one RE along the path between C= and RS. The first RE in the path checks whether C holds a valid certificate or a pre-shared relay key. If verified= , the AA messages from C are relayed normally. Otherwise, the AA messages f= rom C are ignored.

<= span style=3D"color:#1F497D;mso-fareast-language:ZH-CN"> 

Regards,

Danping

 

Hi Danping

 

I think ACE is at a very early stage that it is bette= r to first solve the problem without the relay path. At a later stage, the = relay path can be added for scenarios that might need them and ofcourse DoS protection will be an important issu= e to consider then. Do you have any specific solutions to solve the problem= ? If the DoS protection solution depends heavily on the AA data then imho i= t should be solved in ACE.

 

Regards

Sandeep  

 

 

Hi, =

There is = an issue that I am not sure whether it is suitable for a draft: should we c= onsider secure relay of the Authentication and authorization (AA) messages = to protect relay elements along the relay path?

&nbs= p;

DTLS rela= y and PANA relay have been proposed, however the relay elements simply rela= ys the AA messages to the server. To avoid DOS attack, the they limit the f= requency and maximum number of times to relay the AA requests.

&nbs= p;

In constr= aint environment, the relay elements might be energy constrained devices. I= f a malicious client intends to exhaust the relay elements’ power by = frequently sending AA requests with forged IPs or IDs, is there any countermeasure to this issue? Do we need to consi= der this issue in ACE WG?

&nbs= p;

Regards,<= o:p>

Danping

 

The information contained in this mess= age may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not t= he intended recipient, you are hereby notified that any use, forwarding, di= ssemination, or reproduction of this message is strictly prohibited and may= be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy= all copies of the original message.

--_000_BE6D13F6A4554947952B39008B0DC0153E80A5FEDBXPRD9003MB059_-- From nobody Thu Aug 14 20:35:36 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6511A08B8 for ; Thu, 14 Aug 2014 20:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4nRdRlnRCqX for ; Thu, 14 Aug 2014 20:35:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF78A1A0807 for ; Thu, 14 Aug 2014 20:35:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIG55489; Fri, 15 Aug 2014 03:35:30 +0000 (GMT) Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Aug 2014 04:35:27 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.44]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.03.0158.001; Fri, 15 Aug 2014 11:35:21 +0800 From: "Hedanping (Ana)" To: "Kumar, Sandeep" , "ace@ietf.org" Thread-Topic: [Ace] About secure relay of authentication and authroization messages Thread-Index: AQHPtpGd1jSZboQ4OUmhg7LIrnqs+JvNm7iAgANfoeA= Date: Fri, 15 Aug 2014 03:35:21 +0000 Message-ID: <77FA386512F0D748BC7C02C36EB1106D8D473D@szxeml557-mbs.china.huawei.com> References: <77FA386512F0D748BC7C02C36EB1106D8D4164@szxeml557-mbs.china.huawei.com> <77FA386512F0D748BC7C02C36EB1106D8D4220@szxeml557-mbs.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.95.23] Content-Type: multipart/alternative; boundary="_000_77FA386512F0D748BC7C02C36EB1106D8D473Dszxeml557mbschina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/M5Y4cVt1eB00sqOV3HR70O2yl00 Subject: Re: [Ace] About secure relay of authentication and authroization messages X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 03:35:35 -0000 --_000_77FA386512F0D748BC7C02C36EB1106D8D473Dszxeml557mbschina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sandeep, According to your solution "The first RE in the path checks whether C holds= a valid certificate or a pre-shared relay key" which itself is an authenti= cation/authorization decision. Infact it sounds more like an AA decision to= first access the one-hop relay and then an AA decision to access the RS. [Danping] Your understanding is right. In unconstraint environment, Relay = Elements simply relay the packets to destination. And as we know, the REs = are likely to be constraint devices in constraint environment such as ad ho= c WSNs, thus the battery resource and packet buffer will be consumed due to= relaying packet for C. In other words, to request resources over a RS that= is multiple hops away intrinsically hints a request of the resource over R= Es along the hops. Therefore I believe the a light AA is desired for the f= irst-hop relay to protect itself and other REs along the route. Would it not be simple to consider the relay to be an RS which is one-hop a= way and use the not-yet-designed ACE solution for the first-hop too. [Danping] It would be better to design a mechanism which allows AM/AS issui= ng a permission for C to access the first-hop RE, the permission might be t= ransmitted separately or piggybacked with the first AA message between C an= d RS. The not-yet-designed ACE solution might be used too, but it is unnece= ssary to exchange key to secure the relay message and the message flow woul= d be different. What do you think? Regards, Danping From: Kumar, Sandeep [mailto:sandeep.kumar@philips.com] Sent: Wednesday, August 13, 2014 3:24 PM To: Hedanping (Ana); ace@ietf.org Subject: RE: [Ace] About secure relay of authentication and authroization m= essages HI Danping According to your solution "The first RE in the path checks whether C holds= a valid certificate or a pre-shared relay key" which itself is an authenti= cation/authorization decision. Infact it sounds more like an AA decision to= first access the one-hop relay and then an AA decision to access the RS. W= ould it not be simple to consider the relay to be an RS which is one-hop aw= ay and use the not-yet-designed ACE solution for the first-hop too. Regards Sandeep From: Hedanping (Ana) [mailto:ana.hedanping@huawei.com] Sent: Wednesday, August 13, 2014 2:58 AM To: Kumar, Sandeep; ace@ietf.org Subject: RE: [Ace] About secure relay of authentication and authroization m= essages Hi Sandeep, Thanks for the information and also thank you for showing interest in this = issue. The assumption is that, during the AA procedure, there are AA messages exch= anged between the C and RS, which are not directly connected. To solve DOS = attack, I roughly have a solution in mind: A relay key/certificate is needed. There might exist more than one RE along= the path between C and RS. The first RE in the path checks whether C holds= a valid certificate or a pre-shared relay key. If verified, the AA message= s from C are relayed normally. Otherwise, the AA messages from C are ignore= d. Regards, Danping From: Kumar, Sandeep [mailto:sandeep.kumar@philips.com] Sent: Tuesday, August 12, 2014 4:21 PM To: Hedanping (Ana); ace@ietf.org Subject: RE: [Ace] About secure relay of authentication and authroization m= essages Hi Danping I think ACE is at a very early stage that it is better to first solve the p= roblem without the relay path. At a later stage, the relay path can be adde= d for scenarios that might need them and ofcourse DoS protection will be an= important issue to consider then. Do you have any specific solutions to so= lve the problem? If the DoS protection solution depends heavily on the AA d= ata then imho it should be solved in ACE. Regards Sandeep From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hedanping (Ana) Sent: Tuesday, August 12, 2014 5:50 AM To: ace@ietf.org Subject: [Ace] About secure relay of authentication and authroization messa= ges Hi, There is an issue that I am not sure whether it is suitable for a draft: sh= ould we consider secure relay of the Authentication and authorization (AA) = messages to protect relay elements along the relay path? DTLS relay and PANA relay have been proposed, however the relay elements si= mply relays the AA messages to the server. To avoid DOS attack, the they li= mit the frequency and maximum number of times to relay the AA requests. In constraint environment, the relay elements might be energy constrained d= evices. If a malicious client intends to exhaust the relay elements' power = by frequently sending AA requests with forged IPs or IDs, is there any coun= termeasure to this issue? Do we need to consider this issue in ACE WG? Regards, Danping ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_77FA386512F0D748BC7C02C36EB1106D8D473Dszxeml557mbschina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sand= eep,

According to your solution “The first RE in the path checks whether C holds a vali= d certificate or a pre-shared relay key” which itself is an authentication/authorization decision. Infact it sounds more like an= AA decision to first access the one-hop relay and then an AA decision to a= ccess the RS.

[Dan= ping] Your understanding is right.  In unconstraint environment, Relay= Elements simply relay the packets to destination. And as we know,  th= e REs are likely to be constraint devices in constraint environment such as ad hoc WSNs, thus the battery resource and packet buff= er will be consumed due to relaying packet for C. In other words, to reques= t resources over a RS that is multiple hops away intrinsically hints a requ= est of the resource over REs along the hops.  Therefore I believe the a light AA is desired for the firs= t-hop relay to protect itself and other REs along the route.

&n= bsp;

Would i= t not be simple to consider the relay to be an RS which is one-hop away and= use the not-yet-designed ACE solution for the first-hop too.

[Dan= ping] It would be better to design a mechanism which allows AM/AS issuing a= permission for C to access the first-hop RE, the permission might be trans= mitted separately or piggybacked with the first AA message between C and RS. The not-yet-designed ACE solution m= ight be used too, but it is unnecessary to exchange key to secure the relay= message and the message flow would be different.  What do you think?<= o:p>

 

Rega= rds,

Danp= ing

&n= bsp;

&n= bsp;

From: Kumar, Sande= ep [mailto:sandeep.kumar@philips.com]
Sent: Wednesday, August 13, 2014 3:24 PM
To: Hedanping (Ana); ace@ietf.org
Subject: RE: [Ace] About secure relay of authentication and authroiz= ation messages

 

HI Danping

 

According to your solution “The first RE in the path checks whether C holds a vali= d certificate or a pre-shared relay key” which itself is an authentication/authorization decision. Infact it sounds more like an= AA decision to first access the one-hop relay and then an AA decision to a= ccess the RS. Would it not be simple to consider the relay to be an RS whic= h is one-hop away and use the not-yet-designed ACE solution for the first-hop too.

&n= bsp;

Regards=

Sandeep= <= /o:p>

 

From: Hedanping (A= na) [mailto:ana.hedanping@huawe= i.com]
Sent: Wednesday, August 13, 2014 2:58 AM
To: Kumar, Sandeep; ace@ietf.org=
Subject: RE: [Ace] About secure relay of authentication and authroiz= ation messages

 

Hi Sand= eep,

Thanks = for the information and also thank you for showing interest in this issue.<= o:p>

The ass= umption is that, during the AA procedure, there are AA messages exchanged b= etween the C and RS, which are not directly connected. To solve DOS attack,= I roughly have a solution in mind:

=  

= A relay key/certificate is nee= ded. There might exist more than one RE along the path between C and RS. Th= e first RE in the path checks whether C holds a valid certificate or a pre-shared relay key. If verified, the AA m= essages from C are relayed normally. Otherwise, the AA messages from C are = ignored.

=  

Regards= ,

Danping=

 

Hi Danping

 

I think ACE is at a very early stage that it is better to first s= olve the problem without the relay path. At a later stage, the relay path c= an be added for scenarios that might need them and ofcourse DoS protection will be an important issue to consider th= en. Do you have any specific solutions to solve the problem? If the DoS pro= tection solution depends heavily on the AA data then imho it should be solv= ed in ACE.

 

Regards

Sandeep  

 

From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hedanping (Ana)
Sent: Tuesday, August 12, 2014 5:50 AM
To: ace@ietf.org
Subject: [Ace] About secure relay of authentication and authroizatio= n messages

 

Hi,

There is an issue that I am not= sure whether it is suitable for a draft: should we consider secure relay o= f the Authentication and authorization (AA) messages to protect relay eleme= nts along the relay path?

 

DTLS relay and PANA relay have = been proposed, however the relay elements simply relays the AA messages to = the server. To avoid DOS attack, the they limit the frequency and maximum n= umber of times to relay the AA requests.

 

In constraint environment, the = relay elements might be energy constrained devices. If a malicious client i= ntends to exhaust the relay elements’ power by frequently sending AA = requests with forged IPs or IDs, is there any countermeasure to this issue? Do we need to consider this issue in ACE= WG?

 

Regards,

Danping

 

The information contained in this message may be = confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recip= ient, you are hereby notified that any use, forwarding, dissemination, or r= eproduction of this message is strictly prohibited and may be unlawful. If = you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the o= riginal message.

--_000_77FA386512F0D748BC7C02C36EB1106D8D473Dszxeml557mbschina_-- From nobody Fri Aug 15 00:13:17 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550F81A0778 for ; Fri, 15 Aug 2014 00:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UY-_VNMBLI4d for ; Fri, 15 Aug 2014 00:13:09 -0700 (PDT) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BE4E1A0751 for ; Fri, 15 Aug 2014 00:13:09 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id g18so1802625oah.6 for ; Fri, 15 Aug 2014 00:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=DgFJ2ORmC1TLzwM4lrbzMggCyiDfKHiwcRY/lO+slEU=; b=k9PbSj4gQMTkAZNLt9inO7G/Mm1Oz7GjuD32Jv7vNM2goybJMeILqSbsEnqvtPr+/u lr7kzipbmZ7iLQGbgDpftYZE7kjXAmVc5eqtIkQMvdtmuDmU17AAAzPHRREKlR/N9YQM 9m3RTvsL3eZHFYC3x0lXARHfJtQgj+Nc01ZWUTCb2yEEVO3+hEVF8LHseSJEIdD7ecMT /LQLdkr1TgRtxQ6T3BKxBzbeiwLMD4s893RgA6ccjz3tzn86S8Drd9CtQ12p9wwbGe1b uQaTAF6INDsZz1HKKbgU4+K46b89zwjvpJIxO2TxEmXTb1vQTUMbCIWgxTl6t2ZcK7ll YMwA== MIME-Version: 1.0 X-Received: by 10.60.146.176 with SMTP id td16mr18620117oeb.28.1408086788982; Fri, 15 Aug 2014 00:13:08 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.202.206.1 with HTTP; Fri, 15 Aug 2014 00:13:08 -0700 (PDT) Received: by 10.202.206.1 with HTTP; Fri, 15 Aug 2014 00:13:08 -0700 (PDT) In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D8D473D@szxeml557-mbs.china.huawei.com> References: <77FA386512F0D748BC7C02C36EB1106D8D4164@szxeml557-mbs.china.huawei.com> <77FA386512F0D748BC7C02C36EB1106D8D4220@szxeml557-mbs.china.huawei.com> <77FA386512F0D748BC7C02C36EB1106D8D473D@szxeml557-mbs.china.huawei.com> Date: Fri, 15 Aug 2014 08:13:08 +0100 X-Google-Sender-Auth: 2gsQQlcmOdjlqvZU9uaN2s42lxQ Message-ID: From: Robert Cragie To: "Hedanping (Ana)" Content-Type: multipart/alternative; boundary=047d7b5d4b46decd5b0500a5c01c Archived-At: http://mailarchive.ietf.org/arch/msg/ace/2y7Lb6fk9NDDH1obkKC6q4NCHZU Cc: "Kumar, Sandeep" , ace@ietf.org Subject: Re: [Ace] About secure relay of authentication and authroization messages X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 07:13:12 -0000 --047d7b5d4b46decd5b0500a5c01c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with Sandeep's assessment also; the access from C to the first RE should be modelled in a similar way as C to RS. This meta-modelling, i.e. modelling an AA resource as a resource almost always comes up and can result in a "death spiral" of dependency if not modelled carefully, e.g. an ACL is a resource, which needs an ACL, which is a resource, which needs an ACL... In a constrained environment, the access to the RE must be carefully controlled and may contain static/implicit rules regarding access. The RE is then considered a pass-through for a higher-layer access; this in itself may be layered any number of times before end-to-end is achieved, which may or may not imply IP connectivity end-to-end but as Carsten has pointed out, that is the assumption for the specific problem statement. An RE is thus a pass-through intermediary; whilst we have generally postponed discussion on intermediaries, this layered approach could potentially apply to both pass-through and proxy intermediaries. Robert On 15 Aug 2014 04:35, "Hedanping (Ana)" wrote: > Hi Sandeep, > > According to your solution =E2=80=9CThe first RE in the path checks wheth= er C > holds a valid certificate or a pre-shared relay key=E2=80=9D which itself= is an > authentication/authorization decision. Infact it sounds more like an AA > decision to first access the one-hop relay and then an AA decision to > access the RS. > > [Danping] Your understanding is right. In unconstraint environment, Rela= y > Elements simply relay the packets to destination. And as we know, the RE= s > are likely to be constraint devices in constraint environment such as ad > hoc WSNs, thus the battery resource and packet buffer will be consumed du= e > to relaying packet for C. In other words, to request resources over a RS > that is multiple hops away intrinsically hints a request of the resource > over REs along the hops. Therefore I believe the a light AA is desired f= or > the first-hop relay to protect itself and other REs along the route. > > > > Would it not be simple to consider the relay to be an RS which is one-hop > away and use the not-yet-designed ACE solution for the first-hop too. > > [Danping] It would be better to design a mechanism which allows AM/AS > issuing a permission for C to access the first-hop RE, the permission mig= ht > be transmitted separately or piggybacked with the first AA message betwee= n > C and RS. The not-yet-designed ACE solution might be used too, but it is > unnecessary to exchange key to secure the relay message and the message > flow would be different. What do you think? > > > > Regards, > > Danping > > > > > > *From:* Kumar, Sandeep [mailto:sandeep.kumar@philips.com] > *Sent:* Wednesday, August 13, 2014 3:24 PM > *To:* Hedanping (Ana); ace@ietf.org > *Subject:* RE: [Ace] About secure relay of authentication and > authroization messages > > > > HI Danping > > > > According to your solution =E2=80=9CThe first RE in the path checks wheth= er C > holds a valid certificate or a pre-shared relay key=E2=80=9D which itself= is an > authentication/authorization decision. Infact it sounds more like an AA > decision to first access the one-hop relay and then an AA decision to > access the RS. Would it not be simple to consider the relay to be an RS > which is one-hop away and use the not-yet-designed ACE solution for the > first-hop too. > > > > Regards > > Sandeep > > > > *From:* Hedanping (Ana) [mailto:ana.hedanping@huawei.com > ] > *Sent:* Wednesday, August 13, 2014 2:58 AM > *To:* Kumar, Sandeep; ace@ietf.org > *Subject:* RE: [Ace] About secure relay of authentication and > authroization messages > > > > Hi Sandeep, > > Thanks for the information and also thank you for showing interest in thi= s > issue. > > The assumption is that, during the AA procedure, there are AA messages > exchanged between the C and RS, which are not directly connected. To solv= e > DOS attack, I roughly have a solution in mind: > > > > A relay key/certificate is needed. There might exist more than one RE > along the path between C and RS. The first RE in the path checks whether = C > holds a valid certificate or a pre-shared relay key. If verified, the AA > messages from C are relayed normally. Otherwise, the AA messages from C a= re > ignored. > > > > Regards, > > Danping > > *From:* Kumar, Sandeep [mailto:sandeep.kumar@philips.com > ] > *Sent:* Tuesday, August 12, 2014 4:21 PM > *To:* Hedanping (Ana); ace@ietf.org > *Subject:* RE: [Ace] About secure relay of authentication and > authroization messages > > > > Hi Danping > > > > I think ACE is at a very early stage that it is better to first solve the > problem without the relay path. At a later stage, the relay path can be > added for scenarios that might need them and ofcourse DoS protection will > be an important issue to consider then. Do you have any specific solution= s > to solve the problem? If the DoS protection solution depends heavily on t= he > AA data then imho it should be solved in ACE. > > > > Regards > > Sandeep > > > > *From:* Ace [mailto:ace-bounces@ietf.org ] *On > Behalf Of *Hedanping (Ana) > *Sent:* Tuesday, August 12, 2014 5:50 AM > *To:* ace@ietf.org > *Subject:* [Ace] About secure relay of authentication and authroization > messages > > > > Hi, > > There is an issue that I am not sure whether it is suitable for a draft: > should we consider secure relay of the Authentication and authorization > (AA) messages to protect relay elements along the relay path? > > > > DTLS relay and PANA relay have been proposed, however the relay elements > simply relays the AA messages to the server. To avoid DOS attack, the the= y > limit the frequency and maximum number of times to relay the AA requests. > > > > In constraint environment, the relay elements might be energy constrained > devices. If a malicious client intends to exhaust the relay elements=E2= =80=99 power > by frequently sending AA requests with forged IPs or IDs, is there any > countermeasure to this issue? Do we need to consider this issue in ACE WG= ? > > > > Regards, > > Danping > > > ------------------------------ > > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby > notified that any use, forwarding, dissemination, or reproduction of this > message is strictly prohibited and may be unlawful. If you are not the > intended recipient, please contact the sender by return e-mail and destro= y > all copies of the original message. > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > --047d7b5d4b46decd5b0500a5c01c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I agree with Sandeep's assessment also; the access from = C to the first RE should be modelled in a similar way as C to RS. This meta= -modelling, i.e. modelling an AA resource as a resource almost always comes= up and can result in a "death spiral" of dependency if not model= led carefully, e.g. an ACL is a resource, which needs an ACL,=C2=A0 which i= s a resource, which needs an ACL...

In a constrained environment, the access to the RE must be c= arefully controlled and may contain static/implicit rules regarding access.= The RE is then considered a pass-through for a higher-layer access; this i= n itself may be layered any number of times before end-to-end is achieved, = which may or may not imply IP connectivity end-to-end but as Carsten has po= inted out, that is the assumption for the specific problem statement.

An RE is thus a pass-through intermediary; whilst we have ge= nerally postponed discussion on intermediaries, this layered approach could= potentially apply to both pass-through and proxy intermediaries.

Robert

On 15 Aug 2014 04:35, "Hedanping (Ana)"= ; <ana.hedanping@huawei.com<= /a>> wrote:

Hi Sand= eep,

According to your solution =E2=80=9CThe first RE in the path checks whether C holds a va= lid certificate or a pre-shared relay key=E2=80=9D which itself is an authentication/authorization decision. Infact it sounds more like an= AA decision to first access the one-hop relay and then an AA decision to a= ccess the RS.

[Danping] Your understandin= g is right.=C2=A0 In unconstraint environment, Relay Elements simply relay = the packets to destination. And as we know, =C2=A0the REs are likely to be = constraint devices in constraint environment such as ad hoc WSNs, thus the battery resource and packet buff= er will be consumed due to relaying packet for C. In other words, to reques= t resources over a RS that is multiple hops away intrinsically hints a requ= est of the resource over REs along the hops. =C2=A0Therefore I believe the a light AA is desired for the firs= t-hop relay to protect itself and other REs along the route.<= /span>

= =C2=A0

Would i= t not be simple to consider the relay to be an RS which is one-hop away and= use the not-yet-designed ACE solution for the first-hop too.=

[Danping] It would be bette= r to design a mechanism which allows AM/AS issuing a permission for C to ac= cess the first-hop RE, the permission might be transmitted separately or pi= ggybacked with the first AA message between C and RS. The not-yet-designed ACE solution m= ight be used too, but it is unnecessary to exchange key to secure the relay= message and the message flow would be different. =C2=A0What do you think?<= u>

=C2=A0=

Regards,

Danping

= =C2=A0

= =C2=A0

From: Kumar, Sande= ep [mailto:s= andeep.kumar@philips.com]
Sent: Wednesday, August 13, 2014 3:24 PM
To: Hedanping (Ana); ace@ietf.org
Subject: RE: [Ace] About secure relay of authentication and authroiz= ation messages

=C2=A0

HI Danping

=C2=A0

According to your solution =E2=80=9CThe first RE in the path checks whether C holds a va= lid certificate or a pre-shared relay key=E2=80=9D which itself is an authentication/authorization decision. Infact it sounds more like an= AA decision to first access the one-hop relay and then an AA decision to a= ccess the RS. Would it not be simple to consider the relay to be an RS whic= h is one-hop away and use the not-yet-designed ACE solution for the first-hop too.

= =C2=A0

Regards=

Sandeep=

=C2=A0

From: Hedanping (A= na) [mailto:a= na.hedanping@huawei.com]
Sent: Wednesday, August 13, 2014 2:58 AM
To: Kumar, Sandeep; ace@ietf.org
Subject: RE: [Ace] About secure relay of authentication and authroiz= ation messages

=C2=A0

Hi Sand= eep,

Thanks = for the information and also thank you for showing interest in this issue.<= u>

The ass= umption is that, during the AA procedure, there are AA messages exchanged b= etween the C and RS, which are not directly connected. To solve DOS attack,= I roughly have a solution in mind:

=C2=A0

A relay key/certificate is needed. There might exist mor= e than one RE along the path between C and RS. The first RE in the path che= cks whether C holds a valid certificate or a pre-shared relay key. If verified, the AA m= essages from C are relayed normally. Otherwise, the AA messages from C are = ignored.

=C2=A0

Regards= ,

Danping=

From: Kumar, Sande= ep [mailto:s= andeep.kumar@philips.com]
Sent: Tuesday, August 12, 2014 4:21 PM
To: Hedanping (Ana); ace@ietf.org
Subject: RE: [Ace] About secure relay of authentication and authroiz= ation messages

=C2=A0

Hi Danping

=C2=A0

I think ACE is at a very early stage that it is better to first s= olve the problem without the relay path. At a later stage, the relay path c= an be added for scenarios that might need them and ofcourse DoS protection will be an important issue to consider th= en. Do you have any specific solutions to solve the problem? If the DoS pro= tection solution depends heavily on the AA data then imho it should be solv= ed in ACE.

=C2=A0

Regards

Sandeep =C2=A0

=C2=A0

From: Ace [mailto:ace-bounces@ietf.= org] On Behalf Of Hedanping (Ana)
Sent: Tuesday, August 12, 2014 5:50 AM
To: ace@ietf.org
Subject: [Ace] About secure relay of authentication and authroizatio= n messages

=C2=A0

Hi,

There is an issue that I am not= sure whether it is suitable for a draft: should we consider secure relay o= f the Authentication and authorization (AA) messages to protect relay eleme= nts along the relay path?

=C2=A0

DTLS relay and PANA relay have = been proposed, however the relay elements simply relays the AA messages to = the server. To avoid DOS attack, the they limit the frequency and maximum n= umber of times to relay the AA requests.

=C2=A0

In constraint environment, the = relay elements might be energy constrained devices. If a malicious client i= ntends to exhaust the relay elements=E2=80=99 power by frequently sending A= A requests with forged IPs or IDs, is there any countermeasure to this issue? Do we need to consider this issue in ACE= WG?

=C2=A0

Regards,

Danping

=C2=A0

The information contained in this message may be = confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recip= ient, you are hereby notified that any use, forwarding, dissemination, or r= eproduction of this message is strictly prohibited and may be unlawful. If = you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the o= riginal message.=


_______________________________________________
Ace mailing list
Ace@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/ace

--047d7b5d4b46decd5b0500a5c01c-- From nobody Fri Aug 15 01:03:53 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22BA51A092B for ; Fri, 15 Aug 2014 01:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyEz-6BuPhYX for ; Fri, 15 Aug 2014 01:03:51 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F2A1A053B for ; Fri, 15 Aug 2014 01:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s7F83WP4027508; Fri, 15 Aug 2014 10:03:32 +0200 (CEST) Received: from [192.168.217.145] (p54890029.dip0.t-ipconnect.de [84.137.0.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C5D11E4B; Fri, 15 Aug 2014 10:03:31 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D8D426A@szxeml557-mbs.china.huawei.com> Date: Fri, 15 Aug 2014 10:03:30 +0200 X-Mao-Original-Outgoing-Id: 429782610.092302-ce9ee6028cddc79f4aebc9663b50fb34 Content-Transfer-Encoding: quoted-printable Message-Id: References: <77FA386512F0D748BC7C02C36EB1106D8D4164@szxeml557-mbs.china.huawei.com> <77FA386512F0D748BC7C02C36EB1106D8D4220@szxeml557-mbs.china.huawei.com> <77FA386512F0D748BC7C02C36EB1106D8D426A@szxeml557-mbs.china.huawei.com> To: "Hedanping (Ana)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/9wXj0AZd5GL6fMeEO47Z4--Sgg4 Cc: "Kumar, Sandeep" , "ace@ietf.org" Subject: Re: [Ace] About secure relay of authentication and authroization messages X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 08:03:52 -0000 On 13 Aug 2014, at 04:30, Hedanping (Ana) = wrote: > Hi Carsten, >=20 > I agree that C got the right to access the network, thereafter it has = the IP to communicate. My concern is: > C and RS might not always be the neighbors of each other due to weak = wireless signal or topology design (imagine a energy constrained WSN = with ad-hoc feature), thus packets between them should be relayed by = nodes (Relay Elements) along the path, which is determined by a certain = routing protocol. Right, in the Internet, we call these relaying elements =93routers", and = the relaying =93routing=94. I still don=92t understand what application layer authorization has to = do with it. There also is a role for application layer proxies, but there is no = point in using a proxy when you can simply route. So I=92m trying to understand the use case where one wouldn=92t just = route, and why. Gr=FC=DFe, Carsten From nobody Fri Aug 15 02:01:01 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A018C1A0972 for ; Fri, 15 Aug 2014 02:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2y7uy8aMbYAr for ; Fri, 15 Aug 2014 02:00:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C379D1A0941 for ; Fri, 15 Aug 2014 02:00:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLH32951; Fri, 15 Aug 2014 09:00:46 +0000 (GMT) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Aug 2014 10:00:44 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.44]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Fri, 15 Aug 2014 17:00:41 +0800 From: "Hedanping (Ana)" To: "robert.cragie@gridmerge.com" Thread-Topic: [Ace] About secure relay of authentication and authroization messages Thread-Index: AQHPtpGd1jSZboQ4OUmhg7LIrnqs+JvNm7iAgANfoeD//8IiAIAAkKlA Date: Fri, 15 Aug 2014 09:00:40 +0000 Message-ID: <77FA386512F0D748BC7C02C36EB1106D8D4796@szxeml557-mbs.china.huawei.com> References: <77FA386512F0D748BC7C02C36EB1106D8D4164@szxeml557-mbs.china.huawei.com> <77FA386512F0D748BC7C02C36EB1106D8D4220@szxeml557-mbs.china.huawei.com> <77FA386512F0D748BC7C02C36EB1106D8D473D@szxeml557-mbs.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.95.23] Content-Type: multipart/alternative; boundary="_000_77FA386512F0D748BC7C02C36EB1106D8D4796szxeml557mbschina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/eGc_1rRi68YhBQ36naCBZqPEgoI Cc: "Kumar, Sandeep" , "ace@ietf.org" Subject: Re: [Ace] About secure relay of authentication and authroization messages X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 09:00:58 -0000 --_000_77FA386512F0D748BC7C02C36EB1106D8D4796szxeml557mbschina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpGcm9tOiByb2JlcnQuY3JhZ2llQGdtYWlsLmNvbSBbbWFpbHRvOnJvYmVy dC5jcmFnaWVAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgUm9iZXJ0IENyYWdpZQ0KU2VudDogRnJp ZGF5LCBBdWd1c3QgMTUsIDIwMTQgMzoxMyBQTQ0KVG86IEhlZGFucGluZyAoQW5hKQ0KQ2M6IEt1 bWFyLCBTYW5kZWVwOyBhY2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQWNlXSBBYm91dCBzZWN1 cmUgcmVsYXkgb2YgYXV0aGVudGljYXRpb24gYW5kIGF1dGhyb2l6YXRpb24gbWVzc2FnZXMNCg0K DQpJIGFncmVlIHdpdGggU2FuZGVlcCdzIGFzc2Vzc21lbnQgYWxzbzsgdGhlIGFjY2VzcyBmcm9t IEMgdG8gdGhlIGZpcnN0IFJFIHNob3VsZCBiZSBtb2RlbGxlZCBpbiBhIHNpbWlsYXIgd2F5IGFz IEMgdG8gUlMuIFRoaXMgbWV0YS1tb2RlbGxpbmcsIGkuZS4gbW9kZWxsaW5nIGFuIEFBIHJlc291 cmNlIGFzIGEgcmVzb3VyY2UgYWxtb3N0IGFsd2F5cyBjb21lcyB1cCBhbmQgY2FuIHJlc3VsdCBp biBhICJkZWF0aCBzcGlyYWwiIG9mIGRlcGVuZGVuY3kgaWYgbm90IG1vZGVsbGVkIGNhcmVmdWxs eSwgZS5nLiBhbiBBQ0wgaXMgYSByZXNvdXJjZSwgd2hpY2ggbmVlZHMgYW4gQUNMLCAgd2hpY2gg aXMgYSByZXNvdXJjZSwgd2hpY2ggbmVlZHMgYW4gQUNMLi4uDQoNCkluIGEgY29uc3RyYWluZWQg ZW52aXJvbm1lbnQsIHRoZSBhY2Nlc3MgdG8gdGhlIFJFIG11c3QgYmUgY2FyZWZ1bGx5IGNvbnRy b2xsZWQgYW5kIG1heSBjb250YWluIHN0YXRpYy9pbXBsaWNpdCBydWxlcyByZWdhcmRpbmcgYWNj ZXNzLiBUaGUgUkUgaXMgdGhlbiBjb25zaWRlcmVkIGEgcGFzcy10aHJvdWdoIGZvciBhIGhpZ2hl ci1sYXllciBhY2Nlc3M7IHRoaXMgaW4gaXRzZWxmIG1heSBiZSBsYXllcmVkIGFueSBudW1iZXIg b2YgdGltZXMgYmVmb3JlIGVuZC10by1lbmQgaXMgYWNoaWV2ZWQsIHdoaWNoIG1heSBvciBtYXkg bm90IGltcGx5IElQIGNvbm5lY3Rpdml0eSBlbmQtdG8tZW5kIGJ1dCBhcyBDYXJzdGVuIGhhcyBw b2ludGVkIG91dCwgdGhhdCBpcyB0aGUgYXNzdW1wdGlvbiBmb3IgdGhlIHNwZWNpZmljIHByb2Js ZW0gc3RhdGVtZW50Lg0KDQpbRGFucGluZ10gSSB0b3RhbGx5IGFncmVlIHRoYXQgdGhlIGFjY2Vz cyB0byBSRSBzaG91bGQgYmUgY2FyZWZ1bGx5IGRlc2lnbmVkIGluIGNvbnN0cmFpbmVkIGVudmly b25tZW50LiBBQV9hY2UgaXMgZGVzaWduZWQgZm9yIGEgaGlnaGVyIGxldmVsIHJlc291cmNlIGFj Y2Vzcy9tYW5pcHVsYXRpb24sIHRoZSBpc3N1ZSBkaXNjdXNzZWQgaGVyZSBpcyB0byBhdm9pZCBS RSB1bmNvbmRpdGlvbmFsbHkgcmVsYXlpbmcgdGhlIEFBX2FjZS4gSXQgc2VlbXMgdGhhdCB1c2lu ZyBhbiBBQV9hY2UgdG8gcmVxdWVzdCByZWxheSBmb3IgYW5vdGhlciBBQV9hY2UgaXMgYSBwYXJh ZG94LCBhbmQgYSBsaWdodC13ZWlnaHQgYWNjZXNzIGNvbnRyb2wgc2hvdWxkIGJlIGRlc2lnbmVk Lg0KDQpBbiBSRSBpcyB0aHVzIGEgcGFzcy10aHJvdWdoIGludGVybWVkaWFyeTsgd2hpbHN0IHdl IGhhdmUgZ2VuZXJhbGx5IHBvc3Rwb25lZCBkaXNjdXNzaW9uIG9uIGludGVybWVkaWFyaWVzLCB0 aGlzIGxheWVyZWQgYXBwcm9hY2ggY291bGQgcG90ZW50aWFsbHkgYXBwbHkgdG8gYm90aCBwYXNz LXRocm91Z2ggYW5kIHByb3h5IGludGVybWVkaWFyaWVzLg0KDQpbRGFucGluZ10gT0ssIEkgYW0g d2lsbGluZyB0byBjb250cmlidXRlIG9uIHRoaXMgdG9waWMgaW4gdGhlIGZ1dHVyZS4NCg0KUm9i ZXJ0DQpPbiAxNSBBdWcgMjAxNCAwNDozNSwgIkhlZGFucGluZyAoQW5hKSIgPGFuYS5oZWRhbnBp bmdAaHVhd2VpLmNvbTxtYWlsdG86YW5hLmhlZGFucGluZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQpI aSBTYW5kZWVwLA0KQWNjb3JkaW5nIHRvIHlvdXIgc29sdXRpb24g4oCcVGhlIGZpcnN0IFJFIGlu IHRoZSBwYXRoIGNoZWNrcyB3aGV0aGVyIEMgaG9sZHMgYSB2YWxpZCBjZXJ0aWZpY2F0ZSBvciBh IHByZS1zaGFyZWQgcmVsYXkga2V54oCdIHdoaWNoIGl0c2VsZiBpcyBhbiBhdXRoZW50aWNhdGlv bi9hdXRob3JpemF0aW9uIGRlY2lzaW9uLiBJbmZhY3QgaXQgc291bmRzIG1vcmUgbGlrZSBhbiBB QSBkZWNpc2lvbiB0byBmaXJzdCBhY2Nlc3MgdGhlIG9uZS1ob3AgcmVsYXkgYW5kIHRoZW4gYW4g QUEgZGVjaXNpb24gdG8gYWNjZXNzIHRoZSBSUy4NCg0KW0RhbnBpbmddIFlvdXIgdW5kZXJzdGFu ZGluZyBpcyByaWdodC4gIEluIHVuY29uc3RyYWludCBlbnZpcm9ubWVudCwgUmVsYXkgRWxlbWVu dHMgc2ltcGx5IHJlbGF5IHRoZSBwYWNrZXRzIHRvIGRlc3RpbmF0aW9uLiBBbmQgYXMgd2Uga25v dywgIHRoZSBSRXMgYXJlIGxpa2VseSB0byBiZSBjb25zdHJhaW50IGRldmljZXMgaW4gY29uc3Ry YWludCBlbnZpcm9ubWVudCBzdWNoIGFzIGFkIGhvYyBXU05zLCB0aHVzIHRoZSBiYXR0ZXJ5IHJl c291cmNlIGFuZCBwYWNrZXQgYnVmZmVyIHdpbGwgYmUgY29uc3VtZWQgZHVlIHRvIHJlbGF5aW5n IHBhY2tldCBmb3IgQy4gSW4gb3RoZXIgd29yZHMsIHRvIHJlcXVlc3QgcmVzb3VyY2VzIG92ZXIg YSBSUyB0aGF0IGlzIG11bHRpcGxlIGhvcHMgYXdheSBpbnRyaW5zaWNhbGx5IGhpbnRzIGEgcmVx dWVzdCBvZiB0aGUgcmVzb3VyY2Ugb3ZlciBSRXMgYWxvbmcgdGhlIGhvcHMuICBUaGVyZWZvcmUg SSBiZWxpZXZlIHRoZSBhIGxpZ2h0IEFBIGlzIGRlc2lyZWQgZm9yIHRoZSBmaXJzdC1ob3AgcmVs YXkgdG8gcHJvdGVjdCBpdHNlbGYgYW5kIG90aGVyIFJFcyBhbG9uZyB0aGUgcm91dGUuDQoNCldv dWxkIGl0IG5vdCBiZSBzaW1wbGUgdG8gY29uc2lkZXIgdGhlIHJlbGF5IHRvIGJlIGFuIFJTIHdo aWNoIGlzIG9uZS1ob3AgYXdheSBhbmQgdXNlIHRoZSBub3QteWV0LWRlc2lnbmVkIEFDRSBzb2x1 dGlvbiBmb3IgdGhlIGZpcnN0LWhvcCB0b28uDQoNCltEYW5waW5nXSBJdCB3b3VsZCBiZSBiZXR0 ZXIgdG8gZGVzaWduIGEgbWVjaGFuaXNtIHdoaWNoIGFsbG93cyBBTS9BUyBpc3N1aW5nIGEgcGVy bWlzc2lvbiBmb3IgQyB0byBhY2Nlc3MgdGhlIGZpcnN0LWhvcCBSRSwgdGhlIHBlcm1pc3Npb24g bWlnaHQgYmUgdHJhbnNtaXR0ZWQgc2VwYXJhdGVseSBvciBwaWdneWJhY2tlZCB3aXRoIHRoZSBm aXJzdCBBQSBtZXNzYWdlIGJldHdlZW4gQyBhbmQgUlMuIFRoZSBub3QteWV0LWRlc2lnbmVkIEFD RSBzb2x1dGlvbiBtaWdodCBiZSB1c2VkIHRvbywgYnV0IGl0IGlzIHVubmVjZXNzYXJ5IHRvIGV4 Y2hhbmdlIGtleSB0byBzZWN1cmUgdGhlIHJlbGF5IG1lc3NhZ2UgYW5kIHRoZSBtZXNzYWdlIGZs b3cgd291bGQgYmUgZGlmZmVyZW50LiAgV2hhdCBkbyB5b3UgdGhpbms/DQoNCg0KDQpSZWdhcmRz LA0KDQpEYW5waW5nDQoNCg0KRnJvbTogS3VtYXIsIFNhbmRlZXAgW21haWx0bzpzYW5kZWVwLmt1 bWFyQHBoaWxpcHMuY29tPG1haWx0bzpzYW5kZWVwLmt1bWFyQHBoaWxpcHMuY29tPl0NClNlbnQ6 IFdlZG5lc2RheSwgQXVndXN0IDEzLCAyMDE0IDM6MjQgUE0NClRvOiBIZWRhbnBpbmcgKEFuYSk7 IGFjZUBpZXRmLm9yZzxtYWlsdG86YWNlQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtBY2VdIEFi b3V0IHNlY3VyZSByZWxheSBvZiBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aHJvaXphdGlvbiBtZXNz YWdlcw0KDQpISSBEYW5waW5nDQoNCkFjY29yZGluZyB0byB5b3VyIHNvbHV0aW9uIOKAnFRoZSBm aXJzdCBSRSBpbiB0aGUgcGF0aCBjaGVja3Mgd2hldGhlciBDIGhvbGRzIGEgdmFsaWQgY2VydGlm aWNhdGUgb3IgYSBwcmUtc2hhcmVkIHJlbGF5IGtleeKAnSB3aGljaCBpdHNlbGYgaXMgYW4gYXV0 aGVudGljYXRpb24vYXV0aG9yaXphdGlvbiBkZWNpc2lvbi4gSW5mYWN0IGl0IHNvdW5kcyBtb3Jl IGxpa2UgYW4gQUEgZGVjaXNpb24gdG8gZmlyc3QgYWNjZXNzIHRoZSBvbmUtaG9wIHJlbGF5IGFu ZCB0aGVuIGFuIEFBIGRlY2lzaW9uIHRvIGFjY2VzcyB0aGUgUlMuIFdvdWxkIGl0IG5vdCBiZSBz aW1wbGUgdG8gY29uc2lkZXIgdGhlIHJlbGF5IHRvIGJlIGFuIFJTIHdoaWNoIGlzIG9uZS1ob3Ag YXdheSBhbmQgdXNlIHRoZSBub3QteWV0LWRlc2lnbmVkIEFDRSBzb2x1dGlvbiBmb3IgdGhlIGZp cnN0LWhvcCB0b28uDQoNClJlZ2FyZHMNClNhbmRlZXANCg0KRnJvbTogSGVkYW5waW5nIChBbmEp IFttYWlsdG86YW5hLmhlZGFucGluZ0BodWF3ZWkuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBBdWd1 c3QgMTMsIDIwMTQgMjo1OCBBTQ0KVG86IEt1bWFyLCBTYW5kZWVwOyBhY2VAaWV0Zi5vcmc8bWFp bHRvOmFjZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbQWNlXSBBYm91dCBzZWN1cmUgcmVsYXkg b2YgYXV0aGVudGljYXRpb24gYW5kIGF1dGhyb2l6YXRpb24gbWVzc2FnZXMNCg0KSGkgU2FuZGVl cCwNClRoYW5rcyBmb3IgdGhlIGluZm9ybWF0aW9uIGFuZCBhbHNvIHRoYW5rIHlvdSBmb3Igc2hv d2luZyBpbnRlcmVzdCBpbiB0aGlzIGlzc3VlLg0KVGhlIGFzc3VtcHRpb24gaXMgdGhhdCwgZHVy aW5nIHRoZSBBQSBwcm9jZWR1cmUsIHRoZXJlIGFyZSBBQSBtZXNzYWdlcyBleGNoYW5nZWQgYmV0 d2VlbiB0aGUgQyBhbmQgUlMsIHdoaWNoIGFyZSBub3QgZGlyZWN0bHkgY29ubmVjdGVkLiBUbyBz b2x2ZSBET1MgYXR0YWNrLCBJIHJvdWdobHkgaGF2ZSBhIHNvbHV0aW9uIGluIG1pbmQ6DQoNCg0K DQpBIHJlbGF5IGtleS9jZXJ0aWZpY2F0ZSBpcyBuZWVkZWQuIFRoZXJlIG1pZ2h0IGV4aXN0IG1v cmUgdGhhbiBvbmUgUkUgYWxvbmcgdGhlIHBhdGggYmV0d2VlbiBDIGFuZCBSUy4gVGhlIGZpcnN0 IFJFIGluIHRoZSBwYXRoIGNoZWNrcyB3aGV0aGVyIEMgaG9sZHMgYSB2YWxpZCBjZXJ0aWZpY2F0 ZSBvciBhIHByZS1zaGFyZWQgcmVsYXkga2V5LiBJZiB2ZXJpZmllZCwgdGhlIEFBIG1lc3NhZ2Vz IGZyb20gQyBhcmUgcmVsYXllZCBub3JtYWxseS4gT3RoZXJ3aXNlLCB0aGUgQUEgbWVzc2FnZXMg ZnJvbSBDIGFyZSBpZ25vcmVkLg0KDQoNClJlZ2FyZHMsDQpEYW5waW5nDQpGcm9tOiBLdW1hciwg U2FuZGVlcCBbbWFpbHRvOnNhbmRlZXAua3VtYXJAcGhpbGlwcy5jb21dDQpTZW50OiBUdWVzZGF5 LCBBdWd1c3QgMTIsIDIwMTQgNDoyMSBQTQ0KVG86IEhlZGFucGluZyAoQW5hKTsgYWNlQGlldGYu b3JnPG1haWx0bzphY2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0FjZV0gQWJvdXQgc2VjdXJl IHJlbGF5IG9mIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRocm9pemF0aW9uIG1lc3NhZ2VzDQoNCkhp IERhbnBpbmcNCg0KSSB0aGluayBBQ0UgaXMgYXQgYSB2ZXJ5IGVhcmx5IHN0YWdlIHRoYXQgaXQg aXMgYmV0dGVyIHRvIGZpcnN0IHNvbHZlIHRoZSBwcm9ibGVtIHdpdGhvdXQgdGhlIHJlbGF5IHBh dGguIEF0IGEgbGF0ZXIgc3RhZ2UsIHRoZSByZWxheSBwYXRoIGNhbiBiZSBhZGRlZCBmb3Igc2Nl bmFyaW9zIHRoYXQgbWlnaHQgbmVlZCB0aGVtIGFuZCBvZmNvdXJzZSBEb1MgcHJvdGVjdGlvbiB3 aWxsIGJlIGFuIGltcG9ydGFudCBpc3N1ZSB0byBjb25zaWRlciB0aGVuLiBEbyB5b3UgaGF2ZSBh bnkgc3BlY2lmaWMgc29sdXRpb25zIHRvIHNvbHZlIHRoZSBwcm9ibGVtPyBJZiB0aGUgRG9TIHBy b3RlY3Rpb24gc29sdXRpb24gZGVwZW5kcyBoZWF2aWx5IG9uIHRoZSBBQSBkYXRhIHRoZW4gaW1o byBpdCBzaG91bGQgYmUgc29sdmVkIGluIEFDRS4NCg0KUmVnYXJkcw0KU2FuZGVlcA0KDQpGcm9t OiBBY2UgW21haWx0bzphY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEhlZGFucGlu ZyAoQW5hKQ0KU2VudDogVHVlc2RheSwgQXVndXN0IDEyLCAyMDE0IDU6NTAgQU0NClRvOiBhY2VA aWV0Zi5vcmc8bWFpbHRvOmFjZUBpZXRmLm9yZz4NClN1YmplY3Q6IFtBY2VdIEFib3V0IHNlY3Vy ZSByZWxheSBvZiBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aHJvaXphdGlvbiBtZXNzYWdlcw0KDQpI aSwNClRoZXJlIGlzIGFuIGlzc3VlIHRoYXQgSSBhbSBub3Qgc3VyZSB3aGV0aGVyIGl0IGlzIHN1 aXRhYmxlIGZvciBhIGRyYWZ0OiBzaG91bGQgd2UgY29uc2lkZXIgc2VjdXJlIHJlbGF5IG9mIHRo ZSBBdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiAoQUEpIG1lc3NhZ2VzIHRvIHByb3Rl Y3QgcmVsYXkgZWxlbWVudHMgYWxvbmcgdGhlIHJlbGF5IHBhdGg/DQoNCkRUTFMgcmVsYXkgYW5k IFBBTkEgcmVsYXkgaGF2ZSBiZWVuIHByb3Bvc2VkLCBob3dldmVyIHRoZSByZWxheSBlbGVtZW50 cyBzaW1wbHkgcmVsYXlzIHRoZSBBQSBtZXNzYWdlcyB0byB0aGUgc2VydmVyLiBUbyBhdm9pZCBE T1MgYXR0YWNrLCB0aGUgdGhleSBsaW1pdCB0aGUgZnJlcXVlbmN5IGFuZCBtYXhpbXVtIG51bWJl ciBvZiB0aW1lcyB0byByZWxheSB0aGUgQUEgcmVxdWVzdHMuDQoNCkluIGNvbnN0cmFpbnQgZW52 aXJvbm1lbnQsIHRoZSByZWxheSBlbGVtZW50cyBtaWdodCBiZSBlbmVyZ3kgY29uc3RyYWluZWQg ZGV2aWNlcy4gSWYgYSBtYWxpY2lvdXMgY2xpZW50IGludGVuZHMgdG8gZXhoYXVzdCB0aGUgcmVs YXkgZWxlbWVudHPigJkgcG93ZXIgYnkgZnJlcXVlbnRseSBzZW5kaW5nIEFBIHJlcXVlc3RzIHdp dGggZm9yZ2VkIElQcyBvciBJRHMsIGlzIHRoZXJlIGFueSBjb3VudGVybWVhc3VyZSB0byB0aGlz IGlzc3VlPyBEbyB3ZSBuZWVkIHRvIGNvbnNpZGVyIHRoaXMgaXNzdWUgaW4gQUNFIFdHPw0KDQpS ZWdhcmRzLA0KRGFucGluZw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVudGlh bCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdl IGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkg dXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyBt ZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRl ciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFs IG1lc3NhZ2UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpBY2UgbWFpbGluZyBsaXN0DQpBY2VAaWV0Zi5vcmc8bWFpbHRvOkFjZUBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQo= --_000_77FA386512F0D748BC7C02C36EB1106D8D4796szxeml557mbschina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseTrlrovkvZM7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0 ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IuaJueazqOahhuaW h+acrCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxlLW5h bWU6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms65om55rOo5qGG5paH5pysOw0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIu MHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFJvYmVy dCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJv YmVydC5jcmFnaWVAZ21haWwuY29tIFttYWlsdG86cm9iZXJ0LmNyYWdpZUBnbWFpbC5jb21dDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPlJvYmVydCBDcmFnaWU8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5 LCBBdWd1c3QgMTUsIDIwMTQgMzoxMyBQTTxicj4NCjxiPlRvOjwvYj4gSGVkYW5waW5nIChBbmEp PGJyPg0KPGI+Q2M6PC9iPiBLdW1hciwgU2FuZGVlcDsgYWNlQGlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbQWNlXSBBYm91dCBzZWN1cmUgcmVsYXkgb2YgYXV0aGVudGljYXRpb24g YW5kIGF1dGhyb2l6YXRpb24gbWVzc2FnZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+SSBhZ3JlZSB3aXRoIFNhbmRlZXAn cyBhc3Nlc3NtZW50IGFsc287IHRoZSBhY2Nlc3MgZnJvbSBDIHRvIHRoZSBmaXJzdCBSRSBzaG91 bGQgYmUgbW9kZWxsZWQgaW4gYSBzaW1pbGFyIHdheSBhcyBDIHRvIFJTLiBUaGlzIG1ldGEtbW9k ZWxsaW5nLCBpLmUuIG1vZGVsbGluZyBhbiBBQSByZXNvdXJjZSBhcyBhIHJlc291cmNlIGFsbW9z dCBhbHdheXMgY29tZXMgdXAgYW5kIGNhbiByZXN1bHQgaW4gYSAmcXVvdDtkZWF0aA0KIHNwaXJh bCZxdW90OyBvZiBkZXBlbmRlbmN5IGlmIG5vdCBtb2RlbGxlZCBjYXJlZnVsbHksIGUuZy4gYW4g QUNMIGlzIGEgcmVzb3VyY2UsIHdoaWNoIG5lZWRzIGFuIEFDTCwmbmJzcDsgd2hpY2ggaXMgYSBy ZXNvdXJjZSwgd2hpY2ggbmVlZHMgYW4gQUNMLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tVVMiPkluIGEgY29uc3RyYWluZWQgZW52aXJvbm1lbnQsIHRoZSBhY2Nl c3MgdG8gdGhlIFJFIG11c3QgYmUgY2FyZWZ1bGx5IGNvbnRyb2xsZWQgYW5kIG1heSBjb250YWlu IHN0YXRpYy9pbXBsaWNpdCBydWxlcyByZWdhcmRpbmcgYWNjZXNzLiBUaGUgUkUgaXMgdGhlbiBj b25zaWRlcmVkIGEgcGFzcy10aHJvdWdoIGZvciBhIGhpZ2hlci1sYXllciBhY2Nlc3M7IHRoaXMg aW4gaXRzZWxmIG1heSBiZSBsYXllcmVkIGFueQ0KIG51bWJlciBvZiB0aW1lcyBiZWZvcmUgZW5k LXRvLWVuZCBpcyBhY2hpZXZlZCwgd2hpY2ggbWF5IG9yIG1heSBub3QgaW1wbHkgSVAgY29ubmVj dGl2aXR5IGVuZC10by1lbmQgYnV0IGFzIENhcnN0ZW4gaGFzIHBvaW50ZWQgb3V0LCB0aGF0IGlz IHRoZSBhc3N1bXB0aW9uIGZvciB0aGUgc3BlY2lmaWMgcHJvYmxlbSBzdGF0ZW1lbnQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izk0MzYz NCI+W0RhbnBpbmddIEkgdG90YWxseSBhZ3JlZSB0aGF0IHRoZSBhY2Nlc3MgdG8gUkUgc2hvdWxk IGJlIGNhcmVmdWxseSBkZXNpZ25lZCBpbiBjb25zdHJhaW5lZCBlbnZpcm9ubWVudC4gQUFfYWNl IGlzIGRlc2lnbmVkIGZvciBhIGhpZ2hlciBsZXZlbCByZXNvdXJjZSBhY2Nlc3MvbWFuaXB1bGF0 aW9uLCB0aGUgaXNzdWUNCiBkaXNjdXNzZWQgaGVyZSBpcyB0byBhdm9pZCBSRSB1bmNvbmRpdGlv bmFsbHkgcmVsYXlpbmcgdGhlIEFBX2FjZS4gSXQgc2VlbXMgdGhhdCB1c2luZyBhbiBBQV9hY2Ug dG8gcmVxdWVzdCByZWxheSBmb3IgYW5vdGhlciBBQV9hY2UgaXMgYSBwYXJhZG94LCBhbmQgYSBs aWdodC13ZWlnaHQgYWNjZXNzIGNvbnRyb2wgc2hvdWxkIGJlIGRlc2lnbmVkLjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5BbiBSRSBpcyB0aHVzIGEg cGFzcy10aHJvdWdoIGludGVybWVkaWFyeTsgd2hpbHN0IHdlIGhhdmUgZ2VuZXJhbGx5IHBvc3Rw b25lZCBkaXNjdXNzaW9uIG9uIGludGVybWVkaWFyaWVzLCB0aGlzIGxheWVyZWQgYXBwcm9hY2gg Y291bGQgcG90ZW50aWFsbHkgYXBwbHkgdG8gYm90aCBwYXNzLXRocm91Z2ggYW5kIHByb3h5IGlu dGVybWVkaWFyaWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiM5NDM2MzQiPltEYW5waW5nXSBPSywgSSBhbSB3aWxsaW5nIHRvIGNvbnRy aWJ1dGUgb24gdGhpcyB0b3BpYyBpbiB0aGUgZnV0dXJlLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5Sb2JlcnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIDE1IEF1 ZyAyMDE0IDA0OjM1LCAmcXVvdDtIZWRhbnBpbmcgKEFuYSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzphbmEuaGVkYW5waW5nQGh1YXdlaS5jb20iPmFuYS5oZWRhbnBpbmdAaHVhd2VpLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PkhpIFNhbmRlZXAsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5BY2NvcmRpbmcgdG8geW91ciBzb2x1dGlvbiDi gJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGUgZmly c3QgUkUgaW4gdGhlIHBhdGggY2hlY2tzIHdoZXRoZXIgQyBob2xkcw0KIGEgdmFsaWQgY2VydGlm aWNhdGUgb3IgYSBwcmUtc2hhcmVkIHJlbGF5IGtleeKAnSB3aGljaCBpdHNlbGYgaXMgYW4gYXV0 aGVudGljYXRpb24vYXV0aG9yaXphdGlvbiBkZWNpc2lvbi4gSW5mYWN0IGl0IHNvdW5kcyBtb3Jl IGxpa2UgYW4gQUEgZGVjaXNpb24gdG8gZmlyc3QgYWNjZXNzIHRoZSBvbmUtaG9wIHJlbGF5IGFu ZCB0aGVuIGFuIEFBIGRlY2lzaW9uIHRvIGFjY2VzcyB0aGUgUlMuDQo8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6Izk0MzYzNCI+W0RhbnBpbmddIFlvdXIgdW5kZXJzdGFuZGluZyBpcyByaWdo dC4mbmJzcDsgSW4gdW5jb25zdHJhaW50IGVudmlyb25tZW50LCBSZWxheSBFbGVtZW50cyBzaW1w bHkgcmVsYXkgdGhlIHBhY2tldHMgdG8gZGVzdGluYXRpb24uIEFuZCBhcyB3ZSBrbm93LCAmbmJz cDt0aGUgUkVzIGFyZSBsaWtlbHkgdG8gYmUgY29uc3RyYWludCBkZXZpY2VzIGluIGNvbnN0cmFp bnQgZW52aXJvbm1lbnQgc3VjaA0KIGFzIGFkIGhvYyBXU05zLCB0aHVzIHRoZSBiYXR0ZXJ5IHJl c291cmNlIGFuZCBwYWNrZXQgYnVmZmVyIHdpbGwgYmUgY29uc3VtZWQgZHVlIHRvIHJlbGF5aW5n IHBhY2tldCBmb3IgQy4gSW4gb3RoZXIgd29yZHMsIHRvIHJlcXVlc3QgcmVzb3VyY2VzIG92ZXIg YSBSUyB0aGF0IGlzIG11bHRpcGxlIGhvcHMgYXdheSBpbnRyaW5zaWNhbGx5IGhpbnRzIGEgcmVx dWVzdCBvZiB0aGUgcmVzb3VyY2Ugb3ZlciBSRXMgYWxvbmcgdGhlIGhvcHMuICZuYnNwO1RoZXJl Zm9yZQ0KIEkgYmVsaWV2ZSB0aGUgYSBsaWdodCBBQSBpcyBkZXNpcmVkIGZvciB0aGUgZmlyc3Qt aG9wIHJlbGF5IHRvIHByb3RlY3QgaXRzZWxmIGFuZCBvdGhlciBSRXMgYWxvbmcgdGhlIHJvdXRl Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPldvdWxkIGl0IG5vdCBiZSBzaW1wbGUgdG8gY29uc2lkZXIgdGhlIHJlbGF5IHRvIGJl IGFuIFJTIHdoaWNoIGlzIG9uZS1ob3AgYXdheSBhbmQgdXNlIHRoZSBub3QteWV0LWRlc2lnbmVk IEFDRSBzb2x1dGlvbiBmb3IgdGhlIGZpcnN0LWhvcA0KIHRvby48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6Izk0MzYzNCI+W0RhbnBpbmddIEl0IHdvdWxkIGJlIGJldHRlciB0byBkZXNpZ24g YSBtZWNoYW5pc20gd2hpY2ggYWxsb3dzIEFNL0FTIGlzc3VpbmcgYSBwZXJtaXNzaW9uIGZvciBD IHRvIGFjY2VzcyB0aGUgZmlyc3QtaG9wIFJFLCB0aGUgcGVybWlzc2lvbiBtaWdodCBiZSB0cmFu c21pdHRlZCBzZXBhcmF0ZWx5IG9yIHBpZ2d5YmFja2VkIHdpdGggdGhlIGZpcnN0IEFBIG1lc3Nh Z2UNCiBiZXR3ZWVuIEMgYW5kIFJTLiBUaGUgbm90LXlldC1kZXNpZ25lZCBBQ0Ugc29sdXRpb24g bWlnaHQgYmUgdXNlZCB0b28sIGJ1dCBpdCBpcyB1bm5lY2Vzc2FyeSB0byBleGNoYW5nZSBrZXkg dG8gc2VjdXJlIHRoZSByZWxheSBtZXNzYWdlIGFuZCB0aGUgbWVzc2FnZSBmbG93IHdvdWxkIGJl IGRpZmZlcmVudC4gJm5ic3A7V2hhdCBkbyB5b3UgdGhpbms/PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOiM5NDM2MzQiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5SZWdhcmRzLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5EYW5waW5nPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBLdW1hciwNCiBT YW5kZWVwIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNhbmRlZXAua3VtYXJAcGhpbGlwcy5jb20i IHRhcmdldD0iX2JsYW5rIj5zYW5kZWVwLmt1bWFyQHBoaWxpcHMuY29tPC9hPl0NCjxicj4NCjxi PlNlbnQ6PC9iPiBXZWRuZXNkYXksIEF1Z3VzdCAxMywgMjAxNCAzOjI0IFBNPGJyPg0KPGI+VG86 PC9iPiBIZWRhbnBpbmcgKEFuYSk7IDxhIGhyZWY9Im1haWx0bzphY2VAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5hY2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbQWNl XSBBYm91dCBzZWN1cmUgcmVsYXkgb2YgYXV0aGVudGljYXRpb24gYW5kIGF1dGhyb2l6YXRpb24g bWVzc2FnZXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5I SSBEYW5waW5nPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPkFjY29yZGlu ZyB0byB5b3VyIHNvbHV0aW9uIOKAnDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPlRoZSBmaXJzdCBSRSBpbiB0aGUgcGF0aCBjaGVja3Mgd2hldGhlciBDIGhv bGRzDQogYSB2YWxpZCBjZXJ0aWZpY2F0ZSBvciBhIHByZS1zaGFyZWQgcmVsYXkga2V54oCdIHdo aWNoIGl0c2VsZiBpcyBhbiBhdXRoZW50aWNhdGlvbi9hdXRob3JpemF0aW9uIGRlY2lzaW9uLiBJ bmZhY3QgaXQgc291bmRzIG1vcmUgbGlrZSBhbiBBQSBkZWNpc2lvbiB0byBmaXJzdCBhY2Nlc3Mg dGhlIG9uZS1ob3AgcmVsYXkgYW5kIHRoZW4gYW4gQUEgZGVjaXNpb24gdG8gYWNjZXNzIHRoZSBS Uy4gV291bGQgaXQgbm90IGJlIHNpbXBsZSB0byBjb25zaWRlcg0KIHRoZSByZWxheSB0byBiZSBh biBSUyB3aGljaCBpcyBvbmUtaG9wIGF3YXkgYW5kIHVzZSB0aGUgbm90LXlldC1kZXNpZ25lZCBB Q0Ugc29sdXRpb24gZm9yIHRoZSBmaXJzdC1ob3AgdG9vLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TYW5kZWVwPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IEhlZGFucGluZw0KIChBbmEpIFs8YSBocmVmPSJtYWlsdG86YW5hLmhlZGFucGluZ0BodWF3ZWku Y29tIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOmFuYS5oZWRhbnBpbmdAaHVhd2VpLmNvbTwvYT5d DQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBdWd1c3QgMTMsIDIwMTQgMjo1OCBBTTxi cj4NCjxiPlRvOjwvYj4gS3VtYXIsIFNhbmRlZXA7IDxhIGhyZWY9Im1haWx0bzphY2VAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5hY2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJFOiBbQWNlXSBBYm91dCBzZWN1cmUgcmVsYXkgb2YgYXV0aGVudGljYXRpb24gYW5kIGF1dGhy b2l6YXRpb24gbWVzc2FnZXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGkgU2FuZGVl cCw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5UaGFua3MgZm9yIHRoZSBpbmZvcm1hdGlvbiBhbmQgYWxzbyB0aGFuayB5b3UgZm9yIHNob3dp bmcgaW50ZXJlc3QgaW4gdGhpcyBpc3N1ZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGUgYXNzdW1wdGlvbiBpcyB0aGF0LCBkdXJpbmcg dGhlIEFBIHByb2NlZHVyZSwgdGhlcmUgYXJlIEFBIG1lc3NhZ2VzIGV4Y2hhbmdlZCBiZXR3ZWVu IHRoZSBDIGFuZCBSUywgd2hpY2ggYXJlIG5vdCBkaXJlY3RseSBjb25uZWN0ZWQuDQogVG8gc29s dmUgRE9TIGF0dGFjaywgSSByb3VnaGx5IGhhdmUgYSBzb2x1dGlvbiBpbiBtaW5kOjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bi1sZWZ0OjE4LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+QSByZWxheSBrZXkvY2VydGlmaWNhdGUgaXMgbmVlZGVkLiBUaGVyZSBtaWdo dCBleGlzdCBtb3JlIHRoYW4gb25lIFJFIGFsb25nIHRoZSBwYXRoIGJldHdlZW4gQyBhbmQgUlMu IFRoZSBmaXJzdCBSRSBpbiB0aGUgcGF0aCBjaGVja3Mgd2hldGhlciBDIGhvbGRzIGEgdmFsaWQg Y2VydGlmaWNhdGUgb3IgYSBwcmUtc2hhcmVkDQogcmVsYXkga2V5LiBJZiB2ZXJpZmllZCwgdGhl IEFBIG1lc3NhZ2VzIGZyb20gQyBhcmUgcmVsYXllZCBub3JtYWxseS4gT3RoZXJ3aXNlLCB0aGUg QUEgbWVzc2FnZXMgZnJvbSBDIGFyZSBpZ25vcmVkLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkRhbnBp bmc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEt1bWFyLA0KIFNhbmRlZXAg WzxhIGhyZWY9Im1haWx0bzpzYW5kZWVwLmt1bWFyQHBoaWxpcHMuY29tIiB0YXJnZXQ9Il9ibGFu ayI+bWFpbHRvOnNhbmRlZXAua3VtYXJAcGhpbGlwcy5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8 L2I+IFR1ZXNkYXksIEF1Z3VzdCAxMiwgMjAxNCA0OjIxIFBNPGJyPg0KPGI+VG86PC9iPiBIZWRh bnBpbmcgKEFuYSk7IDxhIGhyZWY9Im1haWx0bzphY2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5hY2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbQWNlXSBBYm91dCBz ZWN1cmUgcmVsYXkgb2YgYXV0aGVudGljYXRpb24gYW5kIGF1dGhyb2l6YXRpb24gbWVzc2FnZXM8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5IaSBEYW5waW5n PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgQUNFIGlzIGF0 IGEgdmVyeSBlYXJseSBzdGFnZSB0aGF0IGl0IGlzIGJldHRlciB0byBmaXJzdCBzb2x2ZSB0aGUg cHJvYmxlbSB3aXRob3V0IHRoZSByZWxheSBwYXRoLiBBdCBhIGxhdGVyIHN0YWdlLA0KIHRoZSBy ZWxheSBwYXRoIGNhbiBiZSBhZGRlZCBmb3Igc2NlbmFyaW9zIHRoYXQgbWlnaHQgbmVlZCB0aGVt IGFuZCBvZmNvdXJzZSBEb1MgcHJvdGVjdGlvbiB3aWxsIGJlIGFuIGltcG9ydGFudCBpc3N1ZSB0 byBjb25zaWRlciB0aGVuLiBEbyB5b3UgaGF2ZSBhbnkgc3BlY2lmaWMgc29sdXRpb25zIHRvIHNv bHZlIHRoZSBwcm9ibGVtPyBJZiB0aGUgRG9TIHByb3RlY3Rpb24gc29sdXRpb24gZGVwZW5kcyBo ZWF2aWx5IG9uIHRoZSBBQSBkYXRhIHRoZW4NCiBpbWhvIGl0IHNob3VsZCBiZSBzb2x2ZWQgaW4g QUNFLiA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+UmVnYXJkczwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29s b3I6IzFGNDk3RCI+U2FuZGVlcCAmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQWNlDQogWzxhIGhyZWY9Im1haWx0bzphY2Ut Ym91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzphY2UtYm91bmNlc0BpZXRm Lm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkhlZGFucGluZyAoQW5hKTxicj4NCjxiPlNl bnQ6PC9iPiBUdWVzZGF5LCBBdWd1c3QgMTIsIDIwMTQgNTo1MCBBTTxicj4NCjxiPlRvOjwvYj4g PGEgaHJlZj0ibWFpbHRvOmFjZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmFjZUBpZXRmLm9y ZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0FjZV0gQWJvdXQgc2VjdXJlIHJlbGF5IG9mIGF1 dGhlbnRpY2F0aW9uIGFuZCBhdXRocm9pemF0aW9uIG1lc3NhZ2VzPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SGksDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj5UaGVyZSBpcyBhbiBpc3N1ZSB0aGF0IEkgYW0gbm90IHN1cmUgd2hldGhlciBpdCBpcyBz dWl0YWJsZSBmb3IgYSBkcmFmdDogc2hvdWxkIHdlIGNvbnNpZGVyIHNlY3VyZSByZWxheSBvZiB0 aGUgQXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gKEFBKSBtZXNzYWdlcw0KIHRvIHBy b3RlY3QgcmVsYXkgZWxlbWVudHMgYWxvbmcgdGhlIHJlbGF5IHBhdGg/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+RFRMUyByZWxheSBhbmQgUEFOQSByZWxheSBoYXZlIGJlZW4gcHJvcG9zZWQsIGhv d2V2ZXIgdGhlIHJlbGF5IGVsZW1lbnRzIHNpbXBseSByZWxheXMgdGhlIEFBIG1lc3NhZ2VzIHRv IHRoZSBzZXJ2ZXIuIFRvIGF2b2lkIERPUyBhdHRhY2ssIHRoZSB0aGV5IGxpbWl0IHRoZQ0KIGZy ZXF1ZW5jeSBhbmQgbWF4aW11bSBudW1iZXIgb2YgdGltZXMgdG8gcmVsYXkgdGhlIEFBIHJlcXVl c3RzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkluIGNvbnN0cmFpbnQgZW52aXJvbm1lbnQsIHRo ZSByZWxheSBlbGVtZW50cyBtaWdodCBiZSBlbmVyZ3kgY29uc3RyYWluZWQgZGV2aWNlcy4gSWYg YSBtYWxpY2lvdXMgY2xpZW50IGludGVuZHMgdG8gZXhoYXVzdCB0aGUgcmVsYXkgZWxlbWVudHPi gJkgcG93ZXIgYnkgZnJlcXVlbnRseQ0KIHNlbmRpbmcgQUEgcmVxdWVzdHMgd2l0aCBmb3JnZWQg SVBzIG9yIElEcywgaXMgdGhlcmUgYW55IGNvdW50ZXJtZWFzdXJlIHRvIHRoaXMgaXNzdWU/IERv IHdlIG5lZWQgdG8gY29uc2lkZXIgdGhpcyBpc3N1ZSBpbiBBQ0UgV0c/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5EYW5waW5nPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBh bGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpncmF5Ij5UaGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgY29uZmlkZW50aWFsIGFuZCBs ZWdhbGx5IHByb3RlY3RlZCB1bmRlcg0KIGFwcGxpY2FibGUgbGF3LiBUaGUgbWVzc2FnZSBpcyBp bnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwg Zm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgbWVzc2Fn ZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdQ0KIGFy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBi eSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1l c3NhZ2UuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpBY2UgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOkFjZUBpZXRmLm9yZyI+QWNlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2U8L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_77FA386512F0D748BC7C02C36EB1106D8D4796szxeml557mbschina_-- From nobody Fri Aug 15 02:08:44 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927101A0961 for ; Fri, 15 Aug 2014 02:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfUfgmmuYUx9 for ; Fri, 15 Aug 2014 02:08:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15AB51A0956 for ; Fri, 15 Aug 2014 02:08:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIG79733; Fri, 15 Aug 2014 09:08:30 +0000 (GMT) Received: from SZXEML463-HUB.china.huawei.com (10.82.67.206) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Aug 2014 10:08:29 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.44]) by szxeml463-hub.china.huawei.com ([10.82.67.206]) with mapi id 14.03.0158.001; Fri, 15 Aug 2014 17:08:22 +0800 From: "Hedanping (Ana)" To: Carsten Bormann Thread-Topic: [Ace] About secure relay of authentication and authroization messages Thread-Index: AQHPtpGd1jSZboQ4OUmhg7LIrnqs+JvNN1EAgACOGvCAAwYiAIAAlt+Q Date: Fri, 15 Aug 2014 09:08:21 +0000 Message-ID: <77FA386512F0D748BC7C02C36EB1106D8D47A3@szxeml557-mbs.china.huawei.com> References: <77FA386512F0D748BC7C02C36EB1106D8D4164@szxeml557-mbs.china.huawei.com> <77FA386512F0D748BC7C02C36EB1106D8D4220@szxeml557-mbs.china.huawei.com> <77FA386512F0D748BC7C02C36EB1106D8D426A@szxeml557-mbs.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.95.23] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/lWO_56sclPnJ6pIIl4lN51Dew7E Cc: "Kumar, Sandeep" , "ace@ietf.org" Subject: Re: [Ace] About secure relay of authentication and authroization messages X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 09:08:39 -0000 Hi Carsten, So I'm trying to understand the use case where one wouldn't just route, and= why. [Danping] The routers themselves may be energy constrained or the bandwidth= of the network is constrained, which makes the network itself fragile unde= r a DOS attack that might not target at the final RS... -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: Friday, August 15, 2014 4:04 PM To: Hedanping (Ana) Cc: Kumar, Sandeep; ace@ietf.org Subject: Re: [Ace] About secure relay of authentication and authroization m= essages On 13 Aug 2014, at 04:30, Hedanping (Ana) wrote: > Hi Carsten, >=20 > I agree that C got the right to access the network, thereafter it has the= IP to communicate. My concern is: > C and RS might not always be the neighbors of each other due to weak wire= less signal or topology design (imagine a energy constrained WSN with ad-ho= c feature), thus packets between them should be relayed by nodes (Relay Ele= ments) along the path, which is determined by a certain routing protocol. Right, in the Internet, we call these relaying elements "routers", and the = relaying "routing". I still don't understand what application layer authorization has to do wit= h it. There also is a role for application layer proxies, but there is no point i= n using a proxy when you can simply route. So I'm trying to understand the use case where one wouldn't just route, and= why. [Danping] Because the router itself may be energy constrained or the bandwi= dth of the route is constrained that is fragile under DOS attack that might= not target at the final RS... Gr=FC=DFe, Carsten From nobody Fri Aug 15 06:19:14 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1261E1A0AA8; Fri, 15 Aug 2014 06:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThF10638_KmJ; Fri, 15 Aug 2014 06:19:08 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AAF81A0AA9; Fri, 15 Aug 2014 06:19:08 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id uq10so1861648igb.14 for ; Fri, 15 Aug 2014 06:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=npBzq5uNPhOXfyurEGDa8Md2s9CSRe8bnKzA1r50+q8=; b=tkduAIV/gbHBJNfcv3LtiIxGyQChzdzfIMOhO6AG49d6l+X6fCkjwjA0mDSOjz1Mfu nKQiNwUJbl//ueujatFPvavbXVhYfiIcwPcyi7sjSmX8vS6zaE7I1bIj6aT3eSOfIC7o EvbRaA6jG7dDzKxm4Nx57d2eazkar2DmTzca8OjhDDvRvRSFsVfOEhAu0hbXHiuW0E1L Jaxi3u1WRZbBnRFKcM+FjFkLk9AzSG5lYxzH6V7dIc9HpPZAoliMIwsaxD4DFbS+jigM MexDS/V86J/zpqh3h28w9dAXISZyOX7CVY01K8Lh2UUkNu79dPY98eELv1Rfiz7eA0oC Qnog== X-Received: by 10.50.153.83 with SMTP id ve19mr5203360igb.4.1408108747610; Fri, 15 Aug 2014 06:19:07 -0700 (PDT) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.118.107]) by mx.google.com with ESMTPSA id hu5sm7865430igb.16.2014.08.15.06.19.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Aug 2014 06:19:07 -0700 (PDT) Message-ID: <53EE08B9.8000406@gmail.com> Date: Fri, 15 Aug 2014 09:18:49 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Hedanping (Ana)" , "Kumar, Sandeep" , "ace@ietf.org" References: <77FA386512F0D748BC7C02C36EB1106D8D4164@szxeml557-mbs.china.huawei.com> <77FA386512F0D748BC7C02C36EB1106D8D4220@szxeml557-mbs.china.huawei.com> <77FA386512F0D748BC7C02C36EB1106D8D473D@szxeml557-mbs.china.huawei.com> In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D8D473D@szxeml557-mbs.china.huawei.com> Content-Type: multipart/alternative; boundary="------------080706060506000506040402" Archived-At: http://mailarchive.ietf.org/arch/msg/ace/Ws66NOH2oe_yRGzVVIo3L8BKty0 Cc: "dtls-iot@ietf.org" Subject: Re: [Ace] About secure relay of authentication and authroization messages X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 13:19:12 -0000 This is a multi-part message in MIME format. --------------080706060506000506040402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear colleagues: FYI - You may wish to have a look at the discussion on the IETF DICE mailing list end of May (messages 240-253; May 27-30, 2014) related to this, see, e.g., http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00241.html. This discussion was triggered by some questions I had re suggestions in the security considerations section of draft-kumar-dice-dtls-relay-01 aimed at countering Denial of Service attacks. Best regards, Rene On 8/14/2014 11:35 PM, Hedanping (Ana) wrote: > > Hi Sandeep, > > According to your solution "The first RE in the path checks whether C > holds a valid certificate or a pre-shared relay key" which itself is > an authentication/authorization decision. Infact it sounds more like > an AA decision to first access the one-hop relay and then an AA > decision to access the RS. > > [Danping] Your understanding is right. In unconstraint environment, > Relay Elements simply relay the packets to destination. And as we > know, the REs are likely to be constraint devices in constraint > environment such as ad hoc WSNs, thus the battery resource and packet > buffer will be consumed due to relaying packet for C. In other words, > to request resources over a RS that is multiple hops away > intrinsically hints a request of the resource over REs along the hops. > Therefore I believe the a light AA is desired for the first-hop relay > to protect itself and other REs along the route. > > Would it not be simple to consider the relay to be an RS which is > one-hop away and use the not-yet-designed ACE solution for the > first-hop too. > > [Danping] It would be better to design a mechanism which allows AM/AS > issuing a permission for C to access the first-hop RE, the permission > might be transmitted separately or piggybacked with the first AA > message between C and RS. The not-yet-designed ACE solution might be > used too, but it is unnecessary to exchange key to secure the relay > message and the message flow would be different. What do you think? > > Regards, > > Danping > > *From:*Kumar, Sandeep [mailto:sandeep.kumar@philips.com] > *Sent:* Wednesday, August 13, 2014 3:24 PM > *To:* Hedanping (Ana); ace@ietf.org > *Subject:* RE: [Ace] About secure relay of authentication and > authroization messages > > HI Danping > > According to your solution "The first RE in the path checks whether C > holds a valid certificate or a pre-shared relay key" which itself is > an authentication/authorization decision. Infact it sounds more like > an AA decision to first access the one-hop relay and then an AA > decision to access the RS. Would it not be simple to consider the > relay to be an RS which is one-hop away and use the not-yet-designed > ACE solution for the first-hop too. > > Regards > > Sandeep > > *From:*Hedanping (Ana) [mailto:ana.hedanping@huawei.com] > *Sent:* Wednesday, August 13, 2014 2:58 AM > *To:* Kumar, Sandeep; ace@ietf.org > *Subject:* RE: [Ace] About secure relay of authentication and > authroization messages > > Hi Sandeep, > > Thanks for the information and also thank you for showing interest in > this issue. > > The assumption is that, during the AA procedure, there are AA messages > exchanged between the C and RS, which are not directly connected. To > solve DOS attack, I roughly have a solution in mind: > > A relay key/certificate is needed. There might exist more than one RE > along the path between C and RS. The first RE in the path checks > whether C holds a valid certificate or a pre-shared relay key. If > verified, the AA messages from C are relayed normally. Otherwise, the > AA messages from C are ignored. > > Regards, > > Danping > > *From:*Kumar, Sandeep [mailto:sandeep.kumar@philips.com] > *Sent:* Tuesday, August 12, 2014 4:21 PM > *To:* Hedanping (Ana); ace@ietf.org > *Subject:* RE: [Ace] About secure relay of authentication and > authroization messages > > Hi Danping > > I think ACE is at a very early stage that it is better to first solve > the problem without the relay path. At a later stage, the relay path > can be added for scenarios that might need them and ofcourse DoS > protection will be an important issue to consider then. Do you have > any specific solutions to solve the problem? If the DoS protection > solution depends heavily on the AA data then imho it should be solved > in ACE. > > Regards > > Sandeep > > *From:*Ace [mailto:ace-bounces@ietf.org] *On Behalf Of *Hedanping (Ana) > *Sent:* Tuesday, August 12, 2014 5:50 AM > *To:* ace@ietf.org > *Subject:* [Ace] About secure relay of authentication and > authroization messages > > Hi, > > There is an issue that I am not sure whether it is suitable for a > draft: should we consider secure relay of the Authentication and > authorization (AA) messages to protect relay elements along the relay > path? > > DTLS relay and PANA relay have been proposed, however the relay > elements simply relays the AA messages to the server. To avoid DOS > attack, the they limit the frequency and maximum number of times to > relay the AA requests. > > In constraint environment, the relay elements might be energy > constrained devices. If a malicious client intends to exhaust the > relay elements' power by frequently sending AA requests with forged > IPs or IDs, is there any countermeasure to this issue? Do we need to > consider this issue in ACE WG? > > Regards, > > Danping > > ------------------------------------------------------------------------ > > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original message. > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------080706060506000506040402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear colleagues:

FYI - You may wish to have a look at the discussion on the IETF DICE mailing list end of May (messages 240-253; May 27-30, 2014) related to this, see, e.g.,  http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00241.html. This discussion was triggered by some questions I had re suggestions in the security considerations section of draft-kumar-dice-dtls-relay-01 aimed at countering Denial of Service attacks.

Best regards, Rene

On 8/14/2014 11:35 PM, Hedanping (Ana) wrote:

Hi Sandeep,

According to your solution “The first RE in the path checks whether C holds a valid certificate or a pre-shared relay key” which itself is an authentication/authorization decision. Infact it sounds more like an AA decision to first access the one-hop relay and then an AA decision to access the RS.

[Danping] Your understanding is right.  In unconstraint environment, Relay Elements simply relay the packets to destination. And as we know,  the REs are likely to be constraint devices in constraint environment such as ad hoc WSNs, thus the battery resource and packet buffer will be consumed due to relaying packet for C. In other words, to request resources over a RS that is multiple hops away intrinsically hints a request of the resource over REs along the hops.  Therefore I believe the a light AA is desired for the first-hop relay to protect itself and other REs along the route.

 

Would it not be simple to consider the relay to be an RS which is one-hop away and use the not-yet-designed ACE solution for the first-hop too.

[Danping] It would be better to design a mechanism which allows AM/AS issuing a permission for C to access the first-hop RE, the permission might be transmitted separately or piggybacked with the first AA message between C and RS. The not-yet-designed ACE solution might be used too, but it is unnecessary to exchange key to secure the relay message and the message flow would be different.  What do you think?

 

Regards,

Danping

 

 

From: Kumar, Sandeep [mailto:sandeep.kumar@philips.com]
Sent: Wednesday, August 13, 2014 3:24 PM
To: Hedanping (Ana); ace@ietf.org
Subject: RE: [Ace] About secure relay of authentication and authroization messages

 

HI Danping

 

According to your solution “The first RE in the path checks whether C holds a valid certificate or a pre-shared relay key” which itself is an authentication/authorization decision. Infact it sounds more like an AA decision to first access the one-hop relay and then an AA decision to access the RS. Would it not be simple to consider the relay to be an RS which is one-hop away and use the not-yet-designed ACE solution for the first-hop too.

 

Regards

Sandeep

 

From: Hedanping (Ana) [mailto:ana.hedanping@huawei.com]
Sent: Wednesday, August 13, 2014 2:58 AM
To: Kumar, Sandeep; ace@ietf.org
Subject: RE: [Ace] About secure relay of authentication and authroization messages

 

Hi Sandeep,

Thanks for the information and also thank you for showing interest in this issue.

The assumption is that, during the AA procedure, there are AA messages exchanged between the C and RS, which are not directly connected. To solve DOS attack, I roughly have a solution in mind:

 

A relay key/certificate is needed. There might exist more than one RE along the path between C and RS. The first RE in the path checks whether C holds a valid certificate or a pre-shared relay key. If verified, the AA messages from C are relayed normally. Otherwise, the AA messages from C are ignored.

 

Regards,

Danping

From: Kumar, Sandeep [mailto:sandeep.kumar@philips.com]
Sent: Tuesday, August 12, 2014 4:21 PM
To: Hedanping (Ana); ace@ietf.org
Subject: RE: [Ace] About secure relay of authentication and authroization messages

 

Hi Danping

 

I think ACE is at a very early stage that it is better to first solve the problem without the relay path. At a later stage, the relay path can be added for scenarios that might need them and ofcourse DoS protection will be an important issue to consider then. Do you have any specific solutions to solve the problem? If the DoS protection solution depends heavily on the AA data then imho it should be solved in ACE.

 

Regards

Sandeep  

 

From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hedanping (Ana)
Sent: Tuesday, August 12, 2014 5:50 AM
To: ace@ietf.org
Subject: [Ace] About secure relay of authentication and authroization messages

 

Hi,

There is an issue that I am not sure whether it is suitable for a draft: should we consider secure relay of the Authentication and authorization (AA) messages to protect relay elements along the relay path?

 

DTLS relay and PANA relay have been proposed, however the relay elements simply relays the AA messages to the server. To avoid DOS attack, the they limit the frequency and maximum number of times to relay the AA requests.

 

In constraint environment, the relay elements might be energy constrained devices. If a malicious client intends to exhaust the relay elements’ power by frequently sending AA requests with forged IPs or IDs, is there any countermeasure to this issue? Do we need to consider this issue in ACE WG?

 

Regards,

Danping

 

The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.



_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------080706060506000506040402-- From nobody Fri Aug 15 07:32:47 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357D71A073C for ; Fri, 15 Aug 2014 07:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXtHhzmvu-mw for ; Fri, 15 Aug 2014 07:32:45 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AFA91A6F3A for ; Fri, 15 Aug 2014 07:32:45 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A7D6320029; Fri, 15 Aug 2014 10:35:44 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A733F63AC9; Fri, 15 Aug 2014 10:32:44 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8BBFC638D9; Fri, 15 Aug 2014 10:32:44 -0400 (EDT) From: Michael Richardson To: "Hedanping \(Ana\)" In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D8D47A3@szxeml557-mbs.china.huawei.com> References: <77FA386512F0D748BC7C02C36EB1106D8D4164@szxeml557-mbs.china.huawei.com> <77FA386512F0D748BC7C02C36EB1106D8D4220@szxeml557-mbs.china.huawei.com> <77FA386512F0D748BC7C02C36EB1106D8D426A@szxeml557-mbs.china.huawei.com> <77FA386512F0D748BC7C02C36EB1106D8D47A3@szxeml557-mbs.china.huawei.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ace/3VPZr5KcDBuooFPAzBkm_cyHq-s Cc: Carsten Bormann , "Kumar, Sandeep" , "ace@ietf.org" Subject: Re: [Ace] About secure relay of authentication and authroization messages X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 14:32:46 -0000 --=-=-= Hedanping (Ana) wrote: > [Danping] The routers themselves may be energy constrained or the > bandwidth of the network is constrained, which makes the network itself > fragile under a DOS attack that might not target at the final RS... Out of scope. If the network is so fragile, then nothing ACE does will help or hinder. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU+4aCoCLcPvd0N1lAQIknAf/ZTtmSt9BW8biPjTjvSM4Uou+4b7f1QzV 6H8hPpjoNZP1Eh5Xj9zFoS2dPwFxc2SqhTOIrjNXXlTocR5myQzWUs2BghtQvBVC awQSgqfoC1l2FLS7HYnJHYOpqGoQLBRaysXk0LI8zSfZFyEMLlIeckhsaDCPrnix /fV+TKxnn+rupwYiSsTxexGraxGe+6e/h/iRLQM5V31TbODKlH6H9eXUE22mU2zE dhvIsFOgISrLxZP75T+gVRcznee2L+8Dp2zxoHG/iUC1GTPgbJgzVzqFQDdiLGM7 Z42Bt7KowyzoLm6TcqSXac/OtR7IG0Le3UqwKovNEFLCI50qBvhenQ== =p9vt -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Aug 17 10:53:01 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E651A0B7C for ; Sun, 17 Aug 2014 10:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDQ2tr2ucTJR for ; Sun, 17 Aug 2014 10:52:57 -0700 (PDT) Received: from mailscan1.extendcp.co.uk (mailscan23.extendcp.co.uk [176.32.226.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBB251A0B79 for ; Sun, 17 Aug 2014 10:52:56 -0700 (PDT) Received: from lb1.hi.local ([10.0.1.197] helo=mailscan2.extendcp.co.uk) by mailscan-g67.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1XJ4dP-0006ac-H8; Sun, 17 Aug 2014 18:52:51 +0100 Received: from lb1.hi.local ([10.0.1.197] helo=mail41.extendcp.co.uk) by mailscan2.extendcp.co.uk with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1XJ4dM-0006Sg-SW; Sun, 17 Aug 2014 18:52:51 +0100 Received: from host86-171-66-149.range86-171.btcentralplus.com ([86.171.66.149] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1XJ4dF-0005uY-Jc; Sun, 17 Aug 2014 18:52:42 +0100 Message-ID: <53F0EBE4.7050607@gridmerge.com> Date: Sun, 17 Aug 2014 18:52:36 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Hedanping (Ana)" References: <77FA386512F0D748BC7C02C36EB1106D8D4164@szxeml557-mbs.china.huawei.com> <77FA386512F0D748BC7C02C36EB1106D8D4220@szxeml557-mbs.china.huawei.com> <77FA386512F0D748BC7C02C36EB1106D8D473D@szxeml557-mbs.china.huawei.com> <77FA386512F0D748BC7C02C36EB1106D8D4796@szxeml557-mbs.china.huawei.com> In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D8D4796@szxeml557-mbs.china.huawei.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080006050907070006090800" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: http://mailarchive.ietf.org/arch/msg/ace/z8Sei7ggeAV0y7Ja5iXkeVSrX-4 Cc: "Kumar, Sandeep" , "ace@ietf.org" Subject: Re: [Ace] About secure relay of authentication and authroization messages X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 17:53:01 -0000 This is a cryptographically signed message in MIME format. --------------ms080006050907070006090800 Content-Type: multipart/alternative; boundary="------------020603090901050802010009" This is a multi-part message in MIME format. --------------020603090901050802010009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Danping, Comments inline, bracketed by . Robert On 15/08/2014 10:00 AM, Hedanping (Ana) wrote: > > Hi Robert, > > *From:*robert.cragie@gmail.com [mailto:robert.cragie@gmail.com] *On=20 > Behalf Of *Robert Cragie > *Sent:* Friday, August 15, 2014 3:13 PM > *To:* Hedanping (Ana) > *Cc:* Kumar, Sandeep; ace@ietf.org > *Subject:* Re: [Ace] About secure relay of authentication and=20 > authroization messages > > I agree with Sandeep's assessment also; the access from C to the first = > RE should be modelled in a similar way as C to RS. This=20 > meta-modelling, i.e. modelling an AA resource as a resource almost=20 > always comes up and can result in a "death spiral" of dependency if=20 > not modelled carefully, e.g. an ACL is a resource, which needs an ACL, = > which is a resource, which needs an ACL... > > In a constrained environment, the access to the RE must be carefully=20 > controlled and may contain static/implicit rules regarding access. The = > RE is then considered a pass-through for a higher-layer access; this=20 > in itself may be layered any number of times before end-to-end is=20 > achieved, which may or may not imply IP connectivity end-to-end but as = > Carsten has pointed out, that is the assumption for the specific=20 > problem statement. > > [Danping] I totally agree that the access to RE should be carefully=20 > designed in constrained environment. AA_ace is designed for a higher=20 > level resource access/manipulation, the issue discussed here is to=20 > avoid RE unconditionally relaying the AA_ace. It seems that using an=20 > AA_ace to request relay for another AA_ace is a paradox, and a=20 > light-weight access control should be designed. > In the problem statement case, as Carsten points out, there is no=20 relay as such and intermediaries are simply routers. Also, as has been=20 pointed out, how end-to-end IP connectivity is achieved is out of scope=20 wrt. the problem statement. My personal view is that if modelled=20 correctly, the same model can be applied in the meta-cases as described=20 earlier. However, I think initially we should focus on the problem=20 statement. > An RE is thus a pass-through intermediary; whilst we have generally=20 > postponed discussion on intermediaries, this layered approach could=20 > potentially apply to both pass-through and proxy intermediaries. > > [Danping] OK, I am willing to contribute on this topic in the future. > > Robert > > On 15 Aug 2014 04:35, "Hedanping (Ana)" > wrote: > > Hi Sandeep, > > According to your solution "The first RE in the path checks whether C=20 > holds a valid certificate or a pre-shared relay key" which itself is=20 > an authentication/authorization decision. Infact it sounds more like=20 > an AA decision to first access the one-hop relay and then an AA=20 > decision to access the RS. > > [Danping] Your understanding is right. In unconstraint environment,=20 > Relay Elements simply relay the packets to destination. And as we=20 > know, the REs are likely to be constraint devices in constraint=20 > environment such as ad hoc WSNs, thus the battery resource and packet=20 > buffer will be consumed due to relaying packet for C. In other words,=20 > to request resources over a RS that is multiple hops away=20 > intrinsically hints a request of the resource over REs along the hops. = > Therefore I believe the a light AA is desired for the first-hop relay = > to protect itself and other REs along the route. > What typically happens in practice in the constrained case is=20 basically a "lockdown", whereby perimeter nodes (i.e. those which could=20 act as relay) silently discard any incoming packet which cannot be=20 authenticated. Therefore, the network has to be "opened" to allow=20 unauthenticated traffic (which is typically the case in an initial=20 authentication handshake) to be relayed to the authenticator. This can=20 be modelled in a similar way to the C-RS case, whereby the=20 unauthenticated node is C, the RE is RS and the access policy is a=20 simple rule which allows or denies traffic based on a boolean value. In=20 this case, neither C (unauthenticated node) nor RS (RE) have credentials = as such as the traffic is completely unauthenticated. > > Would it not be simple to consider the relay to be an RS which is=20 > one-hop away and use the not-yet-designed ACE solution for the=20 > first-hop too. > > [Danping] It would be better to design a mechanism which allows AM/AS=20 > issuing a permission for C to access the first-hop RE, the permission=20 > might be transmitted separately or piggybacked with the first AA=20 > message between C and RS. The not-yet-designed ACE solution might be=20 > used too, but it is unnecessary to exchange key to secure the relay=20 > message and the message flow would be different. What do you think? > The first AA message is likely to be completely unauthenticated so the=20 concept of AM/AS seem to disappear in this case for this simple reason:=20 The RE cannot make any access decisions based on the message coming from = C (the unauthenticated node) at all, as no part of it can be trusted,=20 nor can it ask an AS to make any decisions on its behalf, nor can any=20 token have been set up a priori with an AS. Therefore access is, as=20 described above, allowed or denied based on whether the network is open. Once the unauthenticated node is authenticated and has network access,=20 it no longer has a C-RS relationship with the RE. Subsequent=20 authentication and authorization decisions will be made that are closer=20 to the problem statement described in ACE. > > --------------020603090901050802010009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Danping,

Comments inline, bracketed by <RCC></RCC>.

Robert

On 15/08/2014 10:00 AM, Hedanping (Ana= ) wrote:

Hi Robert,

 

From: robert.cragie@gmail.com [mailto:robert.cragie@gmail.com] On Behalf Of Robert Cragie
Sent: Friday, August 15, 2014 3:13 PM
To: Hedanping (Ana)
Cc: Kumar, Sandeep; ace@ietf.org
Subject: Re: [Ace] About secure relay of authentication and authroization messages=

 

I agree with Sandeep's assessment also; the access from C to the first RE should be modelled in a similar way as C to RS. This meta-modelling, i.e. modelling an AA resource as a resource almost always comes up and can result in a "death spiral" of dependency if not modelled carefully, e.g. an ACL is a resource, which needs an ACL,&nbs= p; which is a resource, which needs an ACL...<= /p>

In a constrained environment, the access to the RE must be carefully controlled and may contain static/implicit rules regarding access. The RE is then considered a pass-through for a higher-layer access; this in itself may be layered any number of times before end-to-end is achieved, which may or may not imply IP connectivity end-to-end but as Carsten has pointed out, that is the assumption for the specific problem statement.

[Danping] I totally agree that the access to R= E should be carefully designed in constrained environment. AA_ace is designed for a higher level resource access/manipulation, the issue discussed here is to avoid RE unconditionally relaying the AA_ace. It seems that using an AA_ace to request relay for another AA_ace is a paradox, and a light-weight access control should be designed.

<RCC>In the problem statement case, as Carsten points out, there is no relay as such and intermediaries are simply routers. Also, as has been pointed out, how end-to-end IP connectivity is achieved is out of scope wrt. the problem statement. My personal view is that if modelled correctly, the same model can be applied in the meta-cases as described earlier. However, I think initially we should focus on the problem statement.</RCC>

An RE is thus a pass-through intermediary= ; whilst we have generally postponed discussion on intermediaries, this layered approach could potentially apply to both pass-through and proxy intermediaries.

[Danping] OK, I am willing to contribute on this topic in the future.

Robert

On 15 Aug 2014 04:3= 5, "Hedanping (Ana)" <ana.hedanping@hu= awei.com> wrote:

Hi Sandeep,

According to your solution “The first RE in the path checks whether = C holds a valid certificate or a pre-shared relay keyR= 21; which itself is an authentication/authorization decision. Infact it sounds more like an AA decision to first access the one-hop relay and then an AA decision to access the RS.

[Danping] Y= our understanding is right.  In unconstraint environme= nt, Relay Elements simply relay the packets to destination. And as we know,  the REs are likely t= o be constraint devices in constraint environment such as ad hoc WSNs, thus the battery resource and packet buffer will be consumed due to relaying packet for C. In other words, to request resources over a RS that is multiple hops away intrinsically hints a request of the resource over REs along the hops.  Therefore I= believe the a light AA is desired for the first-hop relay to protect itself and other REs along the route.<= /span>

<RCC>What typically happens in practice in the constrained case is basically a "lockdown", whereby perimeter nodes (i.e. those which could act as relay) silently discard any incoming packet which cannot be authenticated. Therefore, the network has to be "opened" to allow unauthenticated traffic (which is typically the case in an initial authentication handshake) to be relayed to the authenticator. This can be modelled in a similar way to the C-RS case, whereby the unauthenticated node is C, the RE is RS and the access policy is a simple rule which allows or denies traffic based on a boolean value. In this case, neither C (unauthenticated node) nor RS (RE) have credentials as such as the traffic is completely unauthenticated.</RCC>

 

Would it not be simple to consider the relay to be an RS which is one-hop away and use the not-yet-designed ACE solution for the first-hop too.=

[Danping] I= t would be better to design a mechanism which allows AM/AS issuing a permission for C to access the first-hop RE, the permission might be transmitted separately or piggybacked with the first AA message between C and RS. The not-yet-designed ACE solution might be used too, but it is unnecessary to exchange key to secure the relay message and the message flow would be different.  What do you think?

=
<RCC>
The first AA message is likely to be completely unauthenticated so the concept of AM/AS seem to disappear in this case for this simple reason: The RE cannot make any access decisions based on the message coming from C (the unauthenticated node) at all, as no part of it can be trusted, nor can it ask an AS to make any decisions on its behalf, nor can any token have been set up a priori with an AS. Therefore access is, as described above, allowed or denied based on whether the network is open.

Once the unauthenticated node is authenticated and has network access, it no longer has a C-RS relationship with the RE. Subsequent authentication and authorization decisions will be made that are closer to the problem statement described in ACE.
</RCC>

 


--------------020603090901050802010009-- --------------ms080006050907070006090800 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNDA4MTcxNzUyMzZaMCMGCSqGSIb3DQEJBDEWBBTVL0/HqVFuSkLIuDXv+riysVQCCDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAEmfQ1sszZtwAwrrbHCxcc4iEbqsX0BhfeBb99UipnpJOqCd 6ginwbeMZxj5H1v1TrxgUk8/ISE42x9v8gx5qdWFuvwhQnoACY2NEm5ccg6h6y75LldBVZmT Abi+xwIpNlJZHippQrovhzcSwhkIoPfFUx/PO8KVhIaZDgAYEbD5NApx4FsAKTrzOM1fc5FL kRWvVw8frP/b/6pTK5/rzYp2HK2vcNwPrtY9cBTLdNds1MZyTtLTJlrT/CZsX8XTVwDdy244 /lIHnPmKQiq68UiOVdx9DBwW9ypRgyFt7+n4ohKeXq+WZe5ps2Umkb9zdbT+YlRyeaOTwwt7 8bJCcTUAAAAAAAA= --------------ms080006050907070006090800-- From nobody Thu Aug 21 06:34:33 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B5E1A02E5 for ; Thu, 21 Aug 2014 06:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e64bRAMWLpsG for ; Thu, 21 Aug 2014 06:34:29 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 552271A02E2 for ; Thu, 21 Aug 2014 06:34:29 -0700 (PDT) Received: from [172.16.254.105] ([80.92.114.129]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M2WgT-1WS4lq22aL-00sOeC for ; Thu, 21 Aug 2014 15:34:27 +0200 Message-ID: <53F5F6F0.4000202@gmx.net> Date: Thu, 21 Aug 2014 15:41:04 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Ace@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Ge7RdUudrxoIHqccgkwDenVXXdJRseB7V" X-Provags-ID: V03:K0:lIcob8v9bRnbENeQN9fsjM/02MfsxM4O1WuoQzXW63Z/Hd74XBc V7vVAAplOJj/wgovDhsDpCB3Cwzbzk5z42rVDy/dkWH0c3R7L4VpKvp5sQJnJZEgpBM3eOJ hhX8foyTXM1iVivf5U73+1AKO/gk1olyrzwDZ6MxxQ3OOHAOlyFSpAmY2PHOTmslIWTLpp9 UCgMEuvkcKFR6OkT94ZlA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/ace/hUAJxXJ8-ntL-GLYxrSHlgjBwws Subject: [Ace] ACE Use Case document X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 13:34:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ge7RdUudrxoIHqccgkwDenVXXdJRseB7V Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, we started a call for adoption of draft-seitz-ace-usecases as a starting point for the use case charter item in July and we were hoping to get a lot of feedback. Unfortunately, it turned out that only very few responded, namely Robert, Michael, Peter, and Rene (whereby Rene voiced concerns). Of course, you may have been on vacation and therefore unable to review the draft and to respond. With the vacation period coming to an end we hope to receive additional feedback from other working group participants. Ciao Hannes & Kepeng --Ge7RdUudrxoIHqccgkwDenVXXdJRseB7V Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJT9fbwAAoJEGhJURNOOiAtLVkH/1GMPj/HC6L10rSZooBM656V Kr0s4nSJR1UFyAK8JpvjPO9JZgyhnyfGkqFKMgW0pyBV8S7SqlClsz5PVwCPPG88 zkUPjIGibycyXduHapL0K/9npWicvpKP+T8V+CoI+97H/Tl/bemyDpWXZKssrRS+ 9/my+1MiqWi71R+BtAteeVSV6PZlNXQ1Ri4fAB+cFjzg9HHfzlMq1RyCoq0vosJw Zm2xL7yAJzUZWSkDNhDX5dFjmdVNuA5XL+oqLUwuxpZ357NBNq9tdEkuvn/w+oD6 R22BP/WcIVyHFV6dzfoCrBcYC1OebH0aLkeS+LospvTH4Sn35cP13GqkvseCn10= =Qfbz -----END PGP SIGNATURE----- --Ge7RdUudrxoIHqccgkwDenVXXdJRseB7V-- From nobody Sat Aug 23 05:24:20 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F019B1A6F9D for ; Sat, 23 Aug 2014 05:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBu_SWzaXnd2 for ; Sat, 23 Aug 2014 05:24:17 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D82451A876A for ; Sat, 23 Aug 2014 05:24:16 -0700 (PDT) Received: from [172.16.254.100] ([80.92.114.249]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lhwgc-1WZEM81LYg-00nBOW for ; Sat, 23 Aug 2014 14:24:14 +0200 Message-ID: <53F88813.8060403@gmx.net> Date: Sat, 23 Aug 2014 14:24:51 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Ace@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cL4mP2VAicdeh5CLMVd57OUrLI77eKJRK" X-Provags-ID: V03:K0:+n6CUO5s/U/I+tQkwt0FWcNg2IIj9sYUpOr4LdzfbW5h6jRyt+i d9OBw9Dhr6jOvll24dGbqhCS/jZ5koCWK2HdhIYJW4qjDPgeN6P1C5g0Dj6wW3mddYokPqD MsWT7MUJD5j4KAdi9uId3Y7/GnyO7Q5nQjZlHFEWzqjWcrc61cbjrGDErG4TGqLO+cYDf3Z IIEA+mp2MWFI+l6SNTBHA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/ace/6OpdoF6lES8oSAeCAtMJjPys2Ew Subject: [Ace] Webex Conference Call about "How to Select Hardware for IoT Systems?" X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 12:24:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cL4mP2VAicdeh5CLMVd57OUrLI77eKJRK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, Various groups in the IETF currently standardize technology for use with constrained devices and the choice of hardware impacts the design of Internet of Things (IoT) systems. To provide guidance RFC 7228 "Terminology for Constrained-Node Networks" defines three classes of devices depending on their RAM and flash memory size. Class 0 characterizes devices that have less than 10 KiB of RAM and less than 100 KiB of flash memory and RFC 7228 adds "... most likely they will not have the resources required to communicate directly with the Internet in a secure manner." For others even class 2 with ~ 50 KiB of RAM and ~ 250 KiB of flash memory is too constrained. With the increasing commercial interest in IoT the question about a reasonable hardware configuration surfaces again and again. At IETF#90 I offered to bring a hardware expert along. Peter Aldworth, a hardware engineer with more than 19 years of experience, will lead the discussion at an upcoming webinar. Please indicate your availability here: http://moreganize.com/bzTrVxhqaHp Ciao Hannes --cL4mP2VAicdeh5CLMVd57OUrLI77eKJRK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJT+IgTAAoJEGhJURNOOiAtyRcH/208s2hMzvAqEnArvUtQ/tw8 zkc+4//xQorPQNDl10Iz9eouLI0Jx2w/APSDAz9qCOGikW5I2XGVKpMxBzS8cIGc vTMii7xXto2bp8buB6gLFpkj0tiUwObEGMuDAVaGACzh4ayL16EcU0YcZ4bPm01h 6i38a5Pp7gxDeIjJ2iJIvmmKoTBxWRlo7slrDL9b8OxsbK+NMmQqO5caM1POFcnB 4x9+wQVj4SASSLK+NzD07FyFvlTKyStRhM0jnO3ScxkRlfI7kDWr6EFaxcbNFRfa T+N2eM7WLrGq9QUSLtPefphDWxrmSp+BcUVJzwQbWLMumzJDJUxeBpl7uclAXqI= =d5E9 -----END PGP SIGNATURE----- --cL4mP2VAicdeh5CLMVd57OUrLI77eKJRK-- From nobody Mon Aug 25 00:07:14 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB331A8AB3 for ; Mon, 25 Aug 2014 00:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqErqeXN-3o7 for ; Mon, 25 Aug 2014 00:07:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9E631A8AB1 for ; Mon, 25 Aug 2014 00:07:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLS86484; Mon, 25 Aug 2014 07:07:08 +0000 (GMT) Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 25 Aug 2014 08:06:11 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.128]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Mon, 25 Aug 2014 15:06:05 +0800 From: Likepeng To: "ace@ietf.org" Thread-Topic: Review of draft-seitz-ace-usecases-01 Thread-Index: Ac/AMwjLqbd6ZDFDQVizyfBoASMU7g== Date: Mon, 25 Aug 2014 07:06:04 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F258186500@SZXEMA501-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F258186500SZXEMA501MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/3-DWrYd2qoviZonpaHrvw6HplTs Subject: [Ace] Review of draft-seitz-ace-usecases-01 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 07:07:12 -0000 --_000_34966E97BE8AD64EAE9D3D6E4DEE36F258186500SZXEMA501MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, Here are my personal review comments for draft-seitz-ace-usecases-01. Overall, it is a very good document. General comments: 1. It is better to change the document title to "use cases and require= ments" because requirements are derived from use cases and even more import= ant than use cases. 2. For each use case, it is better to specify the roles, e.g. who is C= lient, Resource Server, Resource Owner. 3. There are some useful contents in draft-seitz-ace-problem-descripti= on-01 and draft-seitz-ace-design-considerations-00. Maybe we can take some = contents into the use case draft. Detailed comments: 2.1.2: It is better to use "Client", "Resource Server", "Resource Owner" in= stead of "fruit vendor", "transport company", "delivery service" in the req= uirements. 2.2.2: It is better to use "Client", "Resource Server", "Resource Owner" in= stead of "Jane", "Jeffrey" in the requirements. 2.4.2: Requirement U4.7, this seems to be the interaction between Resource = Owner and Authorization Server, should this be out of scope? 3.3: U5.2 talks about offline scenario, but this requirement is not mention= ed in section 3.3. Thanks, Kind Regards Kepeng --_000_34966E97BE8AD64EAE9D3D6E4DEE36F258186500SZXEMA501MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 

Here are my personal review com= ments for draft-seitz-ace-usecases-01.

 

Overall, it is a very good docu= ment.

 

General comments:

1= .   &= nbsp;  It is better to change = the document title to “use cases and requirements” because requ= irements are derived from use cases and even more important than use cases.=

2= .   &= nbsp;  For each use case, it i= s better to specify the roles, e.g. who is Client, Resource Server, Resourc= e Owner.

3= .   &= nbsp;  There are some useful c= ontents in draft-seitz-ace-problem-description-01 and draft-seitz-ace-desig= n-considerations-00. Maybe we can take some contents into the use case draf= t.

 

Detailed comments:

2.1.2: It is better to use R= 20;Client”, “Resource Server”, “Resource Owner̶= 1; instead of “fruit vendor”, “transport company”, = “delivery service” in the requirements.

 

2.2.2: It is better to use R= 20;Client”, “Resource Server”, “Resource Owner̶= 1; instead of “Jane”, “Jeffrey” in the requirements= .

 

2.4.2: Requirement U4.7, this s= eems to be the interaction between Resource Owner and Authorization Server,= should this be out of scope?

 

3.3: U5.2 talks about offline s= cenario, but this requirement is not mentioned in section 3.3.

 

Thanks,

 

Kind Regards<= /p>

Kepeng

 

--_000_34966E97BE8AD64EAE9D3D6E4DEE36F258186500SZXEMA501MBSchi_-- From nobody Mon Aug 25 20:12:39 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520B31A06BD for ; Mon, 25 Aug 2014 20:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fo2FP6nkQpSH for ; Mon, 25 Aug 2014 20:12:35 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0187.outbound.protection.outlook.com [207.46.163.187]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0164C1A06B0 for ; Mon, 25 Aug 2014 20:12:34 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) with Microsoft SMTP Server (TLS) id 15.0.1019.14; Tue, 26 Aug 2014 03:12:33 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.1019.014; Tue, 26 Aug 2014 03:12:33 +0000 From: Anthony Nadalin To: Hannes Tschofenig , "Ace@ietf.org" Thread-Topic: [Ace] ACE Use Case document Thread-Index: AQHPvUSoEtZnaNqOW0WosButZ+xxG5vhsYVQ Date: Tue, 26 Aug 2014 03:12:33 +0000 Message-ID: References: <53F5F6F0.4000202@gmx.net> In-Reply-To: <53F5F6F0.4000202@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [50.46.126.7] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03152A99FF x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199003)(189002)(377454003)(53754006)(19580395003)(83322001)(106116001)(19580405001)(99396002)(95666004)(86362001)(99286002)(50986999)(107046002)(107886001)(105586002)(74502001)(54356999)(76176999)(2656002)(74662001)(46102001)(31966008)(106356001)(81542001)(77982001)(76576001)(85306004)(81342001)(101416001)(33646002)(76482001)(87936001)(4396001)(64706001)(108616004)(86612001)(83072002)(20776003)(79102001)(66066001)(21056001)(80022001)(90102001)(85852003)(92566001)(74316001)(2501001)(42262002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB309; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/ace/BzcMXUqdaGrtKQp5obiakoIefcs Subject: Re: [Ace] ACE Use Case document X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 03:12:37 -0000 TXkgbWFqb3IgaXNzdWVzIGFuZCBjb21tZW50cyB3aXRoIHRoZSBkb2N1bWVudCBpcyB0aGF0IGl0 IGRvZXMgbm90IGNvdmVyIGEgbG90IG9mIHRoZSB1c2UgY2FzZSB0aGF0IHdlIHNlZSBpbiB0aGUg bWFya2V0cGxhY2UsIHRoZSB1c2UgY2FzZSBkb2N1bWVudCBjYW4gYmUgYnJvYWRlciB0aGFuIHRo ZSBzY29wZSBvZiB0aGUgV0cgKGV2ZW4gdGhvdWdoIEkgZG9uJ3Qgc2VlIG11Y2ggaW4gdGhlIGNo YXJ0ZXIgdGhhdCBsaW1pdHMgdGhlIHNjb3BlKS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IEFjZSBbbWFpbHRvOmFjZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg SGFubmVzIFRzY2hvZmVuaWcNClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMjEsIDIwMTQgNjo0MSBB TQ0KVG86IEFjZUBpZXRmLm9yZw0KU3ViamVjdDogW0FjZV0gQUNFIFVzZSBDYXNlIGRvY3VtZW50 DQoNCkhpIGFsbCwNCg0Kd2Ugc3RhcnRlZCBhIGNhbGwgZm9yIGFkb3B0aW9uIG9mIGRyYWZ0LXNl aXR6LWFjZS11c2VjYXNlcyBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvciB0aGUgdXNlIGNhc2UgY2hh cnRlciBpdGVtIGluIEp1bHkgYW5kIHdlIHdlcmUgaG9waW5nIHRvIGdldCBhIGxvdCBvZiBmZWVk YmFjay4NCg0KVW5mb3J0dW5hdGVseSwgaXQgdHVybmVkIG91dCB0aGF0IG9ubHkgdmVyeSBmZXcg cmVzcG9uZGVkLCBuYW1lbHkgUm9iZXJ0LCBNaWNoYWVsLCBQZXRlciwgYW5kIFJlbmUgKHdoZXJl YnkgUmVuZSB2b2ljZWQgY29uY2VybnMpLg0KDQpPZiBjb3Vyc2UsIHlvdSBtYXkgaGF2ZSBiZWVu IG9uIHZhY2F0aW9uIGFuZCB0aGVyZWZvcmUgdW5hYmxlIHRvIHJldmlldyB0aGUgZHJhZnQgYW5k IHRvIHJlc3BvbmQuDQoNCldpdGggdGhlIHZhY2F0aW9uIHBlcmlvZCBjb21pbmcgdG8gYW4gZW5k IHdlIGhvcGUgdG8gcmVjZWl2ZSBhZGRpdGlvbmFsIGZlZWRiYWNrIGZyb20gb3RoZXIgd29ya2lu ZyBncm91cCBwYXJ0aWNpcGFudHMuDQoNCkNpYW8NCkhhbm5lcyAmIEtlcGVuZw0KDQo= From nobody Tue Aug 26 00:02:26 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3E61A0970 for ; Tue, 26 Aug 2014 00:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.218 X-Spam-Level: X-Spam-Status: No, score=-0.218 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1vigWGsIVlg for ; Tue, 26 Aug 2014 00:02:21 -0700 (PDT) Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id 41C2B1A0864 for ; Tue, 26 Aug 2014 00:02:21 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by outbox.sics.se (Postfix) with ESMTPS id 0FEE685B for ; Tue, 26 Aug 2014 09:02:20 +0200 (CEST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s7Q72J8o006621 for ; Tue, 26 Aug 2014 09:02:19 +0200 Received: from [192.168.0.108] (unknown [85.235.11.178]) (Authenticated sender: ludwig@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 411CF40116 for ; Tue, 26 Aug 2014 09:02:20 +0200 (CEST) Message-ID: <53FC30F4.6000205@sics.se> Date: Tue, 26 Aug 2014 09:02:12 +0200 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: ace@ietf.org References: <53F5F6F0.4000202@gmx.net> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040805030400070604010909" X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sics-se:default, sics-se:default, base:default, @@RPTN) X-p0f-Info: os=Solaris 10, link=Ethernet or modem X-CanIt-Geo: =?UTF-8?Q?ip=3D85.235.11.178; _country=3DSE; _region=3DSk=C3=A5ne; _city=3DLund; _latitude=3D55.7000; _longitude=3D13.1833; _http://maps.google.com/maps=3Fq=3D55.7000,13.1833&z=3D6?= X-CanItPRO-Stream: outbound-sics-se:outbound (inherits from outbound-sics-se:default, sics-se:default, base:default) X-Canit-Stats-ID: 09MHj2jvJ - d932da288d50 - 20140826 X-Antispam-Training-Forget: https://canit.sunet.se/canit/b.php?i=09MHj2jvJ&m=d932da288d50&t=20140826&c=f X-Antispam-Training-Nonspam: https://canit.sunet.se/canit/b.php?i=09MHj2jvJ&m=d932da288d50&t=20140826&c=n X-Antispam-Training-Spam: https://canit.sunet.se/canit/b.php?i=09MHj2jvJ&m=d932da288d50&t=20140826&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/2kYUSuZ5GrxRUPgg82eRV2Ccv_c Subject: Re: [Ace] ACE Use Case document X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 07:02:25 -0000 This is a cryptographically signed message in MIME format. --------------ms040805030400070604010909 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 08/26/2014 05:12 AM, Anthony Nadalin wrote: > My major issues and comments with the document is that it does not cove= r a lot of the use case that we see in the marketplace, > the use case document can be broader than the scope of the WG (even tho= ugh I don't see much in the charter that limits the scope). If you want to contribute more use cases that are relevant, you are most = welcome. Do you think the use cases in the current document are relevant? Are there aspects of these use cases that you feel are missing in the=20 document? Regards, Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms040805030400070604010909 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwiRTjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE0MDEwNzA3MjgzNVoXDTE1MDEwNzEyNTgyMlowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnLm1tc30QxHa9wtdVjC3NgxjLJicnccm0HD+ 1X16kPMKGvwps8F1oDhYn7jXIe46p1AuJMzLK0GIioE4JwxCFGdvpz7cg2xyTyrdBVUzSqez Dfqt4FOJq6hrdrIMS8MHEzl7Jk02gv9cTn/pHQvDpkiThRpbSLU5mlMqtEQ8gDQY5YyBX0Mv 5qculV08I2JU8HEeTt1oeqhvBImgQfOVYMDatHlWHUVVrmYd6iIo+cuiUGd5kiA0XuaLYX0E oCoao/z5Wg9U0sQlx0hl4r96Q+NdoZZ1prfts3qtyBzJ2hu135aikigzJ6sueWHv/jbISUek tOMm0xkx1GOqqWtEAwIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRZmjjBh8N3klra+mVQgC00 pl68ZTAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQELBQADggEBAHqEYmtWr83S+iLXE97KBnHJZiMr6PMuLKxmh0o6UJJwKgf+KTP2czxRnPSI +whuqfQZdmz6g3A2K8AooMU0RXrzncnX1c4826APdnXkRxnGQxtZXI1wuhPn4z7iDKZ6ij9u K5Pfn10JL/ERDig2qJQbqvhtIAx0RY7y7r+hLMvgXVq9mf3WRJYmGQeFW+N9t5Z1eEwG4m9R KAZm0fnfeDn/Ai4kmxTckBH7dZwW2lTtwQqQ4su+PGCJ0e9ndBLpvTqaYGSAl+L7PO7vxPhS /cS67Xa6BtnYJLTr3MaGXaN+CEUFSfwQHa9DKcAqh3kldErI3kCvnot0CigBl4aILOEwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwiRTjAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA4MjYwNzAyMTJaMCMGCSqGSIb3DQEJBDEW BBR+DSvBJekMLTsLdBdTTWCb7XP1SzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCJFOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMIkU4wDQYJKoZIhvcNAQEBBQAE ggEAcZiLTynceg24wQPAjZACuNRGjwwy/0MvTsAgPDgYtuj49taL9hqFg0LMv29jDqaw5JxQ 2sIQNsWsTDjGtC792NBdL5FmUOLIQbpAJ1oW+qLZqunTM3AYQvAet4KTwYFWKbsCP+pWAENg XRnrzbw0Eq+HhIw4mKM3sZavNnwBDHrsghJtbF/Ylr0qn1h29IY0cQzypTuzjkb9jcWsJZa4 JXVhra+ynKrbkoPJIQdHUpjGfhSjHtGJZm/N771TlVbuOLOp7pUHBD1xJiN9PnZlOwO72dFW X5gy8pMoTdsPgsg0qBgMj8Yqeyd95dCX3oLDrIqTAGxHRJ91Q1Rxhpa2DwAAAAAAAA== --------------ms040805030400070604010909-- From nobody Tue Aug 26 00:12:16 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519201A0AD9 for ; Tue, 26 Aug 2014 00:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X_yPS6J0hHwE for ; Tue, 26 Aug 2014 00:12:14 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07AD01A0864 for ; Tue, 26 Aug 2014 00:12:14 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id lf10so22825084pab.16 for ; Tue, 26 Aug 2014 00:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=435/neh+okuRj8SLahBJLZczFZWDUJaqMQzW+YtBaEc=; b=R0IB2WFdxN1L4+9XXakSpxEbjaFxjvUEi2WFpCoc9Ixkb4jaVEuZGQZm8ytTtwQ20s McsOxqNnph3HlqeeR1ICwCiH+7gwJexcBHmNgczwLRF3epYOKH9ZFU05727EsyaSaUFr UYc3hcwlKnMxdArMVsGjZXimtjw8ELMSCXWRaXBMOvsMglOisR/Z1y+335Jres8NeYe/ 59qjCjam6dXo3melNx6Svup3qBjHzIZk9EQtQQL7PeAaZ037SXA08t+iYML4012eoEHU B4GoaPPce4gzWlQKercsOWKxCPbGDED+eIPX2HhDMcNq+xT7fb73mfYR6hMx/DgqAtHn EewA== X-Received: by 10.70.103.42 with SMTP id ft10mr6508222pdb.2.1409037132533; Tue, 26 Aug 2014 00:12:12 -0700 (PDT) Received: from [192.168.0.104] ([203.230.193.47]) by mx.google.com with ESMTPSA id fz10sm3100466pdb.50.2014.08.26.00.12.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Aug 2014 00:12:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jong-Hyouk Lee In-Reply-To: Date: Tue, 26 Aug 2014 16:12:08 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53F5F6F0.4000202@gmx.net> To: Anthony Nadalin X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/HV-dHZPl0fwS6yGkBW8A2BRMVdY Cc: Hannes Tschofenig , "Ace@ietf.org" Subject: Re: [Ace] ACE Use Case document X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 07:12:15 -0000 Hi all As like Anthony, I think that the use-cases document should be broader = than the current one. The working group should try to get some more = inputs from folks before trying to fire the call for adoption.=20 J. -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon On Aug 26, 2014, at 12:12 PM, Anthony Nadalin = wrote: > My major issues and comments with the document is that it does not = cover a lot of the use case that we see in the marketplace, the use case = document can be broader than the scope of the WG (even though I don't = see much in the charter that limits the scope). >=20 > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig > Sent: Thursday, August 21, 2014 6:41 AM > To: Ace@ietf.org > Subject: [Ace] ACE Use Case document >=20 > Hi all, >=20 > we started a call for adoption of draft-seitz-ace-usecases as a = starting point for the use case charter item in July and we were hoping = to get a lot of feedback. >=20 > Unfortunately, it turned out that only very few responded, namely = Robert, Michael, Peter, and Rene (whereby Rene voiced concerns). >=20 > Of course, you may have been on vacation and therefore unable to = review the draft and to respond. >=20 > With the vacation period coming to an end we hope to receive = additional feedback from other working group participants. >=20 > Ciao > Hannes & Kepeng >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Tue Aug 26 00:23:10 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D571A0ACC for ; Tue, 26 Aug 2014 00:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.218 X-Spam-Level: X-Spam-Status: No, score=-0.218 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsJIoy5RIrdG for ; Tue, 26 Aug 2014 00:23:02 -0700 (PDT) Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id C88D91A096C for ; Tue, 26 Aug 2014 00:23:01 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by outbox.sics.se (Postfix) with ESMTPS id 275BA18F for ; Tue, 26 Aug 2014 09:23:01 +0200 (CEST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s7Q7N0kd018278 for ; Tue, 26 Aug 2014 09:23:00 +0200 Received: from [192.168.0.108] (unknown [85.235.11.178]) (Authenticated sender: ludwig@sics.se) by letter.sics.se (Postfix) with ESMTPSA id A616340116 for ; Tue, 26 Aug 2014 09:23:00 +0200 (CEST) Message-ID: <53FC35D3.5000309@sics.se> Date: Tue, 26 Aug 2014 09:22:59 +0200 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: ace@ietf.org References: <53CD27D3.1010709@gmx.net> <53DB12A2.90209@gmail.com> In-Reply-To: <53DB12A2.90209@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000906080905060106000803" X-Bayes-Prob: 0.995 (Score 5, tokens from: outbound, outbound-sics-se:default, sics-se:default, base:default, @@RPTN) X-p0f-Info: os=Solaris 10, link=Ethernet or modem X-CanIt-Geo: =?UTF-8?Q?ip=3D85.235.11.178; _country=3DSE; _region=3DSk=C3=A5ne; _city=3DLund; _latitude=3D55.7000; _longitude=3D13.1833; _http://maps.google.com/maps=3Fq=3D55.7000,13.1833&z=3D6?= X-CanItPRO-Stream: outbound-sics-se:outbound (inherits from outbound-sics-se:default, sics-se:default, base:default) X-Canit-Stats-ID: 09MHjn0nC - 5ab3ee167d16 - 20140826 X-Antispam-Training-Forget: https://canit.sunet.se/canit/b.php?i=09MHjn0nC&m=5ab3ee167d16&t=20140826&c=f X-Antispam-Training-Nonspam: https://canit.sunet.se/canit/b.php?i=09MHjn0nC&m=5ab3ee167d16&t=20140826&c=n X-Antispam-Training-Spam: https://canit.sunet.se/canit/b.php?i=09MHjn0nC&m=5ab3ee167d16&t=20140826&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/GO9mjsJjXL5KhAiEVExmxsz23WY Subject: Re: [Ace] Call for adoption on draft-seitz-ace-usecases-01 ("ACE Use Cases") X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 07:23:04 -0000 This is a cryptographically signed message in MIME format. --------------ms000906080905060106000803 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 08/01/2014 06:08 AM, Rene Struik wrote: > Dear colleagues: > > I participated in the ACE discussions in Toronto last week, read > draft-seitz-ace-usecases-01, and saw the email discussions that ensued > since the meeting. > > Unfortunately, I cannot support adopting the use case draft in its > current form. > > I think it is far from ready to be a fruitful base for incremental > improvements as a WG document. Moreover, there seems to be quite some > disagreement as to whether certain use cases (discussed on the mailing > list over the last few days, but mostly not in the draft) are considere= d > inside scope of this working group. > > We should not simply adopt a draft, just because it is there. It also > should have sufficient merit to have a chance progressing to an > informational RFC or document that otherwise would guide the developmen= t > of an authorization and authentication solution as a proposed standard.= > Right now, I feel it does not have these qualities. > I would provide a more succinct description of use cases that capture > security-relevant events, including the following: It is not really clear to me what you find lacking with the current draft. The use case descriptions are rather succinct, with a minimum of flavor text to keep them readable and give some real world application context. They do capture security-relevant events (or rather Authentication and Authorization relevant, since its ACE and not SCE), such as > 1) change of network composition: new kid on the block; See e.g. the home automation use case, requirement U2.1 and U2.2 > temporary (repair) or permanently (disposed) decommissioned device; See e.g. the building automation use case section 2.4.1.4 > temporary or > permanent network union, resp. partitioning; Perhaps you could clarify how that affects authentication and=20 authorization solutions? Unless you want ACE to do network access control= =2E > 2) change of roles of devices: new role assigned to device; role > retracted from device; assignment of meta-roles and retraction hereof; > roles based on global policies, resp. local decisions; Why the focus on role-based access control? Do you mean changes in=20 access rights and/or access control policies? I think these are covered=20 quite extensively in the use cases, e.g. U2.1, U2.2, U3.1, U3.2 > 3) initialization or roles of devices and evolution hereof during > lifecycle of devices and networks, all the way from conception (e.g., > chip manufacturing) to system integration, etc. (e.g., change of > ownership/control, logical/procedural transfer operation), to > operational use, replacement, disposition. The security lifecycle of devices is covered in the building automation use case. Feel free to make concrete suggestions where you think more details would be useful. > > I would also go into more details as to what might be different with > constrained networks. Simply allocating a single third-party device to > do arbitrage may not do the job, since delegation of computational or > storage cost may be offset by communication cost, energy consumption, > and denial of service risk. One should support both peer-to-peer > (localized) and outsourced ("cloud based", if one wishes) scenarios. The use cases make no general assumption about a single third-party device to do arbitraging. There is some reference to authorization=20 servers in the building automation use case (an oversight on my part).=20 This should be removed in the next update. > I would also pay lots of attention to distinction between homogeneous > and heterogeneous trust domain scenarios. After all, one should > facilitate "mix and match" scenarios, where devices may be procured fro= m > multiple vendors, that may not know each other and, even if they would,= > not trust each other. See e.g. U2.5 and to some extent U4.6 > Having any presumption that manufacturers should > do secret handshakes for their devices to be able to communicate > securely may hamper significantly deployment in ease of use manner and > never bring the full potential of internet of things forward. Moreover,= > it could stifle innovation, since baking in pre-established > relationships may force the hand of contractual parties in favor of > vested interests and the bigger party. I don't quite see how the use case draft makes any presumptions on secret handshakes. Could you elaborate on what you mean? > Use cases should focus on both consumer and non-consumer style scenario= s > and include, industrial control, critical infrastructure, etc. Consumer style scenarios like e.g. home automation and personal health monitoring? Non-consumer style scenarios like container monitoring and smart metering= ? I don't quite see what your issue with the current document is in that respect. I agree that we should have a good SCADA/ICS use case, that's why I asked for input on that one. > I am happy to contribute to use cases that incorporate the above feedba= ck and > that borrow from experience gained in discussions with industrial > control and other wireless sensor standardization groups, covering both= > security, ease of use, and ease of deployment and provisioning, over th= e > last 5-10 years. By all means please do contribute them. > Lastly, it would be good to take the viewpoint as to what > functionalities are required and emphasize slghtly less those > constraints that may become less of an issue over time (e.g., those in > the digital vs. the analog domain). As we heard during the ACE session > in Toronto, lots of crypto can be considered (or can soon be considered= ) > a commodity for low-hanging fruit applications one may wish to target. I really don't see how the use case draft makes any assumptions on the=20 hardware crypto capabilities. The only thing it states is that=20 constrained devices have limited resources (especially battery) and that = the authentication and authorization measures should take these into=20 account. Regards, Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms000906080905060106000803 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwiRTjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE0MDEwNzA3MjgzNVoXDTE1MDEwNzEyNTgyMlowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnLm1tc30QxHa9wtdVjC3NgxjLJicnccm0HD+ 1X16kPMKGvwps8F1oDhYn7jXIe46p1AuJMzLK0GIioE4JwxCFGdvpz7cg2xyTyrdBVUzSqez Dfqt4FOJq6hrdrIMS8MHEzl7Jk02gv9cTn/pHQvDpkiThRpbSLU5mlMqtEQ8gDQY5YyBX0Mv 5qculV08I2JU8HEeTt1oeqhvBImgQfOVYMDatHlWHUVVrmYd6iIo+cuiUGd5kiA0XuaLYX0E oCoao/z5Wg9U0sQlx0hl4r96Q+NdoZZ1prfts3qtyBzJ2hu135aikigzJ6sueWHv/jbISUek tOMm0xkx1GOqqWtEAwIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRZmjjBh8N3klra+mVQgC00 pl68ZTAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQELBQADggEBAHqEYmtWr83S+iLXE97KBnHJZiMr6PMuLKxmh0o6UJJwKgf+KTP2czxRnPSI +whuqfQZdmz6g3A2K8AooMU0RXrzncnX1c4826APdnXkRxnGQxtZXI1wuhPn4z7iDKZ6ij9u K5Pfn10JL/ERDig2qJQbqvhtIAx0RY7y7r+hLMvgXVq9mf3WRJYmGQeFW+N9t5Z1eEwG4m9R KAZm0fnfeDn/Ai4kmxTckBH7dZwW2lTtwQqQ4su+PGCJ0e9ndBLpvTqaYGSAl+L7PO7vxPhS /cS67Xa6BtnYJLTr3MaGXaN+CEUFSfwQHa9DKcAqh3kldErI3kCvnot0CigBl4aILOEwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwiRTjAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA4MjYwNzIyNTlaMCMGCSqGSIb3DQEJBDEW BBT7a5K2qCo29w4qN9m6U47aTa0c3TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCJFOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMIkU4wDQYJKoZIhvcNAQEBBQAE ggEAPuJiZyDhTMmNPPQs73yhA/DTgvIA0k9BCcDYD4q5Is1gQYPbTZeWcb5hssxq/v3wgU2E 0xAp4lB4iT7gu85R8YieG/0HgXkDxCG3m51jPz9DeRcRpAc8YyNEWwvotL7KXtbKnuEDSeHn PhaCL6Ox/ws+jKRJak87nnMw8l4oYzBwbckAy05RQlBuAIy7PTpLw0LCZkk2hg09J+8gYaZ6 ElX3GzchgtG6sKu+vFBhqh/wxLbAOHumYF2mCs755ISRHf9/vIG2qm70fXRXvLBfcc6HohUI ysGeF1m7SwQ3u3QeZqVtyto5BF0+KTgVyXY4EV0r+pX8YEomWTiKRdsfMgAAAAAAAA== --------------ms000906080905060106000803-- From nobody Tue Aug 26 00:35:03 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF921A0ADB for ; Tue, 26 Aug 2014 00:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDhSjtvBDsK5 for ; Tue, 26 Aug 2014 00:34:55 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0011.outbound.protection.outlook.com [213.199.154.11]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0BA1A0AD1 for ; Tue, 26 Aug 2014 00:34:54 -0700 (PDT) Received: from DBXPR04CA003.eurprd04.prod.outlook.com (10.255.191.151) by DB3PR04MB0634.eurprd04.prod.outlook.com (25.160.45.148) with Microsoft SMTP Server (TLS) id 15.0.1015.17; Tue, 26 Aug 2014 07:34:50 +0000 Received: from DB3FFO11FD004.protection.gbl (2a01:111:f400:7e04::151) by DBXPR04CA003.outlook.office365.com (2a01:111:e400:9800::23) with Microsoft SMTP Server (TLS) id 15.0.1015.19 via Frontend Transport; Tue, 26 Aug 2014 07:34:50 +0000 Received: from mail.philips.com (206.191.240.52) by DB3FFO11FD004.mail.protection.outlook.com (10.47.216.93) with Microsoft SMTP Server (TLS) id 15.0.1010.11 via Frontend Transport; Tue, 26 Aug 2014 07:34:50 +0000 Received: from DBXPRD9003MB059.MGDPHG.emi.philips.com ([169.254.7.226]) by DBXPRD9003HT001.MGDPHG.emi.philips.com ([141.251.25.206]) with mapi id 14.16.0466.000; Tue, 26 Aug 2014 07:34:49 +0000 From: "Kumar, Sandeep" To: Anthony Nadalin , Hannes Tschofenig , "Ace@ietf.org" Thread-Topic: [Ace] ACE Use Case document Thread-Index: AQHPvUSp1/liP+U3d0aCbPEfpgzmOJviPJ6AgABIPTA= Date: Tue, 26 Aug 2014 07:34:49 +0000 Message-ID: References: <53F5F6F0.4000202@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:206.191.240.52; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(428002)(85714005)(377454003)(189002)(53754006)(13464003)(199003)(86362001)(99396002)(81156004)(76176999)(54356999)(68736004)(106466001)(19580405001)(50986999)(79102001)(92726001)(6806004)(46406003)(69596002)(105586002)(83072002)(15975445006)(1511001)(44976005)(97756001)(64706001)(92566001)(2421001)(83322001)(77096002)(81342001)(2656002)(101416001)(21056001)(85852003)(46102001)(106116001)(23726002)(107046002)(77982001)(97736001)(33656002)(4396001)(50466002)(55846006)(66066001)(81542001)(107886001)(104016003)(31966008)(76482001)(20776003)(87936001)(95666004)(47776003)(19580395003)(74502001)(84676001)(80022001)(90102001)(74662001)(85306004)(2501001)(7059011)(567094001); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR04MB0634; H:mail.philips.com; FPR:; MLV:sfv; PTR:ErrorRetry; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 03152A99FF Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is 206.191.240.52) smtp.mailfrom=sandeep.kumar@philips.com; X-OriginatorOrg: philips.com Archived-At: http://mailarchive.ietf.org/arch/msg/ace/slfSmH7IOe-_xzl7bXJIyvaI2g8 Subject: Re: [Ace] ACE Use Case document X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 07:34:58 -0000 Hi Anthony Can you clarify if you are missing use cases that you wish were there or yo= u also see requirements (that are in scope of the charter) missing that sho= uld have been derived from those missing use cases. If latter, can you be m= ore specific about those missing requirements. Thanks Sandeep -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Anthony Nadalin Sent: Tuesday, August 26, 2014 5:13 AM To: Hannes Tschofenig; Ace@ietf.org Subject: Re: [Ace] ACE Use Case document My major issues and comments with the document is that it does not cover a = lot of the use case that we see in the marketplace, the use case document c= an be broader than the scope of the WG (even though I don't see much in the= charter that limits the scope). -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, August 21, 2014 6:41 AM To: Ace@ietf.org Subject: [Ace] ACE Use Case document Hi all, we started a call for adoption of draft-seitz-ace-usecases as a starting po= int for the use case charter item in July and we were hoping to get a lot o= f feedback. Unfortunately, it turned out that only very few responded, namely Robert, M= ichael, Peter, and Rene (whereby Rene voiced concerns). Of course, you may have been on vacation and therefore unable to review the= draft and to respond. With the vacation period coming to an end we hope to receive additional fee= dback from other working group participants. Ciao Hannes & Kepeng _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From nobody Tue Aug 26 00:37:51 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C271A0AD9 for ; Tue, 26 Aug 2014 00:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4cGK6qwa_WH for ; Tue, 26 Aug 2014 00:37:47 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0019.outbound.protection.outlook.com [213.199.154.19]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9FC61A0AD1 for ; Tue, 26 Aug 2014 00:37:46 -0700 (PDT) Received: from DBXPR04CA009.eurprd04.prod.outlook.com (10.255.191.157) by AM3PR04MB0632.eurprd04.prod.outlook.com (10.255.133.153) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Tue, 26 Aug 2014 07:37:44 +0000 Received: from DB3FFO11FD007.protection.gbl (2a01:111:f400:7e04::170) by DBXPR04CA009.outlook.office365.com (2a01:111:e400:9800::29) with Microsoft SMTP Server (TLS) id 15.0.1015.19 via Frontend Transport; Tue, 26 Aug 2014 07:37:43 +0000 Received: from mail.philips.com (206.191.240.52) by DB3FFO11FD007.mail.protection.outlook.com (10.47.216.96) with Microsoft SMTP Server (TLS) id 15.0.1010.11 via Frontend Transport; Tue, 26 Aug 2014 07:37:43 +0000 Received: from DBXPRD9003MB059.MGDPHG.emi.philips.com ([169.254.7.226]) by DBXPRD9003HT003.MGDPHG.emi.philips.com ([141.251.25.208]) with mapi id 14.16.0466.000; Tue, 26 Aug 2014 07:37:40 +0000 From: "Kumar, Sandeep" To: Jong-Hyouk Lee , Anthony Nadalin Thread-Topic: [Ace] ACE Use Case document Thread-Index: AQHPvUSp1/liP+U3d0aCbPEfpgzmOJviPJ6AgABC8ACAAAZkAA== Date: Tue, 26 Aug 2014 07:37:39 +0000 Message-ID: References: <53F5F6F0.4000202@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:206.191.240.52; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(428002)(85714005)(51704005)(13464003)(377454003)(53754006)(199003)(24454002)(189002)(76482001)(80022001)(90102001)(4396001)(92566001)(2421001)(104016003)(77982001)(55846006)(87936001)(97736001)(85306004)(81342001)(97756001)(101416001)(21056001)(20776003)(46406003)(47776003)(64706001)(79102001)(83072002)(66066001)(33656002)(1511001)(85852003)(92726001)(86362001)(84676001)(95666004)(105586002)(99396002)(44976005)(107046002)(6806004)(50466002)(19580395003)(77096002)(83322001)(74502001)(19580405001)(76176999)(81542001)(106116001)(81156004)(325944007)(69596002)(46102001)(106466001)(50986999)(31966008)(15975445006)(54356999)(2656002)(74662001)(68736004)(23726002)(7059011)(567094001); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR04MB0632; H:mail.philips.com; FPR:; MLV:sfv; PTR:ErrorRetry; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 03152A99FF Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is 206.191.240.52) smtp.mailfrom=sandeep.kumar@philips.com; X-OriginatorOrg: philips.com Archived-At: http://mailarchive.ietf.org/arch/msg/ace/F--J4TK4GegTYwjMMyDeVVOFsRk Cc: Hannes Tschofenig , "Ace@ietf.org" Subject: Re: [Ace] ACE Use Case document X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 07:37:49 -0000 The call for adoption is only to make this a WG document so that folks can = contribute to a single document. The document can only get broader with con= sensus if it is a WG document. Do you think there are issues in the current= use cases that should be removed? Sandeep -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Jong-Hyouk Lee Sent: Tuesday, August 26, 2014 9:12 AM To: Anthony Nadalin Cc: Hannes Tschofenig; Ace@ietf.org Subject: Re: [Ace] ACE Use Case document Hi all As like Anthony, I think that the use-cases document should be broader than= the current one. The working group should try to get some more inputs from= folks before trying to fire the call for adoption. J. -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol= Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon On Aug 26, 2014, at 12:12 PM, Anthony Nadalin wrote= : > My major issues and comments with the document is that it does not cover = a lot of the use case that we see in the marketplace, the use case document= can be broader than the scope of the WG (even though I don't see much in t= he charter that limits the scope). > > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig > Sent: Thursday, August 21, 2014 6:41 AM > To: Ace@ietf.org > Subject: [Ace] ACE Use Case document > > Hi all, > > we started a call for adoption of draft-seitz-ace-usecases as a starting = point for the use case charter item in July and we were hoping to get a lot= of feedback. > > Unfortunately, it turned out that only very few responded, namely Robert,= Michael, Peter, and Rene (whereby Rene voiced concerns). > > Of course, you may have been on vacation and therefore unable to review t= he draft and to respond. > > With the vacation period coming to an end we hope to receive additional f= eedback from other working group participants. > > Ciao > Hannes & Kepeng > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From nobody Tue Aug 26 02:07:04 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851D41A6EE7 for ; Tue, 26 Aug 2014 02:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucMU7DmChBXV for ; Tue, 26 Aug 2014 02:07:00 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 540561A6EF2 for ; Tue, 26 Aug 2014 02:07:00 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id p10so21939671pdj.22 for ; Tue, 26 Aug 2014 02:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NcJSZjBqeH68IbLdIPRgOh51Hu6slHDlvS0IL5RS2MU=; b=K6mKmU8A078du9n9rM7J+Y95ymXHFKzVv6GcdABflBcul2XQyOP4Lo0QayOu/XPlTv ZrMRBC9CSBC96gEGB6Vc41Mt8+gVetCr+72epE03zumHcO5GTP0S93UoxZXahFvqIfbQ vr31qkXdTDuZ/ZtT2a8ZgLBR04qQEmJKl22e3EtcMiOjD5iLG32iKS9rezBkFiWucTDi fAmMywbLUO6fCkmL+2Ua+xl6xeRJxCGkAGvnEZ1NLkmZ5TdkBfILFqd3ibbPN/mKJhfI qQ7IdgAeh/KFId2layg5uxPcISbHhmWI06CsDn+f0RwXWRSUDkEcwFnFEHHkwb7Eo6CM MkiA== X-Received: by 10.70.34.235 with SMTP id c11mr35358393pdj.76.1409044019866; Tue, 26 Aug 2014 02:06:59 -0700 (PDT) Received: from [192.168.0.104] ([203.230.193.47]) by mx.google.com with ESMTPSA id ow2sm3664230pdb.27.2014.08.26.02.06.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Aug 2014 02:06:59 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jong-Hyouk Lee In-Reply-To: Date: Tue, 26 Aug 2014 18:06:54 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <5C0C065C-2F78-4FF8-ACBC-F359D33C266F@gmail.com> References: <53F5F6F0.4000202@gmx.net> To: "Kumar, Sandeep" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/kfh_Adh-uTfGNmZgX49Wybofwbo Cc: Anthony Nadalin , Hannes Tschofenig , "Ace@ietf.org" Subject: Re: [Ace] ACE Use Case document X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 09:07:02 -0000 -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon On Aug 26, 2014, at 4:37 PM, Kumar, Sandeep = wrote: > The call for adoption is only to make this a WG document so that folks = can contribute to a single document. The document can only get broader = with consensus if it is a WG document. I do not think so. When an individual document has enough supports for = adoption, the document can be a WG document. Not necessary, first = adopted and then improved. In other words, I do not think that the = current document is matured enough for calling the adoption. > Do you think there are issues in the current use cases that should be = removed? As stated in the abstract, the use-cases document is intended to be a = guideline for developing a comprehensive authentication and access = control approach while deriving security requirements. However, what I = concern from the current document is possibilities of lacking of = deriving security requirements from the limited use-cases in the = document.=20 In addition, I would like to see the document=92s improvement in its = organisation and structure. For instance, it must help if the document = contains a table showing comparisons of the use-cases listed in the = document in terms of environment (network, protocol, etc) and security = requirement. J.=20 >=20 > Sandeep >=20 > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Jong-Hyouk Lee > Sent: Tuesday, August 26, 2014 9:12 AM > To: Anthony Nadalin > Cc: Hannes Tschofenig; Ace@ietf.org > Subject: Re: [Ace] ACE Use Case document >=20 > Hi all >=20 > As like Anthony, I think that the use-cases document should be broader = than the current one. The working group should try to get some more = inputs from folks before trying to fire the call for adoption. >=20 > J. > -- > Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random = Protocol Engineering Lab., Sangmyung University >=20 > #email: jonghyouk@gmail.com > #webpage: https://sites.google.com/site/hurryon >=20 > On Aug 26, 2014, at 12:12 PM, Anthony Nadalin = wrote: >=20 >> My major issues and comments with the document is that it does not = cover a lot of the use case that we see in the marketplace, the use case = document can be broader than the scope of the WG (even though I don't = see much in the charter that limits the scope). >>=20 >> -----Original Message----- >> From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes = Tschofenig >> Sent: Thursday, August 21, 2014 6:41 AM >> To: Ace@ietf.org >> Subject: [Ace] ACE Use Case document >>=20 >> Hi all, >>=20 >> we started a call for adoption of draft-seitz-ace-usecases as a = starting point for the use case charter item in July and we were hoping = to get a lot of feedback. >>=20 >> Unfortunately, it turned out that only very few responded, namely = Robert, Michael, Peter, and Rene (whereby Rene voiced concerns). >>=20 >> Of course, you may have been on vacation and therefore unable to = review the draft and to respond. >>=20 >> With the vacation period coming to an end we hope to receive = additional feedback from other working group participants. >>=20 >> Ciao >> Hannes & Kepeng >>=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 > ________________________________ > The information contained in this message may be confidential and = legally protected under applicable law. The message is intended solely = for the addressee(s). If you are not the intended recipient, you are = hereby notified that any use, forwarding, dissemination, or reproduction = of this message is strictly prohibited and may be unlawful. If you are = not the intended recipient, please contact the sender by return e-mail = and destroy all copies of the original message. From nobody Tue Aug 26 08:54:49 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45731A8716 for ; Tue, 26 Aug 2014 08:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnoa4hajeg1O for ; Tue, 26 Aug 2014 08:54:44 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10F161A8742 for ; Tue, 26 Aug 2014 08:54:43 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB310.namprd03.prod.outlook.com (10.141.48.25) with Microsoft SMTP Server (TLS) id 15.0.1019.14; Tue, 26 Aug 2014 15:54:35 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.1019.014; Tue, 26 Aug 2014 15:54:34 +0000 From: Anthony Nadalin To: Ludwig Seitz , "ace@ietf.org" Thread-Topic: [Ace] ACE Use Case document Thread-Index: AQHPvUSoEtZnaNqOW0WosButZ+xxG5vhsYVQgADLQwCAAJSz8A== Date: Tue, 26 Aug 2014 15:54:34 +0000 Message-ID: References: <53F5F6F0.4000202@gmx.net> <53FC30F4.6000205@sics.se> In-Reply-To: <53FC30F4.6000205@sics.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2001:4898:80e8:ee31::3] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03152A99FF x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(13464003)(199003)(189002)(377454003)(24454002)(479174003)(19580405001)(19580395003)(21056001)(87936001)(99396002)(101416001)(81342001)(83322001)(76176999)(83072002)(85852003)(15975445006)(76576001)(74316001)(81542001)(106356001)(86362001)(33646002)(92566001)(105586002)(16601075003)(80022001)(106116001)(64706001)(20776003)(99286002)(74662001)(95666004)(108616004)(31966008)(74502001)(90102001)(107886001)(2656002)(77982001)(15202345003)(54356999)(86612001)(4396001)(85306004)(76482001)(107046002)(50986999)(79102001)(46102001)(2501001)(24736002)(3826002)(42262002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB310; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_fea9927bb3db4bc8abb5ba0843a53a3fBLUPR03MB309namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/ace/nfdpz0EdtHbKZ4FrPnK7MeQuX_M Subject: Re: [Ace] ACE Use Case document X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 15:54:47 -0000 --_000_fea9927bb3db4bc8abb5ba0843a53a3fBLUPR03MB309namprd03pro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have made comments on the missing use cases 1) High-end devices (I'm defining high-end as capable of TLS). Scenar= io is : the device, like an industrial pump, presents an identity proof to = a gateway service, the service verifies the proof and authenticates the dev= ice. Once authenticated, the device can upload telemetry information, query= for information, receive notifications and/or receive commands. We can a= ccomplish this today with the OAuth 2.0 assertion profile, with client acti= ng as itself, sending a signed assertion to the gateway. The key is pre-pro= visioned on the device at the manufacture. a. The first scenario is to improve on the above. Specific areas of im= provement i. Lighter weight protocol, reduced amount of bytes sent on the wire, = and reduced cpu cycles on the device. ii. Address mid-range devices (that have TCP/IP stack but no TLS built = in). One candidate that is being looked at is TKS PKS, to allow a shared sy= mmetric key to be used to enable transport level security. 2) Secret provisioning is another important problem to solve. Scenario= is : I bring home my new thermostat and want to associate it with my accou= nt, how is it paired? Later when I sell my house, how to I transfer ownersh= ip of the thermostat? The most common pattern seems to be having the user g= et a code from the device, enter it in a pc, than acknowledge the pairing f= rom the device. There are similar patterns for mid-range devices without di= splays (like https://www.spark.io/), they have a photo resistor, that liter= ally let a phone app flash a code to the device to complete the pairing. Pr= ovisioning protocol, should allow for various ways to communicate keys. Some Interesting consumer scenarios might be: 1) When I install a new light bulb, how does my wife get access to con= trol it from her phone? This should be seamless, since there can't be an on= boarding experience for everything I bring into the home. 2) If somebody sides a malicious "puck" device under my door, what kee= ps it from joining the other things in the home and attacking the house. 3) If I have guests and I want to give control of some parts of my hom= e, how is that done? Use of proximity is one interesting idea I've heard he= re, if you are in my house you can turn lights on and off. -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Ludwig Seitz Sent: Tuesday, August 26, 2014 12:02 AM To: ace@ietf.org Subject: Re: [Ace] ACE Use Case document On 08/26/2014 05:12 AM, Anthony Nadalin wrote: > My major issues and comments with the document is that it does not > cover a lot of the use case that we see in the marketplace, the use case = document can be broader than the scope of the WG (even though I don't see m= uch in the charter that limits the scope). If you want to contribute more use cases that are relevant, you are most we= lcome. Do you think the use cases in the current document are relevant? Are there aspects of these use cases that you feel are missing in the docum= ent? Regards, Ludwig -- Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --_000_fea9927bb3db4bc8abb5ba0843a53a3fBLUPR03MB309namprd03pro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have made comments on the missing use cases
 
  1. High-end devices (I’m defining high-end as capable of TLS). = Scenario is : the device, like an industrial pump, presents an identity pr= oof to a gateway service, the service verifies the proof and authenticates = the device. Once authenticated, the device can upload telemetry information, query for information, receive notificati= ons and/or receive commands.  We  can accomplish this today with = the OAuth 2.0 assertion profile, with client acting as itself, sending a si= gned assertion to the gateway. The key is pre-provisioned on the device at the manufacture.
    2.
  1. The first scenario is to improve on the above. Specific areas of improv= ement
    2.
  1. Lighter weight protocol, reduced amount of bytes sent on the wire, and = reduced cpu cycles on the device.
  2. Address mid-range devices (that h= ave TCP/IP stack but no TLS built in). One candidate that is being looked a= t is TKS PKS, to allow a shared symmetric key to be used to enable transpor= t level security.
    3.
  1. Secret provisioning is another important problem to solve. Scenario is = : I bring home my new thermostat and want to associate it with my account, = how is it paired? Later when I sell my house, how to I transfer ownership o= f the thermostat? The most common pattern seems to be having the user get a code from the device, enter it in= a pc, than acknowledge the pairing from the device. There are similar patt= erns for mid-range devices without displays (like https://www.spark.io/), they have a photo resistor, that literally let a phone app flash a code to = the device to complete the pairing. Provisioning protocol, should allow for= various ways to communicate keys.
    2.
 
Some Interesting consumer scenarios might be:<= /font>
  1. When I install a new light bulb, how does my wife get access to control= it from her phone? This should be seamless, since there can’t be an = onboarding experience for everything I bring into the home.
  2. If some= body sides a malicious “puck” device under my door, what keeps = it from joining the other things in the home and attacking the house.
    3. <= li>If I have guests and I want to give control of some parts of my home, ho= w is that done? Use of proximity is one interesting idea I’ve heard h= ere, if you are in my house you can turn lights on and off.
 
 
 
-----Original Message-----
From: Ace [mailto:ace-bounces@ietf.= org] On Behalf Of Ludwig Seitz
Sent: Tuesday, August 26, 2014 12:02 AM
To: ace@ietf.org
Subject: Re: [Ace] ACE Use Case document
 
On 08/26/2014 05:12 AM, Anthony Nadalin wrote:
> My major issues and comments with the document is that it does no= t
> cover a lot of the use case that we see in the marketplace, the u= se case document can be broader than the scope of the WG (even though I don= 't see much in the charter that limits the scope).
 
If you want to contribute more use cases that are relevant, you are mo= st welcome.
 
Do you think the use cases in the  current document are relevant?=
Are there aspects of these use cases that you feel are missing in the = document?
 
Regards,
 
Ludwig
 
--
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelev=E4gen 17
SE-223 70 Lund
 
Phone +46(0)70-349 92 51
 
 
 --_000_fea9927bb3db4bc8abb5ba0843a53a3fBLUPR03MB309namprd03pro_-- From nobody Tue Aug 26 08:57:52 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9A61A8760 for ; Tue, 26 Aug 2014 08:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDnHHg6MxkDh for ; Tue, 26 Aug 2014 08:57:47 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DA6C1A8747 for ; Tue, 26 Aug 2014 08:57:46 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) with Microsoft SMTP Server (TLS) id 15.0.1019.14; Tue, 26 Aug 2014 15:57:45 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.1019.014; Tue, 26 Aug 2014 15:57:45 +0000 From: Anthony Nadalin To: "Kumar, Sandeep" , Jong-Hyouk Lee Thread-Topic: [Ace] ACE Use Case document Thread-Index: AQHPvUSoEtZnaNqOW0WosButZ+xxG5vhsYVQgADOCQCAAAcigIAAivQg Date: Tue, 26 Aug 2014 15:57:44 +0000 Message-ID: <487b656532104c71ac1a39d4b936516f@BLUPR03MB309.namprd03.prod.outlook.com> References: <53F5F6F0.4000202@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2001:4898:80e8:ee31::3] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03152A99FF x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(85714005)(51704005)(374574003)(13464003)(377454003)(53754006)(199003)(24454002)(189002)(51444003)(64706001)(87936001)(108616004)(4396001)(76482001)(93886004)(20776003)(86612001)(83072002)(76576001)(77982001)(101416001)(33646002)(81342001)(85306004)(74316001)(85852003)(92566001)(90102001)(80022001)(79102001)(21056001)(95666004)(99396002)(99286002)(50986999)(105586002)(107046002)(19580405001)(19580395003)(83322001)(106116001)(325944007)(81542001)(31966008)(106356001)(86362001)(74502001)(15975445006)(54356999)(2656002)(46102001)(74662001)(76176999)(567094001)(3826002)(24736002)(42262002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB309; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/ace/voa7j3-YTPqTrJUtgvZDj6SGVa8 Cc: Hannes Tschofenig , "Ace@ietf.org" Subject: Re: [Ace] ACE Use Case document X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 15:57:50 -0000 Agree its call for adoption and it's not a final draft but before we adopt = some of us would like to know the direction of this document the ability to= add/supplement the use cases -----Original Message----- From: Kumar, Sandeep [mailto:sandeep.kumar@philips.com]=20 Sent: Tuesday, August 26, 2014 12:38 AM To: Jong-Hyouk Lee; Anthony Nadalin Cc: Hannes Tschofenig; Ace@ietf.org Subject: RE: [Ace] ACE Use Case document The call for adoption is only to make this a WG document so that folks can = contribute to a single document. The document can only get broader with con= sensus if it is a WG document. Do you think there are issues in the current= use cases that should be removed? Sandeep -----Original Message----- From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Jong-Hyouk Lee Sent: Tuesday, August 26, 2014 9:12 AM To: Anthony Nadalin Cc: Hannes Tschofenig; Ace@ietf.org Subject: Re: [Ace] ACE Use Case document Hi all As like Anthony, I think that the use-cases document should be broader than= the current one. The working group should try to get some more inputs from= folks before trying to fire the call for adoption. J. -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol= Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon On Aug 26, 2014, at 12:12 PM, Anthony Nadalin wrote= : > My major issues and comments with the document is that it does not cover = a lot of the use case that we see in the marketplace, the use case document= can be broader than the scope of the WG (even though I don't see much in t= he charter that limits the scope). > > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig > Sent: Thursday, August 21, 2014 6:41 AM > To: Ace@ietf.org > Subject: [Ace] ACE Use Case document > > Hi all, > > we started a call for adoption of draft-seitz-ace-usecases as a starting = point for the use case charter item in July and we were hoping to get a lot= of feedback. > > Unfortunately, it turned out that only very few responded, namely Robert,= Michael, Peter, and Rene (whereby Rene voiced concerns). > > Of course, you may have been on vacation and therefore unable to review t= he draft and to respond. > > With the vacation period coming to an end we hope to receive additional f= eedback from other working group participants. > > Ciao > Hannes & Kepeng > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From nobody Tue Aug 26 23:53:59 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097C51A0428 for ; Tue, 26 Aug 2014 23:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5u97jcrXrJXz for ; Tue, 26 Aug 2014 23:53:55 -0700 (PDT) Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id CE0161A0430 for ; Tue, 26 Aug 2014 23:53:54 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by outbox.sics.se (Postfix) with ESMTPS id 5823A863 for ; Wed, 27 Aug 2014 08:53:52 +0200 (CEST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s7R6rpeq019997 for ; Wed, 27 Aug 2014 08:53:52 +0200 Received: from [192.168.0.108] (unknown [85.235.11.178]) (Authenticated sender: ludwig@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 43E7440118 for ; Wed, 27 Aug 2014 08:53:52 +0200 (CEST) Message-ID: <53FD807E.5080609@sics.se> Date: Wed, 27 Aug 2014 08:53:50 +0200 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: ace@ietf.org References: <53F5F6F0.4000202@gmx.net> <487b656532104c71ac1a39d4b936516f@BLUPR03MB309.namprd03.prod.outlook.com> In-Reply-To: <487b656532104c71ac1a39d4b936516f@BLUPR03MB309.namprd03.prod.outlook.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030309050803020705030907" X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sics-se:default, sics-se:default, base:default, @@RPTN) X-p0f-Info: os=Solaris 10, link=Ethernet or modem X-CanIt-Geo: =?UTF-8?Q?ip=3D85.235.11.178; _country=3DSE; _region=3DSk=C3=A5ne; _city=3DLund; _latitude=3D55.7000; _longitude=3D13.1833; _http://maps.google.com/maps=3Fq=3D55.7000,13.1833&z=3D6?= X-CanItPRO-Stream: outbound-sics-se:outbound (inherits from outbound-sics-se:default, sics-se:default, base:default) X-Canit-Stats-ID: 09MHGRQTi - 1fa47fd18a2e - 20140827 X-Antispam-Training-Forget: https://canit.sunet.se/canit/b.php?i=09MHGRQTi&m=1fa47fd18a2e&t=20140827&c=f X-Antispam-Training-Nonspam: https://canit.sunet.se/canit/b.php?i=09MHGRQTi&m=1fa47fd18a2e&t=20140827&c=n X-Antispam-Training-Spam: https://canit.sunet.se/canit/b.php?i=09MHGRQTi&m=1fa47fd18a2e&t=20140827&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/4ge4XHHLArcfRaIiNCg51McQkuE Subject: Re: [Ace] ACE Use Case document X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 06:53:58 -0000 This is a cryptographically signed message in MIME format. --------------ms030309050803020705030907 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 08/26/2014 05:57 PM, Anthony Nadalin wrote: > Agree its call for adoption and it's not a final draft but before we ad= opt some of us would like to know the direction of this document the abil= ity to add/supplement the use cases > When a draft is adopted, the direction of the document is entirely up to = the WG. Right now we, the authors, can do what we want with the=20 document, so I'd say by adopting it you would gain more control about=20 the contents. /Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms030309050803020705030907 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwiRTjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE0MDEwNzA3MjgzNVoXDTE1MDEwNzEyNTgyMlowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnLm1tc30QxHa9wtdVjC3NgxjLJicnccm0HD+ 1X16kPMKGvwps8F1oDhYn7jXIe46p1AuJMzLK0GIioE4JwxCFGdvpz7cg2xyTyrdBVUzSqez Dfqt4FOJq6hrdrIMS8MHEzl7Jk02gv9cTn/pHQvDpkiThRpbSLU5mlMqtEQ8gDQY5YyBX0Mv 5qculV08I2JU8HEeTt1oeqhvBImgQfOVYMDatHlWHUVVrmYd6iIo+cuiUGd5kiA0XuaLYX0E oCoao/z5Wg9U0sQlx0hl4r96Q+NdoZZ1prfts3qtyBzJ2hu135aikigzJ6sueWHv/jbISUek tOMm0xkx1GOqqWtEAwIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRZmjjBh8N3klra+mVQgC00 pl68ZTAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQELBQADggEBAHqEYmtWr83S+iLXE97KBnHJZiMr6PMuLKxmh0o6UJJwKgf+KTP2czxRnPSI +whuqfQZdmz6g3A2K8AooMU0RXrzncnX1c4826APdnXkRxnGQxtZXI1wuhPn4z7iDKZ6ij9u K5Pfn10JL/ERDig2qJQbqvhtIAx0RY7y7r+hLMvgXVq9mf3WRJYmGQeFW+N9t5Z1eEwG4m9R KAZm0fnfeDn/Ai4kmxTckBH7dZwW2lTtwQqQ4su+PGCJ0e9ndBLpvTqaYGSAl+L7PO7vxPhS /cS67Xa6BtnYJLTr3MaGXaN+CEUFSfwQHa9DKcAqh3kldErI3kCvnot0CigBl4aILOEwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwiRTjAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA4MjcwNjUzNTBaMCMGCSqGSIb3DQEJBDEW BBT3PKVC/k5fluSwGlBkTXp2OP5yCDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCJFOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMIkU4wDQYJKoZIhvcNAQEBBQAE ggEAIW+w2LgBK77Fo5tnxULoJorft6dT874hB+L/5Vx1iON2PyPpUghNDK0c9ipkyS3VJoc1 1co480pxp6X8JoiPwbo+KL0GjMO5wL4t3xZwavz3xPmPwVkDBBrbMIm6pKBnvr3wnYBMlzE9 2lKsQ+L6o6JT4daLF65WtqoWwtc80qXDthjt3htJLD1lozAng+DrRQHFvsOkAVfW+f1cfTgy RC8MJCHATEJ33zTHSA6PQaMad+eoe4oyj1u02Zyuagg7vzMa+hU6J24GHU7f/5lUsvjLWgZr rwv2NJTNgn89BJAJJ/s+3k1uul03Kw/8xhmZ5lGLKiBkSv1gJeH9oCRRfwAAAAAAAA== --------------ms030309050803020705030907-- From nobody Wed Aug 27 00:29:10 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7784B1A045F for ; Wed, 27 Aug 2014 00:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogcw0tpHbRIJ for ; Wed, 27 Aug 2014 00:29:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE0271A0457 for ; Wed, 27 Aug 2014 00:29:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLV01708; Wed, 27 Aug 2014 07:29:05 +0000 (GMT) Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Aug 2014 08:29:05 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.57]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Wed, 27 Aug 2014 15:29:00 +0800 From: Bert Greevenbosch To: "Ace@ietf.org" Thread-Topic: [Ace] Call for adoption on draft-seitz-ace-usecases-01 ("ACE Use Cases") Thread-Index: AQHPpPKsQ9dekN8C0kSkuvLqJKYC0pvkQ1ZQ Date: Wed, 27 Aug 2014 07:28:59 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63E6F78DB@SZXEMA510-MBX.china.huawei.com> References: <53CD27D3.1010709@gmx.net> In-Reply-To: <53CD27D3.1010709@gmx.net> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.162.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/cOfwZGPmMK6_ilNw6KrLqL8-Wj8 Subject: Re: [Ace] Call for adoption on draft-seitz-ace-usecases-01 ("ACE Use Cases") X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 07:29:08 -0000 Hi all, I think the use case and requirements document is in good shape. Of course there is still work to be done on it, but this is not a WG last c= all, just a call for adoption. B.t.w., about a year ago, I submitted a use case document myself: tools.ietf.org/html/draft-greevenbosch-core-authreq-00 We may consider whether use-cases 3.1 (authorised and unauthorised devices)= , 3.4 (maintaining and extending a network of sensors and actuators) and 3.= 8 (mixing nodes from different vendors) make sense for adoption in the new = use case document. 3.1 and 3.8 use certification to block sensors from joining the network, ba= sed on their credentials, which in the story are used to determine the type= of sensor or are absent. 3.4 illustrates maintenance, especially replacing a single unit or adding a= group of sensors. Anyway I support WG adoption of draft-seitz-ace-usecases-01. Best regards, Bert > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Hannes Tschofenig > Sent: 21 July 2014 22:47 > To: Ace@ietf.org > Subject: [Ace] Call for adoption on draft-seitz-ace-usecases-01 ("ACE > Use Cases") >=20 > Hi all, >=20 > we have a milestone for a use case document in ACe and draft-seitz-ace- > usecases is a promising candidate for this milestone. >=20 > This email is a call for adoption for draft-seitz-ace-usecases-01. >=20 > Please respond if you support, or object to, the adoption of this > document as the basis for this work item. Deadline for your response: > 31. July 2014 >=20 > Ciao > Hannes & Kepeng From nobody Wed Aug 27 00:40:11 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F6A1A046A for ; Wed, 27 Aug 2014 00:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.918 X-Spam-Level: X-Spam-Status: No, score=-2.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKqGRfsVUwUT for ; Wed, 27 Aug 2014 00:40:08 -0700 (PDT) Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id 06F481A045C for ; Wed, 27 Aug 2014 00:40:08 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by outbox.sics.se (Postfix) with ESMTPS id 23F4E6BD; Wed, 27 Aug 2014 09:40:07 +0200 (CEST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s7R7e601011676; Wed, 27 Aug 2014 09:40:06 +0200 Received: from [192.168.0.108] (unknown [85.235.11.178]) (Authenticated sender: ludwig@sics.se) by letter.sics.se (Postfix) with ESMTPSA id E494C40116; Wed, 27 Aug 2014 09:40:06 +0200 (CEST) Message-ID: <53FD8B55.9010203@sics.se> Date: Wed, 27 Aug 2014 09:40:05 +0200 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Anthony Nadalin , "ace@ietf.org" References: <53F5F6F0.4000202@gmx.net> <53FC30F4.6000205@sics.se> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090609030707070508060109" X-Bayes-Prob: 0.005 (Score 0, tokens from: outbound, outbound-sics-se:default, sics-se:default, base:default, @@RPTN) X-p0f-Info: os=Solaris 10, link=Ethernet or modem X-CanIt-Geo: =?UTF-8?Q?ip=3D85.235.11.178; _country=3DSE; _region=3DSk=C3=A5ne; _city=3DLund; _latitude=3D55.7000; _longitude=3D13.1833; _http://maps.google.com/maps=3Fq=3D55.7000,13.1833&z=3D6?= X-CanItPRO-Stream: outbound-sics-se:outbound (inherits from outbound-sics-se:default, sics-se:default, base:default) X-Canit-Stats-ID: 09MHHE6yT - c00205f5b005 - 20140827 X-Antispam-Training-Forget: https://canit.sunet.se/canit/b.php?i=09MHHE6yT&m=c00205f5b005&t=20140827&c=f X-Antispam-Training-Nonspam: https://canit.sunet.se/canit/b.php?i=09MHHE6yT&m=c00205f5b005&t=20140827&c=n X-Antispam-Training-Spam: https://canit.sunet.se/canit/b.php?i=09MHHE6yT&m=c00205f5b005&t=20140827&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/VDzgfk8MsicvffJIrkYBIi6NhGA Subject: Re: [Ace] ACE Use Case document X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 07:40:10 -0000 This is a cryptographically signed message in MIME format. --------------ms090609030707070508060109 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 08/26/2014 05:54 PM, Anthony Nadalin wrote: > I have made comments on the missing use cases > > 1. High-end devices (I=92m defining high-end as capable of TLS). > Scenario is : the device, like an industrial pump, presents an > identity proof to a gateway service, the service verifies the proof= > and authenticates the device. Once authenticated, the device can > upload telemetry information, query for information, receive > notifications and/or receive commands. We can accomplish this > today with the OAuth 2.0 assertion profile, with client acting as > itself, sending a signed assertion to the gateway. The key is > pre-provisioned on the device at the manufacture. > > 1. The first scenario is to improve on the above. Specific areas of > improvement > > 1. Lighter weight protocol, reduced amount of bytes sent on the wire, > and reduced cpu cycles on the device. > 2. Address mid-range devices (that have TCP/IP stack but no TLS built > in). One candidate that is being looked at is TKS PKS, to allow a > shared symmetric key to be used to enable transport level security.= > Ok, let me try to separate the solutions bits here from what I consider=20 to be a use case: You have a high-end device that is part of an industrial control system. The system is using an internal network that is separated from the=20 Internet and communicates outside this network through a gateway that=20 performs authentication (and supposedly authorization). The problems=20 that need to be solved here are: - how to keep unauthorized parties outside of the internal network - how to allow authorized parties to access devices inside the internal=20 network - how to keep the resource consumption of the protocols solving the=20 problems above to a minimum Does that roughly represent what you meant? I'd gladly flesh that out into a full ICS use case with your help, but=20 I'd like to keep solution related details out of the use case draft, in=20 order to avoid biasing this document towards a specific solution. > 2. Secret provisioning is another important problem to solve. Scenario= > is : I bring home my new thermostat and want to associate it with m= y > account, how is it paired? Later when I sell my house, how to I > transfer ownership of the thermostat? The most common pattern seems= > to be having the user get a code from the device, enter it in a pc,= > than acknowledge the pairing from the device. There are similar > patterns for mid-range devices without displays (like > _https://www.spark.io/_), they have a photo resistor, that literall= y > let a phone app flash a code to the device to complete the pairing.= > Provisioning protocol, should allow for various ways to communicate= > keys. > > Some Interesting consumer scenarios might be: > > 1. When I install a new light bulb, how does my wife get access to > control it from her phone? This should be seamless, since there > can=92t be an onboarding experience for everything I bring into the= home. > 2. If somebody sides a malicious =93puck=94 device under my door, what= > keeps it from joining the other things in the home and attacking th= e > house. > 3. If I have guests and I want to give control of some parts of my > home, how is that done? Use of proximity is one interesting idea > I=92ve heard here, if you are in my house you can turn lights on an= d off. To cover this we could extend the home automation use case. Would you=20 like to propose an extension to that section of the draft? /Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms090609030707070508060109 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwiRTjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE0MDEwNzA3MjgzNVoXDTE1MDEwNzEyNTgyMlowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnLm1tc30QxHa9wtdVjC3NgxjLJicnccm0HD+ 1X16kPMKGvwps8F1oDhYn7jXIe46p1AuJMzLK0GIioE4JwxCFGdvpz7cg2xyTyrdBVUzSqez Dfqt4FOJq6hrdrIMS8MHEzl7Jk02gv9cTn/pHQvDpkiThRpbSLU5mlMqtEQ8gDQY5YyBX0Mv 5qculV08I2JU8HEeTt1oeqhvBImgQfOVYMDatHlWHUVVrmYd6iIo+cuiUGd5kiA0XuaLYX0E oCoao/z5Wg9U0sQlx0hl4r96Q+NdoZZ1prfts3qtyBzJ2hu135aikigzJ6sueWHv/jbISUek tOMm0xkx1GOqqWtEAwIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRZmjjBh8N3klra+mVQgC00 pl68ZTAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQELBQADggEBAHqEYmtWr83S+iLXE97KBnHJZiMr6PMuLKxmh0o6UJJwKgf+KTP2czxRnPSI +whuqfQZdmz6g3A2K8AooMU0RXrzncnX1c4826APdnXkRxnGQxtZXI1wuhPn4z7iDKZ6ij9u K5Pfn10JL/ERDig2qJQbqvhtIAx0RY7y7r+hLMvgXVq9mf3WRJYmGQeFW+N9t5Z1eEwG4m9R KAZm0fnfeDn/Ai4kmxTckBH7dZwW2lTtwQqQ4su+PGCJ0e9ndBLpvTqaYGSAl+L7PO7vxPhS /cS67Xa6BtnYJLTr3MaGXaN+CEUFSfwQHa9DKcAqh3kldErI3kCvnot0CigBl4aILOEwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwiRTjAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA4MjcwNzQwMDVaMCMGCSqGSIb3DQEJBDEW BBQrsZju7F8XVUVQuvbIxzrJryAWijBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCJFOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMIkU4wDQYJKoZIhvcNAQEBBQAE ggEAZux9eblDoSvoPo9KDXKltOLbcUtuElZNJLteF32L1Xs9rNJg42ukRLtpb9Z7/aEKBNhT cWpv2CMlVZ12lyD3h2ayYDaGjtBGho51GRk0gxMGgB3E+BKaSb2HPLyzEFa9djA1dU2SeqNC caKWP9wSrNos8wkHpvCMmbRDdsa2G11+D7aHF+pXAx5dXERlf63wXS6z83VYmPtc0Rfpg8l8 5ZTXA8CIIFjn9mvciG/Ql6/HXj+npS/8ZBmNuQczHc8ra+3qyU9J68+oI4/tGgLRRuyy85oV fz7nfqsWhMx9aM147ELYdINamsWoD71qavg44u+qnYPWaIQzlly1b0+VTQAAAAAAAA== --------------ms090609030707070508060109-- From nobody Wed Aug 27 05:26:12 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF2521A066D for ; Wed, 27 Aug 2014 05:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3k_pfBwhad53 for ; Wed, 27 Aug 2014 05:26:03 -0700 (PDT) Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0881A066C for ; Wed, 27 Aug 2014 05:26:03 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by outbox.sics.se (Postfix) with ESMTPS id A8E4A6BD for ; Wed, 27 Aug 2014 14:26:02 +0200 (CEST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s7RCQ2Hb017092 for ; Wed, 27 Aug 2014 14:26:02 +0200 Received: from [192.168.0.108] (unknown [85.235.11.178]) (Authenticated sender: ludwig@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 59D5B40116 for ; Wed, 27 Aug 2014 14:26:02 +0200 (CEST) Message-ID: <53FDCE58.7010807@sics.se> Date: Wed, 27 Aug 2014 14:26:00 +0200 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: ace@ietf.org References: <53F5F6F0.4000202@gmx.net> <5C0C065C-2F78-4FF8-ACBC-F359D33C266F@gmail.com> In-Reply-To: <5C0C065C-2F78-4FF8-ACBC-F359D33C266F@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050007050104070902070106" X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sics-se:default, sics-se:default, base:default, @@RPTN) X-p0f-Info: os=Solaris 10, link=Ethernet or modem X-CanIt-Geo: =?UTF-8?Q?ip=3D85.235.11.178; _country=3DSE; _region=3DSk=C3=A5ne; _city=3DLund; _latitude=3D55.7000; _longitude=3D13.1833; _http://maps.google.com/maps=3Fq=3D55.7000,13.1833&z=3D6?= X-CanItPRO-Stream: outbound-sics-se:outbound (inherits from outbound-sics-se:default, sics-se:default, base:default) X-Canit-Stats-ID: 09MHMq2Ll - 1447f5925c47 - 20140827 X-Antispam-Training-Forget: https://canit.sunet.se/canit/b.php?i=09MHMq2Ll&m=1447f5925c47&t=20140827&c=f X-Antispam-Training-Nonspam: https://canit.sunet.se/canit/b.php?i=09MHMq2Ll&m=1447f5925c47&t=20140827&c=n X-Antispam-Training-Spam: https://canit.sunet.se/canit/b.php?i=09MHMq2Ll&m=1447f5925c47&t=20140827&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/gT_6yfH50mDlKhqMgRUHA4s9bco Subject: Re: [Ace] ACE Use Case document X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 12:26:06 -0000 This is a cryptographically signed message in MIME format. --------------ms050007050104070902070106 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 08/26/2014 11:06 AM, Jong-Hyouk Lee wrote: > > -- > Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random > Protocol Engineering Lab., Sangmyung University > > #email: jonghyouk@gmail.com > #webpage: https://sites.google.com/site/hurryon > > On Aug 26, 2014, at 4:37 PM, Kumar, Sandeep = wrote: > >> The call for adoption is only to make this a WG document so that folks= can contribute to a single document. The document can only get broader w= ith consensus if it is a WG document. > > I do not think so. When an individual document has enough supports for = adoption, the document can be a WG document. Not necessary, first adopted= and then improved. > In other words,I do not think that the current document is matured=20 enough for calling the adoption. Could you elaborate on this perceived lack of maturity? The document has = been around for some time and has been discussed in several IETF=20 meetings (IETF 88-90). > >> Do you think there are issues in the current use cases that should be = removed? > > As stated in the abstract, the use-cases document is intended to be a g= uideline for developing a comprehensive authentication and access control= approach > while deriving security requirements. However, what I concern from the = current document is possibilities of lacking of deriving security require= ments from the limited use-cases in the document. I agree with your point that the documents needs a broader set of use=20 cases. I think that if the document was adopted, it would be easier to=20 get more people to contribute their use cases. Currently it is a private = submission, and I suspect people might be weary to invest time in a=20 document with such an uncertain future. > > In addition, I would like to see the document=92s improvement in its or= ganisation and structure. For instance, it must help if the document cont= ains a table showing comparisons of the use-cases > listed in the document in terms of environment (network, protocol, etc)= and security requirement. There is a list of aggregated security requirements in section 3 for=20 what it's worth. Fitting that into a table would be difficult and=20 probably not very helpful. As for the network and protocols, since ACE is spawned off CoRE, the=20 underlying assumption is that we concentrate on a protocol stack roughly = like this (*=3Doptional) at start: CoAP - DTLS* - IPv6 - 6LoWPAN - IEEE 802.15.4 This doesn't preclude the usefulness of our solutions for other protocol = stacks, but as a baseline it seems useful to me. I have however tried to = keep such details out of the use case document, and I'd like to hear a=20 good argument on why this would be useful, before I start making such=20 distinctions in the use cases. /Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms050007050104070902070106 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwiRTjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE0MDEwNzA3MjgzNVoXDTE1MDEwNzEyNTgyMlowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnLm1tc30QxHa9wtdVjC3NgxjLJicnccm0HD+ 1X16kPMKGvwps8F1oDhYn7jXIe46p1AuJMzLK0GIioE4JwxCFGdvpz7cg2xyTyrdBVUzSqez Dfqt4FOJq6hrdrIMS8MHEzl7Jk02gv9cTn/pHQvDpkiThRpbSLU5mlMqtEQ8gDQY5YyBX0Mv 5qculV08I2JU8HEeTt1oeqhvBImgQfOVYMDatHlWHUVVrmYd6iIo+cuiUGd5kiA0XuaLYX0E oCoao/z5Wg9U0sQlx0hl4r96Q+NdoZZ1prfts3qtyBzJ2hu135aikigzJ6sueWHv/jbISUek tOMm0xkx1GOqqWtEAwIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRZmjjBh8N3klra+mVQgC00 pl68ZTAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQELBQADggEBAHqEYmtWr83S+iLXE97KBnHJZiMr6PMuLKxmh0o6UJJwKgf+KTP2czxRnPSI +whuqfQZdmz6g3A2K8AooMU0RXrzncnX1c4826APdnXkRxnGQxtZXI1wuhPn4z7iDKZ6ij9u K5Pfn10JL/ERDig2qJQbqvhtIAx0RY7y7r+hLMvgXVq9mf3WRJYmGQeFW+N9t5Z1eEwG4m9R KAZm0fnfeDn/Ai4kmxTckBH7dZwW2lTtwQqQ4su+PGCJ0e9ndBLpvTqaYGSAl+L7PO7vxPhS /cS67Xa6BtnYJLTr3MaGXaN+CEUFSfwQHa9DKcAqh3kldErI3kCvnot0CigBl4aILOEwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwiRTjAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA4MjcxMjI2MDBaMCMGCSqGSIb3DQEJBDEW BBTUAZZE+aSIJ45IQgzrdKkdJ3a9vDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCJFOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMIkU4wDQYJKoZIhvcNAQEBBQAE ggEAl6RTaJ0lq6PcW6Zt2qTHj63+aHXz5t5gawuc9cky3fVDi5UEE23v+7ymLovOWQf93cJg 3sC1oGNK5LZ6PGcl2IR18D5xuvAim7jzRZYx2JlVgJv3ZfcQYGjCiK8mfFaFa0Tgj42coJqt doaq89HhSm629C0W9qBYlmy7aL7GTvhJKMQL0iW93NtZ8+Ki+NMDx4LoS5xH+4njv6jxZQmK 2tYWyvn+Mxq2jDgGqPjecrjvno1XVa7SEQ007MkML3NsT8xQjFSoz1mounmQmFBwTzd00rki smoFK+uQTd6b78yn33w2JKB4C/mQlp60mLzUXn0B7bhMob64nrl6D6Jn4AAAAAAAAA== --------------ms050007050104070902070106-- From nobody Wed Aug 27 09:01:25 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02451A0B71 for ; Wed, 27 Aug 2014 09:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNoWmoj9OCGD for ; Wed, 27 Aug 2014 09:01:14 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07B2D1A0B0C for ; Wed, 27 Aug 2014 09:01:13 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id C73AB3B42F7; Wed, 27 Aug 2014 18:01:11 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id A4EE415804E; Wed, 27 Aug 2014 18:01:11 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Wed, 27 Aug 2014 18:01:11 +0200 From: To: Hannes Tschofenig , "Ace@ietf.org" Thread-Topic: [Ace] ACE Use Case document Thread-Index: AQHPvUSpiX2AIZcPh0qLV3s6vDSz6ZvkpCIA Date: Wed, 27 Aug 2014 16:01:10 +0000 Message-ID: <8728_1409155271_53FE00C7_8728_13244_1_8F1D83ADCC1AC94186A867BEE9B7D91306E51F54@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <53F5F6F0.4000202@gmx.net> In-Reply-To: <53F5F6F0.4000202@gmx.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.8.27.143921 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/Y-57U69MTc_H_YhJ_cPFjmz0sE8 Subject: Re: [Ace] ACE Use Case document X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 16:01:23 -0000 SGVsbG8gYWxsLA0KDQpJJ3ZlIHJlYWQgdGhlIGRyYWZ0LCBhbmQgbm90YWJseSBTZWN0aW9uIDIu NSB3aXRoIHBhcnRpY3VsYXIgaW50ZXJlc3QuDQpBbHRob3VnaCBJIHdvdWxkIGRpc2N1c3Mgc29t ZSBvZiB0aGUgcmF0aW9uYWxlcyBwcmVzZW50ZWQgaW4gc2VjdGlvbnMgMi41LjEgYW5kIDIuNS4y LCB0aGV5IGRvIG5vdCBpbXBhY3QgdGhlIHJlcXVpcmVtZW50cyBpbiAyLjUuNC4sIHdoaWNoIEkg YWdyZWUgd2l0aC4NClNlY3Rpb24gMyBhbHNvIHNlZW1zIGdvb2QgdG8gbWUuDQpJIHRoZXJlZm9y ZSByZWNvbW1lbmQgYWRvcHRpbmcgdGhlIGRyYWZ0IGFzIGEgV0cgZG9jdW1lbnQgc28gdGhhdCBm dXJ0aGVyIGVmZm9ydHMgY2FuIGJlIGZ1bm5lbGVkIGludG8gbWFraW5nIGl0IGV2ZW4gYmV0dGVy Lg0KQmVzdCwNCg0KRG9taW5pcXVlDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXC oDogQWNlIFttYWlsdG86YWNlLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSGFubmVz IFRzY2hvZmVuaWcNCkVudm95w6nCoDogamV1ZGkgMjEgYW/Du3QgMjAxNCAxNTo0MQ0Kw4DCoDog QWNlQGlldGYub3JnDQpPYmpldMKgOiBbQWNlXSBBQ0UgVXNlIENhc2UgZG9jdW1lbnQNCg0KSGkg YWxsLA0KDQp3ZSBzdGFydGVkIGEgY2FsbCBmb3IgYWRvcHRpb24gb2YgZHJhZnQtc2VpdHotYWNl LXVzZWNhc2VzIGFzIGEgc3RhcnRpbmcgcG9pbnQgZm9yIHRoZSB1c2UgY2FzZSBjaGFydGVyIGl0 ZW0gaW4gSnVseSBhbmQgd2Ugd2VyZSBob3BpbmcgdG8gZ2V0IGEgbG90IG9mIGZlZWRiYWNrLg0K DQpVbmZvcnR1bmF0ZWx5LCBpdCB0dXJuZWQgb3V0IHRoYXQgb25seSB2ZXJ5IGZldyByZXNwb25k ZWQsIG5hbWVseSBSb2JlcnQsIE1pY2hhZWwsIFBldGVyLCBhbmQgUmVuZSAod2hlcmVieSBSZW5l IHZvaWNlZCBjb25jZXJucykuDQoNCk9mIGNvdXJzZSwgeW91IG1heSBoYXZlIGJlZW4gb24gdmFj YXRpb24gYW5kIHRoZXJlZm9yZSB1bmFibGUgdG8gcmV2aWV3IHRoZSBkcmFmdCBhbmQgdG8gcmVz cG9uZC4NCg0KV2l0aCB0aGUgdmFjYXRpb24gcGVyaW9kIGNvbWluZyB0byBhbiBlbmQgd2UgaG9w ZSB0byByZWNlaXZlIGFkZGl0aW9uYWwgZmVlZGJhY2sgZnJvbSBvdGhlciB3b3JraW5nIGdyb3Vw IHBhcnRpY2lwYW50cy4NCg0KQ2lhbw0KSGFubmVzICYgS2VwZW5nDQoNCgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBt ZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1h dGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMK cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24u IFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2ln bmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMg am9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQn YWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVz c2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZp bGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91 bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRp b24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz LgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNz YWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5r IHlvdS4KCg== From nobody Wed Aug 27 20:00:37 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BE91A02F1 for ; Wed, 27 Aug 2014 20:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_51=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlDIPgUrwrn4 for ; Wed, 27 Aug 2014 20:00:29 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B351A02EC for ; Wed, 27 Aug 2014 20:00:28 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id ey11so611808pad.35 for ; Wed, 27 Aug 2014 20:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4j5DQOKtaH8Q8wwB0U/jiJw/r6v+NeoZs/t998+/xKc=; b=jMi1pN3mee4iGamuM225YjM8UIqVUIm5f/CeltwUDb4PkxM7Bh45ny4vpqZUNWB9lU Ds4RbC/xuAtvuAiV4MSVYKmvKsakAehFUdSdx2Z50y5DmLEH2t0V79rJshMduHevp9hF C0drtlk5RK2ZAKW4UGf7ufveIzUCePLVwtcgA7xLTzEoV1Wp8L70MA9VyAxKSfKphy+s n2OZRlwdInQj2u/MVrYo6Fn+JyVt5MQkhNPwF7o+c0ZI2eKLwkDlP8ssJFJNZN+etQs2 HjtdZg1KugBcKwFsS2b94aScQLYPpSVnNp48gmKetiVNmE50tiHO4b1PV/j7xHn3xaam kTLQ== X-Received: by 10.66.183.81 with SMTP id ek17mr1429809pac.39.1409194828607; Wed, 27 Aug 2014 20:00:28 -0700 (PDT) Received: from [172.16.1.117] ([1.245.60.4]) by mx.google.com with ESMTPSA id o2sm3068534pde.30.2014.08.27.20.00.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Aug 2014 20:00:27 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jong-Hyouk Lee In-Reply-To: <53FDCE58.7010807@sics.se> Date: Thu, 28 Aug 2014 12:00:23 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53F5F6F0.4000202@gmx.net> <5C0C065C-2F78-4FF8-ACBC-F359D33C266F@gmail.com> <53FDCE58.7010807@sics.se> To: Ludwig Seitz X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/i2o8Fc2iUTi6KU9-5hVxEqCra4c Cc: ace@ietf.org Subject: Re: [Ace] ACE Use Case document X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 03:00:34 -0000 -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon On Aug 27, 2014, at 9:26 PM, Ludwig Seitz wrote: > On 08/26/2014 11:06 AM, Jong-Hyouk Lee wrote: >>=20 >> -- >> Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random >> Protocol Engineering Lab., Sangmyung University >>=20 >> #email: jonghyouk@gmail.com >> #webpage: https://sites.google.com/site/hurryon >>=20 >> On Aug 26, 2014, at 4:37 PM, Kumar, Sandeep = wrote: >>=20 >>> The call for adoption is only to make this a WG document so that = folks can contribute to a single document. The document can only get = broader with consensus if it is a WG document. >>=20 >> I do not think so. When an individual document has enough supports = for adoption, the document can be a WG document. Not necessary, first = adopted and then improved. > > In other words,I do not think that the current document is matured = enough for calling the adoption. >=20 > Could you elaborate on this perceived lack of maturity? The document = has been around for some time and has been discussed in several IETF = meetings (IETF 88-90). You see there are people thinking the current document is immature. The = long live and discussion does not mean the document is mature.=20 >>=20 >>> Do you think there are issues in the current use cases that should = be removed? >>=20 >> As stated in the abstract, the use-cases document is intended to be a = guideline for developing a comprehensive authentication and access = control approach >> while deriving security requirements. However, what I concern from = the current document is possibilities of lacking of deriving security = requirements from the limited use-cases in the document. >=20 > I agree with your point that the documents needs a broader set of use = cases. I think that if the document was adopted, it would be easier to = get more people to contribute their use cases. Currently it is a private = submission, and I suspect people might be weary to invest time in a = document with such an uncertain future. No more, no less. >>=20 >> In addition, I would like to see the document=92s improvement in its = organisation and structure. For instance, it must help if the document = contains a table showing comparisons of the use-cases >> listed in the document in terms of environment (network, protocol, = etc) and security requirement. >=20 > There is a list of aggregated security requirements in section 3 for = what it's worth. Fitting that into a table would be difficult and = probably not very helpful. Must be helpful. Try to include a new section containing such a = comparison table. If needed, you will have inputs from me. >=20 > As for the network and protocols, since ACE is spawned off CoRE, the = underlying assumption is that we concentrate on a protocol stack roughly = like this (*=3Doptional) at start: >=20 > CoAP - DTLS* - IPv6 - 6LoWPAN - IEEE 802.15.4 Could you explicitly write the protocol stack in the document?=20 >=20 > This doesn't preclude the usefulness of our solutions for other = protocol stacks, but as a baseline it seems useful to me. I have however = tried to keep such details out of the use case document, and I'd like to = hear a good argument on why this would be useful, before I start making = such distinctions in the use cases. Do not expect readers would only people in this room. J. >=20 > /Ludwig >=20 > --=20 > Ludwig Seitz, PhD > SICS Swedish ICT AB > Ideon Science Park > Building Beta 2 > Scheelev=E4gen 17 > SE-223 70 Lund >=20 > Phone +46(0)70-349 92 51 > http://www.sics.se >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Thu Aug 28 00:27:15 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C2E1A06A1 for ; Thu, 28 Aug 2014 00:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLl8i9jmMxuY for ; Thu, 28 Aug 2014 00:27:11 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0080.outbound.protection.outlook.com [213.199.154.80]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3D51A06CF for ; Thu, 28 Aug 2014 00:27:11 -0700 (PDT) Received: from DB3PR04CA010.eurprd04.prod.outlook.com (10.242.134.30) by DB3PR04MB0635.eurprd04.prod.outlook.com (25.160.45.149) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Thu, 28 Aug 2014 07:27:08 +0000 Received: from DB3FFO11FD023.protection.gbl (2a01:111:f400:7e04::194) by DB3PR04CA010.outlook.office365.com (2a01:111:e400:9814::30) with Microsoft SMTP Server (TLS) id 15.0.1015.19 via Frontend Transport; Thu, 28 Aug 2014 07:27:08 +0000 Received: from mail.philips.com (206.191.240.52) by DB3FFO11FD023.mail.protection.outlook.com (10.47.217.54) with Microsoft SMTP Server (TLS) id 15.0.1010.11 via Frontend Transport; Thu, 28 Aug 2014 07:27:08 +0000 Received: from DBXPRD9003MB059.MGDPHG.emi.philips.com ([169.254.7.226]) by DBXPRD9003HT002.MGDPHG.emi.philips.com ([141.251.25.207]) with mapi id 14.16.0466.000; Thu, 28 Aug 2014 07:27:08 +0000 From: "Kumar, Sandeep" To: Jong-Hyouk Lee , Ludwig Seitz Thread-Topic: [Ace] ACE Use Case document Thread-Index: AQHPvUSp1/liP+U3d0aCbPEfpgzmOJviPJ6AgABC8ACAAAZkAIAAGa0AgAHJ9gCAAPRNgIAASF8w Date: Thu, 28 Aug 2014 07:27:07 +0000 Message-ID: References: <53F5F6F0.4000202@gmx.net> <5C0C065C-2F78-4FF8-ACBC-F359D33C266F@gmail.com> <53FDCE58.7010807@sics.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:206.191.240.52; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(428002)(374574003)(51704005)(24454002)(189002)(377454003)(199003)(479174003)(101416001)(84676001)(33656002)(20776003)(47776003)(2656002)(50466002)(99396002)(23726002)(4396001)(68736004)(83322001)(69596002)(90102001)(6806004)(46102001)(93886004)(64706001)(106466001)(81156004)(85306004)(104016003)(81342001)(76176999)(44976005)(105586002)(54356999)(50986999)(31966008)(76482001)(106116001)(80022001)(77982001)(92566001)(77096002)(97736001)(66066001)(86362001)(97756001)(81542001)(55846006)(107046002)(21056001)(95666004)(74502001)(87936001)(79102001)(85852003)(83072002)(46406003)(92726001)(567094001); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR04MB0635; H:mail.philips.com; FPR:; MLV:sfv; PTR:ErrorRetry; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 031763BCAF Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is 206.191.240.52) smtp.mailfrom=sandeep.kumar@philips.com; X-OriginatorOrg: philips.com Archived-At: http://mailarchive.ietf.org/arch/msg/ace/MITL0wdmksJr7oIMuK6y40QpKsU Cc: "ace@ietf.org" Subject: Re: [Ace] ACE Use Case document X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 07:27:13 -0000 > > > On 08/26/2014 11:06 AM, Jong-Hyouk Lee wrote: > > > > Could you elaborate on this perceived lack of maturity? The document ha= s > been around for some time and has been discussed in several IETF meetings > (IETF 88-90). > > You see there are people thinking the current document is immature. The > long live and discussion does not mean the document is mature. > To be frank, you not liking this draft because some other people do not lik= e it is unfortunate. However we are here to discuss it based on technical m= erits. ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From nobody Thu Aug 28 01:12:00 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD101A0ACF for ; Thu, 28 Aug 2014 01:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.918 X-Spam-Level: X-Spam-Status: No, score=-2.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sp32uxjgibnn for ; Thu, 28 Aug 2014 01:11:56 -0700 (PDT) Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id A85381A0722 for ; Thu, 28 Aug 2014 01:11:55 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by outbox.sics.se (Postfix) with ESMTPS id 380936BD for ; Thu, 28 Aug 2014 10:11:54 +0200 (CEST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s7S8BrJx022737 for ; Thu, 28 Aug 2014 10:11:54 +0200 Received: from [192.168.0.108] (unknown [85.235.11.178]) (Authenticated sender: ludwig@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 794AB40117 for ; Thu, 28 Aug 2014 10:11:54 +0200 (CEST) Message-ID: <53FEE448.7030204@sics.se> Date: Thu, 28 Aug 2014 10:11:52 +0200 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: ace@ietf.org References: <53F5F6F0.4000202@gmx.net> <8728_1409155271_53FE00C7_8728_13244_1_8F1D83ADCC1AC94186A867BEE9B7D91306E51F54@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <8728_1409155271_53FE00C7_8728_13244_1_8F1D83ADCC1AC94186A867BEE9B7D91306E51F54@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070803030401070505010609" X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sics-se:default, sics-se:default, base:default, @@RPTN) X-p0f-Info: os=Solaris 10, link=Ethernet or modem X-CanIt-Geo: =?UTF-8?Q?ip=3D85.235.11.178; _country=3DSE; _region=3DSk=C3=A5ne; _city=3DLund; _latitude=3D55.7000; _longitude=3D13.1833; _http://maps.google.com/maps=3Fq=3D55.7000,13.1833&z=3D6?= X-CanItPRO-Stream: outbound-sics-se:outbound (inherits from outbound-sics-se:default, sics-se:default, base:default) X-Canit-Stats-ID: 09MI8bS7N - 175f1609963d - 20140828 X-Antispam-Training-Forget: https://canit.sunet.se/canit/b.php?i=09MI8bS7N&m=175f1609963d&t=20140828&c=f X-Antispam-Training-Nonspam: https://canit.sunet.se/canit/b.php?i=09MI8bS7N&m=175f1609963d&t=20140828&c=n X-Antispam-Training-Spam: https://canit.sunet.se/canit/b.php?i=09MI8bS7N&m=175f1609963d&t=20140828&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/T7fNdMXkksgwpKzgLjNqreXra2E Subject: Re: [Ace] ACE Use Case document X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 08:11:59 -0000 This is a cryptographically signed message in MIME format. --------------ms070803030401070505010609 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 08/27/2014 06:01 PM, dominique.barthel@orange.com wrote: > Hello all, > > I've read the draft, and notably Section 2.5 with particular interest. > Although I would discuss some of the rationales presented in sections 2= =2E5.1 and 2.5.2, they do not impact the requirements in 2.5.4., which I = agree with. > Section 3 also seems good to me. > I therefore recommend adopting the draft as a WG document so that furth= er efforts can be funneled into making it even better. > Best, > > Dominique > Dominique, please share your points about how sections 2.5.1 and 2.5.2 could be=20 improved, your input would be much appreciated. /Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=C3=A4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms070803030401070505010609 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwiRTjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE0MDEwNzA3MjgzNVoXDTE1MDEwNzEyNTgyMlowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnLm1tc30QxHa9wtdVjC3NgxjLJicnccm0HD+ 1X16kPMKGvwps8F1oDhYn7jXIe46p1AuJMzLK0GIioE4JwxCFGdvpz7cg2xyTyrdBVUzSqez Dfqt4FOJq6hrdrIMS8MHEzl7Jk02gv9cTn/pHQvDpkiThRpbSLU5mlMqtEQ8gDQY5YyBX0Mv 5qculV08I2JU8HEeTt1oeqhvBImgQfOVYMDatHlWHUVVrmYd6iIo+cuiUGd5kiA0XuaLYX0E oCoao/z5Wg9U0sQlx0hl4r96Q+NdoZZ1prfts3qtyBzJ2hu135aikigzJ6sueWHv/jbISUek tOMm0xkx1GOqqWtEAwIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRZmjjBh8N3klra+mVQgC00 pl68ZTAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQELBQADggEBAHqEYmtWr83S+iLXE97KBnHJZiMr6PMuLKxmh0o6UJJwKgf+KTP2czxRnPSI +whuqfQZdmz6g3A2K8AooMU0RXrzncnX1c4826APdnXkRxnGQxtZXI1wuhPn4z7iDKZ6ij9u K5Pfn10JL/ERDig2qJQbqvhtIAx0RY7y7r+hLMvgXVq9mf3WRJYmGQeFW+N9t5Z1eEwG4m9R KAZm0fnfeDn/Ai4kmxTckBH7dZwW2lTtwQqQ4su+PGCJ0e9ndBLpvTqaYGSAl+L7PO7vxPhS /cS67Xa6BtnYJLTr3MaGXaN+CEUFSfwQHa9DKcAqh3kldErI3kCvnot0CigBl4aILOEwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwiRTjAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA4MjgwODExNTJaMCMGCSqGSIb3DQEJBDEW BBR5wN0DMrKuAhshPXIiyjp3r8qDlzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCJFOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMIkU4wDQYJKoZIhvcNAQEBBQAE ggEAdFLry5hEnSZlAtwl3rs/sm1xiKiEPeTHEmPf7H4kalLR35I0ndadXljBVaNTOkwVQXSg 7fM3JEf1via/IPwtaUK6578UA9Gg4+fSZ4CvKsIYgVT0+p4hwFkeS6KFZJ9Wv8Tv6aIswWSW YY/CG7we2EA8mUYsifOkcBasw3dEyMsQ7hepepnWvEWEyP0lrCPqK9Wmxqu1Womek5dxZuwG YHqP/hOM+bBH2TGp401CY2B0QE3iGNXFUNvlakCdN5S0vNoCZoGf5l02OgLcbWPxR/dyhVSl Uvpufe7lXJ6yS0jMb37wimy2srViuWFa5USI+VsDnq+IhyVIz+6bjmy84QAAAAAAAA== --------------ms070803030401070505010609-- From nobody Thu Aug 28 05:51:43 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0971A03EA for ; Thu, 28 Aug 2014 05:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzIbxFXLYjBU for ; Thu, 28 Aug 2014 05:51:38 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B3C01A02D0 for ; Thu, 28 Aug 2014 05:51:37 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id uz6so540002obc.5 for ; Thu, 28 Aug 2014 05:51:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=mfCPJr65sygy48tsObzjyhCtpk9AlYGx8yb1CUZY3+I=; b=yXr/5YgfXnS4rmZxFdCv+wh32XxSw7K7kJbUBucSZICCmlzX/Sj/moZbLPUvD/fvmd VRcAMYDmhqhviE+02E/kPdqtR7Fte+w7G1/QDHkgU3+H9Q7cISWgFGJs/Af8qTtlr1ab 0HckFsmoJmfxqCz/X/GPbhQRIDRvagbOd4WZ87wuO50/d0r1cGEhJPlJO4r23N9arjU9 NCmoc0JpbmtJOpveerA6QipzZkIpDevfaboR6v/oqLS2M7+jD9fufjq3QRmsvZd7jmeF 5OwBhIYhbZ+sWjbdWk3a5uU1i1NCQm7N216PAZoi8jV+M5T4jD0LoKEynZDlmpLOD0fy vDQg== X-Received: by 10.60.52.144 with SMTP id t16mr1857818oeo.81.1409230297459; Thu, 28 Aug 2014 05:51:37 -0700 (PDT) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.118.107]) by mx.google.com with ESMTPSA id bu7sm5472054oec.9.2014.08.28.05.51.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Aug 2014 05:51:37 -0700 (PDT) Message-ID: <53FF25D4.70406@gmail.com> Date: Thu, 28 Aug 2014 08:51:32 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Hannes Tschofenig , "Ace@ietf.org" References: <53F5F6F0.4000202@gmx.net> In-Reply-To: <53F5F6F0.4000202@gmx.net> Content-Type: multipart/alternative; boundary="------------010602080302010402040408" Archived-At: http://mailarchive.ietf.org/arch/msg/ace/3voIkja_hm5fXuBwGCOa6PNulgo Subject: Re: [Ace] ACE Use Case document X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 12:51:39 -0000 This is a multi-part message in MIME format. --------------010602080302010402040408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Hannes: I think also Dorothy Gellert, Anthony Nadalin, Kathleen Moriarty, and Mike Jones weighed in on during your first "call for adoption" time window. {For their feedback, please see the email archive.} Given traffic so far, it seems prudent to take the draft off the table for now and morph it into something more palatable to the group first. There are lots of groups working on internet of things style use cases, both in home control, industrial control, smart grid, and, e.g., critical infrastructure. Shouldn't the efforts of ACE aim to be as ambitious as serving all those application domains? Best regards, Rene On 8/21/2014 9:41 AM, Hannes Tschofenig wrote: > Hi all, > > we started a call for adoption of draft-seitz-ace-usecases as a starting > point for the use case charter item in July and we were hoping to get a > lot of feedback. > > Unfortunately, it turned out that only very few responded, namely > Robert, Michael, Peter, and Rene (whereby Rene voiced concerns). > > Of course, you may have been on vacation and therefore unable to review > the draft and to respond. > > With the vacation period coming to an end we hope to receive additional > feedback from other working group participants. > > Ciao > Hannes & Kepeng > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------010602080302010402040408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Hannes:

I think also Dorothy Gellert, Anthony Nadalin, Kathleen Moriarty, and Mike Jones weighed in on during your first "call for adoption" time window. {For their feedback, please see the email archive.}

Given traffic so far, it seems prudent to take the draft off the table for now and morph it into something more palatable to the group first.

There are lots of groups working on internet of things style use cases, both in home control, industrial control, smart grid, and, e.g., critical infrastructure. Shouldn't the efforts of ACE aim to be as ambitious as serving all those application domains?

Best regards, Rene

On 8/21/2014 9:41 AM, Hannes Tschofenig wrote:
Hi all,

we started a call for adoption of draft-seitz-ace-usecases as a starting
point for the use case charter item in July and we were hoping to get a
lot of feedback.

Unfortunately, it turned out that only very few responded, namely
Robert, Michael, Peter, and Rene (whereby Rene voiced concerns).

Of course, you may have been on vacation and therefore unable to review
the draft and to respond.

With the vacation period coming to an end we hope to receive additional
feedback from other working group participants.

Ciao
Hannes & Kepeng




_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------010602080302010402040408-- From nobody Thu Aug 28 05:52:17 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC0A1A03EF for ; Thu, 28 Aug 2014 05:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aczYBjlqQMC6 for ; Thu, 28 Aug 2014 05:52:07 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BFD11A02D0 for ; Thu, 28 Aug 2014 05:52:06 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id eb12so535221oac.40 for ; Thu, 28 Aug 2014 05:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=/qAiY+79m7wdTEY02acAwZhYy+9PqPmBd5Ef0HKt1mM=; b=JTKwSNA0D5qpkjf6ImWefTRTJgBGxgQMmbEETyxlIBof+B/Ykjf7gNkc57Cfp0FzoS fxrGPDmfOaAkDhIwk9v4WY4q1+u0zbnLOSfq+r7f138ubOgHgEpVE7W87z/tts/ZIio4 oQcxXK75Q7zktlERPAb1rqvXVGuwPAHwhQoeQcGT4euPh7ZDPJqWcxLg0pjypwRe7zEC Kgwr8RR3toROJA6JHfnh52g7siwL5hzYnU0x3RQG+pnbH4dWobFaSLNGzoJHwDlNJ36P k2apqz48BHVm34shXe/Wn0Mnc5fF2x9+AskEYqHmktUmkkjpAfq1QiD7Dm9I+57FNSJE nVUA== X-Received: by 10.60.74.6 with SMTP id p6mr3279031oev.43.1409230326428; Thu, 28 Aug 2014 05:52:06 -0700 (PDT) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.118.107]) by mx.google.com with ESMTPSA id d8sm5490456oel.4.2014.08.28.05.52.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Aug 2014 05:52:06 -0700 (PDT) Message-ID: <53FF25F1.20403@gmail.com> Date: Thu, 28 Aug 2014 08:52:01 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stefanie Gerdes , "ace@ietf.org" References: <53CFEE95.309@tzi.de> In-Reply-To: <53CFEE95.309@tzi.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ace/FQRFv4HslgYgb5wngNKnLKvuKKI Subject: Re: [Ace] How to progress? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 12:52:12 -0000 Hi Steffi: Just curious: did you get any more feedback on your questions posed on the day of the ACE WG meeting in Toronto? So far, I have seen detailed feedback by Michael Richardson and myself and more general feedback by Hannes Tshofenig and Goran Selander, but I can imagine you received more feedback than just from these four persons off-list. If you feel a compilation of feedback would benefit the group, this may be a good thing to provide. Best regards, Rene On 7/23/2014 1:19 PM, Stefanie Gerdes wrote: > Hi everyone, > > The discussion today and during the previous meetings made me think that > there are still a lot of unspoken assumptions and requirements flying > around. I think we won't be able to come to an agreement on a solution > if we don't manage to identify the key assumptions and requirements. > This is why I came up with a couple of questions which I think would > help to explore the context of the problem we are trying to solve. I > know that there will in most cases not be only one answer to these > questions but I think we will need to get a feeling about the range of > answers. > > These are the questions I came up with: > 1. What categories of constrained devices do we want to support (C0, C1..)? > 1a) What are the smallest devices we are going to support (RAM, ROM, etc)? > 2. For each device in the architecture: What are the limitations of this > device? > 2a) Are the limitations always the same? > 2b) How much can we gain from introducing less constrained actors? > 3. What message sizes do we want to consider? > 4. What are the application security requirements for the > communication between constrained nodes? > 4a) Integrity > 4b) Confidentiality > 4c) Non-Repudiation > 4e) ... > 4f) Are all of these always needed? > 5. Which level of security is needed on the devices (high, middle, low)? > 5a) Do we always need devices to be tamper-proof? > 6. How do the constraints of the nodes influence the protocols to be used? > 7. Can we find a single protocol which supports all kinds of devices in > every part of the architecture? > 8. What roles do proxies have that we want to support? > 9. Do we need authorization without user interaction? > 10. Which constraints concerning the connectivity of devices do we want > to support? > 10a) "Offline" authorization (only some devices are "online", no > device is online, etc) > 10b) Intermittent connectivity > 10c) Special connectivity requirements (e.g. unidirectional links) > > > I thought it might be helpful to collect the relevant questions and > assumptions in a wiki: http://trac.tools.ietf.org/wg/ace/trac/wiki/Questions > > What do you think? > > Thanks, > Steffi > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Thu Aug 28 06:49:24 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99DE11A0430 for ; Thu, 28 Aug 2014 06:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sg_bpvYW4nG9 for ; Thu, 28 Aug 2014 06:49:19 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92A261A0428 for ; Thu, 28 Aug 2014 06:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s7SDn7CR000923; Thu, 28 Aug 2014 15:49:07 +0200 (CEST) Received: from [134.102.218.214] (dynamic-218-o.informatik.uni-bremen.de [134.102.218.214]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8DCA6BEC; Thu, 28 Aug 2014 15:49:07 +0200 (CEST) Message-ID: <53FF3353.3020806@tzi.de> Date: Thu, 28 Aug 2014 15:49:07 +0200 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Rene Struik , "ace@ietf.org" References: <53CFEE95.309@tzi.de> <53FF25F1.20403@gmail.com> In-Reply-To: <53FF25F1.20403@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ace/XxnVm_YfNkgABetHSHu4U029irw Subject: Re: [Ace] How to progress? X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 13:49:21 -0000 Hi Rene, I added the feedback from the people you mentioned and also tried to add other aspects that people mentioned on the list, such as Kathleen's comments to the use cases document. Moreover, I tried to transform the questions to be more of a check list because of Kepeng's suggestion to have yes/no questions. The current version of the question is available in the wiki [1]. For your convenience, I will also list them below. I was on vacation the last two weeks and I'm just back in office today. I'm still trying to catch up on things so I might have missed some stuff that happened in the meantime. Best regards, Steffi [1] http://trac.tools.ietf.org/wg/ace/trac/wiki/Questions ACE: Exploring the Problem Space 1. What categories of constrained devices do we want to support (cf. http://tools.ietf.org/rfc/rfc7228)? * C0 (data size << 10 KiB, code size << 100KiB) and above * C1 (data size ~ 10 KiB, code size ~ 100KiB) and above * C2 (data size ~ 50 KiB, code size ~ 250 KiB) and above * What are the smallest devices we are going to support (RAM, ROM, etc)? 2. What are the limitations of constrained devices? * Limited RAM, ROM * No user interfaces * Unable to precisely measure time * Limited ability to send / receive messages * Limited Energy * Are the limitations always the same? 3. Which configurations of constrainedness do we want to consider? * C and RS are constrained * C is constrained but RS is not * RS is constrained but C is not 4. What can we gain from introducing less constrained actors? * Translate complex policies into authorization tokens which are easy to validate * Providing the owner's policies without user interaction at the time of authorization * Attribute Validation (does the entity in possession of a certain key really posses the claimed attributes) * Providing a user interface to owners * Time Keeping 5. What are the limitations of less constrained actors? 6. What limitations of underlying protocols do we have to consider? * Frame size 7. What are the application security requirements for the communication between constrained nodes? * Integrity * Confidentiality * Non-Repudiation * Privacy * ... * Are all of these always needed? 8. Which level of security is needed on the devices (high, middle, low)? * Do we need the constrained devices to have unique identities? * Do we always need devices to be tamper-proof? * Do we need tamper detection/auditing? * Logging / Protection of Logs / Purging * Do we need end to end security? 9. How do the constraints of the nodes influence the protocols to be used? 10. Can we find a single protocol which supports all kinds of devices in every part of the architecture? * Communication between two constrained devices * Communication where one endpoint is constrained * Communication between less constrained devices as needed to transmit the authorization information 11. What roles do proxies have that we want to support? * Reverse proxies * Forward proxies * Cross-protocol proxies 12. Do we need authorization without user interaction? 13. Which constraints concerning the connectivity of devices do we want to support? * "Offline" authorization (only some devices are "online", no device is online, etc) * RS may not be able to communicate with AS at the time of the request from C. * C may not be able to communicate with AM at the time of the request. * C may not be able to communicate with AS at the time of the request. * C must be able to act on RS when both are disconnected from everything * Intermittent connectivity * Latency * Special connectivity requirements (e.g. unidirectional links) * Sleepy Devices 14. Do we need to consider problems concerning the lifecycle of devices other than the operational phase? * Commissioning * Maintenance * Decommissioning * Handover 15. Do we need to consider specific threats? * Session intercept / hijacking * Monitoring From nobody Thu Aug 28 11:09:40 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E000D1A6ED9 for ; Thu, 28 Aug 2014 11:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmLmM3iOGQjU for ; Thu, 28 Aug 2014 11:09:33 -0700 (PDT) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FD561A88F1 for ; Thu, 28 Aug 2014 11:09:33 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id eu11so3501496pac.39 for ; Thu, 28 Aug 2014 11:09:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=T4VPXETrGcCtfu4I0DA4TsYwPtxEgVWApPG6PiXysDc=; b=YpVVwj4AvNV0cwTNAObxqFOBJ457fZI5+5kta3oWEmDMILdzSkCxXSrGQ6xC4S3YcW K1apR5D0c3LbH0WOwcC9a9Ve5p5nEUVwv9FCn1nVOeP+P+Z/7wEBKZCttDSFSEk4P6b0 wmbYb93n0UUyZzGc2siuD0JUTBGuYbZrcfA8Vw9o0WaHMKtgP+ao8MYu3vFeMUCKZF/W /n2wqdHt0AVfgeJQ95CrcRPDqusLZ5oeVoe6WmN7voXNccqcG4vm3JHZ6vCDHIM6WDLI KE1sRy+naBaA98NeoeZxNS4INykT+lkEQlOVT8bianomad7mqic1omxbuL1HFj06hVHD hJNw== X-Gm-Message-State: ALoCoQkqBWy159GLPme7wimqROglmhzTd2b3iLfUWecs6PoRTtTOYlSAUaX6sqmQ6s8TDI+ofR0F X-Received: by 10.68.139.99 with SMTP id qx3mr8205217pbb.75.1409249370094; Thu, 28 Aug 2014 11:09:30 -0700 (PDT) Received: from [192.168.1.94] (75-37-193-167.lightspeed.lsatca.sbcglobal.net. [75.37.193.167]) by mx.google.com with ESMTPSA id v1sm6345530pdp.76.2014.08.28.11.09.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Aug 2014 11:09:29 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Lambert In-Reply-To: <53F88813.8060403@gmx.net> Date: Thu, 28 Aug 2014 11:09:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53F88813.8060403@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/hfXPH3hzIVFfEMtKUbHLqF9w-v4 Cc: "Ace@ietf.org" Subject: Re: [Ace] Webex Conference Call about "How to Select Hardware for IoT Systems?" X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 18:09:37 -0000 On Aug 23, 2014, at 5:24 AM, Hannes Tschofenig = wrote: > Hi all, >=20 > Various groups in the IETF currently standardize technology for use = with > constrained devices and the choice of hardware impacts the design of > Internet of Things (IoT) systems. To provide guidance RFC 7228 > "Terminology for Constrained-Node Networks" defines three classes of > devices depending on their RAM and flash memory size. Class 0 > characterizes devices that have less than 10 KiB of RAM and less than > 100 KiB of flash memory and RFC 7228 adds "... most likely they will = not > have the resources required to communicate directly with the Internet = in > a secure manner." For others even class 2 with ~ 50 KiB of RAM and ~ = 250 > KiB of flash memory is too constrained. May or may not be able to attend call, but generally disagree with above = statement. Bluetooth, WI-Fi, Zigbee all have built in security and crypto hardware. = It=92s not hard to provide cryptography. Public key techniques are also possible in very constrained devices. =20 There are also some low overhead symetric algorithms that take minimal = processing and memory. All that is needed is clear requirements and devices can be built. However =85 TLS, DTLS and X.509 are a bad path (IMHO). These have been = verburdened with cruft from years of patching and bad design practice. = These security approaches will not fit. =20 Likewise, OAuth and other web centric security frameworks were not = designed for small devices. Trimming might be possible, but it would = be better to pursue simpler frameworks that could be scaled upward, than = trying to shrink larger frameworks to fit. Paul PS - currently working at a Semiconductor company on IoT and wireless = ... >=20 > With the increasing commercial interest in IoT the question about a > reasonable hardware configuration surfaces again and again. At IETF#90 = I > offered to bring a hardware expert along. Peter Aldworth, a hardware > engineer with more than 19 years of experience, will lead the = discussion > at an upcoming webinar. >=20 > Please indicate your availability here: > http://moreganize.com/bzTrVxhqaHp >=20 > Ciao > Hannes >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace