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

From: Randy Bush <[email-masked]>
Date: Sat, 01 Apr 2000 12:53:28 -0800

i do not know who you are, but, given that the accounting draft is currently
at -05 and is pretty much passed the iesg, i presume you are just someone
with a broken mail system.

randy

> > 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 [email-masked] Fri Jan 28 16:53:41 2000
> From: Randy Bush <[email-masked]>
> To: Matt Holdrege <[email-masked]>
> Cc: [email-masked], [email-masked]
> Subject: Re: (radius) iesg security review of draft-ietf-radius-ext-05.txt
> Message-Id: <[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.