You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@directory.apache.org by er...@apache.org on 2007/05/28 03:30:57 UTC
svn commit: r542072 -
/directory/apacheds/trunk/kerberos-shared/src/main/java/org/apache/directory/server/kerberos/shared/io/decoder/ErrorMessageDecoder.java
Author: erodriguez
Date: Sun May 27 18:30:56 2007
New Revision: 542072
URL: http://svn.apache.org/viewvc?view=rev&rev=542072
Log:
Added ASN.1 codec support for the client side of KDC error messages.
Added:
directory/apacheds/trunk/kerberos-shared/src/main/java/org/apache/directory/server/kerberos/shared/io/decoder/ErrorMessageDecoder.java (with props)
Added: directory/apacheds/trunk/kerberos-shared/src/main/java/org/apache/directory/server/kerberos/shared/io/decoder/ErrorMessageDecoder.java
URL: http://svn.apache.org/viewvc/directory/apacheds/trunk/kerberos-shared/src/main/java/org/apache/directory/server/kerberos/shared/io/decoder/ErrorMessageDecoder.java?view=auto&rev=542072
==============================================================================
--- directory/apacheds/trunk/kerberos-shared/src/main/java/org/apache/directory/server/kerberos/shared/io/decoder/ErrorMessageDecoder.java (added)
+++ directory/apacheds/trunk/kerberos-shared/src/main/java/org/apache/directory/server/kerberos/shared/io/decoder/ErrorMessageDecoder.java Sun May 27 18:30:56 2007
@@ -0,0 +1,159 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ *
+ */
+package org.apache.directory.server.kerberos.shared.io.decoder;
+
+
+import java.io.IOException;
+import java.nio.ByteBuffer;
+import java.util.Enumeration;
+
+import org.apache.directory.server.kerberos.shared.messages.ErrorMessage;
+import org.apache.directory.server.kerberos.shared.messages.ErrorMessageModifier;
+import org.apache.directory.server.kerberos.shared.messages.value.KerberosPrincipalModifier;
+import org.apache.directory.shared.asn1.der.ASN1InputStream;
+import org.apache.directory.shared.asn1.der.DERApplicationSpecific;
+import org.apache.directory.shared.asn1.der.DEREncodable;
+import org.apache.directory.shared.asn1.der.DERGeneralString;
+import org.apache.directory.shared.asn1.der.DERGeneralizedTime;
+import org.apache.directory.shared.asn1.der.DERInteger;
+import org.apache.directory.shared.asn1.der.DEROctetString;
+import org.apache.directory.shared.asn1.der.DERSequence;
+import org.apache.directory.shared.asn1.der.DERTaggedObject;
+
+
+/**
+ * @author <a href="mailto:dev@directory.apache.org">Apache Directory Project</a>
+ * @version $Rev$, $Date$
+ */
+public class ErrorMessageDecoder
+{
+ /**
+ * Decodes a {@link ByteBuffer} into an {@link ErrorMessage}.
+ *
+ * KRB-ERROR ::= [APPLICATION 30] SEQUENCE
+ *
+ * @param in
+ * @return The {@link ErrorMessage}.
+ * @throws IOException
+ */
+ public ErrorMessage decode( ByteBuffer in ) throws IOException
+ {
+ ASN1InputStream ais = new ASN1InputStream( in );
+
+ DERApplicationSpecific app = ( DERApplicationSpecific ) ais.readObject();
+
+ DERSequence errorMessage = ( DERSequence ) app.getObject();
+
+ return decodeErrorMessageSequence( errorMessage );
+ }
+
+
+ /*
+ KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
+ pvno [0] INTEGER (5),
+ msg-type [1] INTEGER (30),
+ ctime [2] KerberosTime OPTIONAL,
+ cusec [3] Microseconds OPTIONAL,
+ stime [4] KerberosTime,
+ susec [5] Microseconds,
+ error-code [6] Int32,
+ crealm [7] Realm OPTIONAL,
+ cname [8] PrincipalName OPTIONAL,
+ realm [9] Realm -- service realm --,
+ sname [10] PrincipalName -- service name --,
+ e-text [11] KerberosString OPTIONAL,
+ e-data [12] OCTET STRING OPTIONAL
+ }
+ */
+ private ErrorMessage decodeErrorMessageSequence( DERSequence sequence )
+ {
+ ErrorMessageModifier errorModifier = new ErrorMessageModifier();
+ KerberosPrincipalModifier clientModifier = new KerberosPrincipalModifier();
+ KerberosPrincipalModifier serverModifier = new KerberosPrincipalModifier();
+
+ for ( Enumeration e = sequence.getObjects(); e.hasMoreElements(); )
+ {
+ DERTaggedObject object = ( DERTaggedObject ) e.nextElement();
+ int tag = object.getTagNo();
+ DEREncodable derObject = object.getObject();
+
+ switch ( tag )
+ {
+ case 0:
+ // DERInteger tag0 = ( DERInteger ) derObject;
+ // int pvno = tag0.intValue();
+ break;
+ case 1:
+ // DERInteger tag1 = ( DERInteger ) derObject;
+ // msgType = MessageType.getTypeByOrdinal( tag1.intValue() );
+ break;
+ case 2:
+ DERGeneralizedTime tag2 = ( DERGeneralizedTime ) derObject;
+ errorModifier.setClientTime( KerberosTimeDecoder.decode( tag2 ) );
+ break;
+ case 3:
+ DERInteger tag3 = ( DERInteger ) derObject;
+ errorModifier.setClientMicroSecond( tag3.intValue() );
+ break;
+ case 4:
+ DERGeneralizedTime tag4 = ( DERGeneralizedTime ) derObject;
+ errorModifier.setServerTime( KerberosTimeDecoder.decode( tag4 ) );
+ break;
+ case 5:
+ DERInteger tag5 = ( DERInteger ) derObject;
+ errorModifier.setServerMicroSecond( tag5.intValue() );
+ break;
+ case 6:
+ DERInteger tag6 = ( DERInteger ) derObject;
+ errorModifier.setErrorCode( tag6.intValue() );
+ break;
+ case 7:
+ DERGeneralString tag7 = ( DERGeneralString ) derObject;
+ clientModifier.setRealm( tag7.getString() );
+ break;
+ case 8:
+ DERSequence tag8 = ( DERSequence ) derObject;
+ clientModifier.setPrincipalName( PrincipalNameDecoder.decode( tag8 ) );
+ break;
+ case 9:
+ DERGeneralString tag9 = ( DERGeneralString ) derObject;
+ serverModifier.setRealm( tag9.getString() );
+ break;
+ case 10:
+ DERSequence tag10 = ( DERSequence ) derObject;
+ serverModifier.setPrincipalName( PrincipalNameDecoder.decode( tag10 ) );
+ break;
+ case 11:
+ DERGeneralString tag11 = ( DERGeneralString ) derObject;
+ errorModifier.setExplanatoryText( tag11.getString() );
+ break;
+ case 12:
+ DEROctetString tag12 = ( DEROctetString ) derObject;
+ errorModifier.setExplanatoryData( tag12.getOctets() );
+ break;
+ }
+ }
+
+ errorModifier.setClientPrincipal( clientModifier.getKerberosPrincipal() );
+ errorModifier.setServerPrincipal( serverModifier.getKerberosPrincipal() );
+
+ return errorModifier.getErrorMessage();
+ }
+}
Propchange: directory/apacheds/trunk/kerberos-shared/src/main/java/org/apache/directory/server/kerberos/shared/io/decoder/ErrorMessageDecoder.java
------------------------------------------------------------------------------
svn:eol-style = native
Re: svn commit: r542072 - /directory/apacheds/trunk/kerberos-shared/src/main/java/org/apache/directory/server/kerberos/shared/io/decoder/ErrorMessageDecoder.java
Posted by Enrique Rodriguez <en...@gmail.com>.
On 5/27/07, Alex Karasulu <ak...@apache.org> wrote:
> ...
> And BTW kerberos-shared once moved to shared/kerberos should be just like
> shared/ldap in
> that it should contain the protocol PDU elements. It should not contain
> anything that is specific
> to a client or specific to the service that plugs into apacheds. The
> shared-ldap module for
> example contains the client and server (req/resp) PDUs for LDAP. It does
> not contain the
> LDAP protocol service which is in apacheds. Is this analogous with what is
> to be shared/kerberos?
Yes.
Enrique
Re: svn commit: r542072 - /directory/apacheds/trunk/kerberos-shared/src/main/java/org/apache/directory/server/kerberos/shared/io/decoder/ErrorMessageDecoder.java
Posted by Alex Karasulu <ak...@apache.org>.
OK this is exactly what I was thinking regarding ServiceConfiguration not
extending (core)
Configuration ... I just changed the subject on this thread for searching
archives and posted
my response to the list. I think we're talking about the same exact thing
here.
And BTW kerberos-shared once moved to shared/kerberos should be just like
shared/ldap in
that it should contain the protocol PDU elements. It should not contain
anything that is specific
to a client or specific to the service that plugs into apacheds. The
shared-ldap module for
example contains the client and server (req/resp) PDUs for LDAP. It does
not contain the
LDAP protocol service which is in apacheds. Is this analogous with what is
to be shared/kerberos?
Alex
On 5/28/07, Enrique Rodriguez <en...@gmail.com> wrote:
>
> On 5/27/07, Enrique Rodriguez <en...@gmail.com> wrote:
> > ...
> > I can make that happen by moving kerberos-shared and protocol-shared
> > to the shared subproject. protocol-shared should move since it was
> > intented to be shared by protocols. That leaves core Configuration
> > deps. Any thoughts there? I think we talked at one point about
> > moving Configuration to its own module. We may need a separate base
> > class for service (protocol) configuration vs. core configuration.
> > That makes a lot of sense and of course Spring doesn't care. I
> > thought there was some requirement that a core Configuration had to be
> > in the env when obtaining a context using CoreContextFactory but I
> > could be mistaken.
>
> I did some more checking. Most protocols had the following line in
> their env setup for using CoreContextFactory:
>
> env = new Hashtable<String, Object>( config.toJndiEnvironment() );
>
> The 'config.toJndiEnvironment()' required that every
> ServiceConfiguration extend core Configuration or an exception is
> thrown for ServiceConfiguration not being an instance of
> Configuration. If I just remove this line, I can make
> ServiceConfiguration the base of its own hierarchy and everything
> appears to work just fine. Any clue what that was there for and if I
> can just remove it? Tests pass and the server runs fine in
> server-main.
>
> With that gone and ServiceConfiguration not extending Configuration,
> the deps from protocol-shared can be easily removed. In fact, I have
> the deps totally removed now and after more testing I will likely
> commit the changes on Monday. I also apparently have to move all
> interceptors into the core. I have 3 interceptors (password policy,
> key derivation, and key export) and of course interceptors have tight
> deps to the core.
>
> I will commit everything on Monday after I test more.
>
> Enrique
>
Re: svn commit: r542072 - /directory/apacheds/trunk/kerberos-shared/src/main/java/org/apache/directory/server/kerberos/shared/io/decoder/ErrorMessageDecoder.java
Posted by Enrique Rodriguez <en...@gmail.com>.
On 5/27/07, Alex Karasulu <ak...@apache.org> wrote:
> ...
> > The alternative
> > would be 2-3 interceptors in their own module with that module having
> > deps on core and kerberos-shared.
>
> Does it make sense to put these interceptors into their own module? Just
> keep in mind
> we were eventually going to break up the core which means we might do this
> separation
> down the line anyway. Doing it now might save us a step. Do you see
> benefits in not
> stuffing these into the core?
I think they should go into the core. The dep burden is minimal.
When it's time to refactor the core then all the interceptors will be
together for review. As for performance, they need not be enabled in
the Spring XML and I also remember the impact was minimal when they
were enabled. The main issue would be if kerberos-shared pulled in a
ton of deps but it doesn't.
Enrique
Re: svn commit: r542072 - /directory/apacheds/trunk/kerberos-shared/src/main/java/org/apache/directory/server/kerberos/shared/io/decoder/ErrorMessageDecoder.java
Posted by Alex Karasulu <ak...@apache.org>.
On 5/28/07, Enrique Rodriguez <en...@gmail.com> wrote:
>
> On 5/27/07, Enrique Rodriguez <en...@gmail.com> wrote:
> > ...
> > With that gone and ServiceConfiguration not extending Configuration,
> > the deps from protocol-shared can be easily removed. In fact, I have
> > the deps totally removed now and after more testing I will likely
> > commit the changes on Monday. I also apparently have to move all
> > interceptors into the core. I have 3 interceptors (password policy,
> > key derivation, and key export) and of course interceptors have tight
> > deps to the core.
>
> FYI, moving the Kerberos-related interceptors into the core means
> putting a dep from core to kerberos-shared. That OK?
This is OK.
The alternative
> would be 2-3 interceptors in their own module with that module having
> deps on core and kerberos-shared.
Does it make sense to put these interceptors into their own module? Just
keep in mind
we were eventually going to break up the core which means we might do this
separation
down the line anyway. Doing it now might save us a step. Do you see
benefits in not
stuffing these into the core?
Alex
Re: svn commit: r542072 - /directory/apacheds/trunk/kerberos-shared/src/main/java/org/apache/directory/server/kerberos/shared/io/decoder/ErrorMessageDecoder.java
Posted by Enrique Rodriguez <en...@gmail.com>.
On 5/27/07, Enrique Rodriguez <en...@gmail.com> wrote:
> ...
> With that gone and ServiceConfiguration not extending Configuration,
> the deps from protocol-shared can be easily removed. In fact, I have
> the deps totally removed now and after more testing I will likely
> commit the changes on Monday. I also apparently have to move all
> interceptors into the core. I have 3 interceptors (password policy,
> key derivation, and key export) and of course interceptors have tight
> deps to the core.
FYI, moving the Kerberos-related interceptors into the core means
putting a dep from core to kerberos-shared. That OK? The alternative
would be 2-3 interceptors in their own module with that module having
deps on core and kerberos-shared.
Enrique
Re: svn commit: r542072 - /directory/apacheds/trunk/kerberos-shared/src/main/java/org/apache/directory/server/kerberos/shared/io/decoder/ErrorMessageDecoder.java
Posted by Enrique Rodriguez <en...@gmail.com>.
On 5/27/07, Enrique Rodriguez <en...@gmail.com> wrote:
> ...
> I can make that happen by moving kerberos-shared and protocol-shared
> to the shared subproject. protocol-shared should move since it was
> intented to be shared by protocols. That leaves core Configuration
> deps. Any thoughts there? I think we talked at one point about
> moving Configuration to its own module. We may need a separate base
> class for service (protocol) configuration vs. core configuration.
> That makes a lot of sense and of course Spring doesn't care. I
> thought there was some requirement that a core Configuration had to be
> in the env when obtaining a context using CoreContextFactory but I
> could be mistaken.
I did some more checking. Most protocols had the following line in
their env setup for using CoreContextFactory:
env = new Hashtable<String, Object>( config.toJndiEnvironment() );
The 'config.toJndiEnvironment()' required that every
ServiceConfiguration extend core Configuration or an exception is
thrown for ServiceConfiguration not being an instance of
Configuration. If I just remove this line, I can make
ServiceConfiguration the base of its own hierarchy and everything
appears to work just fine. Any clue what that was there for and if I
can just remove it? Tests pass and the server runs fine in
server-main.
With that gone and ServiceConfiguration not extending Configuration,
the deps from protocol-shared can be easily removed. In fact, I have
the deps totally removed now and after more testing I will likely
commit the changes on Monday. I also apparently have to move all
interceptors into the core. I have 3 interceptors (password policy,
key derivation, and key export) and of course interceptors have tight
deps to the core.
I will commit everything on Monday after I test more.
Enrique
Re: svn commit: r542072 - /directory/apacheds/trunk/kerberos-shared/src/main/java/org/apache/directory/server/kerberos/shared/io/decoder/ErrorMessageDecoder.java
Posted by Enrique Rodriguez <en...@gmail.com>.
On 5/27/07, Alex Karasulu <ak...@apache.org> wrote:
> ...
> This might not be a good thing. If you build a CLI or RCP based client
> then it will pull in these dependencies. You see where I'm going with this?
OK, we're on the same page here. The problem isn't putting code that
would support a client into kerberos-shared, but rather that
kerberos-shared shouldn't have the dependencies that result in a core
dependency. I agree the full load of core deps shouldn't burden
clients.
> ...
> Hmmm it depends on protocol-shared which depends on apacheds-core even
> if it may not need the dependency. Probably there's some small peice of
> code
> in protocol-shared that depends on core code but that's not used by the
> kerberos
> shared module. Regardless though you have a dependency imposed due to the
> Maven dependency graph which will cause the apacheds-core jar to be pulled
> down. If we can do away with this it will be best.
The major culprit is ServiceConfiguration, which depends on
Configuraton and ConfigurationUtil, both of which are in the core.
Everything else in protocol-shared is easy to deal with.
> > If you're wondering if kerberos-shared can be moved to the shared code
> > outside of trunk, then I think that makes sense, with a little
> > refactoring to remove minor deps on core.
>
> Yes this the point.
I can make that happen by moving kerberos-shared and protocol-shared
to the shared subproject. protocol-shared should move since it was
intented to be shared by protocols. That leaves core Configuration
deps. Any thoughts there? I think we talked at one point about
moving Configuration to its own module. We may need a separate base
class for service (protocol) configuration vs. core configuration.
That makes a lot of sense and of course Spring doesn't care. I
thought there was some requirement that a core Configuration had to be
in the env when obtaining a context using CoreContextFactory but I
could be mistaken.
Enrique
Re: svn commit: r542072 - /directory/apacheds/trunk/kerberos-shared/src/main/java/org/apache/directory/server/kerberos/shared/io/decoder/ErrorMessageDecoder.java
Posted by Alex Karasulu <ak...@apache.org>.
On 5/27/07, Enrique Rodriguez <en...@gmail.com> wrote:
>
> On 5/27/07, Alex Karasulu <ak...@apache.org> wrote:
> > Just wondering if your kerberos client will use the kerberos shared
> library?
> > If so I'm wondering if it should
> > go into shared/kerberos? However I guess it does depend on the core
> right
> > and this is why it is in the apacheds
> > project?
>
> That question wasn't totally clear on account of the "it"'s.
Yes I see that ambiguity as well now that I read it again. My point was
if you are putting client PDU code for the kerberos codec into the kerberos
shared module in apacheds then this means any client like a LoginModule
which you write will have a dependency on the kerberos-shared jar.
I don't
> see why I would put a client into kerberos-shared.
I thought from your commit log that you were putting client PDUs into
the kerberos-shared module. If I'm wrong that's fine.
What other modules
> would share a client? Instead, other modules would share components
> providing client-side support so what makes sense is to put shared
> Kerberos functionality in kerberos-shared, such as ASN.1 codecs and
> components for requesting TGTs and service tickets, which could be
> shared by different types of clients, be they CLI or RCP.
Ok I see so I was right that you are putting client PDUs into this module.
This just means that clients will now have a dependency on ApacheDS
jars since kerberos-shared is technically an ApacheDS module. This is
so because it depends on core transitively through the protocol-shared
module.
This might not be a good thing. If you build a CLI or RCP based client
then it will pull in these dependencies. You see where I'm going with this?
The Kerberos client I am working on is a CLI client with a dependency
> on Commons CLI. The CLI Kerberos client currently does depend on
> kerberos-shared, hence my codec commits to kerberos-shared. This
> Kerberos client should be mostly wiring together Commons CLI with
> codecs and the aforementioned ticket request components.
Yep I get that but it also depends on apacheds-core.
Kerberos-shared is a shared library, intended to be shared by servers
> *or* clients.
Ok this is exactly why it might be better put into the shared project rather
thank keeping it in the apacheds project. Basically it would be analogous
to the shared/ldap module which does not depend on the core but can be
used by it as well as any clients. We do not want these shared libraries
for various protocols to be pulling in dependencies from the server.
SNIP
If you're wondering how this could work with enhancements to
> LdapStudio, then I was picturing LdapStudio plugins would depend on
> kerberos-shared and not pick up any of the CLI-specific code in
> clients-kerberos.
No that's fine. I'm just thinking we might want to move the kerberos-shared
module into the shared subproject instead of keeping it in the apacheds
project
and removing the dependency on core. This probably just means replacing or
duplicating (if small) the code that the kerberos-shared module depends on
in
the protocol-shared module. Or another option is to move the code that is
depended on into the kerberos-shared module. I'm sure there are other
options
as well but the whole point is to remove the dependency that kerberos-shared
has transitively to the apacheds core.
kerberos-shared shouldn't have any dependencies on core. I think it
> is mostly in apacheds trunk for legacy reasons.
Hmmm it depends on protocol-shared which depends on apacheds-core even
if it may not need the dependency. Probably there's some small peice of
code
in protocol-shared that depends on core code but that's not used by the
kerberos
shared module. Regardless though you have a dependency imposed due to the
Maven dependency graph which will cause the apacheds-core jar to be pulled
down. If we can do away with this it will be best.
Though, it does have
> a dependency on ConfigurationException, but that's easy to either get
> rid of or, since it occurs in single vs. multi-base searches, replace
> when we have a better solution for multi-base searching.
>
> If you're wondering if kerberos-shared can be moved to the shared code
> outside of trunk, then I think that makes sense, with a little
> refactoring to remove minor deps on core.
Yes this the point.
Alex
Re: svn commit: r542072 - /directory/apacheds/trunk/kerberos-shared/src/main/java/org/apache/directory/server/kerberos/shared/io/decoder/ErrorMessageDecoder.java
Posted by Enrique Rodriguez <en...@gmail.com>.
On 5/27/07, Alex Karasulu <ak...@apache.org> wrote:
> Just wondering if your kerberos client will use the kerberos shared library?
> If so I'm wondering if it should
> go into shared/kerberos? However I guess it does depend on the core right
> and this is why it is in the apacheds
> project?
That question wasn't totally clear on account of the "it"'s. I don't
see why I would put a client into kerberos-shared. What other modules
would share a client? Instead, other modules would share components
providing client-side support so what makes sense is to put shared
Kerberos functionality in kerberos-shared, such as ASN.1 codecs and
components for requesting TGTs and service tickets, which could be
shared by different types of clients, be they CLI or RCP.
The Kerberos client I am working on is a CLI client with a dependency
on Commons CLI. The CLI Kerberos client currently does depend on
kerberos-shared, hence my codec commits to kerberos-shared. This
Kerberos client should be mostly wiring together Commons CLI with
codecs and the aforementioned ticket request components.
Kerberos-shared is a shared library, intended to be shared by servers
*or* clients. The clients could be CLI or GUI, Swing or RCP. All the
ASN.1 codecs are in kerberos-shared. For example, the commit in
question is ASN.1 support for decoding ErrorMessages and will be used
by client-side Kerberos and client-side Change Password.
If you're wondering how this could work with enhancements to
LdapStudio, then I was picturing LdapStudio plugins would depend on
kerberos-shared and not pick up any of the CLI-specific code in
clients-kerberos.
kerberos-shared shouldn't have any dependencies on core. I think it
is mostly in apacheds trunk for legacy reasons. Though, it does have
a dependency on ConfigurationException, but that's easy to either get
rid of or, since it occurs in single vs. multi-base searches, replace
when we have a better solution for multi-base searching.
If you're wondering if kerberos-shared can be moved to the shared code
outside of trunk, then I think that makes sense, with a little
refactoring to remove minor deps on core.
Enrique
Re: svn commit: r542072 - /directory/apacheds/trunk/kerberos-shared/src/main/java/org/apache/directory/server/kerberos/shared/io/decoder/ErrorMessageDecoder.java
Posted by Alex Karasulu <ak...@apache.org>.
Just wondering if your kerberos client will use the kerberos shared
library? If so I'm wondering if it should
go into shared/kerberos? However I guess it does depend on the core right
and this is why it is in the apacheds
project?
Alex
On 5/27/07, erodriguez@apache.org <er...@apache.org> wrote:
>
> Author: erodriguez
> Date: Sun May 27 18:30:56 2007
> New Revision: 542072
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=542072
> Log:
> Added ASN.1 codec support for the client side of KDC error messages.
>