Subject: Re: [TLS] Summarizing identity change discussion so far

From: "Blumenthal, Uri - 0662 - MITLL" <[email-masked]>
Date: Thu, 17 Dec 2009 19:50:34 -0500

I'm jumping in late (what would you expect from somebody on vacation :-), but most of what I may want to say is already eloquently put by Kyle. 

I agree with him points - including (and especially!) those made about WG defining & hard-coding inflexible policies (stated in subsequent postings).

----- Original Message -----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Sent: Thu Dec 17 16:37:15 2009
Subject: Re: [TLS] Summarizing identity change discussion so far

On Tue, Dec 8, 2009 at 1:13 AM,  <[email-masked]> wrote:
> (wearing Area Director hat)
>
> - We recommend that TLS libraries SHOULD provide identity matching
> (with memcmp, abort handshake if changed) functionality to
> applications, and SHOULD allow applications to enable/disable this
> functionality.

No, identity matching SHOULD be done in accordance with PKIX.  memcmp
is not at all sufficient.

However, I would support the following:

- TLS libraries SHOULD provide identity matching services between and
throughout renegotiation handshakes.  Libraries SHOULD implement this
in accordance with PKIX [PKIX], but MAY do so with a direct memory
comparison.  Implementors are cautioned that this latter approach does
not provide for changing the cipher parameters -- such as a
renegotiation with an EC or DH certificate after identification with
an RSA certificate.  If the identity matching service fails to match
the identity, implementations MUST abort the handshake with a fatal
bad_certificate alert.

-Kyle H
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Kyle Hamilton <[email-masked]>
Date: Thu, 17 Dec 2009 17:15:30 -0800

I'll just state this: I believe that defining the semantics of
identity credentials provided during the course of the TLS protocol's
execution is NOT within the legitimate realm of the design of the TLS
protocol.  TLS explicitly references PKIX, and PKIX is really the only
place that uses 'identity', but (on further reading) it doesn't
describe precisely what 'identity' is.

So, I'll take a stab at a potential guidance for those who don't have
the time to research in-depth, taking into account Pasi's and
everyone's ideas: If there is a match between ANY one of the new
certificate's Subject/sAN and the old certificate's Subject/sAN,
including all path components in the same order for that entity, AND
is issued by the same authority, it SHOULD be regarded as being the
same identity, though exceptions will undoubtedly exist.  Differences
in the Certificate Policy, kU, or eKU fields SHOULD be evaluated as
well, to ensure that the new certificate is valid for the kind of
connection and transactions being performed.

The only thing that SHOULD modify the default behavior (defined as
"all 'MUST*' and 'SHOULD*' but no 'MAY*'") is the implementation of a
security policy.  If such a security policy exists but has no
information on this topic, the defaults SHOULD control (unless there's
a very, very good reason not to).

-Kyle H

---

From: Martin Rex <[email-masked]>
Date: Fri, 18 Dec 2009 02:31:12 +0100 (MET)

> connection and transactions being performed.

*I* would really prefer that a TLS spec does _NOT_ open that can of worms
called X.509 Certificate at all.

You don't know how many trust anchors there are (some software comes
preloaded with more than one hundred) and you don't know how long the
CA hierarchies are and whether those trust anchors all have path
length limits.  If you only look at Subject/sAN, you can be fooled
with certs from different CAs, and if add the issuer of the
end-entity cert, then you can be fooled if your attacker can
obtain a specific intermediate CA cert under some other root, and on and on.

I also see absolutely no reason to duplicate code and functionality
here that may get out of sync all too easily.

The application was able to perform the initial authentication
(log-on or ACL-check), so it is the duty of the application to
perform any reauthentication in the very same fashion when
renegotiation results in a different cert(chain).  Everything
else will result in endless pain.

...and that is a reason why personally, I prefer that the necessity
for cert renewal requires a new connection and full initial handshake--
because that is exaclty the code path which has all of the
functionality and checks that we are looking for!

-Martin

---

From: Kyle Hamilton <[email-masked]>
Date: Thu, 17 Dec 2009 17:45:38 -0800

> functionality and checks that we are looking for!

I do agree with you there.  Unless the saved session mechanism also
triggers the functionality and checks that a full handshake would, but
I think that's too much to hope for.

-Kyle H

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 17 Dec 2009 19:58:53 -0700

> connection and transactions being performed.

For an attempt at in-depth guidance about the checking of identities in
certificates presented within application protocols that use TLS, see:

http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-02

I hope to push out -03 in the next week, incorporating feedback received
at IETF 76.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Martin Rex <[email-masked]>
Date: Fri, 18 Dec 2009 20:16:33 +0100 (MET)

Kyle Hamilton wrote:
> > renegotiation results in a different cert(chain). Â Everything

This could be another potential security problem for an application.

If the certficate path validation is only triggered during full
handshakes (because it is somehow chained into the processing
of the Certficate handshake message in a Callback-style),
then a TLS implementation of TLS session resume might skip
the certificate path validation (still providing the original
certificate to the application), and the application might
perform only the mapping (log-on, ACL-check) while assuming that
the certificate path validation was automatically provided
by the TLS implementation.

In theory, TLS sessions get purged from the server-side session
cache at some point in time, so the that the problem could be
temporary.  But depending on how the session cache
expiration is implemented (based on time-of-creation vs.
last-recently-used), there might be a possibility for a client
to "touch" the cached session regularly, so that it will not
be expired from a session cache that operates on last-recently-used,
which may allow the client to skip certificate-path-validation
(which would mean that expiration and revocation might be
 ignored for as long as the client can keep the session in
 the servers session cache).

-Martin