preauth mechanism functioning at the client-side

[Gopal Paliwal]

Hi,
Thanks for the reply.
Currently the number 32 which I assigned for the new-preauth type is'nt
having conflict with the existing ones as I did go thru RFC's & relevant
code for this change.

The problem I am facing is AS_RES does contain this preauth-type as a hint
(i captured it on etheral and could see the number 32 as a type/value pair).


Also the client is able to get this hint. THis hint preauth goes in
sort_padata_seq() code at the client side but client somehow selects preauth
value 2 (pa_enc_timestamp) to fill preauth data & sends that to server.
---->When I avoid just send my required preauth(32) to the client and dont
send pa_enc_timestamp(2) to the client as a edata hint, client gives me an
error like "LOOP detacted at the in krb5_get_in_tkt". This is due to the
fact that client doesn't get preauth type(2) from the client side.

I wish to know specifically, why client is not accepting any other preauth
apart from type-2 in my case. And whether client can send 2-preauth types
back to the server.

-gopal


On 8/13/07, Tim Alsop <Tim.Alsop at cybersafe.com> wrote:
>
> Gopal
>
> You may remember that I replied to your last email, showing you the
> output from our software, which already supports RSA SecurID, VASCO
> Digipass and Secure Computing SafeWord tokens. To implement this we have
> support in our client software to handle hardware authentication
> pre-auth type. This is so that the client can ask the user for the
> information from the token + pin (if applicable). Without any client
> code changes the client is only aware of how to ask for a principal name
> and password.
>
> Also, when you select a pre-auth type, please check the RFCs in case of
> a conflict with other pre-auth types that are known.
>
> Regards,
> Tim
>
> -----Original Message-----
> From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf
> Of Gopal Paliwal
> Sent: 13 August 2007 18:23
> To: krbdev at mit.edu
> Subject: preauth mechanism functioning at the client-side
>
> hi,
>
> I am implementing a OTP support mechanism in existing kerberos 1.6.1.
> Till now, i have done the server changes and the AS_REP contains one
> more
> required timestamp as OTP one. I wish to know, will the existing client
> be
> able to send 2 preauth sequences (one is pa_enc_timestamp) and the other
> one
> is my declared preauth-using OTP.
> Or the client just sends any-one of the asked preauth type.
>
> I see that the server would able to support more than one preauth-type
> sent
> by the client by making it verify each preauth type in a loop but i am
> not
> sure about how the client behaves in sending multi-preauth types.
>
> I debugged the client code and I could make out that the client gets my
> created preauth mechanism as hint but still it selects enc_time-stamp as
> a
> default one to reply back. The number I chose for my preauth type is 32.
>
>
> Regards,
> -Gopal Paliwal
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>