Hi
Thanks for the information ,
Can someone please let me know where can I get the new code if I can download.
thanks
bandi
Steve Langasek wrote:
> On Tue, 18 Sep 2001, SRIDHAR BANDI wrote:
>
> > Thank you so much for the clarification but I have a small doubt in that ,
>
> > When rlogind (for example) is the server who makes as [AS_REQ] to the KDC on
> > behalf of the client (user) then the KDC to issues the [AS_REP] ( without any
> > preauthentication if no preauth are present) that contains the ticket(TGT) and
> > the encrypted data that can be decrypted by clients password, on receiving the
> > [AS-REP] the server (rlogind) will try to decrypt the data that is obtained
> > from the KDC , So the client is said to be authenticated if he knows the
> > password which can decrypt the data in [AS-REP] . Now if the KDC is spoofed
> > then the password of the clients also need to be known to the KDC so that the
> > client's password can be used to decrypt the packet as its at the server
> > (rlogind) end that the decryption takes place. So I still have a doubt that,
> > will the spoofing of KDC be caught by doing verify_krb_v5_tgt() .
> > please help me out .
>
> If the KDC is being spoofed, the danger is that it's being spoofed by the
> person trying to log in to the system. A simple password verification will
> work (the server will be able to decrypt the ticket) because this only
> requires cooperation between the user and the spoofing KDC.
>
> Using that TGT to request a ticket from the KDC will /not/ work, because the
> spoofed `TGT' is not a valid TGT in the realm; the attacker would need to
> compromise the KDC to make this work (and then it's not spoofing anymore). If
> the server requests a ticket for a service principal that is in its
> possession, only a KDC that knows that service principal can generate a proper
> ticket that will be accepted by the verification routine.
>
> If you verify the TGT, the only way you can be spoofed is if one or more
> principals in your Kerberos realm have been compromised. Dealing with
> compromised principals is out of scope for pam_krb5.
>
> > I could think of a problem that is addressed with this is that when both the
> > user and the KDC are spoofed this will work , but even this will fail in the
> > case when the keytab file is not present for the serveras it will ignore the
> > case and allows the user in.
>
> In the current revision of the code, it's considered an error if the PAM
> module cannot find a keytab -- /unless/ you use the 'missing_keytab_ok'
> option.
>
> Regards,
> Steve Langasek
> postmodern programmer
>
> _______________________________________________
>
> Pam-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/pam-list
