Multiple TGT's to the same principal.

[Rogerio Ferreira da Cunha]

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).

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.