Newbie's question

[kaiduan xie]

Jeffrey,

Many thanks for help. In fact, why we choose Kerberos is that we do not want 
to keep the user's password in clear text. Be more straight, we do not want 
to transmit the user's password in Internet, and also are prohibited from 
getting the clear-text password from our customer. Now we are using MD5, 
although it does not transmit the user's password in Internet, it requires 
the clear text password at the server side to calculate the response and 
compares the response with that came from the message. So I think base-64 
encoding the whole
Kerberos AP-REQ message and putting the message in the application's message 
is fine so far.

Best regards,

kaiduan


>From: Jeffrey Hutzelman <jhutz at cmu.edu>
>To: kaiduan xie <kaiduanx at hotmail.com>, kerberos at mit.edu
>Subject: Re: Newbie's question
>Date: Wed, 30 Mar 2005 20:53:48 -0500
>
>
>
>On Wednesday, March 30, 2005 04:33:21 PM -0800 kaiduan xie 
><kaiduanx at hotmail.com> wrote:
>
>>Hi, all,
>>
>>I have an application where the client needs to authenticate to the
>>server before carrying on further communications. The client will acquire
>>ticket from KDC which runs in Microsoft's Domain Controller. After
>>getting the ticket, the client will send the ticket and the authenticator
>>together to the server for authentication. My question are:
>>
>>1) Can I put the authenticator and ticket into MY application's message
>>instead of Kerberos's Application Request message? For example, convert
>>the authenticator and ticket into hex-coded string and put this string
>>into the MY applicaiton's message.
>>
>>Credential: 0fde234567abedghi
>>
>>and at the server side, after receiving the authenticator and ticket from
>>the application's message (NOT Kerberos's Application Request message),
>>the server applies Kerberos algorithm to verify whether the credential is
>>correct or not.
>
>Well, you _can_ do whatever you want, but if you don't use Kerberos 
>messages, then the resulting protocol is not Kerberos and cannot safely be 
>assumed to have the security properties of Kerberos.  For example, in the 
>Kerberos AP-REQ exchange, the authenticator is both encrypted and 
>integrity-protected.  The algorithms used to provide these properties are 
>carefully designed to avoid a number of attacks against both the crypto and 
>the protocol as a whole; without the require properties, the protocol is 
>not secure.
>
>You should not expect Kerberos libraries to give you much help if you are 
>not using Kerberos messages.  The simplest and most portable interfaces are 
>designed around producing and consuming Kerberos protocol messages.  If you 
>choose not to use those messages, you will end up writing a lot more code.
>
>
>What you probably want to do instead is use the Kerberos messages, but 
>transport them in an encoded form suitable for your application.  For 
>example, your "Credential" example above could be the hex-encoded form of a 
>Kerberos AP-REQ.  However, you should bear in mind that the actual messages 
>will be considerably larger than suggested by your example.  If possible, 
>you should consider using a more compact encoding, such as the base-64 
>encoding defined in section 3 of RFC3548.
>
>Also, it is worth noting that unless your application message is 
>integrity-protected (and possibly encrypted) in a way that is 
>cryptographically bound to your authentication exchange, you haven't 
>actually gained much.  Sending a "Credential" containing a hex-encoded 
>AP-REQ may prove the client's identity, but it doesn't prove that any of 
>the rest of the message actually came from that client, as opposed to from 
>some attacker who modified the request in transit.
>
>-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
>   Sr. Research Systems Programmer
>   School of Computer Science - Research Computing Facility
>   Carnegie Mellon University - Pittsburgh, PA
>

_________________________________________________________________
Take charge with a pop-up guard built on patented Microsoft® SmartScreen 
Technology. 
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines 
  Start enjoying all the benefits of MSN® Premium right now and get the 
first two months FREE*.