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

From: [email-masked] (Bernard Aboba)
Date: Wed, 19 Mar 2003 08:42:24 -0800 (PST)

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.

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.

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

Transport address types

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?

---

From: [email-masked] (Walker, Jesse)
Date: Wed, 19 Mar 2003 21:03:18 -0800

Bernard,

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

Good observations. One of the things I am not clear on is what needs to be
done to make Archie effective with PPP. Your suggestions here look like a
good starting point in sorting that out. Thanks.
 
> 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.

Sounds like another good suggestion, so plan to do something in the next
revision. If you have other suggestions here, please let us know.

-- Jesse