Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4EA12955A; Sat, 13 May 2017 03:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.279 X-Spam-Level: * X-Spam-Status: No, score=1.279 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 TqcPHygGsH_s; Sat, 13 May 2017 03:00:11 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.30]) (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 ACDEF1293DF; Sat, 13 May 2017 02:58:04 -0700 (PDT) Received: from [80.187.102.33] (helo=[10.155.159.117]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1d9ToH-0007sD-TK; Sat, 13 May 2017 11:58:02 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-EE7126E8-91EF-4095-9A38-5C1A7E7C509E; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPhone Mail (14E304) In-Reply-To: Date: Sat, 13 May 2017 11:58:01 +0200 Cc: "" , ace Content-Transfer-Encoding: 7bit Message-Id: <22C1AD59-1B76-4596-AAFB-2CF1770FA58B@lodderstedt.net> References: To: Samuel Erdtman X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] New OAuth client credentials RPK and PSK X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 10:00:14 -0000 --Apple-Mail-EE7126E8-91EF-4095-9A38-5C1A7E7C509E Content-Type: multipart/alternative; boundary=Apple-Mail-768C5DE9-09D7-4D5E-AED8-A00E4F601F98 Content-Transfer-Encoding: 7bit --Apple-Mail-768C5DE9-09D7-4D5E-AED8-A00E4F601F98 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Samuel, as far as I understand your draft, it utilizes results of the (D)TLS client a= uthentication for authentication towards the tokens endpoint - similar to ht= tps://tools.ietf.org/html/draft-ietf-oauth-mtls-00.html. Do you intend to al= so utilize the binding of the access token to a certain key pair as describe= d in oauth-ietf-mtls? best regards, Torsten. > Am 12.05.2017 um 10:03 schrieb Samuel Erdtman : >=20 > Hi ACE and OAuth WGs, >=20 > I and Ludwig submitted a new draft yesterday defining how to use Raw Publi= c Key and Pre Shared Key with (D)TLS as OAuth client credentials, https://da= tatracker.ietf.org/doc/draft-erdtman-ace-rpcc/. >=20 > We think this is valuable to the ACE work since the ACE framework is based= on OAuth, but client credentials as defined in the OAuth framework are not t= he best match for embedded devices. >=20 > We think Raw Public Keys and Pre Shared Keys are more suitable credentials= for embedded devices for the following reasons: > * Better security by binding to transport layer. > * If PSK DTLS is to be used a key need to be distributed any way, why not m= ake use of it as credential. > * Client id and client secret accommodates for manual input by a humans. T= his does not scale well and requires some for of input device. > * Some/many devices will have crypto-hardware that can protect key materia= l, to not use that possibility would be a waste. > * There are probably more reasons these was just the once on top of my hea= d. >=20 > This is not the first resent initiative to create new client credential ty= pes, the OAuth WG adopted a similar draft for certificate based client crede= ntials (https://tools.ietf.org/html/draft-ietf-oauth-mtls-00.html). That wor= k is also valuable to ACE but not all devices will be able to work with cert= ificates or even asymmetric cryptos . >=20 > Please review and comment. >=20 > Cheers > //Samuel >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-768C5DE9-09D7-4D5E-AED8-A00E4F601F98 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Samuel,

as far as I understand your draft, it utilizes results of the (D)TL= S client authentication for authentication towards the tokens endpoint - sim= ilar to https://tools.ietf.org/html/draft-ietf-oauth-mtls-00.html. Do you= intend to also utilize the binding of the access token to a certain key pai= r as described in oauth-ietf-mtls?

best regards,
Torsten.

Am 12.05.2017 um 10:03 schrieb Samuel Erdtman= <samuel@erdtman.se>:

=
Hi ACE a= nd OAuth WGs,

I and Ludwig submitted a new draft yesterday defi= ning how to use Raw Public Key and Pre Shared Key with (D)TLS as OAuth clien= t credentials, https://datatracker.ietf.org/doc/draft-erdtman-ace-rpcc/.

We think this is valuable to the ACE work since the ACE fr= amework is based on OAuth, but client credentials as defined in the OAuth fr= amework are not the best match for embedded devices.

We th= ink Raw Public Keys and Pre Shared Keys are more suitable credentials for em= bedded devices for the following reasons:
* Better security by= binding to transport layer.
* If PSK DTLS is to be used a key= need to be distributed any way, why not make use of it as credential.
* Client id and client secret accommodates for manual input by a hu= mans. This does not scale well and requires some for of input device.
* Some/many devices will have crypto-hardware that can protect key m= aterial, to not use that possibility would be a waste.
* There= are probably more reasons these was just the once on top of my head.

This is not the first resent initiative to create new= client credential types, the OAuth WG adopted a similar draft for certifica= te based client credentials (https://tools.ietf.org/html/draft-ietf-oauth-mtls-00.= html). That work is also valuable to ACE but not all devices will be abl= e to work with certificates or even asymmetric cryptos .

P= lease review and comment.

Cheers
//Samuel


____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-768C5DE9-09D7-4D5E-AED8-A00E4F601F98-- --Apple-Mail-EE7126E8-91EF-4095-9A38-5C1A7E7C509E Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSTCCBUUw ggQtoAMCAQICEDPbmsaqwjeZa3PxA3uZ8LQwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNzAxMDkwMDAwMDBaFw0xODAxMDkyMzU5 NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEArsGSzZyz9Lq9SRW9Sve5K8n5lWhplOCE6HH3gMye12DjOpkF FZt0b73t27G17Xsp6WUxHhNevf7ck0AUpvYUPCHBqVGJSIWF9hWAoSFCgQACOoh/cDFbzz1PsMY8 El7OmIus4JXtY4/VdoSIhFP3hzATbNAg32Kp+N8vtTuKTwbgnizJSyzZTYrsttn3LmwY17HU+U9v XloMus5U/ln4ADZx0zyyDSsA6gtPxXYJpbgSTnHckVZ5zfR80guIZ538Y2qqsqt5VaSRSR2oQzE/ HETkKc/odPVhqBrXLyvnSFkCPrAXV07rcvwkPvHZeYVu4QdVWyO2HIQ4i2x9r5m7SwIDAQABo4IB 9TCCAfEwHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFPngHgVxOZ7G Sji/IW4YJMBj02PHMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEE AbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwXQYD VR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50 QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwWAYI KwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhl bnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNv bW9kb2NhLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0B AQsFAAOCAQEAAmueyHjiyL1qYgfe+hVSsGuKlgcvjCAfG8Jaq48tC0IjP8pH/tGi4uL9CHVfLnV3 pLDnjg6M2uvpEBp7crZZcnSPLeVss+tkhwv+F7ISYQyT4flNkqVUb8nfewbCPcIN13ObfpU7rlXo IarEEplQo4SuymYVluQxTLOFKm5QOMF4JBMw/rjy4t95J7Mdp9NFUzQrKPJDaJ2Jr/TcTXFcjLvN VmMBjK0959a9v1/1miRHd1DBsTh1KvBigEOUNMxvT5uUtB6/tioDZqBDDk8Gvdno/xmye3YiasS7 JgMREq5WcXqpWGu5kMFZMGPEvyPHeBZeqxx3amf4ImVnZ6WvgzGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDPbmsaqwjeZa3PxA3uZ8LQw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTcwNTEzMDk1ODAxWjAjBgkqhkiG9w0BCQQxFgQUYOEC6XrZA/dpTQeAFfq0ljlifFAwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAz25rGqsI3mWtz8QN7mfC0MIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAz25rGqsI3mWtz8QN7mfC0MA0GCSqGSIb3DQEB AQUABIIBAHQ40c3DyWzr6dE3lOhaZAb9gtBqDWYfr7u+4bSTutxl58xdnrFClL7+94fNHPM35YfQ 51juPP1qMokJqNUaWeeqtzpdPZer/8FvlF3eXRXAPQziVa5EJgH9nEMwYx9I1VNoz3jlN1Y2qAy5 dEuifBJQLXrQvEhAXXF6kvhGUv+Xm70DhYpvbpYg+bAF2Y2Gbalhu0FgeSR/RU3GKkGsLOX+e8I2 GowyaqiVRFyxzmskyeHZc+DNWRoiNS/RCaf5/98oGBUJPpDaMJG2iXfwjL2MRu7kg+QcYk1cc+N5 8DVknkpX6G/QDrloUlRgCae/XyU+2fZBYFnUekXtjdA9UD0AAAAAAAA= --Apple-Mail-EE7126E8-91EF-4095-9A38-5C1A7E7C509E--