Subject: Re: [TLS] some questions for your draft

From: yangqinqin <[email-masked]>
Date: Wed, 25 Nov 2009 16:45:37 +0800

Marsh,

Thank you for your reply. I have just joined the mailing list.

In your draft, 
 "If the other end attempts to authenticate with a different identity, the renegotiation MUST fail."

How do you achieve it in the renegotiation?  

You also wrote in the draft,  "For certificate based cipher suites, this means bitwise equality of the end-entity certificate. " 

This increases authentication steps. But original TLS renegotiation protocol has not this step. 

Thanks,

Qinqin Yang

----- Original Message ----- 
From: Marsh Ray 
To: yangqinqin 
Cc: Steve Dispensa ; Nasko Oskov ; Eric Rescorla 
Sent: Wednesday, November 25, 2009 9:33 AM
Subject: Re: some questions for your draft

yangqinqin wrote:
> Thank you for your reply.
> But I have not joined the mailing list.  And I didn' t find it in the
> archives of the [TLS] mailing list. There are  too many mails related to
> this question. Moreover, english is not my native language. So I hope
> you will give me answer.

Here's one message I can find:

http://www.ietf.org/mail-archive/web/tls/current/msg04136.html
> I really don't like to allow both, change of identities during
> renegotiation _and_ arbitrary interleaving of application data
> with the renegotiation handshake messages.  Applications
> may get this wrong easily

It sounds like the wording is motivated in part by the ambiguity of
application data transmitted between the Change Cipher Spec and Finished
messages.

I suspect it's also a recognition that many applications are expecting
authentication to strengthen across renegotiation, but not change entirely.

- Marsh

---

From: Marsh Ray <[email-masked]>
Date: Wed, 25 Nov 2009 10:44:35 -0600

yangqinqin wrote:
> In your draft, "If the other end attempts to authenticate with a
> different identity, the renegotiation MUST fail."
> 
> You also wrote in the draft,  "For certificate based cipher suites,
> this means bitwise equality of the end-entity certificate. "
> 

Yeah, I don't know how that got in there.

I certainly didn't put it in, and I do not think it has any place in the
TLS spec.

- Marsh

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 25 Nov 2009 08:55:22 -0800

At Wed, 25 Nov 2009 10:44:35 -0600,
> I certainly didn't put it in, and I do not think it has any place in the

As I said, Pasi Eronen suggested it and it seemed sound to me.

I'm not wedded to it and if the WG feels that it's a bad idea, I'll
gladly take it out. Pasi?

-Ekr

---

From: Nasko Oskov <[email-masked]>
Date: Wed, 25 Nov 2009 17:19:23 +0000

Eric Rescorla wrote:
>> I certainly didn't put it in, and I do not think it has any place in 
>> the TLS spec.
>
>I'm not wedded to it and if the WG feels that it's a bad idea, I'll gladly
>take it out. Pasi?

I would suggest we don't modify this behavior as part of the fix. Someone
already mentioned load balancers that change certs on renegotiation. At the
very least this could be a SHOULD instead of MUST.

The way I read it, it prevents the current client auth implementations,
since it disallows change of identity (from anon to authenticated).

Nasko

---

From: Martin Rex <[email-masked]>
Date: Wed, 25 Nov 2009 18:24:22 +0100 (MET)

I'm actually very favourable of a restriction that already established
identities (not the lack thereof!) must not change during renegotiaton,
and contemplating to add this into my proposal as well.

http://www.ietf.org/mail-archive/web/tls/current/msg04136.html
http://www.ietf.org/mail-archive/web/tls/current/msg04132.html
http://www.ietf.org/mail-archive/web/tls/current/msg04091.html

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Wed, 25 Nov 2009 11:33:47 -0600

> and contemplating to add this into my proposal as well.

I believe the current TLS specs do not have a sufficiently rigorous
definition of "identity" in order to be mandating restrictions like
this. memcmp() of certs doesn't cut it. At best, they will be ignored.
At worst, they will entice developers to make unsafe assumptions.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Wed, 25 Nov 2009 18:34:06 +0100 (MET)

> very least this could be a SHOULD instead of MUST.

I haven't fully understood the scenario the Yngve described.

On a regular renegotiation (full handshake followed by a renegotiation)
this is not going to happen, unless a MitM is performed.

I assume that it happens on an attempted TLS session resume for
which the server performs a full handshake instead.

If the client has a problem with the identity change from the
failed proposed resume to the successful full handshake, then
this is a client problem.

I consider it somewhat unlikely (but not impossible) that the
backend infrastructure behind that loadbalancer shares TLS session
caches but not TLS credentials.

> since it disallows change of identity (from anon to authenticated).

This interpretation might be non-intentional.  I would assume that
changing state from non-authenticated to authenticated during
renegotiation, as it is current practice with delayed client authentication,
is not what this requirement intended to prohibit in the future.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 25 Nov 2009 19:25:36 +0100 (MET)

> At worst, they will entice developers to make unsafe assumptions.

memcmp() of the certs is the only way TLS can implement this.
This is the only concept of identical known to TLS.

Equivalence between different certs (that may even come from
different PKIs) is completely outside of the scope of TLS.
As previous mentioned this is the last paragraph of the
introduction of the TLS spec:

                          The TLS standard, however, does not specify how
   protocols add security with TLS; the decisions on how to initiate TLS
   handshaking and how to interpret the authentication certificates
   exchanged are left to the judgment of the designers and implementors
   of protocols that run on top of TLS.

Yes, I'm aware that a memcmp() restriction is going to cause
a disruption for Servers that both, actively use renegotiation and
allow server certificates to be updated in-flight. (A lot of servers
require a restart for replacing/updating the server certificate, though).

If that is a concern for certain clients, then these clients must
either implement a re-connect retry mechanism or provide an
authentication (callback) function that will perform the necessary
comparison of the server identity for renegotiation and can handle
a server certificate renewal.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Wed, 25 Nov 2009 12:40:54 -0600

> This is the only concept of identical known to TLS.

It's a pretty weak concept of "identity", too.

>    of protocols that run on top of TLS.

The spec is saying not to do what you advocate because it's outside the
scope of TLS.

> require a restart for replacing/updating the server certificate, though).

Then please please don't bundle it in with what is supposed to be an
urgent bugfix.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Wed, 25 Nov 2009 19:52:10 +0100 (MET)

> It's a pretty weak concept of "identity", too.

It is the strongest possible concept of "equivalent identity" in existance.

It is also the only one for which I consider a full re-authentication
dispensable.

Which is what I'm trying to achieve.  I would not know how to force
a re-authentication onto an existing client app.

> The spec is saying not to do what you advocate because it's outside the

The spec says that TLS does not include authentication
(it often performs certificate path validation, though).

> Then please please don't bundle it in with what is supposed to be an

I think we do have another security problem here that
we should fix.  There may be a number of apps that simply do not
expect that they have to reauthenticate if renegotation allows
the identity to change.

Could you elaborate on usage scenarios which might be adversly affected
by such a requirement/constraint?

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Wed, 25 Nov 2009 13:17:45 -0600

> It is the strongest possible concept of "equivalent identity" in existance.

certificate != identity

> a re-authentication onto an existing client app.

Most apps shouldn't allow renegotiation at all. The few that do had
better know what they're doing.

> expect that they have to reauthenticate if renegotation allows

I agree that there are a lot of apps out there that are not
renegotiation-aware.

> by such a requirement/constraint?

No, I don't have to in order to support my argument. In order to support
yours though, you need to prove that there are no such apps in existence.

TLS is a protocol that operates at certain layers, it provides certain
guarantees, and offers certain features.

A spec and a version number only have meaning to the extent that the
guarantees are properly met and that existing functionality doesn't get
yanked out based on the opinions of arbitrary folks on a mailing list
like you and me.

- Marsh

---

From: Kyle Hamilton <[email-masked]>
Date: Wed, 25 Nov 2009 11:53:49 -0800

Do *not* put any arbitrary policy decisions into an IETF standard.
Such as "must not change Identity".

I can see *several* situations where an identity could be usefully
changed inside a connection -- for example, a manager putting in her
smart card (on the same machine as the worker) and keying in her pin,
to be prompted by the server to authorize a given transaction -- and
then pulling the smart card out again, thus removing the capability to
use that key.  (This is the kind of thing that is done at, for
example, Fry's Electronics... except that they just use usernames and
passwords to authenticate and authorize.)

Another is the case where a given identity is unacceptable for some
operation -- for example, I end up using my kyanhaATkyanhaDOTnet
certificate to try to do something that only [email-masked] is
allowed to do.  I'd prefer to keep the same TLS connection, just
change the identity that it's bound to.

(What about the situation where your cert has been revoked and OCSP is
saying that it is, and you're trying to put a replacement into place?
Or, if the root you've been using has been dropped from the Trust List
of whatever browser your clients are using -- you're suddenly
untrusted.  So you need to get a completely different signer -- and
that will completely fail the memcmp test.  It might even fail strcmp
on the components of the Subject.  Regardless, this is outside the
scope of TLS; it is the application designer and the application
consumer who determine the security policy that they're going to use,
not any one of us.)

-Kyle H

On Wed, Nov 25, 2009 at 10:52 AM, Martin Rex <[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Kyle Hamilton <[email-masked]>
Date: Wed, 25 Nov 2009 12:00:03 -0800

TLS does not mandate authentication, and thus does not mandate any
specific Identity.  The only case where it mandates authentication is
when the Server wishes to ask the Client for its identity, and that's
arguably a policy decision which, since it's in the spec, is a bug.
(I can see HTTP servers not being able to, but as an underlying
protocol TLS shouldn't cater to the wants of specific protocols and
protocol usages.)

TLS also does not specify certificate path validation -- that is the
function of PKIX, currently RFC 5280.  It just happens that because
ASN.1 DER and BER aren't common in the internet world, the only things
that can really parse it are special-purpose certificate verifiers,
and those are special-purpose enough that they get bundled with most
TLS implementations.

However, separate libraries for validating certificates do exist.
http://libpkix.sourceforge.net/ is one that is open-source.
Certificate path validation is not inherently tied to TLS -- just
think of S/MIME, hmm?

-Kyle H

---

From: <[email-masked]>
Date: Wed, 25 Nov 2009 21:02:55 +0100

> gladly take it out. Pasi?

IMHO the recent discussions seem to indicate that many applications
would be confused (in ways that could lead to security problems) by
identity changes during renegotiation, because the TLS library APIs
usually try to hide renegotiation from applications.

While the RI extension fixes the man-in-the-middle problem, it doesn't
remove the problems when there is no man-in-the-middle, just the two
endpoints (either of whom could be potentially malicious).

So IMHO this draft needs either Security Considerations text
explaining "even when the RI extension is used, renegotiation is quite
likely to do things you wouldn't expect and possibly break your
security", or make the default behavior much less surprising.
I would prefer the latter. 

For the TLS library, the only form of identity comparison it can do is
memcmp(), since all the rest depends on what semantics the
applications give to various fields in the certificate (subject,
subjectAltName, NameConstraints, Clearance, CertificatePolicies,
etc.). But if the application wants to do more complex identity
comparison, it can do so.

(And the current text intentionally allows moving from e.g. DH-anon or
server-only auth to mutual auth with certs.)

Best regards,
Pasi

---

From: <[email-masked]>
Date: Wed, 25 Nov 2009 21:05:39 +0100

Nasko Oskov wrote:

> Someone already mentioned load balancers that change certs on
> renegotiation. At the very least this could be a SHOULD instead of
> MUST.

Yngve's email was about a load balancer directing different TCP
connections to different physical servers (with different certs),
which would mean different HTTP requests for the same page could
end up in different servers.

But renegotiation is not going to move your TLS connection from one
physical box to another, so there the cert would remain same.

(And note the requirement is qualified by "unless the application
explicitly asks to allow identity changes")

> since it disallows change of identity (from anon to authenticated).

The intention was to allow changing from anon to authenticated,
but perhaps the wording isn't as clear as it should be.

Best regards,
Pasi

---

From: Martin Rex <[email-masked]>
Date: Wed, 25 Nov 2009 21:28:26 +0100 (MET)

> Such as "must not change Identity".

You put it _much_ more generic that it is being discussed.

> passwords to authenticate and authorize.)

I don't see why this is a renegotiation scenario.
And it seems that your area of application does perform a
re-authentication at the app-level (and looks like a change
in client-identity, not a server-identity), so it doesn't
apply to the scenario that I want to get fixed.

Your help in wiggling out the details of the final constraint
is still welcome.  I would want such a constraint to be as clear
as we can make it in order to not break existing usage scenarios
and possible future applications of the TLS technology.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 25 Nov 2009 21:33:37 +0100 (MET)

> and those are special-purpose enough that they get bundled with most

That is not fully correct.  If you read through the description
of the Server Certificate message in the TLS spec, that does
create a certain level of expectations what a TLS implementation
should do with regards to Server Certificate Validation.

-Martin

---

From: Bruno Harbulot <[email-masked]>
Date: Wed, 25 Nov 2009 20:39:24 +0000

Hello,

> At worst, they will entice developers to make unsafe assumptions.

(Apologies for jumping in this discussion, I have only been able to read 
  some of the e-mails posted on this list this month.)

I think the TLS spec should stay away from the concept of identity. This 
is too vague a concept and people have different expectations for it. 
It's more appropriate in something like PKIX.

Some certificate-based mechanisms do not necessarily rely on the concept 
of user identity (in the sense of certificate = user).

One could imagine a situation where a client would initially present a 
client certificate that contains attributes (like an attribute 
certificate), but that doesn't embed the attributes the server wants for 
this particular request. The server could then initiate a re-negotiation 
to ask the client to present another certificate, with other attributes. 
This can be particularly useful for role-based (or virtual organisation) 
authorisation, for example.
The concept of identity then becomes rather loose; in some contexts, 
anonymity might even be required.

I don't think that TLS should address this; rather, it should be up to 
the components that verify the certificates.

Best wishes,

Bruno.

---

From: yangqinqin <[email-masked]>
Date: Thu, 26 Nov 2009 11:55:19 +0800

>Bruno Harbulot wrote:

>the components that verify the certificates.

I agreed that  the concept of identity is too vague a concept and people have different expectations for it. And a client can have several different client certificates that contains attributes,  particularly, for role-based authorization. So I think that TLS should allow such identity changes during renegotiation. 

>comparison, it can do so.

For identity comparison during renegotiation,TLS may only do memcmp() , and  more complex identity
comparison  can be left to Specific application to do. There shloud have a alarm message to applications and leave applications to choose whether to continue re-negotiation.

Best regards,

Qinqin Yang

---

From: yangqinqin <[email-masked]>
Date: Thu, 26 Nov 2009 12:31:47 +0800

Nico wrote:
>On Mon, Nov 09, 2009 at 10:52:31PM +0100, Martin Rex wrote:

>> Personally, I would it find much cleaner if the semantics for the
>> renegotiation would require the TLS peers to suspend transmission
>> of application data while performing TLS renegotiation,
>> i.e.

>+1

>This is the right time to add such a constraint.

>Unlike a "authenticated identities can't change" constraint, this could
>be implemented without conceivable app protocols being broken, I think,
>but it may require API changes for some implementations, and that it may
>put this change out of reach.+1I agree to add such a constraint in this draft. 

  ----- Original Message ----- 
  From: Martin Rex 
  To: Eric Rescorla 
  Cc: [email-masked] 
  Sent: Thursday, November 26, 2009 1:24 AM
  Subject: Re: [TLS] some questions for your draft

  -Martin

---

From: <[email-masked]>
Date: Thu, 26 Nov 2009 09:35:09 +0100

The current text (in the -00 draft) basically says "identity changes
are OK, but only if the application understands them".

(And by default, the TLS library must assume the application hasn't
probably thought that something like myConn.getPeerCertificates() 
could return a different value each time it's called. And the 
application might have difficulties in figuring out which cert
was used for which application-level message/transaction, since
the TLS library often gives just a byte stream, not a byte stream
where each byte is annotated with the certificate.)

So all the use cases for identity changes you mention would still
be allowed.

Best regards,
Pasi
(not wearing any hats)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Kyle Hamilton
> Sent: 25 November, 2009 21:54
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [TLS] some questions for your draftx
>

---

From: <[email-masked]>
Date: Thu, 26 Nov 2009 09:38:13 +0100

Bruno Harbulot:

> One could imagine a situation where a client would initially present
> a client certificate that contains attributes (like an attribute
> certificate), but that doesn't embed the attributes the server wants
> for this particular request. The server could then initiate a re-
> negotiation to ask the client to present another certificate, with
> other attributes.  This can be particularly useful for role-based
> (or virtual organisation) authorisation, for example.  The concept
> of identity then becomes rather loose; in some contexts, anonymity
> might even be required.
> 
> I don't think that TLS should address this; rather, it should be up
> to the components that verify the certificates.

The current text in -00 allows the use case you describe above.
If the components that verify/use the certificates support identity
changes, that's just fine.

The text just requires that if the component has been written without
considering possible identity changes, the TLS library should not
"surprise" it...

Best regards,
Pasi
(not wearing any hats)

---

From: <[email-masked]>
Date: Thu, 26 Nov 2009 09:40:10 +0100

yangqinqin wrote:

> For identity comparison during renegotiation,TLS may only do
> memcmp() , and more complex identity comparison can be left to
> Specific application to do. There shloud have a alarm message to
> applications and leave applications to choose whether to continue
> re-negotiation.

This is essentially what the text in the -00 draft says: if the
application chooses to continue, it can do so.

Best regards,
Pasi
(not wearing any hats)

---

From: David-Sarah Hopwood <[email-masked]>
Date: Thu, 26 Nov 2009 18:39:30 +0000

[email-masked] wrote:
> could return a different value each time it's called.

Exactly. Unless the TLS library interface uses a callback style
where the app has to confirm the new certificate before any data
is received/sent on the new session, there's no possible way for
the application to get this right. For other kinds of interface,
the only secure option is for the library to do a byte-for-byte
comparison of the cert. If this breaks some use cases -- tough.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

---

From: Marsh Ray <[email-masked]>
Date: Thu, 26 Nov 2009 13:57:01 -0600

David-Sarah Hopwood wrote:
> is received/sent on the new session,

All the ones that I've looked at provide exactly that, though it's not
perfect either.

> there's no possible way for
> the application to get this right.

And I have yet to see any developer-oriented documentation provide
example code that does everything right.

> For other kinds of interface,
> comparison of the cert.

A simpler alternative is to RECOMMEND that library implementations
default to disallowing renegotiation but allow a config option if the
app wants to enable it (perhaps requiring a callback be overridden). The
return value of the callback should be able to immediately terminate the
handshake and discard buffered data on failure.

> If this breaks some use cases -- tough.

Easy for you to say, easy for others to ignore.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Thu, 26 Nov 2009 21:15:30 +0100 (MET)

> All the ones that I've looked at provide exactly that, though it's not

OpenSSL offers a callback, but an app is _not_ required to
register a callback.  It can easily use 
SSL_get_peer_certificate() or SSL_get_peer_cert_chain().
after SSL_connect() completes successfully.

> example code that does everything right.

It's worse than that.  There has been no possible way for
a TLS implementation to get this right!

When would be the correct time to fire such a callback?

Try to describe it in terms of before/while/after which Handshake
message any why.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Thu, 26 Nov 2009 14:53:48 -0600

> a TLS implementation to get this right!

In the liberal spec-interpretation general case, yes.

> When would be the correct time to fire such a callback?

1. Many applications could run with a default of disabling renegotiation
entirely. You could possibly live without a callback in many of those cases.

2. The implementation could refuse data between hello and finished and
provide callbacks on cert verify and finished.

3. Otherwise, a callback on just about every handshake message would be
needed, and the subtleties of application data, alerts, and handshake
messages would all be pushed off onto the application.

> Try to describe it in terms of before/while/after which Handshake

1. Disable all renegotiation.
or
2. Consult your application-level protocol documentation which will
perfectly spell out the allowed sequence of TLS messages. :-)

- Marsh

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 26 Nov 2009 20:40:59 -0800

On 2009-11-26 12:15 PST, Martin Rex wrote:
>> All the ones that I've looked at provide exactly that, 

NSS certainly does, also.

>> though it's not perfect either.
>

NSS provides a callback.  If the app does not register its own callback
function, then NSS provides its own default callback which verifies the
cert chain against the user's preconfigured set of trust anchors, doing
OCSP checking (if configured to do so), then finally checking that the
cert bears a DNS name or pattern that matches the name previously registered
by the application.  Whether the callback is the default one
or an application supplied one, if it returns a failure result, that is
fatal to that handshake.  The handshake will not complete, and no
application data will ever travel on the session that would have been
established if that handshake had completed.

>>> there's no possible way for the application to get this right.

With NSS, the only way for an application to get it wrong is to deliberately
return a false success response to the callback without
checking the cert.  Sadly, I have seen apps do just that. :(

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 27 Nov 2009 23:36:44 +0100

On Nov 25, 2009, at 9:02 PM, <[email-masked]> <[email-masked] 
 > wrote:

> endpoints (either of whom could be potentially malicious).

Why do you think so?

If an RI-secured renegotiation shows a new certificate, this confirms  
that the same party is using those two certificates.  How could an  
additional (potentially malicious) party join the conversation?

Bodo

---

From: Marsh Ray <[email-masked]>
Date: Sun, 29 Nov 2009 18:20:24 -0600

Bodo Moeller wrote:
> On Nov 25, 2009, at 9:02 PM, <[email-masked]>
> <[email-masked]> wrote:
> 

I've been wondering that, too. What exactly is this defending against?

What is a (properly-authenticated) "malicious endpoint", and how could a
wire protocol defend against one?

- Marsh