RFC5077 KWK

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC5077 KWK

OpenSSL - User mailing list

Is it possible to use 5077 with a key wrapping key in a Needham-Schroeder scenario:

 

  • A is a Key Server
  • C is say a web server
  • A has a relationship with C and hence A has key KEYac
  • B wants to talk to C but doesn’t have a relationship with C
  • B has a relationship with A
  • B asks A for a key it can use with C
  • A generates a KEYbc and wraps it with KEYac giving us KEYbcac with key_name KEYac

 

Is it possible to construct a 5077 style ticket with KEYbcac that can be transparently unwrapped by C so that B can speak with C using KEYbc? By transparently, I mean without modification to the server C.

 

Thanks,

Karl


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

Re: RFC5077 KWK

Viktor Dukhovni


> On Apr 5, 2018, at 2:02 PM, Henderson, Karl via openssl-users <[hidden email]> wrote:
>
> Is it possible to use 5077 with a key wrapping key in a Needham-Schroeder scenario:
>  
> • A is a Key Server
> • C is say a web server
> • A has a relationship with C and hence A has key KEYac
> • B wants to talk to C but doesn’t have a relationship with C
> • B has a relationship with A
> • B asks A for a key it can use with C
> • A generates a KEYbc and wraps it with KEYac giving us KEYbcac with key_name KEYac
>  
> Is it possible to construct a 5077 style ticket with KEYbcac that can be transparently unwrapped by C so that B can speak with C using KEYbc? By transparently, I mean without modification to the server C.

You can use GSSAPI with Kerberos and TLS channel binding.  RFC5077 defines stateless server session resumption, by moving the server state to the client encrypted in the server's key.  The server key should be short-term, and should not be known to any third party (such as A).

The structure of a server session depends on internal implementation details of the server SSL library, and cannot portably be constructed by some other entity.

TLS 1.3 unifies session tickets with (external) PSKs, perhaps you should recast your approach in terms of PSKs rather than session tickets.

--
        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 KWK

OpenSSL - User mailing list
Thanks,

> TLS 1.3 unifies session tickets with (external) PSKs, perhaps you should recast your approach in terms of PSKs rather than session tickets.

Is there a good implementation example of this?

On 4/5/18, 2:19 PM, "openssl-users on behalf of Viktor Dukhovni" <[hidden email] on behalf of [hidden email]> wrote:

   
   
    > On Apr 5, 2018, at 2:02 PM, Henderson, Karl via openssl-users <[hidden email]> wrote:
    >
    > Is it possible to use 5077 with a key wrapping key in a Needham-Schroeder scenario:
    >  
    > • A is a Key Server
    > • C is say a web server
    > • A has a relationship with C and hence A has key KEYac
    > • B wants to talk to C but doesn’t have a relationship with C
    > • B has a relationship with A
    > • B asks A for a key it can use with C
    > • A generates a KEYbc and wraps it with KEYac giving us KEYbcac with key_name KEYac
    >  
    > Is it possible to construct a 5077 style ticket with KEYbcac that can be transparently unwrapped by C so that B can speak with C using KEYbc? By transparently, I mean without modification to the server C.
   
    You can use GSSAPI with Kerberos and TLS channel binding.  RFC5077 defines stateless server session resumption, by moving the server state to the client encrypted in the server's key.  The server key should be short-term, and should not be known to any third party (such as A).
   
    The structure of a server session depends on internal implementation details of the server SSL library, and cannot portably be constructed by some other entity.
   
    TLS 1.3 unifies session tickets with (external) PSKs, perhaps you should recast your approach in terms of PSKs rather than session tickets.
   
    --
    Viktor.
   
    --
    openssl-users mailing list
    To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
   

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

Re: RFC5077 KWK

Viktor Dukhovni


> On Apr 5, 2018, at 2:29 PM, Henderson, Karl via openssl-users <[hidden email]> wrote:
>
>> TLS 1.3 unifies session tickets with (external) PSKs, perhaps you should recast your approach in terms of PSKs rather than session tickets.
>
> Is there a good implementation example of this?

I think you'd be trailblazing there.  Good luck.

--
        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 KWK

OpenSSL - User mailing list
Thanks

On 4/5/18, 2:35 PM, "openssl-users on behalf of Viktor Dukhovni" <[hidden email] on behalf of [hidden email]> wrote:

   
   
    > On Apr 5, 2018, at 2:29 PM, Henderson, Karl via openssl-users <[hidden email]> wrote:
    >
    >> TLS 1.3 unifies session tickets with (external) PSKs, perhaps you should recast your approach in terms of PSKs rather than session tickets.
    >
    > Is there a good implementation example of this?
   
    I think you'd be trailblazing there.  Good luck.
   
    --
    Viktor.
   
    --
    openssl-users mailing list
    To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
   

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