On 13/05/2015 21:17, Nico Williams wrote:
We're closer.
On Wed, May 13, 2015 at 07:10:10PM +0200, Jakob Bohm wrote:
On 13/05/2015 17:46, Nico Williams wrote:
On Wed, May 13, 2015 at 12:03:33PM +0200, Jakob Bohm wrote:
On 12/05/2015 21:45, Nico Williams wrote:
On Tue, May 12, 2015 at 08:23:34
On 13/05/2015 21:37, Jeffrey Altman wrote:
On 5/13/2015 3:17 PM, Nico Williams wrote:
Kerberos in particular supports PROT_READY. There is no Kerberos IV GSS
mechanism, FYI. I'd never heard of GSS-SRP-6a; do you have a reference?
Nico,
Look for draft-burdis-cat-srp-sasl. It was never standa
On 5/13/2015 3:17 PM, Nico Williams wrote:
> Kerberos in particular supports PROT_READY. There is no Kerberos IV GSS
> mechanism, FYI. I'd never heard of GSS-SRP-6a; do you have a reference?
Nico,
Look for draft-burdis-cat-srp-sasl. It was never standardized but I
believe there is an implement
I wonder if we could do this in the KITTEN WG list. Maybe not every
extension to TLS needs to be treated as a TLS WG work item... We should
ask the security ADs.
Nico
--
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/l
We're closer.
On Wed, May 13, 2015 at 07:10:10PM +0200, Jakob Bohm wrote:
> On 13/05/2015 17:46, Nico Williams wrote:
> >On Wed, May 13, 2015 at 12:03:33PM +0200, Jakob Bohm wrote:
> >>On 12/05/2015 21:45, Nico Williams wrote:
> >>>On Tue, May 12, 2015 at 08:23:34PM +0200, Jakob Bohm wrote:
> >>>
For the TL;DR: My original quick writeup included some
mistakes in the details of TLS (forgot about Finished
messages) and SASL/GS2. It is thus in more than
anticipated need of change before it can become a
proper spec, finding and fixing such mistakes is the
main benefit of having this kind of d
On Wed, May 13, 2015 at 12:03:33PM +0200, Jakob Bohm wrote:
> On 12/05/2015 21:45, Nico Williams wrote:
> >On Tue, May 12, 2015 at 08:23:34PM +0200, Jakob Bohm wrote:
> >>How about the following simplifications for the new
> >>extension, lets call it "GSS-2" (at least in this e-mail).
> >>
> >>1.
On 12/05/2015 21:45, Nico Williams wrote:
On Tue, May 12, 2015 at 08:23:34PM +0200, Jakob Bohm wrote:
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 pr
I should add that I prefer a protocol that optimizes the GSS round trips
over one that doesn't, though that means using SPNEGO for negotiation
(when negotiation is desired).
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/li
On Tue, May 12, 2015 at 08:23:34PM +0200, Jakob Bohm wrote:
> 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
> mecha
On 11/05/2015 20:52, Nico Williams wrote:
On Mon, May 11, 2015 at 04:42:49PM +, 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[*] T
On Mon, May 11, 2015 at 04:42:49PM +, 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
>
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.
[*]
13 matches
Mail list logo
