Subject: [Dots] Mutual Authentication between DOTS peers

From: "Jon Shallow" <[email-masked]>
Date: Tue, 2 Jan 2018 17:19:10 -0000

Hi WG,

Mutual Authentication is required between 2 DOTS peers, but then the drafts
do not make any suggestions that I have found as to how to do it other than
referring to EST.

I want to make sure we have a set of alternatives in place as a minimum
requirement for DOTS vendor interoperability.

What I am planning to put into place (be more enforcing) in my DOTS
implementation - comments welcome as well as additional suggestions.

PKI

Client and Server Certificates have to be signed by the same CA.  The CA
does not need to get exchanged during (D)TLS session set up.  The CA does
not need to go back to a well-known root CA.

PSK

The DOTS client 'identity' (potentially FQDN of client) is used for
validating the client by the server, and the DOTS server 'identity-hint'
(potentially FQDN of server) is used by the client for validating the
server.  Obviously they both share the same PSK!

RPK

Nothing in place so far as I have not worked out how to get OpenSSL to do
this for me so far, so have no suggestions here.

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 3 Jan 2018 07:38:12 +0000

Hi Jon,

Thanks for the comments, please see inline.

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Tuesday, January 2, 2018 10:49 PM
To: [email-masked]
Subject: [Dots] Mutual Authentication between DOTS peers

Hi WG,

Mutual Authentication is required between 2 DOTS peers, but then the drafts do not make any suggestions that I have found as to how to do it other than referring to EST.

[TR] No, https://tools.ietf.org/html/draft-ietf-dots-signal-channel-14#section-7.1 discusses PKI, PSK and RPK and the data channel draft refers to this section for mutual authentication b/w the DOTS agents.

I want to make sure we have a set of alternatives in place as a minimum requirement for DOTS vendor interoperability.

What I am planning to put into place (be more enforcing) in my DOTS implementation - comments welcome as well as additional suggestions.

PKI

Client and Server Certificates have to be signed by the same CA.  The CA does not need to get exchanged during (D)TLS session set up.  The CA does not need to go back to a well-known root CA.

PSK

The DOTS client 'identity' (potentially FQDN of client) is used for validating the client by the server, and the DOTS server 'identity-hint' (potentially FQDN of server) is used by the client for validating the server.  Obviously they both share the same PSK!

[TR] The "PSK_Identity" and "PSK identity hint" need not be FQDNs of the DOTS client and server, https://tools.ietf.org/html/rfc4279#section-5 does not mandate a particular type of identity.

-Tiru

RPK

Nothing in place so far as I have not worked out how to get OpenSSL to do this for me so far, so have no suggestions here.

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Wed, 3 Jan 2018 11:27:47 -0000

Hi Tiru,

See inline [Jon]

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 03 January 2018 07:38
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] Mutual Authentication between DOTS peers

Hi Jon,

Hi WG,

[TR] No,
<https://tools.ietf.org/html/draft-ietf-dots-signal-channel-14#section-7.1>
https://tools.ietf.org/html/draft-ietf-dots-signal-channel-14#section-7.1
discusses PKI, PSK and RPK and the data channel draft refers to this section
for mutual authentication b/w the DOTS agents.

[Jon] I think I did not phrase this correctly.  I was looking for (and hence
defining as a best practice for DOTS) the specifics of what need to be
checked (enforced) for mutual authentication. 7.1 does refer to a DOTS
server may present a PKIX certificate which the DOTS client then has to
verify, but nothing about how the DOTS server verifies the DOTS client.  [I
should have referred to PKIX in my statement above].

[Jon] My DOTS server for instance (if PKI) requests the Peer Certificate
from the DOTS client - if it is not given, not authorized (CN or Subject
Alternative Name is not valid) or does not have common CA that signed both
the DOTS server and DOTS client certificates, then mutual authentication
from the DOTS server perspective fails.

[Jon] To me, it is the DOTS client that is most likely to be the rogue
element.

PKI

PSK

[TR] The "PSK_Identity" and "PSK identity hint" need not be FQDNs of the
DOTS client and server, https://tools.ietf.org/html/rfc4279#section-5 does
not mandate a particular type of identity.

[Jon] The next paragraph goes on to state "However, the TLS client and
server clearly have to agree on the identities and keys to be used."

[Jon] Again for DOTS vendor interoperability, I think we should indicate
what is acceptable / best practice for DOTS.

[Jon] While the DOTS server and DOTS client may be in the same client
domain, it is possible that different DOTS vendors are supplying different
components.

-Tiru

RPK

 

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 4 Jan 2018 10:54:30 +0000

Hi Jon,

Please see inline [TR2]

From: Jon Shallow [mailto:[email-masked]]
Sent: Wednesday, January 3, 2018 4:58 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: RE: [Dots] Mutual Authentication between DOTS peers

Hi Tiru,

See inline [Jon]

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 03 January 2018 07:38
To: Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Mutual Authentication between DOTS peers

Hi Jon,

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Tuesday, January 2, 2018 10:49 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Dots] Mutual Authentication between DOTS peers

Hi WG,

[Jon] I think I did not phrase this correctly.  I was looking for (and hence defining as a best practice for DOTS) the specifics of what need to be checked (enforced) for mutual authentication. 7.1 does refer to a DOTS server may present a PKIX certificate which the DOTS client then has to verify, but nothing about how the DOTS server verifies the DOTS client.  [I should have referred to PKIX in my statement above].

[Jon] My DOTS server for instance (if PKI) requests the Peer Certificate from the DOTS client - if it is not given, not authorized (CN or Subject Alternative Name is not valid) or does not have common CA that signed both the DOTS server and DOTS client certificates, then mutual authentication from the DOTS server perspective fails.

[Jon] To me, it is the DOTS client that is most likely to be the rogue element.

[TR] Good point, proposed text:

The DOTS server SHOULD support certificate-based client authentication and the DOTS client SHOULD respond to the DOTS server's TLS certificate request message with the
PKIX certificate held by the DOTS client. DOTS client certificate validation MUST be performed as per [RFC5280] and the DOTS client certificate MUST conform to
the [RFC5280] certificate profile. If a DOTS client does not support TLS client certificate authentication, then it MUST support pre-shared key based or raw public key based
    client authentication.

PKI

PSK

[Jon] The next paragraph goes on to state "However, the TLS client and server clearly have to agree on the identities and keys to be used."

[Jon] Again for DOTS vendor interoperability, I think we should indicate what is acceptable / best practice for DOTS.
[Jon] While the DOTS server and DOTS client may be in the same client domain, it is possible that different DOTS vendors are supplying different components.

[TR2] I don't see a DOTS vendor interoperability problem, using some out-of-band mechanism DOTS client and DOTS server have to be provisioned with the secret key and PSK identity. The DOTS client and server do not have to interpret or validate the PSK identity, it is only used to pick the associated shared secret key.

-Tiru

RPK

Regards

Jon