Subject: [Netconf] Kathleen Moriarty's Discuss on draft-ietf-netconf-call-home-11: (with DISCUSS and COMMENT)

From: "Kathleen Moriarty" <[email-masked]>
Date: Wed, 21 Oct 2015 06:53:30 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-netconf-call-home-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 2.1 & 3.1
Why is authentication limited to server-side authentication?  It seems
that this really should be mutual authentication to ensure the server is
also connecting to the correct client and there was no attack prior to
the callback.
3.1 S3 - Why is client-side authentication optional?

Without this must, there should be a security consideration that the call
back could go to a malicious client.  The types of authentication matter
as well, but that's covered in Stephen's discuss points along with the
SecDir review questions on TLS-PSK.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In section 1.3, please add a sentence that points to the threat/security
analysis for use of this function with NETCONF and RESTCONF after the
last sentence:

   In such circumstances, allowing the SSH/TLS server to contact the
   SSH/TLS client would open new vulnerabilities.  Any use of call home
   with SSH/TLS for purposes other than NETCONF or RESTCONF will need a
   thorough, contextual security analysis.

---

From: Kent Watsen <[email-masked]>
Date: Wed, 21 Oct 2015 20:52:12 +0000

Hi Kathleen,

Thank you for your review.

>also connecting to the correct client and there was no attack prior to

Both NETCONF ad RESTCONF require client authentication, and this is called out in the Applicability Statement (Section 1.3).  Also, in the "The NETCONF or RESTCONF Client” section, it says:

   C7  After the server's host key or certificate is validated, the SSH
   or TLS protocol proceeds as normal to establish a SSH or TLS
   connection.

The “proceeds as normal” is intended to cover client authentication.  Also, in the "The NETCONF or RESTCONF Server” section, it says:

   S5  In most cases, establishing the SSH or TLS connection also
   entails server authentication of client credentials; only with
   RESTCONF do some client authentication schemes occur after the
   secure transport connection (TLS) has been established.  If
   client authentication is required, and the client is unable to
   successfully authenticate itself to the server in an amount of
   time defined by local policy, the server MUST close the
   connection.

Which speaks to it as well.

Do you believe there is a need to change the text?

>SecDir review questions on TLS-PSK.

Do mean S5 pasted above where it says “If client authentication is required”?

This text is speaking about transport-level client-auth.  NETCONF over SSH or over TLS both have transport-level authentication, but RESTCONF (e.g., HTTPS) allows the Basic and Digest authentication modes, and that client auth happen after the TLS session is established.

Is it clear now, or do you think that text should be updated?

>   thorough, contextual security analysis.

Unfortunately, there isn't an analysis to point to.  The “analysis” is happening now along with the SecDir review.   Do we need to perform such an analysis now?

Thanks again,
Kent

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 21 Oct 2015 18:07:57 -0400

Hi Kent,

Thanks for your quick response.  I'm just on an iPhone, but don't want to wait to respond in case it helps you.  Inline.

Sent from my iPhone

> On Oct 21, 2015, at 4:52 PM, Kent Watsen <[email-masked]> wrote:
> 
> 
> Hi Kathleen,
> 
> The “proceeds as normal” is intended to cover client authentication.  

Ok, this wasn't clear to me, but probably isn't the sentence to fix.

> Also, in the "The NETCONF or RESTCONF Server” section, it says:
> 
> 
>   secure transport connection (TLS) has been established.  

I think if this said, "Establishing an SSH or TLS session requires server authentication of client credentials, with the exception of..."

The point would be more clear as I didn't realize this was already the case from the language in this draft.

> If

Yes, but just the text where I made a suggestions u be enough to get the point across more clearly.

> Do mean S5 pasted above where it says “If client authentication is required”?

Yes.
> This text is speaking about transport-level client-auth.  NETCONF over SSH or over TLS both have transport-level authentication, but RESTCONF (e.g., HTTPS) allows the Basic and Digest authenticatio…

Ok, is it possible to make this more clear?  I think Stephen has a discuss on HTTPAuth methods already, so that can be discussed in his thread.  I just ask that you point to the newly updated RFCs on these 2 standards as they do a good job of outlining all of the security considerations, which are substantial.  RFC7616 & RFC 7615
> Unfortunately, there isn't an analysis to point to.  The “analysis” is happening now along with the SecDir review.   Do we need to perform such an analysis now?
The section reads as if one exists and that you've mitigated the risks.  As such, I'd expect to see all of the security considerations for using the method defined in this draft.  Making the auth requirements more clear will help and pointing out the vulnerability of the HTTPAuth basic and digest modes for RESTCONF in the security considerations is part of that.  

Mention of the possibility of connecting to an incorrect client (possibly malicious) in the few instances where client auth isn't required or is weak is important as well for the reader.

Thank you!
Kathleen

---

From: Kent Watsen <[email-masked]>
Date: Sat, 24 Oct 2015 05:17:21 +0000

Hi Kathleen,

>Ok, this wasn't clear to me, but probably isn't the sentence to fix.

In the DISCUSS with Stephen, I offered to add the following text to the end of C7:

  When performing client-authentcation with the NETCONF/RESTCONF
  server, the NETCONF/RESTCONF client MUST ensure to only use
  credentials that had previously associated for the NETCONF/RESTCONF
  server’s presented host key or server certificate.

I know you said this may not be the sentence to fix, but does it resolve this issue for you?

>The point would be more clear as I didn't realize this was already the case from the language in this draft.

Consider it done.

>Yes, but just the text where I made a suggestions u be enough to get the point across more clearly.

Sure, I’ll make the fix mentioned above.

>> Do mean S5 pasted above where it says “If client authentication is required”?

OLD:

NEW:   s/client/transport (SSH or TLS) level client/

      transport (SSH or TLS) level client authentication is required, and the client is unable to

Does this text resolve your issue?

>Ok, is it possible to make this more clear?  I think Stephen has a discuss on HTTPAuth methods already, so that can be discussed in his thread.  I just ask that you point to the newly updated RFCs o…

Sure  (but I’ll assume you meant 7617, instead of 7616)

>Mention of the possibility of connecting to an incorrect client (possibly malicious) in the few instances where client auth isn't required or is weak is important as well for the reader.

Hmmm, so I’m not sure what to do with this comment.  

Yes, per Stephen’s DISCUSS, make the auth requirements more clear, and point out the vulnerability of the HTTPAuth basic and digest modes for RESTCONF in the security considerations (pending feedback from TLS WG and openssh list).

But back to Section 1.3, is there a specific change in the text that you’re hoping to see here?

Thanks,
Kent

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 27 Oct 2015 14:55:34 -0400

Hi Kent,

Responses in-line.  I think we are about good-to-go with one
correction and suggested text for the last item.

> I know you said this may not be the sentence to fix, but does it resolve this issue for you?

Sure, this works with the update you agreed to below.

Thank you!

Thank you!

> Does this text resolve your issue?

This works for me, thanks.

> Sure  (but I’ll assume you meant 7617, instead of 7616)

Basic is in RFC7616 and digest is in RFC7617, so you are partially
correct and I had the incorrect number in my message.

> But back to Section 1.3, is there a specific change in the text that you’re hoping to see here?

How about the following:

OLD:

   This contrasts with the base SSH and TLS protocols, which do not
   require programmatic verification of the other party (section 9.3.4
   of [RFC4251], section 4 of [RFC4252], and section 7.3 of [RFC5246]).
   In such circumstances, allowing the SSH/TLS server to contact the
   SSH/TLS client would open new vulnerabilities.  Any use of call home
   with SSH/TLS for purposes other than NETCONF or RESTCONF will need a
   thorough, contextual security analysis.

NEW:

   This contrasts with the base SSH and TLS protocols, which do not
   require programmatic verification of the other party (section 9.3.4
   of [RFC4251], section 4 of [RFC4252], and section 7.3 of [RFC5246]).
   In such circumstances, allowing the SSH/TLS server to contact the
   SSH/TLS client would open new vulnerabilities.  Any use of call home
   with SSH/TLS needs a
   thorough, contextual security analysis.  The analysis for NETCONF and
   RESTCONF is underway.

I don't think you have a reference to add for this, correct?  If you
do, I would put that in as well.

-- 

Best regards,
Kathleen

---

From: Kent Watsen <[email-masked]>
Date: Tue, 27 Oct 2015 23:08:28 +0000

[top-posting for convenience]

Hi Kathleen,

Regarding "The analysis for NETCONF and RESTCONF is underway.”, I’m happy to add the text but wonder what it refers to.  Does it refer to this IESG review, or the pending discuss with the TLS WG and openssh list, or something else?   If it’s “something else”, we may be in trouble, as there is nothing else I’m aware of...

Thanks,
Kent

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 27 Oct 2015 22:06:14 -0400

Sent from my iPhone

> On Oct 27, 2015, at 7:08 PM, Kent Watsen <[email-masked]> wrote:
> 

I thought you said this was underway in Stephen's discuss.  If not, please tweak the text to say this has not been done and there are associated risks.  The current text reads as if RESTCONF and NETCONF are somehow exempt from the risks.

Thanks,
Kathleen