Re: Multiple TGT's to the same principal. - Kerberos

This is a discussion on Re: Multiple TGT's to the same principal. - Kerberos ; > Hi, > > Is it possible to request more than one TGT , if multiple servers > share the same principal and care to don't send requests with the same > timestamp? Typically, servers do not request tickets (including ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Re: Multiple TGT's to the same principal.

  1. Re: Multiple TGT's to the same principal.



    > Hi,
    >
    > Is it possible to request more than one TGT , if multiple servers
    > share the same principal and care to don't send requests with the same
    > timestamp?


    Typically, servers do not request tickets (including TGTs) at all
    unless they are also functioning as a client. Servers keep their
    key in local storage.

    If a client needs to talk to multiple servers that share the same
    principal, then it needs only one TGT (and one service ticket).

    > I'm working to integrate the SIP protocol with Kerberos, as a option
    > for a Key Management Protocol like MIKEY, to provide a "share key by
    > demand".



    John

  2. Re: Multiple TGT's to the same principal.

    On Nov 20, 12:05 pm, John Hascall wrote:
    > > Hi,

    >
    > > Is it possible to request more than one TGT , if multiple servers
    > > share the same principal and care to don't send requests with the same
    > > timestamp?

    >
    > Typically, servers do not request tickets (including TGTs) at all
    > unless they are also functioning as a client. Servers keep their
    > key in local storage.
    >
    > If a client needs to talk to multiple servers that share the same
    > principal, then it needs only one TGT (and one service ticket).
    >
    > > I'm working to integrate the SIP protocol with Kerberos, as a option
    > > for a Key Management Protocol like MIKEY, to provide a "share key by
    > > demand".

    >
    > John


    Hi,

    As I told, I am working on a proposal to provide Kerberos as a Key
    Mgmt Protocol to SIP (*1) clients [RFC 3261], to provide the keys
    needed to protect the media on RTP (SRTP) protocol. It looks a little
    like what KINK does for IPSEC protocol [RFC3961].

    I am focusing on the times when a SIP client sends an INVITE to
    establish calls without be sure where the call will be ended on IP
    network. One classical (there are others) case happens when the call
    is direct to a public switched telephony network (PSTN) number. All
    the proxies along the signaling path could choose the best gateway
    based on call cost, proximity, policies, etc [RFC 3219 explain this].
    So, the RTP (or better the SRTP) will be ended on a previously unknown
    gateway.

    If the user wishes establish a secure media with SRTP (at least on IP
    part off the call), some of standards today will fail, like those on
    RFC380, because they need a PKI or Pre-shared key that doesn't scale
    or even works in this scenario. The SDES [RFC 4568] approach is not
    secure when there multiple domains are involved one a call.
    Off course, the gateway must decrypt the media before forward that to
    PSTN side.

    To face this problem I thought the caller could send its TGT (*2) and
    ask to the callee (the gateway) send back a KRB_AP_REQ, all the way
    back on the cross realm trusted relationship chain (the gateway should
    ask for a TGS on caller's KDC realm first).

    When the callee gets in contact with the caller's KDC, it could for a
    TGS (KRB_TGS_REQ) using the ENC-TKT-IN-SKEY flag. Then, the callee
    sends the AS_AP_REQ using USE-SESSION-KEY flag. Finishing this
    process, both callee and called will have a session key and subkey to
    be used in the SRTP security negotiation.

    It is a kind off reversal key negotiation approach. IMHO, will be
    easer for the callee (the gateway) find the caller in some situations,
    cousin the TGT contains the Realm from caller's KDC. The caller's
    principal can be extracted from the field "From:" presents on SIP
    messages.

    The motivation on the question on last post, is based on the fact that
    caller (the person whom owner a principal) can be registered on
    multiple terminals, as SIP state, so, or the user ask for a TGT with
    proxy enabled or it ask for multiple TGT's as long as it needs. I
    think the second option is easy, because it does not need a mechanism
    to send the TGTs.

    To tell you the whole idea, the integration between SIP, Kerberos is
    just provide a shared key (actually the subkeys) to XOR the keys sent
    on SDES protocol, that otherwise will follow on plain text. It could
    be also used to configure the pre-shared key (PSK) on MIKEY-PSK
    protocol, in a on-demand fashion, improving the weakest characteristic
    of this protocol: keep secret share keys on multi domain environment.


    Excuse-me for the long post, but I wish to share those ideas with
    someone to see if they worth. I would be very happy if you and other
    fellows on this group send some comments.

    I tryng to develop this proposal for my M.Sc. on Comp .Sc. on
    Universidade Federal Fluminense - UFF, in Rio de Janeiro.

    Thanks,

    (*1) I don't know if you have skills on SIP but it is pretty like the
    HTTP protocol and it also inherits some fields from SMTP like To:,
    From:, Subject:. Users on SIP are identified by URI's like emails, so
    the relationship between URI and Principals can be very straight.

    (*2) SIP supports MIME extensions. It could be possible to send the
    KRB_AP_REQ/REP and TGT on SIP message attachments.

  3. Re: Multiple TGT's to the same principal.



    Rogerio Ferreira da Cunha wrote:
    > On Nov 20, 12:05 pm, John Hascall wrote:
    >>> Hi,
    >>> Is it possible to request more than one TGT , if multiple servers
    >>> share the same principal and care to don't send requests with the same
    >>> timestamp?

    >> Typically, servers do not request tickets (including TGTs) at all
    >> unless they are also functioning as a client. Servers keep their
    >> key in local storage.
    >>
    >> If a client needs to talk to multiple servers that share the same
    >> principal, then it needs only one TGT (and one service ticket).
    >>
    >>> I'm working to integrate the SIP protocol with Kerberos, as a option
    >>> for a Key Management Protocol like MIKEY, to provide a "share key by
    >>> demand".

    >> John

    >
    > Hi,
    >
    > As I told, I am working on a proposal to provide Kerberos as a Key
    > Mgmt Protocol to SIP (*1) clients [RFC 3261], to provide the keys
    > needed to protect the media on RTP (SRTP) protocol. It looks a little
    > like what KINK does for IPSEC protocol [RFC3961].
    >
    > I am focusing on the times when a SIP client sends an INVITE to
    > establish calls without be sure where the call will be ended on IP
    > network. One classical (there are others) case happens when the call
    > is direct to a public switched telephony network (PSTN) number. All
    > the proxies along the signaling path could choose the best gateway
    > based on call cost, proximity, policies, etc [RFC 3219 explain this].
    > So, the RTP (or better the SRTP) will be ended on a previously unknown
    > gateway.
    >
    > If the user wishes establish a secure media with SRTP (at least on IP
    > part off the call), some of standards today will fail, like those on
    > RFC380, because they need a PKI or Pre-shared key that doesn't scale
    > or even works in this scenario. The SDES [RFC 4568] approach is not
    > secure when there multiple domains are involved one a call.
    > Off course, the gateway must decrypt the media before forward that to
    > PSTN side.
    >
    > To face this problem I thought the caller could send its TGT (*2) and
    > ask to the callee (the gateway) send back a KRB_AP_REQ, all the way
    > back on the cross realm trusted relationship chain (the gateway should
    > ask for a TGS on caller's KDC realm first).


    How would you send the TGT securely? Usually a TGT can be used to
    impersonate the user, and is not normally sent. When it is "forwarded"
    it is protected by a session key from a service ticket used to authenticate
    to a trusted service. An example is ssh with GSSAPIDelegation yes.
    The TGT is never just sent on its own.

    Rather then looking at Kerberos directly, can you do what you need to do
    using GSSAPI?

    >
    > When the callee gets in contact with the caller's KDC, it could for a
    > TGS (KRB_TGS_REQ) using the ENC-TKT-IN-SKEY flag. Then, the callee
    > sends the AS_AP_REQ using USE-SESSION-KEY flag. Finishing this
    > process, both callee and called will have a session key and subkey to
    > be used in the SRTP security negotiation.
    >
    > It is a kind off reversal key negotiation approach. IMHO, will be
    > easer for the callee (the gateway) find the caller in some situations,
    > cousin the TGT contains the Realm from caller's KDC. The caller's
    > principal can be extracted from the field "From:" presents on SIP
    > messages.
    >
    > The motivation on the question on last post, is based on the fact that
    > caller (the person whom owner a principal) can be registered on
    > multiple terminals, as SIP state, so, or the user ask for a TGT with
    > proxy enabled or it ask for multiple TGT's as long as it needs. I
    > think the second option is easy, because it does not need a mechanism
    > to send the TGTs.
    >
    > To tell you the whole idea, the integration between SIP, Kerberos is
    > just provide a shared key (actually the subkeys) to XOR the keys sent
    > on SDES protocol, that otherwise will follow on plain text. It could
    > be also used to configure the pre-shared key (PSK) on MIKEY-PSK
    > protocol, in a on-demand fashion, improving the weakest characteristic
    > of this protocol: keep secret share keys on multi domain environment.
    >
    >
    > Excuse-me for the long post, but I wish to share those ideas with
    > someone to see if they worth. I would be very happy if you and other
    > fellows on this group send some comments.
    >
    > I tryng to develop this proposal for my M.Sc. on Comp .Sc. on
    > Universidade Federal Fluminense - UFF, in Rio de Janeiro.
    >
    > Thanks,
    >
    > (*1) I don't know if you have skills on SIP but it is pretty like the
    > HTTP protocol and it also inherits some fields from SMTP like To:,
    > From:, Subject:. Users on SIP are identified by URI's like emails, so
    > the relationship between URI and Principals can be very straight.
    >
    > (*2) SIP supports MIME extensions. It could be possible to send the
    > KRB_AP_REQ/REP and TGT on SIP message attachments.
    > ________________________________________________
    > Kerberos mailing list Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos
    >
    >


    --

    Douglas E. Engert
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444

  4. Re: Multiple TGT's to the same principal.

    On 20 nov, 20:25, "Douglas E. Engert" wrote:
    > Rogerio Ferreira da Cunha wrote:
    >
    >
    >
    > > On Nov 20, 12:05 pm, John Hascall wrote:
    > >>> Hi,
    > >>> Is it possible to request more than one TGT , if multiple servers
    > >>> share the same principal and care to don't send requests with the same
    > >>> timestamp?
    > >> Typically, servers do not request tickets (including TGTs) at all
    > >> unless they are also functioning as a client. Servers keep their
    > >> key in local storage.

    >
    > >> If a client needs to talk to multiple servers that share the same
    > >> principal, then it needs only one TGT (and one service ticket).

    >
    > >>> I'm working to integrate the SIP protocol with Kerberos, as a option
    > >>> for a Key Management Protocol like MIKEY, to provide a "share key by
    > >>> demand".
    > >> John

    >
    > > Hi,

    >
    > > As I told, I am working on a proposal to provide Kerberos as a Key
    > > Mgmt Protocol to SIP (*1) clients [RFC 3261], to provide the keys
    > > needed to protect the media on RTP (SRTP) protocol. It looks a little
    > > like what KINK does for IPSEC protocol [RFC3961].

    >
    > > I am focusing on the times when a SIP client sends an INVITE to
    > > establish calls without be sure where the call will be ended on IP
    > > network. One classical (there are others) case happens when the call
    > > is direct to a public switched telephony network (PSTN) number. All
    > > the proxies along the signaling path could choose the best gateway
    > > based on call cost, proximity, policies, etc [RFC 3219 explain this].
    > > So, the RTP (or better the SRTP) will be ended on a previously unknown
    > > gateway.

    >
    > > If the user wishes establish a secure media with SRTP (at least on IP
    > > part off the call), some of standards today will fail, like those on
    > > RFC380, because they need a PKI or Pre-shared key that doesn't scale
    > > or even works in this scenario. The SDES [RFC 4568] approach is not
    > > secure when there multiple domains are involved one a call.
    > > Off course, the gateway must decrypt the media before forward that to
    > > PSTN side.

    >
    > > To face this problem I thought the caller could send its TGT (*2) and
    > > ask to the callee (the gateway) send back a KRB_AP_REQ, all the way
    > > back on the cross realm trusted relationship chain (the gateway should
    > > ask for a TGS on caller's KDC realm first).

    >
    > How would you send the TGT securely? Usually a TGT can be used to
    > impersonate the user, and is not normally sent. When it is "forwarded"
    > it is protected by a session key from a service ticket used to authenticate
    > to a trusted service. An example is ssh with GSSAPIDelegation yes.
    > The TGT is never just sent on its own.
    >
    > Rather then looking at Kerberos directly, can you do what you need to do
    > using GSSAPI?
    >
    >
    >
    >
    >
    > > When the callee gets in contact with the caller's KDC, it could for a
    > > TGS (KRB_TGS_REQ) using the ENC-TKT-IN-SKEY flag. Then, the callee
    > > sends the AS_AP_REQ using USE-SESSION-KEY flag. Finishing this
    > > process, both callee and called will have a session key and subkey to
    > > be used in the SRTP security negotiation.

    >
    > > It is a kind off reversal key negotiation approach. IMHO, will be
    > > easer for the callee (the gateway) find the caller in some situations,
    > > cousin the TGT contains the Realm from caller's KDC. The caller's
    > > principal can be extracted from the field "From:" presents on SIP
    > > messages.

    >
    > > The motivation on the question on last post, is based on the fact that
    > > caller (the person whom owner a principal) can be registered on
    > > multiple terminals, as SIP state, so, or the user ask for a TGT with
    > > proxy enabled or it ask for multiple TGT's as long as it needs. I
    > > think the second option is easy, because it does not need a mechanism
    > > to send the TGTs.

    >
    > > To tell you the whole idea, the integration between SIP, Kerberos is
    > > just provide a shared key (actually the subkeys) to XOR the keys sent
    > > on SDES protocol, that otherwise will follow on plain text. It could
    > > be also used to configure the pre-shared key (PSK) on MIKEY-PSK
    > > protocol, in a on-demand fashion, improving the weakest characteristic
    > > of this protocol: keep secret share keys on multi domain environment.

    >
    > > Excuse-me for the long post, but I wish to share those ideas with
    > > someone to see if they worth. I would be very happy if you and other
    > > fellows on this group send some comments.

    >
    > > I tryng to develop this proposal for my M.Sc. on Comp .Sc. on
    > > Universidade Federal Fluminense - UFF, in Rio de Janeiro.

    >
    > > Thanks,

    >
    > > (*1) I don't know if you have skills on SIP but it is pretty like the
    > > HTTP protocol and it also inherits some fields from SMTP like To:,
    > > From:, Subject:. Users on SIP are identified by URI's like emails, so
    > > the relationship between URI and Principals can be very straight.

    >
    > > (*2) SIP supports MIME extensions. It could be possible to send the
    > > KRB_AP_REQ/REP and TGT on SIP message attachments.
    > > ________________________________________________
    > > Kerberos mailing list Kerbe...@mit.edu
    > >https://mailman.mit.edu/mailman/listinfo/kerberos

    >
    > --
    >
    > Douglas E. Engert
    > Argonne National Laboratory
    > 9700 South Cass Avenue
    > Argonne, Illinois 60439
    > (630) 252-5444


    If you look at RFC4120, section 3.7, page 46, the authors explain how
    to setup a peer to peer authentication (between to clients) when they
    don't have access to the long term key. Some terminals could throw
    away the long term key after they got a TGT from AS. They will keep
    just
    the TGT and the session Key to ask services for a TGS.

    In this scenario, if a client (let's say Alice) wants access a service
    one another client (let's say Bob), in a P2P fashion, Alice should ask
    for a TGS based on Bob's TGT. The TGS will extract the Bob's session
    Key from TGT (because it is protect with TGS's Key) and create a
    special TGS with Bob's session Key.

    To manage this Alice must get the Bob TGT first, to send it attached
    on KRB_TGS_REQ, with the flag ENC-TKT-IN-SKEY enabled. After she
    receives the KRB_TGS_REP, she can send a KRB_AP_REQ to Bob using the
    flag USE-SESSION-KEY enabled. At this time, Bob can open the
    KRB_AP_REQ, looks for the TGS and see the Key created by the TGS, and
    then check it against the authenticator header assembled by Alice.

    The authors go further and say this is a secure process. As long as
    the TGT's session-key of Bob is kept secrete.
    Alice can send the KRB_TGS_REQ with Bob principal, and if it does not
    match with the Princial inside the TGT the KDC will send a KRB_ERROR.

    If someone try to impersonate Bob (let's say Mallory) sending hers
    TGT to Alice, and Alice follows assembling the KRB_TGS_REQ message,
    once
    she include the Name and Realm extracted from Bob INVITE she will
    have a good chance to avoid the attack.

    The RFC 4210, section 3.3.3, says "If the ENC-TKT-IN-SKEY option has
    been specified and an additional ticket has been included in the
    request, it indicates that the client is using user-to-user
    authentication to prove its identity to a server that does not have
    access to a persistent key [...] If the name of the requested server is
    missing from the request, the name of the client in the additional
    ticket will be used. Otherwise, the name of the requested server will
    be compared to the name of the client in the additional ticket. If
    it is different, the request will be rejected."

    Unless Mallory has forged all the SIP message, there is no way to go
    ahead. SIP INVITE are usually authenticated on the providers, and the
    Request-URI is used on the digest.

    I Though if Mallory could impersonate Alice, it's not a Kerberos
    problem, but a SIP problem.
    Someone is making callings with another credential.
    SIP has it's own authentication processes, using Digest and TLS/DTLS.

    I am not suggesting replace the SIP authentication
    process, but a way to share a key between peers, like a "on demand pre-
    shared key".

    Rogerio

+ Reply to Thread