Subject: Re: [Ietf-krb-wg] COMMENT: <draft-ietf-krb-wg-anon-12.txt>

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 08 Oct 2010 11:43:10 -0400

--On Tuesday, October 05, 2010 12:11:24 PM +0100 Ralph Droms 
<[email-masked]> wrote:

>
> On Oct 5, 2010, at 11:52 AM 10/5/10, Jeffrey Hutzelman wrote:
>
>> --On Tuesday, October 05, 2010 03:17:21 AM -0700 Ralph Droms
>> <[email-masked]> wrote:
>>
>>> Comment:
>>> Section 4.2:
>>>
>>>   The TGS SHOULD NOT
>>>   populate identity-based authorization data into an anonymous ticket
>>>   in that such authorization data typically reveals the client's
>>>   identity.
>>>
>>> MUST?  Or, under what conditions can the TGS violate the SHOULD NOT?
>>
>> Presumably, "in particular circumstances when the particular behavior is
>> acceptable or even useful", and where the "full implications" have been
>> "understood and the case carefully weighed" (RFC2119 section 4).
>>
>> Sorry, but I keep seeing this meme that use of SHOULD or SHOULD NOT
>> needs to be accompanied by a description of circumstances under which a
>> behavior other than the recommended one is appropriated; often such
>> claims include an assertion that RFC2119 requires doing so.  This is
>> nonsense; SHOULD and SHOULD NOT are intended for cases where
>> _unforeseen_ circumstances may lead to doing something different.  If we
>> knew what those conditions were, we'd have written "MUST NOT ... except
>> when ..." instead of "SHOULD NOT".
>
> OK...but, in this particular case, it seems important to expand on the
> SHOULD NOT, because - assuming I'm understanding the spec correctly - if
> the TGS does violate the SHOULD NOT, it negates the value of the
> anonymous ticket.

Not necessarily.  Depending on policy, it might be desirable to reveal 
limited information without revealing the client's principal name.

I agree it is worth discussing this further, and am copying the WG list to 
that end.  Hopefully we can agree on something that satisfies your concern.

-- Jeff
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Fri, 08 Oct 2010 21:46:18 -0400

I don't think we're going to get better than a SHOULD NOT on this in any
reasonable time.  If there is some good reason to release the
information.  For example, if you're releasing information on a
particular group that someone is in.  The SAML community has a huge
quantity of mostly implementation-specific policy and advice on this
sort of issue.  I don't think we're going to manage to come up with
something coherent in post-approval handling.  I agree this is an
interesting topic.  I think it would be a great thing to write a paper
or informational RFC (or if you found an answer, BCP) about.  I don't
know how to say anything short about partial release of attribute
information under the control of a trusted third party.

Scott, any thoughts?

---

From: Scott Cantor <[email-masked]>
Date: Fri, 8 Oct 2010 22:19:37 -0400

On Oct 8, 2010, at 9:46 PM, Sam Hartman <[email-masked]> wrote:
> particular group that someone is in.

I would concur that coming up with any rigorous guidance on this is difficult. There are reams written on compromise of anonymity through attribute information, and no algorithm is going to answer that question in the abstract. I think the best you can do is highlight the danger and urge implementers to provide appropriate policy controls when combining anonymous tickets with authorization data.

> The SAML community has a huge
> sort of issue.

Mostly alluding to all the existing literature on this sort of thing.

>  I don't think we're going to manage to come up with

I don't either.

-- Scott

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 26 Oct 2010 13:30:51 -0400

--On Friday, October 08, 2010 10:19:37 PM -0400 Scott Cantor 
<[email-masked]> wrote:

> I would concur that coming up with any rigorous guidance on this is
> difficult. There are reams written on compromise of anonymity through
> attribute information, and no algorithm is going to answer that question
> in the abstract. I think the best you can do is highlight the danger and
> urge implementers to provide appropriate policy controls when combining
> anonymous tickets with authorization data.
>

I don't see anything resembling a consensus to make a change here, and I'm 
inclined to agree with Sam and Scott that coming up with stronger guidance 
is not something that can be done easily or quickly, if at all.  So, I'm 
going to leave the document as-is.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg