Intrusion Detection Message Exchange Requirements
draft-ietf-idwg-requirements-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2007-03-12
|
10 | (System) | This was part of a ballot set with: draft-ietf-idwg-beep-idxp |
2007-03-12
|
10 | (System) | Ballot writeup text was added |
2007-03-12
|
10 | (System) | Ballot approval text was added |
2004-05-12
|
10 | Amy Vezza | State Changes to RFC Ed Queue from RFC Published by Amy Vezza |
2004-05-12
|
10 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
2004-04-06
|
10 | Harald Alvestrand | State Changes to RFC Ed Queue from RFC Published by Harald Alvestrand |
2003-10-22
|
10 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
2002-12-12
|
10 | (System) | IESG has approved the document |
2002-10-22
|
10 | (System) | New version available: draft-ietf-idwg-requirements-10.txt |
2002-09-27
|
10 | Jeffrey Schiller | Draft Added by schiller |
2002-09-27
|
10 | Jeffrey Schiller | Assigned to has been changed to schiller from bellovin by schiller |
2002-09-25
|
10 | Steven Bellovin | responsible has been changed to IESG as a whole from Author |
2002-09-25
|
10 | Steven Bellovin | State Changes to IESG Evaluation -- 0 from AD Evaluation -- External Party by bellovin |
2002-09-25
|
09 | (System) | New version available: draft-ietf-idwg-requirements-09.txt |
2002-09-24
|
10 | Steven Bellovin | responsible has been changed to Author from Responsible AD |
2002-09-24
|
10 | Steven Bellovin | The nits... (a) the null entries and Rationale entries in the ToC should be deleted (or add titles for all those null subsections, (b) Security … The nits... (a) the null entries and Rationale entries in the ToC should be deleted (or add titles for all those null subsections, (b) Security Considerations is a numbered section, and (c) that section should say that Section 5 lists the security requirements for the eventual protocols. More substantively, Section 5.6 calls for "non-repudiation". Do you really mean that? "Non-repudiation", roughly speaking, means "I can prove to the judge that you said this". In other words, it only applies when you have to invoke a third party. The only way to do non-repudiation is to digitally sign each message. You can't do it with transport-level security mechanisms like TLS -- the only non-repudiation there is "so-and-so participated in the key negotiation", because the quantity that's digitally signed is some intermediate steps in the key exchange dialog. You can't prove to the judge that a given party sent a TLS message, because two parties have the necessary keys. Given that Section 5.5 already covers integrity, I suspect that what 5.6 is getting at is per-source authentication, which in turn implies per-source keying. If so, better text would be something like "The IDP MUST support separate authentication keys for each sender. If symmetric algorithms are used, these keys would need be known to the manager it is communicating with." Note that there may be a conflict here with 4.2, since post-aggregation there is no way to preserve the per-source authenticitation if you don't trust the aggregator. Digital signatures would solve that problem, but they're considerably more expensive to compute and verify. But that tradeoff is the WG's call. |
2002-09-24
|
10 | Steven Bellovin | A new comment added by bellovin |
2002-09-24
|
10 | Steven Bellovin | State Changes to AD Evaluation -- External Party from AD Evaluation by bellovin |
2002-09-23
|
10 | Steven Bellovin | I'm ready to add it to the reading list, though I'm going to tell the authors that (a) the null entries and Rationale entries in … I'm ready to add it to the reading list, though I'm going to tell the authors that (a) the null entries and Rationale entries in the ToC should be deleted, (b) Security Considerations is a numbered section, and (c) that section should say that Section 5 lists the security requirements for the eventual protocols. |
2002-09-23
|
10 | Steven Bellovin | A new comment added by bellovin |
2002-08-27
|
08 | (System) | New version available: draft-ietf-idwg-requirements-08.txt |
2002-08-01
|
10 | Steven Bellovin | responsible has been changed to Responsible AD from |
2002-08-01
|
10 | Steven Bellovin | State Changes to AD Evaluation from Requested … State Changes to AD Evaluation from Requested by bellovin |
2002-06-25
|
07 | (System) | New version available: draft-ietf-idwg-requirements-07.txt |
2002-05-08
|
10 | Jacqueline Hargest | Assigned to has been changed to bellovin from members by jhargest |
2002-02-04
|
06 | (System) | New version available: draft-ietf-idwg-requirements-06.txt |
2001-02-20
|
05 | (System) | New version available: draft-ietf-idwg-requirements-05.txt |
2001-01-03
|
04 | (System) | New version available: draft-ietf-idwg-requirements-04.txt |
1999-10-26
|
02 | (System) | New version available: draft-ietf-idwg-requirements-02.txt |
1999-09-16
|
01 | (System) | New version available: draft-ietf-idwg-requirements-01.txt |
1999-06-25
|
00 | (System) | New version available: draft-ietf-idwg-requirements-00.txt |