I don't have time to review the patch but I can talk about anonymous and fast.
Remember that for 1.9, anonymous requires you have a trust anchor and can verify the KDC's certificate. RFc 6112 does talk about a mode where neither side has a key, but that's not implemented yet and will require explicit enablement on the client. As far as FASt is concerned, using an anonymous ticket where you can verify the KDC is fine. See section 5.4.1 in RFc 6113. It's actually also OK to use the mode where you cannot verify the KDC, although that requires more bookkeeping and does not permit all options; the current code does not support that. Presumably though at the same time as anonymous support is added that does not require verifying the KDC, you'd fix FAST to do the bookkeeping: FAST is the only realistic consumer of that anonymous mode. If I were doing something like this I'd try to default to using FAST when possible, because it does provide a significant security benefit. My recommendation would be to have default behavior try to get anonymous TGT; if that succeeds use it as an armor cache. If the KDc supports anonymous but not FAST (don't know anything that does this), then the software will automatically detect FAST is not available. I'd then provide an option to disable anonymous and an option to require it. I'm reasonably sure it's safe to do that; I'm quite sure we'd get feedback fairly quickly from unstable if we got it wrong. When requesting anonymous tickets it's important to make sure that the prompter provided will never invoke the conversation function. If pkinit is not available or if the KDc doesn't have pkinit the current code will ask for a password even for anonymous. I definitely think it would be good to use FAST whenever we can and to try and default toward that. It will help now against MIT, and I know that one of my coauthors on the spec was definitely looking at ways to encourage adoption for their implementation using mechanisms similar to what I'm discussing in this message. --Sam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
