[openssl-dev] Kerberos

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[openssl-dev] Kerberos

Matt Caswell-2
I am considering removing Kerberos support from OpenSSL 1.1.0. There are
a number of problems with the functionality as it stands, and it seems
to me to be a very rarely used feature. I'm interested in hearing any
opinions on this (either for or against).

Thanks in advance for your input,

Matt
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Kerberos

Blumenthal, Uri - 0553 - MITLL
What are the problems?


----- Original Message -----
From: Matt Caswell [mailto:[hidden email]]
Sent: Tuesday, May 05, 2015 04:21 AM
To: [hidden email] <[hidden email]>; [hidden email] <[hidden email]>
Subject: [openssl-dev] Kerberos

I am considering removing Kerberos support from OpenSSL 1.1.0. There are
a number of problems with the functionality as it stands, and it seems
to me to be a very rarely used feature. I'm interested in hearing any
opinions on this (either for or against).

Thanks in advance for your input,

Matt
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Kerberos

Matt Caswell-2


On 05/05/15 13:22, Blumenthal, Uri - 0553 - MITLL wrote:
> What are the problems?

The code as it exists today is not compiled by default. I recently fixed
a set of issues in master that had not been spotted simply because the
code is not regularly compiled and used. One possible solution to that
is to turn it on by default...but I think that is worse since it
unnecessarily increases the attack surface for those that don't use it
(the vast majority). As it turns out the "--with-krb5-include" Configure
option has not been working correctly in 1.0.2 since it was
released...but no-one noticed.

Due to the infrequency with which it is being used in practice this
means that the code is not being kept up to date. There are some
technical issues (including its use of single DES) which mean the
existing solution is not fit-for-purpose. Viktor is probably better
placed to elaborate on those.

Either we should invest in the effort to bring it up to a suitable
standard or we get rid of it. Given that (I believe) very few people are
using it, it seems more sensible to get rid of it. Part of the purpose
of my email was to gauge whether I was right that very few people are
using it.

Matt
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Kerberos

Blumenthal, Uri - 0553 - MITLL
I'm hesitant to remove this capability altogether, but your argument is convincing.
In view of the progress recently made in the quantum computing field, I think it would be nice to strengthen symmetric crypto capabilities (such as Kerberos), but that implies a lot of work (which I'm not volunteering for :).

Between a rock and a hard place. :-)


----- Original Message -----
From: Matt Caswell [mailto:[hidden email]]
Sent: Tuesday, May 05, 2015 08:56 AM
To: [hidden email] <[hidden email]>
Subject: Re: [openssl-dev] Kerberos



On 05/05/15 13:22, Blumenthal, Uri - 0553 - MITLL wrote:
> What are the problems?

The code as it exists today is not compiled by default. I recently fixed
a set of issues in master that had not been spotted simply because the
code is not regularly compiled and used. One possible solution to that
is to turn it on by default...but I think that is worse since it
unnecessarily increases the attack surface for those that don't use it
(the vast majority). As it turns out the "--with-krb5-include" Configure
option has not been working correctly in 1.0.2 since it was
released...but no-one noticed.

Due to the infrequency with which it is being used in practice this
means that the code is not being kept up to date. There are some
technical issues (including its use of single DES) which mean the
existing solution is not fit-for-purpose. Viktor is probably better
placed to elaborate on those.

Either we should invest in the effort to bring it up to a suitable
standard or we get rid of it. Given that (I believe) very few people are
using it, it seems more sensible to get rid of it. Part of the purpose
of my email was to gauge whether I was right that very few people are
using it.

Matt
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Kerberos

Kenneth Robinette
In reply to this post by Matt Caswell-2
Perhaps people use the --with-krb5-flavor=MIT config which is what we do, and we use it
in all the time in 1.0.2.

Ken

InterSoft International, Inc.
Phone: 888-823-1541
Fax: 866-701-1260


From: Matt Caswell <[hidden email]>
To: [hidden email]
Sent: Tuesday, May 5, 2015 7:56 AM
Subject: Re: [openssl-dev] Kerberos



On 05/05/15 13:22, Blumenthal, Uri - 0553 - MITLL wrote:
> What are the problems?

The code as it exists today is not compiled by default. I recently fixed
a set of issues in master that had not been spotted simply because the
code is not regularly compiled and used. One possible solution to that
is to turn it on by default...but I think that is worse since it
unnecessarily increases the attack surface for those that don't use it
(the vast majority). As it turns out the "--with-krb5-include" Configure
option has not been working correctly in 1.0.2 since it was
released...but no-one noticed.

Due to the infrequency with which it is being used in practice this
means that the code is not being kept up to date. There are some
technical issues (including its use of single DES) which mean the
existing solution is not fit-for-purpose. Viktor is probably better
placed to elaborate on those.

Either we should invest in the effort to bring it up to a suitable
standard or we get rid of it. Given that (I believe) very few people are
using it, it seems more sensible to get rid of it. Part of the purpose
of my email was to gauge whether I was right that very few people are
using it.




Matt
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Kerberos

Tomas Mraz-2
On Út, 2015-05-05 at 13:22 +0000, Technical Support wrote:
> Perhaps people use the --with-krb5-flavor=MIT config which is what we do, and we use itin all the time in 1.0.2.
> Ken

>       From: Matt Caswell <[hidden email]>
>  To: [hidden email]
>  Sent: Tuesday, May 5, 2015 7:56 AM
>  Subject: Re: [openssl-dev] Kerberos
>    
>
>
> On 05/05/15 13:22, Blumenthal, Uri - 0553 - MITLL wrote:
> > What are the problems?
>
> The code as it exists today is not compiled by default. I recently fixed
> a set of issues in master that had not been spotted simply because the
> code is not regularly compiled and used. One possible solution to that
> is to turn it on by default...but I think that is worse since it
> unnecessarily increases the attack surface for those that don't use it
> (the vast majority). As it turns out the "--with-krb5-include" Configure
> option has not been working correctly in 1.0.2 since it was
> released...but no-one noticed.
>
> Due to the infrequency with which it is being used in practice this
> means that the code is not being kept up to date. There are some
> technical issues (including its use of single DES) which mean the
> existing solution is not fit-for-purpose. Viktor is probably better
> placed to elaborate on those.

Fedora and Red Hat Enterprise Linux openssl packages have the KRB5
support compiled in. I believe there are some customers that still use
it on older RHEL releases. On the other hand the current set of
supported ciphers does not make it useful for future use anymore so I do
not care much if it is removed from openssl master branch. If you
properly announce that the support will be removed unless anybody
provides patch adding support for current secure KRB5 algorithms, I am
OK with that.

Regards,
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
(You'll never know whether the road is wrong though.)


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Kerberos

Viktor Dukhovni
In reply to this post by Matt Caswell-2
On Tue, May 05, 2015 at 01:56:13PM +0100, Matt Caswell wrote:

> Due to the infrequency with which it is being used in practice this
> means that the code is not being kept up to date. There are some
> technical issues (including its use of single DES) which mean the
> existing solution is not fit-for-purpose. Viktor is probably better
> placed to elaborate on those.

A better way to combine TLS with Kerberos, albeit with extra
round-trips for initial session establishment, is to use anon-DH
(ADH or AECDH) to establish a TLS session, and GSSAPI with
channel-binding for mutual authentication.

If one then stores GSSAPI authentication results along with TLS
session state, resumed connections suffer no extra latency.

GSSAPI has a well-defined API, and does not require extra TLS
ciphersuites,

Direct use of Kerberos makes the TLS library depend on the choice
of Kerberos run-time (MIT vs. Heimdal) complicating package
management.  Also TLS Kerberos ciphersuites are defined only for
obsolete ciphers (DES, 3DES, RC4 and IDEA).  I don't see any
likelihood of more modern KRB5 ciphersuites being added in the
future.

There are also TLS API difficulties, because it is not easy to
configure the server principal name, handle different Kerberos name
types, obtain the client principal name on the server side, ...

There is little point in any case in doing TLS with Kerberos, it
is not widely supported, it makes more sense to use GSSAPI with
wrap/unwrap, or Roland Dowdeswell's libknc, that presents a
Kerberos authenticated stream abstraction much more cleanly
than Kerberos inside TLS.

    https://github.com/elric1/knc

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] [TLS] Update spec to match current practices for certificate chain order

Viktor Dukhovni
In reply to this post by Matt Caswell-2
On Thu, May 07, 2015 at 08:49:21AM +0300, Yoav Nir wrote:

> > I think there was also discussion on this list at some point suggesting
> > changing that "MAY" for omitting the root CA cert to a "SHOULD" or a
> > "MUST". (I think the argument for the latter was to reduce wasted bandwidth)

Sorry, this is incompatible with use of DANE TLSA records when the
ceritificate usage is DANE-TA(2).  See:

    https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-16#section-3.1.2
    https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-5.2

The first of these is currently in IETF LC, the second in DANE WG LC.

> SHOULD is OK, MUST would imply perfect knowledge of how the other side is
> configured.

As you note, there is more than one way to verify certificates,
and the server cannot know exactly which certificates are needed
by the client.  A SHOULD or MUST would be counter-productive.

> The root of trust may or may not be the self-signed certificate.
> But it?s probably always fine to omit the self-signed certificate.

No, not always.

> > Any reason this would be problematic? It'd be a simple change to add
> > for the TLS 1.3 spec that would align things better with real-world usage.
>
> None that I can think of

You won't be able to say that next time. :-)

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] [openssl-users] Kerberos

Viktor Dukhovni
In reply to this post by Matt Caswell-2
On Thu, May 07, 2015 at 08:00:17PM -0400, Nathaniel McCallum wrote:

> There have been some conversations behind Red Hat doors about
> improving the state of Kerberos/TLS in both standards and
> implementations. Could we maybe have a broader conversation about how
> to fix this situation?

To be blunt, if you want better Kerberos support in TLS, the fix
is to expand the TLS WG charter to explore new directions in TLS
Kerberos support.  Given all the current efforts on 1.3, this is
not going to happen for quite some time.

There's nothing that can be done in just OpenSSL, and the right
immediate action is to drop support for the obsolete protocol.

[ FWIW, Nico concurs. ]

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] [openssl-users] Kerberos

Jeffrey Altman-2
On 5/7/2015 8:40 PM, Viktor Dukhovni wrote:

> On Thu, May 07, 2015 at 08:00:17PM -0400, Nathaniel McCallum wrote:
>
>> There have been some conversations behind Red Hat doors about
>> improving the state of Kerberos/TLS in both standards and
>> implementations. Could we maybe have a broader conversation about how
>> to fix this situation?
>
> To be blunt, if you want better Kerberos support in TLS, the fix
> is to expand the TLS WG charter to explore new directions in TLS
> Kerberos support.  Given all the current efforts on 1.3, this is
> not going to happen for quite some time.
>
> There's nothing that can be done in just OpenSSL, and the right
> immediate action is to drop support for the obsolete protocol.
>
> [ FWIW, Nico concurs. ]
As do I and I am one of the individuals that pushed to get RFC 2712
passed the TLS WG and added to OpenSSL back in 1999.

While Viktor is correct that GSS authentication used over TLS with
appropriate channel bindings is a good option, it is not an option for
everyone.  It isn't easy to re-architect protocols that have been
deployed for more than 15 years in production.

There have been several efforts over the years to better integrate GSS
and Kerberos into TLS.  The approach that I prefer is one in which TLS
relies upon GSS authentication to produce a shared secret key that is
used to feed the TLS Pre-Shared Key (PSK) functionality.  However that
went nowhere.  TLS is complicated enough and there were significant
concerns that creating a GSS hole in the protocol would risk broader
security and performance issues.

SSH2 + GSS Key Exchange demonstrates how easy it should be to combine
GSS Kerberos with a security protocol and remove the dependency on key
management.  I have often wondered if the real resistance to adding GSS
to TLS is the negative impact it would have on the bottom lines of
companies that sell server certificates.

Regardless, the inability to improve the support in this area has left
the those organizations that rely upon 2712 with the choice of use
insecure protocols or re-implement the applications.  I do not believe
that any sane OS or application vendor can with a straight face continue
to ship 2712 support.  As such it should be removed from OpenSSL master.

Jeffrey Altman


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] [openssl-users] Kerberos

Matt Caswell-2


On 08/05/15 02:28, Jeffrey Altman wrote:

> Regardless, the inability to improve the support in this area has left
> the those organizations that rely upon 2712 with the choice of use
> insecure protocols or re-implement the applications.  I do not believe
> that any sane OS or application vendor can with a straight face continue
> to ship 2712 support.  As such it should be removed from OpenSSL master.

I plan to start preparing the patches to remove it next week.

Matt

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] [openssl-users] Kerberos

Nathaniel McCallum-5
In reply to this post by Jeffrey Altman-2
On Thu, 2015-05-07 at 21:28 -0400, Jeffrey Altman wrote:

> On 5/7/2015 8:40 PM, Viktor Dukhovni wrote:
> > On Thu, May 07, 2015 at 08:00:17PM -0400, Nathaniel McCallum wrote:
> >
> > > There have been some conversations behind Red Hat doors about
> > > improving the state of Kerberos/TLS in both standards and
> > > implementations. Could we maybe have a broader conversation
> > > about how
> > > to fix this situation?
> >
> > To be blunt, if you want better Kerberos support in TLS, the fix
> > is to expand the TLS WG charter to explore new directions in TLS
> > Kerberos support.  Given all the current efforts on 1.3, this is
> > not going to happen for quite some time.
> >
> > There's nothing that can be done in just OpenSSL, and the right
> > immediate action is to drop support for the obsolete protocol.
> >
> > [ FWIW, Nico concurs. ]
>
> As do I and I am one of the individuals that pushed to get RFC 2712
> passed the TLS WG and added to OpenSSL back in 1999.
>
> While Viktor is correct that GSS authentication used over TLS with
> appropriate channel bindings is a good option, it is not an option
> for
> everyone.  It isn't easy to re-architect protocols that have been
> deployed for more than 15 years in production.
>
> There have been several efforts over the years to better integrate
> GSS
> and Kerberos into TLS.  The approach that I prefer is one in which
> TLS
> relies upon GSS authentication to produce a shared secret key that is
> used to feed the TLS Pre-Shared Key (PSK) functionality.  However
> that
> went nowhere.  TLS is complicated enough and there were significant
> concerns that creating a GSS hole in the protocol would risk broader
> security and performance issues.
>
> SSH2 + GSS Key Exchange demonstrates how easy it should be to combine
> GSS Kerberos with a security protocol and remove the dependency on
> key
> management.  I have often wondered if the real resistance to adding
> GSS
> to TLS is the negative impact it would have on the bottom lines of
> companies that sell server certificates.
>
> Regardless, the inability to improve the support in this area has
> left
> the those organizations that rely upon 2712 with the choice of use
> insecure protocols or re-implement the applications.  I do not
> believe
> that any sane OS or application vendor can with a straight face
> continue
> to ship 2712 support.  As such it should be removed from OpenSSL
> master.

I agree that the current situation is not sustainable. I was only
hoping to start a conversation about how to improve the situation.

For instance, there is this: http://tls-kdh.arpa2.net/

I don't see any reason this couldn't be expanded to do GSSAPI.

But maybe this mailing list isn't the right place for such a
discussion.

Perhaps the right question to ask is how much interest there would be
in improving this situation in the TLS WG and whether or not OpenSSL
would have interest in implementing such a project.

Nathaniel
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] [openssl-users] Kerberos

Jeffrey Altman-2
On 5/8/2015 5:17 PM, Nathaniel McCallum wrote:
>
> I agree that the current situation is not sustainable. I was only
> hoping to start a conversation about how to improve the situation.
>
> For instance, there is this: http://tls-kdh.arpa2.net/
>
> I don't see any reason this couldn't be expanded to do GSSAPI.

I think that TLS-KDH is fundamentally flawed because it is tied to the
Kerberos protocol.  Most operating systems today support Kerberos but
they do not support a stable standard Kerberos API because such a
creature does not exist in the wild.

If we want a TLS implementation to make use of Kerberos authentication
on a broad range of operating systems that we must access Kerberos
through GSS. Only by using GSS can userland TLS implementations hope to
stack on top of the OS provided Kerberos in a portable way.

> But maybe this mailing list isn't the right place for such a
> discussion.
>
> Perhaps the right question to ask is how much interest there would be
> in improving this situation in the TLS WG and whether or not OpenSSL
> would have interest in implementing such a project.

The IETF TLS WG and perhaps the IETF Kitten WG are the appropriate
places to hold discussions.  Or perhaps hold an IETF BOF first to
explore the interest.   The last time I was involved the work product was

 https://tools.ietf.org/html/draft-santesson-tls-gssapi-03

I still believe that is a reasonable approach.

Jeffrey Altman



_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] [openssl-users] Kerberos

Nico Williams
In reply to this post by Nathaniel McCallum-5
On Fri, May 08, 2015 at 05:17:29PM -0400, Nathaniel McCallum wrote:
> I agree that the current situation is not sustainable. I was only
> hoping to start a conversation about how to improve the situation.

RFC2712 uses Authenticator, which is an ASN.1 type quite clearly NOT
intended for use outside RFC1510 because it isn't a PDU.  RFC2712
unnecessarily constructed its own AP-REQ that's different from the
RFC1510 (now 4120) AP-REQ.

This is bad for a variety of reasons, not the least of which are
complicating Kerberos APIs and/or RFC2712 implementations (which might
have to parse out the Authenticator and Ticket from a plain AP-REQ).

I also notice that the EncryptedPreMasterSecret is under-specified (is
it a Kerberos EncryptedData?  who knows?).

RFC2712 could be replaced with a properly-done protocol that uses
Kerberos in the full TLS handshake (i.e., not in session resumption).
This would be the lowest-effort fix.

A generic GSS-in-TLS extension would require much more energy (see
below).

> For instance, there is this: http://tls-kdh.arpa2.net/

Yes, it'd be nice to add PFS to the Kerberos AP exchange, and we just
might get there, but adding Kerberos and/or GSS to TLS is a very
different undertaking.

> I don't see any reason this couldn't be expanded to do GSSAPI.

Well, that's difficult because GSS has arbitrary round trips...

You're not the first to want this, see for example here:

https://tools.ietf.org/html/draft-santesson-tls-gssapi-01
https://tools.ietf.org/html/draft-williams-tls-app-sasl-opt-04

And more if you consider other efforts like False Start and look past
GSS/SASL.  Probably many more than I know of then...

Two main design axis:

1) When does the GSS context token begin, and how is channel binding
done.

 - no GSS mech negotiation, first GSS context token goes in TLS
   ClientHello;

   (channel binding done via MIC tokens or GSS_Pesudorandom() output
   exchanges)

or (e.g., if the client needs to negotiate mechs)

 - TLS ClientHello carries client mechList, server announces a mech in
   its handshake message, first GSS context token goes in second client
   handshake flight with normal channel binding

(Both options could be specified, with clients choosing as desired.)

x

2) How many GSS context tokens can be exchanged and who is responsible
for continuing past the traditional TLS handshake.

 - one round trip only

or

 - arbitrary round trips continued by TLS or by the application

The first order of business is to decide on whether or not to support
multiple round trips (IMO we must; what's the point if not?).

The second is to decide whether or not additional context token round
trips are to be done by the application, both as to how they appear on
the wire and how they appear in the API.

The third is to decide whether GSS mechanism negotiation is supported,
and whether it can be optimized away when it's not needed.

The fourth is to decide whether SASL (with SASL/GS2 to get GSS) isn't
better, since if we're going to spend a pair of flights in negotiation,
we might as well let server-talks-first SASL mechs get a leg up on GSS.
Remember, SASL can do GSS just fine via SASL/GS2 [RFC5801].

> But maybe this mailing list isn't the right place for such a
> discussion.

Well, TLS WG would be the right forum, but they are busy with TLS 1.3.
Some of us could get together elsewhere, probably not here.

> Perhaps the right question to ask is how much interest there would be
> in improving this situation in the TLS WG and whether or not OpenSSL
> would have interest in implementing such a project.

My impression is: none, because TLS WG is too busy at this time, and in
the past it has been very difficult to get the necessary level of
implementor effort.  Past performance is not always a predictor of
future performance.

It would help if GSS had better, less niche mechanisms.  For example: if
Kerberos had PKCROSS (based on DANE, say), that would help.  Or if ABFAB
went viral.  But for now everyone in the TLS world is happy _enough_
with WebPKI for server (should be service, but hey) authentication and
bearer tokens for user authentication.

Part of the problem is that HTTP authentication schemes (whether in HTTP
proper or not) have no real binding to TLS, and HTTP is basically a
routable (and usually routed) protocol anyways, which complicates
everything.  But HTTPS is the main consumer of TLS.  One might think
that adding user authentication options to TLS would be desirable for
HTTP applications, but again, the routing inherent to HTTP means that
routing must pass along user authentication information, but this isn't
always easy.  And HTTP is stateless and so doesn't deal well with
needing continuation of authentication exchanges, so bearer tokens it
basically kinda has to be, so that better mechanisms lose their appeal.

If the main consumer of GSS-in-TLS were to be something other than HTTP,
well, great, but still, HTTPS is the biggest consumer (next is SMTP)...
And it's easier then to think of GSS-in-TLS as optimizing *application*
protocols with TLS by tagging some application data along in handshake
messages -- there have been many proposals like this, and this is by far
the most promising approach for special some applications (e.g., IMAP).
But now we're talking about generic TLS extensions (to be used for GSS)
rather than adding GSS support to TLS, and while that might make it
easier to get this through, it also makes coding applications harder.

I don't mean to sound pessimistic, much less to dissuade you.  Rather, I
want you to know what level of energy it will take to accomplish what
you're after.  Hopefully something does come of this.  I'll be glad to
help.

Nico
--
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] [openssl-users] Kerberos

Nico Williams

I should have mentioned NPN and ALPN too.

A TLS application could use ALPN to negotiate the use of a variant of
the real application protocol, with the variant starting with a
channel-bound GSS context token exchange.

The ALPN approach can optimize the GSS mechanism negotiation, at the
price of a cartesian explosion of {app protocols} x {GSS mechs}.  A
variant based on the same idea could avoid the cartesian explosion.  But
hey, TLS is the land of cartesian explosions; when in Rome...

The ALPN approach would be my preference here.  With TLS libraries
implementing the GSS context exchange, naturally.  The result would be
roughly what you seem to have in mind.

If we ask TLS WG, I strongly suspect that we'll be asked to look at ALPN
first.

I should add that I also would like to see the RFC4121 Kerberos GSS
mechanism gain PFS, independently of TLS gaining GSS.

Nico
--
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Kerberos

John Denker-2
In reply to this post by Matt Caswell-2
On 05/05/2015 01:21 AM, Matt Caswell wrote:

> I am considering removing Kerberos support from OpenSSL 1.1.0. There are
> a number of problems with the functionality as it stands, and it seems
> to me to be a very rarely used feature.

I don't understand what it means to say the
feature "seems" rarely used.  Is there any
actual evidence about the number and/or
importance of uses?

>  I'm interested in hearing any
> opinions on this (either for or against).

Opinions are not a good substitute for actual
evidence.

This thread has revealed that some people on
this list would prefer something else, but
that leaves unanswered (and almost unasked)
the question of whether Kerberos is actually
being used.

Personally I don't use it, but that does not
come close to answering the question.  A few
moments of googling suggest that some people
are using Kerberos in conjunction with openssl.
For example:
  http://linuxsoft.cern.ch/cern/slc61/i386/yum/updates/repoview/krb5-pkinit-openssl.html

> I plan to start preparing the patches to remove it next week.

Why do we think that's worth the trouble?

What evidence is there that removal won't
cause problems?  It's hard to prove a negative,
and the recent discussions on this list don't
even come close.

I don't care about Kerberos directly, but it
seems like a poor use of resources to worry
about Kerberos while more pressing issues are
left unaddressed.

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Kerberos

Viktor Dukhovni
On Fri, May 08, 2015 at 10:57:10PM -0700, John Denker wrote:
>
> I don't understand what it means to say the feature "seems" rarely used.
> Is there any actual evidence about the number and/or importance of uses?

We don't need to ask the original question.  The current Kerberos
support in OpenSSL SHOULD NOT be used, and support SHOULD be removed,
even if there are current users.  They can stay with whatever
version of OpenSSL provides the feature at present, we won't
confiscate the code from them.

> For example:
>
>   http://linuxsoft.cern.ch/cern/slc61/i386/yum/updates/repoview/krb5-pkinit-openssl.html

This is not in fact a use of the Kerberos cipher-suites in TLS.
Rather it is a use of Kerberos in which user passwords are replaced
with PKI smartcards or similar.  It uses OpenSSL's libcrypto for
the PKI bits, but has nothing to do with TLS.

> > I plan to start preparing the patches to remove it next week.
>
> Why do we think that's worth the trouble?

This is unmaintained and largely unused code, whose functionality
is obsolete.
>
> I don't care about Kerberos directly, but it seems like a poor use of
> resources to worry about Kerberos while more pressing issues are left
> unaddressed.

Sorry, removing the code removes the cost of continuing to support
that code (even poorly), and removes any latent security issues in
that code.

Since this code is conditionally compiled, removing it is rather
easy.  Just drop all the "#ifdef ... #endif" code blocks that
support the obsolete Kerberos ciphersuites.

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Kerberos

Douglas E Engert
In reply to this post by John Denker-2


On 5/9/2015 12:57 AM, John Denker wrote:

> On 05/05/2015 01:21 AM, Matt Caswell wrote:
>
>> I am considering removing Kerberos support from OpenSSL 1.1.0. There are
>> a number of problems with the functionality as it stands, and it seems
>> to me to be a very rarely used feature.
>
> I don't understand what it means to say the
> feature "seems" rarely used.  Is there any
> actual evidence about the number and/or
> importance of uses?
>
>>   I'm interested in hearing any
>> opinions on this (either for or against).
>
> Opinions are not a good substitute for actual
> evidence.
>
> This thread has revealed that some people on
> this list would prefer something else, but
> that leaves unanswered (and almost unasked)
> the question of whether Kerberos is actually
> being used.
>
> Personally I don't use it, but that does not
> come close to answering the question.  A few
> moments of googling suggest that some people
> are using Kerberos in conjunction with openssl.
> For example:
>    http://linuxsoft.cern.ch/cern/slc61/i386/yum/updates/repoview/krb5-pkinit-openssl.html

That refers to the use of the OpenSSL crypto libraries to provide PKI functions needed
to support the PKINIT protocols. PKINIT uses PKI for a pre-authentication data element
as part of the Kerberos AS-REQ. PKINIT is used by Windows Active Directory and unix versions
of Kerberos for smart card login to the AD or KDC.

https://tools.ietf.org/html/rfc4556

It has nothing to do with the SSL/TLS protocols using Kerberos.

I too have never used the Kerberos with the SSL protocol. Time marches on,
DES is deprecated and not used in Kerberos, SSL is being replaced by TLS,
and these change have not been reflected in the standards used for the OpenSSL Kerberos code.

I have worked with Jeff ALtman and Nico Williams in IETF working groups and they are the experts in
the use of GSS and Kerberos.

>
>> I plan to start preparing the patches to remove it next week.
>
> Why do we think that's worth the trouble?
>
> What evidence is there that removal won't
> cause problems?  It's hard to prove a negative,
> and the recent discussions on this list don't
> even come close.
>
> I don't care about Kerberos directly, but it
> seems like a poor use of resources to worry
> about Kerberos while more pressing issues are
> left unaddressed.

Misuse of the older Kerberos code in OpenSSL with SSL is not as secure as one might think.
Removing the code might be the best thing that could happen.

>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> .
>

--

  Douglas E. Engert  <[hidden email]>

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Kerberos

John Denker-2
On 05/09/2015 05:21 AM, Douglas E Engert wrote:
>
> Removing the code might be the best thing that could happen.

It "might" be.  That's hardly a ringing endorsement.

> Misuse of the older Kerberos code in OpenSSL with SSL is not as
> secure as one might think.

That's not proof -- that's not even evidence that it
is necessary to remove the code.  More specifically,
it is an awfully high-handed way to inform the users
what we think is "best" for them.

As previously mentioned in a different context, it
is a bedrock principle of sound reasoning and sound
planning that one should
   /Consider all the plausible scenarios./

So let's consider the following scenario:  Rather
than extirpating the code, we could simply add in
a few instances of something like this:

  #error This feature is insecure, obsolete, unsupported, and vehemently deprecated.
  #warning This code will be removed in a future release.

and leave it that way for a couple of Debian release
cycles.  That serves the purpose of communicating
with the users, without being quite so high-handed.

Also it would be good to communicate exactly what is
being deprecated.  All of Kerberos?  Some particular
combination of Kerberos+SSL????

In this scenario, users who wish to communicate a
reply to us can do so, on a non-emergency basis.
They can search for other ways of doing what needs
to be done, on a non-emergency basis.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Kerberos

Viktor Dukhovni
On Sat, May 09, 2015 at 11:45:07AM -0700, John Denker wrote:

> > Misuse of the older Kerberos code in OpenSSL with SSL is not as
> > secure as one might think.
>
> That's not proof -- that's not even evidence that it
> is necessary to remove the code.  More specifically,
> it is an awfully high-handed way to inform the users
> what we think is "best" for them.

Nobody owes you such a proof.

> Also it would be good to communicate exactly what is
> being deprecated.  All of Kerberos?  Some particular
> combination of Kerberos+SSL?

OpenSSL cannot deprecate "all of Kerberos".  Applications that use
Kerberos can continue to do so whether the OpenSSL developers love
it or hate it.  OpenSSL developers can (and should) drop functionality
that depends on Kerberos from the OpenSSL library.  Specifically,
we're proposing to drop support RFC 2712 TLS Kerberos ciphersuites.

I don't know why you're so adamant when you clearly don't know
what's under discussion.  It is best to stop the sub-thread here.

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
12