Subject: (radius) time to finish this already!

From: Randy Bush <[email-masked]>
Date: Thu, 03 Feb 2000 15:45:35 -0800

hellooooo!  how can we finish, declare victory, and move on to a new life?
what can i do to help?

randy

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
Date: Fri, 28 Jan 2000 16:53:07 -0800

the status of drafts is as follows:

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

draft-ietf-radius-tunnel-auth-09.txt
  o iesg has in process

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

draft-ietf-radius-tunnel-acct-05.txt
  o approved by iesg pending security warnings as agreed

draft-ietf-radius-accounting-v2-02.txt
  o normative reference to tunnel-auth, so waiting for the latter to pass

randy

---[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.

---

From: "David Mitton" <[email-masked]>
Date: Fri, 04 Feb 2000 09:59:50 -0500

>        it doesn't, in this case, provide protection from dictionary attacks.

I've had an off-line discussion with Marcus about this, I think we came to 
an understanding between us.
The confusion over term "dictionary attacks" seems profound.

There is nothing proscribed in RADIUS to prevent front door dictionary 
attacks.  The RFCs/drafts do not ever mention keeping state on number of 
attempts, or blacklisting, etc, etc.  These are left to the authentication 
implementation.

In this context, we are referring to a weakness in RADIUS whereas, 
authentication request messages are "secured" based on the shared secret 
and the encrypted contents of the User-Password attribute.  If the 
User-Password attribute is not authenticated in the processing of a 
message, as happens with CHAP, or some compulsory tunnel setups, then the 
knowledge of the secret has not been confirmed.  This opens the door for a 
system with access to the network to send RADIUS packets to the server and 
attempt to guess an account password without knowing a secret.  (actually 
most servers these days will not respond to an unknown client, (also not an 
RFC requirement) but masquerading as a known client could be attempted)

By adding an attribute that both includes an integrity check, and causes 
the secret to be confirmed, and therefore strengthens the security of 
NAS<-->RADIUS-SERVER exchanges in these cases.

         Dave.

---------------------------------------------------------------
David Mitton                                  ESN: 248-4570
Consulting Engineer, Nortel Networks           978-288-4570 Direct
Carrier Packet Solutions, Preside              978-288-3030 FAX
Billerica, MA 01821                     [email-masked]

-

---

From: Randy Bush <[email-masked]>
Date: Fri, 04 Feb 2000 07:20:16 -0800

> an understanding between us.

thank you!

> NAS<-->RADIUS-SERVER exchanges in these cases.

so what is the conclusion?  will marcus un-object, or will the document be
changed?

randy
-

---

From: Paul Krumviede <[email-masked]>
Date: Fri, 04 Feb 2000 14:26:02 -0800

Isn't it true that even in the presence of a User-Password attribute
it isn't possible to distinguish between an invalid password or use
of an invalid secret? I'd not sure that this allows any interesting
attack, but it seems misleading to to suggest that there is any
real authentication of a request.

-paul

--On Friday, 04 February, 2000 09:59 -0500 David Mitton 
<[email-masked]> wrote:

>> 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.
>>
>>     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).
>>
>>        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.
>
> I've had an off-line discussion with Marcus about this, I think we came
> to an understanding between us. The confusion over term "dictionary
> attacks" seems profound.
>
> attempts, or blacklisting, etc, etc.  These are left to the
> authentication implementation.
>
> message, as happens with CHAP, or some compulsory tunnel setups, then
> the knowledge of the secret has not been confirmed.  This opens the door
> for a system with access to the network to send RADIUS packets to the
> server and attempt to guess an account password without knowing a
> secret.  (actually most servers these days will not respond to an
> unknown client, (also not an RFC requirement) but masquerading as a
> known client could be attempted)
>

-

---

From: "David Mitton" <[email-masked]>
Date: Mon, 07 Feb 2000 10:00:36 -0500

Paul,

It's true that if either the password data is incorrect, or the "shared" 
secret used to generate the contents of the User-Password attribute in the 
message is incorrect, that the server cannot tell the difference, and can 
only do one thing, return an Access-Reject.

For the authentication to be made, both have to be correct.
Everything else is a failed attempt.

So I'm not sure what you think is misleading here?

Well, okay, are you really asking about non-User-Password accesses?
And the use of the Signature attribute there?
In that case, only the message content and Secret is being validated.
You're right that there is no password authentication.

But this would typically be used where a Chap challenge/response has done 
it's own obscuring, or in the tunnelling case where we are just the first 
step in multi-phase authentication.

         Dave.

BTW: I didn't participate in the design of this stuff.  I found RADIUS 
pretty much the way it is in 1996 when I joined Xylogics and started 
implementing it as a replacement for our own proprietary AAA protocol.  The 
RADIUS WG was chartered to write the RFC pretty much as-is.  And was 
repeatedly advised by it's then AD and WG Chair to not attempt to make 
significant design changes to the protocol.

Any attempt to do significant revamps of the protocol, like say
draft-ietf-calhoun-enh-radius-00.txt, June-1996, were rejected as working 
group items.

So I can explain how the stuff works within the confines of what has been 
done in the WG since then, but we haven't been allowed (or given much 
incentive) to do much better than that.

-

---

From: Paul Krumviede <[email-masked]>
Date: Wed, 09 Feb 2000 15:10:08 -0800

--On Monday, 07 February, 2000 10:00 -0500 David Mitton 
<[email-masked]> wrote:

> secret used to generate the contents of the User-Password attribute in
> the message is incorrect, that the server cannot tell the difference,
> and can only do one thing, return an Access-Reject.
>

The issue is that I've seen groups that want to raise an alarm
on successive failures. Of course, they want the alarm to be
unambiguous so that it can be dealt with correctly. The question
is, how does one categorize such failures, even if the User-Password
attribute is present? Attempts to guess a password for a particular
account? A user persistently using an incorrect password? A mis-
configured NAS? Or somebody attempting to spoof a NAS? The
latter 2 are a bit easier, as all attempts from that source address
would fail, but this isn't all that reliable in large facilities at 
off-peak
hours.

The concern is simply that people not automatically assume that
a failed authentication attempt, or more particularly a series of
failed attempts, can be reliably determined to fall into any particular
failure category.

> But this would typically be used where a Chap challenge/response has
> done it's own obscuring, or in the tunnelling case where we are just the
> first step in multi-phase authentication.
>
>          Dave.
>
> implementing it as a replacement for our own proprietary AAA protocol.
> The RADIUS WG was chartered to write the RFC pretty much as-is.  And was

I seem to recall quite a few a rounds of this advice :-)

> draft-ietf-calhoun-enh-radius-00.txt, June-1996, were rejected as
> working group items.
>
> So I can explain how the stuff works within the confines of what has
> been done in the WG since then, but we haven't been allowed (or given
> much incentive) to do much better than that.

I know, and I'm not suggesting we do anything other than perhaps
make it explicit that even in the case of use of the User-Password
attribute it isn't clear that a failed authentication is due to a bad
user password or a bad secret (or a broken implementation of
something, but that goes without saying and is beyond the scope
of a spec anyway).

-paul

>>>> 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.
>>>>
>>> attacks.  The RFCs/drafts do not ever mention keeping state on number
>>> of attempts, or blacklisting, etc, etc.  These are left to the
>>> authentication request messages are "secured" based on the shared
>>> secret and the encrypted contents of the User-Password attribute.  If
>>> the User-Password attribute is not authenticated in the processing of a
>>> the knowledge of the secret has not been confirmed.  This opens the
>>> door for a system with access to the network to send RADIUS packets to
>>> the server and attempt to guess an account password without knowing a
>>> By adding an attribute that both includes an integrity check, and
>>> causes the secret to be confirmed, and therefore strengthens the
>>> security of NAS<-->RADIUS-SERVER exchanges in these cases.
>>>
>>>          Dave.
>>>

-

---

From: "David Mitton" <[email-masked]>
Date: Thu, 10 Feb 2000 10:03:37 -0500

Not to continue the issue with respect to the draft, but to offer a 
suggestion to would be server implementors...

At 03:10 PM 2/9/00 -0800, Paul Krumviede wrote:
>would fail, but this isn't all that reliable in large facilities at off-peak
>hours.
>

Given the way RADIUS is, a server implementing user authentication failure 
thresholds should assume each authentication failure is a per user problem 
deal with as per it's policy, assuming/considering that configuration 
failures are rare and quickly dealt with.

To detect configuration failures, the server should keep a simple counter 
of failures per NAS IP address, and if they reach a threshold, raise an 
alert that the secret may be mis-set, or you are under attack.  A paranoid 
server may consider client blacklisting policies too.

         Dave.

<snip>....

-

---

From: Paul Krumviede <[email-masked]>
Date: Thu, 10 Feb 2000 07:29:02 -0800

Your comment is eminently reasonable, with the possible exception of
client black-listing. Given the ease of spoofing source addresses for
protocols on top of IP, that sounds like a recipe for denial of service 
attacks.
In particular, it was the apparent intention of some people to do this that
made this issue stick in my mind at the time and to raise it now.

-paul

--On Thursday, 10 February, 2000 10:03 -0500 David Mitton 
<[email-masked]> wrote:

>>> It's true that if either the password data is incorrect, or the
>>> "shared" secret used to generate the contents of the User-Password
>>> attribute in the message is incorrect, that the server cannot tell the
>>> difference, and can only do one thing, return an Access-Reject.
>>>
>> off-peak hours.
> Given the way RADIUS is, a server implementing user authentication
> failure thresholds should assume each authentication failure is a per
> user problem deal with as per it's policy, assuming/considering that
> configuration failures are rare and quickly dealt with.
>
> To detect configuration failures, the server should keep a simple
> counter of failures per NAS IP address, and if they reach a threshold,
> raise an alert that the secret may be mis-set, or you are under attack.
> A paranoid server may consider client blacklisting policies too.
>
>          Dave.
>
>
> <snip>....

-

---

From: Barry James <[email-masked]>
Date: Thu, 10 Feb 2000 23:00:45 +0000 (GMT)

When a proxy RADIUS receives a User-Name attribute with a realm prefix or
suffix should it forward the request to the appropriate realm server with
the User-Name unmodified (ie still containing the realm information) or
should it strip the realm identifier and only send the username?  Maybe I
missed it, but I didn't see any specific mention of this behavior in the
v2-03 draft.

Thanks,
Barry

Barry L James            | Never doubt that a small group of
IP SWAT                  | thoughtful, committed citizens can
Level 3 Communications   | change the world.  Indeed, it's 
http://www.level3.com    | the only thing that ever has.
Member IEEE, AAAI        | #include <std_disclaimer>

-

---

From: "David Mitton" <[email-masked]>
Date: Fri, 11 Feb 2000 11:55:58 -0500

There is no standard that covers this behavior.
Practically speaking, in my experience, you will want both behaviors 
depending on what the downstream RADIUS server needs. If it is hosting 
multiple realms, it may still want the information to differentiate the 
users itself.  Recommendation: Make it an option.

There is very little in the RADIUS RFCs & drafts that covers proxy 
operation.  You may want to look at RoamOps RFCs and 2607 in particular.

         Dave.

Advisor, Nortel Networks                      978-288-4570 Direct

-