Subject: [eap] RE: Comments on draft-jwalker-eap-archie-00.txt

From: [email-masked] (Walker, Jesse)
Date: Wed, 19 Mar 2003 11:48:20 -0800

Bernard,

Thanks for the comments! Responses below.

> Section 2.1
> 
> The Archie Start message contains a SessionId value which is randomly
> selected. As you may know, IEEE 802.1aaD5 makes it possible for an
> authenticator to initiate with a message other than an
> EAP-Request/Identity.  As I read the draft, EAP Archie does 
> not require an
> EAP-Request/Identity to be sent, and since it is intended as a
> default builtin authentication method, might make use of this 
> facility.
> 
> However as I understand it, the IEEE 802.1aa MIB is adding a 
> variable to
> supply the entire first packet -- this it is not clear 
> whether they have
> left room for variation in the SessionId as required in EAP 
> Archie. I suggest
> reviewing D5 so as to recommend changes to allow Archie-Like 
> protocols to
> function better.

If I understand, you are not suggesting a change in Archie.
 
> Section 4.1
> 
> I think the protocol needs a Message Type (single octet) 
> field. As it is,
> it's no clear how the peers can be clear what message type (Archie
> Request1, Archie Response1, Archie Request2, Archie 
> Response2) is being
> sent, other than by checking the Identifier field.

Fair enough. We will add this in the next version.

> BType
> 
> I don't recommend inventing your own address family registry. 
> Please reuse
> the existing registry (a two octet field) defined by:
> 
> http://www.iana.org/assignments/address-family-numbers

Excellent observation. We will look at this and figure out how to use the
existing registry.
 
> Transport address types

This was meant to be a <IP address, protocol number, port number> triplet.
This was so Archie could be used for other things for applications.
 
> Not sure what these are used for. Can you explain?
> 
> MAC1, MAC2, MAC3
> 
> Maybe this is obvious, but I don't see instructions on what 
> the peer or
> EAP server should do if MAC validation fails. Is this a fatal 
> error, or is
> silent discard the correct behavior?

Yes, I realized this after sending out the draft. I think we need to
silently discard. I have not discussed this with Russ.

-- Jesse

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 19 Mar 2003 19:41:09 -0800 (PST)

> If I understand, you are not suggesting a change in Archie.

Right. Not an Archie issue -- but may be an IEEE 802.1aa issue.

> This was so Archie could be used for other things for applications.

Ah. But the introduction says that Archie is only defined for use with
EAP. So you might describe when the various address families are used. For
example, presumably the IP address family might be used with PANA (where
an IP address is available), but not with 802.11 (where the MAC address is
probably relevant). In PPP, I'd assume that the phone number might be the
correct thing. Laying this out would be helpful -- as well as stating what
the intended use is (such as requiring the AAA server to check the "bound"
client address against the Calling-Station-Id attribute). Presumably if
this check were to fail, some action should be taken (logging, refusing to
bring the link up, etc).

It would also be nice to include a section on "Binding" to describe why
this is important and what attacks it prevents, particularly in roaming
systems. And a similar section on "naming" and why that is important, too.
BTW, I didn't see support for naming in Archie. For example, there has
been speculation that the combination of
Acct-Session-Id/Acct-Multi-Session-Id might be an appropriate key name.