Subject: RE: Review comments on draft-ietf-cat-idup-gss-08.txt

From: Carlisle Adams <[email-masked]>
Date: Tue, 4 Nov 1997 19:57:59 -0500

Hi John, all,

>----------
>From: 	Linn, John[SMTP:[email-masked]]
>Sent: 	Thursday, October 23, 1997 1:07 PM
>To: 	'CAT-WG List'
>Subject: 	Review comments on draft-ietf-cat-idup-gss-08.txt
>
>I've now done a first-pass review of draft-ietf-cat-idup-gss-08.txt, and
>would like to raise some questions and issues on the document and to 
>encourage other CAT-WG members to review and comment as well. 
>
>It's worth noting that the IDUP semantics for GSS_S_CONTINUE_NEEDED 
>status, as defined on page 7, are quite different than the base GSS 
>semantics for this major_status code. In the IDUP definition, this 
>status indicates that the output buffer supplied is too small to hold 
>the generated data.  Given the fact that IDUP's operational environment 
>isn't synchronous with respect to communicating peers in a manner 
>analogous to base GSS, it's not surprising that GSS_S_CONTINUE_NEEDED's 
>interpretation per base GSS isn't applicable.  Given, however, the 
>definition of an IDUP-specific IDUP_S_MORE_DATA_NEEDED code to 
>accommodate an input data continuation case, it seems self-consistent to
>define a complementary IDUP-specific code for the output data 
>continuation case rather than to reinterpret the semantics of 
>GSS_S_CONTINUE_NEEDED.  If future interest were to arise in 
>incorporating IDUP-style data continuation facilities into base GSS, it 
>would be desirable to avoid having to disentangle conflicting 
>GSS_S_CONTINUE_NEEDED semantics at that time.

This is a good point.  I will replace all occurrences of
GSS_S_CONTINUE_NEEDED with IDUP_S_MORE_BUFFER_NEEDED (or something
similar).

>Generally, I found it difficult to grasp the relationships among 
>GSS_S_COMPLETE, GSS_S_CONTINUE_NEEDED, IDUP_S_MORE_DATA_NEEDED, and 
>IDUP_S_MORE_PIDU_NEEDED (which is mentioned on page 8 but not in the SE 
>calls section) status values in terms of which values (or, perhaps, 
>combinations thereof?) are to be returned by which calls under what 
>circumstances and appropriate caller behavior in response thereto.  
>(Until I recognized the use of "complete" as defined in conjunction with
>IDUP_Form_Complete_PDU, I also wondered about the relation between 
>IDUP_S_INCOMPLETE and the above codes; others might or might not share 
>the same confusion.) I believe that some more discussion in this area 
>(some of which might need to be at the per-call level rather than the 
>per-section level, as is done for the GP calls but not the SE or EV 
>calls) clarifying and helpful. 

I will try to add more clarifying text at the per-call level...

>Per Table 1 (starting on p. 6) defining IDUP major_status codes:
>
>- GSS_S_BAD_NAME and GSS_S_BAD_NAMETYPE do not appear.  Given (per sec. 
>1.1.5) IDUP's usage of naming equivalent to base GSS, should they? 

They should be included if they are appropriate error returns for one or
more of the IDUP-specific calls (i.e., not just the calls that are
shared with GSS).  I will look again and fix if necessary.

>- As included in 2078bis, should IDUP adopt GSS_S_BAD_MIC as a 
>preferred alias for GSS_S_BAD_SIG?

Yes.

>- GSS_S_DEFECTIVE_VERIF has no corresponding entry in the base GSS 
>status codes.  Should this be an IDUP-specific major_status? 

I thought I had seen it...  I'll fix this.

>- Per IDUP_S_BAD_ENC_IDU, is this status actually specific just to 
>attempted decryption of encrypted IDUs or does it also apply to 
>attempted integrity verification of received IDUs which may or may 
>not be encrypted?  

It's specific to attempted decryption.

>- (editorial) Per IDUP_S_BAD_TARG_INFO, suggest change from "all the 
>information" to "information provided".

What I was trying to stress here is that *all* of the information is bad
in some way (as opposed to the situation in which *some* of the
information is bad and the rest is fine, in which case call processing
can go ahead).  I'm not sure your suggestion captures this adequately.
I will try to come up with some other wording.

>Per the conformance requirements on p. 12, and the fact (per p. 45) that
>use of GSS_Acquire_cred() is recommended in preference to 
>IDUP_Acquire_cred_with_auth() where possible, would it be reasonable to 
>characterize implementation of IDUP_Acquire_cred_with_auth() as an 
>optional facility in the interests of common credential management, so 
>as to minimize required changes to the credential-related elements of 
>base GSS implementations seeking to incorporate IDUP services?

Yes.

>Also regarding conformance, would it be feasible to state any 
>expectations about what subset of the defined parameter bundles are 
>expected to be supported by IDUP implementations generally, so that 
>callers seeking portability can restrict their usage to service 
>facilities specified within those bundles?

This is a bit difficult since it depends so much on what the mechanisms
are defined to do (i.e., what protection / unprotection capabilities
they have).  The spec. takes what is probably the simplest approach,
which is to make the GP calls themselves optional.  The SE and EV calls
have fairly simple parameter bundles, so I don't think this sort of
profiling activity is necessary for them.

>Per sec. 2.1, I suggest selecting the bit values for IDUP's 
>ENCRYPT_ONLY, DECRYPT_ONLY, SIGN_ONLY, and VERIFY_ONLY cred_usage values
>so that they are non-colliding with base GSS cred_usage values, thereby 
>enabling (for a single credential) indication of its usage both for base
>GSS and for IDUP purposes. 

This sounds fine.  What I was trying to do was to explicitly overlap so
that existing credential management code would acquire credentials that
were useful for *something* in the IDUP environment (as opposed to
nothing).  But I'm happy to change this since your suggestion makes
things clearer anyway.

>Per sec. 2.2.2, PolicyAndTime structure, is an expiration time 
>appropriate in addition to an effectivity time? 

Good question!  I got this structure from Denis; perhaps he can
comment...

>Per sec. 2.3.2, several of the calls carry an OPTIONAL Target_Info_S 
>parameter bundle with the comment that it is to be used only if a 
>separate recipient list is needed for signing.  From the wording, I'm 
>not clear whether the need for such a list is assumed to be application-
>determined, mechanism-prescribed, or either/both of the above; which is 
>it? 

Application-determined.  (The application knows about the intended
targets of the data it wants to send out.)  I will try to clarify this.

>Per sec. 2.3.2.2, in Bad_Target_Name, several of the bad_targ_status 
>values seem to correspond to GSS-level major_status conditions.  Would 
>it be feasible and useful to apply mechanism-independent values at this 
>level of reporting in the interests of application portability across 
>IDUP mechanisms? 

Perhaps these could (and should) be mechanism-independent values, but
they are not GSS-level major_status conditions (because they don't
necessarily impact further processing; they are simply warnings of
specific targets that cannot be used).  Recall, too, that you want one
of these *per* inappropriate target so, again, they can't really be
major_status values.  Thus, I think they are properly minor_status /
informational values, which GSS does not typically define in a
mechanism-independent way.

>Per sec. 2.3.2.8, may both sign_qop_alg_in and sig_token be non-NULL in 
>a single call and, if so, which governs? 

They should not both be non-NULL, but of course you can't *force* an
application to adhere to this.  If they are both non-NULL, sig_token
governs, since this is the token created at protection time and
therefore carries the information needed to unprotect.  sign_qop_alg_in,
on the other hand, may only represent the caller's best guess as to what
algorithm to use to unprotect.

>Sec. 2.3.2.4 (typo): "form a complete evi."

Thanks.  I tried hard to catch all these...

>Per sec. 2.3.5, the prot_oper_id iteration facility provides valuable 
>and useful flexibility.  As I read the text, though, there's a possible 
>implication that any callers of the GP level IDUP_Start_Protect call 
>might have to obtain and employ mechanism-specific information in order 
>to input a sequence of values which is suitable for the mechanism in 
>use.  While some callers may want and need to invoke mechanism-specific 
>controls, others might wish to operate in a portable manner (allowing 
>the underlying mechanism to perform one or more iterated processing 
>stages at its discretion).  Is this behavior obtainable by specifying a 
>NULL Special_Conditions bundle, or a zero INTEGER for prot_oper_id 
>within a non-NULL Special_Conditions bundle? 

The intention is that passing a NULL bundle always specifies default
behavior and is the most portable approach.  Failing that (i.e., if you
need this bundle for some other reason but don't care about
prot_oper_id), your suggestion of passing "0" for prot_oper_id is a good
one.  I will add text to this effect.

>Per secs. 2.4.1-2.4.2 (IDUP_Form_Complete_PIDU), this is an interesting 
>facility.  I suspect that the usage of the term "complete" as defined 
>here (rendering self-sufficient for purposes of verification and 
>unprotection, vs. creation of an intact, self-consistent object) may be 
>surprising to readers; if this is covered in the [ISO/IEC] or other 
>available citation, it might be worth citing it here.  I've a question: 
>if this call completes successfully, is the result presumed to be 
>unprotectable by any entity or, if not, is there a specified means for 
>identifying which entities are to be able to perform the unprotection 
>operation?

Again, I'll let Denis comment on this one (since he convinced me to add
this call to the spec.).  My understanding (with respect to your last
sentence above) is that a "complete" evidence token should be
unprotectable by any entity.  [Denis can correct me if this is wrong.]

John:  thanks again for your comments.  I will issue an updated draft
shortly after the 14th (when the WG Last Call ends) incorporating all
comments received up to that point.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

---

From: Bob Blakley <[email-masked]>
Date: Wed, 5 Nov 1997 14:51:46 -0500

I'm attaching a .PDF file containing the portions of the CORBA security
specification which deal
with non-repudiation; Denis and I (and others) designed these interfaces based
on an earlier
version of IDUP and included an extensive discussion of complete evidence (it
even comes with
a picture!)  Please feel free to cannibalize anything you find useful for
re-absorption into IDUP.

Discussion of complete evidence occurs throughout, but the most relevant
section is on pages 15-60
and 15-61 which describes what is meant by complete evidence and gives an
illustrative example.

Enjoy!!

--bob

Bob Blakley
IBM Lead Security Architect
Voice: +1 (512) 838-8133
Fax:    +1 (512) 838-0156
Post:    11400 Burnet Road, Mail Stop 9134, Austin, TX 78758 USA
Internet: [email-masked]

        [email-masked]
        11/04/97 08:18 PM
Please respond to [email-masked] @ internet

To: [email-masked] @ internet, [email-masked] @ internet
cc:
Subject: RE: Review comments on draft-ietf-cat-idup-gss-08.txt

Hi John, all,

Yes.

Yes.