Subject: (radius) Reply Attributes in Access-Reject

From: "Varghese, Joe" <[email-masked]>
Date: Mon, 10 Apr 2000 08:42:04 -0500

Can someone clarify the following:

"It MAY include one or more Reply-Message Attributes with a text message
which the NAS MAY display to the user."

Does this mean that only Attribute 18 (i.e., Reply-Message) should be used,
or *any* attribute could be used, as long as the NAS understands the
meaning?

For our application, we include a Counter value that is used to prevent
replay-attacks (used in a hash of the password and counter). The Counter and
the Hash are forwarded to the Radius server as VSAs. 

To solve the problem of the the counters on the client and server side being
out of synch, I had wanted the Radius server to reply with an Access-Reject
with a counter value (as opposed to a simple Access-Reject) i.e., in the
Access-Reject include a VSA. 

Is this breaking the standard?

joe varghese

--------------------------------
George (Joe) Varghese
[email-masked]
(630) 713-9522

> -----Original Message-----
> From: Darran Potter [mailto:[email-masked]]
> Sent: Friday, April 07, 2000 5:08 AM
> To: Vipin Jain; [email-masked]
> Subject: Re: (radius) Tag field for radius tunnel authentication
> 
> 
> There's a can of worms... This was all gone over last year at 
> quite some length.
> I recall the final text resulting from a compromise. The big 
> problem is backwards
> compatibility. There are some NASs today that still expect a 
> clear text tunnel password.
> 
> ..and in a proxy chain you could get a clear text T-P given 
> back to you... although
> perhaps unlikely.
> 
> 
> Darran
> 
> ----- Original Message ----- 
> From: "Vipin Jain" <[email-masked]>
> To: "'Glen Zorn'" <[email-masked]>; <[email-masked]>
> Sent: 07 April 2000 09:47
> Subject: RE: (radius) Tag field for radius tunnel authentication
> 
> 
> > 
> > Same Draft: draft-ietf-radius-tunnel-auth-09.txt
> > 
> > May I ask the reason for having three different 
> interpretation of "tag"
> > field for various attributes; Three interpretations being:
> > [1] Attributes like Tunnel-Type: if < 32 its part of a tunnel group,
> > otherwise error
> > [2] Attributes like Tunnel-Client-Endpoint: if < 32 its part of a
> > tunnel group, otherwise it is common to all groups
> > [3] Attributes like Tunnel-Password: if <32 its part of a tunnel
> > group, otherwise IGNORE the value of "tag". Why can't it be 
> interpreted as
> > [2]?
> > 
> > thanks for any help!
> > - Vipin
> > 
> > 
> > -
> > 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.
> 
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: "David Mitton" <[email-masked]>
Date: Mon, 10 Apr 2000 10:03:15 -0400

Hi Joe!

         I don't think there is anything wrong with including your VSA (or 
any number of them) in the Access-Reject message.  Just that most other 
standard implementations won't know what to do with those attributes, and 
probably ignore them.  You could make this server function NAS dependent.

         The RFC is explaining the standard behavior for error reporting 
which may include a multi-line text message.  The table 5.44 on pages 
58-59, shows the inclusion rules for each std attribute and message.

         Dave.

>Is this breaking the standard?

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

-

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 10 Apr 2000 11:58:26 -0700

> probably ignore them.  You could make this server function NAS dependent.

In other words: yes, in breaks the standard, but why do you care?
;-)

-