Folks, Monday is the deadline for requesting WG sessions at IETF 81: https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi And Monday the 13th is the deadline for BoF requests: http://www.ietf.org/iesg/bof-procedures.html Cheers, S.
Hi, The paper that Sean, Stephen, & PeterSA wrote that was discussed here at the end of april, is published here.. The Need for a Web Security API <http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_28.pdf> slides: <http://www.w3.org/2011/identity-ws/slides/HodgesFarrellTurnerStAndre.pdf> It turns out that at that workshop <http://www.w3.org/2011/identity-ws/agenda.html> the need for such crypto support was mentioned either directly or or tacitly implied by several of the other presenters/authors/participants. So when the workshop was summed up, it was among the proposals with the most interest on the part of those present. See.. The W3C Identity in the Browser workshop: Final Report Rough Notes <http://www.w3.org/2005/Incubator/socialweb/wiki/IdentityBrowser#Final_Report_Rough_Notes> In fact, there's been work going on from time-to-time wrt JavaScript (JS) "native" crypto APIs, and David Dahl (Mozilla) has been working on that of late, and has a prototype. He recently posted the below message to several lists, but the main discussion appears to be occurring on the public-webapps <at> w3.org list. Here's the root of the thread.. Request for feedback: DOMCrypt API proposal http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0795.html(Continue reading)
Hi all, We received a liaison [1] from ITU-T saying they're planning to start a couple of work items on the security of IPv6. As far as we know, they envisage developing a "technical guideline on deploying IPv6" and "Security Management Guideline for implementation of IPv6 environment in telecommunications organizations." Bear in mind that they're just starting so they know about as much as we would just before a BoF or something like that. I think we'd like to respond to them that that's great, and we'll be interested in their results, but can they *please* come back to us before saying something should be changed so's we can talk about it. If you've comments or ideas on that, please respond to this in the next week. At that point, we'll get some help translating this into liaison-speak (thanks Eliot(Continue reading)and send the result to these lists for a quick check before shipping it off to the ITU-T folks. Cheers, S. [1] https://datatracker.ietf.org/liaison/1047/
Hi, RFC 4775 is the process to follow. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: ipv6-bounces <at> ietf.org [mailto:ipv6-bounces <at> ietf.org] On Behalf Of Fred Baker Sent: Saturday, June 04, 2011 11:10 PM To: Stephen Farrell Cc: Turner, Sean P.; v6ops <at> ietf.org; ipv6 <at> ietf.org; saag <at> ietf.org; Eliot Lear Subject: Re: [v6ops] ITU-T SG17 IPv6 security work items liaison On Jun 4, 2011, at 9:53 AM, Stephen Farrell wrote: > I think we'd like to respond to them that that's great, > and we'll be interested in their results, but can they > *please* come back to us before saying something should > be changed so's we can talk about it. That seems like a reasonable proposal. There a, of course, several proposed sets of security guidelines for IPv6 floating in the breeze. If you want my druthers, I would like to see a comprehensive security *architecture*. Steve Kent wrote to me last month, on(Continue reading)
Dear all at http-auth mailing list, (Cc: Peter, Sean, Harry, and related mailing lists subscribers) following the discussions in the Prague http-auth Bar-BoF in March, and the W3C Identity in Browser workshop in the last month, now I would like to re-call the formation of BoF for http-auth in IETF. The workshop was really hot and enjoying, and there were so many useful inputs to both Web community and IETF, I believe. Some materials presented and discussed there are available at <http://www.w3.org/2011/identity-ws/>. # Harry, are the *output* materials of the workshop already available to public? Currently I'm preparing a start-up version of problem statement document and proposed BoF agenda. However, very unfortunately, the last week I had a severe fever heat and could not work well (I'm really sorry about that). I'm going to submit them to the list within two days, and if possible comments to the last version of the agenda proposal, available at <http://www.ietf.org/mail-archive/web/http-auth/current/msg00770.html>, are welcome. I'm currently working based on that. Thanks, Yutaka -- -- Yutaka OIWA, Ph.D. Research Scientist Research Center for Information Security (RCIS) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: <y.oiwa <at> aist.go.jp>, <yutaka <at> oiwa.jp>(Continue reading)
On 05/06/11 21:30, Arturo Servin wrote: > > I do not see why the ITU has to start from zero. What Eliot said. > There are several (or some at least) very good RFC and I+D documents related to IPv6 security. Sure. Feel free to send RFC numbers and we'll include some in the draft response that we'll circulate in a while. (So no need to spam everyone with those, just sending your suggestions to Eliot, Sean and I will be enough.) Thanks, S. > I think we should recommend them to ITU, it is good that they let us know, it would be better if they use our work as a foundation. > > just my 20 cents > -as > > > On 5 Jun 2011, at 00:10, John Leslie wrote: > >> Stephen Farrell <stephen.farrell <at> cs.tcd.ie> wrote: >>> >>> We received a liaison [1] from ITU-T saying they're(Continue reading)
We've not had any takers on this offer. We're still willing to entertain topics. Don't be shy ;) spt On 4/5/11 10:50 AM, Stephen Farrell wrote: > > And while we're filling the saag folder. I'm sure we've all > noted the general warmth with which many saag presentations > have been greeted over the years(Continue reading)
The W3C XML Security Working Group has issued Last Call Working Drafts of XML Signature 2.0 and Canonical XML 2.0. These specifications are intended to address XML-related performance and attack surface issues. Working Drafts here: http://www.w3.org/TR/xmldsig-core2/ http://www.w3.org/TR/xml-c14n2/ While the formal Last Call period has ended on 31 May, the WG is prepared to accept reviews until 5 July. Regards, -- Thomas Roessler, W3C <tlr <at> w3.org> ( <at> roessler)
I've updated the Reverse SSH draft per suggestions:
- now uses IANA-assigned SSH port 22
- now defines proper client and server roles (Reverse SSH client, Reverse SSH server)
- now uses in-band negotiation to automatically authenticate the SSH Server's host key
Key aspects used to achieve this update include:
- contextual awareness to set SSH client/server roles
- definition of a new family of public host key algorithms (hmac-*)
My own thoughts:
- I like how now the host key and MAC algorithm are negotiated for hmac-* use
- I'm glad to find a solution minimizing the impact to existing SSH implementations
Link:
- http://tools.ietf.org/html/draft-kwatsen-reverse-ssh-01
Thanks,
Kent
On Wed, 2011-06-08 at 16:43 -0700, Kent Watsen wrote: > I've updated the Reverse SSH draft per suggestions: > > - now uses IANA-assigned SSH port 22 > - now defines proper client and server roles (Reverse SSH client, Reverse SSH server) So, let's make sure I have this right. A device "calling home" is going to connect to some server on port 22, and expect the server to immediately pick up the role of being an SSH client? How is the server to distinguish between such a device and a normal ssh client being used by an admin who wants to log in to the server? Or by some other protocol that runs over ssh? I'm pretty sure I recall the discussion on this point involving some sort of negotiation, rather than a requirement that both sides know a priori which protocol variant they're going to speak. In fact, I seem to recall der Mouse suggesting use of a pre-kex extension packet to indicate this. > - definition of a new family of public host key algorithms (hmac-*) This is not the way to achieve what you're trying to do. Nor is specifying use of only particular host key algorithms, which rather badly breaks modularity. Further, what you've done doesn't actually buy anything. If the HMAC is precomputed before the device that will act as SSH server is deployed, then there is no operational advantage over X.509 certificates. On the other hand, if the HMAC is computed at the time of the connection, then both the client and server must know the key _and_ there must be a different key for each client/server pair (so(Continue reading)
RSS Feed3 | |
|---|---|
4 | |
39 | |
1 | |
37 | |
12 | |
45 | |
68 | |
7 | |
25 | |
174 | |
107 | |
81 | |
9 | |
36 | |
3 | |
12 | |
9 | |
41 | |
16 | |
18 | |
30 | |
81 | |
43 | |
31 | |
71 | |
30 | |
13 | |
11 | |
22 | |
36 | |
23 | |
5 | |
40 | |
38 | |
16 | |
12 | |
7 | |
17 | |
2 | |
3 | |
3 | |
24 | |
10 | |
1 | |
8 | |
16 | |
6 | |
4 | |
56 | |
84 | |
41 | |
63 | |
110 | |
30 | |
25 | |
14 | |
10 | |
18 | |
4 | |
5 | |
17 | |
37 | |
38 | |
27 | |
41 | |
1 | |
6 | |
29 | |
6 | |
15 | |
33 | |
43 | |
38 | |
6 | |
24 | |
31 | |
23 | |
11 | |
11 | |
2 | |
12 | |
24 | |
4 | |
5 | |
30 | |
8 | |
4 | |
32 | |
6 | |
26 | |
9 | |
23 | |
36 | |
7 | |
56 | |
25 | |
68 | |
3 | |
57 | |
17 | |
42 | |
83 | |
8 | |
8 | |
4 | |
16 |
