Subject: [Isms] Updated TLSTM document posted

From: Wes Hardaker <[email-masked]>
Date: Tue, 08 Dec 2009 15:27:21 -0800

I've updated the TLSTM document to address all the outstanding WG issues
and comments received to date (roughly 130 comment items were received,
though some were duplicates).

The current version (-02) can be found here:

  http://tools.ietf.org/id/draft-ietf-isms-dtls-tm-02.txt

  (It's currently still redirecting to -01, but I'm sure that will be
  fixed once the publication finishes propagating)

Diffs since last time can be found here:

  http://tools.ietf.org/rfcdiff?url2=draft-ietf-isms-dtls-tm-02.txt

I'll be sending out responses to each person that submitted comments
shortly.  Thanks to everyone who did send in comments as they were all
very helpful.

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "tom.petch" <[email-masked]>
Date: Fri, 18 Dec 2009 18:16:53 +0100

Wes

I find this a bit light still on client side processing of certs.

The I-D rightly says that the use of certs by TLS is optional for
both client and server.  What it does not say is that many, if not
most, uses of TLS require server certs and not client certs - some
stacks would even appear to fail when client certs are involved.

So the environment into which this is going, in terms of TLS,
is that server certs are a commonplace, client certs are not.

As I see, it is the client cert that here is the basis for the
derivation of the securityName and so is REQUIRED.  How
do you ensure that a client Cert is even sent?

- limit the ciphersuites to those where a client cert is REQUIRED?

- require the server library to allow the request of a client cert and insist
that one is requested?

- ...?

And what if no client cert is requested? Perhaps the client 
should terminate the TLS session if the initial handshake does 
not ask for client cert; assuming it can tell.  Most likely,
this will be an implementation bug on the part of the server, failing
to tell the TLS library that that is what it wants, but it could be 
malicious.  And it would be useful to have a MIB object to
count this type of failure (as distinct from 'I did not like the
server cert').

I say 'initial' because a common pattern when client certs are
required is to establish a TLS session with only a server cert
and then to re-negotiate using the secure channel and this 
time asking for a client cert.  This has been going on for many
years, and it has just been noticed that it opens up a hole for
a MITM attack - see the TLS list for more details (if you have  
few weeks to spare reading all the details:-(

Since client certs are a MUST, I think that we should 
exclude this approach and require client certs in all
negotiations (even if a fix for the loophole is imminent).

Tom Petch

----- Original Message ----- 
From: "Wes Hardaker" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, December 09, 2009 12:27 AM
Subject: [Isms] Updated TLSTM document posted

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 Dec 2009 17:22:44 +0100

> negotiations (even if a fix for the loophole is imminent).

Can you make a concrete proposal what should be added/deleted in the
existing ID to address your concern? But keep in mind that we do not
want to mess around with (D)TLS internals. Also not that there is
text like this:

   a)  The (D)TLS server side of the connection identifies the
       authenticated identity from the (D)TLS client's principal
       certificate using configuration information from the
       tlstmCertToTSNTable mapping table.  The resulting derived
       tmSecurityName is recorded in the tmStateReference cache as
       tmSecurityName.  The details of the lookup process are fully
       described in the DESCRIPTION clause of the
       tlstmCertToTSNTable MIB object.  If any verification fails in
       any way (for example because of failures in cryptographic
       verification or because of the lack of an appropriate row in
       the tlstmCertToTSNTable) then the session establishment MUST
       fail, the tlstmSessionInvalidClientCertificates object is
       incremented and processing stops.

The text clearly says that a failure to verify the client's cert
causes processing to stop. It is not clear to me why this is not
sufficient - hence the request for a concrete change proposal.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 22 Dec 2009 16:41:07 -0800

>>>>> On Fri, 18 Dec 2009 18:16:53 +0100, "tom.petch" <[email-masked]> said:

tp> I find this a bit light still on client side processing of certs.

I've tried to careful walk the line of too much vs too little (in fact,
I've recently removed some DTLS specific handling and have moved a lot
of text to an appendix because WG members thought there was too much
detail).  In short, it's not our job to specify how to process
certificates as that's already documented in other documents like 5280.

tp> The I-D rightly says that the use of certs by TLS is optional for
tp> both client and server.

True, but it also says that this document is only specifying X.509 based
authentication of clients and servers.  It doesn't preclude other forms
of TLS usage, but is only concentrating on the X.509 usage.

tp> What it does not say is that many, if not most, uses of TLS require
tp> server certs and not client certs - some stacks would even appear to
tp> fail when client certs are involved.

Most web uses do, yes.  I have a number of personal client-side
certificates that disagree with your statement that they're not commonly
used.  Their usage has definitely been increasing in the past decade,
though not as much over port 80 which is where many people believe all
TLS takes place.

tp> As I see, it is the client cert that here is the basis for the
tp> derivation of the securityName and so is REQUIRED.  How
tp> do you ensure that a client Cert is even sent?

You'll get an error if you follow the Elements of Procedure without a
client offering a certificate.  Specifically:

           If any verification fails in any way (for example because of
           failures in cryptographic verification or because of the lack
           of an appropriate row in the tlstmCertToTSNTable) then the
           session establishment MUST fail, the
           tlstmSessionInvalidClientCertificates object is incremented
           and processing stops.

tp> And what if no client cert is requested? Perhaps the client 
tp> should terminate the TLS session if the initial handshake does 
tp> not ask for client cert; assuming it can tell.  Most likely,
tp> this will be an implementation bug on the part of the server, failing
tp> to tell the TLS library that that is what it wants, but it could be 
tp> malicious.  And it would be useful to have a MIB object to
tp> count this type of failure (as distinct from 'I did not like the
tp> server cert').

We could create counters to identify every particular type of error that
may result from TLS, but the number of counters would be huge and be
very specific to TLS processing.  The WG has specifically avoided
management of TLS specific internals and it is hoped that future TLS and
X.509 specific MIB objects may be developed in other working groups.

You're right that problems like you've listed will result in failed
connections.  It is impossible for this document to enumerate all the
possible connection failure cases without duplicating most of the TLS
and 5280 documents in the process.

tp> I say 'initial' because a common pattern when client certs are
tp> required is to establish a TLS session with only a server cert
tp> and then to re-negotiate using the secure channel and this 
tp> time asking for a client cert.

That's common for applications where a client certificate isn't
required, yes.  For us we always require a client cert.

---

From: "tom.petch" <[email-masked]>
Date: Thu, 24 Dec 2009 11:03:30 +0100

Juergen

The text you quote is fine; I am concerned about an earlier problem,
getting a certificate to validate in the first place, about which more should
be said in Appendix B, such as:

"The (D)TLS client initiates the handshake protocol with a ClientHello
message but the server can request a handshake, initial or as part
of a re-negotiation, with a HelloRequest"

and

"Most applications running over TLS authenticate the server with a
certificate and do not authenticate the client.  When the client is
authenticated, then it is often as part of a re-negotiation, that is a
secure channel is established with an initial handshake with server
authentication only and then a re-negotiation authenticates the client.

The TLS client cannot send an unsolicited certificate; it can only
send one when requested to by the TLS server, and then only of
the type that the server requests.  The derivation of the SNMP
securityName depends on the client certificate and so SNMP
applications acting as a TLS server must ensure that the handshake
requests a client certificate suitable for authentication.

The client can send application data after an initial handshake and
prior to re-negotiation and so the client certificate must be requested
as part of the initial handshake and not left to re-negotiation."

A reference for this would be RFC5246.

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Thu, 24 Dec 2009 11:29:25 +0100

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
Sent: Wednesday, December 23, 2009 1:41 AM

> >>>>> On Fri, 18 Dec 2009 18:16:53 +0100, "tom.petch" <[email-masked]>
said:
<snip>

> though not as much over port 80 which is where many people believe all

To quote the author of RFC5246,

"it's common (well, common in the small number of cases where client certs are
used at all) for the server to let the client connect and request a resource and
then if the resource is protected renegotiate asking for a certificate"

or this quote just in from the TLS list

> Although it's technically possible to implement client identity
> protection securely with the existing protocol, it is so significantly
> underspecified that it makes it unlikely that even those clients
> which care about this, implement it in a secure fashion today.

Ouch!

Ask most people with a TLS background (as opposed to operations)
and I expect you will find the view that
- client authentication is rare
- when the client is authenticated, it is as part of re-negotiation
so that is the environment I see us going into; hence the need to say
more.

Tom Petch

<snip>

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 24 Dec 2009 06:49:19 -0800

>>>>> On Thu, 24 Dec 2009 11:29:25 +0100, "tom.petch" <[email-masked]> said:

tp> - when the client is authenticated, it is as part of re-negotiation
tp> so that is the environment I see us going into; hence the need to say
tp> more.

During the last IETF meeting it was decided that we shouldn't say
anything in particular about the existing TLS renegotiation problems as
they're out of scope.  Mentioning it seems like an obvious thing to, but
in the end: the problem is known and is being handled by the base
protocol working group.  It's not our job to document the potential
flaws in the other protocol.  Nor is it our job to document every
possibly insecure method of implementing the base protocol.  If we went
down that road there are actually a number of things we might have to
list.

Consider the SSHTM document.  Why didn't we say in it that SSH version 1
is an insecure version of the protocol and shouldn't be used?  It's
fundamentally the same problem, but much older.  Should we document
every potential TLS issue people may run into?  I don't think that's our
job.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 24 Dec 2009 06:56:31 -0800

>>>>> On Thu, 24 Dec 2009 11:03:30 +0100, "tom.petch" <[email-masked]> said:

tp> The text you quote is fine; I am concerned about an earlier problem,
tp> getting a certificate to validate in the first place, about which
tp> more should be said in Appendix B, such as:

Would the following statement, added to the a) bullet in 5.3 meet your
needs?

"The (D)TLS server MUST request and expect a certificate from the client
and MUST NOT accept messages over the (D)TLS session until the client
has sent one."

tp> "The (D)TLS client initiates the handshake protocol with a ClientHello
tp> message but the server can request a handshake, initial or as part
tp> of a re-negotiation, with a HelloRequest"

It's been decided that we can't go into that much detail about the TLS
protocol.  IE, listing the "HelloRequest" message type is too much (and
in fact, I just removed references to other message types from the
document at the request of the WG).  We should be stating things more
generically than that.  I agree we need to state absolutely that the
client must present a certificate and the server must expect one, which
I tried to craft into the above sentence.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "David Harrington" <[email-masked]>
Date: Thu, 24 Dec 2009 10:01:05 -0500

+1

dbh 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Wes Hardaker
> Sent: Thursday, December 24, 2009 9:49 AM
> To: tom.petch
> Cc: [email-masked]

---

From: "tom.petch" <[email-masked]>
Date: Thu, 24 Dec 2009 20:00:47 +0100

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
Sent: Thursday, December 24, 2009 3:49 PM

> every potential TLS issue people may run into?  I don't think that's our

I think that you misconstrue my point.

When client certificates are used, the commonest way of using them is
re-negotiation (based on posts to the TLS list and other places).  This
is current technology, accepted and used (I would not put SSH v1
in that category).

SNMP TLS servers must request client certificates and must not
re-negotiate to do so, not because a loophole that will in all
probability be fixed before this I-D hits the streets, but because
this technique will have the TLS client sending SNMP messages
before the client certificate has arrived - there is nothing to stop it.
So rather than having the first n SNMP messages fail because there
is no client certificate from which to generate a securityName,
ban this technique for this application.

We must not ban renegotiation because it is needed; TLS recommends
that security parameters are renegotiated every 24 hours, and SNMP
sessions will last longer than that.

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Thu, 24 Dec 2009 20:31:45 +0100

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
Sent: Thursday, December 24, 2009 3:56 PM

> and MUST NOT accept messages over the (D)TLS session until the client

Yes, that addresses my main concern; perhaps it would be better to say
'until the server has received one'
but I leave that up to you.

> I tried to craft into the above sentence.

I find the existing sentence
"Only the (D)TLS
   client can initiate the handshake protocol.  "
--- well, not right - no need to mention TLS messages but I think we should
hint at the server's ability to kick things off.

Perhaps

"The (D)TLS client initiates the handshake protocol while the (D)TLS
server can ask the client to do so."

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 27 Dec 2009 14:50:57 +0100

> and MUST NOT accept messages over the (D)TLS session until the client

To be more precise, s/messages/SNMP messages/

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 27 Dec 2009 14:56:55 +0100

> sessions will last longer than that.

Speaking as a technical contributor, I think the proposed addition to
5.3 makes it clear that SNMP messages arriving before the mutual
authentication is complete are not processed. I do not think we need
to go into the (D)TLS specifics how to achieve mutual authentication
or how to minimize the risk of getting SNMP messages before mutual
authentication is complete.

/js

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 28 Dec 2009 07:28:54 -0800

>>>>> On Sun, 27 Dec 2009 14:50:57 +0100, Juergen Schoenwaelder <[email-masked]> said:

JS> To be more precise, s/messages/SNMP messages/

Will do.

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 28 Dec 2009 07:30:13 -0800

This is the final sentence that I added:

The (D)TLS server MUST request and expect a certificate from the
client and MUST NOT accept SNMP messages over the (D)TLS session until
the client has sent one and it has been authenticated.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "David Harrington" <[email-masked]>
Date: Mon, 28 Dec 2009 10:45:49 -0500

"sent one" is ambiguous.
Does it have to send a certificate or an SNMP message? 

dbh

> Sent: Monday, December 28, 2009 10:30 AM
> To: Wes Hardaker
> Cc: [email-masked]
> >>>>> On Sun, 27 Dec 2009 14:50:57 +0100, Juergen 
> Schoenwaelder <[email-masked]> said:
>

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 28 Dec 2009 07:46:55 -0800

>>>>> On Mon, 28 Dec 2009 10:45:49 -0500, "David Harrington" <[email-masked]> said:

DH> "sent one" is ambiguous.
DH> Does it have to send a certificate or an SNMP message? 

Ok, then:

The (D)TLS server MUST request and expect a certificate from the
client and MUST NOT accept SNMP messages over the (D)TLS session until
the client has sent a certificate and it has been authenticated.

---

From: "tom.petch" <[email-masked]>
Date: Wed, 30 Dec 2009 15:08:28 +0100

s1.1
"Either SNMP entity may act as client or as server."

This seems to tell me that a CG or NO can be TLS client or TLS server, but 3.3
used to say
"(D)TLS sessions may be initiated by (D)TLS clients on behalf of
   command generators, notification originators, proxy forwarders "

which suggests that CG and NO are TLS clients.

Please clarify.

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Wed, 30 Dec 2009 15:12:14 +0100

5.3 3)b (I think)

dbh commented on 
"determine the if the presented identity matches"
to which WH replied
"It makes sense to me as is and you don't describe how you're
      confused so it's hard to fix your issue with it."

Yes it makes sense to me, but I would find it more grammatical if
it read
"determine if the presented identity matches"

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Wed, 30 Dec 2009 15:15:16 +0100

"4)  The (D)TLS-specific session identifier is set in the sessionID of
       the tmStateReference passed to the TLS Transport Model to
       indicate that the session has been established successfully and
       to point to a specific (D)TLS session for future use."

sessionID does not exist here (does in TLS:-)

And I think that 
"The (D)TLS-specific session identifier"
is tlstmSessionID
in which case, please say it explicitly ie
"The (D)TLS-specific session identifier, tlstmSessionID, is set ....

Tom Petch

---

From: "David Harrington" <[email-masked]>
Date: Wed, 30 Dec 2009 10:27:20 -0500

Hi,

What it should say is
"(D)TLS sessions may be initiated by (D)TLS clients on behalf of
SNMP appplications that initiate communications, such as command
generators, notification originators, proxy forwarders."

RFC3411 architecture allows for new applications to be defined, so the
old wording was too restrictive, and, as you point out, the current
wording is not restrictive enough.

dbh 

> Behalf Of tom.petch
> Sent: Wednesday, December 30, 2009 9:08 AM
> To: Wes Hardaker; [email-masked]
> Subject: Re: [Isms] Updated TLSTM document 1.1
> 
> s1.1

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 30 Dec 2009 08:17:17 -0800

>>>>> On Wed, 30 Dec 2009 10:27:20 -0500, "David Harrington" <[email-masked]> said:

DH> What it should say is
DH> "(D)TLS sessions may be initiated by (D)TLS clients on behalf of
DH> SNMP appplications that initiate communications, such as command
DH> generators, notification originators, proxy forwarders."

Good text; thanks!  Changed!
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 30 Dec 2009 08:19:43 -0800

>>>>> On Wed, 30 Dec 2009 15:15:16 +0100, "tom.petch" <[email-masked]> said:

tp> And I think that 
tp> "The (D)TLS-specific session identifier"
tp> is tlstmSessionID
tp> in which case, please say it explicitly ie
tp> "The (D)TLS-specific session identifier, tlstmSessionID, is set ....

Actually, it should say the "TLSTM-specific session identifier", which
I've changed it to and also added your suggested reference to tlstmSessionID.

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 30 Dec 2009 08:20:34 -0800

>>>>> On Wed, 30 Dec 2009 15:12:14 +0100, "tom.petch" <[email-masked]> said:

tp> Yes it makes sense to me, but I would find it more grammatical if
tp> it read
tp> "determine if the presented identity matches"

Yes, David and I actually already resolved that particular issue over
private email.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "tom.petch" <[email-masked]>
Date: Wed, 30 Dec 2009 19:12:11 +0100

----- Original Message ----- 
From: "David Harrington" <[email-masked]>
Sent: Wednesday, December 30, 2009 4:27 PM
Subject: RE: [Isms] Updated TLSTM document 1.1

> wording is not restrictive enough.

Good

What about 1.1, 

"Either SNMP entity may act as client or as server."
 in isolation, at the start, still looks misleading to me.

Or are you suggesting that this text appears in 1.1 and in
3.3 ?

Tom Petch

---

From: "David Harrington" <[email-masked]>
Date: Wed, 30 Dec 2009 14:43:59 -0500

> Or are you suggesting that this text appears in 1.1 and in

How about
"An SNMP entity may act as client or server or both, depending on the
SNMP applications supported."

dbh

---

From: "tom.petch" <[email-masked]>
Date: Thu, 31 Dec 2009 12:18:12 +0100

----- Original Message ----- 
From: "David Harrington" <[email-masked]>
Sent: Wednesday, December 30, 2009 8:43 PM

> SNMP applications supported."
 
Looks good,

Tom Petch