Subject: [kitten] Fwd: RE: [Editorial Errata Reported] RFC2743 (2758)

From: Stephen Farrell <[email-masked]>
Date: Wed, 06 Apr 2011 13:19:19 +0100

Hi all,

Martin filed an erratum on gssapi and John agrees that its
correct, so I plan to approve and mark it as "hold for
document update" tomorrow.

Yell if that's wrong.
Thanks,
S.

-------- Original Message --------
Subject: RE: [Editorial Errata Reported] RFC2743 (2758)
Date: Wed, 6 Apr 2011 08:12:56 -0400
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
CC: <[email-masked]>, <[email-masked]>, <[email-masked]>

My understanding at this point is that Martin's erratum is correct as
written, and that it should be taken into account if and when RFC-2743
is revised under kitten wg auspices.  I haven't been involved in kitten
wg discussion, however, and don't know whether any rationale has been
raised there which might modify this conclusion.

--jl

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Wednesday, April 06, 2011 7:14 AM
To: Linn, John; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Editorial Errata Reported] RFC2743 (2758)

Martin, John,

Do you have consensus on whether I ought approve this erratum or
not, or if the text describing the issue needs changing? Or, do
we need to ask the kitten wg about it?

If approved, I assume the right thing here is hold-for-document
update?

Thanks,
Stephen.

On 01/04/11 19:33, [email-masked] wrote:
> Greetings, Martin. 
> 
> It seems to me that the text in RFC-2743, 2.1.4, in the description of GSS_S_COMPLETE status: "that the resulting credential from GSS_Add_cred() is ... suitable for the usage requested in cred_usage" is consistent with your erratum about a returned cred_usage value.  If the available cred_usage doesn't match the set requested, then the call would fail with some status other than GSS_S_COMPLETE. So, I'm not now seeing the need for such an output value. I'd expect that the bindings spec would have inherited that behavior by reference, rather than defining it differently, but could again be surprised. Does any subsequent work in Kitten speak to this question?  
> 
> --jl
> 
> -----Original Message-----
> From: Martin Rex [mailto:[email-masked]] 
> Sent: Friday, April 01, 2011 1:48 PM
> To: Linn, John
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Editorial Errata Reported] RFC2743 (2758)
> 
> Hi John,
> 
> [email-masked] wrote:
>>
>> This is an interesting surprise after 11 years. I haven't been involved
>> with GSS-API implementations recently, and don't know whether any
>> deployments actually output cred_usage and/or mech_set as described.
>> That said, it does appear (per RFC-2743, 2.1.4, and without now
>> reviewing broader context) that mech_set would be redundant given
>> actual_mechs, and that a cred_usage output would be redundant given
>> that GSS_S_COMPLETE status asserts that the requested input
>> cred_usage choices are available. 
> 
> What I've reported is a difference between GSS-API high-leval (rfc2743)
> and GSS-API C-Bindings (rfc2744).
> 
> But after searching through my CAT archives, I found the following
> discussion refering to a cred_usage output parameter for gss_add_cred()
> 
>   From:  Carlisle Adams <[email-masked]>
>   To: <[email-masked]>, Graham Bland <[email-masked]>
>   Subject: RE: GSS and IDUP
>   Date: Mon, 23 Mar 1998 18:20:50 -0500
>   Message-Id: <c=CA%a=_%p=NorTel_Secure_Ne%l=[email-masked]>
> 
>   =Credentials and Usage
>   = ----------------------------------
>   =1.
>   =The GSS C Bindings define 'cred_usage' as input only for both
>   =gss_acquire_cred and gss_add_cred. It does not comment on what should
>   =happen if only a subset of the usage is available (e.g, if BOTH is
>   =requested and only INITIATE is available, should that generate a
>   =GSS_C_NO_CRED?).
> 
>   (This is a GSS C-bindings issue.)
> 
>   =Thus, both acquire_cred and add_cred should have 'actual_cred_usage' output
>   =parameters.  The latter is a change to the c-bindings only, bringing it in
>   =line with the GSS spec, the former deviates from both.  However without some
>   =sort of resolution in this area, any application that wishes use GSS and
>   =IDUP would have to maintain separate credentials for each, negating much of
>   =the value of a core set of credential management functions.
> 
>   Done (see p.44).
> 
> And GSS-IDUP has an acquire_cred (not add_cred) call with seperate
> cred_usage input and output parameters:
> 
>   http://tools.ietf.org/html/rfc2479#page-49
> 
> 
> The purpose of mech_set in presence of actual_mechs seems less clear.
> 
> -Martin
> 
> 
> 
>> -----Original Message-----
>> From: RFC Errata System [mailto:[email-masked]] 
>> Sent: Tuesday, March 29, 2011 6:22 PM
>> To: [email-masked]; [email-masked]; [email-masked]; Linn, John
>> Cc: [email-masked]; [email-masked]
>> Subject: [Editorial Errata Reported] RFC2743 (2758)
>>
>>
>> The following errata report has been submitted for RFC2743,
>> "Generic Security Service Application Program Interface Version 2, Update 1".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=2743&eid=2758
>>
>> --------------------------------------
>> Type: Editorial
>> Reported by: Martin Rex <[email-masked]>
>>
>> Section: 2.1.4
>>
>> Original Text
>> -------------
>>    o  actual_mechs SET OF OBJECT IDENTIFIER, -- if returned, caller must
>>    -- release with GSS_Release_oid_set()
>>
>>    o  initiator_time_rec INTEGER -- in seconds, or reserved value for
>>    -- INDEFINITE
>>
>>    o  acceptor_time_rec INTEGER -- in seconds, or reserved value for
>>    -- INDEFINITE
>>
>>    o  cred_usage INTEGER, -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
>>    -- 2=ACCEPT-ONLY
>>
>>    o  mech_set SET OF OBJECT IDENTIFIER -- full set of mechanisms
>>    -- supported by resulting credential.
>>
>>    Return major_status codes:
>>
>>
>> Corrected Text
>> --------------
>>    o  actual_mechs SET OF OBJECT IDENTIFIER, -- full set of mechanisms
>>    -- supported by resulting credential.  If returned, caller must
>>    -- release with GSS_Release_oid_set()
>>
>>    o  initiator_time_rec INTEGER -- in seconds, or reserved value for
>>    -- INDEFINITE
>>
>>    o  acceptor_time_rec INTEGER -- in seconds, or reserved value for
>>    -- INDEFINITE
>>
>>    Return major_status codes:
>>
>>
>> Notes
>> -----
>> There appears to be accidentally duplicated text trailing the list of output parameters in section 2.1.4:  GSS_Add_cred call  (top of page 38).
>>
>> The parameter "cred_usage" is an input-only parameter and also listed under input parameters, and the parameter "mech_set" is a duplicate of the actual_mechs output parameter.  Compare GSS-API C-Bindings document rfc2744, section 5.3. gss_add_cred
>>
>> -Martin
>>
>> Instructions:
>> -------------
>> This errata is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party (IESG)
>> can log in to change the status and edit the report, if necessary. 
>>
>> --------------------------------------
>> RFC2743 (draft-ietf-cat-rfc2078bis-08)
>> --------------------------------------
>> Title               : Generic Security Service Application Program Interface Version 2, Update 1
>> Publication Date    : January 2000
>> Author(s)           : J. Linn
>> Category            : PROPOSED STANDARD
>> Source              : Common Authentication Technology
>> Area                : Security
>> Stream              : IETF
>> Verifying Party     : IESG
>>
>>
>>
> 
>