Subject: RE: [eap] draft-aboba-radius-rfc2869bis-22

From: <[email-masked]>
Date: Tue, 12 Aug 2003 15:07:01 +0300

Hi,

There's no ambiguity or circularity because in RADIUS, the Request
Authenticator is just a random number--not a keyed hash over the
packet contents. Thus, when calculating Message-Authenticator for
Access-Requests, we can include it without any circularity problems.

The Response Authenticator (in Access-Challenge/Accept/Reject) 
is a keyed hash, but it's not included when calculating the
Message-Authenticator for responses (the HMAC-MD5 is not 
calculated over "the entire RADIUS packet"; check the 
definition in 2869bis). If it were included, then we would
have some circularity problems, and would have to set 
the field to zero before calculating.

Best regards,
Pasi

> -----Original Message-----
> From: ext Brian Burch [mailto:[email-masked]]
> Sent: Monday, August 11, 2003 6:54 PM
> To: EAP Mailing List
> Subject: [eap] draft-aboba-radius-rfc2869bis-22
> 
> 
> Description of issue: EAP Message Authenticator String 
> description needs clarification
> Submitter name: Brian Burch
> Submitter email address: [email-masked]
> Date first submitted: 11 August 2003
> Reference: 
> Document: RFC 2869bis
> Comment type: Technical
> Priority: 1
> Section: 3.2.  Message-Authenticator - String
>
> Rationale/Explanation of issue: I realise this section has 
> NOT changed significantly between the published RFC and the 
> draft. However, I'm currently working in this area and I 
> cannot derive an unambiguous 
> interpretation of the section from rfc2689bis-22.
>
> Length description of problem:
> There's a semi-recursive problem with this attribute. The EAP 
> Message Authenticator is supposed to digitally sign an entire 
> Radius/EAP packet, but so is the Radius Authenticator. Given 
> that Radius is being used 
> as a "transport mechanism" for EAP, it follows that the 
> Radius Authenticator MUST be the last field computed. In 
> other words, the EAP Message Authenticator MUST be computed 
> over the Radius packet BEFORE 
> the Radius Authenticator is known. Therefore, the EAP Message 
> Authenticator must be computed over an all-zero's Radius 
> Authenticator. This could be stated more clearly.
> 
> Now, we have the same question about the EAP Message 
> Authenticator itself. Do we compute over an all-zero's EAP 
> Message Authenticator, or do we compute over just the Radius 
> Packet BEFORE the Message Authenticator is added? I don't know 
> and I can't tell from the RFC. My guess is the process is as follows:
> 
> 1. Put the EAP Message attribute into the Radius Packet.
> 2. Put an all-zero's EAP Message Authenticator into the Radius Packet.
> 3. Compute the HMAC-MD5 digest for the entire Radius packet, 
> i.e. 
> {RadiusType;RadiusIdentifier;RadiusLength;RadiusRequestAuthent
> icator;Non-EAPRadiusAttributes;EAP-MSG;EAP-Zero-Auth}
> 4. Put the new HMAC-MD5 digest into the string value of the 
> (currently zero) EAP-MessageAuthenticator attribute.
> 5. Compute the RadiusAuthenticator over the entire 
> RadiusPacket (as normal).
> 
> I'm not certain whether my understanding is correct, but a 
> description of this kind is less ambiguous. It would also 
> make the sentence that describes "the message integrity 
> check" much clearer.
> 
> I have the same kind of problem understanding the description 
> of the EAP Message Authenticator within Access-Challenge, 
> etc. Does it mean that I should perform the same process as 
> described above (for a 
> RadiusRequest), but instead of using the all-zero's EAP 
> Message Authenticator, substitute the digest from the 
> original RadiusRequest EAP Message Authenticator? I don't 
> think so, because the RFC says 
> "using the Request-Authenticator" and that means the Radius 
> Authenticator, not the EAP Authenticator. It seems to me that 
> the EAP and Radius Authenticators are being "tangled 
> together" - if true, then logic 
> reponsible for EAP processing would also need to have access 
> to the original Radius packet. This seems to be 
> architecturally undesirable and deserves explanantion if unavoidable.
> 
> I apologise if my email is hard to understand. This is the 
> first time I've tried to contribute to a draft RFC and I am 
> not familiar with the process. If you need more information 
> from me, I'll be pleased to continue the 
> discussion by private email with any interested parties.
> 
> Requested change:
> 1. new preamble/philosphy paragraph.
> 2. reworded RadiusRequest creation paragraph.
> 3. reworded RadiusRequest message integrity check paragraph.
> 4. reworded RadiusResponse/AccessChallenge/RadiusReject 
> creation paragraph.
> 5. reworded RadiusResponse/AccessChallenge/RadiusReject 
> message integrity check paragraph.
> 
> 
> Regards,
> 
> Brian Burch
> [http://www.PingToo.com/]
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap