RADIUS Extension for Digest Authentication
draft-ietf-radext-digest-auth-09

[Ballot discuss]
I don't think the security considerations surrounding client nonce
generation are correct.  In particular, I believe the security of
digest authentication depends on the server choosing a fresh nonce to
prevent replays.  Take a look at section 3 in
draft-ietf-sasl-rfc2831bis.  In the case where the RADIUS client
chooses the nonce then the RADIUS client is being trusted to avoid
these attacks.  In many environments the load considerations which
seem to be the primary motivation for client nonces in this spec would
not justify that trust.

Please either explain to me why these concerns do not exist or
document them.  If these concerns exist, then please add a
recommendation for server nonces in cases where load is not an issue.

If there are attacks that can be mounted when client nonces are
used,servers need to offer a configuration in which client nonces are
refused; this is not provided by the current server behavior.



I don't believe a normative reference to RFC 3310 is appropriate.  RFC
3310 is very clearly not a standards-track protocol.

[Ballot comment]
Please include an informative reference for CHAP in section 1.3.

  Section 3.1 says:
  >
  > The RADIUS server MAY have added a Digest-Nextnonce attribute into an
  > Access-Accept packet.  If the RADIUS client discovers this, it puts
  > the contents of this attribute into a 'nextnonce' directive.  Now it
  > can send an HTTP-style response.
  >
  Perhaps a better wording might be:
  >
  > When the RADIUS server provides a Digest-Nextnonce attribute in the
  > Access-Accept packet, the RADIUS client puts the contexts of this
  > attribute into a 'nextnonce' directive so that it can send an
  > HTTP-style response.

  Section 4.9 says:
  >
  >4.9.  Digest-Algorithm attribute
  >
  >  Type
  >
  s/Type/Description/

  Section 4.20 says:
  >
  >4.20.  SIP-AOR
  >
  >  Type
  >
  s/Type/Description/

  Section 7 says:
  >
  > A->B
  >
  >    INVITE sip:97226491335@example.com SIP/2.0
  >    Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0"
  >        ,opaque="",realm="example.com"
  >        ,response="f3ce87e6984557cd0fecc26f3c5e97a4"
  >        ,uri="sip:97226491335@10.0.69.38",username="12345678"
  >    From:
  >    To:
  >
  > B->C
  >
  >    Code = 1 (Access-Request)
  >    Attributes:
  >    NAS-IP-Address = a 0 45 26 (10.0.69.38)
  >    NAS-Port-Type = 5 (Virtual)
  >    User-Name = "12345678"
  >    Digest-Response = "f3ce87e6984557cd0fecc26f3c5e97a4"
  >    Digest-Realm = "example.com"
  >    Digest-Nonce = "3bada1a0"
  >    Digest-Method = "INVITE"
  >    Digest-URI = "sip:97226491335@example.com"
  >
  Why is the value of Digest-URI not the same URI provided by A?

[Ballot discuss]
Section 2 says:
  >
  > As there is no automatic capability exchange, the operator MUST
  > make sure that the RADIUS client software uses the correct nonce
  > generation mode when accessing a specific RADIUS server:
  >
  This use of "MUST" does not seem right to me.  The "operator" is a
  human, so it does not seem like a situation covered by RFC 2119.

  Section 3.1 says:
  >
  > It puts the 'response' directive into a Digest-Response attribute
  > and the realm / nonce / digest-uri / qop / algorithm / cnonce / nc /
  > username / opaque directives into the respective Digest-Realm /
  > Digest-Nonce / Digest-URI / Digest-Qop / Digest-Algorithm /
  > Digest-CNonce / Digest-Nonce-Count / Digest-Username / Digest-Opaque
  > attributes.
  >
  What does the slash character (/) signify?  In ABNF, the slash
  character separates choices, but that does not seem to be the right
  context.  I think that "respective" is key to understanding this
  sentence.  Please reword.  I find it very confusing.

  Section 4.2 says:
  >
  > This attribute describes a protection space of the RADIUS server.
  > See [RFC2617] 1.2 for details.  It MUST only be used in Access-Request
  > and Access-Challenge packets.
  >
  Section 1 says that a protection space is the combination of realm and
  digest URI, but this says this text only includes a Realm.  Is this
  attribute used in conjunction with something else to determine the
  protection space?

  Section 4.7 says:
  >
  > If the HTTP-style request has an Authorization header, the RADIUS
  > client puts the value of the "uri" directive in the (known as
  > "digest-uri-value" in section 3.2.2 of [RFC2617]) without quotes
  > into this attribute.
  >
  Are the quote characters removed?  I do not think that is the intended
  meaning.  Perhaps it should say: "without quoting."

IANA Comments:
Upon approval of this document the IANA will assign numerous RADIUS Attribute Type values in the following registry:
http://www.iana.org/assignments/radius-types

The first of the suggested values appears to be already assigned.  Will this cause any issues for the Authors?

[Ballot comment]
Page 26
      NAS-IP-Address = a 0 45 26 (10.0.69.38)
Probably IP address should be changed to be in accordance with
IP addresses for examples (RFC3330), i.e. 192.0.2.0/24 range

[Ballot discuss]
Comments from Glen Zorn:

Although the document goes into great detail about the behavior required from RADIUS clients & servers, it's not at all clear to me how it would work in a proxied network, esp. one supporting roaming.

Basically this doc seems to assume that the RADIUS client is in a realm in which the SIP (for example) user holds valid credentials.  Since I've avoided SIP (& HTTP, for that matter), I can't really say whether that's actually true or not.  Maybe the SIP proxies route requests in that way. 

In any case, there is a more serious flaw in the protocol, in that it seems to perpetuate one of the classic attacks against CHAP w/RADIUS (the attack doesn't work against standalone CHAP).  The attack is enabled by the RADIUS client's generation of challenges & can result in difficult to detect theft of service.  The attack goes like this:

1) Crack the SIP server/RADIUS client, installing a local user (say, AttkVrizn) & modifying the software to keep a small table of valid user names, challenges & responses.
2) Connect to the SIP server as AttkVrizn (possibly authenticating to keep others from poaching).  The RADIUS client then "authenticates" one of the users in the table to the RADIUS server using the stored challenge & response -- if the challenges are just pseudo-random numbers (as specified in this draft), there is no way (short of keeping a list of every challenge it's ever seen) for it to know that the challenges & responses are old.  This will start a session under the victim's name & she will be charged for the service provided to AttkVrizn; the only way I know of to detect it is either through a software audit of the SIP server/RADIUS client or through the victim's diligent monitoring of their bill.

[Ballot discuss]
I don't think the security considerations surrounding client nonce
generation are correct.  In particular, I believe the security of
digest authentication depends on the server choosing a fresh nonce to
prevent replays.  Take a look at section 3 in
draft-ietf-sasl-rfc2831bis.  In the case where the RADIUS client
chooses the nonce then the RADIUS client is being trusted to avoid
these attacks.  In many environments the load considerations which
seem to be the primary motivation for client nonces in this spec would
not justify that trust.

Please either explain to me why these concerns do not exist or
document them.  If these concerns exist, then please add a
recommendation for server nonces in cases where load is not an issue.

If there are attacks that can be mounted when client nonces are
used,servers need to offer a configuration in which client nonces are
refused; this is not provided by the current server behavior.

[Ballot discuss]
The HTTP example in Section 7 shows a WWW-Authenticate header in a 407 response and an Authorization in the reissued GET. Shouldn't a 407 contain a Proxy-Authenticate, and the reissued get a Proxy-Authorization? Or perhaps the authors intended this to be a 401, as the sentence of explanatory text prior to the example does not suggest the presence of a proxy.

[Ballot comment]
The authors might note, contrary to impllication of the motivational text in 1.2, that RFC3261 did not intend to supplant Digest authentication with TLS and S/MIME. Digest is still mandatory and is the preferred way for a UA to authenticate itself to a proxy server. This just furthers the need for this mechanism, of course - the text in 1.2 makes it sound like Digest a legacy mechanism for SIP.

[Ballot comment]
The authors might note, contrary to impllication of the motivational text in 1.2, that RFC3261 did not intend to supplant Digest authentication with TLS and S/MIME. Digest is still mandatory and is the preferred way for a UA to authenticate itself to a proxy server. This just furthers the need for this mechanism, of course - the text in 1.2 makes it sound like Digest a legacy mechanism for SIP.

[Ballot discuss]
Section 4 includes notes to IANA that should probably be included or referenced in the "IANA Considerations" section.  An example:

"[IANA: use 102 if possible]"

It might be helpful to add a sentence to the IANA Considerations section to tell someone to look in section 4 for these requested assignments.  It might also be helpful to be more specific about which registry the values are being assigned to.

[Ballot discuss]
Section 4 includes notes to IANA that should probably be included or referenced in the "IANA Considerations" section.  An example:

"[IANA: use 102 if possible]"

It might be helpul to add a sentence to the IANA Considerations section to tell someome to look in section 4 for these requested assignments.  It might also be helpful to be more specific about which registry the values are being assigned to.