You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2007/06/26 10:08:29 UTC
Incompatible HostAddressType with RFCs
Hi,*
while looking at the HostAddressType class (in kerberos-shared
project), I found values for address types which are not the same than
the ones given in RFC 1510 or 4120. Is there a reason, or is it just a
copy from the<sys/socket.h> values ?
For instance, we don't support NetBios and IPV6 address types while it
is described into the RFCs (code 16 and 20), and there are some
address types which are listed in the source and not in the RFCs.
Thanks for any information.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Incompatible HostAddressType with RFCs
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi,
On 7/2/07, Enrique Rodriguez <en...@gmail.com> wrote:
> On 6/26/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> > Oh, ok.
> >
> > I was also thinking about switching from Class to Enum for those types.
>
> I like the way the current Class enumerators allow for a descriptive
> toString(), which is useful during logging. I didn't think you could
> replicate that with enums.
Enum are just wrappers for classes, but with special syntaxes. Here is
an example of conversion, where you can see that we also have the
toString() method :
package org.apache.directory.server.kerberos.shared.messages.value.types;
import java.util.Arrays;
public enum TransitedEncodingType
{
/**
* Constant for the "null" transited encoding type.
*/
NULL( 0 ),
/**
* Constant for the "Domain X500 compress" transited encoding type.
*/
DOMAIN_X500_COMPRESS( 1 );
/**
* Array for building a List of VALUES.
*/
private static final TransitedEncodingType[] values =
{ NULL, DOMAIN_X500_COMPRESS };
/**
* A List of all the transited encoding type constants.
*/
public static final List VALUES = Collections.unmodifiableList(
Arrays.asList( values ) );
/**
* The value/code for the transited encoding type.
*/
private final int ordinal;
/**
* Private constructor prevents construction outside of this class.
*/
private TransitedEncodingType( int ordinal )
{
this.ordinal = ordinal;
}
/**
* Returns the transited encoding type when specified by its ordinal.
*
* @param type
* @return The transited encoding type.
*/
public static TransitedEncodingType getTypeByOrdinal( int type )
{
switch ( type )
{
case 1 : return DOMAIN_X500_COMPRESS;
default : return NULL;
}
}
/**
* Returns the number associated with this transited encoding type.
*
* @return The transited encoding type ordinal.
*/
public int getOrdinal()
{
return ordinal;
}
/**
* @see Object#toString()
*/
public String toString()
{
switch ( this )
{
case DOMAIN_X500_COMPRESS : return "Domain X500 compress (1)";
default : return "null (0)";
}
}
}
>
> > FYI, I have started to write some encoders for simple Kerberos
> > constructs (like PrincipalName, EncryptionKey,etc) and it works pretty
> > well. The idea is to extend the existing classes by adding a couple of
> > methods, so that you ask them to 'encode' themselves :
>
> OK, so it sounds like the message class and its codecs are combined,
> similar to how JAAS KerberosTicket works.
>
> Sounds good, especially the speed boost.
I will soon commit some code. It's really faster.
FYI, the most important
> class, which directs the heavy lifting, is CipherTextHandler.
Yes, I noticed it's the place where we have huge CPU consumption while
running some tests. There may be some ways to improve this class, but
I want to finish the codec stuff before, because it's the easiest way
for me to get a grip on the whole thing, learning all the vocabulary
and interns of Kerberos from the low level layer.
> CipherTextHandler contains the static hashed adapters that actually
> make use of the Encoder/Decoder interfaces, so this is where
> compatibility with the new codecs is key. This is for the "one-shot"
> codec use.
I see. It should not be a pb at all.
>
> > PrincipalName principal = new PrincipalName(
> > PrincipalNameType.KRB_NT_PRINCIPAL, "Test" );
> >
> > ByteBuffer encoded = ByteBuffer.allocate( principal.computeLength() );
> >
> > principal.encode( encoded );
>
> Is this for the "one-shot" use or also how the codecs are used in the
> codec filters? I ask because all of the JCE crypto works with byte[]
> so anytime one of the current Encoder-using Kerberos objects is
> "one-shot" encoded it is immediately encrypted using the byte[] form.
> If this is a no cost operation than it is OK but I thought you should
> be aware. It may be slightly nicer for the API to use a byte[].
I have used ByteBuffer just to be in synch with MINA, as MINA is using
ByteBuffers. The overhead is almost unnoticeable. Switching from
ByteBuffer to byte[] is barely the same operation then switching from
String to char[] : an access to the intern array.
>
> Enrique
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Incompatible HostAddressType with RFCs
Posted by Enrique Rodriguez <en...@gmail.com>.
On 6/26/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> Oh, ok.
>
> I was also thinking about switching from Class to Enum for those types.
I like the way the current Class enumerators allow for a descriptive
toString(), which is useful during logging. I didn't think you could
replicate that with enums.
> FYI, I have started to write some encoders for simple Kerberos
> constructs (like PrincipalName, EncryptionKey,etc) and it works pretty
> well. The idea is to extend the existing classes by adding a couple of
> methods, so that you ask them to 'encode' themselves :
OK, so it sounds like the message class and its codecs are combined,
similar to how JAAS KerberosTicket works.
Sounds good, especially the speed boost. FYI, the most important
class, which directs the heavy lifting, is CipherTextHandler.
CipherTextHandler contains the static hashed adapters that actually
make use of the Encoder/Decoder interfaces, so this is where
compatibility with the new codecs is key. This is for the "one-shot"
codec use.
> PrincipalName principal = new PrincipalName(
> PrincipalNameType.KRB_NT_PRINCIPAL, "Test" );
>
> ByteBuffer encoded = ByteBuffer.allocate( principal.computeLength() );
>
> principal.encode( encoded );
Is this for the "one-shot" use or also how the codecs are used in the
codec filters? I ask because all of the JCE crypto works with byte[]
so anytime one of the current Encoder-using Kerberos objects is
"one-shot" encoded it is immediately encrypted using the byte[] form.
If this is a no cost operation than it is OK but I thought you should
be aware. It may be slightly nicer for the API to use a byte[].
Enrique
Re: Incompatible HostAddressType with RFCs
Posted by Emmanuel Lecharny <el...@gmail.com>.
Oh, ok.
I was also thinking about switching from Class to Enum for those types.
FYI, I have started to write some encoders for simple Kerberos
constructs (like PrincipalName, EncryptionKey,etc) and it works pretty
well. The idea is to extend the existing classes by adding a couple of
methods, so that you ask them to 'encode' themselves :
PrincipalName principal = new PrincipalName(
PrincipalNameType.KRB_NT_PRINCIPAL, "Test" );
ByteBuffer encoded = ByteBuffer.allocate( principal.computeLength() );
principal.encode( encoded );
The ByteBuffer now contains the encoded PrincipalName. For such an
object, the gain is impressive : it encodes around 6 times faster. The
good point is that it's not intrusive (the old encoding is still
working, otherwise I wouldn't be able to compare the results)
I also started to add some Unit tests for each class I extended, with
specific tests (like a Principal name with a NULL name)
Work in progress, and it will take time...
On 6/27/07, Enrique Rodriguez <en...@gmail.com> wrote:
> On 6/26/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> > ...
> > while looking at the HostAddressType class (in kerberos-shared
> > project), I found values for address types which are not the same than
> > the ones given in RFC 1510 or 4120. Is there a reason, or is it just a
> > copy from the<sys/socket.h> values ?
>
> Yes, socket.h.
>
> > For instance, we don't support NetBios and IPV6 address types while it
> > is described into the RFCs (code 16 and 20), and there are some
> > address types which are listed in the source and not in the RFCs.
>
> And some of the numbers are just wrong, most importantly the one for
> IPv6. I recommend trimming/updating it to just the values from RFC
> 4120.
>
> Enrique
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Incompatible HostAddressType with RFCs
Posted by Enrique Rodriguez <en...@gmail.com>.
On 6/26/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> ...
> while looking at the HostAddressType class (in kerberos-shared
> project), I found values for address types which are not the same than
> the ones given in RFC 1510 or 4120. Is there a reason, or is it just a
> copy from the<sys/socket.h> values ?
Yes, socket.h.
> For instance, we don't support NetBios and IPV6 address types while it
> is described into the RFCs (code 16 and 20), and there are some
> address types which are listed in the source and not in the RFCs.
And some of the numbers are just wrong, most importantly the one for
IPv6. I recommend trimming/updating it to just the values from RFC
4120.
Enrique