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

From: "Brian Burch" <[email-masked]>
Date: Mon, 11 Aug 2003 16:53:45 +0100 (BST)

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;RadiusRequestAuthenticator;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