RT RT/krbdev.mit.edu: Ticket #7062 PKINIT pa_pk_as_req_draft9 encoding issues Signed in as guest.
[Logout]

[Home] [Search] [Configuration]

[Display] [History] [Basics] [Dates] [People] [Links] [Jumbo]

 
 

 The Basics  
Id
7062
Status
open
Worked
0 min
Priority
0/0
Queue
krb5
 

 Keyword Selections  
Component
Tags
Version_reported
Version_Fixed
Target_Version
 

 Relationships  
Depends on:
Depended on by:
Parents:
Children:

Refers to:
Referred to by:
 
 Dates  
Created: Sun Jan 8 23:29:37 2012
Starts: Not set
Started: Not set
Last Contact: Not set
Due: Not set
Updated: Sat Feb 11 00:29:41 2012 by ghudson
 

 People  
Owner
 Nobody
Requestors
 ghudson@mit.edu
Cc
 
AdminCc
 
 

 More about Greg Hudson  
Comments about this user:
No comment entered about this user
This user's 25 highest priority tickets:
 

History   Display mode: [Brief headers] [Full headers]
      Sun Jan  8 23:29:37 2012  ghudson - Ticket created    
     
Subject: PKINIT pa_pk_as_req_draft9 encoding issues

draft-ietf-cat-kerberos-pk-init-09 defines PA-PK-AS-REQ as:

PA-PK-AS-REQ ::= SEQUENCE {
    signedAuthPack          [0] SignedData
    trustedCertifiers       [1] SEQUENCE OF TrustedCas OPTIONAL,
    kdcCert                 [2] IssuerAndSerialNumber OPTIONAL
    encryptionCert          [3] IssuerAndSerialNumber OPTIONAL
}

Per this spec, all four fields (when present) should have constructed
context-specific tags wrapping universal constructed sequence tags, with
the sequence contents for SignedData and IssuerAndSerialNumber defined
by RFC 2630.

Our encoder for this type generates primitive context tags for the
first, third, and fourth fields, as if the CMS encodings were wrapped in
IMPLICIT OCTET STRING.  (CMS types in PKINIT are actually specified this
way in draft 20 and onward, but not in draft 9.)

Our decoder for this type is not consistent with either the draft or the
encoder.  It expects a primitive context tag for the first field, but
expects a constructed context tag for the third and fourth fields.  It
also expects the fourth field to have the context tag number 2 instead
of 3, which is apparently a typo.

For reference, Heimdal defines its version of the structure as:

PA-PK-AS-REQ-Win2k ::= SEQUENCE {
    signed-auth-pack        [0] IMPLICIT OCTET STRING,
    trusted-certifiers      [2] SEQUENCE OF TrustedCA-Win2k OPTIONAL,
    kdc-cert                [3] IMPLICIT OCTET STRING OPTIONAL,
    encryption-cert         [4] IMPLICIT OCTET STRING OPTIONAL
}

Note that (like us) this definition uses primtive context tags for the
CMS types; unlike us, the tag numbers for the second, third, and fourth
field are shifted upward by one.

The purpose of our draft9 code is to interoperate with Windows 2000, not
to faithfully implement the draft9 spec, so we probably don't want to
change anything without interop testing.  It seems likely that decoding
pa_pk_as_req_draft9 was never tested, so it's probably an unusual case
(Windows 2000 client against MIT KDC).


Download (untitled) 1.9k
      Sat Feb 11 00:29:41 2012  ghudson - Comments added    
     
The PKINIT client code sets the signedAuthPack and kdcCert fields in
draft9 requests before encoding a draft9 PA-PK-AS-REQ.  It contains code
to set the trustedCertifiers field (using, I think, the caName
alternative), but it is #if'd out with the comment "W2K3 KDC doesn't like
this".  There is no code to set the encryptionCert field.

The PKINIT server code (if it was ever tested against Microsoft clients)
only appears to care about the signedAuthPack field of a draft9 request.

Heimdal only ever sets the signedAuthPack field when encoding, and never
attempts to decode a draft9 PA-PK-AS-REQ.  So the apparently shifted
fields in the Heimdal ASN.1 module probably aren't significant.


Download (untitled) 697b