Multiple TGT's to the same principal.

[Douglas E. Engert]

Rogerio Ferreira da Cunha wrote:
> On Nov 20, 12:05 pm, John Hascall <j... at iastate.edu> 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 at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 
> 

-- 

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