Clarifications sought on Kerberos SA: TGS_REQ and Server Auth??

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Clarifications sought on Kerberos SA: TGS_REQ and Server Auth??

Surendra Babu A
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? 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?

Please let me know your thoughts.

Thank you,
-Surendra
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Clarifications sought on Kerberos SA: TGS_REQ and Server Auth??

Douglas E. Engert


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           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Clarifications sought on Kerberos SA: TGS_REQ and Server Auth??

Surendra Babu A
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. So for Server Authentication, HOst name should be known. Right?

Without knowing the Hostname, it is diffifcult to resolve the Server Authentication. Right?

Additionally, Application Server side, should we configure the KDC server IP address? I think It is not required. Because we are alreadys ending the Server Pricipal in TGS-REQ. Right?

Conclusion: To enjoy the benefit of Server Authentication of Kerberos, User should enter the Hostname of Applciation Server. Right?


Issue#2: Regarding GSSAPI.
My assumption is, if ESMTP supports Kerberos, then it will give AUTH GSSAPI response for the EHLO command. So I am sending the Servcie Ticket from our esmtp client. Is it right?

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.

Is it correct? We are assuming that, GSSPAI is supported means, Kerberos is supported. Is it right?

Could you please explain about the Application Server transactions??? How to communicate with GSSAPI?

Thank you,
-Surendra









----- Original Message -----
From: "Douglas E. Engert" <[hidden email]>
To: "Surendra Babu A" <[hidden email]>
Cc: <[hidden email]>
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           [hidden email]
> > https://mailman.mit.edu/mailman/listinfo/kerberos
> >
> >
>
> --
>
>   Douglas E. Engert  <[hidden email]>
>   Argonne National Laboratory
>   9700 South Cass Avenue
>   Argonne, Illinois  60439
>   (630) 252-5444
>
>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Clarifications sought on Kerberos SA: TGS_REQ and Server Auth??

Surendra Babu A
In reply to this post by Douglas E. Engert
 >

> > 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.
>
>
Surendra:

1. If I use GSSAPI, how it can resolve these issues? COuld you please let me know the steps to clarify the same? Any pointers on this is appreciated very well. How Server Authentication happens with GSSAPI? How does Service Ticket transferred?

2. What kind of implamentation should be done at ESMTP client side to handle the Kerberised ESMTP Server response?


> >
> > Please let me know your thoughts.
> >
> > Thank you,
> > -Surendra
> > ________________________________________________
> > Kerberos mailing list           [hidden email]
> > https://mailman.mit.edu/mailman/listinfo/kerberos
> >
> >
>
> --
>
>   Douglas E. Engert  <[hidden email]>
>   Argonne National Laboratory
>   9700 South Cass Avenue
>   Argonne, Illinois  60439
>   (630) 252-5444
>
>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Clarifications sought on Kerberos SA: TGS_REQ and Server Auth??

Douglas E. Engert
In reply to this post by Surendra Babu A


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" <[hidden email]>
> To: "Surendra Babu A" <[hidden email]>
> Cc: <[hidden email]>
> 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           [hidden email]
>>>https://mailman.mit.edu/mailman/listinfo/kerberos
>>>
>>>
>>
>>--
>>
>>  Douglas E. Engert  <[hidden email]>
>>  Argonne National Laboratory
>>  9700 South Cass Avenue
>>  Argonne, Illinois  60439
>>  (630) 252-5444
>>
>>
>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Clarifications sought on Kerberos SA: TGS_REQ and Server Auth??

sandypossible
In reply to this post by Surendra Babu A
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.
>> I believe you need to have TGT before  using GSS API .

- Sandy.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Clarifications sought on Kerberos SA: TGS_REQ and Server Auth??

Donn Cave
In reply to this post by Surendra Babu A
In article <001101c5fb2a$76d25060$[hidden email]>,
 [hidden email] (Surendra Babu A) wrote:

> - 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.
>
> Is it correct? We are assuming that, GSSPAI is supported means, Kerberos is
> supported. Is it right?

Yes, all sounds right to me.

> Could you please explain about the Application Server transactions??? How to
> communicate with GSSAPI?

If you have downloaded the MIT Kerberos distribution, you
could look at src/appl/gss-sample/.  Therein you will find
example code for a simple GSS application.

gss-sample uses functions like send_token() to transmit the
authentication data.  Your application won't use those, and
instead will send and receive authentication data according
to the ESMTP AUTH protocol.  That's probably explained in
an ESMTP RFC.

   Donn Cave, [hidden email]
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Clarifications sought on Kerberos SA: TGS_REQ and Server Auth??

Surendra Babu A
In reply to this post by Douglas E. Engert
Hi,

Could you please explain how can user enjoy the Server Authentication
feature with IP address of the KDC? If I give host name, it will form the
correct principal in TGS_REQ and send that to KDC.

If I give IP Address of the Server, forming of TGS_REQ is failed. How can
Client, KDC and Server agrees up on single principal name? That means, Host
name of server to be configured some where? if so, where?

My aim is: without using the Host name (FQDN) of Server, I should be able to
form TGS-REQ and get TGS-REP.

Is it possible? Please let me know your thoughts.

Thank you,
-Surendra


----- Original Message -----
From: "Douglas E. Engert" <[hidden email]>
To: "Surendra Babu A" <[hidden email]>
Cc: <[hidden email]>
Sent: Wednesday, December 07, 2005 7:34 PM
Subject: Re: Clarifications sought on Kerberos SA: TGS_REQ and Server Auth??


>
>
> 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" <[hidden email]>
> > To: "Surendra Babu A" <[hidden email]>
> > Cc: <[hidden email]>
> > 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           [hidden email]
> >>>https://mailman.mit.edu/mailman/listinfo/kerberos
> >>>
> >>>
> >>
> >>--
> >>
> >>  Douglas E. Engert  <[hidden email]>
> >>  Argonne National Laboratory
> >>  9700 South Cass Avenue
> >>  Argonne, Illinois  60439
> >>  (630) 252-5444
> >>
> >>
> >
> >
>
> --
>
>   Douglas E. Engert  <[hidden email]>
>   Argonne National Laboratory
>   9700 South Cass Avenue
>   Argonne, Illinois  60439
>   (630) 252-5444
>
>

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos