Re: Please, stop this hurting vendetta, don't you think enough time has passed ?
Sven Luther [EMAIL PROTECTED] wrote: There are two recent events which made me decide to write this mail, and circumvent the ban, which is something which i have not done in over a year. [...] - [...someone] chose to use my name in a contempting way, and nobody thought it worth to critic him. - [an emdebian meeting which] i am not allowed to go is because of the opinion of the DPL about me. This is a slightly modified repost of a DD-only email. If I've got any of this wrong, please contact me off-list. Before commenting, those who can should read the debian-private.200706* archive and familiarise oneself with a sample of the situation (it may become public in 2010-06). Also, I feel http://comments.gmane.org/gmane.linux.debian.devel.project/11951 (about the preceding expulsion) may be relevant. One public announcement of this ban was http://lists.debian.org/debian-powerpc/2007/07/msg00111.html As I understand it: - the ban resulted from commenting prolifically on other developers after being asked to stop by various project organisers. - it was made site-wide and permanent because the poster reacted to being banned on one list by commenting to other lists on the developers involved. - the ban has been lifted one list at a time after a request and the users of that list agreeing when asked. - alternatively, other people can forward acceptable messages from banned people without unusual penalty just because it's from a banned person. However, the OP has just evaded the ban instead of getting someone to resend, so I'm expecting that to have annoyed people, so it's improbable that the -project or -devel bans will be lifted. For the avoidance of doubt: I feel this situation wasn't handled brilliantly, but at least it was handled eventually in a way that has the key features of stated reasons and a possible route back into debian. As to the two recent events mentioned: 1. I don't remember seeing an email using someone's name in that way, else I would have contacted its sender - maybe the sender would like to apologise anyway? 2. I'd like DDs to see a statement of the reason for Sven Luther being denied entry to the emdebian meeting from its organisers, rather than only having one view of the story, but I'm not sure who the organisers are and I didn't find details of the event on d-d-a or http://www.debian.org/events/ - Usually it's not good to publish such things, but the subject has just put it into the public domain anyway. Regards, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
[Let's move this to debian-project since there is no debian-admin-public-bikeshedding. I hope mutt doesn't eat my Mail-Followup-To header.] On Thu, 28 Aug 2008, Peter Palfrader wrote: I generally avoid using password authentication to Debian hosts, *except* in the particular case of scp'ing files from one Debian host to another because That being said we are evaluating means that will allow simple file transfers. So, there are a few ideas floating around: - Tell people to only load the debian.org key into an agent, and use -c when doing that so they have to confirm each use of that key. Then forward that agent to the debian host when they want to copy files. pros: + works right now. + no problems with existing firewalls. cons: - Sure, as if people would ever do that. - install sendfile/saft on all machines so you can do sendfile foo.tar.gz [EMAIL PROTECTED] Unfortunately sendfile doesn't use crypto, so who knows what happens to the stuff you send. And it's yet another network facing server - I don't know if anybody ever did a real audit on it either. Also, I have no idea if it's still actively maintained these days. Lack of crypto seems to suggest that there certainly isn't any new development going on, and hasn't in ages. pros: + simple to use, + easy to implement cons: - no confidentiality, - no integrity checking, - maintainence status? - might cause problems with existing firewalls. The crypto stuff could be alleviated by using ipsec between all our servers. But that works even less well than you'd expect. - use uucp. UUCP stands for Unix to Unix Copy and was built for exactly this purpose. It allows one to copy files to remote systems. We can make it use ssh as a transport so its reasonably secure against non-local adversaries. Unfortunately it stores files in the public spool on the target host, where it can be read by any local user (maybe even copied by remote users using uucp) and overwritten by any remote user using uucp. pros: + probably not hard to use, + not hard to implement + no problems with existing firewalls. cons: - no confidentialy to local users (and local users on peers) - files can be overwritten by other users so you can't be sure you get the file on the target host that you wanted. - progress of copy status is not immediately apparent - setup afs Using AFS would allow us to use a shared /afs/debian.org tree on all our systems. AFS does all the magic crypto stuff so you don't have to worry about Eve sniffing or Mallory tampering with packets. Setting up AFS is a big chunk of work. It would require us first to setup a kerberos realm, to integrate it into ud-ldap so that new krb principals are created with ud-ldap users, and that ud-ldap users can set krb passwords, which probably should be different from their ldap password. On the user side once logged in you'd have to get a kerberos ticket using your krb password, then alog to get access to your /afs/debian.org/transfer/$user or whatever. We will not put homedirs onto AFS (that would completely torpedo the initial goal), it would simply provide a transfer area. pros: + AFS is cool + once we have a krb realm we could maybe also use it for other stuff like all those web services that require logins. How good is krb support in browsers these days? cons: - integrating krb and afs into ud-ldap is a lot of work - setting up afs will be a lot of work too - little prior experience with afs - AFS suffers from the not-a-filesystem syndrome: file access control is not unix-like and will confuse users. - might cause problems with existing firewalls. What other options did we forget? -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please, stop this hurting vendetta, don't you think enough time has passed ?
Hello, Sven Luther was invited to the Extremadura event, and people in the group was asked and nobody was uncomfortable with him, so we (mostly I did) decided it was ok for him to come. After some time it looks like there is some people arround that place by that time that it is not comfortable with him, so we started an argument on if Sven could participate and integrate back into Debian slowly or be excluded by the moment (ever?). DPL made latest decision, whom we should respect. This comment is done to clarify some bits not to start a flame nor to chat about it. Regards -- Héctor Orón -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Sat, Aug 30, 2008 at 02:32:08PM +0200, Peter Palfrader wrote: - install sendfile/saft on all machines so you can do sendfile foo.tar.gz [EMAIL PROTECTED] The crypto stuff could be alleviated by using ipsec between all our servers. But that works even less well than you'd expect. The machines needs to check DNSSEC or the names can be spoofed which makes ipsec mood. - setup afs pros: + AFS is cool Yeah. You can make read-only snapshots for backup purposes. + once we have a krb realm we could maybe also use it for other stuff like all those web services that require logins. How good is krb support in browsers these days? Firefox supports it in a whitelist approach. However I never tested it. cons: - integrating krb and afs into ud-ldap is a lot of work - setting up afs will be a lot of work too - little prior experience with afs - AFS suffers from the not-a-filesystem syndrome: file access control is not unix-like and will confuse users. Also other parts are not really POSIX-like. Hardlinks or so. - might cause problems with existing firewalls. - The needed kernel module still uses rootkit-like behaviour. What other options did we forget? - Setup Kerberos, allow it as an additional ssh login variant + Ticket forwarding However, only the insecure options allow automatic operation, so lets extend some options (yes, I think about the D-I images which are located in people): - Allow additional principals for automatic usage This can be combined with AFS and SSH-Kerberos Each user can create additional principals $USER/cron/[EMAIL PROTECTED], the keys are put into a keyfile so that a script can create a ticket and use that to do the operations. AFS: Just needs proper ACLs for this principal. SSH: Needs mapping in /etc/krb/krb5.conf or .k5login and there was something else. Bastian -- Extreme feminine beauty is always disturbing. -- Spock, The Cloud Minders, stardate 5818.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Sat, Aug 30, 2008 at 03:16:01PM +0200, Bastian Blank wrote: On Sat, Aug 30, 2008 at 02:32:08PM +0200, Peter Palfrader wrote: + once we have a krb realm we could maybe also use it for other stuff like all those web services that require logins. How good is krb support in browsers these days? Firefox supports it in a whitelist approach. However I never tested it. I use Kerberos authentication for my OpenID server, and it works flawlessly with Iceweasel and mod_auth_kerb. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
[Trimming lists] On Sat, 30 Aug 2008, Bastian Blank wrote: On Sat, Aug 30, 2008 at 02:32:08PM +0200, Peter Palfrader wrote: - install sendfile/saft on all machines so you can do sendfile foo.tar.gz [EMAIL PROTECTED] The crypto stuff could be alleviated by using ipsec between all our servers. But that works even less well than you'd expect. The machines needs to check DNSSEC or the names can be spoofed which makes ipsec mood. Or you use only resolvers that you have a trusted (i.e. ipsec) connection to and those need to have a complete axfr'ed zone. As hinted in the original email, I don't think ipsec (or stunnel) are useful solutions to help us make sendfile suck less. - setup afs pros: + AFS is cool Yeah. You can make read-only snapshots for backup purposes. Probably not useful for a transfer share. But if it ever grows beyond that that might be useful. - AFS suffers from the not-a-filesystem syndrome: file access control is not unix-like and will confuse users. Also other parts are not really POSIX-like. Hardlinks or so. Direct consequence of its permission model I'd assume. What other options did we forget? - Setup Kerberos, allow it as an additional ssh login variant Circumvents the entire idea behind this exercise: Assuming an attacker already has control over one host we want to make it as hard as possible for them to jump to other hosts. -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Sat, Aug 30, 2008 at 05:46:16PM +0200, Peter Palfrader wrote: On Sat, 30 Aug 2008, Bastian Blank wrote: On Sat, Aug 30, 2008 at 02:32:08PM +0200, Peter Palfrader wrote: The crypto stuff could be alleviated by using ipsec between all our servers. But that works even less well than you'd expect. The machines needs to check DNSSEC or the names can be spoofed which makes ipsec mood. Or you use only resolvers that you have a trusted (i.e. ipsec) connection to and those need to have a complete axfr'ed zone. Then we can drop the whole ud-ldap thing and use centralized authentication. What other options did we forget? - Setup Kerberos, allow it as an additional ssh login variant Circumvents the entire idea behind this exercise: Assuming an attacker already has control over one host we want to make it as hard as possible for them to jump to other hosts. Nope. It is the same that ssh with key auth. Anything an attacker can get is a short-term secret in form of a forwarded ticket. The service ticket themself is useless for anything else then the direct connection between the user and the server. Bastian -- Too much of anything, even love, isn't necessarily a good thing. -- Kirk, The Trouble with Tribbles, stardate 4525.6 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Sat, 30 Aug 2008, Bastian Blank wrote: Or you use only resolvers that you have a trusted (i.e. ipsec) connection to and those need to have a complete axfr'ed zone. Then we can drop the whole ud-ldap thing and use centralized authentication. Um. I don't see why that follows. I don't think it matters however. :) ipsec/stunnel etc aren't the solution. What other options did we forget? - Setup Kerberos, allow it as an additional ssh login variant Circumvents the entire idea behind this exercise: Assuming an attacker already has control over one host we want to make it as hard as possible for them to jump to other hosts. Nope. It is the same that ssh with key auth. Anything an attacker can get is a short-term secret in form of a forwarded ticket. The service ticket themself is useless for anything else then the direct connection between the user and the server. But it allows them to get a shell on the target server. Even if only for a short term[1]. This means we lose. 1. And more likely the user will fetch a full TGT on the source host when they want to copy stuff to another host since the default mode of login will probably stay ssh keys. -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please, stop this hurting vendetta, don't you think enough time has passed ?
On 30/08/08 at 02:03 +0200, Sven Luther wrote: - in a thread about some guy who chose to hide is name probably to circumvent a similar ban than i am under, and accuse the debian governance of all kind of evil acts, in maybe a clumsy way, Martin Shulze chose to use my name in a contempting way, and nobody thought it worth to critic him. [...] And yes, i made mistakes, numerous mistakes back then, who doesn't make them. I believe that Martin Schulze's email was a mistake, and I also regret that nobody took the time to publicly express his disagreement with what was written. FWIW, I completely agree that using your name in that way was inappropriate, and understand why you felt hurted by that. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Sat, Aug 30, 2008 at 02:32:08PM +0200, Peter Palfrader wrote: - setup afs Using AFS would allow us to use a shared /afs/debian.org tree on all our systems. AFS does all the magic crypto stuff so you don't have to worry about Eve sniffing or Mallory tampering with packets. Setting up AFS is a big chunk of work. It would require us first to setup a kerberos realm, to integrate it into ud-ldap so that new krb principals are created with ud-ldap users, and that ud-ldap users can set krb passwords, which probably should be different from their ldap password. On the user side once logged in you'd have to get a kerberos ticket using your krb password, then alog to get access to your /afs/debian.org/transfer/$user or whatever. We will not put homedirs onto AFS (that would completely torpedo the initial goal), it would simply provide a transfer area. pros: + AFS is cool That's never been a very good reason, IMO. But, hey, I won't deny it, either ;-) + once we have a krb realm we could maybe also use it for other stuff like all those web services that require logins. How good is krb support in browsers these days? Pretty good. Konqueror supports it out of the box, iceweasel only requires you to edit the 'network.negotiate-auth.trusted-uris' about:config variable, and then it works well, too. Dunno about other browsers. (for some infathomable reason, the firefox developers consider Negotiate authentication to be unsafe with untrusted and/or non-SSL hosts. Dunno why that is, and never saw a compelling argument...) -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: transfering files between *.debian.org hosts
* Peter Palfrader: What other options did we forget? Modern NFS over IPsec to a central file server. However, less than stellar bandwidth at the Debian servers requires really, really modern NFS with persistent caching. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Sat, Aug 30, 2008 at 06:48:57PM +0200, Wouter Verhelst wrote: + once we have a krb realm we could maybe also use it for other stuff like all those web services that require logins. How good is krb support in browsers these days? Pretty good. Konqueror supports it out of the box, iceweasel only requires you to edit the 'network.negotiate-auth.trusted-uris' about:config variable, and then it works well, too. Dunno about other browsers. (for some infathomable reason, the firefox developers consider Negotiate authentication to be unsafe with untrusted and/or non-SSL hosts. Dunno why that is, and never saw a compelling argument...) And what do the iceweasel developers think? Perhaps iceweasel could have this enabled by default? (Or are there other negotiations besides Kerberos that are enabled with this setting, which should be avoided?) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Sat, Aug 30, 2008 at 06:48:57PM +0200, Wouter Verhelst wrote: (for some infathomable reason, the firefox developers consider Negotiate authentication to be unsafe with untrusted and/or non-SSL hosts. Dunno why that is, and never saw a compelling argument...) Negotiate auth does not provide confidentiality or integrity protection different to the normal use of kerberos. Bastian -- What kind of love is that? Not to be loved; never to have shown love. -- Commissioner Nancy Hedford, Metamorphosis, stardate 3219.8 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Sat, Aug 30, 2008 at 05:46:16PM +0200, Peter Palfrader wrote: What other options did we forget? - Setup Kerberos, allow it as an additional ssh login variant Circumvents the entire idea behind this exercise: Assuming an attacker already has control over one host we want to make it as hard as possible for them to jump to other hosts. Well, the underlying premise here is, of course, that certain routinely useful capabilities need to be taken out of the hands of the users because they won't use them responsibly[1]. But you haven't yet guarded against an even more irresponsible use of ssh capabilities: - create an ssh key - add the public key to LDAP as an authorized key - install unencrypted copies of the key on every Debian host you can access - add various levels of obfuscation to keep the mean admins from noticing and taking away your access (name the file .cshrc and add an IdentityFile option to .ssh/config, or make an alias for ssh, or make an alias called something /other/ than ssh...) - instant, password-free access from any Debian host to any other Debian host - ... for anyone who has managed to gain access to the account on *any* of the systems. Without them having to catch you logging in first. This is obviously an *incredibly* bad idea for anyone to do if they actually care about the security of the Debian systems. But we're already talking about hard policy changes to stop users from doing things they shouldn't do in the first place (== using passwords when logging in to Debian servers from their systems), so I don't think you should underestimate the capacity of developers to be cleverly stupid when security is concerned. So, given that I don't see a good way for you to prevent the above strategy (or other twisted workarounds that I haven't thought of) without also blocking lots more legitimate uses, I think it's important to ensure that doing things the right way isn't made so difficult that people resort to ad-hoc insecure methods to get things done. Having your inter-host file transfers sandboxed, such that you have to log in to the host on each end in order to get the files copied to the place you want them, would be a serious nuisance, and in particular, it would not allow for good use of rsync as a time- and bandwidth- saving technique. Having to start a separate ssh agent for Debian systems would also not be user-friendly. I think that choosing solutions with either of these features would result in a significant number of users doing less responsible things with their ssh keys in order to get work done. As a result, I don't think you're going to completely eliminate the risk of shell-hopping[2], and therefore the emphasis should be on mitigation, so that the methods people will prefer to use have the least window of exposure. Kerberized ssh with ticket forwarding is one of the better ones in this regard, because it doesn't require typing a password across the wire and the delegated credentials have a limited lifetime. RSA auth forwarding is also good by this standard, because the credentials are only available while the user's initial connection is active and there are methods for requiring user confirmation for each instance of authentication forwarding. Anything that involves sending your password across the wire, or storing RSA keys on the Debian host, is pretty obviously not good. But if you don't find these arguments persuasive, then of the options proposed, I think AFS is the best. (Or you could use Samba with Kerberos sign+seal... :) 1. And more likely the user will fetch a full TGT on the source host when they want to copy stuff to another host since the default mode of login will probably stay ssh keys. Well, a way around that is to not give users kinit on the Debian hosts, and/or implement ACLs on the KDC that prohibit issuing TGTs to Debian hosts. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] [1] or that there is no responsible use for them [2] even if you go the route of requiring confirmation for each use of the ssh agent, your ssh client on the Debian host is not a privileged process, so if someone has compromised your account, they can hijack your connection once it's established... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: transfering files between *.debian.org hosts
Bastian Blank [EMAIL PROTECTED] writes: On Sat, Aug 30, 2008 at 02:32:08PM +0200, Peter Palfrader wrote: - AFS suffers from the not-a-filesystem syndrome: file access control is not unix-like and will confuse users. Also other parts are not really POSIX-like. Hardlinks or so. The three main things that are weird are no hardlinks between directories, directory ACLs rather than file permissions (the group and other mode bits are basically ignored; the directory ACLs are all that matter), and you can mount any AFS volume as a directory under any other AFS volume, so you can get circular file systems. - might cause problems with existing firewalls. - The needed kernel module still uses rootkit-like behaviour. If you mean the system call table modification, this is now strictly optional and AFS works fine without it. It uses keyrings instead of supplemental groups. The supplemental group behavior is preserved where possible for backward compatibility, but the keyring (which was designed specifically for this sort of thing) is now the canonical repository for the PAG. A bigger problem at the kernel level is that the kernel APIs change constantly and have not infrequently had various GPL-only tags added that force OpenAFS into annoying workarounds (it is released under the IBM Public License, another DFSG-free license that isn't quite GPL-compatible). However, for systems that run stable, the corresponding stable release of OpenAFS should continue to work fine. This mostly is a problem if one runs a backported kernel, in which case you'll need a backported OpenAFS as well. I'd certainly be happy to answer questions and help with AFS setup as I have time. I'd love to have a Debian OpenAFS cell. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: transfering files between *.debian.org hosts
Wouter Verhelst [EMAIL PROTECTED] writes: (for some infathomable reason, the firefox developers consider Negotiate authentication to be unsafe with untrusted and/or non-SSL hosts. Dunno why that is, and never saw a compelling argument...) Well, having your browser spontaneously authenticate you to any system keyed in your local realm or in a realm with which you have cross-realm trust is something of a leak of personal information. I can see why they wouldn't want that to happen silently on request. I think the real solution would be to add a drop-down prompt similar to the prompts for pop-up menus and the like for sites that are attempting Negotiate-Auth, rather than just disabling it by default -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Sun, Aug 31, 2008 at 01:16:32AM +0200, Bastian Blank wrote: On Sat, Aug 30, 2008 at 06:48:57PM +0200, Wouter Verhelst wrote: (for some infathomable reason, the firefox developers consider Negotiate authentication to be unsafe with untrusted and/or non-SSL hosts. Dunno why that is, and never saw a compelling argument...) Negotiate auth does not provide confidentiality or integrity protection different to the normal use of kerberos. Well, ok, but you're negotiating *authentication*. Why are confidentiality and integrity protection required for that? Firefox doesn't exactly have HTTP basic auth support disabled by default, either... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
