Subject: [Tools-team] Agenda for the 14 June 2006 Teleconference

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 14 Jun 2006 17:36:21 +0200

Hi,

Here is the proposed agenda for today's call.

------------------------------------------------------------------------

1. Agenda bashing and comments on previous minutes

2. Status review

   * Dashboard
	- Henrik

   * Issue trackers, Wiki
	- Henrik

   * Review team support tool
	- Tero

   * Draft info draft
	- Alex

   * Meta-information schema
	- Stas

3. Tracker extension specification
	draft-ietf-proto-wgchair-tracker-ext
	draft-ietf-proto-iab-irtf-tracker-ext

4. Google Summer of Code info

5. Any other business

6. Next meeting:

  Teleconference Wednesday 28th of June, 16:00 GMT (same local time
  as today).

------------------------------------------------------------------------
Connection details:

To join the call, dial +1-734-615-7474 and enter PIN 0151989.

One can also join the call by dialling:
 sip:[email-masked]
on a SIP-enabled voice communications client.

If the SIP client cannot dial URLs, you can have the conference
system call you if you have the sip URL for your phone.  Go to
 https://edial.internet2.edu/call/0151989
and type in the URL to your phone, and follow the directions.

_______________________________________________
Tools-team mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tools-team

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 14 Jun 2006 19:58:04 +0300

> 	- Henrik

Some comments about loginmgr.

1) That login manager really needs to require TLS protection, i.e
   mandate that both the forms and the posts are always using TLS.

2) The URL for changing password should only work exactly once, not
   for 24 hours. The problem with 24 hours is that if someone manages
   to get the URL later from my mailbox or some other place he can
   change my password after I changed it. If it works exactly once,
   either I will get error that password has already been changed
   using the URL (i.e. I know there was attacker who stole my URL) or
   the attacker cannot change my password after I have successfully
   changed it. Perhaps storing the used auth sha1sum to some directory
   and checking that it cannot be there before continuing.
-- 
[email-masked]

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 14 Jun 2006 19:39:33 +0200

Hi Tero,

>    mandate that both the forms and the posts are always using TLS.

Yes.  But to do that, I need a proper cert for tools.ietf.org, which
I don't have.  I've been planning to talk with Ray about it for some
time, but no time...  I assume that this has to go through some
entity that can verify that we have a right to get a cert for
tools.ietf.org.   I also wonder if we need separate certs for
tools.ietf.org, www1.tools.ietf.org, www2.tools.ietf.org and www3.tools.ietf.org...

>    and checking that it cannot be there before continuing.

I agree, and this is already on my todo list, but I wanted to get the
base functionality out there first.  This can be accomplished without
changing what I have now, only putting in an additional check in the
script which verifies the hash.

Something else which you haven't mentioned but is also on my todo list
is rate limiting on requesting the mail with a new password URL, so
people can't anonymously annoy others with a stream of mails with
new password URLs.

Thanks for the feedback :-)

	Henrik

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 15 Jun 2006 12:09:17 +0300

> tools.ietf.org, www1.tools.ietf.org, www2.tools.ietf.org and

As datatracker.ietf.org already has certificate, I assume someone
knows how to get one... And yes, you probably need separate
certificates for each host if you want to run separate tasks on each
of them. If they are all identical i.e. referred always as
tools.ietf.org, then one certificate would be enough, but I guess
there will be some services that will be only on the
www1.tools.ietf.org and not on the others. 

> script which verifies the hash.

I that can be quite easily added, by simply adding check after the
auth data checking saying (using /bin/sh syntax as example)

if [ -f "$authfilesdir/$auth" ]
then
	echo "Auth key already used"
	exit 1
else
	# Auth key ok, mark it as used
	touch "$authfilesdir/$auth"
fi

And then put cronscript that will remove all files from the
$authfilesdir/$auth that are older than one day. 

> people can't anonymously annoy others with a stream of mails with

If someone really starts sending thousands of those emails to some
user then he must use quite a lot of his own bandwidth to send those
requests, and after a while the tools.ietf.org machine will get
slow as sending out those emails takes cpu resources...

What you do want to do is to add the information who sent the request
i.e add things like:

----------------------------------------------------------------------
This request was made from 62.61.72.13:57673
Browser Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.7.12) Gecko/20051028
----------------------------------------------------------------------

to the end of the email that is sent to the user when password is
requested. That way user will at least know IP-address who is sending
those requests, and can himself continue pursuing the attacker instead
of asking you to check www-server logs...

I.e. add

echo "This request was made $ENV{'REMOTE_ADDR'}:$ENV{'REMOTE_PORT'}"
echo "Browser $ENV{'HTTP_USER_AGENT'}"

to the end of email.
-- 
[email-masked]

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 15 Jun 2006 11:28:49 +0200

Hi Tero,

on 2006-06-15 11:09 Tero Kivinen said the following:
> knows how to get one...

Oh, I agree.  That won't be the problem, I hope.

> And yes, you probably need separate

Right.

> 	touch "$authfilesdir/$auth"

Sure, straightforward.

> $authfilesdir/$auth that are older than one day. 

Certainly.

> slow as sending out those emails takes cpu resources...

The annoyance value of 50 emails from a source you don't want to block
is considerable - it's not so much a bandwidth issue as an annoyance
issue, and I'd rather prevent that.  Your proposed fix below makes it
possible to pursue the miscreant, but doesn't prevent the annoyance...

> What you do want to do is to add the information who sent the request

Yes, I may add something like this, it may be useful even if I add
rate limiting.

Regards,

	Henrik