Subject: RE: [TLS] Review of draft-santesson-tls-gssapi-00

From: Stefan Santesson <[email-masked]>
Date: Thu, 8 Mar 2007 16:30:23 +0000

Eric,

I never got any response on this posting to the list.
I have sent a request to put this on the agenda for Prague.

It would be great if we could continue the discussion so we could get to an agreement on the future of this draft in Prague, or shortly thereafter.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Stefan Santesson
> Sent: den 1 februari 2007 19:09
> To: 'Eric Rescorla'; [email-masked]
> Subject: RE: [TLS] Review of draft-santesson-tls-gssapi-00
>
> Eric,
>
> Thank you for the review and the initiative to get a discussion going
> on this draft.
>
> All of your comments are valid and lines up with what I thought would
> be the critical issues to discuss. In the end it's a question of
> whether these changes to TLS are defendable in relation to the benefit
> to the industry and the usability of the protocol.
>
> Response to your comments 1-3.
>
> 1) TLS gets no guarantee of the quality of parameters given by GSS-API.
> But TLS is no entity so in a way that is the wrong question. The
> implementers of this protocol choose to trust the properties of their
> GSS-API based technology. The solution of this draft enables them to
> extend the trusted authentication methods for TLS sessions to the GSS-
> API methods they already use and trust. This can't accidently degrade
> the security for regular TLS users. But this is nothing new. This line
> was already crossed by RFC 2712.
>
> 2) The extended roundtrips is an un-escapable consequence. If necessary
> I believe we can define an upper boundary of the number of roundtrips.
> You are right that the TLS state machine must rely on GSS-API for
> validating and concluding the GSS-API exchange. Without being handed
> the resulting key material from the GSS-API layer, the TLS state
> machine must fail. I feel convinced that it is possible to define the
> appropriate set of rules for the TLS state machine on when to close the
> connection and fail graciously.
>
> 3) I believe the precedent was set by RFC 2712. Security wise we do
> nothing worse than RFC 2712 already do. This draft do however solve a
> number of problems with RFC 2712. I do not agree that this makes a hole
> in TLS. This feature will not be enabled unless its specifically agreed
> between the parties who thereby make the decision to trust GSS-API to
> provide authentication and keying material.
>
>
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
>
>
> > -----Original Message-----
> > From: Eric Rescorla [mailto:[email-masked]]
> > Sent: den 22 januari 2007 21:20
> > To: [email-masked]
> > Subject: [TLS] Review of draft-santesson-tls-gssapi-00
> >
> > $Id: draft-santesson-tls-gssapi-00-rev.txt,v 1.3 2007/01/22 20:27:34
> > ekr Exp $
> >
> > I have reviewed this document and as I indicated in San Diego, I have
> > serious architectural concerns about the way that it interconnects
> TLS
> > and GSS-API.
> >
> > 1. It's totally unclear what security guarantees TLS is supposed
> > to be getting from GSS. In fact, it's not possible to be clear
> > because there is just some set of mechanism IDs. That may be
> > fine in limited environments but it's not fine in the general case
> > where other extensions might be used with TLS.
> >
> > 2. TLS assumes a fixed number of round trips which is determinable
> > from the resumption state. By contrast, once this draft establishes
> > that GSS is to be used, an arbitrary number of round trips may occur
> > in some way that is invisible to TLS. First, that's a big change to
> > the state machine and second it's architecturally problematic.  It's
> > true that there's an indicator in the message for whether it's the
> > last payload or not, but there's no way for the TLS state machine to
> > independently determine whether that has been tampered with. It needs
> > to rely on the GSS state machine. That's problematic both from an
> > engineering and security standpoint.
> >
> > 3. It sets a precedent that the way to interconnect TLS to external
> > security mechanisms is via creating a hole in TLS to carry their
> > mechanisms. This makes TLS more complicated, which is of course
> > the enemy of security protocols.
> >
> >
> > TLS provides a generic mechanism for linking up to externally
> exchanged
> > keys, courtesy of RFC 4279. All you need to do is arrange for your
> > mechanism to create a PSK-Identity binding on both sides and then
> > you can do an ordinary TLS exchange using TLS PSK.
> >
> > In the WG meeting, I heard concerns from the proponents of this draft
> > that they then needed to arrange a way to carry the GSS handshake and
> > that since their application protocols already had a cutout for TLS
> > they wanted to exploit that cutout. I'm not insensitive to this
> point,
> > but that doesn't make it architecturally sound.
> >
> >
> > -Ekr
> >
> > _______________________________________________
> > TLS mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/tls

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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 08 Mar 2007 09:34:13 -0800

>> was already crossed by RFC 2712.

I don't agree. RFC 2712 had a clear interface to Kerberos, namely
a ticket was in the ClientKeyExchange. I'm not saying that worked,
but it was clear. By contrast this draft just creates a hole
where you can shove arbitrary GSS messages, as evidenced by the
fact that you have to extend the state machine to allow an
arbitrary number of roundtrips.

>> I believe we can define an upper boundary of the number of roundtrips.

Well, any number >2 is a radical change in the TLS state machine.

>> in TLS.

Obviously, we disagree on this point.

>> This feature will not be enabled unless its specifically agreed

It seems to me that this argument could be used to justify any
new cipher suite, no matter how broken. The purpose of having
a TLS WG is to decide whether new extensions are worth doing,
not to punt the decision to users.
   
-Ekr

---

From: Martin Rex <[email-masked]>
Date: Thu, 8 Mar 2007 18:52:02 +0100 (MET)

Stefan Santesson wrote:
> It would be great if we could continue the discussion so we could get
> to an agreement on the future of this draft in Prague, or shortly thereafter.

I do not like the key-exchange in draft-santesson-tls-gssapi-00.txt.

Since the architecture leaves the message protection completely up
to the TLS layer, it should also do this with the key exchange
and _limit_ the GSS-API involvement to (a) authentication and
(b) mixing gss-api provided entropy (if available) with
traditional TLS-provided entropy for the pre-master secret.

IMHO, the key exchange should be either DHE or RSA-encryption,
where the latter will require an RSA-based server certificate,
even if self-signed.

The current proposal comes with too many ifs/restrictions for my taste.

GSS-API does allow authentication-only and no-encryption gssapi
mechanisms and the current proposal precludes their use, and I also
don't think that we should mandate the availability of gss_prf
functionality even for those mechanisms where this optional feature
has recently be specified.

Authentication-only gssapi mechanisms as well as integrity-only
gssapi mechanisms will be unable to provide protection for the
key exchange, which is why I think we should stick completely
to the original SSL/TLS key exchange algorithms.

One idea to mix the gssapi authentication into the key exchange
would be to exchange a strong random string of the same length
as the pre-master secret protected with the gssapi message
protection gss_wrap(conf=true) and XOR it with the
pre-master secret that is protected with the traditional TLS
key exchange algorithm before use.  This extra random protected
by gss_wrap(conf=true) should probably be generated by the server
right after successful context establishment and sent to the client
and should be applied (XOR'ed) by the client _after_ sending the
ClientKeyExchange message and applied by the server after receiving
the ClientKeyExchange message.

The strength of the binding between the GSS-API authentication
and the TLS communication channel will only be as strong as the
gss_api message protection itself (i.e. no binding for authentication-
and integrity-only gss-api mechanisms), but that is probably as good
as it can get.

Limiting the strength of the key exchange of a cipher suite like
TLS_GSS_API_WITH_AES_256_CBC_SHA to a single-DES-based gssapi
authentication seems to be a bad idea.
In contast to that, securely mixing in additional entropy from gssapi
authentication into a regular TLS key exchange shouldn't hurt.

SSL/TLS (in contrast to GSS-API) was invented to provide a broad
level of interoperability _on_the_wire_, while GSS-API was invented
to provide interoperability NOT _on_the_wire_ but at the API level
(as an extreme plug'n'play) between applications and GSS-API mechanisms,
and at the same time being strictly limited to a particular gss-api
mechanism and a single user-management/namespace.

Setting up and using clients and servers with a future TLS-stack
that allows for gss-api based authentication but rejects all
cipher-suites without gss-api authentication (or makes it quite
difficult for the users/admins to enable&configure non-gssapi
ciphersuites), is IMHO heading in the wrong direction.

Initial specs had a strong focus on interoperability (in order to
establish a protected communication channel), ultimately leaving
it up to the application to figure out ways to secure the
authentication process (server-side uses the well-known endpoint
identification, client-side SSL certs are still rare, and obvious
design flaws in installed base (WinHTTP) make it difficult to
migrate to SSL client certs today.

So in the tradition of interoperability, I'd really like to see
a requirement for future TLS implementations with support for
gssapi-based authentication that they must offer alternative
ciphersuites (ciphersuites with traditional server-authentication
based on a Server certificate), and that these must be enabled
by default (and only be disabled if the admin explicitly configures
it that way).  We will have to wiggle out the details.

-Martin

---

From: <[email-masked]>
Date: Fri, 9 Mar 2007 12:49:11 +0200

Eric Rescorla wrote:

> >> 2) The extended roundtrips is an un-escapable consequence.  If
> >> necessary I believe we can define an upper boundary of the number
> >> of roundtrips.
> 

I agree; however, there are several ways to do the roundtrips,
and some of them might be slightly less radical than the one
current proposed in draft-santesson-tls-gssapi-01.

Here's one sketch of how this could work:

   ClientHello
   (ciphersuite TLS_RSA_GSSAPI_WITH_AES128_CBC_SHA, 
   gss_api extension with OID list)
                                -------->
                                                   ServerHello
                             (gss_api extension with OID list)
                                                   Certificate
                                <--------      ServerHelloDone
   ClientKeyExchange 
   (just like in normal RSA ciphersuites)
   ChangeCipherSpec
   Finished                     -------->
                                              ChangeCipherSpec
                                <--------             Finished

Then we'd have the GSSAPI exchange:

   ContentType=GSSAPI 
   ("token", gss token data)    -------->
 
                                            ContentType=GSSAPI
                                <--- ("token", gss token data)
 
            (........ repeat 0..N times ..........)

   ContentType=GSSAPI
   ("complete", 
   gss_wrap(channel binding info)) ----->
                                            ContentType=GSSAPI
                                                  ("complete", 
                               gss_wrap(channel binding info))

   Application Data             <------->     Application Data

Here "channel binding info" would be something similar as in
draft-williams-on-channel-binding-01. Using a different content type
and channel binding would avoid the need to feed stuff from GSS-API 
to TLS record layer/handshake layer/key calculations (which AFAIK 
was one thing Eric objected to in IETF67).

(In addition to TLS_RSA_GSSAPI_WITH_*, we could also have
TLS_DHE_GSSAPI_WITH_* ciphersuites, if we need to support
servers without a certificate.)

Comments? 

Best regards,
Pasi

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 09 Mar 2007 14:25:21 +0100

>    gss_api extension with OID list)

I like this approach better, although I don't understand why you need
special GSSAPI ciphersuites, could you explain?  Wouldn't it be
possible to do this with an extension, to enable the extra roundtrips,
without touching the ciphersuites?

>    gss_wrap(channel binding info)) ----->

Using gss_wrap to wrap additional information, such as channel
bindings, has some similarities with the SASL GS2 mechanism.  Note
that it doesn't seem to work with authentication-only GSS-API
mechanisms that doesn't support GSS_Wrap.

In general, I'm in favor of any protocol that permits GSS-API
negotiation inside TLS but outside of the application data exchange.
The details are less important to me, and I think it should be
possible to come up with a good compromise here.

/Simon

---

From: <[email-masked]>
Date: Fri, 9 Mar 2007 16:03:18 +0200

> without touching the ciphersuites?

I'm not sure if we really need special GSSAPI ciphersuites either...
But at least it would allow the client to say "I want to do
RSA+GSS-API, not plain RSA" in a way that would be correctly
understood by existing servers (that don't do GSS-API).

> mechanisms that doesn't support GSS_Wrap.

Hmm... possibly it should be GSS_GetMIC instead of GSS_Wrap?
Are there any important GSS-API mechanisms that support neither?

Best regards,
Pasi

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 9 Mar 2007 14:30:51 +0000

Eric and Martin,

Thank you for elaborate comments on your positions.

Before getting into detailed discussions on your comments, I would like to figure out the principles of concerns and figure out if there is any common ground we could build this on.

As I understand you have 2 major concerns:

1) That the TLS state Machine has not control over the resulting security of TLS. I.e. if a bad GSS-API mechanism is deployed, it would degrade the security of TLS.
2) That the GSS-API exchange requires more than 1 roundtrip of messages to be completed.

Martin suggested a method for ensuring at least TLS level security. This has also crossed my mind but we decided not to go there initially. But how much concern would go away if we did this in a way where at least TLS security level is achieved?

If the TLS state machine still have control over the security level of the encryption key, would it still be a problem that several roundtrips is required for the GSS exchange?
If so, why is this a problem, except from an emotional purity perspective.

Stefan Santesson
Senior Program Manager

> From: Martin Rex [mailto:[email-masked]]
> Sent: den 8 mars 2007 18:52
> To: Stefan Santesson
> Cc: [email-masked]; [email-masked]
> Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00
>
>
> Stefan Santesson wrote:
> >

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 09 Mar 2007 15:36:44 +0100

> understood by existing servers (that don't do GSS-API).

Ok.  I believe it would be a considerable advantage to avoid requiring
new ciphersuites for GSS-API negotiation.

> Are there any important GSS-API mechanisms that support neither?

I'm working on a HMAC-SHA-256 based GSS-API mechanism that only
supports authentication right now... ;-)

When GSS-API mechanisms are used in protected channels (such as TLS,
possibly using a double-handshake mechanism together with channel
bindings in the authentication) I don't see any cryptographic need for
the authentication mechanism to also provide message security
services.  Designing messages security services is quite complicated,
so if possible I would want to avoid it.

/Simon

---

From: <[email-masked]>
Date: Fri, 9 Mar 2007 16:54:47 +0200

Simon Josefsson wrote:

> Ok.  I believe it would be a considerable advantage to avoid 
> requiring new ciphersuites for GSS-API negotiation.

BTW, I'd be interested to know why, and what you consider
to be the advantages? 

<snip>
> When GSS-API mechanisms are used in protected channels (such as 
> TLS, possibly using a double-handshake mechanism together with 
> channel bindings in the authentication) I don't see any 
> cryptographic need for the authentication mechanism to also 
> provide message security services.  Designing messages security 
> services is quite complicated, so if possible I would want to 
> avoid it.

So would your suggestion be to use the GSS-API channel binding
(in GSS_Init/Accept_sec_context) instead of GSS_GetMIC/GSS_Wrap? 

Is there any danger that this could allow replaying GSS tokens
from a different context where the acceptor ignores the channel 
bindings (see RFC 4121, Section 7)? Or can this be addressed
by some other means?

Best regards,
Pasi

---

From: EKR <[email-masked]>
Date: Fri, 09 Mar 2007 07:22:06 -0800

> If the TLS state machine still have control over the security level of the encryption key, would it still be a problem that several roundtrips is required for the GSS exchange?

Yes.

> If so, why is this a problem, except from an emotional purity perspective.

I'm not sure how to explain it any better than I have already. TLS
has a state machine with a given number of round trips. You're
proposing to change it into a state machine with an *arbitrary*
numbr of round trips determined not inside TLS but rather coupled
with the GSS state machine. That's a radical change and strikes
me as extremely hard to analyze.

-Ekr

---

From: EKR <[email-masked]>
Date: Fri, 09 Mar 2007 07:24:36 -0800

> servers without a certificate.)

So, basically, you're suggesting TLS would provide a content type
for an out-of-band channel that other protocols could use for their
negotiation without it winding up in the app layer? This certainly
seems better than the current proposal.

An alternative proposal that seems even cleaner is to simply
do the GSS first and then couple it to TLS with PSK.

-Ekr

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 9 Mar 2007 15:33:28 +0000

Eric,

I hear what you say. I still wander why that is a problem, more than philosophically.
I said IF, we can take security out of the picture (if we can solve that issue so whatever GSS-API come up with, security is preserved), what is then the problem?

Also provided that there are ways for the state machine to bail out and detect the end of the exchange, then what is the actual problem with that.

To time consuming?
To bandwidth consuming?
To insecure anyway?
just not pretty enough?
Or something else..

It doesn't seem very radical to me to have a protocol design which allows an arbitrary number or roundtrips for a sub process as long as the main process can bail out/timeout gracefully. It wouldn't be the first time in protocol design.

Stefan Santesson
Senior Program Manager

> From: EKR [mailto:[email-masked]]
> Sent: den 9 mars 2007 16:22
> To: Stefan Santesson
> Cc: [email-masked]; [email-masked]
> > If the TLS state machine still have control over the security level
> of the encryption key, would it still be a problem that several
> roundtrips is required for the GSS exchange?
>
> Yes.
>
>

---

From: EKR <[email-masked]>
Date: Fri, 09 Mar 2007 07:56:58 -0800

> I said IF, we can take security out of the picture (if we can solve that issue so whatever GSS-API come up with, security is preserved), what is then the problem?

I've explained this as clearly as I can. Coupling two state machines
is a big deal and needs careful analysis. I haven't seen any.

As for taking security out of the picture, that was your claim not
mine. For me, this state machine issue *is* a security issue and
it's not purely an issue of establishing a key with a sufficiently
strong algorithm.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Fri, 9 Mar 2007 19:52:22 +0100 (MET)

Stefan Santesson wrote:
> 
> Before getting into detailed discussions on your comments,
> I would like to figure out the principles of concerns and
> figure out if there is any common ground we could build this on.
> 
> 1) That the TLS state Machine has not control over the resulting
>    security of TLS. I.e. if a bad GSS-API mechanism is deployed,
>    it would degrade the security of TLS.

Actually, there's one more that hasn't been mentioned yet,
the issue of SSL session caching&resumption,

   - what GSS-API based authentication means for the state
     in the SSL session cache

   - how "leaky" is the abstraction

In case GSS-API authentication is hardwired into TLS (handshake)
in the proposed fashion, I would like to see a requirement that
the application has NO, NONE, ZERO control over the underlying
GSS-API operations, i.e. no access to the credential handles,
and in particular no access to the gssapi context handle.
There should be no attributes&characteristics available to
the application which the SSL/TLS stack does not know about
from an authentication, and the SSL/TLS stack should delete
the security context immediately after context establishment
(or failure) and NOT retain a context handle when it completes
the TLS handshake (so that there is no difference between
full TLS handshake and SSL session resume).

... this might not what Microsoft is looking, and it also
precludes the use of arbitrary authorization extensions.

If the application caller wants to play fancy games with
GSS-API and fiddle around with context handles and authorization
extensions, then we should NOT put GSS-API authentication
into the TLS handshake, but leave it up to the application
(and the application will have to deal with persisting
 context attributes and things like authorization data).

> 
> Martin suggested a method for ensuring at least TLS level security.
> This has also crossed my mind but we decided not to go there initially.
> But how much concern would go away if we did this in a way where at
> least TLS security level is achieved?
> 

I've become accustomed to GSS-API over 12 years, so personally *I*
have less problems with the extra roundtrips than Eric.

In some areas, TLS is IMHO more "mature" and has been more carefully
analyzed and hardened than arbitrary GSS-API mechanisms.  GSS-API
based authentication might still have slight weaknesses that
have been addressed in TLS already (countermeasures against timing
attacks for decryption and padding failures).  I don't think that we can
"fix" those in TLS as long as GSS-API is being used for authentication,
even when the handshake is done outside of TLS, e.g. like at the
app-layer.

In GSS-API, there is no limit on the total number of round-trips
until it is determined whether authentication is successful or
has failed.  Performing the GSS-API handshake within TLS will
undoubtedly increase the number of states in the the TLS state
machine and require several additional transitions.

Setting an upper limit for the number of roundtrips acceptable
within the TLS handshake should be possible, but to be anywhere
near useful, we need at least two full roundtrips for GSS-API,
and to be on the safe side, I'd really like to see 3 full
roundtrips (i.e. two additional round-trips to the regular
TLS handshake).

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 9 Mar 2007 22:14:52 +0100 (MET)

> do the GSS first and then couple it to TLS with PSK.

In general, you really want to do TLS first, and then (GSS-API)
authentication, because there are still a lot of authentication
schemes in use that are "fairly weak" and will benefit when
performing the authentication exchange over an encrypted channel.

It also helps to protect the client identity (from network sniffers)
if the GSS-API authentication is performed within the encrypted
channel.

Thinking about it -- there is a Hen an Egg problem with
my desire to protect the GSS-API token exchange with TLS and the attempt
to XOR entropy from gssapi message protection with pre-master
secret data from TLS key exchange.

So I would prefer moving the GSS-API authentication handshake
after the ChangeCipherSpec exchange and to look into GSS-API
channel bindings to link the gssapi authentication exchange
with the TLS handshake.

Looking at the TLS handshake protocol, when me move the GSS-API token
exchange after the clients ChangeCipherSpec message, it might be
best to move it one message further, i.e. outside of the
TLS handshake.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Sat, 10 Mar 2007 00:27:26 +0100 (MET)

> Here's one sketch of how this could work:
  [nice sketch deleted]
> servers without a certificate.)

After thinking about it for a while and spreading my thought
over a few postings, I have ended up exactly where you were
with this sketch.  :)

-Martin

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 12 Mar 2007 11:07:49 +0100

> BTW, I'd be interested to know why, and what you consider

That's a good question... since this was my gut reaction, I'm not sure
if I can put words on it easily, but I suspect that some of the reason
includes variations of these concerns:

1) Adding an extension for GSS-API works with all ciphersuites, and
makes the use of GSS-API orthogonal to the ciphersuite used.  That
makes it possible to define, e.g., a new public-key algorithm in TLS
and have existing extensions, such as a GSS-API or EAP extensions,
apply to it directly.

2) Let's say we create new ciphersuites for both GSS-API and EAP.
What's saying that someone don't want to use both GSS-API and EAP at
the same time?  Should there be TLS_RSA_WITH_AES128_CBC_SHA_GSSAPI_EAP
ciphersuites?  What about if SASL authentication is also supported?
If GSS-API, EAP, and possibly SASL, were negotiated as a separate (or
possibly the same) TLS extension, this would not be a problem.  At
least if the design of the extension(s) were done properly.

3) Simplify TLS analysis.  If GSS-API or EAP is tightly mixed into the
TLS protocol, e.g. the TLS state machine, it becomes harder to analyse
TLS for correctness.  If we can prove that TLS with the extension
mechanism is secure today, that analysis would hold for TLS + GSS-API
too.

4) Simplify implementations.  At least in GnuTLS, adding a new TLS
extension is simple, and it doesn't have much effect on the core part
of the library.  It thus leads to more easily modularized code.
Adding a new ciphersuite is not as easy to modularize.

> (in GSS_Init/Accept_sec_context) instead of GSS_GetMIC/GSS_Wrap? 

Perhaps.  Some more thinking on this choice may be useful.

One problem with this approach is that if the GSS-API channel binding
negotiation fails, for some reason, the implementation typically
doesn't know that the cause was the failed channel binding.

That was a concern in the SASL GS2 mechanism, where one peer may set a
channel bindings that refer to a security channel that the other end
does not know about.  For example, your MUA might not be aware of a
IPSEC channel, and thus might not be able to set the correct IPSEC
channel binding.  Therefor, we chose to use GSS_Wrap instead of
GSS_Init_sec_context channel binding concept, with a fallback to an
identity function if the GSS-API mechanism did not support GSS_Wrap.

(And yes, the fallback open up for a MITM vulnerability, but other
people in the SASL WG thought this was acceptable, possibly reasoning
that the GSS-API mechanism was already too weak to provide anything
better.  Which may be reasonable, although it leads to complexity.)

I don't think this needs to be a concern for TLS though.  If the
GSS-API channel binding fails, things probably should fail.

> bindings (see RFC 4121, Section 7)? Or can this be addressed

Yes, I think there are such concerns.

Further, I suspect there are GSS-API mechanisms out there that ignore
the channel binding field, but I'll let those with more experience
from non-standard GSS-API mechanism fill in the details here.

Since this is often only a problem with particular GSS-API mechanisms,
one could leave this as a security consideration: 'This TLS GSS-API
extension assumes that the negotiated GSS-API mechanism use the
channel binding data properly, which at least includes that
authentication cannot succeed without both ends supplying the same
channel binding, and that successful replay of the tokens is not
possible.'

/Simon

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 12 Mar 2007 16:14:49 +0000

Eric,

I'm sorry, but I need more information to understand your concern.

> it's not purely an issue of establishing a key with a sufficiently

What other security issue than the strength of the key is there?
TLS does not require any user authentication, so any added technology here can only be positive if the alternative in anonymous.

Regarding key strength, I think all cryptographic experts would agree that:

Good key XOR bad key = good key

At least if they are produced independent of each other, e.g. that the bad key is not actively selected with knowledge of the good key to cancel it or make it bad.
Following this logic, you can safely have another process creating a key of un-known strength and XOR it with the "good" key of TLS, and preserve the security level of TLS.

This simple assumption, makes the security impact very easy to analyze with respect to cryptographic strength.

> is a big deal and needs careful analysis. I haven't seen any.

First I don't see them really as coupled. They are performing independent of each other with respect to the information exchange. So we have one protocol that allows another protocol exchange inside it. That is not very uncommon.

The coupling comes only in terms of some resulting information being handed over to the TLS state machine upon completion of the sub process.
I represent a vendor that is interested to do just this, and see no problem with it.
So yes, it would help a great deal to understand why this is a "big deal". Maybe we missed something, or maybe this isn't that big of a problem

If it would not turn out to be a big deal, we have a significant win here by allowing numerous non-PKI based authentication technologies to be used with TLS. That is a "big deal".

Stefan Santesson
Senior Program Manager

> Sent: den 9 mars 2007 16:57
> To: Stefan Santesson
> > I said IF, we can take security out of the picture (if we can solve
> that issue so whatever GSS-API come up with, security is preserved),
> what is then the problem?
>
> > Also provided that there are ways for the state machine to bail out
> and detect the end of the exchange, then what is the actual problem
> with that.
> >
> > To time consuming?
> > To bandwidth consuming?
> > To insecure anyway?
> > just not pretty enough?
> > Or something else..
> >
> > It doesn't seem very radical to me to have a protocol design which
> allows an arbitrary number or roundtrips for a sub process as long as
> the main process can bail out/timeout gracefully. It wouldn't be the
> first time in protocol design.

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 12 Mar 2007 16:20:49 +0000

Pasi,

Thanks for this interesting proposal.
Let me clarify that I'm personally in no way locked on the current proposal in term of selected architecture.
As long as we can achieve the same goal.

Your proposal is interesting as an alternative that we definitely should consider.

Stefan Santesson
Senior Program Manager

> Sent: den 9 mars 2007 16:25
> To: [email-masked]
> Cc: [email-masked]

---

From: <[email-masked]>
Date: Tue, 20 Mar 2007 15:13:03 +0200

Stefan Santesson wrote:

> TLS does not require any user authentication, so any added 
> technology here can only be positive if the alternative in anonymous.
> 
> At least if they are produced independent of each other, e.g.  that
> the bad key is not actively selected with knowledge of the good key
> to cancel it or make it bad.  Following this logic, you can safely
> have another process creating a key of un-known strength and XOR it
> with the "good" key of TLS, and preserve the security level of TLS.
> 
> This simple assumption, makes the security impact very easy 
> to analyze with respect to cryptographic strength.

I'm not sure what Eric had in mind here, but I don't think key
strength is the issue here. As we found out with e.g. PEAP and IKEv2,
adding a new layer or round of authentication can *reduce* security 
if the layers/rounds are not coupled together in the right way.
This *is* a big deal!

(I'm referring to the "Man-in-the-Middle in Tunneled Authentication"
paper by Asokan, Niemi and Nyberg; and related work.)

I think Eric's concern was that the proposal would be easier to
analyze if the interaction between current TLS state machine and
GSS-API would be done in some other way that in the current draft.

<snip>
> If it would not turn out to be a big deal, we have a significant win
> here by allowing numerous non-PKI based authentication technologies
> to be used with TLS. That is a "big deal".

No disagreement from me here...

Best regards,
Pasi

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 20 Mar 2007 15:04:18 +0000

The problem is that it is very hard to engage into a discussion unless the objections are substantiated.

Considering the original proposal there is 1 isolated event (the GSS exchange) that hands a very specific piece of information to a standard TLS initialization process.
This happens to be input to key derivation.

   5. Key Derivation

      After successful completion of the gss_token messages, the client and
      server each obtain 46 bytes of key random data using the GSS-API PRF.
      This data is the TLS pre-master secret.

Therefore it is hard to understand what other security concerns there could be in the context of TLS other than the quality of the resulting key.

Structurally, the problem with your proposal that has been pointed out to me is that many use of TLS requires authentication have to be established before the finished message, or it will be useless. This aspect needs to be analyzed to determined whether completing authentication before the finished message is an absolute requirement for a solution to be meaningful.

As I understand this, the current status of this work is that we have not yet decided to adopt this work item, but that we should explore this issue further to see if we can come up with an acceptable solution. It would be great if you could confirm and elaborate how we will work towards a decision to accept or reject this work.

Stefan Santesson
Senior Program Manager

> From: [email-masked] [mailto:[email-masked]]
> Sent: den 20 mars 2007 14:13
> To: Stefan Santesson
> Cc: [email-masked]

---

From: <[email-masked]>
Date: Tue, 20 Mar 2007 19:00:22 +0200

> unless the objections are substantiated.

I can repeat one specific objection (made by several people already):
*all* current TLS key exchange mechanisms use exactly the same state
machine, i.e. the message exchange shown in Fig. 1 of RFC 2246, while
this proposal doesn't.

This would be quite radical change to TLS. For example, the base 
TLS spec assumes this state machine is always used, so either we 
need to change it to accommodate GSS-API, or the GSS-API document 
has to effectively overrule the base spec in many places.

(I also believe that implementation could be easier if the state
machine is not changed, but that's probably a secondary concern.)

<snip>
> Structurally, the problem with your proposal that has been pointed
> out to me is that many use of TLS requires authentication have to be
> established before the finished message, or it will be useless. This
> aspect needs to be analyzed to determined whether completing
> authentication before the finished message is an absolute
> requirement for a solution to be meaningful.

Could you explain why you think it will be useless?

We certainly have to complete the authentication (including GSS-API)
before we let application data through. In my proposal, that would
happen after the channel binding messages (not immediately after the
finished messages).

> As I understand this, the current status of this work is that 
> we have not yet decided to adopt this work item, but that we 
> should explore this issue further to see if we can come up 
> with an acceptable solution. It would be great if you could 
> confirm and elaborate how we will work towards a decision to 
> accept or reject this work.

Working backwards in time:

To accept this as WG work item, we need to recharter (and the charter
needs to be approved by IESG). Before I and Eric start discussions
about the new charter text with our AD, we would like to have rough WG
consensus that this is a good idea (and we have enough people to
actively work on this, review it, etc.). 

To determine the WG consensus, we will at some point do a straw poll,
at least on the mailing list and possibly at TLS WG meeting as well.

This didn't happen here in Prague, since there was no presentation
about GSS-API. On one hand, I would prefer to do a poll in a meeting
(I find it usually works better); on the other hand, I would also
prefer to have this settled before Chicago. 

Various people (not only Eric :-) have expressed objections to the 
current version of the draft, and some people have proposed changes 
that would make it more acceptable to them.  Before the straw poll, 
I think you should use the opportunity to have more discussion on 
the list, and revise the document (in whatever way you think would 
make the document more acceptable to the WG and help its progress).

(One related comment: the current draft has lot of technical details,
but practically no text about *why* you would want to do this. The
motivation has been explained in various presentations and discussions,
but I think including it in the document itself would be helpful.)

Best regards,
Pasi

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 21 Mar 2007 01:47:00 -0400

The intent of the original proposal was to replace RFC 2712 with a
revised mechanism that would be extensible and permit Kerberos to
be used for mutual authentication bound with an appropriate binding to
the TLS session.  One significant reason for selecting the use of the
GSS-API Kerberos mechanism in place of raw Kerberos is for ease of
implementation on operating systems that do not export raw Kerberos.
(Solaris, Microsoft Windows, among others.) 

The model that I had in mind was SSH gssapi-keyex where the GSS-API
is used to perform mutual authentication and generate key data that
can be used by the encapsulating protocol which in this case would
be TLS.   The GSS-API PRF provides a method of generating key data
that is independent of the negotiated Kerberos session keys.

I am very mindful of the concerns raised by EKR.  Pasi's proposal
looks very much like what was developed for Telnet START-TLS and
AUTH KRB5 binding many years ago except that instead of establishing
an TLS session with an ADH cipher and then binding the TLS finished
messages to a mutual Kerberos 5 authentication at the application
layer, the new ContentType exchange would be performed prior to
the completion of the TLS session establishment.

I believe this approach is workable but I would like to hear how
EKR would propose performing the GSS-API exchange first within
the context of the TLS session establishment.  It is important
that the solution be entirely encompassed within the TLS session
establishment in order for the result to be a transparent replacement
for the existing deployed utilization of RFC 2712.  The goal of
the original proposal was to start TLS, negotiate GSS, and then
bind the result of the GSS exchange to TLS for the completion of
the TLS state machine.  If EKR has a method of accomplishing this
which he would accept, then I would be most eager to consider it.

Thanks.

Jeffrey Altman

---

From: Yoav Nir <[email-masked]>
Date: Wed, 21 Mar 2007 11:22:03 +0200

> machine, i.e. the message exchange shown in Fig. 1 of RFC 2246, while

Agree so far.

> happen after the channel binding messages (not immediately after the

This would change the same state machine which you reference in RFC  
2246. That figure makes it clear that application data immediately  
follows the Finished message. Inserting more handshake messages  
between the Finished message and the application data is just as big  
a change as is inserting them before the Finished message.

Both the GSSAPI draft and the TEE draft add handshake messages before  
the Finished message. To require further authentication or keying  
messages after the Finished message would alter the meaning of the  
Finished message. Maybe we should rename it to AlmostFinished.

I suggest that rather than conducting a straw poll about whether or  
not GSSAPI (or TEE) should become working group items, we first have  
one on whether external authentication should become a working group  
item.  If the answer to that is yes, we can then discuss whether we  
should use the RADIUS namespace, EAP or GSSAPI.

Regards,

Yoav

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 21 Mar 2007 14:36:59 +0000

We have had lots of discussions around GSS-TLS ending in arguments that this would do too many changes to the TLS state machine.

It would be a lot easier to hold that discussion constructively if the TLS state machine was clearly described. A search for the term "state machine" in current TLS 1.2 returns empty. I can't find any other text that would clearly resemble such description.

Would it be possible to add an annex in TLS 1.2 describing the TLS state machine?

It would then be a lot easier to analyze and discuss the impact of any changes caused by various usages of the TLS extensibility mechanisms.

Stefan Santesson
Senior Program Manager

---

From: <[email-masked]>
Date: Wed, 21 Mar 2007 17:07:18 +0200

The state machine is (sort of implicitly) described in these two
figures, copied from RFC 4346:

      ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
      Certificate*
      CertificateVerify*
      [ChangeCipherSpec]
                                               [ChangeCipherSpec]

And the session resumption case:

      ClientHello                   -------->
                                                       ServerHello
                                                [ChangeCipherSpec]
                                    <--------             Finished
      [ChangeCipherSpec]
      Finished                      -------->

I'm not sure if using a state machine description language would
actually help understanding, but it could look something like this
(server's initial state):

  State: WAITING_FOR_CLIENT_HELLO 
  Event: ClientHello received
    process the client hello
    if (didn't work out)
      send alert
      next state: FAILED
    else if (session being resumed)  
      send ServerHello, ChangeCipherSpec, Finished
      next state: WAITING_FOR_CCS
    else
      send ServerHello [Certificate] [ServerKeyExchange] 
         [CertificateRequest] ServerHelloDone
      next state: WAITING_FOR_CERT_OR_CLIENT_KEY_EXCHANGE
  Event: anything else
    maybe send alert
    go to state FAILED

(The TLS implementations I've taken a look at actually have code
that resembles this.)

Best regards,
Pasi 

> From: ext Stefan Santesson [mailto:[email-masked]] 
> Sent: 21 March, 2007 16:37
> To: [email-masked]
> Subject: [TLS] TLS state machine
> 
> We have had lots of discussions around GSS-TLS ending in 
> arguments that this would do too many changes to the TLS 
> state machine.
> 
> It would be a lot easier to hold that discussion 
> constructively if the TLS state machine was clearly 
> described. A search for the term "state machine" in current 
> TLS 1.2 returns empty. I can't find any other text that would 
> clearly resemble such description.
> 
> It would then be a lot easier to analyze and discuss the 
> impact of any changes caused by various usages of the TLS 
> extensibility mechanisms.
> 
> 
> Stefan Santesson
> Senior Program Manager

---

From: <[email-masked]>
Date: Wed, 21 Mar 2007 17:16:57 +0200

> a change as is inserting them before the Finished message.

In my proposal, the GSS-API messages would use a new content type, not
handshake; so the state machine for TLS handshake message processing
would not be changed.

IMHO this is a smaller change (but I admit that judging the size of
these changes is somewhat subjective).

<snip>
> should use the RADIUS namespace, EAP or GSSAPI.

To even consider a straw poll about TEE, you need to present a
plausible plan on how to revise the EAP applicability statement (which
will not happen in TLS WG, but somewhere else) that is acceptable
to the EAP community and SEC ADs.

Best regards,
Pasi

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 21 Mar 2007 16:47:26 +0100

> these changes is somewhat subjective).

I like your proposal better too, since it seems like a good compromise
here, but I believe one of the problems with it is termination: if the
TLS handshake Finished messages doesn't complete a TLS handshake, from
a key-management point of view (which is what some applications wants
from TLS), when should the TLS session terminate?  With your proposal
it finishes after TLS Finished and after GSS_Init/Accept_sec_context
terminates with success.  That's not a generic termination condition
that fits well with how EAP looks at TLS negotiation.

A generic "user authentication" mechanism like the TLS Inner
Application extension, enhanced with support for GSS-API, may be
better.  It would provide a framework to tell applications using TLS
for key-management when the TLS negotiations have finished, instead of
having them wait for TLS Finished and then wait for GSS success.

Anyway, I'd be interested to hear EKR and Stefan's thoughts on your
proposal, and what (if any) disadvantages they believe it have.

/Simon

---

From: Ari Medvinsky <[email-masked]>
Date: Wed, 21 Mar 2007 09:55:48 -0700

Pasi,

I have two objections to the proposal of doing a GSS exchange after the
finished msgs:
1) Numerous existing applications expect to know the identity of the
client upon completion of the handshake (e.g., consider https for
existing web servers, there lots of other examples); your proposal would
require major overhaul to the way apps are secured today with TLS
2) Your proposal still requires the server to have an X509 certificate;
the original proposal does not have this constraint.  There are
scenarios where it is desirable not require server to have an SSL cert.

Ari Medvinsky
Sr. Program Manager
Windows Security

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2007 8:17 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [TLS] Review of draft-santesson-tls-gssapi-00

<snip>

Best regards,
Pasi

---

From: <[email-masked]>
Date: Wed, 21 Mar 2007 19:08:53 +0200

Ari Medvinsky wrote:
> 
> Pasi,
> 
> I have two objections to the proposal of doing a GSS exchange 
> after the finished msgs:
> existing web servers, there lots of other examples); your proposal
> would require major overhaul to the way apps are secured today with
> TLS

I'm not sure if I understand this concern. Certainly a TLS library
doing GSS-API would tell the application "handshake completed"
only after the GSS-API part was also completed?

> 2) Your proposal still requires the server to have an X509
> certificate; the original proposal does not have this constraint.
> There are scenarios where it is desirable not require server to have
> an SSL cert.

I agree that we don't want to require server certs. While the rough 
sketch in my earlier message did " TLS_RSA_GSSAPI_WITH_...", it
would work exactly the same way for "TLS_DH_anon_GSSAPI_WITH...".
So a server cert is not needed.

Best regards,
Pasi

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 21 Mar 2007 18:33:55 +0100

> only after the GSS-API part was also completed?

I'm not convinced of that.  It is useful for TLS library APIs to be
consistent with the TLS protocol.  Your proposal was to add the
GSS-API negotiation after the TLS handshake.

What this means in practice is that, to speak in library-specific API
terms, that applications after calling gnutls_handshake() will have to
call gnutls_gssapi_handshake().  This is similar to what we did for
TLS/IA, after gnutls_handshake() the application calls
gnutls_ia_handshake() to perform the inner handshake.  Only once both
calls have finished successfully will the application be satisfied.

I disagree that this is a serious problem.  Yes, both TLS libraries
and applications must be changed, but they need to be changed to
support this functionality anyway.  The changes inherent in Pasi's
proposal aren't that much bigger than those in Stefan's original
proposal.

/Simon

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 21 Mar 2007 14:05:57 -0400

> GSS-API negotiation after the TLS handshake.
I believe that by negotiating TLS_XXX_GSS_YYY it is implicit that the
TLS library
API must not return until after the GSS handshake has completed. 
Otherwise, what
is the point of adding the new cipher suite designator?

Jeffrey Altman

---

From: <[email-masked]>
Date: Wed, 21 Mar 2007 20:18:39 +0200

> GSS-API negotiation after the TLS handshake.

Well, Stefan's draft is about adding GSS-API based authentication to
TLS; my proposal was simply to rearrange the message order (and adjust
some other details like message types and exactly how the crypto part
works) to make it fit "nicer" with RFC 4346.

Regardless of the message order (and other details), GSS-API 
authentication becomes part of the TLS protocol. But certainly the
exact message order should not have impact on the TLS library APIs.

Best regards,
Pasi

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 21 Mar 2007 18:22:10 +0000

I disagree that the application need to be altered in the original proposal.

It all depends on where TLS obtains its policies and parameters. If that is supplied by separate configuration or policy DB, then the originally proposed handshake can be performed transparent to the application.

Stefan Santesson
Senior Program Manager

> From: Simon Josefsson [mailto:[email-masked]]
> Sent: den 21 mars 2007 18:34
> Cc: Ari Medvinsky; [email-masked]
> Subject: [TLS] Re: Review of draft-santesson-tls-gssapi-00
>

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 21 Mar 2007 18:35:59 +0000

Thank you Pasi,

Considering this being the TLS state machine, the TLS extension mechanism clearly allows a change of the TLS state machine as it allows other handshake messages to be inserted in this flow.

What are the criteria that distinguish a valid change to the TLS state machine from an invalid (unsuitable) one?
Or is this totally subjective?

Stefan Santesson
Senior Program Manager

> Sent: den 21 mars 2007 16:07
> To: Stefan Santesson; [email-masked]
> Subject: RE: [TLS] TLS state machine
>
>

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 Mar 2007 00:09:18 +0100 (MET)

> require major overhaul to the way apps are secured today with TLS

I completely disagree.  If you're doing the abstraction correctly,
it will be transparent for the existing web-servers.

You will need to insert an additional "tls-gss" layer on top of TLS
which does all the GSS-API wizardry, provides the TLS stack with
the necessary tokens for the mech oid negotiation and supplies
the gssapi context level tokens for the context establishment
following the TLS finished exchange.  This tls-gss layer might
persist GSS-API status/context information and  provide access
to things like authorization data.  You really don't want to
go all the way through the TLS layers to frob with gssapi
features and extensions.

Unless a severely broken application looks at the bits-on-the-wire,
it doesn't know and doesn't care where exactly the finished
message goes on the wire.  The App can (and SHOULD) only react to
API return codes tell the application "TLS handshake complete" --
and the tls-gss layer on top of TLS will indicate "finished" when
it is done with the gssapi handshake, which is all what the
web-server above will see and care about.

GSS-API was designed as a token-based protocol that can be inserted
into existing protocol stacks where it fits best.  Since GSS-API
authentication is something that the application cares about
(TLS doesn't and shouldn't care about this), the gss-api
authentication exchange should be layered on top.

> scenarios where it is desirable not require server to have an SSL cert.

Personally, I'd really like to see a requirement for an X.509 server
cert, because this is what will provide interopability with older
TLS clients that don't support this extension.  It should be up
to the application to decide whether it can or wants to provide
alternative authentication methods if GSS-API based authentication
is not available.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 Mar 2007 00:21:47 +0100 (MET)

> scenarios where it is desirable not require server to have an SSL cert.

If at all, the architecture should address GSS-API in general,
not just specific mechanisms favoured by a few.

SSL/TLS has been around for >10 years, so providing web servers with an
X.509 cert is a long solved problem.  The reason why gssapi authentication
is interesting is because it would allow one to authenticate clients/users
based on their existing (non-X.509) credentials in order to provide
Single Sign-On.

Since the installed base does not yet implement a tls-gss extension
(heck, we don't even know what it is going to look like), we ought
to provide a migration path instead of a flag day, so that clients
that are later in supporting tls-gss can still interoperate based
on existing authentication schemes, and ultimately that means
the server ought to provide an X.509 cert for quite some time.

-Martin

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 21 Mar 2007 19:38:40 -0400

> the server ought to provide an X.509 cert for quite some time.
Martin:

There is a small but significant deployed base of RFC 2712 TLS_KRB5
implementations
which need to migrate to something that is non-DES based.   TLS_GSS will
provide that
for them immediately without the need for an X.509 certificate.  They
are not using an
X.509 certificate with TLS_KRB5 ciphers.

A TLS_GSS using Kerberos 5 would be a transparent replacement for these
clients and
servers when both sides support TLS_GSS instead of TLS_KRB5.

Jeffrey Altman
Secure Endpoints Inc.

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 Mar 2007 00:54:36 +0100 (MET)

Stefan Santesson wrote:
> It all depends on where TLS obtains its policies and parameters.
> If that is supplied by separate configuration or policy DB, then the
> originally proposed handshake can be performed transparent to the
> application.

With a clean design, you'll have to alter the application.

A very short-sighted approach might work with some major hacks
in some environments.

Keep in mind that GSS-API abstraction normally means "authentication
of a communication peer", and there is no requirement that this peer
is anyhow related to user accounts of the local OS.

A clean architecture would ultimately allow binary plug-n-play of the
gssapi mechanism with the TLS stack.  And since it is not know in
advance what fancy gssapi extensions the mechanism will have, what
the names will look like and wether or how gssapi state could
be persisted, the TLS stack should NOT sit between the gssapi
mechanism and the application, but underneath the gssapi mechanism.
GSS-API state may include alternative names, authorization data
and that information may be entirely independent (or incompatible)
with the native-OS means to represent such data.

If someone says "In my scenario I could do it transparently",
then he might be thinking with an extremely narrow focus and not
sufficiently general for the architecture of the protocols at hand
(TLS,GSS-API).

Another issue:  TLS session can be cached and can be "forked".
In fact, it is common practice to "fork" TLS sessions frequently.

GSS-API security contexts, on the other hand, can not normally
be duplicated.  And quite a lot of gssapi mechanism require/enforce
a strictly sequential stream of protected messages (which is how
they provide data replay protection).

I really don't want to see the TLS stack being bothered with
persisting state from the GSS-API authentication beyond
a (flat) peer name.

-Martin

---

From: EKR <[email-masked]>
Date: Wed, 21 Mar 2007 23:01:58 -0700

> servers when both sides support TLS_GSS instead of TLS_KRB5.

Sure, but as we're seeing in a number of applications, this doesn't
preclude the use of self-signed certs.

-Ekr

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 22 Mar 2007 02:21:24 -0400

> preclude the use of self-signed certs.
No it doesn't.  However, as I've seen in a number of commercial and open
source products,
the authors don't want to go to the trouble of writing code to generate
certificates as part
of the install so they install the same self-signed certificate and
private key on every system
in the world.  Most users are to naive to know how to replace the
certificate, probably don't
know that they should, and assume that because there is a certificate
there that they are secure.
One of these commercial products and its self-signed certificate was in
use for many years
by a major Medicare system. 

Self-signed certificates have their place but they should not be used as
a bootstrap method
for other authentication technologies.  Too many people make the wrong
assumptions just
based upon their presence.  Please do not insist that they be used as
part of a TLS-GSS
solution.

Jeffrey Altman

---

From: <[email-masked]>
Date: Thu, 22 Mar 2007 10:33:01 +0200

Stefan Santesson wrote:
> 
> Considering this being the TLS state machine, the TLS 
> extension mechanism clearly allows a change of the TLS state 
> machine as it allows other handshake messages to be inserted 
> in this flow.
> 
> What are the criteria that distinguish a valid change to the 
> TLS state machine from an invalid (unsuitable) one?

I wouldn't use words "valid" or "invalid" here; rather, there 
are changes that I'd consider "nicer" (fits better with existing 
pieces of TLS, easier to understand, simpler, etc.) than others.

When there are multiple alternatives to choose from, all of
which essentially work, I'd consider this "niceness" to be
one important criteria for choosing between them. To some 
degree, it is subjective; but it can also be something people
can agree on (and rough WG consensus can be reached).

Best regards,
Pasi

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 Mar 2007 15:06:25 +0100 (MET)

Jeffrey Altman wrote:
> source products, the authors don't want to go to the trouble of
> writing code to generate certificates as part of the install
> so they install the same self-signed certificate and private key
> on every system in the world.

For an administrative UI, the generation of a new keypair should
always be equal or less work than importing an existing keypair.
The problem with vendors/products installing with a static/fixed
keypair from the installation medium is unfortunately real.

One of the reasons for this is likely shortcoming of the PKI toolkit
(broken APIs) and shortcoming of the PKI toolkit documentation
(it lacks examples to create self-signed credentials for common
usage scenarios (e.g. SSL-Server).

>
> Most users are to naive to know how to replace the certificate,
> probably don't know that they should, and assume that because there
> is a certificate there that they are secure.

One can not blame the users/customers for such a problem. 
Those who ship a pre-generated keypair instead freshly generating
one are to blame.

> a bootstrap method for other authentication technologies.

I can not see anything bad about the SSH host key generation
as it is designed one many Unix system today.  If the server is started
without a host key, it simply creates a new keypair on startup.

>
> Too many people make the wrong assumptions just based upon their
> presence.  Please do not insist that they be used as part of a TLS-GSS
> solution.

Please DO!  Up to today TLS interoperability has been great because
pretty much every server had one of the mandatory-to-implement
ciphersuites available for interoperability.

Making it easy or encouraging people to configure future Web-Servers
with TLS_GSSAPI only ciphersuites is equal to dropping
mandatory to implement ciphersuites and traditional strong interoperability
of TLS will be lost forever.

-Martin

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 22 Mar 2007 10:25:59 -0400

> of TLS will be lost forever.
The sites that have deployed RFC 2712 do not have certificates today and
they want to force users to authenticate using there existing Kerberos
infrastructure.  Forcing the deployment of a certificate in order to
deploy TLS_GSS is not going to alter the behavior of the administrators
who insist that only Kerberos mutual authentication be used.

Please remember that mandatory to implement does not mean mandatory to
deploy.    There is nothing preventing the deployment of a server that
supports both TLS_GSS and certificate based ciphers that are used in
most public settings.   Adding complexity to the deployment of TLS_GSS
is not going to alter the deployment policies of the administrators who
use it.

Jeffrey Altman

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 22 Mar 2007 16:11:21 +0100

On Thu, Mar 22, 2007 at 03:48:14PM +0100, Bodo Moeller wrote:

[...]
> This particular concern might be cured by requiring any specific
> GSS-API mechanism to provide to the TLS layer (an upper bound on) the
> number of messages to be exchanged before the GSS-API portion of the
> handshake actually starts.

Oops, the wording I chose here turns out to be ambiguous.  What I
meant is:

This particular concern might be cured by requiring any specific
GSS-API mechanism to provide to the TLS layer, before the GSS-API
portion of the handshake actually starts, (an upper bound on) the
number of messages to be exchanged.

>                             Then you could have the TLS layer do a
> count-down with handshake messages gss_token<n>, gss_token<n-1>, etc.,
> down to gss_token<1> (these count-down numbers being a purely internal
> concept, not appearing on the wire).

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 22 Mar 2007 16:11:21 +0100

[...]

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 22 Mar 2007 15:48:14 +0100

On Wed, Mar 21, 2007 at 06:35:59PM +0000, Stefan Santesson wrote:

> Considering this being the TLS state machine, the TLS extension
> mechanism clearly allows a change of the TLS state machine as it
> allows other handshake messages to be inserted in this flow.
> 
> What are the criteria that distinguish a valid change to the TLS
> state machine from an invalid (unsuitable) one?

I guess this generally is pretty much subjective: changes to the
standard TLS handshake state machine for specific ciphersuites or
extensions presumably would be accepted if there are compelling
arguments supporting these changes.  Here
draft-santesson-tls-gssapi-01.txt has a (potentially curable) problem
because it explains what you would be able to do, but not why and when
you would want to do this.

However, if I understand Eric's criticism correctly, his main
complaint concerning the state machine is not that there *are*
changes; rather, it is that the changes are quite drastic.
The standard TLS handshake state machine has the following simple
properties:

- There is a finite number of states.

- Any given handshake will end (one way or another) after a finite
  number of handshake messages has been exchanged -- i.e., the state
  transition diagram does not have any cycles.

The standard TLS handshake state machine (as well as extended TLS
handshake state machines maintaining similar properties) inherently
bounds the number of rounds and the amount of data exchanged in any
given handshake.  draft-santesson-tls-gssapi-01.txt doesn't do that,
unless considered in conjunction with specific GSS-API mechanisms
enforcing specific bounds.  Even if you are willing to trust that
any specific GSS-API mechanism will guarantee a finite handshake,
draft-santesson-tls-gssapi-01.txt doesn't guarantee upper bounds.

handshake actually starts.  Then you could have the TLS layer do a

Bodo

__________________________	by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis),
	id 0ML2xA-1HUOkb0akO-0000YO; Thu, 22 Mar 2007 15:58:49 +0100
Date: Thu, 22 Mar 2007 15:48:14 +0100
From: Bodo Moeller <[email-masked]>
To: Stefan Santesson <[email-masked]>
Subject: Re: [TLS] TLS state machine
Cc: "[email-masked]" <[email-masked]>

On Wed, Mar 21, 2007 at 06:35:59PM +0000, Stefan Santesson wrote:

> Considering this being the TLS state machine, the TLS extension
> mechanism clearly allows a change of the TLS state machine as it
> allows other handshake messages to be inserted in this flow.
> 
> What are the criteria that distinguish a valid change to the TLS
> state machine from an invalid (unsuitable) one?

I guess this generally is pretty much subjective: changes to the
standard TLS handshake state machine for specific ciphersuites or
extensions presumably would be accepted if there are compelling
arguments supporting these changes.  Here
draft-santesson-tls-gssapi-01.txt has a (potentially curable) problem
because it explains what you would be able to do, but not why and when
you would want to do this.

However, if I understand Eric's criticism correctly, his main
complaint concerning the state machine is not that there *are*
changes; rather, it is that the changes are quite drastic.
The standard TLS handshake state machine has the following simple
properties:

- There is a finite number of states.

- Any given handshake will end (one way or another) after a finite
  number of handshake messages has been exchanged -- i.e., the state
  transition diagram does not have any cycles.

The standard TLS handshake state machine (as well as extended TLS
handshake state machines maintaining similar properties) inherently
bounds the number of rounds and the amount of data exchanged in any
given handshake.  draft-santesson-tls-gssapi-01.txt doesn't do that,
unless considered in conjunction with specific GSS-API mechanisms
enforcing specific bounds.  Even if you are willing to trust that
any specific GSS-API mechanism will guarantee a finite handshake,
draft-santesson-tls-gssapi-01.txt doesn't guarantee upper bounds.

handshake actually starts.  Then you could have the TLS layer do a

Bodo

_____________________
TLS mailing list
[email-masked]

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 Mar 2007 18:47:36 +0100 (MET)

> is not going to alter the deployment policies of the administrators who

Actually, I would appreciate a (new) requirement that a TLS server
MUST posess at least a self-signed credential for one of the
mandatory-to-implement ciphersuites that include server authentication.

Allowing the admin to disable the ciphersuite is OK, but allowing the
implementation to run without any credential for at least one of
the mandatory-to-implement ciphersuites appears to be a bug in the
interoperability concept behind the mandatory to implement ciphersuites.

-Martin

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 22 Mar 2007 14:06:51 -0700

Jeffrey Altman wrote:
> source products, the authors don't want to go to the trouble of writing
> code to generate certificates as part of the install so they install the
> same self-signed certificate and private key on every system in the
> world.  Most users are to naive to know how to replace the certificate,
> probably don't know that they should, and assume that because there is a
> certificate there that they are secure. One of these commercial products
> and its self-signed certificate was in use for many years by a major
> Medicare system.

Because of the proliferation of self-signed server certs in the markets
for certain application protocols, most commercial clients for those
protocols now do NO server cert validity checking, to avoid problems
with those ubiquitous self-signed server certs.  Such is the pernicious
power of self-signed server certs.

> a bootstrap method for other authentication technologies.  Too many
> people make the wrong assumptions just based upon their presence.  

Hear, hear!

> Please do not insist that they be used as part of a TLS-GSS solution.

Please don't even suggest that they be used.

> Jeffrey Altman

/Nelson B

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 23 Mar 2007 12:52:29 +0000

In-line

Stefan Santesson
Senior Program Manager

> Sent: den 22 mars 2007 00:55
> To: Stefan Santesson
> Cc: [email-masked]
> Subject: Re: [TLS] Re: Review of draft-santesson-tls-gssapi-00
>
> Stefan Santesson wrote:
> >

I think this is where we have the principal disagreement. A clean design from an implementation standpoint allow applications to invoke TLS with no alterations to the applications. IN particular when the choice of authentication and encryption method is determined by a separate policy module. Many applications require this simplicity. Its easier to get things right within TLS implementation then to have applications to get this right. It is also much easier to upgrade the TLS implementation than all applications using it.

> is anyhow related to user accounts of the local OS.

This would of course only be requested and invoked where it makes sense. I see no problem with controlling this.

> with the native-OS means to represent such data.

To me, the extnesion mechanism provide a precise and straightforward negotiation mechanism. This option will not be imposed on anyone that does not agree on using the particular GSS-exchange chosen.

> they provide data replay protection).

Accordingly I would not expect a client and server to agree on using GSS-TLS unless it is meaningful and appropriate for the session. As I would not expect a server to accept anon-DH if client authentication is required.

> persisting state from the GSS-API authentication beyond

And I think this problem is important enough to solve. I whish there was an easier way to do it that works transparent to applications. If there is, I'm more than willing to consider it.

/Stefan

---

From: "tom.petch" <[email-masked]>
Date: Fri, 23 Mar 2007 10:56:22 +0100

----- Original Message -----
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 21, 2007 7:35 PM
Subject: RE: [TLS] TLS state machine

Thank you Pasi,

Considering this being the TLS state machine, the TLS extension mechanism
clearly allows a change of the TLS state machine as it allows other handshake
messages to be inserted in this flow.

What are the criteria that distinguish a valid change to the TLS state machine
from an invalid (unsuitable) one?
Or is this totally subjective?

<tp>
Hang on a bit; no way is what Pasi provided a complete state machine.

As EKR has said many times, he regards the number of round trips as a key
component and, although this is not exactly obvious in TLS1.2, it is implicitly
Client->server
  client<-server
Client->server
  client<-server
and whether or not this is embodied in a state machine is a matter of
expression.  The key objection to this proposal I hear is of an increase in,
perhaps an unbounded increase in, the number of such round trips.

Tom Petch

Stefan Santesson
Senior Program Manager