Subject: Re: (radius) iesg security review of draft-ietf-radius-ext-05.txt

From: [email-masked]
Date: Fri, 31 Mar 2000 12:56:43 -0800

> draft-ietf-radius-radius-v2-03.txt
>  o waiting for changes as outlined in carl's message [1] below

I've submitted (today) draft-ietf-radius-radius-v2-04.txt including
this change.

> draft-ietf-radius-ext-05.txt
>  o waiting for response to security review comments [2] below
>  o also would be nice if iana points in [3] were addressed in an iana
>    considerations section or by some other means

I've submitted (today) draft-ietf-radius-ext-06.txt with these two
changes updating draft 05.  Signature has been renamed
Message-Authenticator and the claims about preventing dictionary
attacks clarified to indicate that they do not protect against packet
interception for offline attacks, only against dictionary attacks against
the server itself (using the text suggested on the ietf-radius mailing list
by the person who raised the objection).

An IANA Considerations section has been added as follows (I also
added the same language to the RADIUS Accounting draft):

IANA Considerations

  The Packet Type Codes, Attribute Types, and Attribute Values defined in
  this document are registered by the Internet Assigned Numbers Authority
  (IANA) from the RADIUS name spaces as described in the "IANA
  Considerations" section of [1], in accordance with BCP 26 [10].

[1] refers to the updated RADIUS Draft.

--- Attachment

---

From: Randy Bush <[email-masked]>
Date: Fri, 28 Jan 2000 16:53:07 -0800

---[1]---

From: Carl Rigney <[email-masked]>
Date: Wed, 5 Jan 2000 04:02:01 -0800 (PST)
To: [email-masked]
Subject: (radius) Security Considerations text

Here's the text I plan to put into Security Considerations of the new
RADIUS draft.  The authors for the RADIUS Tunneling draft should insert
similar language (for Tunnel-Password instead of Password) and also
insert an IANA Considerations section into their draft (feel free to
borrow the one from my latest RADIUS draft).  Please make these changes
and submit the update to the Internet-Drafts directory by this Friday
1/7 so things can move along.  I'll have the new RADIUS draft submitted
Wednesday.

  The User-Password hiding mechanism described in Section 5.2 has not
  been subjected to significant amounts of cryptanalysis in the published
  literature.  Some in the IETF community are concerned that this method
  might not provide sufficient confidentiality protection [14] to
  passwords transmitted using RADIUS.  Users should evaluate their threat
  environment and consider whether additional security mechanisms should
  be employed.

[14] Dobbertin, H., "The Status of MD5 After a Recent Attack."
CryptoBytes Vol.2 No.2, Summer 1996.

Suggestions for wordsmithing the language to be more useful are gratefully
accepted, if you send them Wednesday.

---[2]---

Much of my nervousness about cryptographic goop appearing in this draft was
in the section that describes the ARAP authentication protocol.  Since
this is descriptive, rather than prescriptive, I can't really say that
any issue I have with it is meaningful; ARAP isn't our protocol.

Section 5.14 talks about Signature attributes.  Two issues with this:

    1) They're not really signatures, if we want to be precise in our use
       of the language.  A more precise usage would be a MAC (Message
       Authenticator Code).

    2) The draft talks about how this attribute can prevent dictionary
       attacks against CHAP, ARAP or EAP.  I fail to see how it accomplishes
       this.  If I can intercept one of these packets, then I can still
       mount a dictionary attack against a CHAP response, for example, and
       use a front-door attack using the NAS.  That is, I don't need to be
       able to forge NAS<-->RADIUS-SERVER packets in order to sucessfully
       mount a dictionary attack.  While having a cryptographic MAC in the
       NAS<--->RADIUS-SERVER protocol is useful for other very good reasons,
       it doesn't, in this case, provide protection from dictionary attacks.

---[3]---

Rereading all the notes, I now see that there is an IANA
considerations section in draft-ietf-radius-radius-v2-03.txt (coming
down the pipeline) that takes care of much of this. However, they
don't list all the types that have been defined (the IANA site should
do this I guess), rather they just say what is left to assign (which
isn't exactly in sync with what is up on the IANA page).

Seem to me like draft-ietf-radius-ext-05.txt defines a bunch of the
IANA values that are apparently in use, but are not recorded on the
IANA page. It would be good if the document would be clear that IANA
needs to record them.

-30-

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.