Subject: [ietf-tls] RFC2712 KerberosWrapper encoding

From: Simon Wilkinson <[email-masked]>
Date: Thu, 5 Apr 2001 17:00:17 +0100

Has anyone implemented, or is anyone aware of implementations of RFC2712?
(I'm aware of kssl)

I'm having some trouble understanding what is meant by the presentation
language description of the KerberosWrapper.

From the RFC:
| struct
| {
|     opaque Ticket;
|     opaque authenticator;            /* optional */
|     opaque EncryptedPreMasterSecret; /* encrypted with the session key
|                                         which is sealed in the ticket */
| } KerberosWrapper;                   /* new addition */

I'm not sure what is meant by the opaques here. The TLS RFC never uses opaque
without explicitly stating a length. Are these fixed length, or variable
length vectors? If they're variable length, then how many bytes are used to
encode the length?

My current implementation is using variable length, represented by 2 bytes -
I was wondering what others have done. In particular I understand there was
once a reference implementation

Of course, all this becomes moot once draft-ietf-tls-kerb-00.txt becomes
standardised (incidentally, I note that this draft uses, but does not define,
KerbEncryptedPreMasterSecret )

Cheers,

Simon.
--
Simon Wilkinson            <[email-masked]>          http://www.sxw.org.uk
"If you can't be a good example, then you'll just have to be a horrible
warning" -- Catherine Aird

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: [email-masked] (Nelson Bolyard)
Date: Fri, 06 Apr 2001 12:02:51 -0700

Simon Wilkinson wrote:

> without explicitly stating a length. 

Right.  A TLS opaque is a byte.  If the above struct is interpreted 
according to the TLS presentation language, each of those is strictly one 
byte.  Obviously that doesn't work in practice.

> Are these fixed length, or variable length vectors? If they're variable 
> length, then how many bytes are used to > encode the length?

RFC 2712 says 
"The ticket and authenticator are encoded per RFC1510 (ASN.1 encoding)."
so, presumably the author intended for the opaques above to be variable
length data whose length is determined from the ASN.1 encoding.  

IMO, that is an unfortunate choice because it means that the length of the
KerberosWrapper cannot be determined without fully ASN.1 parsing the three
members of that struct.  TLS avoids doing that, and always explicitly 
gives the length of the ASN.1 encoded struct.  E.g. in TLS's Certificate
struct, we find each cert declared
	opaque ASN.1Cert<1..2^24-1>
which means that the length of the cert is explicitly encoded in 3 bytes
prior to the cert itself.  

Also, it's unclear to me how the recipient is supposed to know whether the
"optional" authenticator is present or not.

> My current implementation is using variable length, represented by 2 bytes -

It sounds like your implemented the following structure (using TLS's 
presentation language):

struct
{
    opaque Ticket<1..2^16-1>;
    opaque authenticator<0..2^16-1>;         
    opaque EncryptedPreMasterSecret<1..2^16-1>; 
           /* encrypted with the session key which is sealed in the ticket */
} KerberosWrapper;                   /* new addition */

Is that what you did?  That seems to me like the right thing to do.
It also solves the question about the "optional" authenticator.  
A zero length authenticator is one not supplied.  

> KerbEncryptedPreMasterSecret )

Yes, that's another problem.  I don't think interoperable implementations
can be produced based strictly on RFC 2712 as it now stands.

--
Nelson Bolyard               Sun / Netscape Alliance
Disclaimer:                  I speak for myself, not for Netscape

---

---

From: Simon Wilkinson <[email-masked]>
Date: Fri, 6 Apr 2001 20:33:23 +0100

> "optional" authenticator is present or not.

This was one of the motiviating factors for the assumptions I made to 

> It sounds like your implemented the following structure (using TLS's

[snip]

> Is that what you did?  

Yes, I think that this works in all situations.

> > standardised (incidentally, I note that this draft uses, but does not
> > define, KerbEncryptedPreMasterSecret )
>
> Yes, that's another problem. 

Both 2712 and the later draft almost define it:
   the pre-master secret structure is the same as that used
   in the RSA case; it is encrypted under the Kerberos session key

However, they provide no information as to the on-the-wire encoding. This is 
hard, because I'm not convinced that there's any guarantee that the encrypted 
PMS will always be the same length, as it depends on the block size of the 
underlying Kerberos encryption algorithm. I'm currently using a variable 
vector here as well.

> I don't think interoperable implementations

I'm inclined to agree strongly here, after corresponding with the author of
the 2712 support in OpenSSL as well.

Cheers,

Simon.
-- 
Simon Wilkinson            <[email-masked]>          http://www.sxw.org.uk
"For every complex problem, there is a solution that is simple, neat, and
wrong." -- H. L. Mencken

---