Re: [secdir] SecDir review of draft-ietf-krb-wg-kerberos-referrals-14

Re-tx'ing so the list see the secdir review.

S.

On 09/25/2012 06:13 PM, Yaron Sheffer wrote:
> Nope, but that's per the process described in
> http://trac.tools.ietf.org/area/sec/trac/wiki/SecDirReview. The WG
> chairs are supposedly on the ".all" alias.
> 
> Thanks,
>     Yaron
> 
> On 09/25/2012 07:06 PM, Sean Turner wrote:
>> Did these ever make it to the krb-wg mailing list?
>>
>> spt
>>
>> On 9/23/12 4:46 PM, Yaron Sheffer wrote:
>>> I have reviewed this document as part of the security directorate's
>>> ongoing effort to review all IETF documents being processed by the IESG.
>>> These comments were written primarily for the benefit of the security
>>> area directors.  Document editors and WG chairs should treat these
>>> comments just like any other last call comments.
>>>
>>> This document adds a "referral" mechanism to Kerberos, where a client
>>> (e.g. an end user) can use a generic enterprise-wide name, and have it
>>> mapped to one that is specific to its correct realm; similarly, a
>>> generic name can be used for a service, and the KDC will respond with
>>> the correct principal name (and realm) for the service.
>>>
>>> Summary
>>>
>>> It is obvious that the analysis in the document's Security
>>> Considerations is very thorough. Unfortunately I do not have the
>>> Kerberos expertise (which apparently requires knowledge of specific
>>> implementations' quirky behavior) to determine if all relevant cases
>>> were covered.
>>>
>>> A cursory reading of the Considerations is quite discouraging: several
>>> security mechanisms exist but they are not universally applied, some
>>> implementations do not even follow the base protocol etc. I can only
>>> hope that modern Kerberos implementations have improved in the 11 years
>>> since this protocol first got started.
>>>
>>> Details
>>>
>>> - Sec. 4: "trusted name service" is not well defined. In fact it can be
>>> construed as a euphemism for "enterprise-internal DNS", which is advised
>>> against earlier.
>>> - 4.1, last paragraph: is there no possibility to an "issuing realm" to
>>> "publish" ownership of some resources to the consuming realm, and thus
>>> effectively claim those resources?
>>> - 6. In the authorization ASN.1 snippet, what is the value of MAX?
>>> - 7, first paragraph: when the client sends the request to example.com,
>>> shouldn't it ensure first that it has a pre-existing (pre-configured)
>>> trust relationship with example.com?
>>> - 10: the last paragraph ("Accordingly") is a bit too vague and probably
>>> does not provide implementors with sufficient advice.
>>> - 10: overall it is not clear if this section also applies to caching of
>>> client referrals.
>>> - 11: surprise! FAST (which was an optional SHOULD in Sec. 6) is now a
>>> MUST! Even if it's just FAST negotiation that's a MUST, but FAST itself
>>> (or an equivalent) is just a SHOULD, this still doesn't make a lot of
>>> sense, and should at least be explained.
>>> - 11: this section defines a new structure, but only explains a few of
>>> its members. Please mention where all the other members are defined (RFC
>>> 4120?). By the way, key-expiration is said to be deprecated in RFC 4120,
>>> but what do I know.
>>> - General: the document is said to update RFC 4120. A short section with
>>> a summary of the specific updates would be very useful, so that
>>> implementors can find out if they need to change anything, even if they
>>> do NOT support the Referral functionality. (This is really a shortcoming
>>> of the IETF notion of "RFC X updates RFC Y.")
>>> - Appendix A: in "current implementation", do you mean post-Win 2003?
>>> Please clarify.
>>> - Appendix A: a reference to the MS documentation might be appropriate:
>>> http://msdn.microsoft.com/en-us/library/cc233855(v=prot.13).aspx
>>>
>>> Thanks,
>>>       Yaron
>>>
>>> _______________________________________________
>>> secdir mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/secdir
>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>>>
> _______________________________________________
> secdir mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
> 
> 
_______________________________________________
ietf-krb-wg mailing list
[email protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg