Multiple TGT's to the same principal.

[Rogerio Ferreira da Cunha]

On 20 nov, 20:25, "Douglas E. Engert" <deeng... at anl.gov> wrote:
> 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           Kerbe... at mit.edu
> >https://mailman.mit.edu/mailman/listinfo/kerberos
>
> --
>
>   Douglas E. Engert  <DEEng... at anl.gov>
>   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