RFC5077 ticket construction help

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

RFC5077 ticket construction help

OpenSSL - User mailing list

Need some help with RFC5077 ticket construction. I’d like to implement a type of Needham-Schroeder protocol where:

 

  • A wants to talk to B
  • A and B have a relationship with C
  • C constructs an RFC5077 ticket and gives it to A so that A can contact B

 

Are there any good examples of how to do this?

 

The problem I think I’m having the most difficulty with is understanding what I need to put into the encrypted_state portion of the session ticket.

 

Thanks,

Karl

 


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

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

Re: RFC5077 ticket construction help

Viktor Dukhovni


> On Mar 28, 2018, at 12:26 PM, Henderson, Karl via openssl-users <[hidden email]> wrote:
>
> Need some help with RFC5077 ticket construction. I’d like to implement a type of Needham-Schroeder protocol where:
>  
> • A wants to talk to B
> • A and B have a relationship with C
> • C constructs an RFC5077 ticket and gives it to A so that A can contact B
>  
> Are there any good examples of how to do this?
>  
> The problem I think I’m having the most difficulty with is understanding what I need to put into the encrypted_state portion of the session ticket.

It would more sense for C to issue short-term client certificates.
Session tickets are for session resumption.  In particular they
can't authenticate the server to the client, so you still need
an initial handshake for that.

To do GSSAPI with TLS, do TLS on the outside (client authenticates
the server and establishes an secure channel), and then GSSAPI
with channel binding (server authenticates the client as being the
party at the other end of the channel).

--
        Viktor.

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

Re: RFC5077 ticket construction help

OpenSSL - User mailing list
In reply to this post by OpenSSL - User mailing list

 

 

That’s not what TLS tickets are for.  It is for having session state, where the client holds all the state and the server (having only the decryption key) can resume the connection.

 

You might want to look at OAUTH and the “TLS exporter” documents.

 


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

Re: RFC5077 ticket construction help

Michael Sierchio
In reply to this post by OpenSSL - User mailing list

Since there exists a reference implementation, and the source code is available, why not start there?  The symmetric key protocol is the basis of Kerberos.

- M

On Wed, Mar 28, 2018 at 9:26 AM, Henderson, Karl via openssl-users <[hidden email]> wrote:

Need some help with RFC5077 ticket construction. I’d like to implement a type of Needham-Schroeder protocol where:

 

  • A wants to talk to B
  • A and B have a relationship with C
  • C constructs an RFC5077 ticket and gives it to A so that A can contact B

 

Are there any good examples of how to do this?

 

The problem I think I’m having the most difficulty with is understanding what I need to put into the encrypted_state portion of the session ticket.

 

Thanks,

Karl

 


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




--
"Well," Brahma said, "even after ten thousand explanations, a fool is no wiser, but an intelligent person requires only two thousand five hundred."

- The Mahābhārata

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

Re: RFC5077 ticket construction help

Michael Sierchio
In reply to this post by Viktor Dukhovni


On Wed, Mar 28, 2018 at 9:44 AM, Viktor Dukhovni <[hidden email]> wrote:

It would more sense for C to issue short-term client certificates.
Session tickets are for session resumption.  In particular they
can't authenticate the server to the client, so you still need
an initial handshake for that.

To do GSSAPI with TLS, do TLS on the outside (client authenticates
the server and establishes an secure channel), and then GSSAPI
with channel binding (server authenticates the client as being the
party at the other end of the channel).


It would make more sense, but you're changing the problem definition. Needham-Schroeder is intended to be used over an insecure network. 


--
"Well," Brahma said, "even after ten thousand explanations, a fool is no wiser, but an intelligent person requires only two thousand five hundred."

- The Mahābhārata

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

Re: RFC5077 ticket construction help

Viktor Dukhovni


> On Mar 28, 2018, at 12:46 PM, Michael Sierchio <[hidden email]> wrote:
>
> It would make more sense, but you're changing the problem definition. Needham-Schroeder is intended to be used over an insecure network.

I'm guessing that C's purpose is issuance of client credentials.
If the requirement is to avoid PKI, then TLS is not the protocol
one wants to use.  Use GSSAPI, say via libknc:

        https://github.com/elric1/knc/tree/master/lib

--
        Viktor.

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

Re: RFC5077 ticket construction help

OpenSSL - User mailing list
In reply to this post by Michael Sierchio

Ok, but I’d like to use TLS rather than Kerberos. I’m wondering if I could do something like this:

 

  • C sends a Client Hello with 0 length Session Ticket to B.
  • B sends back a NewSessionTicket to C in Server Hello.
  • C sets SSL_CTX_sess_set_new_cb(ctx, new_session_cb) and saves the session blob/ticket in the new_session_cb function indexed by the URL of B.
  • A contacts C with the URL of B
  • C looks up session ticket indexed by URL of B
  • C sends A the session ticket.
  • A contact B and sets the ticket using SSL_set_session_ticket_ext(ssl, ticket, ticket size)

 

Feasible? I’m trying something like this now but I can’t get it working.

 

From: openssl-users <[hidden email]> on behalf of Michael Sierchio <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Wednesday, March 28, 2018 at 12:45 PM
To: "[hidden email]" <[hidden email]>
Subject: [EXTERNAL] Re: [openssl-users] RFC5077 ticket construction help

 

 

Since there exists a reference implementation, and the source code is available, why not start there?  The symmetric key protocol is the basis of Kerberos.

 

- M

 

On Wed, Mar 28, 2018 at 9:26 AM, Henderson, Karl via openssl-users <[hidden email]> wrote:

Need some help with RFC5077 ticket construction. I’d like to implement a type of Needham-Schroeder protocol where:

 

  • A wants to talk to B
  • A and B have a relationship with C
  • C constructs an RFC5077 ticket and gives it to A so that A can contact B

 

Are there any good examples of how to do this?

 

The problem I think I’m having the most difficulty with is understanding what I need to put into the encrypted_state portion of the session ticket.

 

Thanks,

Karl

 


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



 

--

"Well," Brahma said, "even after ten thousand explanations, a fool is no wiser, but an intelligent person requires only two thousand five hundred."


- The Mahābhārata


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

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

Re: RFC5077 ticket construction help

Viktor Dukhovni


> On Mar 28, 2018, at 1:37 PM, Henderson, Karl via openssl-users <[hidden email]> wrote:
>
> Ok, but I’d like to use TLS rather than Kerberos. I’m wondering if I could do something like this:
>  
> • C sends a Client Hello with 0 length Session Ticket to B.
> • B sends back a NewSessionTicket to C in Server Hello.
> • C sets SSL_CTX_sess_set_new_cb(ctx, new_session_cb) and saves the session blob/ticket in the new_session_cb function indexed by the URL of B.
> • A contacts C with the URL of B
> • C looks up session ticket indexed by URL of B
> • C sends A the session ticket.
> • A contact B and sets the ticket using SSL_set_session_ticket_ext(ssl, ticket, ticket size)
>  
> Feasible? I’m trying something like this now but I can’t get it working.

This is essentially what happens in Postfix much of the time between the tlsmgr(8)
process which manages the TLS session cache and the smtp(8) delivery agent which
talks TLS to remote servers, except the initial acquisition of the session is
by a delivery agent that did not find a session to re-use or tried to re-use a
session, but the server did a full handshake anyway...

Which brings us to an important point.  The server might not resume
a session for any number of reasons, and will do a full handshake.
Then what?  Session resumption is an optimization, and the server
can choose to ignore the presented ticket, or might decide it is
too stale, or that the phase of the moon is wrong, and not use it.

Secondly, you need a very secure channel between C and A, as the
serialized session, may allow off-line decryption of subsequent
traffic between A and C, or at least a man-in-the-middle attack.
The master secret for the cached connection is part of that data.

What's wrong with issuing client certs trusted by B?

--
--
        Viktor.

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

Re: RFC5077 ticket construction help

OpenSSL - User mailing list
In this use case, I may want to have yet another client D that wants to talk to B using the same session ticket. This way, B doesn't need to keep a cert per client. This may pose some security risks but at this point, I'm just trying to make it work.

On 3/28/18, 1:50 PM, "Viktor Dukhovni" <[hidden email]> wrote:

    issuing client certs

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

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

Re: RFC5077 ticket construction help

Michael Richardson
In reply to this post by OpenSSL - User mailing list
Henderson, Karl via openssl-users <[hidden email]> wrote:
    > A wants to talk to B
    > A and B have a relationship with C
    > C constructs an RFC5077 ticket and gives it to A so that A can contact B

    > Are there any good examples of how to do this?

Aside Viktor's comment, this is also classic OAUTH2 situation.

But, it sounds like you need to do this below the application layer
in the TLS layer.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [

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