Internet Group membership Authentication Protocol (IGAP)
draft-hayashi-igap-03
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2005-05-26
|
03 | (System) | State Changes to Dead from AD is watching by IESG Secretary |
2004-03-06
|
03 | (System) | Document has expired |
2004-03-05
|
03 | Margaret Cullen | State Changes to AD is watching from DNP-waiting for AD note by Margaret Wasserman |
2004-03-05
|
03 | Margaret Cullen | [Note]: 'Authors are planning to revise document and start mailing list for discussion of this work.' added by Margaret Wasserman |
2004-01-22
|
03 | Amy Vezza | State Changes to DNP-waiting for AD note from IESG Evaluation - Defer by Amy Vezza |
2004-01-20
|
03 | Russ Housley | [Ballot discuss] Recommendadion: Do not publish without significant revision. The use of authenticated group membership is not new, and there seems to be … [Ballot discuss] Recommendadion: Do not publish without significant revision. The use of authenticated group membership is not new, and there seems to be an operational need for it. However, this draft could use some significant improvement. It says: > IGAP employs a user-based authentication model rather than an > authentication model based upon IP address or MAC address. The > benefits of a user-based model are well known: operational simplicity > and flexibility, in particular with respect to adds, moves, and > changes. Just because an userID is used in the authentication does not mean that it is the user that is being authenticated. Assuming that any user process can listen on the multicast group once access is provided, then we are really talking about machine authentication. There can be significant confusion when a lower layer protocol uses an upper layer identity. While this form of layer violation is necessary in some situations, it must be done with care and lots of supportive text to aid implemetors. The latter is clearly missing. Section 3.1 defines use of cleartext password authentication which is mandatory to implement. We are trying to move away from such machanisms. The argument will probably be made that this is a point-to-point link, so it is relatively safe to use plaintext passwords. I disagree. With rampant use of tunneling, almost no point-to-point links remain so. Further, CHAP is widely implemented, so requiring it is not an imposition. RADIUS is likely to be used as the AAA protocol to carry the AAA data, the RADIUS User-Password hiding mechanism has known vulnerabilities that can result in exposure of the key stream. Since all RADIUS servers support CHAP, there is no reason to be permit cleartext passwords. Section 3.4.2 does not describe retransmission or failover procedures for accounting. As a result, it seems like the accounting protocol will not be adequately reliable. Section 4 is a skeletal security considerations section. It appears that IGAP packets are not integrity protected, which is very big issue. |
2004-01-20
|
03 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded for Russ Housley by Russ Housley |
2004-01-09
|
03 | (System) | Removed from agenda for telechat - 2004-01-08 |
2004-01-08
|
03 | Bert Wijnen | [Ballot discuss] From OPS DIrectorate Review (Pekka): As the techinical issues have already be raised, I don't bother with that again; there has been significant … [Ballot discuss] From OPS DIrectorate Review (Pekka): As the techinical issues have already be raised, I don't bother with that again; there has been significant pushback for something like this in those WGs, and if this goes forward, rather strong IESG notes would be needed. Two comments: - the document is pertinent to IGMPv2, which has already been obsoleted. - some work is (a bit) similar to what others have proposed: draft-lehtonen-mboned-mcop-operation-01 draft-vatiainen-mcop-cops-01 ... but I'm not sure if this is the right way either. Perhaps this issue has been beaten to death multiple times, and it would be waste of energy to do something like that, but maybe a BOF on group membership authorization etc. could be useful to gain some consensus on these issues. (Maybe one could also consider if there is a problem with the MSEC work which is also on the agenda for this telechat :-) |
2004-01-08
|
03 | Bert Wijnen | [Ballot Position Update] New position, Discuss, has been recorded for Bert Wijnen by Bert Wijnen |
2004-01-08
|
03 | Margaret Cullen | [Ballot discuss] See Ballot Write-up for my issues. |
2004-01-08
|
03 | Margaret Cullen | [Ballot Position Update] Position for Margaret Wasserman has been changed to Discuss from Yes by Margaret Wasserman |
2004-01-08
|
03 | Russ Housley | State Changes to IESG Evaluation - Defer from IESG Evaluation by Russ Housley |
2004-01-08
|
03 | Ted Hardie | [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie |
2004-01-07
|
03 | Steven Bellovin | [Ballot discuss] The functionality that IGAP aims to provide is very much needed. However, the current protocol is inadequate. I urge the authors to develop … [Ballot discuss] The functionality that IGAP aims to provide is very much needed. However, the current protocol is inadequate. I urge the authors to develop a proper solution -- possibly via a working group -- and submit it as standards track. The problem is IGAP is single-level -- the first-hop router has to have the IGAP functionality. But that's wrong -- IGAP often needs to be done at the administrative boundary between the charging service provider and the site's distribution network. There's no mechanism here for propagating an IGAP account upstream; at best, each router along the path has to use its own credentials. This is a very bad environment for plaintext passwords. I note that IETF standards require a mandatory-to-implement authentication mechanism other than plaintext passwords. 3.2.1: Basic Leave is an invitation to DoS attacks 3.2.2: the mechanism for calculating the challenge response is not described. Where, for that matter, is the challenge? In the Message field of the Challenge-Response Mechanism Challenge message? Say so. Later parts of the doucment imply that CHAP is used as-is. Say so here. But CHAP isn't a great choice; we have better technology today. A better scheme would be to calculate the HMAC of the challenge. The corresponding Leave message could then send the HMAC of (challenge-1) or some such, thus avoiding an extra round trip. 3.4.1: "the Max Resp Time field MUST be ignored by the receiver" |
2004-01-07
|
03 | Steven Bellovin | [Ballot Position Update] New position, Discuss, has been recorded for Steve Bellovin by Steve Bellovin |
2004-01-06
|
03 | Ned Freed | [Ballot comment] No copyright or IPR boilerplate 26 doc probably needs TOC |
2004-01-06
|
03 | Ned Freed | [Ballot Position Update] New position, No Objection, has been recorded for Ned Freed by Ned Freed |
2004-01-06
|
03 | Margaret Cullen | [Ballot Position Update] New position, Yes, has been recorded for Margaret Wasserman |
2004-01-06
|
03 | Margaret Cullen | Ballot has been issued by Margaret Wasserman |
2004-01-06
|
03 | Margaret Cullen | Created "Approve" ballot |
2004-01-06
|
03 | (System) | Ballot writeup text was added |
2004-01-06
|
03 | (System) | Last call text was added |
2004-01-06
|
03 | (System) | Ballot approval text was added |
2003-12-26
|
03 | Margaret Cullen | State Changes to IESG Evaluation from AD Evaluation::External Party by Margaret Wasserman |
2003-12-26
|
03 | Margaret Cullen | Placed on agenda for telechat - 2004-01-08 by Margaret Wasserman |
2003-12-26
|
03 | Margaret Cullen | [Note]: 'Checked with magma and msec groups -- no obvious overlap, but there are several serious technical/security concerns with the contents.' added by Margaret Wasserman |
2003-11-27
|
03 | Margaret Cullen | State Changes to AD Evaluation::External Party from AD Evaluation::Revised ID Needed by Margaret Wasserman |
2003-11-19
|
03 | Margaret Cullen | [Note]: 'Pending response from MAGMA chairs regarding technical issues.' has been cleared by Margaret Wasserman |
2003-11-19
|
03 | Margaret Cullen | Discussing document with msec chairs, due to apparent overlap with work underway in msec. |
2003-11-13
|
03 | Margaret Cullen | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::External Party by Margaret Wasserman |
2003-10-23
|
03 | Margaret Cullen | State Changes to AD Evaluation::External Party from AD Evaluation by Margaret Wasserman |
2003-10-23
|
03 | Margaret Cullen | [Note]: 'Pending response from MAGMA chairs regarding technical issues.' added by Margaret Wasserman |
2003-09-24
|
03 | Margaret Cullen | State Changes to AD Evaluation from Publication Requested by Margaret Wasserman |
2003-09-22
|
03 | Margaret Cullen | Area acronymn has been changed to int from gen |
2003-09-22
|
03 | Margaret Cullen | Removed from agenda for telechat - 2003-10-02 by Margaret Wasserman |
2003-09-22
|
03 | Margaret Cullen | Shepherding AD has been changed to Margaret Wasserman from Harald Alvestrand |
2003-09-22
|
03 | Natalia Syracuse | Draft Added by Natalia Syracuse |
2003-08-18
|
03 | (System) | New version available: draft-hayashi-igap-03.txt |
2003-05-29
|
02 | (System) | New version available: draft-hayashi-igap-02.txt |
2003-03-07
|
01 | (System) | New version available: draft-hayashi-igap-01.txt |
2002-10-30
|
00 | (System) | New version available: draft-hayashi-igap-00.txt |