Date: Mon, 11 Nov 2013 23:11:13 -0500 (EST)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Jeffrey Hutzelman <jhutz@cmu.edu>
In-Reply-To: <1384212058.31412.41.camel@minbar.fac.cs.cmu.edu>
Message-ID: <alpine.GSO.1.10.1311112304380.4934@multics.mit.edu>
References: <3952_1383839837_rA7FvGqv007407_ldvd2mcdx2s.fsf@cathode-dark-space.mit.edu>
 <1384206692.31412.2.camel@minbar.fac.cs.cmu.edu>
 <10051_1384210008_rABMklPw010752_52815E37.9020109@mit.edu>
 <1384212058.31412.41.camel@minbar.fac.cs.cmu.edu>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: kitten@ietf.org
Subject: Re: [kitten] CAMMAC open issues
Precedence: list

On Mon, 11 Nov 2013, Jeffrey Hutzelman wrote:

> On Mon, 2013-11-11 at 17:46 -0500, Greg Hudson wrote:
>> On 11/11/2013 04:51 PM, Jeffrey Hutzelman wrote:
>>> I fail to see how these are alternatives.  As a wrapper, AD-IF-RELEVANT
>>> has special semantics which nullify the criticality of the element it
>>> wraps.  AD-KDCIssued does not have this property.
>>
>> My reading of RFC 4120 section 5.2.6.2 is that AD-KDCIssued authdata are
>> implicitly non-critical.  The text isn't as precise as I would like, but:
>>
>> * "The KDC-issued ad-data field is intended to provide a means for...
>> positive authorization...".
>
> Not relevant.

It seems relevant in a circumstantial way, in that there is not a security 
risk from ignoring unknown positive authorization data in the way that 
there is for ignoring unknown negative authorization data.

>> * "This element and the elements it encapsulates MAY safely be ignored
>> by applications, application servers, and KDCs that do not implement
>> this element."
>
> I somehow missed this.  In which case, yes, wrapping in AD-KDCIssued
> would indeed obviate the need to wrap in AD-IF-RELEVANT.  However, that
> means that wrapping in AD-KDCissued is not a substitute for using the
> svc-verifier, since the former carries semantics affecting criticality.
> If we drop svc-verifier, then there is no way to issue credentials
> containing AD that is both authenticated and critical!
>
> IMHO, we should simply note that most already-deployed services will not
> understand AD-CAMMAC, and specify that it SHOULD be enclosed in
> AD-IF-RELEVANT unless it contains authorization data which is critical
> with respect to the service or some principal named in other-verifiers.

Do we anticipate there ever being such critical data?  It seems like it 
would be simpler if we could specify that it is always AD-IF-RELEVANT.

> Probably we should also indicate that AD-CAMMAC-BINDING SHOULD be
> enclosed in AD-IF-RELEVANT unless the containing AD-CAMMAC is already so
> wrapped, and modify the text so that an AD-CAMMAC whose first element is
> an AD-IF-RELEVANT wrapping AD-CAMMAC-BINDING is permissible.

It's not immediately clear to me why, if the contents are just an OCTET 
STRING.

> Incidentally, it's not clear that wrapping AD-CAMMAC in AD-IF-RELEVANT
> automatically confers full non-criticality on all of the wrapped
> elements!  The definition of AD-IF-RELEVANT in RFC4120 5.2.6.1 is
> ambiguous in this respect.  It may be desirable to clarify that if a

Ugh.

-Ben