Subject: Re: PKINIT open issues

From: "D. R. Evans" <[email-masked]>
Date: Tue, 11 May 2004 11:49:56 -0600

Love said the following at 04/20/2004 04:50 PM:-
> lets start over, I'm confusing things.
> 
> 1) what key should the reply be enveloped with in the encKey case ?
> 2) what encoding should be used ? CMS allow both DER and BER.
> 3) what is encryptedContentType ?
> 
> these three are are why I'm finding the text confusing
> 

Fair enough; except that you did not describe any of those issues in 
your original posting in this thread. You said that the text was 
confusing, but did not explain why, so I had no idea what yourobjections 
were.

Three issues are already two more than I like to deal with in a single 
e-mail, so I'll put the rest of your e-mail to one side for now and deal 
with the other issues when I get a chance to think about them.

As for the issues you raise:

 > 1) what key should the reply be enveloped with in the encKey case ?

I'm not certain what the phrase "enveloped with" means. Can you please 
explain in minute, tedious detail exactly what you are asking? There are 
too many layers of things going on here for me to try to guess exactly 
what you are asking, since I'll probably guess wrongly.

 > 2) what encoding should be used ? CMS allow both DER and BER

Kerberos requires DER (section 5.1 of RFC 1510), and I don't see any 
suggestion anywhere in this ID that the situation should be any 
different here.

 > 3) what is encryptedContentType ?

Right. Looks like an error, and it should be contentType. Brian, please 
change this if you agree.

   Doc

-- 

-----------------------------------------------------------
Office:  +1 303 494 0394
Mobile: +1 720 839 8462
Fax:    +1 781 240 0527
-----------------------------------------------------------

---

From: Brian Tung <[email-masked]>
Date: Tue, 11 May 2004 11:29:02 -0700

> change this if you agree.

Agreed on both counts, I think.

Brian Tung <[email-masked]>

---

From: Sam Hartman <[email-masked]>
Date: Tue, 11 May 2004 15:08:47 -0400

It seems clear that the Kerberos PDUs will need to be DER encoded.
But is restricting the encoding of the CMS entities desirable?  Do all
the libraries support both encoding types?

---

From: "D. R. Evans" <[email-masked]>
Date: Tue, 11 May 2004 16:10:57 -0600

Sam Hartman said the following at 05/11/2004 01:08 PM:-
> the libraries support both encoding types?

Here is my initial reaction:

-----

If by that you mean "do all extant implementations of PKINIT support 
BER?", the answer is No.

I have always regarded RFC 1510's requirements as controlling, since 
they are unambiguous and provide for no case in which non-DER encoded 
entities would be permitted in Kerberos.

In addition, stacks that reconstitute objects for signature verification 
rely on the use of DER.

-----

However, re-reading your posting, I'm not completely certain where you 
are intending that there might be a line that could be drawn.

So if you could describe an algorithm for determining which entities 
could be allowed to be BER encoded I could (possibly, albeit unlikely) 
be persuaded that BER encoding should be permitted for some objects if 
someone really wants to do that.

   Doc

--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 May 2004 17:31:23 -0500

> are intending that there might be a line that could be drawn.

IMO, wherever Kerberos V or Kerberos extensions like PKINIT have OCTET
STRINGs (or BIT STRINGs even) containing non-Kerberos data then the
encoding of their content is controlled by the specification of that
content, whatever it is.

PKINIT does not have any such OCTET STRINGs or BIT STRINGs, so I would
assume a consistent encoding, but PKINIT uses OCTET STRING holes in
Kerberos V, so technically PKINIT could use BER consistently just as
well as DER.

Of course, since Kerberos implementors already use DER I would think
that DER should be preferred, but, then, if existing PKI toolkits fail
to support DER, then BER may be preferred.

> someone really wants to do that.

I don't know if this is a hard and fast rule off the top of my head, but
I'd be surprised if it weren't:

    Within a single encoded value of some ASN.1 type, a single encoding
    type should be used throughout from the root of the value, but this
    should not constrain the encoding of values stuffed into OCTET/BIT
    STRING and other such holes (e.g., IOS holes and the old "ANY") in
    the first value's type.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 11 May 2004 22:46:39 -0400

>>>>> "D" == D R Evans <[email-masked]> writes:

    D> Sam Hartman said the following at 05/11/2004 01:08 PM:-
    >> It seems clear that the Kerberos PDUs will need to be DER
    >> encoded.  But is restricting the encoding of the CMS entities
    >> desirable?  Do all the libraries support both encoding types?
    >> 

    D> Here is my initial reaction:

    D> -----

    D> If by that you mean "do all extant implementations of PKINIT
    D> support BER?", the answer is No.

    D> I have always regarded RFC 1510's requirements as controlling,
    D> since they are unambiguous and provide for no case in which
    D> non-DER encoded entities would be permitted in Kerberos.

No, I meant do all existing CMS libraries support both encodings and
allow callers to choose which encoding is used.

For that matter, does CMS allow profiles of its usage to specify
encoding rules or does it mandate both encoding rules be supported.

It is inappropriate for RFC 1510 to specify what ASN.1 encoding rules
are used to encode CMS types.

---

From: Love <[email-masked]>
Date: Wed, 12 May 2004 10:20:05 +0200

"D. R. Evans" <[email-masked]> writes:

> confusing, but did not explain why, so I had no idea what
> yourobjections were.
>
> e-mail, so I'll put the rest of your e-mail to one side for now and
> deal with the other issues when I get a chance to think about them.
>
> explain in minute, tedious detail exactly what you are asking? There
> are too many layers of things going on here for me to try to guess
> exactly what you are asking, since I'll probably guess wrongly.

enveloped in the CMS sense, what is the certificate/private-key pair that
was used for to do the CMS operation envelope ?

The answer is of course the same cert/key that the user used (or the
encryptionCert, but that is another story), should be stated.

What error is returned when the certificate isn't allowed/possible to use
envelopedData (by policy or certiciate type) ?

> suggestion anywhere in this ID that the situation should be any

Kerberos can not specify CMS, CMS is already done.

read "2  General Overview" in RFC3369.

I'm fine with requireing DER, but then it must be stated.

Love

---

From: Love <[email-masked]>
Date: Wed, 12 May 2004 10:31:18 +0200

Sam Hartman <[email-masked]> writes:

> Do all the libraries support both encoding types?

I think the question is you can force your CMS lib to generate DER.

For all three (and half, heimdal have two CMS implementations) current
implementations this doesn't seem to be an issue.

I'm quite sure heimdal will not mange to decode packets if they are BER
packets, thus my question.

Love

---

From: "D. R. Evans" <[email-masked]>
Date: Wed, 12 May 2004 10:39:28 -0600

Sam Hartman said the following at 05/11/2004 08:46 PM:-

> allow callers to choose which encoding is used.

In that case, I don't know.

FWIW (which may be nothing) PacketCable mandates DER for all messages 
and objects.

> encoding rules or does it mandate both encoding rules be supported.

I don't know.

> are used to encode CMS types.

I disagree that it is in principle inappropriate for a protocol to state 
how its ASN.1 objects are going to be encoded. It may or may not be 
inappropriate _in this case_, but I don't think you can simply state 
that it is inappropriate without considerable justification.

I understand you to be saying that, since ContentInfo is a CMS type, 
basically all of the information in a PKINIT request can be BER encoded.

Here's why I hate the idea of BER anywhere:

Use of BER implies:

1. Massive layer breaking, since an application must have access to the 
bits that were on the wire in order to verify signatures;

2. An inability to test devices properly, since a single ASN.1 field may 
be BER encoded in what amounts an infinite number of ways, so there's no 
way to guarantee that a recipient can handle all of them, nor that it 
fails gracefully in all the cases where it does fail.

   Doc

--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 12 May 2004 13:27:13 -0400

>> It is inappropriate for RFC 1510 to specify what ASN.1 encoding
    >> rules are used to encode CMS types.
    >> 

    D> I disagree that it is in principle inappropriate for a protocol
    D> to state how its ASN.1 objects are going to be encoded. 

RFC 1510 does not specify CMS.  IT is entirely appropriate for RFC
1510 to specify that DER is used for Kerberos objects.  It even does
this.

Assuming the CMS profiles allow us to do so it is appropriate for
pkinit (but not RFC 1510) to specify that DER be used for CMS objects.
Assuming that it does not create an implementation problem, it is wise
for us to do so.

--Sam

---

From: "D. R. Evans" <[email-masked]>
Date: Wed, 12 May 2004 11:57:55 -0600

Sam Hartman said the following at 05/12/2004 11:27 AM:-
> 1510 to specify that DER is used for Kerberos objects.  It even does

Yep. "All uses of ASN.1 in Kerberos....". I read this to mean, strangely 
enough, "all uses" :-)

> Assuming that it does not create an implementation problem, it is wise

CMS is (as usual) not terribly clear, but it does say that "signed 
attributes and authenticated attributes" require DER encoding. That's 
good enough for me to suggest that we should simply explicitly make DER 
mandatory.

   Doc

--

---

From: "D. R. Evans" <[email-masked]>
Date: Mon, 17 May 2004 16:03:38 -0600

> 
> 4) what is encryptionCert

Well, I don't pretend to know anything about this at all; but it seems 
to me, simply from reading the draft, that it is intended to tell the 
KDC, "Hey, you've already got a cert of mine. Use it when you build the 
reply."

If I'm wrong, then I would agree that this option needs more 
explanation. But I don't see what else it could mean. Presumably you 
think that there's an ambiguity, though, so what else do you think that 
this field could mean?

   Doc

--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 17 May 2004 19:23:45 -0400

>>>>> "D" == D R Evans <[email-masked]> writes:

    D> Love said the following at 04/20/2004 04:50 PM:-
    >> 4) what is encryptionCert

    D> Well, I don't pretend to know anything about this at all; but
    D> it seems to me, simply from reading the draft, that it is
    D> intended to tell the KDC, "Hey, you've already got a cert of
    D> mine. Use it when you build the reply."

    D> If I'm wrong, then I would agree that this option needs more
    D> explanation. But I don't see what else it could
    D> mean. Presumably you think that there's an ambiguity, though,
    D> so what else do you think that this field could mean?

Well then there is the question of why is it reasonable not to require
this to be signed?

---

From: "D. R. Evans" <[email-masked]>
Date: Mon, 17 May 2004 19:09:48 -0600

Sam Hartman said the following at 05/17/2004 05:23 PM:-

> Well then there is the question of why is it reasonable not to require

Repeating my caveat that I don't pretend to know anything about this use of
PKINIT, I don't immediately see what would be the point of signing the
encryptionCert field.

What do you believe would be gained by requiring that it be signed?

   Doc

--

---

From: Love <[email-masked]>
Date: Tue, 18 May 2004 11:51:41 +0200

"D. R. Evans" <[email-masked]> writes:

> PKINIT, 

That the point, I don't know anything, you don't know anything. Why should
it be there if noone know what its good for and the rationale of putting it
there.

I can se how you want to use it. (rsa or dh certifiate as encryptionCert
and using a DSA signing certifiate). But what is the point of that ? If you
want rsa, just use rsa. if you want dh, just use the pkinit dh.

> I don't immediately see what would be the point of signing the
> encryptionCert field.
>

So it doens't get replaced by an attacker to the attackers own certifiate.

I can't really understand why the whole PA-PK-AS-REQ isn't signed.

Love

---

From: "D. R. Evans" <[email-masked]>
Date: Tue, 18 May 2004 09:59:45 -0600

Love said the following at 05/18/2004 03:51 AM:-

> it be there if noone know what its good for and the rationale of putting it

I agree that it would be nice if whoever invented this use would pipe up 
and defend it :-)

> So it doens't get replaced by an attacker to the attackers own certifiate.

What good would that do the attacker? The KDC would simply reject the 
request.

   Doc

--

---

From: Love <[email-masked]>
Date: Tue, 18 May 2004 19:29:49 +0200

> What good would that do the attacker? The KDC would simply reject the

The point of having a encryptionCert is that you can have your
encryptionCert != cert that signed the SignedData of the AuthPack.

Or do you assume the kdc have configuration about what certifiates the
users is allowed to pass in as the encryptionCert ? I'm not assuming that,

Love

---

From: "D. R. Evans" <[email-masked]>
Date: Tue, 18 May 2004 12:03:05 -0600

> 5) I ask two times now for TrustedCAs issuerAndSerial should be [2] not [1]
>  the second time brian told me that this would change
>  see <[email-masked]> to [email-masked]

I am sitting looking at my current copy of the ID, and it _is_ [2] in 
the current document. So I don't understand what your issue is.

   Doc

--

---

From: "D. R. Evans" <[email-masked]>
Date: Tue, 18 May 2004 12:53:45 -0600

Love said the following at 05/18/2004 11:29 AM:-
> encryptionCert != cert that signed the SignedData of the AuthPack.

If that was the intended use, then yes, it needs to be signed. I had 
worked backwards: "since it's not signed, then this must identify the 
cert that signs the SignedData" :-)

But I guess that you are probably right about the intended use, since it 
is called "encryptionCert", not "signatureCert". Also, now I look more 
carefully at text in the ID, the cert that performs the signing MUST be 
included anyway.

I wish someone would step forward and explain definitively how this 
option is supposed work.

Maybe we should give a two-day deadline: if we don't hear anything by 
the end of Thursday, the encryptionCert option goes away because we 
think it's broken! Anyone object to that????

> users is allowed to pass in as the encryptionCert ? I'm not assuming that,

Nope; I wouldn't assume that either.

   Doc

--

---

From: Love <[email-masked]>
Date: Tue, 18 May 2004 21:18:37 +0200

> the current document. So I don't understand what your issue is.

The current copy of the document[1] is wrong, but since Brian say that he
have now fixed it, i'm fine with it.

Love

[1]http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-19.txt

---

From: "D. R. Evans" <[email-masked]>
Date: Tue, 18 May 2004 13:23:49 -0600

D. R. Evans said the following at 05/18/2004 12:03 PM:-
> the current document. So I don't understand what your issue is.

And now I do -- because I thought I was looking at the current document, 
but now realise that I was looking at something that claims to be 
version 19, but isn't!

   Doc

--

---

From: Brian Tung <[email-masked]>
Date: Tue, 18 May 2004 14:22:59 -0700

> but now realise that I was looking at something that claims to be 

I am pretty sure I changed it in the version I sent to you and Sasha and
Eric.  Did some cut-and-pasting happen, perhaps?

P.S. Wrt encryptionCert, I remember putting it in in response to a request
for the possibility that different keys were being used.  I'm afraid I
don't remember who asked for it, and for what specific application.

---

From: "D. R. Evans" <[email-masked]>
Date: Tue, 18 May 2004 15:59:56 -0600

Brian Tung said the following at 05/18/2004 03:22 PM:-
> Eric.  Did some cut-and-pasting happen, perhaps?

Nope; that's the version I had printed out and was looking at. It 
definitely claims to be version 19 :-) Never mind; no harm done except 
that I looked a bit silly -- and I'm very used to that.

> don't remember who asked for it, and for what specific application.

Well, let's see if anyone responds to my challenge. At this point, I'm 
reasonably convinced that it either should go away or there should be 
more description of how it is to be used (and it should be signed if 
it's really supposed to be used the way that Love suggested).

   Doc

--

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 18 May 2004 17:04:21 -0500

> Eric.  Did some cut-and-pasting happen, perhaps?

Is it time to send out a new version to eveyone? 

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Brian Tung <[email-masked]>
Date: Tue, 18 May 2004 21:41:06 -0700

> Is it time to send out a new version to eveyone? 

Yes, I think so, but I think I need to talk to the group that revised
it for pk-init-19.txt before we do so.  There are obviously a few things
that I didn't pay enough attention to.

---

From: Love <[email-masked]>
Date: Wed, 19 May 2004 09:03:27 +0200

> don't remember who asked for it, and for what specific application.

I woke up somewhat early this morning and started to search for for the
origin of encryptionCert.

http://ftp.us.xemacs.org/ftp/pub/ietf/cat/cat-minutes-99mar.txt

Kerberos Public-Key Initial Authentication (PKINIT):
[...]

Denis Pinkas (Bull) commented that PKINIT's introduction needs modification
to reflect Diffie-Hellman as mandatory and RSA as optional, and suggested
also including a facility for signing a users' key independently of a
certificate. He also indicated concern about the use of a single certificate
for signing and encrypting, wanting separate certificates to be used in
order to allow segregation by key usage.  There was consensus among
attendees to allow segregated support, but a specific proposal to the list
is required in order to define the approach. 

I have not been able to find the discussion on the mailing list, so I don't
know why the field was put outside the checksum.

Love

---

From: Sam Hartman <[email-masked]>
Date: Wed, 19 May 2004 16:46:11 -0400

>>>>> "D" == D R Evans <[email-masked]> writes:

    D> I wish someone would step forward and explain definitively how
    D> this option is supposed work.

    D> Maybe we should give a two-day deadline: if we don't hear
    D> anything by the end of Thursday, the encryptionCert option goes
    D> away because we think it's broken! Anyone object to that????

Provided that the people using this option are not Microsoft, I agree.
Unfortunately the people following this from Microsoft's side all seem
to be on vacation or out of the country right now.

However I seem to recall that Microsoft does not use DH and the two
modes of operation are DH and this option.

---

From: "D. R. Evans" <[email-masked]>
Date: Wed, 19 May 2004 16:08:01 -0600

> 6) INTEGER use <[email-masked]>
> 

As usual, I am confused. That message ID corrsponds to the announcement 
of version 18. I don't understand what that has to do with "INTEGER use".

 From the source of that message:

-----

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-cat-kerberos-pk-init-18.txt
Date: Tue, 17 Feb 2004 10:34:20 -0500
Sender: [email-masked]
6.5|September 26, 2003) at
  02/17/2004 11:10:52 AM,
	Serialize by POP3 Server on Mercury/Antec(Release 6.5.1|January 21, 
2004) at
  02/23/2004 09:37:54 AM,
	Serialize complete at 02/23/2004 09:37:54 AM
Content-Type: Multipart/Mixed; Boundary="NextPart"

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Kerberos WG Working Group of the IETF.

-----

etc.

   Doc

--

---

From: Love <[email-masked]>
Date: Sun, 23 May 2004 22:00:19 +0200

"D. R. Evans" <[email-masked]> writes:

> As usual, I am confused. That message ID corrsponds to the
> announcement of version 18. I don't understand what that has to do
> with "INTEGER use".

Sorry, I must have copied the from Message-id: from the wrong mail. I think
that issue is mentioned in:

Message-ID: <[email-masked]>

Basicly, it "INTEGER usage" calls for using constrained INTEGER where
approporate.

Love

> Message-Id: <[email-masked]>
> Mime-Version: 1.0
> To: IETF-Announce: ;
> Cc: [email-masked]
> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on
> 	frigga.ctd.anl.gov
> X-Spam-Status: No, hits=-99.6 required=5.7 tests=MIME_BOUND_NEXTPART,
> 	NO_REAL_NAME,USER_IN_WHITELIST autolearn=no version=2.60
> Precedence: bulk
> X-MIMETrack: Itemize by SMTP Server on Pluto2/Antec(Release
> 	Serialize by POP3 Server on Mercury/Antec(Release
> 6.5.1|January 21, 2004) at
>   02/23/2004 09:37:54 AM,