Surendra Babu A wrote:
Dear Team,
Thanks a lot for the response.
Issue#1. Regarding Hostname in Server Pricipal:
So it is better to use the hostname in the prinicpal.
Yes. As the FQDN is unique, and both the client and server can agree that that
is
the name of the server.
So for Server Authentication, HOst name should be known. Right?
Hopefully. If is in not, then the client has to know the principal name that
the server is using, so it can ask the KDC for a ticket for that service.
The user/client, KDC and service must all agree on how services are named,
so as to avoid attacks where the user is directed to the wrong service
withoutknowing it.
Host names fit this pattern. A KDC admin would/should not add a principal
for host.x.y and give the key to anyone but the admin of the host.x.y
A user may use the command "ssh host.x.y" to establish a session to the host,
The kerberos libs use the host.x.y in the principal. The conection is made and
authenticated in both directions because the names have ben agreed upon in
advance.
Without knowing the Hostname, it is diffifcult to resolve the Server
Authentication. Right?
Yes, but not impossible. If the user client, KDC and server can agree on what
principals
are to be used, then you could get Kerberos to work without host names.
Additionally, Application Server side, should we configure the KDC server IP
address?
That is an implementaiton not a protocol convention. I believe most Kerberos
libs expect
hostnames in the krb5.conf file. Never tried it with an IP address. Using names
can also
allow for multiple IP addresses on a single KDC. But the name of the KDC or
its IP address
are not used in tickets.
I think It is not required. Because we are already sending the Server Pricipal
in TGS-REQ. Right?
If it works, then you can use it.
Conclusion: To enjoy the benefit of Server Authentication of Kerberos, User
should enter the Hostname of Applciation Server. Right?
Yes.
Issue#2: Regarding GSSAPI.
My assumption is, if ESMTP supports Kerberos, then it will give AUTH GSSAPI response for the EHLO command.
If is supports GSSAPI, then forget about using Kerberos and getint tickets ...
and use GSSAPI!
The Kerberos veriosn of GSSPAI does all of that for you.
So I am sending the Servcie Ticket from our esmtp client. Is it right?
Don't know anything about ESMTP or how it uses Kerberos. Sorry.
Let me expalin clearly:
- AS_REQ and AS_REP happend and User Authentication is done successfully.
- TGS_REQ and TGD_REP is happend with Kerberos client and KDC. So Service tkt
is at kdc client side.
- Now we initiated the email operation from Multi Funtion Printer. It
contacted the ESMTP server from ESMTP client.
- Sent the EHLO command. ESMTP Server Gave me the AUTH GSSAPI response. So
Kerberos is supported at server sid. Right??
- After seeing this GSSAPI string, sending the Service ticket to ESMTP server.
If the server is expecting GSSAPI, then the cilent should be use the Client
side of GSSAPI, which is
a generic layer on top Kerberos.
Is it correct? We are assuming that, GSSPAI is supported means, Kerberos is
supported. Is it right?
Maybe. GSSAPI is a generic API for security systems. Kerberos is one of these.
99% of the time
this refers to Kerberos.
Could you please explain about the Application Server transactions??? How to
communicate with GSSAPI?
No. Google for gssapi.
Thank you,
-Surendra
----- Original Message -----
From: "Douglas E. Engert" <[EMAIL PROTECTED]>
To: "Surendra Babu A" <[EMAIL PROTECTED]>
Cc: <[email protected]>
Sent: Wednesday, December 07, 2005 5:11 PM
Subject: Re: Clarifications sought on Kerberos SA: TGS_REQ and Server Auth??
Surendra Babu A wrote:
Hi Kerberos Team,
Could you please let me know your thoughts on the following questions? Thank a
lot in advance,
1. While forming the TGS-REQ pkt, I need to send the Server name with that TGS_REQ packet. For
this reason, I need to use krb5_parse_name(). second Parameter for this API is
a Server Principal.
Should I need to send a qualified Hostname with that?
As long as the server and the client agree on what is in the name, and the
principal
is regstered in the KDC, and the server has a copy of the key, it can work.
Servers usually have a two component name and the realm: <service>/<fqdn of
host>@<realm>
and many of the Kerberos routines assist in making sure the host is converted
to a fqdn.
You could have more components, DCE had some three component names.
You could use IP addresses, but IP addresses don't real identify a host, they
identify an interface. Hosts with multiple interfaces, VPNs, and NAT can
make this dificult. IP numbers change, so the client, server and KDC all need
to be updated. And what will you do about IPV6 addresses in a principal?
Use names if you can, DNS or even names are in pre distributed /etc/hosts
files.
That means, we should know the Host NAme of
the server? Without knowing the HOst Name of the Application Server (i.e. If we
know only IP Address),
can't we form the TGS_REQ packet and get the successful response TGS-REP?? I
tyried with IP Address in
Principal. But it was not successding. COuld you please let me know your
thoughts?
2. For Server Authentication feature: if the Application Server is a Kerberised ESMTP server, how it
should proceed? After sending the Service ticket to ESMTP server, what should
happen? Could you please
let me know the Client and Applciation Server handshake and transfer machanism
till Server Authentication
feature happens?
Rather then using raw Kerberos, can you use gssapi? Gss addresses many of these
issues.
Please let me know your thoughts.
Thank you,
-Surendra
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
