From nobody Mon Feb 1 01:59:44 2016 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 736D21B2F8E for ; Mon, 1 Feb 2016 01:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 mhgRDKp-V35N for ; Mon, 1 Feb 2016 01:59:41 -0800 (PST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6DC31B2F8C for ; Mon, 1 Feb 2016 01:59:41 -0800 (PST) Received: from mfilter34-d.gandi.net (mfilter34-d.gandi.net [217.70.178.165]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 555CFA83E1; Mon, 1 Feb 2016 10:59:40 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter34-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter34-d.gandi.net (mfilter34-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id ZpQw4ynZ42XP; Mon, 1 Feb 2016 10:59:38 +0100 (CET) X-Originating-IP: 93.199.254.229 Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 1C1BFA83D7; Mon, 1 Feb 2016 10:59:37 +0100 (CET) Message-ID: <56AF2C89.7040102@tzi.org> Date: Mon, 01 Feb 2016 10:59:37 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Ludwig Seitz References: <56AF0EA9.40309@sics.se> In-Reply-To: <56AF0EA9.40309@sics.se> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] CoAP option for Access token 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, 01 Feb 2016 09:59:43 -0000 How is the token bound to the current request? To the next request? I have trouble following the conversation because I don't understand what the assumptions are about protection (integrity/authentication of the message being specifically authorized by using the token; also of course confidentiality of the token). In a constrained environment, it is probably better to establish the access (authorization) in a separate transaction and bind this to a specific request via the communication state. This should be done explicitly (e.g., during connection establishment or by using a RESTful mechanism bound to the connection after connection establishment). Grüße, Carsten Ludwig Seitz wrote: > Wouldn't it still be possible for the RS to save a token sent in an option? > Would it then not be possible for the client to remember that it already > sent this token in a previous request (and that it is still valid)? > Would the client then not be able to omit it from further requests > (until it is no longer valid)? From nobody Mon Feb 1 02:47:18 2016 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 8A7491B3069 for ; Mon, 1 Feb 2016 02:47:17 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 rL_aBmqCuVMi for ; Mon, 1 Feb 2016 02:47:15 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BEA61B306D for ; Mon, 1 Feb 2016 02:47:15 -0800 (PST) Received: by mail-lb0-x232.google.com with SMTP id cl12so72195881lbc.1 for ; Mon, 01 Feb 2016 02:47:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=QXEd00DIzLn6sDPq//HbHddOGkdQCgYJvMba75bggw8=; b=OG5nzsnck8iILThEKnawOeThzxnHs9NsEnkX3O3+dv/2ZSERL3wKtyQcZCIoCC40m7 cWVyGxeBRXiIQLbAW+x40cL8Pv0PUEshP6cHf2J1Aqm25BUSMFWSlNHbX1DnDl+EZ3dA KOSUod3jtw/dbcitnZGCbP23HUYycZs31FgOcCK9NDWrz4MPymaBwQRGBORb7btUpv6M xTJ0sH8SqqE7gzg47UMZRmfChVm9o3hFC/R+ZQeGUE6HNJ/nkua4qBbsgBJ4k9aV2GnL zRHw68wK75XeHlY4yLAOIuOb8xkVvLLaJo42yzOHEsJ5c9US57CzwAAxelRa7yr1cMqQ K0QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=QXEd00DIzLn6sDPq//HbHddOGkdQCgYJvMba75bggw8=; b=bOV+bcwOHwURiQ8/+psXQ25Iqm+ogaY6FGKihiEpbc6I/73AUPVKhy/MIXlBz86qyx UEHAQoO7xJve4yxrfwx49TTrBZd57mSNTrA8c9/zvqt6QuEJ2Q9MrJxrjNYmJsnTi2ST 6801hrg8WhSwLEpvNr2wOZe3gq1T0KBWwQxku06o0ObCWwzYufVvMJw6piJ3fiROuzj6 iTmUXE/58rnDi7Ff2J52vk3CJdlxnimruAu4QwPanV5DoxRqhvCQww0UcdhsdX8OuE/q Dh5Snq1kE0GwkuwxTOxbFymcpzC8xBwSuZNrGuz43oC0XP2JKB8U1qj8nfRYivkzRFL8 Kcfw== X-Gm-Message-State: AG10YOS1m2dbYe90Ihpf5jCouGm14Wp7tCIVb63Z3npXia7gjXSxj6pfSntho4pQjhGaoE2x X-Received: by 10.112.168.194 with SMTP id zy2mr8397052lbb.120.1454323633235; Mon, 01 Feb 2016 02:47:13 -0800 (PST) Received: from Hyperion.suse ([85.235.10.186]) by smtp.gmail.com with ESMTPSA id jx8sm3905957lbc.29.2016.02.01.02.47.12 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Feb 2016 02:47:12 -0800 (PST) To: Carsten Bormann References: <56AF0EA9.40309@sics.se> <56AF2C89.7040102@tzi.org> From: Ludwig Seitz Message-ID: <56AF37AF.2020608@sics.se> Date: Mon, 1 Feb 2016 11:47:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56AF2C89.7040102@tzi.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000801000406030504090101" Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] CoAP option for Access token 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, 01 Feb 2016 10:47:17 -0000 This is a cryptographically signed message in MIME format. --------------ms000801000406030504090101 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 02/01/2016 10:59 AM, Carsten Bormann wrote: > How is the token bound to the current request? To the next request? > I have trouble following the conversation because I don't understand > what the assumptions are about protection (integrity/authentication of > the message being specifically authorized by using the token; also of > course confidentiality of the token). > > In a constrained environment, it is probably better to establish the > access (authorization) in a separate transaction and bind this to a > specific request via the communication state. This should be done > explicitly (e.g., during connection establishment or by using a RESTful= > mechanism bound to the connection after connection establishment). > > Gr=C3=BC=C3=9Fe, Carsten > > Ludwig Seitz wrote: >> Wouldn't it still be possible for the RS to save a token sent in an op= tion? >> Would it then not be possible for the client to remember that it alrea= dy >> sent this token in a previous request (and that it is still valid)? >> Would the client then not be able to omit it from further requests >> (until it is no longer valid)? The underlying assumption is that the token is a proof-of-possession=20 token, i.e. that it is associated with a key (symmetric or asymmetric)=20 that the client possesses and that the RS can verify possession of. The binding of the token to a request happens by either using that key=20 to establish session security (e.g. as PSK or RPK for DTLS), or by using = that key in an object security protocol and using that protocol to=20 secure the request. Could you exemplify what you mean with "by using a RESTful mechanism bound to the connection after connection establishment" I'm=20 not sure I'm following you here. Regards, 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 9251 http://www.sics.se --------------ms000801000406030504090101 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CtEwggTnMIIDz6ADAgECAhAfP2QWc8z7Bo71GhHCZ7DdMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMTA3MTE1NzM3WhcNMTcwMTA3MTE1NzM3WjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCiG5fxnXbdU0+3qInGZloXB0zZLM6XAu0EmTuCsWOU8eXN lCe37PTURORfLc3te4gCDcG1GrI2AuWR9MvlcYddMZt5y0T5BVWIu534vVJtG3QCuEYRJOTW B6RWQfK+dIPpZsNhgEQkYLjTHYoCu58gP0pfxNie1X7D+RxeQcq+ynNmyFdsxc2mI+dQqBKq 4zTsCNP4/jpSuovXTn8hEbbR8zkVQ2v/Gx+EO8oMIvkIEUYzkMxe3E9A7dq5DwotRDzP+y3g C4DCtI0tfIUtFjx18Pb5UMNUKZjitrOpXfheEz/igxziydri8bYpx4qGU9CNX+MvQG7Ogqju XKfQhUTTAgMBAAGjggGuMIIBqjALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFBMb8zf+BJ13fxqEl9gYiwxZ4hpmMB8G A1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCugKYYn aHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCBDmx1 ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNV HSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAbgRzIj1s9U5kpXodti5kdj3ztjPb oz4pz8zNwn3qPUW8c3Zd40IFe+R5hRDuIm2aa//fmwop2mLM3+5/LnSnacaDnRfE7pP3NgqX XUuuZf9TtMLU6RUh2Z9JKs0IzWKALPhoLgnCsbtYDrF4QAoVqeNV79Lb6a3r6KdB/xFErbee OkZk/iw9HCr/jnvysYjfFQcBounseJS3JG4RNIuDpfsWPupQSAhl4s0akaakiwqOHCU7x0Ra rbCN+bg+6R5FEtSouIh53Z04JmI7LU3leo/AseQiUpJ6HqQNJYjnsCw8DDbijNhH41ZZKrvB rKMfVvlCH9VqrKW4kPGajKMEJDCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJ KoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0 YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIx NjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNV BAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENv bSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL19 2vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk 9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89V LnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZ ZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8U lVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4G A1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/ BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9z ZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFy dHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2Nh LmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRA W6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4St DwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y 5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bj yOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfC BJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSi F3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odh QJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfr Bzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4W VWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9Vyrw MdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2de oprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAfP2QWc8z7Bo71 GhHCZ7DdMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNjAyMDExMDQ3MTFaMC8GCSqGSIb3DQEJBDEiBCDmajgEu585TlLN x1yf5O/Cqy/VLyI9lm0gbfrbvGW/zTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQHz9kFnPM+waO9RoRwmew3TCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQ Hz9kFnPM+waO9RoRwmew3TANBgkqhkiG9w0BAQEFAASCAQCW9NYNGOsj5cFVedkbqQZOVkrp 2vYU+grc+bVc0PfxzWWk7HMIumf9TxHbciLKIc4ksOxbBqV95vzKY8wL/CFnevAcrQ6eqRGA cqgKLQifCNJHquc4ps4yYVklZtcfvrpocsoCpxfKO7B7uQpQdfQYg2tHf30E8YWlcJvYioKX 1NNcPCh0lpWp+5+3xKbaQkIcs60+xxvfl13ObFp5eLy7YCGFm6vM2a8j/5vna8Otk1pLglfQ FhwT/aVyAZh+EHEPp4XpSxWYj2v4T1dspFsjlMG71ru+fhZbSGHLY0O0GM/XGyVyGFUZEgKT grXxFwsxo44Vcbz8R3XYhni0HZKjAAAAAAAA --------------ms000801000406030504090101-- From nobody Mon Feb 1 03:07:43 2016 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 B35361B3099 for ; Mon, 1 Feb 2016 03:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1xdawI8khEsm for ; Mon, 1 Feb 2016 03:07:41 -0800 (PST) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5608C1B3064 for ; Mon, 1 Feb 2016 03:07:41 -0800 (PST) Received: from mfilter44-d.gandi.net (mfilter44-d.gandi.net [217.70.178.175]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 5264CC5A3C; Mon, 1 Feb 2016 12:07:39 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter44-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter44-d.gandi.net (mfilter44-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id aqGmCq3F7i7i; Mon, 1 Feb 2016 12:07:38 +0100 (CET) X-Originating-IP: 93.199.254.229 Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id B8CC6C5AC0; Mon, 1 Feb 2016 12:07:32 +0100 (CET) Message-ID: <56AF3C73.3050806@tzi.org> Date: Mon, 01 Feb 2016 12:07:31 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Ludwig Seitz References: <56AF0EA9.40309@sics.se> <56AF2C89.7040102@tzi.org> <56AF37AF.2020608@sics.se> In-Reply-To: <56AF37AF.2020608@sics.se> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] CoAP option for Access token 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, 01 Feb 2016 11:07:42 -0000 > The underlying assumption is that the token is a proof-of-possession > token, i.e. that it is associated with a key (symmetric or asymmetric) > that the client possesses and that the RS can verify possession of. > > The binding of the token to a request happens by either using that key > to establish session security (e.g. as PSK or RPK for DTLS), or by using > that key in an object security protocol and using that protocol to > secure the request. OK, both kinds of communication security (via DTLS or via an "object security" protocol above DTLS) establish a security session that can be bound to, using the PoP token once, not per request. > Could you exemplify what you mean with "by using a RESTful > mechanism bound to the connection after connection establishment" I'm > not sure I'm following you here. As in POST /authorize (Note that since we are in an authenticated session, this is just about establishing additional authorization, not about re-authenticating either side. The server needs to bind that authorization to the session.) Look, Ma, no option :-) (Except for protecting the message in any "object security" session, if needed.) Grüße, Carsten From nobody Tue Feb 2 05:28:12 2016 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 0C6BB1B2ACF for ; Tue, 2 Feb 2016 05:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 mKaIwjNRsSAP for ; Tue, 2 Feb 2016 05:28:09 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10CEA1B2ACE for ; Tue, 2 Feb 2016 05:28:08 -0800 (PST) Received: by mail-lb0-x234.google.com with SMTP id bc4so94232452lbc.2 for ; Tue, 02 Feb 2016 05:28:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wahlstromstekniska-se.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=v3PmMlFLwbpmXxcQYHZBr5orkiHcsSDCGl5IhEC4sfg=; b=cmXlFqFaV2EuRPLY6nQsjTaaR4VEi7P7xU/+vd9YWQDXBpP1ijM579bIeyA5FQuERc 0IzSnVQJX8wySMWIrAPCqFG0SJ4mjE+8lb1G1oyWmwa7AI3YutMqMK5Wf+B3EZJZw6YA 2SMmo9dTcr3UdMPPJELd+j/Mvdf8HQOfQunsGtqvfxzRHZtW6aAML8YEvCFsWLRcBByu KRhcWGtSfW5GanojoYhtfME0XuaydLHojrpRGdeGtl+KRugi63nkHbfQjyxuGxv+iiL9 8W2yfjex+e+8vArm8vLr7MFUUsz5VeUY+qZ7F7223IdewpQCbBrgd1aPXjuvxCoQFn8H qXFQ== 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:message-id:references:to; bh=v3PmMlFLwbpmXxcQYHZBr5orkiHcsSDCGl5IhEC4sfg=; b=e0wyGmyrZNzMMys7nDGZ7rmKupfi/JM0NF2nZOJMIkGjBstdAMum3moLPdG+M6khGf hNG2TRTYbIgoEZzCHYnhqQbY4euezPntAPeRFVhz9VFiz/DawLeq1TNOV2a24tiGdp5M FuSYilRXu0ZveJe3tyHDzdqwCpgQfRIHeBwgfqxfR66Ro52It9zC8+LzVEWKAjUrzkA6 Im6CatQoDRol8STUMcG/BEY9zkgrNq0iR2zHe7JwGN2KtV+g3To2Oqe2Bs1XKem5wxe5 hMyRGjdp8XkDA6tU/BzJTOq4+eq6RVRXBqCXmIhhlFWfu1cXFm+pIOPU+mxlr4uEWzG4 0L+Q== X-Gm-Message-State: AG10YOT52Aqz8aogp0Qrd+GOTFsXi+xjZJ1iBldczPUOk+rPXCUYFIoLG/v9tjcPiQbsgA== X-Received: by 10.112.166.33 with SMTP id zd1mr10783232lbb.71.1454419686909; Tue, 02 Feb 2016 05:28:06 -0800 (PST) Received: from [192.168.1.5] (37-247-26-197.customers.ownit.se. [37.247.26.197]) by smtp.gmail.com with ESMTPSA id wj2sm215699lbb.5.2016.02.02.05.28.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 02 Feb 2016 05:28:05 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_5DAE6C74-EF87-4F67-9900-9E44B1C4C5F0" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: =?utf-8?Q?Erik_Wahlstr=C3=B6m?= In-Reply-To: Date: Tue, 2 Feb 2016 14:28:03 +0100 Message-Id: References: To: Samuel Erdtman X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Ace@ietf.org Subject: Re: [Ace] CoAP option for Access token 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, 02 Feb 2016 13:28:11 -0000 --Apple-Mail=_5DAE6C74-EF87-4F67-9900-9E44B1C4C5F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I think an Access-Token option (or Bearer as in = https://tools.ietf.org/html/rfc6750#section-2.1 = ?) is a good thing if = both client and resource server knows that it=E2=80=99s such a small = token. I do however think it=E2=80=99s an optimisation and that it=E2=80=99= s something that could be sorted later on (maybe even in an future = optimisation extension). / Erik > On 30 Jan 2016, at 22:48, Samuel Erdtman wrote: >=20 > Hi, >=20 > Working on the draft-ietf-ace-oauth-authz draft I see the need for a = CoAP Option to send access token in. This option can be used when token = is smaller then 255 bytes. Then it comes down to the trade-of between = sending the access token once to the authorization information resource = at the RS and sending it in each request as this option. >=20 > Can we agree that we need this option? > Should we call it Access-Token or is that to specific? >=20 > Best Regards > //Samuel >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --Apple-Mail=_5DAE6C74-EF87-4F67-9900-9E44B1C4C5F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

I = think an Access-Token option (or Bearer as in https://tools.ietf.org/html/rfc6750#section-2.1?) is = a good thing if both client and resource server knows that it=E2=80=99s = such a small token. I do however think it=E2=80=99s = an optimisation and that it=E2=80=99s something that could be = sorted later on (maybe even in an future optimisation = extension).

/ = Erik



On = 30 Jan 2016, at 22:48, Samuel Erdtman <samuel@erdtman.se> = wrote:

Hi,

Working on = the draft-ietf-ace-oauth-authz draft I see the need for a CoAP = Option to send access token in. This option can be used when token is = smaller then 255 bytes. Then it comes down to the trade-of between = sending the access token once to the authorization information resource = at the RS and sending it in each request as this option.

Can we agree that we = need this option?
Should we call it Access-Token or = is that to specific?

Best Regards
//Samuel

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

= --Apple-Mail=_5DAE6C74-EF87-4F67-9900-9E44B1C4C5F0-- From nobody Tue Feb 2 11:52:12 2016 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 618B31B3038 for ; Tue, 2 Feb 2016 11:52:09 -0800 (PST) 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, HTML_MESSAGE=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 vneO_quljl-1 for ; Tue, 2 Feb 2016 11:52:07 -0800 (PST) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A0131B303C for ; Tue, 2 Feb 2016 11:52:06 -0800 (PST) Received: by mail-qg0-x22f.google.com with SMTP id e32so159135938qgf.3 for ; Tue, 02 Feb 2016 11:52:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1PB1tYXRvMpCEdCBQ55+1wCo4N8eujNOwKWxKVc1wG0=; b=XcZxmdBrNgNgFISFbtsf77roSENAdMyHYNBAB+wLzbAMGUHScMovDJdHZNTMBA4ght 6cw0xCeLbvO0PCCGsJmTpXQ0zcQqFJIwOlPrQIp5JNFS3/z4Bo6E7WInFp0UJ6HSNsya oUAnysHs0BQsq3T2AsGyaNAKyCJzlWgAzaPg4SukQY0NcYaxXGkV71zE7Ga/lzdrqNuS V9LCRFHS5EYIlF4sKSEmpB00jQF1Qu1jzieoAvg/dpVKqMK/T2TN7hSwNKr48viJMgz4 /lHCWohNMlWwTUztf+Lnf2S0ey86AH0xUoAFRMwNYTI+G+K8D2G7+7AyXCBBTzuTZhcH kHCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1PB1tYXRvMpCEdCBQ55+1wCo4N8eujNOwKWxKVc1wG0=; b=YxKi3pvhCExUbpKuIds4sQH9IkqdmnRH8U6TjO5eDBRapEXUfgBfZJcGuyVfSC03iK sQU3d0cQ3P06WgS5ouDZ29MslOmnJ9OQvz6guu6VXRb2hXX2PaNNOC3CHZRfgE6ywddY +k+0OfsY0yYtoxWapyxMcDRFKtdWVJTcf0K1MVDenpxyI4whKn3pIW2W9usdcxweSQ2T zPpLT3xFns/iatDgJ+eklQA3AheUQCUxnMk038kiBMS1AQAyl3hzykX9fCd9LGo/1z6/ Xf2bRzOa5WnxR25hdYKrX+KpmO/Co7R6P/dqMN4Rswdmg5Vy5bvqb2zIgXaav5MVEfMi qjUg== X-Gm-Message-State: AG10YORkgC+B2x8WCPl2XHPJ/cBo5MOqk6tdoofOyH20X/O4smkRehYFS6WTDn4Pnyb3iYIO31J63fCt7p6ruA== MIME-Version: 1.0 X-Received: by 10.140.250.138 with SMTP id v132mr39576457qhc.0.1454442725346; Tue, 02 Feb 2016 11:52:05 -0800 (PST) Received: by 10.55.179.1 with HTTP; Tue, 2 Feb 2016 11:52:05 -0800 (PST) In-Reply-To: References: Date: Tue, 2 Feb 2016 20:52:05 +0100 Message-ID: From: Samuel Erdtman To: Ace@ietf.org Content-Type: multipart/alternative; boundary=001a113a99d0fd9ae0052aced510 Archived-At: Cc: Carsten Bormann , Ludwig Seitz , =?UTF-8?Q?Erik_Wahlstr=C3=B6m?= Subject: Re: [Ace] CoAP option for Access token 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, 02 Feb 2016 19:52:09 -0000 --001a113a99d0fd9ae0052aced510 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I think there is one key benefit of being able to send the access token as an option, if the access token is included as an option the request can be self contained i.e. one operation one request with the access token to prove the rights to do the operation. I think this is useful for operations where the token is used once or very seldom, then it is beneficial not having to send first the token and then do the operation. Further by having the self contained request (access token + operation) the RS does not need to store session data and can in that way serve more clients and If I remember correctly statelessness is one of the key constraints of RESTful design. In the current draft we mention an authorization information resource on the RS in the current working draft it is further detailed. This resource on the RS is meant to be used before the security context (session) has been established. The POST request to the authorization information resource contains the PoP token i.e. an encrypted or signed token that transports the credentials (key) of the client to the RS protected by the AS. Then the key of the client from the token is used for the secure communication DTLS or object security. Best regards // Samuel On Tue, Feb 2, 2016 at 2:28 PM, Erik Wahlstr=C3=B6m wrote: > Hi, > > I think an Access-Token option (or Bearer as in > https://tools.ietf.org/html/rfc6750#section-2.1?) is a good thing if both > client and resource server knows that it=E2=80=99s such a small token. I = do however > think it=E2=80=99s an optimisation and that it=E2=80=99s something that c= ould be sorted > later on (maybe even in an future optimisation extension). > > / Erik > > > > On 30 Jan 2016, at 22:48, Samuel Erdtman wrote: > > Hi, > > Working on the draft-ietf-ace-oauth-authz draft I see the need for a CoAP > Option to send access token in. This option can be used when token is > smaller then 255 bytes. Then it comes down to the trade-of between sendin= g > the access token once to the authorization information resource at the RS > and sending it in each request as this option. > > Can we agree that we need this option? > Should we call it Access-Token or is that to specific? > > Best Regards > //Samuel > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > > --001a113a99d0fd9ae0052aced510 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I think there is one key benefit of= being able to send the access token as an option, if the access token is i= ncluded as an option the request can be self contained i.e. one operation o= ne request with the access token to prove the rights to do the operation. I= think this is useful for operations where the token is used once or very s= eldom, then it is beneficial not having to send first the token and then do= the operation. Further by having the self contained request (access token = + operation) the RS does not need to store session data and can in that way= serve more clients and If I remember correctly statelessness =C2=A0is one = of the key constraints of RESTful design.

In the cur= rent draft we mention an=C2=A0authorization=C2=A0information resource on th= e RS in the current working draft it is further detailed. This resource on = the RS is meant to be used before the security context (session) has been e= stablished. The POST request to the=C2=A0authorization=C2=A0information res= ource contains the PoP token i.e. an=C2=A0encrypted=C2=A0or signed token th= at transports the=C2=A0credentials (key) of the client to the RS protected = by the AS. Then the key of the client from the token is used for the secure= =C2=A0communication DTLS or object security.

Best regards
// Samuel<= /span>

On Tue, Feb 2, 2016 at 2:28 PM, Erik Wahlstr=C3=B6m <= erik@wahlst= romstekniska.se> wrote:
Hi,

I think an Access-T= oken option (or Bearer as in=C2=A0https://tools.ietf.org/html/rfc6750#se= ction-2.1?)=C2=A0is a good thing if both client and resource server kno= ws that it=E2=80=99s such a small token. I do however think it=E2=80=99s an= =C2=A0optimisation=C2=A0and that it=E2=80=99s something that could be sorte= d later on (maybe even in an future optimisation extension).

/ Erik
=


On 30 Jan 2016, at 22:48, Samuel= Erdtman <samuel@= erdtman.se> wrote:

=
Hi,

Working on the=C2=A0draft-ietf-ace-= oauth-authz draft I see the need for a CoAP Option to send access token in.= This option can be used when token is smaller then 255 bytes. Then it come= s down to the trade-of between sending the access token once to the authori= zation information resource at the RS and sending it in each request as thi= s option.

Can we agree that we need this option?
Should we call it Access-Token or is that to specific?
<= br>
Best Regards
//Samuel

_______________________________________________
Ace mailing list
Ace@ietf.org
https://ww= w.ietf.org/mailman/listinfo/ace

=

--001a113a99d0fd9ae0052aced510-- From nobody Thu Feb 4 01:54:59 2016 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 220991A6F10 for ; Thu, 4 Feb 2016 01:54:57 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 FuwOJVmkFZgI for ; Thu, 4 Feb 2016 01:54:55 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F036A1A6EF4 for ; Thu, 4 Feb 2016 01:54:54 -0800 (PST) Received: by mail-lb0-x22a.google.com with SMTP id bc4so27900637lbc.2 for ; Thu, 04 Feb 2016 01:54:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=to:from:subject:cc:message-id:date:user-agent:mime-version :content-type; bh=1eO+u3CLB8ILXEkq7UTjR9giVj32kiksnRfhuBf4SVo=; b=cYPj41R+ZrYppBI4lfF5myearD9BlG+fn4hqd8K3VSvVhPqXt3uWQkx+1zrmEmNSDM rrzipUT2uoMnSJ20WqTpp+vduiV99XjYn08xy3l1+90zVZvpwR4h2aDLGSziEvI6a1pm oIQVfCSFn/0wzYxtBeoUhpCdrT3E5rjjmlP7XNYN2a8WxwQdaevJCpzRhOmp3yRSTUDa IpBcS5huqjTgYu21fhfr8nA/y4JclpcogQ1PXxzE9UyolppHh9ML2CibfrJnXyM+hXy+ +L2MuDa4DCl0usJKXAredAsWw8DETmzIfiCb5admZYecq7cYUCVX+dwJ4L33hV53cLez 2ttw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:cc:message-id:date:user-agent :mime-version:content-type; bh=1eO+u3CLB8ILXEkq7UTjR9giVj32kiksnRfhuBf4SVo=; b=lCMYmpm1uiCVel+K03vayoOJTxtsqL4KmUMqOZh3aI88RhFg7CXw1z7A4PVc+N1oVO EezQd+BdgfVJ/MBjkYfruup9o5rHE5y2GcIibQ+SiYMo14/729mR2T/iK//I3BdW3KCl 4Oai53XQav+9FJpqlZgZkoBkgdwqT4cvNA4/huF0VQvR4n2Kh/eOKz0hV/X8VHhiOD6w Af1xiR1GhcnHBZLbRkfT2Ln8Bm9OsO8WxuOb5Q5K2YdkNz5srrEt0qkt4yPFtVmMC1d5 83u2EbnqXRkAdMARrkBcoRptKRcwb9v0O9/xZ9AFPlIgIQmrONJvakAJauYQsCoolUKC d+rg== X-Gm-Message-State: AG10YOQBuu/jAjIRE4tBQieMJJ1AkMYwqAbnM5vd7O/dS1pA3dC6USo8iABMXwVvXPKsgvRY X-Received: by 10.112.17.70 with SMTP id m6mr3088057lbd.130.1454579693136; Thu, 04 Feb 2016 01:54:53 -0800 (PST) Received: from Hyperion.suse ([85.235.10.186]) by smtp.gmail.com with ESMTPSA id p124sm1443740lfe.31.2016.02.04.01.54.52 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Feb 2016 01:54:52 -0800 (PST) To: ace@ietf.org From: Ludwig Seitz Message-ID: <56B31FEB.4010204@sics.se> Date: Thu, 4 Feb 2016 10:54:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070808040004070008020206" Archived-At: Cc: oauth@ietf.org Subject: [Ace] Questions about OAuth and DTLS 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, 04 Feb 2016 09:54:57 -0000 This is a cryptographically signed message in MIME format. --------------ms070808040004070008020206 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello list(s), in the process of updating our draft [1] (mainly in reaction to the=20 reviewer's comments) I've come up with a question I'd like to put to the = list (crossposting to OAuth as well, they might have considered that=20 already): Assuming we are using (D)TLS to secure the connection between C and RS,=20 assuming further that we are using proof-of-possession tokens [2], i.e.=20 tokens linked to a key, of which the client needs to prove possession in = order for the RS to accept the token. Do we need to support cases, where the type of key used with DTLS does=20 not match the type of key in the PoP-token? Example: The client uses its raw public key as proof of possession, but the DTLS=20 connection C - RS is secured with a pre-shared symmetric key. Is that a realistic use case? It would simplify the DTLS cases a lot, if I could just require the=20 token and the DTLS session to use the same type of key. For starters we=20 could use DTLS handshake to perform the proof-of-possession. Would there be any security issues with using the PoP key in the DTLS=20 handshake? I'm thinking of using pre-shared symmetric PoP keys as PSK as in RFC4279 = and raw public PoP keys as client-authentication key as in RFC7250. Regards, Ludwig [1] https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ [2] https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02 --=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 9251 http://www.sics.se --------------ms070808040004070008020206 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CtEwggTnMIIDz6ADAgECAhAfP2QWc8z7Bo71GhHCZ7DdMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMTA3MTE1NzM3WhcNMTcwMTA3MTE1NzM3WjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCiG5fxnXbdU0+3qInGZloXB0zZLM6XAu0EmTuCsWOU8eXN lCe37PTURORfLc3te4gCDcG1GrI2AuWR9MvlcYddMZt5y0T5BVWIu534vVJtG3QCuEYRJOTW B6RWQfK+dIPpZsNhgEQkYLjTHYoCu58gP0pfxNie1X7D+RxeQcq+ynNmyFdsxc2mI+dQqBKq 4zTsCNP4/jpSuovXTn8hEbbR8zkVQ2v/Gx+EO8oMIvkIEUYzkMxe3E9A7dq5DwotRDzP+y3g C4DCtI0tfIUtFjx18Pb5UMNUKZjitrOpXfheEz/igxziydri8bYpx4qGU9CNX+MvQG7Ogqju XKfQhUTTAgMBAAGjggGuMIIBqjALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFBMb8zf+BJ13fxqEl9gYiwxZ4hpmMB8G A1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCugKYYn aHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCBDmx1 ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNV HSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAbgRzIj1s9U5kpXodti5kdj3ztjPb oz4pz8zNwn3qPUW8c3Zd40IFe+R5hRDuIm2aa//fmwop2mLM3+5/LnSnacaDnRfE7pP3NgqX XUuuZf9TtMLU6RUh2Z9JKs0IzWKALPhoLgnCsbtYDrF4QAoVqeNV79Lb6a3r6KdB/xFErbee OkZk/iw9HCr/jnvysYjfFQcBounseJS3JG4RNIuDpfsWPupQSAhl4s0akaakiwqOHCU7x0Ra rbCN+bg+6R5FEtSouIh53Z04JmI7LU3leo/AseQiUpJ6HqQNJYjnsCw8DDbijNhH41ZZKrvB rKMfVvlCH9VqrKW4kPGajKMEJDCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJ KoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0 YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIx NjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNV BAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENv bSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL19 2vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk 9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89V LnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZ ZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8U lVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4G A1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/ BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9z ZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFy dHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2Nh LmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRA W6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4St DwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y 5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bj yOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfC BJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSi F3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odh QJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfr Bzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4W VWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9Vyrw MdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2de oprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAfP2QWc8z7Bo71 GhHCZ7DdMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNjAyMDQwOTU0NTFaMC8GCSqGSIb3DQEJBDEiBCBq2/j5MPSC67Po uYUbH0vHF5TEnrbAvuyTr1fN6k5ZXjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQHz9kFnPM+waO9RoRwmew3TCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQ Hz9kFnPM+waO9RoRwmew3TANBgkqhkiG9w0BAQEFAASCAQAjh+/cVOx67wDNd4qp7b1RyL5s 9LHFcbDWI7Xaq5q49QsZCHOWeQwXtHU0R16awz2ueeNG3UvTLYHhk2ZnczEjBG6M8I3KpRtD MQXc5z0Dz69/IZCHylvsrx8Un3DQFQ0AsrG36tzma++dctJGQ2duRkJqAbVI2zjiApJp3kV6 iZjfMTPRyNx1PghDZHHvffRNREEqhLT6q059q53SwjhdSJijLeChPggKiTLf41MXODGp4DpA dcyo4mZVDKfdBoZmy/XxG1ovL6zWBY5Z89WEZ0iM6fEnS0DBctp/Ou4KegBI+A2oG5Dd1Hn4 PbSrQQyBDkW8Cz6lCbgwWmmCRLVRAAAAAAAA --------------ms070808040004070008020206-- From nobody Thu Feb 4 06:31:49 2016 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 4A3901B304B; Thu, 4 Feb 2016 06:31:48 -0800 (PST) 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, RP_MATCHES_RCVD=-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 iWFwVt_9H9wj; Thu, 4 Feb 2016 06:31:45 -0800 (PST) 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 C9B211B304F; Thu, 4 Feb 2016 06:31:44 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A1DA82009E; Thu, 4 Feb 2016 09:40:38 -0500 (EST) Received: from obiwan.sandelman.ca (ip6-localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4544363751; Thu, 4 Feb 2016 09:31:43 -0500 (EST) From: Michael Richardson To: Ludwig Seitz In-Reply-To: <56B31FEB.4010204@sics.se> References: <56B31FEB.4010204@sics.se> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 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 Archived-At: Cc: oauth@ietf.org, ace@ietf.org Subject: Re: [Ace] Questions about OAuth and DTLS 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, 04 Feb 2016 14:31:48 -0000 --=-=-= Content-Type: text/plain Ludwig Seitz wrote: > Assuming we are using (D)TLS to secure the connection between C and RS, > assuming further that we are using proof-of-possession tokens [2], > i.e. tokens linked to a key, of which the client needs to prove possession in > order for the RS to accept the token. > Do we need to support cases, where the type of key used with DTLS does not > match the type of key in the PoP-token? > Example: > The client uses its raw public key as proof of possession, but the DTLS > connection C - RS is secured with a pre-shared symmetric key. > Is that a realistic use case? Before I agree that it's unrealistic, I think it's worth going out of charter scope and ask how much these two credentials were created/distributed. I think that in this case, the pre-shared symmetric key is initialized through some out-of-band (perhaps human mediated?) process, while the raw public key did not need any other pre-arrangement. So my question is then: could the out-of-band process have pre-exchanged the raw public key (and the RS's key/certificate!) as well? > It would simplify the DTLS cases a lot, if I could just require the token and > the DTLS session to use the same type of key. For starters we could use DTLS > handshake to perform the proof-of-possession. I agree, that it would be better. (I'm also concerned that we not fail into where IKEv1 did: with weak PSK being the only interoperable mechanism...) > Would there be any security issues with using the PoP key in the DTLS > handshake? > I'm thinking of using pre-shared symmetric PoP keys as PSK as in RFC4279 and > raw public PoP keys as client-authentication key as in > RFC7250. Just because I had to look it up... 4279 - Pre-Shared Key Ciphersuites for Transport Layer Security 7250 - Using Raw Public Keys in Transport Layer Security I thought perhaps it was some more specific mechanism... -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVrNgy4CLcPvd0N1lAQK/jgf+KiuIkxj2uzkPgO5cWG/e4uFIqtYwYMDG fNOBKy70i8p44l4ENyQFII32KjKr6u87KW8UTcOXza13HfAmyunrW3j64DsG/0Zo CbBDT6Wp9DA54JroYtgMn5u7A5YCSdEG/U9Hi8C37gsuSDJnztEFWjhq1jqMDUqY 8fzMS4iwqWUu0ZPBvtFWDzoYQS8lnz89lMpXdYTJj3RhFEHxEDu25+GrBYm4Br3F TL1a5TZ2Y0bijOFBIYISVc8dGH8Ya1Zxy/T0XVaj5gLdeLBuv1oqiFMJzPkKQe9n /PTouDoJKOHFT/oV28vrVCDAR6mXKxlsFe3Ay/6kblPLsN4mSiGBvg== =3+HF -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 4 06:58:21 2016 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 BA0971B30CE for ; Thu, 4 Feb 2016 06:58:19 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=unavailable 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 9WWCPINx-NJi for ; Thu, 4 Feb 2016 06:58:17 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 598E11B30C8 for ; Thu, 4 Feb 2016 06:58:17 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id 78so37795922lfy.3 for ; Thu, 04 Feb 2016 06:58:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=bSwfiVYSEHgTJcF/LzxmXLv7+6PoZ7mCOsO+sioo55Q=; b=u6IofZPEAIAv0fEFTqwaJDO/JOcin+xBZa8mjKmUllhxx5HRsdXrnSXfwEOeXlQ1L8 B+3oroXtTYJOq6nMIaTlVD5xh+OG6C4xqOf8x8hs/RyuulCfSFMn4NYipVmsxecmM8hg ZcYjTa+NE3EvUlh6doeKb2h4I+yzpOI9T4rkZPmxcBCWIT5QYl2vsRCWUMNw3aAgxNLI 1qALGKhF1fBmludcI3f1f6teZ6iBehQ4Z97deGn7vOPQCxvmDsAstgv6U5QdnxDctx8v boqbkIU+CEXDvOo3AvVwftsoOOL4pnMSoZ1AtZ0c7CSK6HTVaUz/IHAaNBRwyhe0a0q7 rnYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=bSwfiVYSEHgTJcF/LzxmXLv7+6PoZ7mCOsO+sioo55Q=; b=QkksVd69HUaTuC/LdFumtlEyx1w9eTOXbwAW/gIdlTM1XZfrjtqH8JSyrxHvImUoqR e0U9hF/6aFofjthoufAvYH3EBr4p0c0hu4gTezLfwmhoIxSq2X/zPfWYJvgnId8pXLDo WreCj9p4/EtxBDoecpPjA2nh8UfhqqZNeg+JhKl6kQlUtiupmX272ZeV5SWMiCq+S2tN 3NJF0blUVxt+nZTPIfELUVpeQl7WcDYObKdzOcatTMNIHtYiwjJyMbmPu2nYN/5vBrUP mcGjVFaD/dlKduiWo0AlVzfujuHYD6AmEMBQUWIcy17MVJAYi0sefKul8zRGfz8tYVQD F+gg== X-Gm-Message-State: AG10YOSqVEN1QrQk+/uXfJH57sFn8vvMqnubkocdPbHD7DryV7e3NI6MO3kvH7067ysoy+Vj X-Received: by 10.25.32.16 with SMTP id g16mr3101681lfg.82.1454597895517; Thu, 04 Feb 2016 06:58:15 -0800 (PST) Received: from Hyperion.suse (host-95-195-150-10.mobileonline.telia.com. [95.195.150.10]) by smtp.gmail.com with ESMTPSA id rp10sm1580917lbb.13.2016.02.04.06.58.14 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Feb 2016 06:58:15 -0800 (PST) To: Michael Richardson References: <56B31FEB.4010204@sics.se> <16330.1454596303@obiwan.sandelman.ca> From: Ludwig Seitz Message-ID: <56B36703.8060305@sics.se> Date: Thu, 4 Feb 2016 15:58:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <16330.1454596303@obiwan.sandelman.ca> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080207050001000001060200" Archived-At: Cc: oauth@ietf.org, ace@ietf.org Subject: Re: [Ace] Questions about OAuth and DTLS 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, 04 Feb 2016 14:58:19 -0000 This is a cryptographically signed message in MIME format. --------------ms080207050001000001060200 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Thank you Michael! Comments inline. /Ludwig On 02/04/2016 03:31 PM, Michael Richardson wrote: > > Ludwig Seitz wrote: > > Assuming we are using (D)TLS to secure the connection between C = and RS, > > assuming further that we are using proof-of-possession tokens [2= ], > > i.e. tokens linked to a key, of which the client needs to prove = possession in > > order for the RS to accept the token. > > > Do we need to support cases, where the type of key used with DTL= S does not > > match the type of key in the PoP-token? > > > Example: > > > The client uses its raw public key as proof of possession, but t= he DTLS > > connection C - RS is secured with a pre-shared symmetric key. > > > Is that a realistic use case? > > Before I agree that it's unrealistic, I think it's worth going out of c= harter > scope and ask how much these two credentials were created/distributed. > > I think that in this case, the pre-shared symmetric key is initialized > through some out-of-band (perhaps human mediated?) process, while the r= aw > public key did not need any other pre-arrangement. Actually even the raw public key needs to be provisioned out-of-band to=20 those supposed to trust it for authentication. > > So my question is then: could the out-of-band process have pre-exchange= d the > raw public key (and the RS's key/certificate!) as well? > Short answer: Yes but only to the AS not to the client(s). Long answer: I am laboring under the assumption that the AS not only=20 provides the OAuth token and the corresponding PoP key to the client,=20 but also some information on the communication security protocols that=20 the RS supports. Furthermore the AS facilitates the establishment of a=20 security context between client and RS by providing things such as a=20 (D)TLS-PSK or the RS's raw public key, depending on the (D)TLS mode that = the RS is going to support. Thus individual clients would not,=20 a-priori, know the raw public key of a RS, but would be able to get that = information from the AS. --=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 9251 http://www.sics.se --------------ms080207050001000001060200 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CtEwggTnMIIDz6ADAgECAhAfP2QWc8z7Bo71GhHCZ7DdMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMTA3MTE1NzM3WhcNMTcwMTA3MTE1NzM3WjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCiG5fxnXbdU0+3qInGZloXB0zZLM6XAu0EmTuCsWOU8eXN lCe37PTURORfLc3te4gCDcG1GrI2AuWR9MvlcYddMZt5y0T5BVWIu534vVJtG3QCuEYRJOTW B6RWQfK+dIPpZsNhgEQkYLjTHYoCu58gP0pfxNie1X7D+RxeQcq+ynNmyFdsxc2mI+dQqBKq 4zTsCNP4/jpSuovXTn8hEbbR8zkVQ2v/Gx+EO8oMIvkIEUYzkMxe3E9A7dq5DwotRDzP+y3g C4DCtI0tfIUtFjx18Pb5UMNUKZjitrOpXfheEz/igxziydri8bYpx4qGU9CNX+MvQG7Ogqju XKfQhUTTAgMBAAGjggGuMIIBqjALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFBMb8zf+BJ13fxqEl9gYiwxZ4hpmMB8G A1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCugKYYn aHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCBDmx1 ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNV HSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAbgRzIj1s9U5kpXodti5kdj3ztjPb oz4pz8zNwn3qPUW8c3Zd40IFe+R5hRDuIm2aa//fmwop2mLM3+5/LnSnacaDnRfE7pP3NgqX XUuuZf9TtMLU6RUh2Z9JKs0IzWKALPhoLgnCsbtYDrF4QAoVqeNV79Lb6a3r6KdB/xFErbee OkZk/iw9HCr/jnvysYjfFQcBounseJS3JG4RNIuDpfsWPupQSAhl4s0akaakiwqOHCU7x0Ra rbCN+bg+6R5FEtSouIh53Z04JmI7LU3leo/AseQiUpJ6HqQNJYjnsCw8DDbijNhH41ZZKrvB rKMfVvlCH9VqrKW4kPGajKMEJDCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJ KoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0 YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIx NjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNV BAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENv bSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL19 2vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk 9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89V LnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZ ZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8U lVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4G A1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/ BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9z ZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFy dHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2Nh LmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRA W6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4St DwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y 5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bj yOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfC BJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSi F3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odh QJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfr Bzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4W VWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9Vyrw MdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2de oprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAfP2QWc8z7Bo71 GhHCZ7DdMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNjAyMDQxNDU4MTFaMC8GCSqGSIb3DQEJBDEiBCD72uL/Mu+gSutw pHXSnrOchormeDxSNm46uOVXY+o5yDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQHz9kFnPM+waO9RoRwmew3TCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQ Hz9kFnPM+waO9RoRwmew3TANBgkqhkiG9w0BAQEFAASCAQBdF/wHMJ9JREH7cBlZjOHSaliB h/eGZXfAzLUQg4NNAT2uU6V2tbyFflIVjumd0SHl265q/rZWRNReBZGQfqMDoqALzYEE2qcF rDQonp+gSbalwuEK5x21f7mBjfsaCiHMFAhP8TW48KMUpyPSBRP3xduy81lmRA4KZZmpaKrm V6R1PGRfiiZxY8ls2VAOE6ZO1tJKEYI8TsZXHJpRAnbI5laQiQYgctlXJ92DfEJx8Ob0Hq/g ggqzV/hGbk9y4sxxfmwHX5ApnLF6xp2jXkxCWpUJqtsPdPEg/+w5FRDK4HyuUzag9iyhTqza RdPw02CnaGCFFXFBAPYYpqwsqUQ+AAAAAAAA --------------ms080207050001000001060200-- From nobody Thu Feb 4 16:01:15 2016 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 5A5081B3245 for ; Thu, 4 Feb 2016 08:14:36 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 7Qm0iAmF7rVj for ; Thu, 4 Feb 2016 08:14:34 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D1641B3242 for ; Thu, 4 Feb 2016 08:14:34 -0800 (PST) Received: by mail-qg0-x231.google.com with SMTP id y9so40616950qgd.3 for ; Thu, 04 Feb 2016 08:14:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SrisFAo+ThRZoPS1TnHl121cEBpTg174ipMwDqKibTY=; b=YaqRfeHIkpT/JT0dtsLf3V6aFuSn88I/wuuoBzpVfZ1g+7V2gkEyprdP2Dh9mRL9/X 8setkbN5zYQHkMbtXg8r2kS52CbvbfISBuczFR/gYvBzStIo0/cRE2fDocIPXLr9aMXQ vEjrjI4igyN67VKhG8fBwydUBLlxQkL1SeSEnptqNu7URwnnbkY6qeC29no/K8v+rBey gZJQNpN4qi+JDzY++KoBeVkYda35D14oeYJRA03xC1W/i5API1hBiihkeq6Hm+2i3RSK Qd6mTowBkPdPMhfD/WlO7vcH3cW7G6yCaFZgt1fq9y+Q7R0QtT/mp1F9+ScvBEVXUhex mkNw== 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=SrisFAo+ThRZoPS1TnHl121cEBpTg174ipMwDqKibTY=; b=EcBoCwXe/E4gAbpzBFq6Bd/ybaFdxinl4nA/4D5iycV6n85L5C/A3ZpNzRcwGA2MN0 nCVT1u1naXN6PRLS40FWMZlXwAfpACfp2oo9iDrry/+6ONCJYT9aA38pPg1RTK3dy1Ut HUxBNWcYKegpO/0IIn86OCFH+SJx739C9XYndBbpNodtQ0fkwuduVamAjhimlUsPMNQS kI6NbT2fEY90Q81QN1sQARaE/RKzj4/NyIzWzlu3zQSmpIxoAmQjoiinIW/Dk1Sk1bxj 6R0gOKxp0ZdPs5UkOax1V+gDdSQXejsDX0qm8cQjbfo7ZIMwYJOCoTo+dWAiVhikJh2U 7q5w== X-Gm-Message-State: AG10YOQ2lsXp3TZhC/EU064kjcVRmyeFFn+GnviMLu/rXx+GD7F5tdJY1vfYC2+ZOlsdvQ== X-Received: by 10.140.19.148 with SMTP id 20mr10046266qgh.60.1454602473421; Thu, 04 Feb 2016 08:14:33 -0800 (PST) Received: from [192.168.8.100] ([181.202.238.84]) by smtp.gmail.com with ESMTPSA id 47sm5470468qgj.11.2016.02.04.08.14.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 04 Feb 2016 08:14:32 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: <56B36703.8060305@sics.se> Date: Thu, 4 Feb 2016 13:14:28 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <36D7AE64-51CB-4437-AC28-9F912CD6B0D9@ve7jtb.com> References: <56B31FEB.4010204@sics.se> <16330.1454596303@obiwan.sandelman.ca> <56B36703.8060305@sics.se> To: Ludwig Seitz X-Mailer: Apple Mail (2.3112) Archived-At: X-Mailman-Approved-At: Thu, 04 Feb 2016 16:01:14 -0800 Cc: Michael Richardson , oauth@ietf.org, ace@ietf.org Subject: Re: [Ace] [OAUTH-WG] Questions about OAuth and DTLS 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, 04 Feb 2016 16:14:36 -0000 In https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution The proof key is included in the access token or provided out of band.=20= The proof mechanism to the RS is what would determine if the key type = needs to match DTLS . =20 If the proof is DTLS then they would need to match. =20 POP will have different presentment mechanisms such as signing the = payload or binding to mutual TLS client auth. For a symmetric key you would encrypt it in the Access token with a Key = known to the RS so only the token decryption key needs to be managed out = of band. John B. > On Feb 4, 2016, at 11:58 AM, Ludwig Seitz wrote: >=20 > Thank you Michael! Comments inline. >=20 > /Ludwig >=20 > On 02/04/2016 03:31 PM, Michael Richardson wrote: >>=20 >> Ludwig Seitz wrote: >> > Assuming we are using (D)TLS to secure the connection between C = and RS, >> > assuming further that we are using proof-of-possession tokens = [2], >> > i.e. tokens linked to a key, of which the client needs to prove = possession in >> > order for the RS to accept the token. >>=20 >> > Do we need to support cases, where the type of key used with = DTLS does not >> > match the type of key in the PoP-token? >>=20 >> > Example: >>=20 >> > The client uses its raw public key as proof of possession, but = the DTLS >> > connection C - RS is secured with a pre-shared symmetric key. >>=20 >> > Is that a realistic use case? >>=20 >> Before I agree that it's unrealistic, I think it's worth going out of = charter >> scope and ask how much these two credentials were = created/distributed. >>=20 >> I think that in this case, the pre-shared symmetric key is = initialized >> through some out-of-band (perhaps human mediated?) process, while the = raw >> public key did not need any other pre-arrangement. >=20 > Actually even the raw public key needs to be provisioned out-of-band = to those supposed to trust it for authentication. >=20 >>=20 >> So my question is then: could the out-of-band process have = pre-exchanged the >> raw public key (and the RS's key/certificate!) as well? >>=20 >=20 > Short answer: Yes but only to the AS not to the client(s). >=20 > Long answer: I am laboring under the assumption that the AS not only = provides the OAuth token and the corresponding PoP key to the client, = but also some information on the communication security protocols that = the RS supports. Furthermore the AS facilitates the establishment of a = security context between client and RS by providing things such as a = (D)TLS-PSK or the RS's raw public key, depending on the (D)TLS mode that = the RS is going to support. Thus individual clients would not, a-priori, = know the raw public key of a RS, but would be able to get that = information from the AS. >=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 9251 > http://www.sics.se >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Feb 5 00:30:49 2016 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 542691A8A93 for ; Fri, 5 Feb 2016 00:30:47 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=unavailable 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 2yBL5UjFFrYa for ; Fri, 5 Feb 2016 00:30:45 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 076E01A8A28 for ; Fri, 5 Feb 2016 00:30:45 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id j78so52478449lfb.1 for ; Fri, 05 Feb 2016 00:30:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=L8ITAPUEg1RywruAPjoo8eet0Qy+oNFMUI34biTDbNE=; b=GvhGGmA2kK0HYLdsczdNwhRHdKlFyOOMuqo0SekGVfLYsSZrLhJhR05IwSWC2rqDZw tcT6Oy6I6JBzsJ3yi1yhWZyCTgCoFPLk1Mlo0g5gLNcOunpxpdjghA65AlM36sAxR3lb da3QEf8mKiwKObDl2FS3GkGpfzNeZZd9E+Yh9M+3FEtp+xGzJ//PF6QYjd7RXHlfxeDG IYiXZwv4jb53x4F0ukv6kGWIy1tBE5E8NWu/xyGhDNcPseUlTb3jghCzbS4WyDPeeTPH xVzqWyiSrcKXk2eFr9qMj9zG3oBarwydxt2q4SAsVa1qeGnTlWFFZDepRDin+Gggn3Xd uUpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=L8ITAPUEg1RywruAPjoo8eet0Qy+oNFMUI34biTDbNE=; b=ZXACjnHHHfiMY4hKLFXHIPpwIzgNtnyHArQllDNpWJxPSWKwp0md1AIBBatslRys/0 kEUl6b2E8NFuyanbz9wUuIdXdObQJ4DEPfhJoAWxBm+WZyj0obbNNerdyOgWUynQT8tF pqCDQ9p1DNVp3194MLGV/az0Qrbf1OkUZFYhjQzZL0zdGY5coEwYqrms/Cx3Oecjgio5 bnBO/Wrs2MyCBS9YMG/B846fYaU94GHvg4tXxFmG2b85za33vKT/00A09PLVrxze06JW PmYphN/yacc6E2skj/AuX3Ltsf7ymzuIbDE0gFeKwY7VpqlrJvAqKj7yor2V5meq/5wM j9hg== X-Gm-Message-State: AG10YOSdfinnot869tFJwRFvz2549AlMyshDmMbp4MBijZIG53CP1Fw2BRMcsX4WDHuqxyge X-Received: by 10.25.18.25 with SMTP id h25mr4504220lfi.165.1454661042921; Fri, 05 Feb 2016 00:30:42 -0800 (PST) Received: from Hyperion.suse ([85.235.10.186]) by smtp.gmail.com with ESMTPSA id 87sm2155732lft.20.2016.02.05.00.30.41 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Feb 2016 00:30:42 -0800 (PST) To: John Bradley References: <56B31FEB.4010204@sics.se> <16330.1454596303@obiwan.sandelman.ca> <56B36703.8060305@sics.se> <36D7AE64-51CB-4437-AC28-9F912CD6B0D9@ve7jtb.com> From: Ludwig Seitz Message-ID: <56B45DA7.6040408@sics.se> Date: Fri, 5 Feb 2016 09:30:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <36D7AE64-51CB-4437-AC28-9F912CD6B0D9@ve7jtb.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020008060204040207000408" Archived-At: Cc: Michael Richardson , oauth@ietf.org, ace@ietf.org Subject: Re: [Ace] [OAUTH-WG] Questions about OAuth and DTLS 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, 05 Feb 2016 08:30:47 -0000 This is a cryptographically signed message in MIME format. --------------ms020008060204040207000408 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 02/04/2016 05:14 PM, John Bradley wrote: > In https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution > > The proof key is included in the access token or provided out of band. > > The proof mechanism to the RS is what would determine if the key type n= eeds to match DTLS . > If the proof is DTLS then they would need to match. > Thank you John, this leads me to another question (maybe I just missed=20 it in the PoP drafts): Who decides what the proof mechanism should be?=20 How is the proof mechanism signaled to the client (the client may=20 support several proof mechanisms)? /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 9251 http://www.sics.se --------------ms020008060204040207000408 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CtEwggTnMIIDz6ADAgECAhAfP2QWc8z7Bo71GhHCZ7DdMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMTA3MTE1NzM3WhcNMTcwMTA3MTE1NzM3WjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCiG5fxnXbdU0+3qInGZloXB0zZLM6XAu0EmTuCsWOU8eXN lCe37PTURORfLc3te4gCDcG1GrI2AuWR9MvlcYddMZt5y0T5BVWIu534vVJtG3QCuEYRJOTW B6RWQfK+dIPpZsNhgEQkYLjTHYoCu58gP0pfxNie1X7D+RxeQcq+ynNmyFdsxc2mI+dQqBKq 4zTsCNP4/jpSuovXTn8hEbbR8zkVQ2v/Gx+EO8oMIvkIEUYzkMxe3E9A7dq5DwotRDzP+y3g C4DCtI0tfIUtFjx18Pb5UMNUKZjitrOpXfheEz/igxziydri8bYpx4qGU9CNX+MvQG7Ogqju XKfQhUTTAgMBAAGjggGuMIIBqjALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFBMb8zf+BJ13fxqEl9gYiwxZ4hpmMB8G A1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCugKYYn aHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCBDmx1 ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNV HSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAbgRzIj1s9U5kpXodti5kdj3ztjPb oz4pz8zNwn3qPUW8c3Zd40IFe+R5hRDuIm2aa//fmwop2mLM3+5/LnSnacaDnRfE7pP3NgqX XUuuZf9TtMLU6RUh2Z9JKs0IzWKALPhoLgnCsbtYDrF4QAoVqeNV79Lb6a3r6KdB/xFErbee OkZk/iw9HCr/jnvysYjfFQcBounseJS3JG4RNIuDpfsWPupQSAhl4s0akaakiwqOHCU7x0Ra rbCN+bg+6R5FEtSouIh53Z04JmI7LU3leo/AseQiUpJ6HqQNJYjnsCw8DDbijNhH41ZZKrvB rKMfVvlCH9VqrKW4kPGajKMEJDCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJ KoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0 YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIx NjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNV BAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENv bSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL19 2vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk 9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89V LnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZ ZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8U lVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4G A1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/ BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9z ZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFy dHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2Nh LmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRA W6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4St DwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y 5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bj yOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfC BJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSi F3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odh QJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfr Bzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4W VWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9Vyrw MdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2de oprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAfP2QWc8z7Bo71 GhHCZ7DdMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNjAyMDUwODMwMzFaMC8GCSqGSIb3DQEJBDEiBCADXMyDDiIYRwVx I332Xwx4hhZ2+4O8UIKeZm9vkinT4zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQHz9kFnPM+waO9RoRwmew3TCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQ Hz9kFnPM+waO9RoRwmew3TANBgkqhkiG9w0BAQEFAASCAQA9qCB1PDMHbxQauDI5WHnm9HVc A58J0QduGBalt9gkD4QL2o9LPExhZqHjphUe0k8/0p/6ufxgkB8+Uyf8LJ8dRjLeKokC4jdN KDA1uUrQ6Qfdn+XLZ0ox50IIM+pbn/suKUKrXT0riPCQKvsaxxCWU8RrUZIlK8EuQAEGxkns GR3qdjD8vnR/DEZc8CQg09LFhRiRhsYBPbh7au408euw7lF2qUc78kgdZgBAYW4uZvRSHF+M 50GEmM4goeOlzaDreRsGkl7k4G30qTBu/5hjXe6iYwCauDGgHGDG04XrvAni1+/gZ5cVHyiZ v9Jc/mow2MoGf7KOWLwfnxN/tFojAAAAAAAA --------------ms020008060204040207000408-- From nobody Fri Feb 5 04:38:19 2016 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 244671B37EE for ; Fri, 5 Feb 2016 04:38:18 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 MrqTRh4hyqwO for ; Fri, 5 Feb 2016 04:38:16 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A58491B37D6 for ; Fri, 5 Feb 2016 04:38:15 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id 78so56198510lfy.3 for ; Fri, 05 Feb 2016 04:38:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=QkYOBwLrHib4ZQdpsjKagd0/SIOq0i3BQRrmQWkyWVQ=; b=cKvFONyWb+FEUteB47Be8x1BZ9pftxOmplslNwG6GAJYg18CGDUIehwcqovzoU9y4q FfepuywcjRqNVmBi/ruKDP0zFhUovbT4Id5+2FBF6U4kBT6+aWGBDedK7jcG+YmWjf6M 0p7F+NA7Wau20cOTuL/8ER0XcFoUJa6eAaYiBGczvJ0nLhf0mbJFO6J+TcKJQ5lCePTX lKUEeW/O+du4eEQREZX2eVkQYrm9y4tQp4jhYtMr8eRKWctS+5WBOVpDGeEuKyqgJ9rT U2BJa6PF0g9sNxNvFpV35EiIQLh46X/+jyOe4h9S27gcL4dOQVqq6jT+Zx/X6EknKrBq Op5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=QkYOBwLrHib4ZQdpsjKagd0/SIOq0i3BQRrmQWkyWVQ=; b=UB33sOe+z7Ayp93ugond1ScfYTPMoMgj6HfuzKlYnqbNBbFf3pF8px0OVJ9AyI68+u wvws3QR1em22vRvq6c9bUpW9H0OC5LNHpnbi42mXIYFQkhPHqXJghE5pB53a8oTBdDCT JHhJyFIszYp572DnPCJoLGd/zTBvAdICm/1X8GBk7YlDzV/DQ6cefob55aiaN3ddo32Z eFgGyOOi2XJp6nybv60AiP4CjYc1wnwKr3ERB/+GiD5Wq8MhuKCK4/SP3rucLUucbGNz wOp23GM8UOYkwaANiWBcG7zPhlemBTvVzXxQ6hgto2ZVfoegILmZji7Id7FbsZMEHZ7W PnOA== X-Gm-Message-State: AG10YORh5A9KKlT9inh3DHH1SZkR2ES9upX6+IdmCFL4jfHNtmUtc/3/USkL3XzJGvXYm6V0 X-Received: by 10.25.29.193 with SMTP id d184mr5930091lfd.28.1454675893938; Fri, 05 Feb 2016 04:38:13 -0800 (PST) Received: from Hyperion.suse ([85.235.10.186]) by smtp.gmail.com with ESMTPSA id ze8sm2217018lbb.45.2016.02.05.04.38.12 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Feb 2016 04:38:13 -0800 (PST) To: Carsten Bormann References: <56AF0EA9.40309@sics.se> <56AF2C89.7040102@tzi.org> <56AF37AF.2020608@sics.se> <56AF3C73.3050806@tzi.org> From: Ludwig Seitz Message-ID: <56B497B4.5090102@sics.se> Date: Fri, 5 Feb 2016 13:38:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56AF3C73.3050806@tzi.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050703060201000900060506" Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] CoAP option for Access token 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, 05 Feb 2016 12:38:18 -0000 This is a cryptographically signed message in MIME format. --------------ms050703060201000900060506 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 02/01/2016 12:07 PM, Carsten Bormann wrote: >> The underlying assumption is that the token is a proof-of-possession >> token, i.e. that it is associated with a key (symmetric or asymmetric)= >> that the client possesses and that the RS can verify possession of. >> >> The binding of the token to a request happens by either using that key= >> to establish session security (e.g. as PSK or RPK for DTLS), or by usi= ng >> that key in an object security protocol and using that protocol to >> secure the request. > > OK, both kinds of communication security (via DTLS or via an "object > security" protocol above DTLS) establish a security session that can be= > bound to, using the PoP token once, not per request. > >> Could you exemplify what you mean with "by using a RESTful >> mechanism bound to the connection after connection establishment" I'm >> not sure I'm following you here. > > As in > > POST /authorize > > (Note that since we are in an authenticated session, this is just about= > establishing additional authorization, not about re-authenticating > either side. The server needs to bind that authorization to the sessio= n.) > > Look, Ma, no option :-) > (Except for protecting the message in any "object security" session, if= > needed.) > > Gr=C3=BC=C3=9Fe, Carsten > Question to the list: in draft-ietf-ace-oauth-authz the default way to=20 transfer authorization tokens C-->RS is POSTing it to an authorization=20 resource at the RS (identical to what Carsten suggests here). We also discuss some alternatives, optimized for specific situations in=20 appendix C: 1. Using the TLS supplemental data extension [RFC4680] with TLS or DTLS 2. Using a CoAP option (for very small tokens, e.g. reference tokens) Do we need these options? These having such options means that we have to specify some signaling=20 from the AS to the client, telling it which token transfer method to use.= /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 9251 http://www.sics.se --------------ms050703060201000900060506 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CtEwggTnMIIDz6ADAgECAhAfP2QWc8z7Bo71GhHCZ7DdMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMTA3MTE1NzM3WhcNMTcwMTA3MTE1NzM3WjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCiG5fxnXbdU0+3qInGZloXB0zZLM6XAu0EmTuCsWOU8eXN lCe37PTURORfLc3te4gCDcG1GrI2AuWR9MvlcYddMZt5y0T5BVWIu534vVJtG3QCuEYRJOTW B6RWQfK+dIPpZsNhgEQkYLjTHYoCu58gP0pfxNie1X7D+RxeQcq+ynNmyFdsxc2mI+dQqBKq 4zTsCNP4/jpSuovXTn8hEbbR8zkVQ2v/Gx+EO8oMIvkIEUYzkMxe3E9A7dq5DwotRDzP+y3g C4DCtI0tfIUtFjx18Pb5UMNUKZjitrOpXfheEz/igxziydri8bYpx4qGU9CNX+MvQG7Ogqju XKfQhUTTAgMBAAGjggGuMIIBqjALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFBMb8zf+BJ13fxqEl9gYiwxZ4hpmMB8G A1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCugKYYn aHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCBDmx1 ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNV HSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAbgRzIj1s9U5kpXodti5kdj3ztjPb oz4pz8zNwn3qPUW8c3Zd40IFe+R5hRDuIm2aa//fmwop2mLM3+5/LnSnacaDnRfE7pP3NgqX XUuuZf9TtMLU6RUh2Z9JKs0IzWKALPhoLgnCsbtYDrF4QAoVqeNV79Lb6a3r6KdB/xFErbee OkZk/iw9HCr/jnvysYjfFQcBounseJS3JG4RNIuDpfsWPupQSAhl4s0akaakiwqOHCU7x0Ra rbCN+bg+6R5FEtSouIh53Z04JmI7LU3leo/AseQiUpJ6HqQNJYjnsCw8DDbijNhH41ZZKrvB rKMfVvlCH9VqrKW4kPGajKMEJDCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJ KoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0 YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIx NjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNV BAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENv bSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL19 2vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk 9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89V LnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZ ZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8U lVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4G A1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/ BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9z ZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFy dHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2Nh LmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRA W6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4St DwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y 5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bj yOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfC BJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSi F3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odh QJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfr Bzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4W VWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9Vyrw MdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2de oprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAfP2QWc8z7Bo71 GhHCZ7DdMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNjAyMDUxMjM4MTJaMC8GCSqGSIb3DQEJBDEiBCAcdagbUohPetWn dM6JNkiaBzntwb2hhTohq8J6BXFlqjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQHz9kFnPM+waO9RoRwmew3TCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQ Hz9kFnPM+waO9RoRwmew3TANBgkqhkiG9w0BAQEFAASCAQAQKcnPI6jARxDt5t+crWltMaIY /FKlm6moqrxxwIatVQTZ9EuuNCcwObr0Royauxz149rE60+pq9c6o8AFRluJReaF0VsR9nU6 QKc8XfXMy/7EgQk/HWqjF3CeW/thPIA1OuLFUwx8zFwDIwbMX+SD9Z1m3cvSAQlv0GKy6bSN 0FIq6KUEUfg7tvzHK8yDts7o8PzENX/BkZy4/3ROaTkWGY2dbhJjJi1bb3liTzEV/HxRKvep 6U9Y+wdgtGQn9rMEix0lTQ3SOrieZd9Gz360NN5GEu6ce1SquSau3ylgL5ZVJTAyx4GJP3Hl Nn6Aj/513heKZL8D4p/TTiiBXPpWAAAAAAAA --------------ms050703060201000900060506-- From nobody Fri Feb 5 05:53:11 2016 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 3F6021B3906 for ; Fri, 5 Feb 2016 05:53:10 -0800 (PST) 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 CQTPuSOBtWms for ; Fri, 5 Feb 2016 05:53:08 -0800 (PST) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82781B3904 for ; Fri, 5 Feb 2016 05:53:07 -0800 (PST) Received: from mfilter25-d.gandi.net (mfilter25-d.gandi.net [217.70.178.153]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 64484FB887; Fri, 5 Feb 2016 14:53:06 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter25-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter25-d.gandi.net (mfilter25-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id M_BZ-w4Qn-Au; Fri, 5 Feb 2016 14:53:04 +0100 (CET) X-Originating-IP: 134.102.157.111 Received: from nar.local (unknown [134.102.157.111]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 3119AFB89F; Fri, 5 Feb 2016 14:53:03 +0100 (CET) Message-ID: <56B4A93D.7040000@tzi.org> Date: Fri, 05 Feb 2016 14:53:01 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Ludwig Seitz References: <56AF0EA9.40309@sics.se> <56AF2C89.7040102@tzi.org> <56AF37AF.2020608@sics.se> <56AF3C73.3050806@tzi.org> <56B497B4.5090102@sics.se> In-Reply-To: <56B497B4.5090102@sics.se> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] CoAP option for Access token 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, 05 Feb 2016 13:53:10 -0000 Using credentials for creating DTLS connections has the advantage that you get mutual authentication at the constrained layer pretty much for free. The disadvantage is that upgrading authorizations requires a separate mechanism (e.g., POST). I'm not seeing much use for a per-request authorization options, but apparently others do. The presence of a POSTable authorization resource could be signalled using the normal hypermedia controls (e.g., /.well-known/source). We typically contain connection-setup information (IP adresses and port numbers) in the URIs, but the way (D)TLS is parameterized from the URI is inadequate. (Just having the "s" bit is adequate only for a homogeneous PKI world such as the big Web.) So that requires some innovation. Innovation would also be required for soliciting per-request authorization options. In HTTP, we have 401 and WWW-Authenticate for this. In CoAP, the WWW-Authenticate style information could also be part of a 4.01 payload (saving the use of another option in exchange for defining another media type). (The 4.01 payload can also be used to initiate upgrading to a DTLS connection, so that would solve some of the above as well. See DCAF-COSE.) Grüße, Carsten Ludwig Seitz wrote: > On 02/01/2016 12:07 PM, Carsten Bormann wrote: >>> The underlying assumption is that the token is a proof-of-possession >>> token, i.e. that it is associated with a key (symmetric or asymmetric) >>> that the client possesses and that the RS can verify possession of. >>> >>> The binding of the token to a request happens by either using that key >>> to establish session security (e.g. as PSK or RPK for DTLS), or by using >>> that key in an object security protocol and using that protocol to >>> secure the request. >> >> OK, both kinds of communication security (via DTLS or via an "object >> security" protocol above DTLS) establish a security session that can be >> bound to, using the PoP token once, not per request. >> >>> Could you exemplify what you mean with "by using a RESTful >>> mechanism bound to the connection after connection establishment" I'm >>> not sure I'm following you here. >> >> As in >> >> POST /authorize >> >> (Note that since we are in an authenticated session, this is just about >> establishing additional authorization, not about re-authenticating >> either side. The server needs to bind that authorization to the >> session.) >> >> Look, Ma, no option :-) >> (Except for protecting the message in any "object security" session, if >> needed.) >> >> Grüße, Carsten >> > > Question to the list: in draft-ietf-ace-oauth-authz the default way to > transfer authorization tokens C-->RS is POSTing it to an authorization > resource at the RS (identical to what Carsten suggests here). > We also discuss some alternatives, optimized for specific situations in > appendix C: > 1. Using the TLS supplemental data extension [RFC4680] with TLS or DTLS > 2. Using a CoAP option (for very small tokens, e.g. reference tokens) > > Do we need these options? > > These having such options means that we have to specify some signaling > from the AS to the client, telling it which token transfer method to use. > > /Ludwig > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Fri Feb 5 06:07:06 2016 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 579F11B3925 for ; Fri, 5 Feb 2016 06:07:01 -0800 (PST) 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 QyO1Sc6w-tmh for ; Fri, 5 Feb 2016 06:06:58 -0800 (PST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C73E11B3924 for ; Fri, 5 Feb 2016 06:06:57 -0800 (PST) Received: from mfilter29-d.gandi.net (mfilter29-d.gandi.net [217.70.178.160]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 9FC53A80D1; Fri, 5 Feb 2016 15:06:56 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter29-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter29-d.gandi.net (mfilter29-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Y9CMyN9WKSCW; Fri, 5 Feb 2016 15:06:55 +0100 (CET) X-Originating-IP: 134.102.157.111 Received: from nar.local (unknown [134.102.157.111]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 7F1EDA8106; Fri, 5 Feb 2016 15:06:54 +0100 (CET) Message-ID: <56B4AC7C.8050600@tzi.org> Date: Fri, 05 Feb 2016 15:06:52 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Ludwig Seitz References: <56AF0EA9.40309@sics.se> <56AF2C89.7040102@tzi.org> <56AF37AF.2020608@sics.se> <56AF3C73.3050806@tzi.org> <56B497B4.5090102@sics.se> <56B4A93D.7040000@tzi.org> In-Reply-To: <56B4A93D.7040000@tzi.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] CoAP option for Access token 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, 05 Feb 2016 14:07:01 -0000 > /.well-known/source That must be my DYAC of the week... /.well-known/core, of course. Grüße, Carsten From nobody Fri Feb 5 07:26:12 2016 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 709BD1B3A43; Fri, 5 Feb 2016 07:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_12=1, RP_MATCHES_RCVD=-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 YtEvaXRF1F39; Fri, 5 Feb 2016 07:26:09 -0800 (PST) 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 76FD71B3A8B; Fri, 5 Feb 2016 07:26:09 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7AB962009E; Fri, 5 Feb 2016 10:35:06 -0500 (EST) Received: from obiwan.sandelman.ca (ip6-localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6ACA963751; Fri, 5 Feb 2016 10:26:07 -0500 (EST) From: Michael Richardson To: Ludwig Seitz In-Reply-To: <56B36703.8060305@sics.se> References: <56B31FEB.4010204@sics.se> <16330.1454596303@obiwan.sandelman.ca> <56B36703.8060305@sics.se> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 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 Archived-At: Cc: oauth@ietf.org, ace@ietf.org Subject: Re: [Ace] Questions about OAuth and DTLS 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, 05 Feb 2016 15:26:11 -0000 --=-=-= Content-Type: text/plain Ludwig Seitz wrote: > On 02/04/2016 03:31 PM, Michael Richardson wrote: >> >> Ludwig Seitz wrote: > Assuming we are using (D)TLS to >> secure the connection between C and RS, > assuming further that we are >> using proof-of-possession tokens [2], > i.e. tokens linked to a key, >> of which the client needs to prove possession in > order for the RS to >> accept the token. >> >> > Do we need to support cases, where the type of key used with DTLS >> does not > match the type of key in the PoP-token? >> >> > Example: >> >> > The client uses its raw public key as proof of possession, but the >> DTLS > connection C - RS is secured with a pre-shared symmetric key. >> >> > Is that a realistic use case? >> >> Before I agree that it's unrealistic, I think it's worth going out of >> charter scope and ask how much these two credentials were >> created/distributed. >> >> I think that in this case, the pre-shared symmetric key is initialized >> through some out-of-band (perhaps human mediated?) process, while the >> raw public key did not need any other pre-arrangement. > Actually even the raw public key needs to be provisioned out-of-band to > those supposed to trust it for authentication. First, let me say that I confused RS and RO/AS in my mind when reading before. Starting again, I think that any PSK for authentication between C<->RS is unrealistic. >> So my question is then: could the out-of-band process have >> pre-exchanged the raw public key (and the RS's key/certificate!) as >> well? > Short answer: Yes but only to the AS not to the client(s). > Long answer: I am laboring under the assumption that the AS not only > provides the OAuth token and the corresponding PoP key to the client, > but also some information on the communication security protocols that > the RS supports. Furthermore the AS facilitates the establishment of a > security context between client and RS by providing things such as a > (D)TLS-PSK or the RS's raw public key, depending on the (D)TLS mode > that the RS is going to support. Thus individual clients would not, > a-priori, know the raw public key of a RS, but would be able to get > that information from the AS. That seems entirely reasonable. Would the OAuth token not also be bound to the Raw RSA key of C? So RS would never need to be told about C's key, because the AS would have told it "key XYZ can access resource ABC" in the OAuth token. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVrS/DICLcPvd0N1lAQJVWQgApv0Ko3RPRLoclvbnsZe8o3NOMgHavBCJ 9iguyYb+xDZ7HjQuW066w+dncqeqGvd+qi4fM8GUFhGLB+1kRyRg20xF5Uf3o1wn e5+DecAt/rwVbC+rZO7gSXp3PSZgl2Vo/U9k+zRr8kK1HBUtl4sYo2CGMj79mcG3 vT//Vqbkw7RaHu70fDMUf63/H8MkmCv4REqWhPrnCBR792thUmC5rB1lmiBQBLO6 XQpuKBVKBQhFqLHkFAXDcmyQEYgjsm4ArGJ7SfhHuOaHt4eGn6oDMhZUQmF4baVA MQQ7XoWvR4cOqaJIp0u0UFOsI8QPEG4bINgsOHHJ338lcDohJXRadQ== =4MtP -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Feb 6 19:59:21 2016 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 174FF1B31D6; Sat, 6 Feb 2016 19:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Oa2NcQ3dGjJy; Sat, 6 Feb 2016 19:59:12 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81F901B31BF; Sat, 6 Feb 2016 19:59:12 -0800 (PST) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id B654C38EF8; Sat, 6 Feb 2016 19:59:11 -0800 (PST) From: "Jim Schaad" To: References: <0c9901d14736$e2353940$a69fabc0$@augustcellars.com> <568AED5E.7000408@cs.tcd.ie> In-Reply-To: <568AED5E.7000408@cs.tcd.ie> Date: Sat, 6 Feb 2016 19:56:39 -0800 Message-ID: <050301d1615b$8ca13b70$a5e3b250$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQLlEEvf79rpkp+SgCb/nHXkvCWZkALyuLCEnOEAncA= Archived-At: Cc: core@ietf.org, Ace@ietf.org Subject: Re: [Ace] Should we support padding for Enveloped/Encrypted 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: Sun, 07 Feb 2016 03:59:15 -0000 Before I close this issue, does anyone else want to weight in? Jim > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Stephen Farrell > Sent: Monday, January 04, 2016 2:09 PM > To: Jim Schaad ; cose@ietf.org > Cc: Ace@ietf.org > Subject: Re: [Ace] Should we support padding for Enveloped/Encrypted > Messages > > > I would argue to try define a padding mechanism here. > > As you note, it may be important later and there are some real issues when > dealing with constrained use-cases. In fact, in the limit one might want to define > a padding-only form for COSE to handle the case where the existence of any > traffic defeats any confidentiality protection. (E.g. sensor that fires a packet > when temp==20C.) I know that that'd not often be useful but I think there will be > times when it will. > > The argument that applications can best do this is not a bad one, but can be > countered. If a node has a common crypto library that ensures that padding can > be done consistently across multiple applications, which could be harder if not > defined at this layer. > (And even more likely, application developers don't care or don't bother or don't > know how to do this well.) > > Cheers, > S. > > PS: FWIW, I'd make the same argument for any protocol - I think we need to > define basic padding mechanisms whenever we can now so that we or others > can learn how to best use those later. > > > On 04/01/16 21:28, Jim Schaad wrote: > > Padding of content is useful for dealing with traffic analysis > > attacks. This can be seen as becoming important as it is now part of > > the basic framework of TLS 1.3. One possible simple analysis that can > > be performed against sensors is looking for thresholds in reported > > values. Just looking at the message length, one can tell the > > difference between '9.0' and '10.0' unless the first item is padded > > out to the same length. For example using either '09.0' or ' 9.0'. > > > > We currently do not have any facility to do a generic padding and it > > is not clear that we should provide one. The benefit is that it would > > allow for the ability to reduce the set of traffic analysis attacks. > > The down side is that we probably need to have some type of length > > field added to encrypted content for all messages. This means that we > > potentially have a single byte (or more depending on how it is done) to all > messages increasing the length. > > It is also not clear yet how much the IoT world cares about doing the > > type of protection in the near term. (It is possible that in time they > > may start > > caring.) > > > > One possible answer is to add the padding to the end of the current > > message ala the PKCS#7 padding. There would be N bytes appended to the > > end of the message, each containing the value of N. The default would > > be to append a single byte with the value of '1'. > > > > The use of padding would be described as being application specific > > rather than being generic. However the single byte would always need > > to be paid even if there was not padding done. > > > > At this time my inclination is to treat this as a problem that the > > application should be solving and to simply address it as a security > > consideration in the COSE message draft. > > > > Any comments? I would like to resolve this by the end of this week. > > > > Jim > > > > > > _______________________________________________ > > 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 From nobody Sun Feb 7 09:24:26 2016 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 0615E1A00E9 for ; Sun, 7 Feb 2016 09:24:25 -0800 (PST) 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, HTML_MESSAGE=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 ECNGMglAS9Mr for ; Sun, 7 Feb 2016 09:24:23 -0800 (PST) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEB0F1A00E6 for ; Sun, 7 Feb 2016 09:24:22 -0800 (PST) Received: by mail-qg0-x234.google.com with SMTP id y9so99380594qgd.3 for ; Sun, 07 Feb 2016 09:24:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=46lEKMtGBlq4AmJGaIcKZaHQ1ai5NAM/TwicPWBNRX8=; b=JQbtfdHisxuJ2q78/BTU2YcLjijt9KHQYvsPBadgDQPylhJ4NmRuCG1e1scdw7g0Zh U9c3xmeYlTJn81g9fpBzBnzX5omtuaxeEiPBi705+gkb2w+izj649aC0qFeH+4Dnj911 Nv61q6cOHFoCo0Dxj99whlegZnFH556UOEpTaMuzlKlJ/MOVPKy+t73s8ZRAKNt9CCnq GNkoxx8NhEMSTSJwA2aRmX/u5lsflal8Q1AF5bnKMKq0g3jxJ2ppAUE6mS0L5Ofejgb4 zz34qqAK6aey1l/ZnhAOZ9EjKcuZnr7WFEC+2mbuLkFv15BGhZQAumxbbTfBxGGQlRXn VEbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=46lEKMtGBlq4AmJGaIcKZaHQ1ai5NAM/TwicPWBNRX8=; b=nJtYdf9JEYD2IatGbWoCmQZrWdy9cBmJm+O/GBhbSnB2SfgUAAUCYP8mHMhDcmSJWG rj2VJCJqmOJFO3zDSIMYTG8KZSeMtmFKC1SCPmv7XalMOApuDrPL5zsMvypdPaehi7pe LbqWxK1RyC9YFJGXVd7K0d0a81Ao5pU6VkbL/Utv02+LQCi80uHbqvofNfYUjzTsRG6M i512qxMzcfMDuiJYlYnbmtBRfLKaKTUHefXiVohWg2lWykSgxG9H1e4d+e9SIR07x2ub tcUbHxYObnoq6+8QQdQ1XMXeozfmSzKqAQ7lKg7A1jVvQPJuoDj+6hkh8QP0a4TmtcnO iaFw== X-Gm-Message-State: AG10YOTKOoRBe6E+LQtew4dgGbSCthAvv9Paz3vK96yue/HGEtqA2iulCckX4yRzlkszKxk4Vm4cCqROsJu4DQ== MIME-Version: 1.0 X-Received: by 10.140.250.138 with SMTP id v132mr31366479qhc.0.1454865861512; Sun, 07 Feb 2016 09:24:21 -0800 (PST) Received: by 10.55.179.1 with HTTP; Sun, 7 Feb 2016 09:24:21 -0800 (PST) In-Reply-To: <56B31FEB.4010204@sics.se> References: <56B31FEB.4010204@sics.se> Date: Sun, 7 Feb 2016 18:24:21 +0100 Message-ID: From: Samuel Erdtman To: Ludwig Seitz Content-Type: multipart/alternative; boundary=001a113a99d0df6e43052b315ada Archived-At: Cc: oauth@ietf.org, ace@ietf.org Subject: Re: [Ace] Questions about OAuth and DTLS 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: Sun, 07 Feb 2016 17:24:25 -0000 --001a113a99d0df6e43052b315ada Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I think it is a reasonable simplification to mandate that PoP key and (D)TLS Mode matches i.e. if the PoP keys is symmetric the (D)TLS mode would be PSK, if the PoP key is asymmetric (D)TLS mode would be Raw Public key. But I think there is some compelling properties of having a symmetric PoP key and a Raw Public Key (D)TLS. In this case the Public key of the RS can be distributed to the client in the client information (the attributes accompanying the token) from AS and the PoP key as defined by PoP key distribution draft. With this setup the client can authenticate the server at connection time and then it can send its PoP token to authorization information endpoint/resource at the RS (defined in draft-ietf-ace-oauth-authz as an alternative to the HTTP Authorization header) to authorize the client. Regards //Samuel On Thu, Feb 4, 2016 at 10:54 AM, Ludwig Seitz wrote: > Hello list(s), > > in the process of updating our draft [1] (mainly in reaction to the > reviewer's comments) I've come up with a question I'd like to put to the > list (crossposting to OAuth as well, they might have considered that > already): > > Assuming we are using (D)TLS to secure the connection between C and RS, > assuming further that we are using proof-of-possession tokens [2], i.e. > tokens linked to a key, of which the client needs to prove possession in > order for the RS to accept the token. > > Do we need to support cases, where the type of key used with DTLS does no= t > match the type of key in the PoP-token? > > Example: > > The client uses its raw public key as proof of possession, but the DTLS > connection C - RS is secured with a pre-shared symmetric key. > > Is that a realistic use case? > > It would simplify the DTLS cases a lot, if I could just require the token > and the DTLS session to use the same type of key. For starters we could u= se > DTLS handshake to perform the proof-of-possession. > > Would there be any security issues with using the PoP key in the DTLS > handshake? > > I'm thinking of using pre-shared symmetric PoP keys as PSK as in RFC4279 > and raw public PoP keys as client-authentication key as in > RFC7250. > > > Regards, > > Ludwig > > [1] https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ > [2] https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02 > > > -- > 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 9251 > http://www.sics.se > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > --001a113a99d0df6e43052b315ada Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I think it is a reasonable simplifi= cation to mandate that PoP key and (D)TLS Mode matches i.e. if the PoP keys= is symmetric the (D)TLS mode would be PSK, if the PoP key is asymmetric (D= )TLS mode would be Raw Public key.

But I think the= re is some compelling properties of having a symmetric PoP key and a Raw Pu= blic Key (D)TLS. In this case the Public key of the RS can be distributed t= o the client in the client information (the attributes accompanying the tok= en) from AS and the PoP key as defined by PoP key distribution draft. With = this setup the client can authenticate the server at connection time and th= en it can send its PoP token to authorization information endpoint/resource= at the RS (defined in draft-ietf-ace-oauth-authz as an alternative to the = HTTP Authorization header) to authorize the client.

Regards
//Samuel





On Thu, Feb 4, 2016 at 10:54 AM, Ludwig Seitz <= ;ludwig@sics.se>= wrote:
Hello list(s),

in the process of updating our draft [1] (mainly in reaction to the reviewe= r's comments) I've come up with a question I'd like to put to t= he list (crossposting to OAuth as well, they might have considered that alr= eady):

Assuming we are using (D)TLS to secure the connection between C and RS, ass= uming further that we are using proof-of-possession tokens [2], i.e. tokens= linked to a key, of which the client needs to prove possession in order fo= r the RS to accept the token.

Do we need to support cases, where the type of key used with DTLS does not = match the type of key in the PoP-token?

Example:

The client uses its raw public key as proof of possession, but the DTLS con= nection C - RS is secured with a pre-shared symmetric key.

Is that a realistic use case?

It would simplify the DTLS cases a lot, if I could just require the token a= nd the DTLS session to use the same type of key. For starters we could use = DTLS handshake to perform the proof-of-possession.

Would there be any security issues with using the PoP key in the DTLS hands= hake?

I'm thinking of using pre-shared symmetric PoP keys as PSK as in RFC427= 9 and raw public PoP keys as client-authentication key as in
RFC7250.


Regards,

Ludwig

[1] https://datatracker.ietf.org/doc/dra= ft-ietf-ace-oauth-authz/
[2] https://tools.ietf.org/html/= draft-ietf-oauth-pop-key-distribution-02


--
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 9251
http://= www.sics.se


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


--001a113a99d0df6e43052b315ada-- From nobody Sun Feb 7 23:50:18 2016 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 889F41ACD1C for ; Sun, 7 Feb 2016 23:50:15 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 qnKj0Ai3DWNg for ; Sun, 7 Feb 2016 23:50:13 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B39F1ACD11 for ; Sun, 7 Feb 2016 23:50:12 -0800 (PST) Received: by mail-lb0-x22f.google.com with SMTP id bc4so78124077lbc.2 for ; Sun, 07 Feb 2016 23:50:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=wzwEM3BOnfR+swR4gC0AFKZOkjilschzMJuFUFWrSd8=; b=DN4aI1IftK+jb8nOCf5VV06LLwZTsdx/rvdkLaZiy3KBUCYUSIxyeo/d/weXNFGE8F DWkx7iegmdLxgOtIEdCGQip9L/Nwg0DmQV16JpASJHx6RZXlPltn7CwQ4Ac3LOd2xLWx a9dPOqJDk1OY2+eidfWZ6fTHYbb1HuWQTGyN6d+mJm+vQxAsjYO2Th+yh64Oe9eIfK66 6mGhosD/XuVKimP26K9EOIUDaswYfWxy8RCxSgzAqXIXaR+4dAH05drqJm/2I+ufQB2t SKMIr4ewAqp73zdkNXGJ6wZnf5kBCJUGXTYXKzoExnbji+zWRzH4P/Lt7Tbuf2Z+XFBG RcCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=wzwEM3BOnfR+swR4gC0AFKZOkjilschzMJuFUFWrSd8=; b=Nyt/7QtukbBJxZMeMcbtvwG6yMO8elauMeNmKRCzHeudaNoNGWzwow+IpfT6WrCC/E 41ebVnn4E8ZbVc5PI+6cTYLhwRWeBxKBmyWT5/4PbDhvYKr0mUl0qb4C1mt+VYnwrhDX Wp0CxS/Eu+3MLOTDRaV4JejhkpKO+fhQjz2JwQnlQsWXYQ/yK/x4/9zDw9t8OeVxwgjM Kw17Y5fn3wGOgPkHoc+kRiFjjomnrk8FpZHTwXRUlgGF/SIv3vjcR16apfrAC5zqERsf PdL7NxC6D4LpMfg3SU2mcSDqM8Ax3KDdHBot5HPgBPlB9rDivtFqIyvjZ2elqlTCTYyW /yvw== X-Gm-Message-State: AG10YOTyIra1xdYvAFLTvEqPISqGJuZA50E4uMaKIj4sc63yUpzBLcNZ0l2OV72qBMs9mZff X-Received: by 10.112.25.99 with SMTP id b3mr3633382lbg.11.1454917810668; Sun, 07 Feb 2016 23:50:10 -0800 (PST) Received: from Hyperion.suse ([85.235.10.186]) by smtp.gmail.com with ESMTPSA id ke9sm3716915lbc.28.2016.02.07.23.50.09 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 07 Feb 2016 23:50:10 -0800 (PST) To: Samuel Erdtman References: <56B31FEB.4010204@sics.se> From: Ludwig Seitz Message-ID: <56B848A0.20503@sics.se> Date: Mon, 8 Feb 2016 08:49:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000605080601030200040006" Archived-At: Cc: oauth@ietf.org, ace@ietf.org Subject: Re: [Ace] Questions about OAuth and DTLS 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, 08 Feb 2016 07:50:15 -0000 This is a cryptographically signed message in MIME format. --------------ms000605080601030200040006 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 02/07/2016 06:24 PM, Samuel Erdtman wrote: > Hi, > ~snip~ > But I think there is some compelling properties of having a symmetric > PoP key and a Raw Public Key (D)TLS. In this case the Public key of the= > RS can be distributed to the client in the client information (the > attributes accompanying the token) from AS and the PoP key as defined b= y > PoP key distribution draft. With this setup the client can authenticate= > the server at connection time and then it can send its PoP token to > authorization information endpoint/resource at the RS (defined in > draft-ietf-ace-oauth-authz as an alternative to the HTTP Authorization > header) to authorize the client. > In this case you need to perform an additional proof-of-possession step. = Worse, we have to define a new protocol for this. @OAuth: It is not really clear to me from reading the PoP drafts, what=20 the acceptable proof-of-possession methods are. Is this some work that=20 the WG is planning to do? /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 9251 http://www.sics.se --------------ms000605080601030200040006 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CtEwggTnMIIDz6ADAgECAhAfP2QWc8z7Bo71GhHCZ7DdMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMTA3MTE1NzM3WhcNMTcwMTA3MTE1NzM3WjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCiG5fxnXbdU0+3qInGZloXB0zZLM6XAu0EmTuCsWOU8eXN lCe37PTURORfLc3te4gCDcG1GrI2AuWR9MvlcYddMZt5y0T5BVWIu534vVJtG3QCuEYRJOTW B6RWQfK+dIPpZsNhgEQkYLjTHYoCu58gP0pfxNie1X7D+RxeQcq+ynNmyFdsxc2mI+dQqBKq 4zTsCNP4/jpSuovXTn8hEbbR8zkVQ2v/Gx+EO8oMIvkIEUYzkMxe3E9A7dq5DwotRDzP+y3g C4DCtI0tfIUtFjx18Pb5UMNUKZjitrOpXfheEz/igxziydri8bYpx4qGU9CNX+MvQG7Ogqju XKfQhUTTAgMBAAGjggGuMIIBqjALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFBMb8zf+BJ13fxqEl9gYiwxZ4hpmMB8G A1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCugKYYn aHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCBDmx1 ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNV HSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAbgRzIj1s9U5kpXodti5kdj3ztjPb oz4pz8zNwn3qPUW8c3Zd40IFe+R5hRDuIm2aa//fmwop2mLM3+5/LnSnacaDnRfE7pP3NgqX XUuuZf9TtMLU6RUh2Z9JKs0IzWKALPhoLgnCsbtYDrF4QAoVqeNV79Lb6a3r6KdB/xFErbee OkZk/iw9HCr/jnvysYjfFQcBounseJS3JG4RNIuDpfsWPupQSAhl4s0akaakiwqOHCU7x0Ra rbCN+bg+6R5FEtSouIh53Z04JmI7LU3leo/AseQiUpJ6HqQNJYjnsCw8DDbijNhH41ZZKrvB rKMfVvlCH9VqrKW4kPGajKMEJDCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJ KoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0 YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIx NjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNV BAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENv bSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL19 2vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk 9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89V LnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZ ZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8U lVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4G A1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/ BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9z ZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFy dHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2Nh LmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRA W6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4St DwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y 5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bj yOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfC BJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSi F3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odh QJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfr Bzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4W VWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9Vyrw MdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2de oprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAfP2QWc8z7Bo71 GhHCZ7DdMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNjAyMDgwNzQ5NTJaMC8GCSqGSIb3DQEJBDEiBCDwhCo0UYRq6g1g 7m9TllUiffCz2mwaXRFKPkMBLrEFAzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQHz9kFnPM+waO9RoRwmew3TCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQ Hz9kFnPM+waO9RoRwmew3TANBgkqhkiG9w0BAQEFAASCAQCOohxF6mMiPydy8HlDr4uyEvsa lXk2BcI2Fb/JAtdXA/x7/Bj1iSl+PjV3ar52vC42hnfC82bFARtIz4bFR7hZnjL4S3g8h5Nf 2GeXxXFVoA/9ujs+Ut8Vj9ntLpDiHr+nR1HJV5hRQ1CurPQ7EhJp66yn8xyn/dqKq0ZdceRk Gl4Ip72MxSbEGf5cLmqsA3TXc+C1EruYHujWYjddUbq0eiHWEa6PiNZXSL9CmIw3iX0xiEX6 6pJtOTGtLoHxP5gxIMwcknfshpRON9TEbV05hKDPCn/ex3M69wkZ5YSn9sS+Zw5y602HrdxI fBtM0yfwWtWAXUs2IrupgHdV2H9/AAAAAAAA --------------ms000605080601030200040006-- From nobody Mon Feb 8 00:02:21 2016 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 953381ACD30 for ; Mon, 8 Feb 2016 00:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_BACKHAIR_12=1, 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 P4Mq5cj1KM6t for ; Mon, 8 Feb 2016 00:02:19 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED8C41ACD2F for ; Mon, 8 Feb 2016 00:02:18 -0800 (PST) Received: by mail-lb0-x231.google.com with SMTP id bc4so78255455lbc.2 for ; Mon, 08 Feb 2016 00:02:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=gSCW56JM2ZTxu55fAbcxYWCl6QLjvgBMGemICuLbQjM=; b=waea6suI+J923M+A/bE3wTYKNphRSLncQZpc80qUU39Wl3aWR8uG60sPCRb8h7M+RF ClGw/NoeKn0UOM/L6iFgqmi/QLkTJHvmP0OZl2GKABgW9Z6h4qoD4pCP7Wkv/08Nk8Uf hc/gGJARU/YlPgbiUnbLrStqijT/8U9m+zZQaGZ8FOlljNwHmHkr6r+2sRKZmI93WZH4 V8NKN3b4rCwRwvGQMP8tSt6VYwPh3ml0o8wbB9Z7Lidg+Ypiyol6qSl2F42VDS1Fn5G5 4QyCTKXklFydDPg0uT+GFmSL3cnYQ/XgpR2kEuBK6EAkNkE/AhmyABw+Ks7rmf2EbSC+ 15tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=gSCW56JM2ZTxu55fAbcxYWCl6QLjvgBMGemICuLbQjM=; b=hrxrKjpjr2ltMgMMgB2sFr8vLtmFMlCBuHCEOgqkuUjThCP/GaGdfvSO4mqSckcm+V T1Rv4LzUo8OLDdYn4fj1DgjR7bzJSjEVgf3x2+UYF2unRuom9h6FBcZKAfskCRkixGkv XGANf8z0qxsaCsdfzU1RgBeO8310Dh7s2Lh4i4vTA5XDnbNLDBlimWwHJCqdTdZF1wPC hiv/KpFWGt3MjRGMqGOEfdYLw2eCTQ0cQoK5SYgX29OO0nQMDBBHCwnF4e2KvhZRus3P R6SCZvlI6uxhyTzNOsZBzcqrn0HW/PZag14JYRtZx2g5VlIwDZp9aRpeHJ7ub8nYm+Ya h5Zw== X-Gm-Message-State: AG10YORsdOynvL3YSaz0JAx1ye00ZUDE7kEw475I8CVkeXotg7IJEQMpvbUOTAao3nG+y2z5 X-Received: by 10.112.169.74 with SMTP id ac10mr10766551lbc.123.1454918537172; Mon, 08 Feb 2016 00:02:17 -0800 (PST) Received: from Hyperion.suse ([85.235.10.186]) by smtp.gmail.com with ESMTPSA id o9sm3841239lfe.15.2016.02.08.00.02.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Feb 2016 00:02:16 -0800 (PST) To: Michael Richardson References: <56B31FEB.4010204@sics.se> <16330.1454596303@obiwan.sandelman.ca> <56B36703.8060305@sics.se> <21409.1454685967@obiwan.sandelman.ca> From: Ludwig Seitz Message-ID: <56B84B87.2070205@sics.se> Date: Mon, 8 Feb 2016 09:02:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <21409.1454685967@obiwan.sandelman.ca> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080100030303010201040300" Archived-At: Cc: oauth@ietf.org, ace@ietf.org Subject: Re: [Ace] Questions about OAuth and DTLS 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, 08 Feb 2016 08:02:20 -0000 This is a cryptographically signed message in MIME format. --------------ms080100030303010201040300 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Michael, thank you for answering, this is getting very interesting. Comments inline. /Ludwig On 02/05/2016 04:26 PM, Michael Richardson wrote: > First, let me say that I confused RS and RO/AS in my mind when reading = before. > > Starting again, I think that any PSK for authentication between C<->RS = is > unrealistic. > Actually I don't want to authenticate the client, I just want do a=20 proof-of-possession for the (symmetric) key that is bound to the token.=20 Wouldn't the DTLS-PSK handshake provide that proof? Detailed scenario (skip if the above makes sense): Client has a PoP token with a symmetric PoP key. Client wants to use=20 DTLS-PSK towards the RS with the symmetric PoP key as PSK to get a.) A=20 secure connection and b.) do the proof-of-possession towards the RS. > >> So my question is then: could the out-of-band process have > >> pre-exchanged the raw public key (and the RS's key/certificate!= ) as > >> well? > > > Short answer: Yes but only to the AS not to the client(s). > > > Long answer: I am laboring under the assumption that the AS not = only > > provides the OAuth token and the corresponding PoP key to the cl= ient, > > but also some information on the communication security protocol= s that > > the RS supports. Furthermore the AS facilitates the establishmen= t of a > > security context between client and RS by providing things such = as a > > (D)TLS-PSK or the RS's raw public key, depending on the (D)TLS m= ode > > that the RS is going to support. Thus individual clients would n= ot, > > a-priori, know the raw public key of a RS, but would be able to = get > > that information from the AS. > > That seems entirely reasonable. Would the OAuth token not also be boun= d to > the Raw RSA key of C? So RS would never need to be told about C's ke= y, > because the AS would have told it "key XYZ can access resource ABC" in = the > OAuth token. > Yes if the PoP token uses a public key as PoP key. C could even generate = an ephemeral key-pair just for this token (and the DTLS-RPK handshake). --=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 9251 http://www.sics.se --------------ms080100030303010201040300 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CtEwggTnMIIDz6ADAgECAhAfP2QWc8z7Bo71GhHCZ7DdMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMTA3MTE1NzM3WhcNMTcwMTA3MTE1NzM3WjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCiG5fxnXbdU0+3qInGZloXB0zZLM6XAu0EmTuCsWOU8eXN lCe37PTURORfLc3te4gCDcG1GrI2AuWR9MvlcYddMZt5y0T5BVWIu534vVJtG3QCuEYRJOTW B6RWQfK+dIPpZsNhgEQkYLjTHYoCu58gP0pfxNie1X7D+RxeQcq+ynNmyFdsxc2mI+dQqBKq 4zTsCNP4/jpSuovXTn8hEbbR8zkVQ2v/Gx+EO8oMIvkIEUYzkMxe3E9A7dq5DwotRDzP+y3g C4DCtI0tfIUtFjx18Pb5UMNUKZjitrOpXfheEz/igxziydri8bYpx4qGU9CNX+MvQG7Ogqju XKfQhUTTAgMBAAGjggGuMIIBqjALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFBMb8zf+BJ13fxqEl9gYiwxZ4hpmMB8G A1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCugKYYn aHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCBDmx1 ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNV HSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAbgRzIj1s9U5kpXodti5kdj3ztjPb oz4pz8zNwn3qPUW8c3Zd40IFe+R5hRDuIm2aa//fmwop2mLM3+5/LnSnacaDnRfE7pP3NgqX XUuuZf9TtMLU6RUh2Z9JKs0IzWKALPhoLgnCsbtYDrF4QAoVqeNV79Lb6a3r6KdB/xFErbee OkZk/iw9HCr/jnvysYjfFQcBounseJS3JG4RNIuDpfsWPupQSAhl4s0akaakiwqOHCU7x0Ra rbCN+bg+6R5FEtSouIh53Z04JmI7LU3leo/AseQiUpJ6HqQNJYjnsCw8DDbijNhH41ZZKrvB rKMfVvlCH9VqrKW4kPGajKMEJDCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJ KoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0 YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIx NjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNV BAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENv bSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL19 2vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk 9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89V LnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZ ZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8U lVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4G A1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/ BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9z ZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFy dHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2Nh LmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRA W6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4St DwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y 5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bj yOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfC BJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSi F3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odh QJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfr Bzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4W VWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9Vyrw MdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2de oprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAfP2QWc8z7Bo71 GhHCZ7DdMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNjAyMDgwODAyMTVaMC8GCSqGSIb3DQEJBDEiBCBC8Zn1fY4xkAtL P+FPjmnBX27tiDG33mnrsxgRxAlKmDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQHz9kFnPM+waO9RoRwmew3TCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQ Hz9kFnPM+waO9RoRwmew3TANBgkqhkiG9w0BAQEFAASCAQAAJOjS501R1rMC+SjOAPQg+BQu WS/88UpV9NY2yxw9/pkjU29l5oA0YoJfGvAkVv8gxQvi9SF1+MCwHXXJYZrqHyiwTuaogPWa fBX8keokhBFPni5ksTO+agzKu+XjFiPBFpzswVfnj8kqH6EJMYhlKbAmav2qFPs7ZX8jr0rt hPTIJVBgQxHjU2h+T0MKxdhd7QiSp17lqjg1X148iWdEdjZU1+S63utxLejMXiJHBfeagixa CHIy1kbrHlJX/djujK/rUNgqUkWIZMSlg6ZlH8l3mgkK7+Atz5vYYZJEIAKrk2dAnAPVrjA8 XsZU5Q5nKf+nKLmyMVDLjRl/ykKgAAAAAAAA --------------ms080100030303010201040300-- From nobody Mon Feb 8 02:52:36 2016 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 44D851ACECE for ; Mon, 8 Feb 2016 02:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 mR6wZM8EzFfe for ; Mon, 8 Feb 2016 02:52:31 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55AB71ACEC4 for ; Mon, 8 Feb 2016 02:52:31 -0800 (PST) Received: by mail-qg0-x230.google.com with SMTP id b35so113789036qge.0 for ; Mon, 08 Feb 2016 02:52:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=SM5aysPZR/YhOQgVnawYn4ZYs/EC4qcnt+6jOpcRc00=; b=ZvUNPFrwAfUmRvGyLpi1JPcreEseSa13zKg5LlMRy8zdzms7zMu7I0WauVn2PjUP79 /bk2RE88ce4pnhaFL1GqRGhEN/fkaF7o44GpBwWYWp8Wwbf+er7lCFOprrJsylkSftDa 6N7wgntfaJsc7FRhqGBQaG3DyFbLr/w+lC1Pnc64m8OrIV2eiaW+9gAEu3jav0l67MxT CRnTMcfB1mBi/UwGyXAzYYVO6/KCQ0E7N5btRavSVKpn8ucEEl7ahhUd4nKseY10/tlf i652O5Hi1kYrIshugkeriBk64/zr6VO14q7jAPGqB1xFOvjpSPfbCUXuPGECOB6AO/Y0 4aWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=SM5aysPZR/YhOQgVnawYn4ZYs/EC4qcnt+6jOpcRc00=; b=Y8xLZRcHelk8RZaXsklt9PeQYJTW+o/tkMtinxEI9DklPvmWhYDY+N2sZ2uNqmCrqG LAY17kW51/2AumzHxq/mK8k+wYW1vwyyfTIo6JJmjLAEooU90BzwrfUPEnTr8Y05x9Zu OlLznC/j600n24LzFU8u+ds2EUlD0qjyRQu9r2JsDqS6VTiE2GoRIJ1c9VMGlB2a1W30 qupaSyjs3CUrvFJ1w71bGRaJ9Hb5cM3SVESAcCHldPaU0lb3VqrtUBiX+874RsMQvB+j RAM8v/YM5o4J5iBW7GObfT6jvTmCnZQsqECFtuqZCJXpsTvL0Or+QWrb7WzZ/Ewy1DKh 9PNg== X-Gm-Message-State: AG10YOQ4mPG7qD78aq1Dy3BMiizenQiYv5W13O6z5cgQe6T2xgT4Kn8wQPKsBnRZDrdwt4wemXOi4u9IXLZWOg== X-Received: by 10.140.194.4 with SMTP id p4mr35611070qha.30.1454928750525; Mon, 08 Feb 2016 02:52:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.148.198 with HTTP; Mon, 8 Feb 2016 02:52:11 -0800 (PST) In-Reply-To: <56A7D04B.9000302@gmx.net> References: <67780087-1D9F-4018-ADB8-724A2D0BEE81@um.es> <56A0F652.1050006@gmx.net> <56A7D04B.9000302@gmx.net> From: Renzo Navas Date: Mon, 8 Feb 2016 11:52:11 +0100 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: =?UTF-8?Q?G=C3=B6ran_Selander?= , Rafa Marin Lopez , ace Subject: Re: [Ace] Time Requirements for Constrained Devices 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, 08 Feb 2016 10:52:35 -0000 Hi Hannes, Hi All, Sorry for the late reply, I was out of work + out of ACE-ML; I am glad Hannes that my message raised an interesting debate/question. I have not done advancements on the field since my last message; but as I said my opinion is that we should have in account Resource Servers that do not have Time Information. Otherwise I think demanding Time-awareness at the RS is a very strong requirement (not so constrained). I am trying to come up with a AA solution+implementation for the simplest Use Case I can think-of and that involves having a very constrained RS (meaning no Real Time Clock nor time sync protocol); The Proof-of-possession token solution is and ideal tool on this constrained scenario as it will permit negotiate a fresh symmetric-key between the previously unknown Client and the RServer. This Key will be used to establish an authenticated secure channel between C and RS. However as I discussed before, if no absolute time awareness is present at RS: either we need token introspection, or we need another flow of messages and a nonce-based approach to generate the shared key/PoP Token. I will go internally for the second option, but as Hannes mentioned this adds complications for the revocation mechanism. My opinion and belief, is that Use Cases where the RS do not have time information will be very common on real deployments. Either we can say that UC can be solved by token introspection, or we will have to explore other solutions. Regards and good start of the week! Renzo On Tue, Jan 26, 2016 at 9:00 PM, Hannes Tschofenig wrote: > Hi Goeran, > > thanks for your response. > > On 01/21/2016 06:40 PM, G=C3=B6ran Selander wrote: >> Hi Hannes, >> >> Good discussion input, some comments: >> >> You write certificates, but CoAP also support raw public keys and >> pre-shared keys. For these cases there is not necessarily time related >> information, is there? > > It is true that with raw public keys and pre-shared secrets the > situation is a bit different. Nevertheless the requirement for time > information still does not necessarily disappear since there is still > the access token that may contain claims like issued at, not before, and > an expiry date. > >> >> If the use case does not allow the RS to be online with AS or time serve= r >> at all times (for reasons of connectivity such as container use case etc= ., >> or for reasons of communication budget) then you are right that it may n= ot >> be possible to verify change of permissions and revokation. > > Correct. > >> >> But still it may be possible for the RS to: >> - invalidate short lived access tokens (counting down using internal clo= ck) >> - verify that access tokens are not replayed (using nonce or sequence >> numbers) >> which is sufficient in terms of timely authorization in some cases. > > Access tokens don't contain sequence numbers or nonces since otherwise > they will become on-time-tokens. > > Using an "internal clock" is not sufficient since such a real-time clock > needs to have a reference to know whether a "short lived token" is > indeed fresh. > >> >> Furthermore a client may have access to the AS even if the RS doesn=E2= =80=99t, and >> through a new access token provide fresh information to the RS. (The RS >> would in this case not know that an access token is recent, but in case = of >> sequence numbers that it is more recent than previous.) > > It is indeed possible that the client may have access to the AS but you > are in essence suggesting > * one-time-tokens, and > * keeping state (such as a sequence number) at the RS. > > >> >> I think we should support deployments which does not require RS to keep >> external time, and accept that those deployments will not be able to >> support immediate revocation. > > The problem is that it come for free. So, we need to make an informed > decision. For that reason I am reaching out to folks in this group to > determine whether there is indeed interest in deploying such solutions. > > Ciao > Hannes >> >> G=C3=B6ran >> >> >> >> On 2016-01-21 16:16, "Ace on behalf of Hannes Tschofenig" >> wrote: >> >>> Hi Renzo, Hi all, >>> >>> thanks for your review comment since you raise a bigger issue. The >>> review feedback was recorded as issue#12 at >>> https://github.com/LudwigSeitz/ace-oauth/issues/12 >>> >>> You are asking what our requirements for the Resource Server (RS) are >>> with regard to the availability of time information (and the accuracy o= f >>> it). Our solution building blocks currently require time information, >>> such as certificates and access tokens. >>> >>> In your email write-up, see >>> http://www.ietf.org/mail-archive/web/ace/current/msg01554.html, you >>> correctly pointed out that there is a relationship with the validity of >>> the authorization information and with a potential revocation mechanism= . >>> >>> Before we start working on solutions I would like to get a sense of the >>> group what the views are. For resource servers do you consider to >>> incorporate a real-time clock and a protocol mechanism that obtains tim= e >>> information? >>> >>> Not having time information at the RS will have the following impact: >>> >>> * The RS somehow has to get information about access tokens where >>> permissions have changed, where the access tokens have been revoked or >>> have otherwise been invalidated since the tokens do not contain validit= y >>> information. >>> * Time-related information in certificates cannot be checked. >>> >>> In many situations we will have a tradeoff between the availability of >>> time information and the required communication overhead for interactin= g >>> with an authorization server to obtain up-to-date information about the >>> validity of the credentials. >>> >>> What does the group think? >>> >>> Ciao >>> Hannes >>> >>> >>> On 11/19/2015 10:19 AM, Rafa Marin Lopez wrote: >>>> Hi Renzo: >>>> >>>> I agree with you that if we consider the distribution of a symmetric >>>> key between three parties the literature is full of very concise and >>>> security proven protocols. >>>> >>>> Please count on me if some help is required in this area. >>>> >>>> Best Regards. >>>> >>>> >>>>> El 13 nov 2015, a las 17:30, Renzo Navas >>>>> escribi=C3=B3: >>>>> >>>>> Good Evening ACE ML, >>>>> >>>>> Reading draft-seitz-ace-oauth-authz-00 (thanks to the authors for eas= y >>>>> to read doc) I was very interested by the PoP token that offers an >>>>> authenticated fresh key to be used for further secure the comm., >>>>> but I saw a very strong requirement for the RS to have a Time Sync. >>>>> mechanism. >>>>> I preview the objective of my mail, is to raise the question: >>>>> >>>>> * Do we want to have a strong requirement for the constrained device >>>>> (RS) on an AA Architecture to have a Time Synchronization mechanism? >>>>> * Are we interested on offering non-time -nonce- based solution for a= n >>>>> OAuth PoP Token approach (for example when the token does not expire)= ? >>>>> >>>>> >>>>> (those interested on those concerns can read the rest of the mail, >>>>> that is rather long) >>>>> >>>>> Regards >>>>> >>>>> ------------------------------------------------------- >>>>> >>>>> (Long version) >>>>> >>>>> I've been working lately on the Authenticated Key Establishment >>>>> problem (The are two very good reference books [1][2]), focusing on >>>>> solutions with a Trusted Third Party, Symmetric Crypto, and not using >>>>> Time-stamps but Nonces (To avoid having to deal with time >>>>> synchronization).I have no strong Crypto background. >>>>> >>>>> First I want to thank the authors of draft-seitz-ace-oauth-authz-00 , >>>>> very enlightening for the oauth neophytes. >>>>> I'm mostly interested on the authentication problem (auth. key >>>>> establishment), so the Proof-of-Possesion Token is a great >>>>> tool/concept, I took the time to read >>>>> draft-ietf-oauth-pop-architecture-05 and >>>>> draft-ietf-oauth-pop-key-distribution-02 to try to have all the >>>>> background possible. >>>>> >>>>> So from the Authenticated key establishment mechanism point of view a >>>>> new fresh key between C and RS obtained by means of a PoP Token >>>>> mechanism -I think- will be similar to a Denning-Sacco shared key >>>>> protocol ( >>>>> http://www.lsv.ens-cachan.fr/Software/spore/denningSacco.html >>>>> . Client is A, AS is S, and RS is B), with the difference that the Po= P >>>>> Token Timestamp have a start and end value that will make the >>>>> "mutiplicity attack" of Denning-Sacco limited on time. >>>>> >>>>> My concern is that we will always need Time sync on the RS, that some >>>>> (most) times will be the constrained node (I think that the Client >>>>> does not need to be Time-aware), is that a MUST requirement? So >>>>> no-time aware devices will not be able to use OAuth PoP Token (or wil= l >>>>> have to use token introspection, a good fallback solution btw) >>>>> >>>>> Will be of interest offering a PoP Token generation and transport >>>>> mechanisms that offers an authenticated fresh key without the need o= f >>>>> Time-awarenness at the RS? >>>>> >>>>> Time awareness at the RS offers great advantages, and maybe also Time >>>>> is always needed in all authorization solutions (to make easy token >>>>> expiration and freshness claims). >>>>> >>>>> But I'm thinking about nonce-based authenticated key establishment. O= f >>>>> course without time information embedded on the token, token >>>>> expiration will be more difficult: >>>>> * we will need token introspection, or >>>>> * the AS will contact the RS to revoke tokens, or >>>>> * we will need on a non-time based solution for revocation that does >>>>> not involve the AS, for example: a pop token/key is valid for use onl= y >>>>> for one (or N) Resource Requests (of course if the response message >>>>> get lost we are screwed...) >>>>> >>>>> >>>>> So maybe we cannot avoid to have Time-awareness at the RS, for >>>>> Authorization purposes.. >>>>> But for Authentication certainly we can avoid Time, the three most >>>>> recommended by [2] nonce-based protocols are: >>>>> * Bellare-Rogaway (3PKD) [a Choo modified version It has been proven >>>>> provably secure on the strongest model to test auth. key establishmen= t >>>>> protocols ] [3] >>>>> * Yahalom [a modified version has been proven secure on a weaker mode= l >>>>> -bellare rogway- than 3PKD] [4] >>>>> * Boyd [Key Agreement: RS, C and AS contribute inputs to generate the >>>>> key] [proof idem yahalom ][5] >>>>> >>>>> The message flows on that three of protocols do not respect OAuth >>>>> flows (I attach an image with the high level message flows, A is the >>>>> initiator always), so that take us apart a bit from OAuth... >>>>> >>>>> This mail is starting to get long so I will try to conclude it, but >>>>> hopefully raise the question: >>>>> >>>>> >>>>> ** Are we interested on offering non-time -nonce- based solution for >>>>> an OAuth PoP Token approach (for example when the token does not >>>>> expire)**? >>>>> >>>>> >>>>> >>>>> If NO, I guess that will need token introspection for RS that cannot >>>>> support time (That mechanism will map to other authenticated key >>>>> establishment protocol and not Denning-Sacco-based ) >>>>> >>>>> if YES, are we interested in adapting a nonce-based auth. key >>>>> establishment protocol to OAuth PoP Token? >>>>> >>>>> >>>>> I hope this questions are useful, >>>>> >>>>> Best regards >>>>> >>>>> Renzo >>>>> >>>>> >>>>> >>>>> [1] Colin A. Boyd and Anish Mathuria. 2003. Protocols for Key >>>>> Establishment and Authentication. Springer-Verlag New York, Inc., >>>>> Secaucus, NJ, USA. >>>>> [2] Kim-Kwang Raymond Choo. 2008. Secure Key Establishment (1ed.). >>>>> Springer Publishing Company, Incorporated. >>>>> >>>>> [3] 3PKD - >>>>> http://eprints.qut.edu.au/1230/1/ACISP_Full_Version_-_03_May_2005.pdf >>>>> [4] Yahalom - https://eprint.iacr.org/2007/188.pdf >>>>> [5] Boyd - http://eprints.qut.edu.au/4421/1/4421_1.pdf >>>>> >>>>> _________________________________= ___ >>>>> ___________ >>>>> Ace mailing list >>>>> Ace@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ace >>>> >>>> ------------------------------------------------------- >>>> Rafael Marin Lopez, PhD >>>> Dept. Information and Communications Engineering (DIIC) >>>> Faculty of Computer Science-University of Murcia >>>> 30100 Murcia - Spain >>>> Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es >>>> ------------------------------------------------------- >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ace mailing list >>>> Ace@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ace >>>> >>> >> > From nobody Tue Feb 9 08:17:51 2016 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 874A01AC406 for ; Tue, 9 Feb 2016 08:17:50 -0800 (PST) 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, HTML_MESSAGE=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 EY_i85yE8KR9 for ; Tue, 9 Feb 2016 08:17:48 -0800 (PST) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76A2C1AC401 for ; Tue, 9 Feb 2016 08:17:48 -0800 (PST) Received: by mail-qg0-x22c.google.com with SMTP id y89so69974878qge.2 for ; Tue, 09 Feb 2016 08:17:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=5kzAfRd1R8/YpF+jjaZvCfeZQ8foBD8D88N2hqu1Ka0=; b=nTO8AddIChes45rtWnyfWlya3YjXXUg1wnJHYdSK/Tpl2wU6rHxfZs8Kkt9qunxz5L 6NLE8+XHL2mvsAiDNwICAhO6hW74/VGkzx9UUxr50DBikccAi4x3mW/MYnHBEJsFWUJx 7Gr67M5WfkhFSjGwsBq8FLAHD0ruzgzg735r+2q2VlWZ0LrcUiy9vt04Sm38IM3t1mX6 Z5jHz9qra6ioewz0222GG0yWK5sQUMpr4VVXybelUGAqdrjbRY4UVcie5qYDLTzm8s33 Mi2MNrdXSCBJgaeBcVKs+TU6konWvjTWpYrIOFgf84ySnklcj0iwcY5ZS9j4++yyGLOK 10/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=5kzAfRd1R8/YpF+jjaZvCfeZQ8foBD8D88N2hqu1Ka0=; b=NU04cGhdXmFkhq+BDPhq2Ikk5ugtOozweDQ59mjUcD8iv3/7AkToZ4MLO3USS2anIC L+5U4JqTkxw1Uff5CqmLRLif3nGR2SI0BeW3P1Big8wWXJBiYAMBoD2CjohxL/P9I8Sb 9IlEqGK0q624hIIxYSAQqvZ0462hVjE315eNSUN1sB53W1t75Ke8jMZcldlfnoaw1Jnr n8YYP2lhTXc8p/7OIZZs0mCvgQCgQAs0NtVE6BRK73g+DriK/OZOyijAzaDc0YzZecSS mAQz67ZTjoACts19a0mQsIMRn1p/oKVVqSaqMqSPn+/7Z7bLD6urLOfFaQkf6nR12Jxp ApOQ== X-Gm-Message-State: AG10YOTY1K4UcMSabPem5w24+0AI6xXOYxplSO9XMXeYIDlrKkVh2rwgtch7EVwJdxolp6MRrhKWDhrnDb+iaw== MIME-Version: 1.0 X-Received: by 10.140.194.4 with SMTP id p4mr45398399qha.30.1455034667386; Tue, 09 Feb 2016 08:17:47 -0800 (PST) Received: by 10.55.179.1 with HTTP; Tue, 9 Feb 2016 08:17:47 -0800 (PST) In-Reply-To: <56B848A0.20503@sics.se> References: <56B31FEB.4010204@sics.se> <56B848A0.20503@sics.se> Date: Tue, 9 Feb 2016 17:17:47 +0100 Message-ID: From: Samuel Erdtman To: Ludwig Seitz , Ace@ietf.org Content-Type: multipart/alternative; boundary=001a11433fa27c5eb5052b58a805 Archived-At: Subject: Re: [Ace] Questions about OAuth and DTLS 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, 09 Feb 2016 16:17:50 -0000 --001a11433fa27c5eb5052b58a805 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, see inline On Mon, Feb 8, 2016 at 8:49 AM, Ludwig Seitz wrote: > On 02/07/2016 06:24 PM, Samuel Erdtman wrote: > >> Hi, >> >> ~snip~ > >> But I think there is some compelling properties of having a symmetric >> PoP key and a Raw Public Key (D)TLS. In this case the Public key of the >> RS can be distributed to the client in the client information (the >> attributes accompanying the token) from AS and the PoP key as defined by >> PoP key distribution draft. With this setup the client can authenticate >> the server at connection time and then it can send its PoP token to >> authorization information endpoint/resource at the RS (defined in >> draft-ietf-ace-oauth-authz as an alternative to the HTTP Authorization >> header) to authorize the client. >> >> > In this case you need to perform an additional proof-of-possession step. > Worse, we have to define a new protocol for this. > But we are defining that in OSCoAP and OSCON, that would be used to validate data/requests from the client. while validating data from the server by having the trusted connection with the RPK > @OAuth: It is not really clear to me from reading the PoP drafts, what th= e > acceptable proof-of-possession methods are. Is this some work that the WG > is planning to do? I think this is what you are looking for https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-02 Signed HTTP request In my opinion it would be good if OSCoAP would be similar, or that one would create a mapping of that draft to CoAP. > > > /Ludwig > > > > > -- > 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 9251 > http://www.sics.se > > --001a11433fa27c5eb5052b58a805 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

see inline

On Mon, Feb 8, 2016 at 8:49 AM, Ludwig= Seitz <ludwig@sics.se> wrote:
On 02/07/201= 6 06:24 PM, Samuel Erdtman wrote:
Hi,

~snip~
But I think there is some compelling properties of having a symmetric
PoP key and a Raw Public Key (D)TLS. In this case the Public key of the
RS can be distributed to the client in the client information (the
attributes accompanying the token) from AS and the PoP key as defined by PoP key distribution draft. With this setup the client can authenticate
the server at connection time and then it can send its PoP token to
authorization information endpoint/resource at the RS (defined in
draft-ietf-ace-oauth-authz as an alternative to the HTTP Authorization
header) to authorize the client.


 In this case you need to perform an additional proof-of-possession step. Wo= rse, we have to define a new protocol for this.

But we are defining that in OSCoAP and OSCON, that would be used t= o validate data/requests from the client. while validating data from the se= rver by having the trusted connection with the RPK


@OAuth: It is not really clear to me from reading the PoP drafts, what the = acceptable proof-of-possession methods are. Is this some work that the WG i= s planning to do?

I think this is what you = are looking for
Signed HTTP request
In my opinion it would be good if OSCoAP would be similar, or t= hat one would create a mapping of that draft to CoAP.
=C2=A0=C2= =A0


/Ludwig




--
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 9251
http://= www.sics.se


--001a11433fa27c5eb5052b58a805-- From nobody Tue Feb 9 08:24:52 2016 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 3FAD11AC42E for ; Tue, 9 Feb 2016 08:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 0lCuQxu-Txc7 for ; Tue, 9 Feb 2016 08:24:48 -0800 (PST) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6C591AC42D for ; Tue, 9 Feb 2016 08:24:47 -0800 (PST) Received: by mail-qg0-x232.google.com with SMTP id y89so70136359qge.2 for ; Tue, 09 Feb 2016 08:24:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=TPHvEih/V8w4XIeVnJwaSS5yd0SJ/xfTJN+/AkhpFD4=; b=GVgm5i/3/YDX1n0CFGQG5y6jvyOVAtHrif13r9YD1zjnBZu6qZWw7/swsFKJ351fHO +ej1m0zDUi9v/2WjpLnhUKJWM4ckPQO9fUyy0IMfTwxDhKFx7Q24qABRi78Rwn1HQmKo kacohpId7jhq8Lkc2KGa7jaQJ3g98gA32BgkR3uq29Xgox0RZh3g0FT+pjKcbmq1aOc0 wqU8SC0SruJOYE1coQl+8+80ws8vwMk/tOWedcWoWA9ihlDfEYJ80laJC+pnNlNlcAYU GSATAP0DDfMXx5OBGBYAoKI0Gy1WxwqcVQ7Rylk5XFnFbgxFgEm1oOy+hYZaQXtlTMjS kWOw== 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:message-id:references:to; bh=TPHvEih/V8w4XIeVnJwaSS5yd0SJ/xfTJN+/AkhpFD4=; b=M6CUtdrUqudvk7xOGUUx9F9tAFM1eyBCsMpeym2vYUSeGBRJb4ypFD6nuzwSyBSRlS CooWKUCSu/Po6n3ZgDeAQNclO9YItMT/jvEHDy/k268rCYgMUztvxemNIAfcygWD2ZQl 2zSAr+CmBvGHazqfXlKvf2joCNn//vO+p84FY/3OJ14fwzhFNRr6eGq6k+dbbc7cEKLi oWcD0X8yEfm9HvbHZdfk7SSDRslikd1EXoUvetc8KOC5zdLSyg5B9CgRxz6P5tCizzG3 nxo92OvULwyPGGEQSx0PEHfeRkkKZlyQEZ9ur7lcQXF/SCAL90RH/UjGHY8dSGE2lgaX UG+A== X-Gm-Message-State: AG10YOQmuw5gbAKwnbqd/VKyTK4RpvCTLs/8dQlL0fasiOi7oTEWyVOr6IBeNXeoooOs0A== X-Received: by 10.140.98.232 with SMTP id o95mr42715789qge.43.1455035086856; Tue, 09 Feb 2016 08:24:46 -0800 (PST) Received: from [192.168.1.68] ([191.115.118.180]) by smtp.gmail.com with ESMTPSA id l19sm16079911qki.42.2016.02.09.08.24.43 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 09 Feb 2016 08:24:45 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_A57B39AB-DA56-428F-A722-BF98A5A4B74F"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: Date: Tue, 9 Feb 2016 13:24:37 -0300 Message-Id: References: <56B31FEB.4010204@sics.se> <56B848A0.20503@sics.se> To: Samuel Erdtman X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Ludwig Seitz , Ace@ietf.org Subject: Re: [Ace] Questions about OAuth and DTLS 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, 09 Feb 2016 16:24:50 -0000 --Apple-Mail=_A57B39AB-DA56-428F-A722-BF98A5A4B74F Content-Type: multipart/alternative; boundary="Apple-Mail=_CDB46521-04C2-47A6-AB5C-8BF8B40BA2CA" --Apple-Mail=_CDB46521-04C2-47A6-AB5C-8BF8B40BA2CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-02 = =20 Is one proposal but is tightly bound to HTTP. We are planning on doing one for TLS client Auth, and perhaps token = binding in the OAuth WG. John B. > On Feb 9, 2016, at 1:17 PM, Samuel Erdtman wrote: >=20 > Hi, >=20 > see inline >=20 > On Mon, Feb 8, 2016 at 8:49 AM, Ludwig Seitz > wrote: > On 02/07/2016 06:24 PM, Samuel Erdtman wrote: > Hi, >=20 > ~snip~ > But I think there is some compelling properties of having a symmetric > PoP key and a Raw Public Key (D)TLS. In this case the Public key of = the > RS can be distributed to the client in the client information (the > attributes accompanying the token) from AS and the PoP key as defined = by > PoP key distribution draft. With this setup the client can = authenticate > the server at connection time and then it can send its PoP token to > authorization information endpoint/resource at the RS (defined in > draft-ietf-ace-oauth-authz as an alternative to the HTTP Authorization > header) to authorize the client. >=20 >=20 > In this case you need to perform an additional proof-of-possession = step. Worse, we have to define a new protocol for this. >=20 > But we are defining that in OSCoAP and OSCON, that would be used to = validate data/requests from the client. while validating data from the = server by having the trusted connection with the RPK >=20 >=20 > @OAuth: It is not really clear to me from reading the PoP drafts, what = the acceptable proof-of-possession methods are. Is this some work that = the WG is planning to do? >=20 > I think this is what you are looking for > https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-02 = > Signed HTTP request >=20 > In my opinion it would be good if OSCoAP would be similar, or that one = would create a mapping of that draft to CoAP. > =20 >=20 >=20 > /Ludwig >=20 >=20 >=20 >=20 > --=20 > Ludwig Seitz, PhD > SICS Swedish ICT AB > Ideon Science Park > Building Beta 2 > Scheelev=C3=A4gen 17 > SE-223 70 Lund >=20 > Phone +46(0)70 349 9251 > http://www.sics.se >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace = --Apple-Mail=_CDB46521-04C2-47A6-AB5C-8BF8B40BA2CA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
https://tools.ietf.org/html/draft-ietf-oauth-signed-http-reques= t-02 
Is one proposal but is tightly bound to HTTP.

We are planning on doing = one for TLS client Auth, and perhaps token binding in the OAuth = WG.

John = B.

On Feb 9, 2016, at 1:17 PM, Samuel Erdtman <samuel@erdtman.se> = wrote:

Hi,

see inline

On Mon, Feb 8, 2016 at 8:49 AM, Ludwig Seitz <ludwig@sics.se> wrote:
On 02/07/2016 06:24 = PM, Samuel Erdtman wrote:
Hi,

~snip~
But I think there is some = compelling properties of having a symmetric
PoP key and a = Raw Public Key (D)TLS. In this case the Public key of the
RS= can be distributed to the client in the client information (the
attributes accompanying the token) from AS and the PoP key as = defined by
PoP key distribution draft. With this setup the = client can authenticate
the server at connection time and = then it can send its PoP token to
authorization = information endpoint/resource at the RS (defined in
draft-ietf-ace-oauth-authz as an alternative to the HTTP = Authorization
header) to authorize the client.


In this = case you need to perform an additional proof-of-possession step. Worse, = we have to define a new protocol for this.

But we are defining = that in OSCoAP and OSCON, that would be used to validate data/requests = from the client. while validating data from the server by having the = trusted connection with the RPK


@OAuth:= It is not really clear to me from reading the PoP drafts, what the = acceptable proof-of-possession methods are. Is this some work that the = WG is planning to do?

I think this is what you are looking = for
https://tools.ietf.org/html/draft-ietf-oauth-signed-http-reques= t-02
Signed HTTP = request

In my = opinion it would be good if OSCoAP would be similar, or that one would = create a mapping of that draft to CoAP.
  


/Ludwig




-- 
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 9251
http://www.sics.se


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

= --Apple-Mail=_CDB46521-04C2-47A6-AB5C-8BF8B40BA2CA-- --Apple-Mail=_A57B39AB-DA56-428F-A722-BF98A5A4B74F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAyMDkxNjI0MzdaMCMGCSqGSIb3DQEJBDEWBBRMNMwjwhRuqp5jyHvgYrpg 1eKngzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAB/0I1tb1HP00t6+tYbuvajwgXbhONNvreUPiPdKJ00CSPbCvgVulF LlvvThX0U4IXQgIL+T74IMYwmo/kybcq54VrdAizEUYSMyF2zBPB+RSUu2suf0s+gqGK2XrHvQi4 Mo+6MxrUYI3RqmbeeBAdKq6ZSvwi1YvhHcSxvFDMIDyACtohABJhGoqemgEs+2qswZFH17zeFn9C bBRjdSzl99say+bDnN5fczOI1fvViC/sEB1MM+/JTWFlTvcbQObAlbGo8Xuo99ZI/1QdyaUJJB63 /EaVQBERVO6ykDFo4eY0G3UWbeIBW57iP3zxPv8GTLvQjjFAR0jpYSvZTWvQAAAAAAAA --Apple-Mail=_A57B39AB-DA56-428F-A722-BF98A5A4B74F-- From nobody Tue Feb 9 15:43:34 2016 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 72E7D1B2CAE for ; Mon, 8 Feb 2016 07:04:17 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=unavailable 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 0tC3HcxDMDsm for ; Mon, 8 Feb 2016 07:04:15 -0800 (PST) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C361B2CA3 for ; Mon, 8 Feb 2016 07:04:15 -0800 (PST) Received: by mail-qg0-x22f.google.com with SMTP id y9so114628806qgd.3 for ; Mon, 08 Feb 2016 07:04:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rpMXDMmAOLKUAvIbqtc3MnPu23bg+sDGGxeIPQBgaT0=; b=2QvQllZ6u+lqg6+PrEL4/HL/3oz1iV1o7EhMahF7JH4YEN1GGcODEn2I/muAsqVn7H ihzy8v+UxhRVLxSMSKbkdzOKGAESho2dwooWKV0Sg//6WHa9TJt0m9Wi7K0xp3JE5wp8 4D3nQW1+EUlfwuhriifIOD9NEnROCyAY3+H5bRyd9ZqVXuWC6hQs104xfc+JAjdWUv5h fKFdEKrJl/mmJaOrBayJhflPFRrCctiWIcgtpm3XcOyNIEYI3shl9CstmC/FvFAlkf3B +1LpJkStZB7c1dvbQLIswhWOFdm0XAGNKroFdM8u4z1bf0bYDK3u3s9p7ozot+BLn+2g kidA== 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=rpMXDMmAOLKUAvIbqtc3MnPu23bg+sDGGxeIPQBgaT0=; b=isaaSdV5X9pzChOjlLDfk/WysVPICAPwaJtRCb4yN0o+yodfnGXDQ3o8MLBE52OwIP bu8URwRJUifPW8jnSQmNtCSUncDjrAbzW2qV99/+x7MpPYEk9pP4o/jfdVZVG5IgHh+7 htwBOA1hBv25tU/xRBF0ox2N1CvJVUvd4ggWXcwJ2dL45nPxbTAI8W3yfJlHGGDU0MdV vSwQxwmCKr0JvGAFzM+A+XJDx3xiPVCct4YE767nxiilfWhdZ+vbqTi8orOhWABXDyCv yLfyhZDUZ3iEOOogfn3/glQNyZoFSkC/F7nQqCDbrsiaTVXUuV/vjJwpoCuy8GYGW+uj WL/w== X-Gm-Message-State: AG10YOR2WusgvpWWWclLYeSUTsu8A9uK6DYRiYCpK5omSOauui6BCCx/s5Ouk1ojjdD0kQ== X-Received: by 10.140.162.2 with SMTP id i2mr37167437qhi.44.1454943854366; Mon, 08 Feb 2016 07:04:14 -0800 (PST) Received: from [192.168.1.68] ([191.115.87.228]) by smtp.gmail.com with ESMTPSA id x136sm14069824qka.0.2016.02.08.07.04.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 08 Feb 2016 07:04:13 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: <56B45DA7.6040408@sics.se> Date: Mon, 8 Feb 2016 12:04:05 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <82E817C1-B95F-4E08-A7BC-E11164FFDD61@ve7jtb.com> References: <56B31FEB.4010204@sics.se> <16330.1454596303@obiwan.sandelman.ca> <56B36703.8060305@sics.se> <36D7AE64-51CB-4437-AC28-9F912CD6B0D9@ve7jtb.com> <56B45DA7.6040408@sics.se> To: Ludwig Seitz X-Mailer: Apple Mail (2.3112) Archived-At: X-Mailman-Approved-At: Tue, 09 Feb 2016 15:43:32 -0800 Cc: Michael Richardson , oauth@ietf.org, ace@ietf.org Subject: Re: [Ace] [OAUTH-WG] Questions about OAuth and DTLS 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, 08 Feb 2016 15:04:17 -0000 The RS is going to have to advertise what presentment mechanisms it = supports. We don=92t have that yet. I suspect that it might be part of OAuth = Discovery. Currently that mostly cover AS discovery, but for the RS I = could see doing a head on the resource and getting back a link to a JSON = document that would contain meta-data about the RS. The standard OAuth answer to this question is the client would get it = from the service documentation, but that is not really scalable. > On Feb 5, 2016, at 5:30 AM, Ludwig Seitz wrote: >=20 > On 02/04/2016 05:14 PM, John Bradley wrote: >> In https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution >>=20 >> The proof key is included in the access token or provided out of = band. >>=20 >> The proof mechanism to the RS is what would determine if the key type = needs to match DTLS . >> If the proof is DTLS then they would need to match. >>=20 >=20 > Thank you John, this leads me to another question (maybe I just missed = it in the PoP drafts): Who decides what the proof mechanism should be? = How is the proof mechanism signaled to the client (the client may = support several proof mechanisms)? >=20 > /Ludwig >=20 >=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 9251 > http://www.sics.se >=20 From nobody Tue Feb 9 15:43:35 2016 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 5DA391B2FF0; Mon, 8 Feb 2016 09:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 k3MkoX8D94qy; Mon, 8 Feb 2016 09:52:30 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.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 A4ECF1B3030; Mon, 8 Feb 2016 09:52:30 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u18HqQQt005764 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Feb 2016 17:52:27 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u18HqQmU017059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 8 Feb 2016 17:52:26 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u18HqNIt032765; Mon, 8 Feb 2016 17:52:24 GMT Received: from [192.168.1.23] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Feb 2016 09:52:23 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13D15) In-Reply-To: <82E817C1-B95F-4E08-A7BC-E11164FFDD61@ve7jtb.com> Date: Mon, 8 Feb 2016 09:52:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56B31FEB.4010204@sics.se> <16330.1454596303@obiwan.sandelman.ca> <56B36703.8060305@sics.se> <36D7AE64-51CB-4437-AC28-9F912CD6B0D9@ve7jtb.com> <56B45DA7.6040408@sics.se> <82E817C1-B95F-4E08-A7BC-E11164FFDD61@ve7jtb.com> To: John Bradley X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: X-Mailman-Approved-At: Tue, 09 Feb 2016 15:43:32 -0800 Cc: Michael Richardson , Ludwig Seitz , oauth@ietf.org, ace@ietf.org Subject: Re: [Ace] [OAUTH-WG] Questions about OAuth and DTLS 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, 08 Feb 2016 17:52:37 -0000 There is a more general problem in PaaS deployment about how RA and AS infra= structure discover and coordinate with each other. For the most part this ha= sn't been necessary since usually the AS and RS are controlled by the same a= dmins. But in PaaS/IaaS the requirements vary widely.=20 How does an RS indicate to an AS what tokens it is able to support (directly= or indirectly via a security module). And then subsequently for the as and r= s to let the client know? We need to broaden discovery to cover all the scenarios so that automated an= d secure config of AS/RS/Tkn/Reg/RS entities works.=20 Phil > On Feb 8, 2016, at 07:04, John Bradley wrote: >=20 > The RS is going to have to advertise what presentment mechanisms it suppor= ts. >=20 > We don=E2=80=99t have that yet. I suspect that it might be part of OAuth= Discovery. Currently that mostly cover AS discovery, but for the RS I coul= d see doing a head on the resource and getting back a link to a JSON documen= t that would contain meta-data about the RS. >=20 > The standard OAuth answer to this question is the client would get it from= the service documentation, but that is not really scalable. >=20 >=20 >> On Feb 5, 2016, at 5:30 AM, Ludwig Seitz wrote: >>=20 >> On 02/04/2016 05:14 PM, John Bradley wrote: >>> In https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution >>>=20 >>> The proof key is included in the access token or provided out of band. >>>=20 >>> The proof mechanism to the RS is what would determine if the key type ne= eds to match DTLS . >>> If the proof is DTLS then they would need to match. >>=20 >> Thank you John, this leads me to another question (maybe I just missed it= in the PoP drafts): Who decides what the proof mechanism should be? How is t= he proof mechanism signaled to the client (the client may support several pr= oof mechanisms)? >>=20 >> /Ludwig >>=20 >>=20 >> --=20 >> Ludwig Seitz, PhD >> SICS Swedish ICT AB >> Ideon Science Park >> Building Beta 2 >> Scheelev=C3=A4gen 17 >> SE-223 70 Lund >>=20 >> Phone +46(0)70 349 9251 >> http://www.sics.se >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Feb 10 05:20:12 2016 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 69CE01B2A1C for ; Wed, 10 Feb 2016 05:20:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 SZ2EkN9aX_Mn for ; Wed, 10 Feb 2016 05:20:05 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D7091B29F2 for ; Wed, 10 Feb 2016 05:20:04 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id j78so11458507lfb.1 for ; Wed, 10 Feb 2016 05:20:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wahlstromstekniska-se.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Tt7W14t+ZlPIsI5Ns/nPqDhTUpiDthfCVwbpStVr69Y=; b=k9woF727JZBOYmgYXRcFaYrFio4HqkQLc7AC2YKxSWcgUsW1diSfgDreHEf69/vwya A3oiG4dt57qoqcmp1UOvIo2t1UKjpfKUPwMwJNYgQGme4QtxEuMGXmLLBjfPIEMIJ5PR O2U5O3HndskFjgyhkGejKf3hdfPnxE+2udSTGH77zEUvJay4vIS/yX00um++cSDpmnEI ry6LS1NRA2whkBacoqyhfN3zP0mAmd8Fau6ChaOiOSzne+hRJPZrIJiSmPAmm1W1RUoA 2CqSW+kp+leDJAlsxY+H2XJ7QBQZVM+MLYts1YVo9HRauZggmczz8oprB/mRDI/Zkjk3 mYJA== 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:message-id:references:to; bh=Tt7W14t+ZlPIsI5Ns/nPqDhTUpiDthfCVwbpStVr69Y=; b=XSlVR0MOd6NMsM03+sbMasanrls3Jf536pQ5ubr2njj6qJf7hQ6c1u7qCAvpXkRBlM JF47kJ2UG1urAS9h4/rL5z/JosQIJfVhAkdkkhh+hrMoreSDcZ2lPaCHmWdIyKbEz1BZ hogKdUn4IoRWtGhOmZNM13efsfe4dS8SSg2ZTwg2PE4IrAjIZtA7XFofe4+wF/jsLZhL 8Hdb+fSN9YAWUyL5bbeY0mgWN3c8bKhq0DGAmwvm1Cjz2S8XN+YHrO4aAqSH65RghUrC W0vhzPbVpiexUL8AFcmEj+vakmF2GgXd0SRvGaYv/zR5Z8+8UASc9V/3irPlD2CcRLhN j8OQ== X-Gm-Message-State: AG10YOQz+wTBaBLCRbZeRsHzRWyukrmzbQ1ZZ9P120o7AJOBKecMl2zdendp6w5ZlAhImg== X-Received: by 10.25.0.6 with SMTP id 6mr13777849lfa.132.1455110402611; Wed, 10 Feb 2016 05:20:02 -0800 (PST) Received: from [172.20.10.2] (c-5eeaaab6-74736162.cust.telenor.se. [94.234.170.182]) by smtp.gmail.com with ESMTPSA id rx3sm455647lbb.35.2016.02.10.05.20.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 10 Feb 2016 05:20:01 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_D3A91BDD-027B-46A3-B2A9-55F968F07244" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: =?utf-8?Q?Erik_Wahlstr=C3=B6m?= In-Reply-To: Date: Wed, 10 Feb 2016 14:19:59 +0100 Message-Id: <8C5A50B1-4932-41F7-BCEF-0707E6DE5351@wahlstromstekniska.se> References: <67780087-1D9F-4018-ADB8-724A2D0BEE81@um.es> <56A0F652.1050006@gmx.net> <56A7D04B.9000302@gmx.net> To: Renzo Navas X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Hannes Tschofenig , ace , Rafa Marin Lopez , =?utf-8?Q?G=C3=B6ran_Selander?= Subject: Re: [Ace] Time Requirements for Constrained Devices 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, 10 Feb 2016 13:20:10 -0000 --Apple-Mail=_D3A91BDD-027B-46A3-B2A9-55F968F07244 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, See below. > On 08 Feb 2016, at 11:52, Renzo Navas wrote: >=20 > Hi Hannes, Hi All, >=20 > Sorry for the late reply, I was out of work + out of ACE-ML; >=20 > I am glad Hannes that my message raised an interesting = debate/question. >=20 > I have not done advancements on the field since my last message; but > as I said my opinion is that we should have in account Resource > Servers that do not have Time Information. Otherwise I think demanding > Time-awareness at the RS is a very strong requirement (not so > constrained). >=20 > I am trying to come up with a AA solution+implementation for the > simplest Use Case I can think-of and that involves having a very > constrained RS (meaning no Real Time Clock nor time sync protocol); > The Proof-of-possession token solution is and ideal tool on this > constrained scenario as it will permit negotiate a fresh symmetric-key > between the previously unknown Client and the RServer. This Key will > be used to establish an authenticated secure channel between C and RS. > However as I discussed before, if no absolute time awareness is > present at RS: either we need token introspection, or we need another > flow of messages and a nonce-based approach to generate the shared > key/PoP Token. > I will go internally for the second option, but as Hannes mentioned > this adds complications for the revocation mechanism. >=20 >=20 > My opinion and belief, is that Use Cases where the RS do not have time > information will be very common on real deployments. >=20 > Either we can say that UC can be solved by token introspection, or we > will have to explore other solutions. I propose that we add this scenario to the section that describes the = functionality and rational behind introspection. This highlights the = requirement of resource servers without means of keeping time and the = fact that access token introspection is a solution for this. When we = have explored other solutions we can augment the draft by either adding = new sections or complement it with new drafts that detail this scenario. I propose that we change the text describing introspection in section = 3.1 = https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-00#section-3.1 = = to look like the following: Introspection: Introspection is a method for a resource server to query the authorization server for the active state and content of a received access token. This is particularly useful in those cases where the authorization decisions are very dynamic and/or where the received access token itself is a reference rather than a self-contained token. Resource servers that don't have the means to keep time can also offload the validation of timed access tokens to the introspection resource on the authorization server. More information about introspection in OAuth 2.0 can be found in [I-D.ietf-oauth-introspection]. Does that sounds reasonable. I=E2=80=99ll add it to the draft for now so = it will be in the -01 revision, but I=E2=80=99m open for feedback. / Erik >=20 > Regards and good start of the week! >=20 > Renzo >=20 >=20 >=20 > On Tue, Jan 26, 2016 at 9:00 PM, Hannes Tschofenig > wrote: >> Hi Goeran, >>=20 >> thanks for your response. >>=20 >> On 01/21/2016 06:40 PM, G=C3=B6ran Selander wrote: >>> Hi Hannes, >>>=20 >>> Good discussion input, some comments: >>>=20 >>> You write certificates, but CoAP also support raw public keys and >>> pre-shared keys. For these cases there is not necessarily time = related >>> information, is there? >>=20 >> It is true that with raw public keys and pre-shared secrets the >> situation is a bit different. Nevertheless the requirement for time >> information still does not necessarily disappear since there is still >> the access token that may contain claims like issued at, not before, = and >> an expiry date. >>=20 >>>=20 >>> If the use case does not allow the RS to be online with AS or time = server >>> at all times (for reasons of connectivity such as container use case = etc., >>> or for reasons of communication budget) then you are right that it = may not >>> be possible to verify change of permissions and revokation. >>=20 >> Correct. >>=20 >>>=20 >>> But still it may be possible for the RS to: >>> - invalidate short lived access tokens (counting down using internal = clock) >>> - verify that access tokens are not replayed (using nonce or = sequence >>> numbers) >>> which is sufficient in terms of timely authorization in some cases. >>=20 >> Access tokens don't contain sequence numbers or nonces since = otherwise >> they will become on-time-tokens. >>=20 >> Using an "internal clock" is not sufficient since such a real-time = clock >> needs to have a reference to know whether a "short lived token" is >> indeed fresh. >>=20 >>>=20 >>> Furthermore a client may have access to the AS even if the RS = doesn=E2=80=99t, and >>> through a new access token provide fresh information to the RS. (The = RS >>> would in this case not know that an access token is recent, but in = case of >>> sequence numbers that it is more recent than previous.) >>=20 >> It is indeed possible that the client may have access to the AS but = you >> are in essence suggesting >> * one-time-tokens, and >> * keeping state (such as a sequence number) at the RS. >>=20 >>=20 >>>=20 >>> I think we should support deployments which does not require RS to = keep >>> external time, and accept that those deployments will not be able to >>> support immediate revocation. >>=20 >> The problem is that it come for free. So, we need to make an informed >> decision. For that reason I am reaching out to folks in this group to >> determine whether there is indeed interest in deploying such = solutions. >>=20 >> Ciao >> Hannes >>>=20 >>> G=C3=B6ran >>>=20 >>>=20 >>>=20 >>> On 2016-01-21 16:16, "Ace on behalf of Hannes Tschofenig" >>> wrote: >>>=20 >>>> Hi Renzo, Hi all, >>>>=20 >>>> thanks for your review comment since you raise a bigger issue. The >>>> review feedback was recorded as issue#12 at >>>> https://github.com/LudwigSeitz/ace-oauth/issues/12 >>>>=20 >>>> You are asking what our requirements for the Resource Server (RS) = are >>>> with regard to the availability of time information (and the = accuracy of >>>> it). Our solution building blocks currently require time = information, >>>> such as certificates and access tokens. >>>>=20 >>>> In your email write-up, see >>>> http://www.ietf.org/mail-archive/web/ace/current/msg01554.html, you >>>> correctly pointed out that there is a relationship with the = validity of >>>> the authorization information and with a potential revocation = mechanism. >>>>=20 >>>> Before we start working on solutions I would like to get a sense of = the >>>> group what the views are. For resource servers do you consider to >>>> incorporate a real-time clock and a protocol mechanism that obtains = time >>>> information? >>>>=20 >>>> Not having time information at the RS will have the following = impact: >>>>=20 >>>> * The RS somehow has to get information about access tokens where >>>> permissions have changed, where the access tokens have been revoked = or >>>> have otherwise been invalidated since the tokens do not contain = validity >>>> information. >>>> * Time-related information in certificates cannot be checked. >>>>=20 >>>> In many situations we will have a tradeoff between the availability = of >>>> time information and the required communication overhead for = interacting >>>> with an authorization server to obtain up-to-date information about = the >>>> validity of the credentials. >>>>=20 >>>> What does the group think? >>>>=20 >>>> Ciao >>>> Hannes >>>>=20 >>>>=20 >>>> On 11/19/2015 10:19 AM, Rafa Marin Lopez wrote: >>>>> Hi Renzo: >>>>>=20 >>>>> I agree with you that if we consider the distribution of a = symmetric >>>>> key between three parties the literature is full of very concise = and >>>>> security proven protocols. >>>>>=20 >>>>> Please count on me if some help is required in this area. >>>>>=20 >>>>> Best Regards. >>>>>=20 >>>>>=20 >>>>>> El 13 nov 2015, a las 17:30, Renzo Navas >>>>>> escribi=C3=B3: >>>>>>=20 >>>>>> Good Evening ACE ML, >>>>>>=20 >>>>>> Reading draft-seitz-ace-oauth-authz-00 (thanks to the authors for = easy >>>>>> to read doc) I was very interested by the PoP token that offers = an >>>>>> authenticated fresh key to be used for further secure the comm., >>>>>> but I saw a very strong requirement for the RS to have a Time = Sync. >>>>>> mechanism. >>>>>> I preview the objective of my mail, is to raise the question: >>>>>>=20 >>>>>> * Do we want to have a strong requirement for the constrained = device >>>>>> (RS) on an AA Architecture to have a Time Synchronization = mechanism? >>>>>> * Are we interested on offering non-time -nonce- based solution = for an >>>>>> OAuth PoP Token approach (for example when the token does not = expire)? >>>>>>=20 >>>>>>=20 >>>>>> (those interested on those concerns can read the rest of the = mail, >>>>>> that is rather long) >>>>>>=20 >>>>>> Regards >>>>>>=20 >>>>>> ------------------------------------------------------- >>>>>>=20 >>>>>> (Long version) >>>>>>=20 >>>>>> I've been working lately on the Authenticated Key Establishment >>>>>> problem (The are two very good reference books [1][2]), focusing = on >>>>>> solutions with a Trusted Third Party, Symmetric Crypto, and not = using >>>>>> Time-stamps but Nonces (To avoid having to deal with time >>>>>> synchronization).I have no strong Crypto background. >>>>>>=20 >>>>>> First I want to thank the authors of = draft-seitz-ace-oauth-authz-00 , >>>>>> very enlightening for the oauth neophytes. >>>>>> I'm mostly interested on the authentication problem (auth. key >>>>>> establishment), so the Proof-of-Possesion Token is a great >>>>>> tool/concept, I took the time to read >>>>>> draft-ietf-oauth-pop-architecture-05 and >>>>>> draft-ietf-oauth-pop-key-distribution-02 to try to have all the >>>>>> background possible. >>>>>>=20 >>>>>> So from the Authenticated key establishment mechanism point of = view a >>>>>> new fresh key between C and RS obtained by means of a PoP Token >>>>>> mechanism -I think- will be similar to a Denning-Sacco shared = key >>>>>> protocol ( >>>>>> http://www.lsv.ens-cachan.fr/Software/spore/denningSacco.html >>>>>> . Client is A, AS is S, and RS is B), with the difference that = the PoP >>>>>> Token Timestamp have a start and end value that will make the >>>>>> "mutiplicity attack" of Denning-Sacco limited on time. >>>>>>=20 >>>>>> My concern is that we will always need Time sync on the RS, that = some >>>>>> (most) times will be the constrained node (I think that the = Client >>>>>> does not need to be Time-aware), is that a MUST requirement? So >>>>>> no-time aware devices will not be able to use OAuth PoP Token (or = will >>>>>> have to use token introspection, a good fallback solution btw) >>>>>>=20 >>>>>> Will be of interest offering a PoP Token generation and transport >>>>>> mechanisms that offers an authenticated fresh key without the = need of >>>>>> Time-awarenness at the RS? >>>>>>=20 >>>>>> Time awareness at the RS offers great advantages, and maybe also = Time >>>>>> is always needed in all authorization solutions (to make easy = token >>>>>> expiration and freshness claims). >>>>>>=20 >>>>>> But I'm thinking about nonce-based authenticated key = establishment. Of >>>>>> course without time information embedded on the token, token >>>>>> expiration will be more difficult: >>>>>> * we will need token introspection, or >>>>>> * the AS will contact the RS to revoke tokens, or >>>>>> * we will need on a non-time based solution for revocation that = does >>>>>> not involve the AS, for example: a pop token/key is valid for use = only >>>>>> for one (or N) Resource Requests (of course if the response = message >>>>>> get lost we are screwed...) >>>>>>=20 >>>>>>=20 >>>>>> So maybe we cannot avoid to have Time-awareness at the RS, for >>>>>> Authorization purposes.. >>>>>> But for Authentication certainly we can avoid Time, the three = most >>>>>> recommended by [2] nonce-based protocols are: >>>>>> * Bellare-Rogaway (3PKD) [a Choo modified version It has been = proven >>>>>> provably secure on the strongest model to test auth. key = establishment >>>>>> protocols ] [3] >>>>>> * Yahalom [a modified version has been proven secure on a weaker = model >>>>>> -bellare rogway- than 3PKD] [4] >>>>>> * Boyd [Key Agreement: RS, C and AS contribute inputs to generate = the >>>>>> key] [proof idem yahalom ][5] >>>>>>=20 >>>>>> The message flows on that three of protocols do not respect OAuth >>>>>> flows (I attach an image with the high level message flows, A is = the >>>>>> initiator always), so that take us apart a bit from OAuth... >>>>>>=20 >>>>>> This mail is starting to get long so I will try to conclude it, = but >>>>>> hopefully raise the question: >>>>>>=20 >>>>>>=20 >>>>>> ** Are we interested on offering non-time -nonce- based solution = for >>>>>> an OAuth PoP Token approach (for example when the token does not >>>>>> expire)**? >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> If NO, I guess that will need token introspection for RS that = cannot >>>>>> support time (That mechanism will map to other authenticated key >>>>>> establishment protocol and not Denning-Sacco-based ) >>>>>>=20 >>>>>> if YES, are we interested in adapting a nonce-based auth. key >>>>>> establishment protocol to OAuth PoP Token? >>>>>>=20 >>>>>>=20 >>>>>> I hope this questions are useful, >>>>>>=20 >>>>>> Best regards >>>>>>=20 >>>>>> Renzo >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> [1] Colin A. Boyd and Anish Mathuria. 2003. Protocols for Key >>>>>> Establishment and Authentication. Springer-Verlag New York, Inc., >>>>>> Secaucus, NJ, USA. >>>>>> [2] Kim-Kwang Raymond Choo. 2008. Secure Key Establishment = (1ed.). >>>>>> Springer Publishing Company, Incorporated. >>>>>>=20 >>>>>> [3] 3PKD - >>>>>> = http://eprints.qut.edu.au/1230/1/ACISP_Full_Version_-_03_May_2005.pdf >>>>>> [4] Yahalom - https://eprint.iacr.org/2007/188.pdf >>>>>> [5] Boyd - http://eprints.qut.edu.au/4421/1/4421_1.pdf >>>>>>=20 >>>>>> = ____________________________________ >>>>>> ___________ >>>>>> Ace mailing list >>>>>> Ace@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ace >>>>>=20 >>>>> ------------------------------------------------------- >>>>> Rafael Marin Lopez, PhD >>>>> Dept. Information and Communications Engineering (DIIC) >>>>> Faculty of Computer Science-University of Murcia >>>>> 30100 Murcia - Spain >>>>> Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es >>>>> ------------------------------------------------------- >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Ace mailing list >>>>> Ace@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ace >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --Apple-Mail=_D3A91BDD-027B-46A3-B2A9-55F968F07244 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

See = below.

On = 08 Feb 2016, at 11:52, Renzo Navas <renzoefra@gmail.com>= wrote:

Hi = Hannes, Hi All,

Sorry for the late reply, I = was out of work + out of ACE-ML;

I am glad = Hannes that my message raised an interesting debate/question.

I have not done advancements on the field = since my last message; but
as I said my opinion is that we = should have in account Resource
Servers that do not have = Time Information. Otherwise I think demanding
Time-awareness= at the RS is a very strong requirement (not so
constrained).

I am trying to = come up with a AA solution+implementation for the
simplest = Use Case I can think-of and that involves having a very
constrained RS (meaning no Real Time Clock nor time sync = protocol);
The Proof-of-possession token solution is and = ideal tool on this
constrained scenario as it will permit = negotiate a fresh symmetric-key
between the previously = unknown Client and the RServer. This Key will
be used to = establish an authenticated secure channel between C and RS.
However as I discussed before, if no absolute time awareness = is
present at RS: either we need token introspection, or = we need another
flow of messages and a nonce-based = approach to generate the shared
key/PoP Token.
I will go internally for the second option, but as Hannes = mentioned
this adds complications for the revocation = mechanism.


My opinion and = belief, is that Use Cases where the RS do not have time
information will be very common on real deployments.

Either we can say that UC can be solved by = token introspection, or we
will have to explore other = solutions.

I propose that we add this scenario to the section = that describes the functionality and rational behind introspection. This = highlights the requirement of resource servers without means of keeping = time and the fact that access token introspection is a solution for = this. When we have explored other solutions we can augment the draft by = either adding new sections or complement it with new drafts that detail = this scenario.

I propose that we = change the text describing introspection in section 3.1 https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-00#secti= on-3.1 to look like the following:


  =  Introspection:

      Introspection is a method for a resource = server to query the
      authorization server for the active = state and content of a
      received access token.  This is = particularly useful in those cases
      where the authorization decisions = are very dynamic and/or where
      the received access token itself is = a reference rather than a
      self-contained token.  Resource = servers that don't have the means
      to keep time can also offload the = validation of timed access
      tokens to the introspection resource on = the authorization server.
      More information about introspection in = OAuth 2.0 can be found in
      = [I-D.ietf-oauth-introspection].

Does that sounds reasonable. I=E2=80=99ll = add it to the draft for now so it will be in the -01 revision, but I=E2=80= =99m open for feedback.

/ = Erik



Regards and good = start of the week!

Renzo



On Tue, Jan 26, 2016 at 9:00 = PM, Hannes Tschofenig
<hannes.tschofenig@gmx.net> wrote:
Hi Goeran,

thanks for your response.

On 01/21/2016 06:40 PM, G=C3=B6ran Selander wrote:
Hi Hannes,

Good discussion input, some comments:

You write certificates, but CoAP also support = raw public keys and
pre-shared keys. For these cases there = is not necessarily time related
information, is there?

It is true that with raw public = keys and pre-shared secrets the
situation is a bit = different. Nevertheless the requirement for time
information= still does not necessarily disappear since there is still
the access token that may contain claims like issued at, not = before, and
an expiry date.


If the = use case does not allow the RS to be online with AS or time server
at all times (for reasons of connectivity such as container = use case etc.,
or for reasons of communication budget) = then you are right that it may not
be possible to verify = change of permissions and revokation.

Correct.


But still it may be possible for the RS = to:
- invalidate short lived access tokens (counting down = using internal clock)
- verify that access tokens are not = replayed (using nonce or sequence
numbers)
which is sufficient in terms of timely authorization in some = cases.

Access tokens don't = contain sequence numbers or nonces since otherwise
they = will become on-time-tokens.

Using an = "internal clock" is not sufficient since such a real-time clock
needs to have a reference to know whether a "short lived = token" is
indeed fresh.


Furthermore= a client may have access to the AS even if the RS doesn=E2=80=99t, = and
through a new access token provide fresh information = to the RS. (The RS
would in this case not know that an = access token is recent, but in case of
sequence numbers = that it is more recent than previous.)

It is indeed possible that the client may have access to the = AS but you
are in essence suggesting
* = one-time-tokens, and
* keeping state (such as a sequence = number) at the RS.



I think we should support = deployments which does not require RS to keep
external = time, and accept that those deployments will not be able to
support immediate revocation.

The problem is that it come for free. So, we need to make an = informed
decision. For that reason I am reaching out to = folks in this group to
determine whether there is indeed = interest in deploying such solutions.

CiaoHannes

G=C3=B6ran



On 2016-01-21 16:16, "Ace on behalf of Hannes Tschofenig"
<ace-bounces@ietf.org on behalf of hannes.tschofenig@gmx.net> wrote:

Hi Renzo, Hi all,

thanks for your review comment since you raise = a bigger issue. The
review feedback was recorded as = issue#12 at
https://github.com/LudwigSeitz/ace-oauth/issues/12

You are asking what our requirements for the = Resource Server (RS) are
with regard to the availability = of time information (and the accuracy of
it). Our solution = building blocks currently require time information,
such = as certificates and access tokens.

In your = email write-up, see
http://www.ietf.org/mail-archive/web/ace/current/msg01554.html,= you
correctly pointed out that there is a relationship = with the validity of
the authorization information and = with a potential revocation mechanism.

Before= we start working on solutions I would like to get a sense of the
group what the views are. For resource servers do you = consider to
incorporate a real-time clock and a protocol = mechanism that obtains time
information?

Not having time information at the RS will have the following = impact:

* The RS somehow has to get = information about access tokens where
permissions have = changed, where the access tokens have been revoked or
have = otherwise been invalidated since the tokens do not contain validity
information.
* Time-related information in = certificates cannot be checked.

In many = situations we will have a tradeoff between the availability of
time information and the required communication overhead for = interacting
with an authorization server to obtain = up-to-date information about the
validity of the = credentials.

What does the group think?

Ciao
Hannes


On 11/19/2015 10:19 AM, Rafa Marin Lopez = wrote:
Hi Renzo:

I agree with you that if we consider the = distribution of a symmetric
key between three parties the = literature is full of very concise and
security proven = protocols.

Please count on me if some help = is required in this area.

Best Regards.


El 13 nov 2015, a las 17:30, Renzo Navas = <renzoefra@gmail.com>
escribi=C3=B3:
Good Evening ACE ML,

Reading = draft-seitz-ace-oauth-authz-00 (thanks to the authors for easy
to read doc) I was very interested by the PoP token that = offers an
authenticated fresh key to be used for further = secure the comm.,
but I saw a very strong requirement for = the RS to have a Time Sync.
mechanism.
I = preview the objective of my mail,  is to raise the question:

* Do we want to have a strong requirement for = the constrained device
(RS) on an AA Architecture to have = a Time Synchronization mechanism?
* Are we interested on = offering non-time -nonce- based solution for an
OAuth PoP = Token approach (for example when the token does not expire)?


(those interested on those = concerns can read the rest of the mail,
that is rather = long)

Regards

-------------------------------------------------------

(Long version)

I've= been working lately on the Authenticated Key Establishment
problem (The are two very good reference books [1][2]), = focusing on
solutions with a Trusted Third Party, = Symmetric Crypto, and not using
Time-stamps but Nonces (To = avoid having to deal with time
synchronization).I have no = strong Crypto background.

First I want to = thank the authors of draft-seitz-ace-oauth-authz-00 ,
very = enlightening for the oauth neophytes.
I'm mostly = interested on the authentication problem (auth. key
establishment), so the Proof-of-Possesion Token is a great
tool/concept, I took the time to read
draft-ietf-oauth-pop-architecture-05 and
draft-ietf-oauth-pop-key-distribution-02 to try to have all = the
background possible.

So = from the Authenticated key establishment mechanism point of view a
new fresh key between C and RS obtained by means of a =  PoP Token
mechanism -I think- will be similar to a =  Denning-Sacco shared key
protocol (
http://www.lsv.ens-cachan.fr/Software/spore/denningSacco.html. Client is A, AS is S, and RS is B), with the difference = that the PoP
Token Timestamp have a start and end value = that will make the
"mutiplicity attack" of Denning-Sacco = limited on time.

My concern is that we will = always need Time sync on the RS, that some
(most) times = will be the constrained node (I think that the Client
does = not need to be Time-aware), is that a MUST requirement? So
no-time aware devices will not be able to use OAuth PoP Token = (or will
have to use token introspection, a good fallback = solution btw)

Will be of interest offering = a PoP Token generation and transport
mechanisms that =  offers an authenticated fresh key without the need of
Time-awarenness at the RS?

Time = awareness at the RS offers great advantages, and maybe also Time
is always needed in all authorization solutions (to make easy = token
expiration and freshness claims).

But I'm thinking about nonce-based authenticated key = establishment. Of
course without time information embedded = on the token, token
expiration will be more difficult:
* we will need token introspection, or
* the AS = will contact the RS to revoke tokens, or
* we will need on = a non-time based solution for revocation that does
not = involve the AS, for example: a pop token/key is valid for use only
for one (or N) Resource Requests (of course if the response = message
get lost we are screwed...)


So maybe we cannot avoid to have = Time-awareness at the RS, for
Authorization purposes..
But for Authentication certainly we can avoid Time, the three = most
recommended by [2] nonce-based protocols are:
* Bellare-Rogaway (3PKD) [a Choo modified version It has been = proven
provably secure on the strongest model to test = auth. key establishment
protocols ] [3]
* = Yahalom [a modified version has been proven secure on a weaker model
-bellare rogway- than 3PKD] [4]
* Boyd [Key = Agreement: RS, C and AS contribute inputs to generate the
key] [proof idem yahalom ][5]

The = message flows on that three of protocols do not respect OAuth
flows (I attach an image with the high level message flows, A = is the
initiator always), so that take us apart a bit from = OAuth...

This mail is starting to get long = so I will try to conclude it, but
hopefully raise the = question:


** Are we = interested on offering non-time -nonce- based solution for
an OAuth PoP Token approach (for example when the token does = not
expire)**?



If NO, I guess that will need token = introspection for RS that cannot
support time (That = mechanism will map to other authenticated key
establishment = protocol and not Denning-Sacco-based )

if = YES, are we interested in adapting a nonce-based auth. key
establishment protocol to OAuth PoP Token?


I hope this questions are useful,

Best regards

Renzo



[1] Colin A. Boyd and Anish Mathuria. 2003. Protocols for = Key
Establishment and Authentication. Springer-Verlag New = York, Inc.,
Secaucus, NJ, USA.
[2] Kim-Kwang = Raymond Choo. 2008. Secure Key Establishment (1ed.).
Springer Publishing Company, Incorporated.

[3] 3PKD -
http://eprints.qut.edu.au/1230/1/ACISP_Full_Version_-_03_May_20= 05.pdf
[4] Yahalom - = https://eprint.iacr.org/2007/188.pdf
[5] Boyd - = http://eprints.qut.edu.au/4421/1/4421_1.pdf

<Auth-Key-Establishmen-MsgFlows.png>_____________________= _______________
___________
Ace mailing = list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and = Communications Engineering (DIIC)
Faculty of Computer = Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------




_______________________________________________
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

= --Apple-Mail=_D3A91BDD-027B-46A3-B2A9-55F968F07244-- From nobody Wed Feb 10 06:46:35 2016 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 139851B2B87 for ; Wed, 10 Feb 2016 06:46:32 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 sYY9-vces7If for ; Wed, 10 Feb 2016 06:46:29 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8803A1B2B8D for ; Wed, 10 Feb 2016 06:46:28 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id j78so13082530lfb.1 for ; Wed, 10 Feb 2016 06:46:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=Ex0PzZ1Bgk5Y8Vr3SZ9ggyTcpzbD73ba2pz7+xU0vwI=; b=uaE2yb8P8CTnI246QMRc49un1lJJuRtLu8xhDLK4WBm4uO/oDsxNQaIcfKInbl7zKc t+PafKUVknNBlmUv9bnSEgbZ/+LMm9uTLARu4Um1twTdlmdD7NxHb4SkXrlxZXJQiUxJ UjuPRX4JEXmszVf5xh0JFH3DLeQ6+c0bNXEWXHWX8V3rYqifkUczLuy8fm5Ywz8qKOEz JsyN1dl8Gx6N8U0TrUrCvL43f2+m02V1X03ffMBIe8A3yWLzuL47PIfnGb0FO6H4VZuu ksglwJAJx0QenuYQFImD+B7fpet0QufQWYwyjgOXLQ0u8cLXzXsk/hB5ibkn3bmfDVI6 9IQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=Ex0PzZ1Bgk5Y8Vr3SZ9ggyTcpzbD73ba2pz7+xU0vwI=; b=Z69ZxLu9PU7TJljUNeCP84Mcexx1rU3W0Iej7aSXanUVnNLu68v2qmrfIqTsyZ7UN3 uc/jJgtkrBPKcXHAbn5QcAEDu76koaW27X8yRO3nAqbeIfF4sGKFdbv/7RlUplm1JSxe 0kBOSWnZyWVK0G6fxxLeEiAT8ijNedEcyja6j3yCZEbWks32ANtykfH0v0ZRWrwDfrQ1 PKtAdGwEm1PdN8hL6u9b3qU594PQIZ9fCiuYdqPs5Apu5xL9RNVi++uibGzdRsdgyNMU OnBtozieRE5c79h61F5NZSOBhjovB5OyppFgvk6G56CB6OY7Q5g2F2R+LSDRo96bOzJE IBHQ== X-Gm-Message-State: AG10YOQUoKKyTR93I7mNqPl67IdYszt9FltTY6KuZU5co40xO4cpx3BEUQJ5gSBdemhr8X7x X-Received: by 10.25.23.24 with SMTP id n24mr16822741lfi.66.1455115586660; Wed, 10 Feb 2016 06:46:26 -0800 (PST) Received: from Hyperion.suse ([85.235.10.186]) by smtp.gmail.com with ESMTPSA id ja4sm514388lbc.8.2016.02.10.06.46.25 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Feb 2016 06:46:25 -0800 (PST) To: ace@ietf.org References: <67780087-1D9F-4018-ADB8-724A2D0BEE81@um.es> <56A0F652.1050006@gmx.net> <56A7D04B.9000302@gmx.net> <8C5A50B1-4932-41F7-BCEF-0707E6DE5351@wahlstromstekniska.se> From: Ludwig Seitz Message-ID: <56BB4D41.7080101@sics.se> Date: Wed, 10 Feb 2016 15:46:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <8C5A50B1-4932-41F7-BCEF-0707E6DE5351@wahlstromstekniska.se> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090104050204000803060804" Archived-At: Subject: Re: [Ace] Time Requirements for Constrained Devices 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, 10 Feb 2016 14:46:32 -0000 This is a cryptographically signed message in MIME format. --------------ms090104050204000803060804 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 02/10/2016 02:19 PM, Erik Wahlstr=F6m wrote: > > I propose that we add this scenario to the section that describes the > functionality and rational behind introspection. This highlights the > requirement of resource servers without means of keeping time and the > fact that access token introspection is a solution for this. When we > have explored other solutions we can augment the draft by either adding= > new sections or complement it with new drafts that detail this scenario= =2E > The problem is that if a device is not able to keep accurate time, it=20 often coincides with also not being able to do real-time=20 over-the-network introspection. You have to consider that a very constrained device will struggle to=20 keep the security context for one secure connection in memory (together=20 with the internet protocol stack and the application it is running), if=20 we now say that it should also do introspection, we basically force it=20 to keep two secure connections in memory at the same time, and that is=20 not a good idea. /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 9251 http://www.sics.se --------------ms090104050204000803060804 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CtEwggTnMIIDz6ADAgECAhAfP2QWc8z7Bo71GhHCZ7DdMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMTA3MTE1NzM3WhcNMTcwMTA3MTE1NzM3WjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCiG5fxnXbdU0+3qInGZloXB0zZLM6XAu0EmTuCsWOU8eXN lCe37PTURORfLc3te4gCDcG1GrI2AuWR9MvlcYddMZt5y0T5BVWIu534vVJtG3QCuEYRJOTW B6RWQfK+dIPpZsNhgEQkYLjTHYoCu58gP0pfxNie1X7D+RxeQcq+ynNmyFdsxc2mI+dQqBKq 4zTsCNP4/jpSuovXTn8hEbbR8zkVQ2v/Gx+EO8oMIvkIEUYzkMxe3E9A7dq5DwotRDzP+y3g C4DCtI0tfIUtFjx18Pb5UMNUKZjitrOpXfheEz/igxziydri8bYpx4qGU9CNX+MvQG7Ogqju XKfQhUTTAgMBAAGjggGuMIIBqjALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFBMb8zf+BJ13fxqEl9gYiwxZ4hpmMB8G A1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCugKYYn aHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCBDmx1 ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNV HSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAbgRzIj1s9U5kpXodti5kdj3ztjPb oz4pz8zNwn3qPUW8c3Zd40IFe+R5hRDuIm2aa//fmwop2mLM3+5/LnSnacaDnRfE7pP3NgqX XUuuZf9TtMLU6RUh2Z9JKs0IzWKALPhoLgnCsbtYDrF4QAoVqeNV79Lb6a3r6KdB/xFErbee OkZk/iw9HCr/jnvysYjfFQcBounseJS3JG4RNIuDpfsWPupQSAhl4s0akaakiwqOHCU7x0Ra rbCN+bg+6R5FEtSouIh53Z04JmI7LU3leo/AseQiUpJ6HqQNJYjnsCw8DDbijNhH41ZZKrvB rKMfVvlCH9VqrKW4kPGajKMEJDCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJ KoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0 YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIx NjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNV BAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENv bSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL19 2vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk 9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89V LnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZ ZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8U lVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4G A1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/ BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9z ZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFy dHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2Nh LmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRA W6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4St DwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y 5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bj yOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfC BJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSi F3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odh QJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfr Bzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4W VWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9Vyrw MdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2de oprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAfP2QWc8z7Bo71 GhHCZ7DdMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNjAyMTAxNDQ2MjVaMC8GCSqGSIb3DQEJBDEiBCCRAHuzpHktyp4J csPSwHmc7t4gNTSbvXUiemlF1anHITBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQHz9kFnPM+waO9RoRwmew3TCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQ Hz9kFnPM+waO9RoRwmew3TANBgkqhkiG9w0BAQEFAASCAQAEfUsvrZTF8mJxQ7n9W4UvcUmV ti+TQsD26OktbmWcOo8DrhnKFX4a5IxJ+Wtn5h3u6NQFnD6+tJBu6t2S0oMS2VshIsvQijJS oT67fONehcVeVwgDfcePMCVeTDvHIlLAPIzON32t4dt+N6LRGzJaa6xzQBgwJJd4+xrenHBs +s5S2u2E+5+L57KoxHKEoXtXR8jzvWDo6O0w+IRw2bdZzo+A0/N7xaCOaev/RYJr20gmKURA MhaJAlgpj+P4uTGWJK1hat03s00/od/nW4tCFJOEkSoa78jhQ2616TJjhc+63OqstrkwQ1rX jSormirdPTHtNVvXDy32l5X1SjU+AAAAAAAA --------------ms090104050204000803060804-- From nobody Thu Feb 11 03:17:19 2016 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 2E6C31AD272 for ; Thu, 11 Feb 2016 03:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3] 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 67PjbpL4bztT for ; Thu, 11 Feb 2016 03:17:13 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF9161AD244 for ; Thu, 11 Feb 2016 03:17:12 -0800 (PST) Received: by mail-lb0-x231.google.com with SMTP id bc4so25779787lbc.2 for ; Thu, 11 Feb 2016 03:17:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wahlstromstekniska-se.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hLNqrUCQaID0kgToK6oU2YcYOpjFssqhQTk5hPxE0Gk=; b=gvgBz3uajpMmwNpeYGzJ0IlrQHsDWSJj5XtcQJVozOE3MnozPCp/alNwebJokXW6kS OYHAF/VBDKvwH9A2L78wYDKQxr0wAow/WRY6sXzit7lpciq0OHh++Is+ZcJ7qIv+uy7w LyYgJMntW/PKVcTP7r75yPi7T7cyj3EF1bIkSNGKqmd1sQ6q0zZWaHqdOMMhA5QEI9n3 0PcWzewvB4GCQJenBJm2ithaK3zAut/0GMWjVxxdaNJBp+v2kTOSSUH5FbbET6wrqvjE lIssuGaouUUxXYDrfn6pCvbP+rr2LZJg1jQDxZASWqcDA/UtA22ACCAdbUYbNace16NC uJPQ== 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=hLNqrUCQaID0kgToK6oU2YcYOpjFssqhQTk5hPxE0Gk=; b=OdK6/FdO/TswCGtwuigJzBIPHyyWaa7rvHeWygDz+vrIog0mW68mX/bbFDYXgq6XiE 7667Intpgw4wVS4J6dQ0UrQa7/4OzM1fIjdRkMLGU58Pl1qf+xYTbTwywhTEccZrnGmo 08rkIij+0QRFfLVpAmstUc7ngGZXyXK7fIrrzx2DRc+ppy7ShtPE+aIM9uY1I5miDVF2 uUE4A9cuG3Z3aQ3GW0p0h8CegWCWRHXrQasNBFyLKATIpQS01GHRnxq3SJqeZa03ICtv yyXtFc79WDj6PaYlFLxDLaw85Qt5Rl7AgxWs4Oj6ji/oBLDsaArFG/tvvNXvYFnx4UQp DGDw== X-Gm-Message-State: AG10YOR6W0b7KujpuG6Yc3gRWcxrQhrKVNiYpt2bBdEbXW5yfd9vs1ghl6ONkwqQRErJlA== X-Received: by 10.112.52.73 with SMTP id r9mr18048106lbo.64.1455189430617; Thu, 11 Feb 2016 03:17:10 -0800 (PST) Received: from [192.168.1.7] (37-247-26-197.customers.ownit.se. [37.247.26.197]) by smtp.gmail.com with ESMTPSA id i127sm1170105lfd.3.2016.02.11.03.17.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 11 Feb 2016 03:17:09 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: =?windows-1252?Q?Erik_Wahlstr=F6m?= In-Reply-To: <56BB4D41.7080101@sics.se> Date: Thu, 11 Feb 2016 12:17:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <67780087-1D9F-4018-ADB8-724A2D0BEE81@um.es> <56A0F652.1050006@gmx.net> <56A7D04B.9000302@gmx.net> <8C5A50B1-4932-41F7-BCEF-0707E6DE5351@wahlstromstekniska.se> <56BB4D41.7080101@sics.se> To: Ludwig Seitz X-Mailer: Apple Mail (2.2104) Archived-At: Cc: ace@ietf.org Subject: Re: [Ace] Time Requirements for Constrained Devices 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, 11 Feb 2016 11:17:15 -0000 I think it=92s one of those problems that=92s hard (i.e. not impossible) = to solve in the perfect way that's simple, secure and always up to date = with latest policies, especially with the diversity of both devices and = required security. - You either do a best effort and just validates the access token. - We would then also propose an alternative to get real time updates = using the introspection endpoint. - And third and last we would open up for potential future work being = done to solve it once and for all (as suggested in earlier discussions = on the list). I think that=92s a good level of commitment for first version. / Erik > On 10 Feb 2016, at 15:46, Ludwig Seitz wrote: >=20 > On 02/10/2016 02:19 PM, Erik Wahlstr=F6m wrote: >>=20 >> I propose that we add this scenario to the section that describes the >> functionality and rational behind introspection. This highlights the >> requirement of resource servers without means of keeping time and the >> fact that access token introspection is a solution for this. When we >> have explored other solutions we can augment the draft by either = adding >> new sections or complement it with new drafts that detail this = scenario. >>=20 >=20 > The problem is that if a device is not able to keep accurate time, it = often coincides with also not being able to do real-time = over-the-network introspection. > You have to consider that a very constrained device will struggle to = keep the security context for one secure connection in memory (together = with the internet protocol stack and the application it is running), if = we now say that it should also do introspection, we basically force it = to keep two secure connections in memory at the same time, and that is = not a good idea. >=20 > /Ludwig >=20 >=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 9251 > http://www.sics.se >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Mon Feb 22 04:59:46 2016 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 B051C1A6EE8 for ; Mon, 22 Feb 2016 04:59:44 -0800 (PST) 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 NWEBevNjw87Q for ; Mon, 22 Feb 2016 04:59:43 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4A141A3BA6 for ; Mon, 22 Feb 2016 04:59:42 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id s5so55055590qkd.0 for ; Mon, 22 Feb 2016 04:59:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type; bh=+K3sIG+zDXcmBzc4kuexRQ+fV60nCQKfGz5LmzJkcpg=; b=A1d+IoLSf5ZOgkwqJ9lWfhh+RCa19Ox+h62vf/3h9aAtckItAnRSVusQG9H7NQ7WDW JLSYUojD7nep6B5JvxtD5p3kE2ojtdKvTUh/bwKQVyr5+rcR2yjR9SKOi9HeV68qD00Y BpMDwtAWzGXm2v85ZUgdy8cTf0B4s0FAVZOIrgsH11xQHSu5dkLOVDmUNmuxds6rk6CD I2uLWaiCEU4syMSOWxEM0y8esCaJKZK77plfLTWGDAaFd9FPNDUtK2WMaNZfyX74iH3s 5EZU2QLydWl/EurnifyvkGkxyYnLUsd++bOv8CN0yNC1jiwV6/d5e1hojJhCpxuSMapa TQaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-type; bh=+K3sIG+zDXcmBzc4kuexRQ+fV60nCQKfGz5LmzJkcpg=; b=TyyQupwMkXd7p62su6EdI66navl1R9hLXQz4mtUxpZrYRkGvWg0SvuyHQS0G/ABC4b VQpsebBRWN2FJb26Hm33kdPReuBonESPh0RJNdce/MTKDGm8S8PDmYs4EGMZw7+4SHY6 LhSWdzusZtSbdQ0oic1wv8iKIcFRC1H13BtOAmhgO8tBRjs46hSUhURgHM25OAd8U1H/ 1kl6Vkodf8aVwYppNWftdOaGeduO/n6jon2i4vcRrBcMDgNF3Z7KIFmH0kTQY0FO/7oQ ye2+V18qkg+uWg+RorPSgLCT0yQ4jEaQtD3bkiF1rwsxlXlP5myKSFWbRz3C/FCCd5AK T14g== X-Gm-Message-State: AG10YOQKw0nTWTamBkWV4ASpU2yZLefXNInIK0zTWD26cjUhxLHrQsHvdaBIZDYieMEB9g== X-Received: by 10.55.203.23 with SMTP id d23mr9363287qkj.25.1456145981584; Mon, 22 Feb 2016 04:59:41 -0800 (PST) Received: from [192.168.1.65] (CPE84948c5cbf81-CM84948c5cbf80.cpe.net.cable.rogers.com. [99.224.83.138]) by smtp.googlemail.com with ESMTPSA id c61sm6550958qgc.24.2016.02.22.04.59.40 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Feb 2016 04:59:40 -0800 (PST) To: "Ace@ietf.org" From: Paul Madsen Message-ID: <56CB063D.7020701@gmail.com> Date: Mon, 22 Feb 2016 07:59:41 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------080708000408050401010800" Archived-At: Subject: [Ace] Review of draft-ietf-ace-oauth-authz-00 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, 22 Feb 2016 12:59:44 -0000 This is a multi-part message in MIME format. --------------080708000408050401010800 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I've read throughdraft-ietf-ace-oauth-authz-00 and thought I'd share my high-level feedback and some thoughts from conversations we have been having with our customers with IoT use cases - the approach of binding OAuth 2.0 to IoT use cases & protocols is critical, as the current default authentication mechanism for many devices appears to be passwords or certs burnt in at manufacture time - both of which have security & privacy implications - this sort of binding has been resonating with the customers I talk to, as it reuses for IoT use cases the conceptual model of user-mediated token issuance they know from their existing REST APIs & native application deployments. - while the consent step that that this model enables is critical for consumer IoT deployments (like customers with smart home offerings) it remains relevant even in workforce & IoT use cases where consent may be less of a concern, but supporting different employees sharing a given device over the work day (shop floor etc) is - importantly, the approach offers to enterprises the promise of being able to reuse their existing investments in OAuth (and related specs, e.g. OpenID Connect, JWT, JOSE etc). Even if they are not currently confronting IoT use cases, work such as this reassures enterprises that these standards will evolve as necessary, and that any OAuth servers they've bought will evolve in lockstep so that, when they do have to support authentication of/to constrained devices, they can be confident that their authentication & authorization infrastructure will be prepared - the customers who are imagining (or supporting) use cases beyond the simplest architecture of devices talking to its own cloud (with likely proprietary authn mechanisms) see the need for an interoperable identity layer by which, for instance, a device might have to interact with different devices or cloud endpoints and do so on behalf of different users, e.g. a smart home speaker calling streaming music APIs on behalf of the various family members in a household. I believe that the best bet for such an interoperable identity layer for IoT is one built on OAuth and related specs, while profiling/extending to new constraints & requirements. Work such as draft-ietf-ace-oauth-authz-00 is an important early step towards that Regards paul --------------080708000408050401010800 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi, I've read through draft-ietf-ace-oauth-authz-00 and thought I'd share my high-level feedback and some thoughts from conversations we have been having with our customers with IoT use cases

- the approach of binding OAuth 2.0 to IoT use cases & protocols is critical, as the current default authentication mechanism for many devices appears to be passwords or certs burnt in at manufacture time - both of which have security & privacy implications

- this sort of binding has been resonating with the customers I talk to, as it reuses for IoT use cases the conceptual model of user-mediated token issuance they know from their existing REST APIs & native application deployments. 

- while the consent step that that this model enables is critical for consumer IoT deployments (like customers with smart home offerings) it remains relevant even in workforce & IoT use cases where consent may be less of a concern, but supporting different employees sharing a given device over the work day (shop floor etc) is

- importantly, the approach offers to enterprises the promise of being able to reuse their existing investments in OAuth (and related specs, e.g. OpenID Connect, JWT, JOSE etc). Even if they are not currently confronting IoT use cases, work such as this reassures enterprises that these standards will evolve as necessary, and that any OAuth servers they've bought will evolve in lockstep so that, when they do have to support authentication of/to constrained devices, they can be confident that their authentication & authorization infrastructure will be prepared

- the customers who are imagining (or supporting) use cases beyond the simplest architecture of devices talking to its own cloud (with likely proprietary authn mechanisms) see the need for an interoperable identity layer by which, for instance, a device might have to interact with different devices or cloud endpoints and do so on behalf of different users, e.g. a smart home speaker calling streaming music APIs on behalf of the various family members in a household.

I believe that the best bet for such an interoperable identity layer for IoT is one built on OAuth and related specs, while profiling/extending to new constraints & requirements. Work such as draft-ietf-ace-oauth-authz-00 is an important early step towards that

Regards

paul

 


--------------080708000408050401010800-- From nobody Thu Feb 25 03:17:20 2016 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 01FC41A00DA for ; Thu, 25 Feb 2016 03:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, 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 o78xWf3FdMmW for ; Thu, 25 Feb 2016 03:17:16 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 3198E1A00E3 for ; Thu, 25 Feb 2016 03:17:15 -0800 (PST) Received: from [192.168.10.140] ([80.92.123.193]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MUHoI-1aPRjk0ROc-00R4kT for ; Thu, 25 Feb 2016 12:17:14 +0100 To: "Ace@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56CEE2B9.7070902@gmx.net> Date: Thu, 25 Feb 2016 12:17:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3ddOcgEUCqoR3lduXHBjPE20FuL9lH0d1" X-Provags-ID: V03:K0:HJLAttA9uQS7mJ9DsV+UGAlCD4CIE53/rnyANAEtJas2/ruzb45 wsGCpCDMpAoP1mC1sG+KmXwOG0NvjtXBlIQYa0YolKgkvoZZ/BuPCU7s19i+C1B4pXfqJuN JnK4DFuaKOzw9T9bcEGtlCitfsGW0xjArmgBAIvl8UA+cI9wWD8zknKhA2vVGV7ua2XxnwA Ndqm/5Cgjlqybuh0Z3+Ig== X-UI-Out-Filterresults: notjunk:1;V01:K0:SxzcXATeJpQ=:yuAa7tNneeRdj1F+DgXrwF ohfAWdFKCux3lJlUOFKfdn+qhK5aecZI2e6RB7mRTlErCGxZe9KrGdbCe2qLqRxFUjk+8qTnL MazkOW3cY0LTekWXjUTSWL3K9DIalZhwvszjYuYAawiAhWcDqKqmgChOlyZzy/ZWYMLf85i/2 Uuc8t70/52YqpAaB/8cKJrsD2rmggQY/bplAAiCSquvduy+DaciiAeSq5IIDmfCE4HNEW12QV pprHz2aNKIZWsHHgdi9qdViGu04Seyvux4Qd6zcyILs9UkL2BMp7ULE4s9g4YpnCRJuOn17MN cEZqzlZBHpeRKHIQ97zg/sdwQdvRfbxjpmvTOI5KrFoUUypmcMsG9y297fd6H/IApCLZBaJ// vr89y1jMxRpVmZV7+6WScOONp4RfpvK8ko17IYgo+Xo525yQQiksM5xJkBpqD7H847sWc0Cc8 587USzbLCfInRWB2d3JavXDk+VmeA/lsSAM0PZpsTkc4ImF5jWaJXvcnOiCA8Nfrcs+zuOMs/ d6OyK1lsS3HKkhH6UgD0qTswHaYbIadB9js/nJFl2UoQiL3X93KvsBSXn0l9thK9Bmh/ykETk /as5wCFSOqkx3xcNar1fneHANLNKHOU91yURtD1QtYI9o5CfQ64SmBILjcBkDiyZ+g9b8kEpY ziam7V03cHwGZrLmHDh7Y1+8wiJkAsEgnOI4urADmKlv9HNvYCNHqZGKELaAd1GqCCfNP0EMu m5kRsfgukQrqfTBEn9U0IH3p7jp/2JvLel8NTeeyFo68WBuuvgSnKYG3cK0= Archived-At: Subject: [Ace] Reminder: ACE virtual interim meeting 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, 25 Feb 2016 11:17:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3ddOcgEUCqoR3lduXHBjPE20FuL9lH0d1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I just wanted to remind you about the upcoming ACE interim meeting, which is going to take place next week, Wednesday, March 2nd. Here is the info: http://www.ietf.org/mail-archive/web/ace/current/msg01634.html Kepeng distributed the agenda for the meeting some time ago already: http://www.ietf.org/mail-archive/web/ace/current/msg01633.html We will obviously talk about our working group items: * Actors draft * ACE OAuth Solution draft Additionally, the CWT will be presented to the group. Most likely we will issue a call for adoption on that document. I would also like to look at the milestones and make plans for the next few months. I would also like to find out again what the best home for an application layer security solution (on top of CoAP) would be. There was some feedback on the list saying that CORE would be a good place but overall there was not much feedback. Here is the link to my question: http://www.ietf.org/mail-archive/web/ace/current/msg01615.html Kepeng had planned a 1-hour meeting and I am wondering whether it would be OK for you if we run a bit over time. Are there problems with it? Ciao Hannes & Kepeng --3ddOcgEUCqoR3lduXHBjPE20FuL9lH0d1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWzuK5AAoJEGhJURNOOiAt+C0H/jPT+7L/qBPZ9iN2rIZoRBxg FEaGx5rA8JlSwagwP95OtlOJA4q4natQVAfTUaV5ugZcEhfp/tUnF4mVyhUA/MDP Gi5oceFR8ahXxHYubuHPnzjLNHICH1bRJ2/Kqls/dnwSXTl8gnNO7TyxQPuI9vXd JpfK3GYcQ9CNhJ/N1QyHGbhf7Ds27UohBZMlNgtr2t+Do3PZxT+cCixydPmKrY6X QtstTOdmI0lZVMw9vVPT6/KfgvTDtYHFKY29FyE/3VEdYFYA6FlabFPnafsjszIQ IgKFBUudvz3cdueepOASUnen4zdtza0AiLEM6STiBumSR4XVBFTxwp0jQW4+XmQ= =xG0z -----END PGP SIGNATURE----- --3ddOcgEUCqoR3lduXHBjPE20FuL9lH0d1-- From nobody Thu Feb 25 04:04:31 2016 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 85AAA1A3B9C for ; Thu, 25 Feb 2016 04:04:29 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 OfWdZsHt7Ssm for ; Thu, 25 Feb 2016 04:04:25 -0800 (PST) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8C221A6F4C for ; Thu, 25 Feb 2016 04:04:24 -0800 (PST) Received: by mail-lf0-x235.google.com with SMTP id j78so31527163lfb.1 for ; Thu, 25 Feb 2016 04:04:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=PrfXHJLbjnPL0/t1Iq7zl7LiZgIWVVz86o4DW7qZKHU=; b=i5vDZmj5lRpgM2SzlxXYZwiRRXmwXAx+vngo/uXItJIQBbzfadXSAXbCPjtU4UXNe7 iBQEwUHYvbvsOHnsO9F3gl3Tb1UHBvBv27OZlnVZzj9e6RnXnA0oX0mcIke7EwK+Ag3D Oatg0rVYuRMtiYJwU6uGrjHToZf2xcZO3EmKwr7M147wM3i9/9UdZGcNRiZsg1eedOpP 3m8Bxy9dDb3LNpQDNE33k3ZDQp+4HHfpay1nZfXP3w3lQ2vIz/vzbYcqK+ViPFH0Zd3b luLmj4d4wgCTRnQt/dUXptWcanoJmS2f+1OwtJVxmSc/SdxvfVJBhS2fPnN8wvqoZmPC cScw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=PrfXHJLbjnPL0/t1Iq7zl7LiZgIWVVz86o4DW7qZKHU=; b=jsYtm2RCI6Lc7YCg97tUiu+T1OpcbmofvyvMwX4VSDCazwrLWgzyCSuTE6N8/Gp3EC knSyS+6YoAlsFswNWLU+2xPKPzV+IZ5i8DEJLDVUOknpsYyw6Q+Xzg+n/5H8kfKTAF9R DKcZSkE4GbJHa4nR0srJCnCW7KjEfEEoYWXnA0cqkNQULuanaoShRRBoBj85D5fcBlnM X5WBOBjMXCviBCj6zuj1ZXbeHCF2tmIJ432j3MQP+CzQcx1JHTAXUUdp/RSxF3tVnkxd Hbyp3RkNtHnN0aYJEF55SGAV/+PGwuAFH/asrXJwJXSK1ngfyT1WA55GmHBTyoHdTqyG IR7Q== X-Gm-Message-State: AG10YORvoi5V7Tr2k3wLXv55W65Obf6Xp1LgrJH7J/LxCXnLYzj2vmy7VcfWdmI2EPG3LspI X-Received: by 10.25.142.201 with SMTP id q192mr13436986lfd.65.1456401862930; Thu, 25 Feb 2016 04:04:22 -0800 (PST) Received: from Hyperion.suse ([85.235.10.186]) by smtp.gmail.com with ESMTPSA id h72sm1124972lfe.33.2016.02.25.04.04.21 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Feb 2016 04:04:22 -0800 (PST) To: ace@ietf.org References: <56CEE2B9.7070902@gmx.net> From: Ludwig Seitz Message-ID: <56CEEDBF.10302@sics.se> Date: Thu, 25 Feb 2016 13:04:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56CEE2B9.7070902@gmx.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050008070108080807090802" Archived-At: Subject: Re: [Ace] Reminder: ACE virtual interim meeting 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, 25 Feb 2016 12:04:29 -0000 This is a cryptographically signed message in MIME format. --------------ms050008070108080807090802 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 02/25/16 12:17, Hannes Tschofenig wrote: > Hi all, > > I just wanted to remind you about the upcoming ACE interim meeting, > which is going to take place next week, Wednesday, March 2nd. > ~snip~ > > Kepeng had planned a 1-hour meeting and I am wondering whether it would= > be OK for you if we run a bit over time. Are there problems with it? > > Ciao > Hannes & Kepeng > That would be fine with me. /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 9251 http://www.sics.se --------------ms050008070108080807090802 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CtEwggTnMIIDz6ADAgECAhAfP2QWc8z7Bo71GhHCZ7DdMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMTA3MTE1NzM3WhcNMTcwMTA3MTE1NzM3WjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCiG5fxnXbdU0+3qInGZloXB0zZLM6XAu0EmTuCsWOU8eXN lCe37PTURORfLc3te4gCDcG1GrI2AuWR9MvlcYddMZt5y0T5BVWIu534vVJtG3QCuEYRJOTW B6RWQfK+dIPpZsNhgEQkYLjTHYoCu58gP0pfxNie1X7D+RxeQcq+ynNmyFdsxc2mI+dQqBKq 4zTsCNP4/jpSuovXTn8hEbbR8zkVQ2v/Gx+EO8oMIvkIEUYzkMxe3E9A7dq5DwotRDzP+y3g C4DCtI0tfIUtFjx18Pb5UMNUKZjitrOpXfheEz/igxziydri8bYpx4qGU9CNX+MvQG7Ogqju XKfQhUTTAgMBAAGjggGuMIIBqjALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFBMb8zf+BJ13fxqEl9gYiwxZ4hpmMB8G A1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCugKYYn aHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCBDmx1 ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNV HSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAbgRzIj1s9U5kpXodti5kdj3ztjPb oz4pz8zNwn3qPUW8c3Zd40IFe+R5hRDuIm2aa//fmwop2mLM3+5/LnSnacaDnRfE7pP3NgqX XUuuZf9TtMLU6RUh2Z9JKs0IzWKALPhoLgnCsbtYDrF4QAoVqeNV79Lb6a3r6KdB/xFErbee OkZk/iw9HCr/jnvysYjfFQcBounseJS3JG4RNIuDpfsWPupQSAhl4s0akaakiwqOHCU7x0Ra rbCN+bg+6R5FEtSouIh53Z04JmI7LU3leo/AseQiUpJ6HqQNJYjnsCw8DDbijNhH41ZZKrvB rKMfVvlCH9VqrKW4kPGajKMEJDCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJ KoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0 YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIx NjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNV BAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENv bSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL19 2vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk 9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89V LnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZ ZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8U lVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4G A1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/ BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9z ZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFy dHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2Nh LmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRA W6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4St DwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y 5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bj yOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfC BJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSi F3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odh QJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfr Bzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4W VWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9Vyrw MdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2de oprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAfP2QWc8z7Bo71 GhHCZ7DdMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNjAyMjUxMjA0MTVaMC8GCSqGSIb3DQEJBDEiBCB9O/P19/VfO/+l m54Dpi7AnFPSht/ShGWtjE+Gtl35gTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQHz9kFnPM+waO9RoRwmew3TCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQ Hz9kFnPM+waO9RoRwmew3TANBgkqhkiG9w0BAQEFAASCAQAQ2RK7woDfQXHGNDZCZAV/Qr/e gP4SfPrq+ifq8HLWvB+NQRRzVXncYJrRyui+NlY/gzoAhfDXIh1PorJ0bey6jTPuSjGI+cpv thuKyeEHNYUg4AppYQxaD3afq+v+cDSKPuQW5ecRElkEeMX23WEQDowmuvpYWfc3hDbgDfaj gzNF2j+B309nGniawhXgPHYrkiAm1M81NPC1brT+4t4bzIkXDJzFAyapMnrIbZc+x67e7UzZ 3Uyt/AU52TFoNpCWqFqbwDzasois2ONCbVtLZsaX7TK9ZLCrkVUdmHNn6qO/5akJTJ81+Pp6 Kk38mRP5RJOLromu3WKARSo/z4mCAAAAAAAA --------------ms050008070108080807090802-- From nobody Thu Feb 25 04:17:42 2016 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 D16321A700F for ; Thu, 25 Feb 2016 04:17:40 -0800 (PST) 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 CgPEnADoyz-S for ; Thu, 25 Feb 2016 04:17:37 -0800 (PST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C15F71A7003 for ; Thu, 25 Feb 2016 04:17:37 -0800 (PST) Received: from mfilter18-d.gandi.net (mfilter18-d.gandi.net [217.70.178.146]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 45CF1172097; Thu, 25 Feb 2016 13:17:36 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter18-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter18-d.gandi.net (mfilter18-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id hJmfH7MG7wD6; Thu, 25 Feb 2016 13:17:34 +0100 (CET) X-Originating-IP: 93.199.254.229 Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id B7E111720BF; Thu, 25 Feb 2016 13:17:33 +0100 (CET) Message-ID: <56CEF0DC.5060605@tzi.org> Date: Thu, 25 Feb 2016 13:17:32 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Hannes Tschofenig References: <56CEE2B9.7070902@gmx.net> In-Reply-To: <56CEE2B9.7070902@gmx.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Reminder: ACE virtual interim meeting 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, 25 Feb 2016 12:17:41 -0000 I think the discussion died down quickly because the answer is such a no-brainer. -- Do the CoAP-related work in CoRE -- Build the "object security" formats in COSE -- Where authenticated authorization is required, use the ACE work Maybe you have some other work in mind that doesn't fit this clear division of work. I should point out that a design team is quite active on moving forward the CoAP-related work. This is not easy work, but it appears to be making good progress. Grüße, Carsten Hannes Tschofenig wrote: > I would also like to find out again what the best home for > an application layer security solution (on top of CoAP) would be. There > was some feedback on the list saying that CORE would be a good place but > overall there was not much feedback. Here is the link to my question: > http://www.ietf.org/mail-archive/web/ace/current/msg01615.html From nobody Thu Feb 25 04:32:09 2016 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 965541A8773; Thu, 25 Feb 2016 04:32:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160225123208.9541.55634.idtracker@ietfa.amsl.com> Date: Thu, 25 Feb 2016 04:32:08 -0800 Archived-At: Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-oauth-authz-01.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 12:32:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments of the IETF. Title : Authorization for the Internet of Things using OAuth 2.0 Authors : Ludwig Seitz Goeran Selander Erik Wahlstroem Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-oauth-authz-01.txt Pages : 53 Date : 2016-02-25 Abstract: This memo defines how to use OAuth 2.0 as an authorization framework with Internet of Things (IoT) deployments, thus bringing a well-known and widely used security solution to IoT devices. Where possible vanilla OAuth 2.0 is used, but where the limitations of IoT devices require it, profiles and extensions are provided. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 25 04:39:23 2016 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 1EE4C1A8AEF for ; Thu, 25 Feb 2016 04:39:22 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 bWKppZLlQz9l for ; Thu, 25 Feb 2016 04:39:20 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C56D1A8A5A for ; Thu, 25 Feb 2016 04:39:19 -0800 (PST) Received: by mail-lb0-x22c.google.com with SMTP id x4so28263736lbm.0 for ; Thu, 25 Feb 2016 04:39:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=57TwGqiPVx4hZjKZaSdBuAmlnHHyZizHH1VOuJI2QHo=; b=dfNfU9Rp4wTlcd+/cYto9uqswUNK1S3FHJlOhun+Gnsnauw1qD3wZyK+GNwgUXtWO1 L6IXF9I9PSprpQQ6N88IBxcqVxONDdHpN+IM3qC5vgps8lh2z7p20+sjbFsuJ3/hbnQn BRkXgJ/OWesI2kLoncKV89QEeN+LOUeTLsivKbQBYxoBccEVpNcAMOiIzUzOWbygaP01 N/kZT8ITmgFzQAHzyTZdhRtUeLeHTUpn1O++WOgFYm1Qg1LCauxjB7LODHiOLD4v1IqC lYQnZISNYPkZs/jR3mGhKazVplS7CylPFZi+5lGtOCoa1I0mEQVzeIj8BJ/VUh4A3nJP yNBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=57TwGqiPVx4hZjKZaSdBuAmlnHHyZizHH1VOuJI2QHo=; b=NX6dmN84dXeFDCR9vILPfFE11r8KwiQT5EvWGNlNfxch079s1XIpqPaUD2+1sSRX5e bX8dSaioLF4x/9h1IROC9Qxmb2wJ3z8g2YVRAlGAEuZ8DauVtp2AHLGaOHxA+jwVgor/ HZKtfGbYsrNHIyKk7+Lrhu42t4ElJVi3oMHseqpRSj701kTEdFHuP2EHUndyvKK+OwYq EUaHAR906fCgNZmo2s+4OT27+UrqA/CriEYwDn2JF2tHe/X5IuvEL5tkVmOtbz4riG9c 0cNlII2WYPd4qmov9nnlra6TcgUcWww82HUbQLdGZvUlOpIlwa3BEeiVjgC+f1O3BNHe HF0A== X-Gm-Message-State: AG10YOR9roihlaGK7F5K+jNlXKxS35W1rwFgo9NAbE9PM8jIRC9k+1Yr/0chQ8kvdXCZN3CK X-Received: by 10.112.141.132 with SMTP id ro4mr6855113lbb.104.1456403957895; Thu, 25 Feb 2016 04:39:17 -0800 (PST) Received: from Hyperion.suse ([85.235.10.186]) by smtp.gmail.com with ESMTPSA id mi9sm1131858lbc.27.2016.02.25.04.39.16 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Feb 2016 04:39:17 -0800 (PST) References: <20160225123208.9541.93223.idtracker@ietfa.amsl.com> To: ace@ietf.org From: Ludwig Seitz X-Forwarded-Message-Id: <20160225123208.9541.93223.idtracker@ietfa.amsl.com> Message-ID: <56CEF5F4.1090405@sics.se> Date: Thu, 25 Feb 2016 13:39:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160225123208.9541.93223.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050200000603020600090503" Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-01.txt 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, 25 Feb 2016 12:39:22 -0000 This is a cryptographically signed message in MIME format. --------------ms050200000603020600090503 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello, we have submitted a new version of our draft for discussion during the=20 interim meeting. We have tried to address several of the reviewers'=20 comments. Those that we have not yet addressed can be found at: https://github.com/LudwigSeitz/ace-oauth/issues , feel free to suggest=20 new issues either on the mailing list or on github. The main changes are: * Major rewrite of 5.1 to clarify the information exchanged between C and AS in the PoP token request profile for IoT * Added 5.2. the CoAP Access-Token option for transfering access tokens in messages that do not have payload. * Added 5.3.2. which defines success and error responses from the RS when receiving an access token. * Added section 5.6 giving guidance on how to handle token expiration in the absence of reliable time. * Added Appendix B: A list of roles and responsibilities for C, AS and RS.in this protocol. Regards, Ludwig Seitz -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-ace-oauth-authz-01.txt Date: Thu, 25 Feb 2016 04:32:08 -0800 From: internet-drafts@ietf.org To: Goeran Selander , Erik Wahlstroem=20 , Ludwig Seitz , Goran=20 Selander , Hannes Tschofenig=20 , Samuel Erdtman A new version of I-D, draft-ietf-ace-oauth-authz-01.txt has been successfully submitted by Ludwig Seitz and posted to the IETF repository. Name: draft-ietf-ace-oauth-authz Revision: 01 Title: Authorization for the Internet of Things using OAuth 2.0 Document date: 2016-02-25 Group: ace Pages: 53 URL:=20 https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-authz-01.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-aut= hz/ Htmlized: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-01= Diff:=20 https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-oauth-authz-01 Abstract: This memo defines how to use OAuth 2.0 as an authorization framework with Internet of Things (IoT) deployments, thus bringing a well-known= and widely used security solution to IoT devices. Where possible vanilla OAuth 2.0 is used, but where the limitations of IoT devices require it, profiles and extensions are provided. =20 Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------ms050200000603020600090503 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CtEwggTnMIIDz6ADAgECAhAfP2QWc8z7Bo71GhHCZ7DdMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMTA3MTE1NzM3WhcNMTcwMTA3MTE1NzM3WjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCiG5fxnXbdU0+3qInGZloXB0zZLM6XAu0EmTuCsWOU8eXN lCe37PTURORfLc3te4gCDcG1GrI2AuWR9MvlcYddMZt5y0T5BVWIu534vVJtG3QCuEYRJOTW B6RWQfK+dIPpZsNhgEQkYLjTHYoCu58gP0pfxNie1X7D+RxeQcq+ynNmyFdsxc2mI+dQqBKq 4zTsCNP4/jpSuovXTn8hEbbR8zkVQ2v/Gx+EO8oMIvkIEUYzkMxe3E9A7dq5DwotRDzP+y3g C4DCtI0tfIUtFjx18Pb5UMNUKZjitrOpXfheEz/igxziydri8bYpx4qGU9CNX+MvQG7Ogqju XKfQhUTTAgMBAAGjggGuMIIBqjALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFBMb8zf+BJ13fxqEl9gYiwxZ4hpmMB8G A1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCugKYYn aHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCBDmx1 ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNV HSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAbgRzIj1s9U5kpXodti5kdj3ztjPb oz4pz8zNwn3qPUW8c3Zd40IFe+R5hRDuIm2aa//fmwop2mLM3+5/LnSnacaDnRfE7pP3NgqX XUuuZf9TtMLU6RUh2Z9JKs0IzWKALPhoLgnCsbtYDrF4QAoVqeNV79Lb6a3r6KdB/xFErbee OkZk/iw9HCr/jnvysYjfFQcBounseJS3JG4RNIuDpfsWPupQSAhl4s0akaakiwqOHCU7x0Ra rbCN+bg+6R5FEtSouIh53Z04JmI7LU3leo/AseQiUpJ6HqQNJYjnsCw8DDbijNhH41ZZKrvB rKMfVvlCH9VqrKW4kPGajKMEJDCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJ KoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0 YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIx NjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNV BAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENv bSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL19 2vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk 9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89V LnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZ ZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8U lVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4G A1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/ BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9z ZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFy dHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2Nh LmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRA W6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4St DwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y 5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bj yOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfC BJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSi F3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odh QJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfr Bzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4W VWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9Vyrw MdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2de oprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAfP2QWc8z7Bo71 GhHCZ7DdMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNjAyMjUxMjM5MTZaMC8GCSqGSIb3DQEJBDEiBCAKE08gfFZnG9Mx 11YcdDZpGyV+P2iqc8tGu3ldlQdj9DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQHz9kFnPM+waO9RoRwmew3TCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQ Hz9kFnPM+waO9RoRwmew3TANBgkqhkiG9w0BAQEFAASCAQBEWUljqor5i4tQw+HOk7/ItmIZ ZSGsu49phIDJCZsU1G4XfrtL7akcKWGmfp5c1WNKTbo2e4tcoB+oS+rTgQJ7w7E6v717fUDX V8qwuPwW6vzMLT9FwezNyaIXpGunEa/VFfonsGibFiE4zSgWcagechPJeIKgDDvCRMJKWMPf KqZljFSyWR6OeqvFFB74yXH1x9h6PAPcMLUYcy8tuGKtlG7qDxJfL1Mr4sLl5pcQN6QeSgb4 Phz2Ug3Y4GAiSypzs+aOz9wFAIbEQoGxVfDFuUsk6uweYiODA7RaR0CQdN9FYiscPLFyU4XC kj1r/i/SIzaRgxiOA1gHnkJhknZ3AAAAAAAA --------------ms050200000603020600090503-- From nobody Thu Feb 25 10:02:42 2016 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 4E7911B2F6B for ; Thu, 25 Feb 2016 10:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, 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 wt0yIdeX9bGD for ; Thu, 25 Feb 2016 10:02:38 -0800 (PST) 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 9836C1B2F12 for ; Thu, 25 Feb 2016 10:02:09 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5B6BE2015D; Thu, 25 Feb 2016 13:03:18 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7207A6374E; Thu, 25 Feb 2016 13:02:08 -0500 (EST) From: Michael Richardson To: Hannes Tschofenig In-Reply-To: <56CEE2B9.7070902@gmx.net> References: <56CEE2B9.7070902@gmx.net> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 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 Date: Thu, 25 Feb 2016 13:02:08 -0500 Message-ID: <31174.1456423328@obiwan.sandelman.ca> Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Reminder: ACE virtual interim meeting 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, 25 Feb 2016 18:02:40 -0000 Hannes Tschofenig wrote: > I just wanted to remind you about the upcoming ACE interim meeting, > which is going to take place next week, Wednesday, March 2nd. > Here is the info: > http://www.ietf.org/mail-archive/web/ace/current/msg01634.html We have (1600) 4pm BERLIN +0100 and 14:00 UTC, which are not the same time in the emails. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Thu Feb 25 11:41:27 2016 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 6AF1B1B3314 for ; Thu, 25 Feb 2016 11:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, 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 SMar74DwEZpE for ; Thu, 25 Feb 2016 11:41:24 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 3A29E1ACE2D for ; Thu, 25 Feb 2016 11:41:23 -0800 (PST) Received: from [192.168.10.140] ([80.92.123.193]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LanoO-1a6ame3NQO-00kOqf; Thu, 25 Feb 2016 20:41:21 +0100 To: Paul Madsen , "Ace@ietf.org" References: <56CB063D.7020701@gmail.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56CF58DC.8040600@gmx.net> Date: Thu, 25 Feb 2016 20:41:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56CB063D.7020701@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cALj1HVhv1IheKcO6UERDfohngXXDA4R6" X-Provags-ID: V03:K0:79OmSgvmfanjPAJuX4sGg7C/O1ROQ8WwFKYKeO2NS4s8anXCbIb 1aprnG8d0ANIRXU1jtObfUuGW7TfUXigpJM+T8Gf4nopilUTs4kmVTw72zajezv53aMAjT1 6XiMSMzUjqg5Zp5AllBTh9umCesLG3U0yiOXZg9polRrl+qcIrBQFj1Q2cQZ18EKxSqwR1C opq7KtAdQeP06QA/T6TqA== X-UI-Out-Filterresults: notjunk:1;V01:K0:nFsKrGIUMt8=:Qxy9ONm6O44ev0xYUQ1AYJ bbYr3m3sDhZUBNlFLXwL9rHAB631BlbEE6oozyBhMf30LXexrWQ0VtZop9mtHjDHTcWBc3QkU k8MjnZx6e8TUgkFQZ0uKQm0TzRYVpvdWJ79PBoRTATfoY6P3gwQBGIHre9sOFtXc7dJj04XiA 8Ms9WC7gu46viXwiTm1j5nNJsg26qEWzM/eCc6g5mtx0ZbPbz/SXCQGKow6JGwdLhBNQUl962 hjT/0YUUOlJAWb9dy0YxTc0XbWBg/6gKNc4nzUIhhftaQShdJXTl4dlFSyaBIT/iAqtXMX+Xd WF9S5g5U3D7O/NAseSr4Ath44feaJ98odYIQzNEvH0sT6q1hFVaLwgdGROW98EYm7ct3BMxGp UXQZYD3zgXEgq/bP5uCjPV+g5GOnIS1D4YbGnXpjjt8H+ROjMQ7HG7RTpWFNK9dSrxTdreoMR pQhBz7V0UApNGEEDXbDnRWHeFGC6T0FNmYSlJ2mP/uvcfEvd+sy7G+mjmI49saDVgJRf+oEMG kqAB+IzuCcexZ/O+tTI6zZQwOYHJmkPCFEE6LfQQ0kfSkLL1KssoLIKWrSSWnEBRKclHXrjew GiA7/gHDcavoAvLAjMjZWWF4z+y2RzcbDIj5u0W8nmg6vu1QOWMZEj6RFzWORs1iecn4Gjec2 9WJbnudiZ5PAWOjHeMa4GmgXfnQQuyfyc74ZAeYcdHM3DWrKNDmf2Qls3MjD4S9JiY0devOFa GqGKG8D99PJxbPR6mX1i670+dSIdFy8JGzr+pLcv6anLAyyTS0CmX7POwrQ= Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-oauth-authz-00 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, 25 Feb 2016 19:41:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cALj1HVhv1IheKcO6UERDfohngXXDA4R6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Paul thanks for looking at the current version of the document. In time for the virtual interim meeting (=3Dfancy word for a conference call), which will take place next Wednesday, we will have an updated version ready that improves readability. Great also to hear that your interactions with customers have been positive and that they feel supported in their investments. We hope that you (and your company) continues to support the work and the prototyping / interoperability testing efforts we want to schedule once the specifications becomes stable enough. Ciao Hannes On 02/22/2016 01:59 PM, Paul Madsen wrote: > Hi, I've read throughdraft-ietf-ace-oauth-authz-00 and thought I'd shar= e > my high-level feedback and some thoughts from conversations we have bee= n > having with our customers with IoT use cases >=20 > - the approach of binding OAuth 2.0 to IoT use cases & protocols is > critical, as the current default authentication mechanism for many > devices appears to be passwords or certs burnt in at manufacture time -= > both of which have security & privacy implications >=20 > - this sort of binding has been resonating with the customers I talk to= , > as it reuses for IoT use cases the conceptual model of user-mediated > token issuance they know from their existing REST APIs & native > application deployments.=20 >=20 > - while the consent step that that this model enables is critical for > consumer IoT deployments (like customers with smart home offerings) it > remains relevant even in workforce & IoT use cases where consent may be= > less of a concern, but supporting different employees sharing a given > device over the work day (shop floor etc) is >=20 > - importantly, the approach offers to enterprises the promise of being > able to reuse their existing investments in OAuth (and related specs, > e.g. OpenID Connect, JWT, JOSE etc). Even if they are not currently > confronting IoT use cases, work such as this reassures enterprises that= > these standards will evolve as necessary, and that any OAuth servers > they've bought will evolve in lockstep so that, when they do have to > support authentication of/to constrained devices, they can be confident= > that their authentication & authorization infrastructure will be prepar= ed >=20 > - the customers who are imagining (or supporting) use cases beyond the > simplest architecture of devices talking to its own cloud (with likely > proprietary authn mechanisms) see the need for an interoperable identit= y > layer by which, for instance, a device might have to interact with > different devices or cloud endpoints and do so on behalf of different > users, e.g. a smart home speaker calling streaming music APIs on behalf= > of the various family members in a household. >=20 > I believe that the best bet for such an interoperable identity layer fo= r > IoT is one built on OAuth and related specs, while profiling/extending > to new constraints & requirements. Work such as > draft-ietf-ace-oauth-authz-00 is an important early step towards that >=20 > Regards >=20 > paul >=20 > =20 >=20 >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --cALj1HVhv1IheKcO6UERDfohngXXDA4R6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWz1jdAAoJEGhJURNOOiAtJO0IAJMDMDtJc9Vl3EuoLCKA5KrJ 5WAmInbntHa4gMH0e6NYk3hK29UjUcjlSNKcKcCiTye+uZfBnySLkzo/VC7i76MR +ysCRCit1FX/CKsVyvr4yysuA6KladA39XsjY/64HD6yEemnOPylNiSuQR9Z3swB azFrq969vhlrjgcREzCuEIQlpsmKIcYOTeRW9REStNc5IxTap4poOyABywgfO5Pf RWikU+F7MFXrDAaxL6FqfbKVHaTr2kFz5mSozVOSxlNihbXjweqRz/zdmTGmuIYA eycX1MUPR0qjpj6AJzQMeqpx2lOkH3OZCtzPPWUTmOv9aNBiII35wjR/4HL2RTA= =8ejt -----END PGP SIGNATURE----- --cALj1HVhv1IheKcO6UERDfohngXXDA4R6-- From nobody Thu Feb 25 22:39:28 2016 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 91DB51AC44B for ; Thu, 25 Feb 2016 22:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, 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 M4hbubhp4_tO for ; Thu, 25 Feb 2016 22:39:25 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 99ABB1AC445 for ; Thu, 25 Feb 2016 22:39:24 -0800 (PST) Received: from [192.168.10.140] ([80.92.123.193]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Maa3B-1aF3hw1UBl-00KA1Z; Fri, 26 Feb 2016 07:39:13 +0100 To: Carsten Bormann References: <56CEE2B9.7070902@gmx.net> <56CEF0DC.5060605@tzi.org> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56CFF310.9000203@gmx.net> Date: Fri, 26 Feb 2016 07:39:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56CEF0DC.5060605@tzi.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RKJWL8hJs9CEKxiWgnnHWVl4jEJjeihJ4" X-Provags-ID: V03:K0:/zOSVYeSUWQeKpt0rRsbk5roPkUdzrGYD1lrnFe2Y7W7Ib49oIw RZaBwRtNMV62p905fEwdVYb1IixMvT2MeKKi9ItS7bal1lTX5NMJJ6ZmIy0SNMZ63oYCRms sQvD1BF6k2+OcGgDc/164pG6YerbhFcPCEVDMvJ2p6u1U/ZSRZoXChjbzg0G247eQd09cfw C47bzstAa7Ei3CZqZ0jQA== X-UI-Out-Filterresults: notjunk:1;V01:K0:UrRwzDnj8Y4=:xKK84brCj52TTOM66g1Fol IUVTSUVtt79xituvCBBnQ5FLtLlBTkHGasxGgvT1WjBoW13WdsxISWiXMm3uYZs+d2kp7oA/T OZLA0UpqWIbEn8+U0npgAi9UHdvfqHwjOq/UhT6gIwcQ3OfZ3sPPFFOYdpTcDzW8JR4dR78hH g462h5g5d0HKtOJLXQcCjWY423yf496VSDLGZPVinVx1weDz3eZYNn3HYTZEoS4ssLSValWcr iZHeo7Fpgia7lNeueSLsv2RO+VPyx+JNN9rXZ/TJvUgAiyP5cE2jBjS+a8liuA/DH8bZmwarl VnDPkH2Z2wH3Hpg1R3N4vpT+FTvy6KgcaBPybG3K558zqy8UD/iyHoU9Jygkwdx5SemOfyyhw lJfI9j8Ofha9GxJ+FcdLindSKwgtD8FF0wRGcJ3xu1skUnfmBhGbi7h5QpUHdvj2SXWrWmV1z nLSJmqMl94RhApqGlFcXHN/cJRhaIdxtgKj3m8UoC8lN7Kf5fhoxTTP5AOFBmrdRmiNNdqqpb Ji1pFnzbMVfH9ixUELSP9Tmnf/cxh/a+P9uLyMCo+ZdK2LAxVlarCw5Siz++vAaeAd0eL33Kw wBP5k0dDzZ1ivkWQfo2oLLMLr0cXE75AFtt82XhvW9UVaOFdAsMXsjGne15e0z3kDDTm8iLHG g8JntqcuIInJtfzc0Z+6srfgkF61/CPY+N1spNRCUcunBtKv5DUZYyFZ5YwlX48ll8CDvjj6d uMR29V7CwSGK9JlExV7wGpVIgK6VIElw9LmgnVZIhsB+8QE8XalKHhb2iJg= Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Reminder: ACE virtual interim meeting 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, 26 Feb 2016 06:39:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RKJWL8hJs9CEKxiWgnnHWVl4jEJjeihJ4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, thanks for the feedback. What design team are you referring to? Ciao Hannes On 02/25/2016 01:17 PM, Carsten Bormann wrote: > I think the discussion died down quickly because the answer is such a > no-brainer. >=20 > -- Do the CoAP-related work in CoRE > -- Build the "object security" formats in COSE > -- Where authenticated authorization is required, use the ACE work >=20 > Maybe you have some other work in mind that doesn't fit this clear > division of work. >=20 > I should point out that a design team is quite active on moving forward= > the CoAP-related work. This is not easy work, but it appears to be > making good progress. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > Hannes Tschofenig wrote: >> I would also like to find out again what the best home for >> an application layer security solution (on top of CoAP) would be. Ther= e >> was some feedback on the list saying that CORE would be a good place b= ut >> overall there was not much feedback. Here is the link to my question: >> http://www.ietf.org/mail-archive/web/ace/current/msg01615.html --RKJWL8hJs9CEKxiWgnnHWVl4jEJjeihJ4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWz/MQAAoJEGhJURNOOiAtFcsH/iHYZ6tqYHiEDeZmfwFK2K7j lupglmmcihKm/TNqvNAKVw3A2hLGcAvOeTKeGD/R8ZyjkwoJekTFvkzCPpE1Mt8q gZO3mRePIqa9FjyxSQb8ORORGOtF1Mi+grXuOdJr7eRpodpU/5rfaXVN1FQ06FEM Ip+imhupgRMwkYTn7tdLIqGhqvsxuJO3dCphPEibwV7RilLYFKrLVRgLwQecFD3j bwfFaiA8A07XwV1La+GHT870P+1K0FLc4M5zY5nZyahQpmwzB+VqUD1m+v6t1IQ+ 9LQINb4imrfB/cwlUxbjnXrrHz5Dkw/Hc0LqT7YSiaVWk/IHocqKc6UBAkollrY= =NBUA -----END PGP SIGNATURE----- --RKJWL8hJs9CEKxiWgnnHWVl4jEJjeihJ4-- From nobody Thu Feb 25 22:46:43 2016 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 6B2431ACD0F for ; Thu, 25 Feb 2016 22:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, 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 aXpMVJdsgSJ7 for ; Thu, 25 Feb 2016 22:46:41 -0800 (PST) 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 BAA791ACD09 for ; Thu, 25 Feb 2016 22:46:40 -0800 (PST) Received: from [192.168.10.140] ([80.92.123.193]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MaJPk-1aFKu50C4W-00Jts3; Fri, 26 Feb 2016 07:46:29 +0100 To: Michael Richardson References: <56CEE2B9.7070902@gmx.net> <31174.1456423328@obiwan.sandelman.ca> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56CFF4C4.8050907@gmx.net> Date: Fri, 26 Feb 2016 07:46:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <31174.1456423328@obiwan.sandelman.ca> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JLhhkKlAi2cBHSrsKwF7VCxCgwsdXhdFd" X-Provags-ID: V03:K0:L5sZRaSgIwUC4TcRhC5eeioZ+vgjgWb78F3u6Rh3FOIfcwQE1Lv BLkGX3rNOTcCPBxnNdUC6QKPV5tSZ9pJ6kiIZom+IpMkEjJfeYueO+cz1gr9uiB4L/6IEcO c2CHvYW9pwxq68MaejN2AQMJPDMl83nRZF1tVKcoczgaAtvuPMFSQlt8mnUG4fiUI2B8VXf UQJauznfLaam8RJH0GbSg== X-UI-Out-Filterresults: notjunk:1;V01:K0:91y0XyVHaIU=:0/4Ma+68CxUCp6/8SUe0W8 e8TlNC5iXwvUYba3s7460jLGK7OONaCBWIjEAsPqoIdbUjSoz+LppiMYWb2Zycf7Sn97/wqlU vBSbGSFaIpiMMtCYEb7H3f66PpwNRrUYNMVg418EXsfkoyygiwVmibybTY+3jB6zQAI/LjIzd x5uFWBPZoPyV7WrH3NHzloUvIM/QvRHyBKLzEiOsgpVJlhNZ55KMTeswO7j0MTzd8AAfHabnE 1tLfsZvl7OLTrlvVFWw8+7YnCaJxFE4L+W8U7ujiCX0MQhtaGOcp5srjd5PT+yu3Qfexb3dnw wX+oY0f3GCVt7XoDb8mKIb1uCTYMuxF6OW/OmRoTukOhM7R8OXZiiJyr3NuqQaAaIN3brC01G WZ2R2QGZUpVHxrVs2zEYWayEqVaXVmvg9JGQwzYEOlhmGeXP8Uhxl9Wc/C5q+TxiUVMIszCfW 3Jm7dM+AhJolWbbbLUEZrjSdmrqZ2GzyN/f+99eEoTou1phhk7NM5/7HMDCBVgSkh/oGYOCVs P7XKyCt3iT/OP7/rq3bRXOMnQWZMUjLfoYxnRnWKpka7ssvGGCXYOdy3szL8ESITI/OxN5OI/ uXTuL3hAsARXXC+/u++gbsBXtDHKf6SipAgy4Psy1qERlezT3uP4jsKlSbN84xVGGResDLsMZ pnQ7Cqfxr9JyNSjVKurKgLsA0l3Nu5/oa2Z6shgQpL8yHZzUroOZbBoQW9jhPqs4uR93WAMGf yNXoYSeqF+p9zd7Nkx6ytodYU6r/wcLTiRJQ1+CZn8RffFWYWofDbQBOcxU= Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Reminder: ACE virtual interim meeting 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, 26 Feb 2016 06:46:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JLhhkKlAi2cBHSrsKwF7VCxCgwsdXhdFd Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Michael, thanks for your response. You are completely right. I missed up the Webex setting. Kepeng announced a starting time of 14:00 GMT for the meeting. I will post a correction to the list. Ciao Hannes On 02/25/2016 07:02 PM, Michael Richardson wrote: > Hannes Tschofenig wrote: > > I just wanted to remind you about the upcoming ACE interim meetin= g, > > which is going to take place next week, Wednesday, March 2nd. >=20 > > Here is the info: > > http://www.ietf.org/mail-archive/web/ace/current/msg01634.html >=20 > We have (1600) 4pm BERLIN +0100 and 14:00 UTC, which are not the same > time in the emails. >=20 > -- > ] Never tell me the odds! | ipv6 mesh net= works [ > ] Michael Richardson, Sandelman Software Works | network archi= tect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rai= ls [ >=20 --JLhhkKlAi2cBHSrsKwF7VCxCgwsdXhdFd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWz/TEAAoJEGhJURNOOiAtD4sH/A6WP+cJDw1cTjdgVdRQPEMh hLifaDJ7euzw8O6kELr+gTle1nfEWUolb7qgrYs5euZGYk6jMpaYDj0UAwutGs4/ c0XjtUMx83E5X9rZkncKSRTa3+k9dBhcxSSsTuf5nTo8vQUntddgqoTf8TccpaEO y1t9Q6yEgp7U2xgeGiS4Hdfwu6IHOq5DmizMIga+5aaettNaostk9MRK1hH7fU9y HjGC9k9VdEeTRiXEWLUkBPyEdaVKoiYykxrvfySqUVinB0ijIriXNbuPmFn/EPX/ co0t90tgwbBSfNBbYhVVOoJeJDRIhFTx+AQBVfwNpVI0teGsRwXOv2Apro+5jAc= =ds/0 -----END PGP SIGNATURE----- --JLhhkKlAi2cBHSrsKwF7VCxCgwsdXhdFd-- From nobody Thu Feb 25 22:57:27 2016 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 763D41ACD3D for ; Thu, 25 Feb 2016 22:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, 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 nVnlIBsCWJvl for ; Thu, 25 Feb 2016 22:57:24 -0800 (PST) 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 625791ACD3B for ; Thu, 25 Feb 2016 22:57:24 -0800 (PST) Received: from [192.168.10.140] ([80.92.123.193]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LymHf-1ZtPWf1eYZ-016AJ8 for ; Fri, 26 Feb 2016 07:57:22 +0100 To: "Ace@ietf.org" References: <56CEE2B9.7070902@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56CFF752.5080901@gmx.net> Date: Fri, 26 Feb 2016 07:57:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56CEE2B9.7070902@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7hFEPDtjJxdQ4L3JJxr4dLnjLGoTlf7lP" X-Provags-ID: V03:K0:GecOYySmg/H+nO0HVcRvQdyyRoqojggz8f9yHNtYSRma/6A9gaJ WNPF0xMsTGhdD/PhhcztsgPVxBTvOouxzZt2fk4/rpo5PJrDuTMfDEZjwCyslrEQ0PFJ4zo wvf/Tz1D3RSMxqMG3r4D7o6mxwpqY1V7YZ4e4PVabNlAr/5q3Y12I1aOiZFKo8oKZ7YN7bT NVFLqNI7Rtg2Rqph3E0+Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:ViU4OTg+eaY=:joHNM0dUG3QjuZa4wl6adO ugr3HkCTK0XYLMTVrtmweZpzmwJJLwFzAvBtWoS9K9MG+Zzr3MOVMIrfszOqP/4m0j6CPIPXX H3FanIg2cFhLTb0MbvJhttcr2DwlYe9gX5vd4Ws9Jfvnlbx6bfdJ00IzIJsGGWKZeJ+JtR9tK dhjkx+TJhOmQx78Xp3c8d8OkHcvoda2rscUSbwP+T6nOrYPXlExZQNx1ijI7WanS53tOjDwtV IBqV79Y05uwNxcPWGXzkO3UEr5XX458Ucfx8hjO9xn319myTi9qYiLrUk9DiMK2FQqwTFBr40 NFTuxEImjnhTA6/Rt2DRHHcM/vJaUPhTAja1Csff5LNMfdbWqQU/8T6Ux+oCWc+RzcxqsXi1l RhAW1Yb77ZU73KiXBfLrihjjgnUNYzrqYnUIOaMuLl0Keu9LDIVVXq0M0KpKWzmlTgbI11oeE scBa10E9Io65p+wCoCPEmdQ9LDkmAEC4Ch4txMs9Xu9uhCSdWZcPRUHNgcXdAvhtwmEr7r5yK uBB2/FnoGrJ5qirGxYVNfVn2lrzUYdE8WiVVY5d4MTYOIcY0M7mzLzu/bhwsS1znDbjGIzsaX ApHH7fnNkuYKl8ArxCtRIj6q2Fjg3GY7gXbLiGQLC9e7nYPisoB7CwCFI6GRHpF2pYCHEbluj QcuODMFhaovpQgAiTgTfTFhiMw9tvUzMuI1J4b+afeBKKRoZHAsLJ1rwk4xFC3+hd0RRmCZpb jQLbwfg7rH9XiQaXgAdUa0tVr8RbhkySfcJ0sza3vE/W5JQ3eP2rG9EBXI0= Archived-At: Subject: [Ace] Correction --- ACE virtual interim meeting (March 2nd 14:00 GMT) 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, 26 Feb 2016 06:57:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7hFEPDtjJxdQ4L3JJxr4dLnjLGoTlf7lP Content-Type: multipart/mixed; boundary="------------060303040004030200030308" This is a multi-part message in MIME format. --------------060303040004030200030308 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I am sorry that I previously distributed wrong Webex conference bridge details. I messed up the start time for the interim meeting. Here is the correct information: Wednesday, March 2nd, 14:00 GMT (planned for 1 hour - we may run over tim= e). Webex: Meeting number: 649 246 728 Meeting password: 6X2upMdh Link: https://ietf.webex.com/ietf/j.php?MTID=3Dm787d2c01ec681b61b0d49c8326b4193= d Audio connection: +1-877-668-4493 Call-in toll free number (US/Canada) +1-650-479-3208 Call-in toll number (US/Canada) Access code: 649 246 728 Ciao Hannes On 02/25/2016 12:17 PM, Hannes Tschofenig wrote: > Hi all, >=20 > I just wanted to remind you about the upcoming ACE interim meeting, > which is going to take place next week, Wednesday, March 2nd. >=20 > Here is the info: > http://www.ietf.org/mail-archive/web/ace/current/msg01634.html >=20 > Kepeng distributed the agenda for the meeting some time ago already: > http://www.ietf.org/mail-archive/web/ace/current/msg01633.html >=20 > We will obviously talk about our working group items: > * Actors draft > * ACE OAuth Solution draft >=20 > Additionally, the CWT will be presented to the group. Most likely we > will issue a call for adoption on that document. >=20 > I would also like to look at the milestones and make plans for the next= > few months. I would also like to find out again what the best home for > an application layer security solution (on top of CoAP) would be. There= > was some feedback on the list saying that CORE would be a good place bu= t > overall there was not much feedback. Here is the link to my question: > http://www.ietf.org/mail-archive/web/ace/current/msg01615.html >=20 > Kepeng had planned a 1-hour meeting and I am wondering whether it would= > be OK for you if we run a bit over time. Are there problems with it? >=20 > Ciao > Hannes & Kepeng >=20 >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --------------060303040004030200030308 Content-Type: text/calendar; name="WebEx_Meeting.ics" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="WebEx_Meeting.ics" BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:Europe Time BEGIN:STANDARD DTSTART:20141001T030000 RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D-1SU;BYMONTH=3D10 TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:Standard Time END:STANDARD BEGIN:DAYLIGHT DTSTART:20140301T020000 RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D-1SU;BYMONTH=3D3 TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:Daylight Savings Time END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT ATTENDEE;CN=3D"ACE Working Group";ROLE=3DREQ-PARTICIPANT;RSVP=3DFALSE:MAI= LTO:ace-chairs@tools.ietf.org ORGANIZER;CN=3D"webex":MAILTO:messenger@webex.com DTSTART;TZID=3D"Europe Time":20160302T150000 DTEND;TZID=3D"Europe Time":20160302T170000 LOCATION:https://ietf.webex.com/ietf TRANSP:OPAQUE SEQUENCE:1456469628 UID:811e05b8-0fc1-4096-8c88-776227c52c4f DTSTAMP:20160302T140000Z DESCRIPTION:\nJOIN WEBEX MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=3D= m3d375c193cf8d06514445ebc5f67ba4f\nMeeting number: 649 246 728\nMeeting p= assword: 6X2upMdh\n\n\nJOIN BY PHONE\n1-877-668-4493 Call-in toll free nu= mber (US/Canada) \n1-650-479-3208 Call-in toll number (US/Canada)\nAccess= code: 649 246 728\n\nToll-free dialing restrictions: \nhttp://www.webex.= com/pdf/tollfree_restrictions.pdf\n\n\n\nCan't join the meeting? Contact = support here:\nhttps://ietf.webex.com/ietf/mc\n\n\nIMPORTANT NOTICE: Plea= se note that this WebEx service allows audio and other information sent d= uring the session to be recorded, which may be discoverable in a legal ma= tter. You should inform all meeting attendees prior to recording if you i= ntend to record the meeting.\n X-ALT-DESC;FMTTYPE=3Dtext/html:  
 
&nbs= p;
 
Join WebEx meeting =
Meeting number: 649 246 728
Meeting password:6X2upMdh
 
 
Join by phone 
1-8= 77-668-4493 Call-in toll free number (US/Canada)&nbs= p;
1-650-47= 9-3208 Call-in toll number (US/Canada) 
Access code: 649 246 728 
Toll-free calli= ng restrictions  


 
Can't join the meeting? Contact support.  
 
= IMPORTANT NOTICE: Pleas= e note that this WebEx service allows audio and other information sent du= ring the session to be recorded, which may be discoverable in a legal mat= ter. You should inform all meeting attendees prior to recording if you in= tend to record the meeting. SUMMARY:ACE Interim Meeting PRIORITY:5 CLASS:PUBLIC BEGIN:VALARM TRIGGER:-PT5M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR --------------060303040004030200030308-- --7hFEPDtjJxdQ4L3JJxr4dLnjLGoTlf7lP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWz/dTAAoJEGhJURNOOiAt2UYH/3odRe7XMz+YETFLwNPjqNKC XRp06A0dUyiK8FxBiINA/VdJS4fJXL0ckCoIG/LFsty7js/EIvmNa46QUXbVD88x +8sYPjo/rzST9v9htCMr3PuiSkvooY2FQZ+avvd1hrmRm3dpHpzKD86TyvSXz/q+ iyBYN6xWTuB5I3i9w9U2mH8g7XEC2wlGXtPn+cqratD7YItiNhfYJXchBKzRZ4rf EslnH6KxVBBk5b4lcMb7c36GIQHwLrefXEy8evOourO0IB7MU7t67HuUjmf3Vhr1 aGtZdootzeoqaC4AQJ/ymdQH0gMvAIMqqgenUIar98F45GRIHItJVQfBe3cJuYw= =xQkl -----END PGP SIGNATURE----- --7hFEPDtjJxdQ4L3JJxr4dLnjLGoTlf7lP-- From nobody Fri Feb 26 10:43:29 2016 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 7EB1F1B2E4B for ; Fri, 26 Feb 2016 10:43:26 -0800 (PST) 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, HTML_MESSAGE=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 yzS5zxzhyOcA for ; Fri, 26 Feb 2016 10:43:24 -0800 (PST) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 779101B2E58 for ; Fri, 26 Feb 2016 10:43:24 -0800 (PST) Received: by mail-qg0-x229.google.com with SMTP id d32so16217623qgd.0 for ; Fri, 26 Feb 2016 10:43:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=/0hf0sViNSezg9gYcPijWdqjQj3rFz9t/g73JtaewBE=; b=FFwmXrfIt/V9qIVVqg4nMgTz4ZCGrszqRMYDtMULzRbD1+1UiiwzthdNctCAHPEqFL 9QVqhRw9PXu7SEbx/BK2hmdO/5N0tnIWL9IRCvRIyda6ubhxjLayZaRU6gzLhHG0Wvli 2FMgNaNF0ooSmGCO3WZUnDxua+uO/VZ9Qfa9bobJ58igSbW7Rh87LW1+gb54925eFKEA Sxo4QLOenBxLzx7MFEKVJC/RLI1K3OFHk7yaoG0TsX59Y2bCA6nFMIvE/zxtOcHevbSk 8/mxoR5rZWX4oYB18Q80NJlmIBUWQY5d8oQ/NBGmNAhgUFyuqlkIPdunjqGM1lyRpmrb oWTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=/0hf0sViNSezg9gYcPijWdqjQj3rFz9t/g73JtaewBE=; b=COewHPMJVK7XlCDwW3Qfl1ge9Z9GyJ+paRHutYWt3SccLzf0uDYSdJNwjs+4G1Lybs L6dHHbkdSTGp05V3N+KuQIOnyKp5ff2yh3Rkuy1P5L9q67+gO7cKBmvvw6jpgu9W5CO9 kMY/ajtATQO+HE5qf3oxPSABJH/kEz+yfHbfB526LL8HIZD1vVXMywrOKiQdmuaGV0io I2MJxfIpJsqTyUbVMLTqcvZlibMSUfGMDKW28NlRQTcztMxsGndqoLXuAGZCnMizyYxN dAu+oInmM+94kg/KVBBZCScOaP3fVOK3bPt0nRF83RsXWvKmQmJMPcpebzuy8Qvckfs2 bMjw== X-Gm-Message-State: AD7BkJLeALCXoZwZvjqggAjPvz7lwj/xc/hMHxvRqRYQdTdMlV1ZY39tXo8GcXhmk2kpkTbainwpZNMHPYECGw== MIME-Version: 1.0 X-Received: by 10.140.194.205 with SMTP id p196mr4213959qha.30.1456512203325; Fri, 26 Feb 2016 10:43:23 -0800 (PST) Received: by 10.55.179.1 with HTTP; Fri, 26 Feb 2016 10:43:23 -0800 (PST) In-Reply-To: <56CEE2B9.7070902@gmx.net> References: <56CEE2B9.7070902@gmx.net> Date: Fri, 26 Feb 2016 19:43:23 +0100 Message-ID: From: Samuel Erdtman To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a11431a767d9838052cb0ac76 Archived-At: Cc: "Ace@ietf.org" Subject: Re: [Ace] Reminder: ACE virtual interim meeting 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, 26 Feb 2016 18:43:26 -0000 --001a11431a767d9838052cb0ac76 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I=C2=B4m fine with the meeting running a bit over time. I think that it would be good to have the application layer security solution discussion during the meeting. IMHO it would be preferable to have the application layer security solution written under ACE similarly to the signed HTTP being under oauth. //Samuel On Thu, Feb 25, 2016 at 12:17 PM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi all, > > I just wanted to remind you about the upcoming ACE interim meeting, > which is going to take place next week, Wednesday, March 2nd. > > Here is the info: > http://www.ietf.org/mail-archive/web/ace/current/msg01634.html > > Kepeng distributed the agenda for the meeting some time ago already: > http://www.ietf.org/mail-archive/web/ace/current/msg01633.html > > We will obviously talk about our working group items: > * Actors draft > * ACE OAuth Solution draft > > Additionally, the CWT will be presented to the group. Most likely we > will issue a call for adoption on that document. > > I would also like to look at the milestones and make plans for the next > few months. I would also like to find out again what the best home for > an application layer security solution (on top of CoAP) would be. There > was some feedback on the list saying that CORE would be a good place but > overall there was not much feedback. Here is the link to my question: > http://www.ietf.org/mail-archive/web/ace/current/msg01615.html > > Kepeng had planned a 1-hour meeting and I am wondering whether it would > be OK for you if we run a bit over time. Are there problems with it? > > Ciao > Hannes & Kepeng > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > --001a11431a767d9838052cb0ac76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I=C2=B4m fine with the meeting=C2= =A0running a bit over time.

I think that it would be good to have the=C2=A0application layer security solution=C2=A0discussion during the meeting. IMHO it wo= uld be preferable to have the=C2=A0= application layer security solution= =C2=A0written under ACE similarly to the signed HTTP being under oauth.

//Samuel

On Thu, Feb 25, 2016 at 12:17 PM, Hann= es Tschofenig <hannes.tschofenig@gmx.net> wrote:
=
Hi all,

I just wanted to remind you about the upcoming ACE interim meeting,
which is going to take place next week, Wednesday, March 2nd.

Here is the info:
http://www.ietf.org/mail-archive/web/a= ce/current/msg01634.html

Kepeng distributed the agenda for the meeting some time ago already:
http://www.ietf.org/mail-archive/web/a= ce/current/msg01633.html

We will obviously talk about our working group items:
=C2=A0* Actors draft
=C2=A0* ACE OAuth Solution draft

Additionally, the CWT will be presented to the group. Most likely we
will issue a call for adoption on that document.

I would also like to look at the milestones and make plans for the next
few months. I would also like to find out again what the best home for
an application layer security solution (on top of CoAP) would be. There
was some feedback on the list saying that CORE would be a good place but overall there was not much feedback. Here is the link to my question:
http://www.ietf.org/mail-archive/web/a= ce/current/msg01615.html

Kepeng had planned a 1-hour meeting and I am wondering whether it would
be OK for you if we run a bit over time. Are there problems with it?

Ciao
Hannes & Kepeng



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


--001a11431a767d9838052cb0ac76--