Internet Group membership Authentication Protocol (IGAP)
draft-hayashi-igap-03

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 :-)

See Ballot Write-up for my issues.

  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.

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"