[openssl-users] [openssl-dev] Replacing RFC2712 (was Re: Kerberos)

[Jakob Bohm]

On 11/05/2015 20:52, Nico Williams wrote:
> On Mon, May 11, 2015 at 04:42:49PM +0000, Viktor Dukhovni wrote:
>> On Mon, May 11, 2015 at 11:25:33AM -0500, Nico Williams wrote:
>>
>>>   - If you don't want to depend on server certs, use anon-(EC)DH
>>>     ciphersuites.
>>>
>>>     Clients and servers must reject[*] TLS connections using such a
>>>     ciphersuite but not using a GSS-authenticated application protocol.
>> [*] Except when employing unauthenticated encrypted communication
>> to mitigate passive monitoring (oportunistic security).
> As this would be replacing RFC2712, it's not opportunistic to begin with :)
As this would be a new RFC, it might be usable for cases
where RFC2712 was never usable.

How about the following simplifications for the new
extension, lets call  it "GSS-2" (at least in this e-mail).

1. GSS (including SASL/GS2) is always done via the SPNego
GSS mechanism, which provides standard handling of
mechanism negotiation (including round-trip optimizations),
and is already its own standard (complete with workarounds
for historic bugs in the dominant implementation...).

2. The TLS client always begins by sending the first
GSS/SPNego leg in a (new) TLS extension "GSS-2".

3. The TLS server (if it supports and allows the extension)
responds with a 0 byte TLS extension "GSS-2" to confirm
support.

4. The second and subsequent legs of the GSS handshake are
sent as the sole contents of the first encrypted records,
actual application data is not sent until the GSS handshake
succeeds.  Note that the first encrypted server to client
record (containing the second leg) can be sent in the same
protocol round trip as the second half of the TLS
handshake.  It is an open design issue if these TLS records
should be tagged as application records or key exchange
records.

5. In the last legs, the GSS mechanism is told to (mutually
if possible) authenticate some already defined hash of the
TLS handshake, thereby protecting the key exchange.Other
than the round trip saving for the first 2 legs, this is
what distinguishes GSS-2 from simply doing application level
GSS over a TLS connection.  Any GSS negotiated keys are not
used beyond this authentication of the TLS key exchange.

6. If the GSS mechanism preferred by the client requires the
authenticated hash value to be known before sending the
first GSS leg, then the client shall simply abstain from
including that first leg in the first leg SPNego message
if sent in the client hello extension.

7. If the client wants encryption of the first GSS leg, it
can either abstain from including that leg in the first
SPNego GSS leg, or it can send a 0-byte first leg and then
send the real first SPNego leg in the first encrypted client
o server record, with the server responding with the second
leg in the first encrypted server to client record as before
(but no longer in the same round trip as the second half of
the TLS handshake).

8. If the GSS mechanism reports failure, the TLS connection
SHALL be aborted with a specified alert.

9. When the "GSS-2" extension is negotiated, TLS
implementations SHOULD allow anonymous (unauthenticated)
cipher suites even if they would not otherwise do so,
however they MUST be able to combine the "GSS-2" extension
with any and all of the cipher suites and TLS versions they
otherwise implement.  For instance, if an implementation of
the "GSS-2" extension is somehow bolted on to a fully
patched OpenSSL 1.0.0 library (via generic extension
mechanisms), then that combination would support it with
TLS 1.0 only, and TLS 1.3 capable implementations would be
negotiating TLS 1.0 when doing "GSS-2" with such an
implementation.

10. Session resumption and Session renegotiation shall have
the same semantics for the GSS authentication result as
they do for certificate validation results done in the
same handshakes.

11. NPN and ALPN are neither required nor affected by GSS-2
and operate as they would with any other TLS mechanisms,
such as certificates.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150512/d9bfd323/attachment-0001.html>