Subject: [Ace] Credential Options

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 2 Mar 2016 19:06:31 +0100

Hi all,

in an attempt to progress <draft-ietf-ace-oauth-authz> the question
arises about solutions should be described in enough detail to have them
interoperable.

There are three types of credentials specified:

* PSK
* Raw Public Key
* Certificates

With regard to asymmetric cryptography we settled with ECC and DTLS/TLS
profile document makes certain recommendations regarding the crypto.

However, there is still the question about what is
mandatory-to-implement and what should be described in the WG document.

What should be mandatory to implement:

* Option 1: Nothing
* Option 2: PSK, RPK, Certificates
* Option 3: PSK
* Option 4: RPK
* Option 5: Certificates

Which of the three should be described in the document? (Obviously the
MTI versions but also others or should they be covered in separate
documents?)

Here are the slides from the ACE virtual interim meeting providing
further background information:
https://www.ietf.org/proceedings/interim/2016/03/02/ace/slides/slides-interim-2016-ace-1-3.pdf

Deadline: 16th March 2016

Ciao
Hannes & Kepeng

---

From: Erik Wahlström <[email-masked]>
Date: Wed, 2 Mar 2016 20:20:25 +0100

I think all three PSK, RPK and cert needs to be defined in the core
document. I don't think anyone should be MTI, they all have different
setups and security properties so forcing a constrained device do implement
something it will not be using is not really efficient.

/ Erik

On Wed, Mar 2, 2016 at 7:06 PM, Hannes Tschofenig <[email-masked]
> wrote:

> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>
>

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 2 Mar 2016 12:38:10 -0800

> -----Original Message-----
> From: Ace [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
> Sent: Wednesday, March 02, 2016 10:07 AM
> To: [email-masked]
> Subject: [Ace] Credential Options
> 
> Hi all,
> 
> in an attempt to progress <draft-ietf-ace-oauth-authz> the question arises
> about solutions should be described in enough detail to have them
> interoperable.
> 

If you say certificates, do you need to make an additional statement of what type of certificates we are dealing with?  Are these the PKIX X.509 certificate or something akin to the automotive certificate that was presented in SAAG a couple of meetings ago?  

Jim

> However, there is still the question about what is mandatory-to-implement and
> what should be described in the WG document.
> 
> Which of the three should be described in the document? (Obviously the MTI
> versions but also others or should they be covered in separate
> documents?)
> 
> Here are the slides from the ACE virtual interim meeting providing further
> background information:

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 3 Mar 2016 09:28:45 +0100

On 03/02/16 20:20, Erik Wahlström wrote:
> setups and security properties so forcing a constrained device do
> implement something it will not be using is not really efficient.
>
> / Erik

+1

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70 349 9251
http://www.sics.se

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 3 Mar 2016 12:13:35 +0100

-- chair hat off

Hi all,

I would also like to state my view in this discussion.

> What should be mandatory to implement:

When we speak about MTI then we have to say which nodes need to
implement certain functionality mandatorily. I think we need to make
this decision on a deployment profile bases rather than for the entire
document.

So, my impression is "nothing for the overall document" but for instead
for each profile.

> MTI versions but also others or should they be covered in separate

I think we should describe the raw public key (RPK)-based mechanism in
the document.

> Deadline: 16th March 2016
Ciao
Hannes

---

From: Samuel Erdtman <[email-masked]>
Date: Sat, 12 Mar 2016 11:04:31 +0100

Hi Jim,

Sorry for not being more explicit about certificate type, the credential
types are more or less taken directly from CoAP (
https://tools.ietf.org/html/rfc7252#section-9) i.e. the certificates
referred to are X509 certificates.

//Samuel

On Wed, Mar 2, 2016 at 9:38 PM, Jim Schaad <[email-masked]> wrote:

> arises
> If you say certificates, do you need to make an additional statement of
> what type of certificates we are dealing with?  Are these the PKIX X.509
> certificate or something akin to the automotive certificate that was
> presented in SAAG a couple of meetings ago?
>
> Jim
>
> >
> mandatory-to-implement and
> MTI

---

From: Samuel Erdtman <[email-masked]>
Date: Sat, 12 Mar 2016 11:08:40 +0100

Hi All

A further note on certificate usage

The current version of the draft adds the possibility for the AS to return
x5c, x5t, or x5t#S256 (defined in https://tools.ietf.org/html/rfc7515) in
the token response to indicate what server certificate to expect from the
resource server when connecting. There is however currently not text about
how to bind a client certificate to a token.
If we want to include certificates as one of the credential types that we
define in this document we could do this by adding a parameter to the token
request, e.g. x5t, that the AS can include int the self contained Access
Token or in the introspection response. If client uses a certificate (x509)
as client credentials towards the AS when requesting the token the AS could
use the client certificate directly in the token response instead of the
client explicitly telling the AS what certificate it wants to be referred
to in the Access Token.

//Samuel

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 14 Mar 2016 09:54:47 +0100

On 2016-03-12 11:08, Samuel Erdtman wrote:
> The current version of the draft adds the possibility for the AS to
> return x5c, x5t, or x5t#S256 (defined in
> https://tools.ietf.org/html/rfc7515) in the token response to indicate
> what server certificate to expect from the resource server when
> connecting. There is however currently not text about how to bind a
> client certificate to a token.
> If we want to include certificates as one of the credential types that
> we define in this document we could do this by adding a parameter to the
> token request, e.g. x5t, that the AS can include int the self contained
> Access Token or in the introspection response. If client uses a
> certificate (x509) as client credentials towards the AS when requesting
> the token the AS could use the client certificate directly in the token
> response instead of the client explicitly telling the AS what
> certificate it wants to be referred to in the Access Token.
>
> //Samuel
>

I would still prefer it to be explicit, which kind of PoP key client is 
requesting. There could be instances where the client uses a cert to 
authenticate towards the AS, but wants/needs to use something else 
towards the RS.

I will add some text to specify has to bind a cert to the token using 
x5t#S256.

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Samuel Erdtman <[email-masked]>
Date: Tue, 15 Mar 2016 07:13:33 +0100

Hi,

On the subject mandatory to implement, in the CoAP specification
RawPublicKey is the one credential type that is mandatory to implement (
https://tools.ietf.org/html/rfc7252#section-9), maybe that could be enough
here too.

//Samuel

---

From: "Erik Wahlström" <[email-masked]>
Date: Wed, 16 Mar 2016 13:28:55 -0000

As I mentioned before. I don’t think any method should be MTI. They all have different security properties and forcing a constrained device to support a method it does not attend to use is just not the right thing to do.

So, feeling strongly about Option1: nothing. On the other hand I think all three should be specified in the core framework.

/ Erik

From: Ace [mailto:[email-masked]] On Behalf Of Samuel Erdtman
Sent: den 15 mars 2016 06:14
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ace] Credential Options

Hi,

On the subject mandatory to implement, in the CoAP specification RawPublicKey is the one credential type that is mandatory to implement (https://tools.ietf.org/html/rfc7252#section-9), maybe that could be enough here too.

//Samuel

On Wed, Mar 2, 2016 at 7:06 PM, Hannes Tschofenig <[email-masked] <mailto:[email-masked]> > wrote:

Hi all,

* PSK
* Raw Public Key
* Certificates

* Option 1: Nothing

Ciao
Hannes & Kepeng

_______________________________________________
Ace mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/ace

---

From: Göran Selander <[email-masked]>
Date: Fri, 18 Mar 2016 05:53:31 +0000

Hi,

Sorry for missing the deadline. I agree with Erik in the following sense.

I’m for option 1 on MTI.

As for specifying the use, there are two aspects:

  1.  Transport of key/credential from AS to C and RS
  2.  Binding of key/credential to access token/rights

In case of the first time access rights there is no major difference between these. But for example in the case of a client acquiring extended or additional rights, there needs to be a way to bind access rights to an existing key/credential without transporting the key. And this needs to be specified in the framework, e.g. how a client in the token request sends a reference to its key/credential rather than the actual key/credential, etc. And in the case of certificates,  sending an identifier of the certificate rather than the certificate itself of course has an impact for constrained devices, where certificates may be pre-configured but heavy to transport.

So I’m for specifying the use in the sense of specifying how to reference/bind which credential to use in all three cases (while how it is used may be left for different profiles). And I’m for specifying how to transport at least PSK and RPK.

Göran

From: Ace <[email-masked]<mailto:[email-masked]>> on behalf of Erik Wahlström <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 16 March 2016 at 14:28
To: 'Samuel Erdtman' <[email-masked]<mailto:[email-masked]>>, 'Hannes Tschofenig' <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ace] Credential Options

From: Ace [mailto:[email-masked]] On Behalf Of Samuel Erdtman
Sent: den 15 mars 2016 06:14
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ace] Credential Options

Hi,

//Samuel

On Wed, Mar 2, 2016 at 7:06 PM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

* PSK
* Raw Public Key
* Certificates

* Option 1: Nothing

Ciao
Hannes & Kepeng

_______________________________________________
Ace mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ace