Subject: RE: BER v DER: implementation comment

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 3 Sep 2004 09:01:21 -0700

> Um.... are you really suggesting that PKINIT-enabled KDCs not enforce
DER when they parse incoming messages

The BER vs DER discussion is for the encoding of the CMS objects only.
These objects are encapsulated in OCTET STRING in the Kerberos messages,
thus are not constrained by the BER encoding rules used by Kerberos
messages.  

The Microsoft CMS library (also known as CRYPTO-API) can decode
BER-encoded CMS objects, and the CMS objects it produces are DER
encoded. Thus if your KDC only accepts DER-encoded CMS, it should be
able to interoperate with our implementations.

Our position on this issue is that the PKINIT draft should not discuss
the encoding of CMS objects and leave it to the CMS spec.  I believe
Heimdal has a similar position.

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of D. R. Evans
Sent: Friday, September 03, 2004 7:24 AM
Cc: [email-masked]
Subject: Re: BER v DER: implementation comment

Tom Yu said the following at 2004-09-02 17:07 :

> Valid DER encodings are a subset of valid BER encodings.  As long as 
> you don't enforce strict DER on decode,

Um.... are you really suggesting that PKINIT-enabled KDCs not enforce
DER when they parse incoming messages?

Danger, danger, Will Robinson....

"Why does your KDC not accept my BER-encoded Kerberos messages? This one
over here is much better than yours, because it does...."

   Doc

--
--------------------------------------------------------------
Phone:  +1 303 494 0394
Mobile: +1 720 839 8462
Fax:    +1 781 240 0527
IM:     [email-masked]
--------------------------------------------------------------

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 3 Sep 2004 12:30:16 -0500

On Fri, Sep 03, 2004 at 11:11:04AM -0600, D. R. Evans wrote:
> So, to paraphrase:
> 
> My original comment: Clients might find it difficult to plement BER for 
> the CMS layer, because they have to have a DER parser for Kerberos -- so 
> now they need two parsers.
> 
> Now, either Tom is wasting bandwidth on a completely NOP response (which 
> I doubt) or he's suggesting that you don't need a DER parser because a 
> BER parser can parse DER. I disagree with that conclusion: you must have 
> a DER parser for the Kerberos stuff. If you allow BER in CMS, you now 
> also need a BER parser for the CMS stuff (and a way to switch between 
> the two, of course). In our KDC implementation this is a trivial thing 
> to arrange, but that may not be true for other implementations, 
> especially of clients.

Doc,

The problem is that we have a boundary between two different protocols,
Kerberos V and CMS, one of which specifies DER and the other of which
specifies BER.

As a result we also have boundaries between actual implementations: some
implementors have access to unrelated, off-the-shelf Kerberos V and CMS
implementations.

Forcing DER for CMS on such implementors means re-implementing CMS.
Forcing BER on CableLabs means updating their decoder.  The burden of
one the former is much larger than the burden of the latter (at least
from my p.o.v.).

Of course, you can't just transition from DER to BER at the Kerberos
V/PKINIT/CMS boundaries, so we also propose wrapping the CMS objects in
an OCTET STRING so that the boundaries in question are opaque and
clearly shadows the boundaries between off-the-shelf Kerberos V and
off-the-shelf CMS implementations.

Nico
--

---

From: "D. R. Evans" <[email-masked]>
Date: Fri, 03 Sep 2004 11:11:04 -0600

> The BER vs DER discussion is for the encoding of the CMS objects only.

Um, here is what Tom said, including my original observation:

-----

N7DR> Also, one shouldn't generalize it to assume that all implementations
N7DR> would require similarly small amounts of change. I suspect that adding
N7DR> support for BER decoding of some fields while maintaining DER decoding
N7DR> for other fields would in fact be a major pain for some
N7DR> implementations, especially clients.

Valid DER encodings are a subset of valid BER encodings.  As long as
you don't enforce strict DER on decode, a BER parser will handle both
DER and BER inputs.

-----

So, to paraphrase:

   Doc

---

From: Love <[email-masked]>
Date: Tue, 07 Sep 2004 11:18:04 +0200

> Heimdal has a similar position.

Indeed, CMS is already specified, and it allows for BER. I think that
PKINIT could recommend implementors to generate DER for the CMS objects,
but not make it mandatory.

Love

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 07 Sep 2004 19:12:02 -0400

> one the former is much larger than the burden of the latter (at least

I think you and a number of other people on this list are doing a 
disservice to the PacketCable community by making an assumption that is 
simply not true.

CableLabs is not a Kerberos implementor.

For our purposes, CableLabs is essentially a standards organization. 
Particularly, it is an industry organization whose members are cable 
television operators, and it sets standards for that industry, does 
compliance testing on products, and also provides a variety of other 
services to the industry.

The PacketCable specification focuses on using existing cable 
infrastructure to provide a variety of new services, such as voice 
telephone service.  This specification makes use of Kerberos and PKINIT to 
authenticate customer equipment to the cable operator's equipment.

There are many implementors of the PacketCable specification.  Most of 
these, in terms of both number of implementations and number of units 
deployed, are embedded systems which are installed in customers' homes. 
These units are client implementations of Kerberos and PKINIT.

So, when you say "CableLabs would have to update their decoder", what 
you're really saying is that each of these implementors would have to 
update their decoders.

> off-the-shelf CMS implementations.

This proposal was discussed at the WG meeting in San Diego, on Jabber, and 
on this mailing list.  It seems to me that we have a WG concensus to 
proceed with this.  Right now we're only discussing the encoding of the 
encapsulated CMS objects.

-- Jeff