Joseph Salowey (jsalowey | 2 Apr 17:17 2007
Picon

Comments on draft-ietf-eap-netsel-problem-06.txt

I've taken a look at the draft and the one concern I have is that it
seems that security considerations are discussed rather lightly.  In
particular they are not discussed in the design considerations.

In the discussion of AAA routing it would be good to have more
discussion of the trust relationships required between AAA systems.
There is also little discussion of authenticating the network and/or
realm that is being accessed or determining that the network is
authorized to provide the services which it may claim to provide.  

Joe
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

Bernard Aboba | 2 Apr 21:12 2007
Picon

Re: Comments on draft-ietf-eap-netsel-problem-06.txt

Do you have any specific changes to propose?

>From: "Joseph Salowey (jsalowey)" <jsalowey <at> cisco.com>
>To: <eap <at> frascone.com>
>Subject: [eap] Comments on draft-ietf-eap-netsel-problem-06.txt
>Date: Mon, 2 Apr 2007 08:17:35 -0700
>
>I've taken a look at the draft and the one concern I have is that it
>seems that security considerations are discussed rather lightly.  In
>particular they are not discussed in the design considerations.
>
>In the discussion of AAA routing it would be good to have more
>discussion of the trust relationships required between AAA systems.
>There is also little discussion of authenticating the network and/or
>realm that is being accessed or determining that the network is
>authorized to provide the services which it may claim to provide.
>
>Joe
>_________________________________________________________________
>To unsubscribe or modify your subscription options, please visit:
>http://lists.frascone.com/mailman/listinfo/eap
>
>Arhives: http://lists.frascone.com/pipermail/eap

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

(Continue reading)

Bernard Aboba | 7 Apr 15:42 2007
Picon

The Peer-Id and tunneled methods

Review of the recently submitted EAP-TTLSv0 specification has raised some 
questions about how the Peer-Id is determined for tunneled methods:

1. What if multiple identities are being authenticated?  EAP-TTLSv0 can 
handle both mutual authentication in phase I (via certificates) as well as 
one or more inner methods.   Are multiple Peer-Ids returned in this case, or 
is there only one (or none)?

2. What if Phase I used only server authentication and the inner method 
doesn't export a Peer-Id (e.g. EAP-MD5).  Does the tunneled method return 
the null Peer-Id in this case?

3. Do Peer-Ids have a type?

Here are some thoughts on these questions.

1. A method may return multiple Peer-IDs.  In AAA, there is the assumption 
that a session can be tied to an account for billing purposes.  For example, 
even where anonymity is used, there is a need for the AAA server to know who 
the user is, so that they can be billed for the session.  For example, RFC 
4372 assumes that the AAA server can return a CUI based on an inner 
identity; it is also possible for the AAA server to return a User-Name 
attribute which will be carried in subsequent Accounting-Requests.  Where 
there are multiple Peer-Ids,  the AAA server may have to choose between them 
to decide which User-Name attribute to return, or how the Peer-Ids map to 
the CUI returned in the Access-Accept.

2. The EAP-Response/Identity is not really suitable as a Peer-Id, since it 
is primarily used for routing purposes, and may be "decorated". As a result, 
the RADIUS User-Name attribute (which is undecorated) is typically more 
(Continue reading)

Alan DeKok | 7 Apr 16:45 2007

Re: The Peer-Id and tunneled methods

Bernard Aboba wrote:
> Review of the recently submitted EAP-TTLSv0 specification has raised some 
> questions about how the Peer-Id is determined for tunneled methods:

  Is there a reference to the draft?  tools.ietf.org has only expired
drafts for "*ttls*" or "*funk*".

  Alan DeKok.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

Bernard Aboba | 7 Apr 23:49 2007
Picon

Re: The Peer-Id and tunneled methods

>   Is there a reference to the draft?  tools.ietf.org has only expired
>drafts for "*ttls*" or "*funk*".

The current draft is available here:
http://www.watersprings.org/pub/id/draft-funk-eap-ttls-v0-00.txt

This document is currently being revised to fill in some missing material 
(e.g. EMSK generation, Peer-Id, Server-Id, Session-Id).  When it is 
available, it will be found here:
http://www.ietf.org/internet-drafts/draft-funk-eap-ttls-v0-01.txt

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

Bernard Aboba | 8 Apr 00:14 2007
Picon

Re: Last call comments: draft-williams-on-channel-binding-01.txt:EAP chann

>The Extensible Authentication Protocol (EAP) [RFC3748] includes two
>facilities related to channel binding.  The first, called channel
>binding, is used to bind the lower-layer channel created between the
>peer and the authenticator to the authentication performed using EAP.

I think you need to be careful about the precise meaning of "bind" and 
"lower layer channel" here.

Properties of the lower layer channel such as ciphersuite negotiation are 
determined during the Secure Association Exchange.  During the SAP other 
parameters advertised or negotiated between the peer and authenticator can 
be cryptographically bound to the transient session keys used between peer 
and authenticator.  For example, within IEEE 802.11i, the peer and 
authenticator MAC address, ciphersuite
and capabilities are securely confirmed during the 4-way handshake.

In contrast, Channel Bindings as defined in RFC 3748 occur during the EAP 
exchange.  Its purpose is to confirm the consistency of channel properties 
advertised by the authenticator to the peer and EAP server.  However, 
negotiation of the lower layer channel properties occurs during the SAP.

>Specific details of this facility have not been specified, but it is
>likely that this channel would use endpoint channel bindings carried
>in the EAP method exchange.

Secure Association Protocols are specified in considerable detail within 
IEEE 802.11i, IEEE 802.16e and IKEv2.  Also, both RFC 3748 and the EAP Key 
Management Framework discuss Channel Bindings. So saying it is "unspecified" 
doesn't seem accurate.

(Continue reading)

hartmans-ietf | 10 Apr 00:30 2007
Picon

Re: Last call comments: draft-williams-on-channel-binding-01.txt:EAP chann

>>>>> "Bernard" == Bernard Aboba <bernard_aboba <at> hotmail.com> writes:

    >> The Extensible Authentication Protocol (EAP) [RFC3748] includes
    >> two facilities related to channel binding.  The first, called
    >> channel binding, is used to bind the lower-layer channel
    >> created between the peer and the authenticator to the
    >> authentication performed using EAP.

    Bernard> I think you need to be careful about the precise meaning
    Bernard> of "bind" and "lower layer channel" here.

I'm using them consistently with the rest of the document.

    Bernard> Properties of the lower layer channel such as ciphersuite
    Bernard> negotiation are determined during the Secure Association
    Bernard> Exchange.  During the SAP other parameters advertised or
    Bernard> negotiated between the peer and authenticator can be
    Bernard> cryptographically bound to the transient session keys
    Bernard> used between peer and authenticator.  For example, within
    Bernard> IEEE 802.11i, the peer and authenticator MAC address,
    Bernard> ciphersuite and capabilities are securely confirmed
    Bernard> during the 4-way handshake.

This is a true statement.

    Bernard> In contrast, Channel Bindings as defined in RFC 3748
    Bernard> occur during the EAP exchange.  Its purpose is to confirm
    Bernard> the consistency of channel properties advertised by the
    Bernard> authenticator to the peer and EAP server.  However,
    Bernard> negotiation of the lower layer channel properties occurs
(Continue reading)

Nicolas Williams | 10 Apr 01:07 2007
Picon

Re: Last call comments: draft-williams-on-channel-binding-01.txt:EAP chann

So then the stuff to bind to exists but no spec says "the EAP channel
bindings for this kind of L2 association is XYZ" and we all have a good
idea of what that text should read like, right?

On Mon, Apr 09, 2007 at 03:52:31PM -0700, Bernard Aboba wrote:
> No one has defined the format of channel bindings and with the
> possible exception of 802.11r I don't know of any lower layer that has
> clearly defined what identity should be bound for that layer.
>  
> [BA] As outlined in RFC 3748 and the EAP Key Management Framework, channel binding matching is designed to
be a mechanical process, which implies that they are communicated in the form of AAA attributes. 
>  
> For example, the following AAA attributes can be sent from the NAS to the AAA server for IEEE 802: 
>  
> Called-Station-Id:  Authenticator Port MAC address or AP BSSID (potentially with the SSID)
> Calling-Station-Id:  Supplcant MAC address
> NAS-Identifier:  Authenticator identifier (IEEE 802.11r R1KH-ID)
> 
> >How do I know what the lower layer identity is unless the lower layer
> >spec tells me
>  
> Lower layer specifications already define the source MAC addresses (e.g. IEEE 802), and in some cases,
authenticator identities (IEEE 802.11r).   So no additional lower layer standards are required. 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

(Continue reading)

Bernard Aboba | 10 Apr 00:52 2007
Picon

RE: Last call comments: draft-williams-on-channel-binding-01.txt:EAP chann

No one has defined the format of channel bindings and with the
possible exception of 802.11r I don't know of any lower layer that has
clearly defined what identity should be bound for that layer.
 
[BA] As outlined in RFC 3748 and the EAP Key Management Framework, channel binding matching is designed to be a mechanical process, which implies that they are communicated in the form of AAA attributes.
 
For example, the following AAA attributes can be sent from the NAS to the AAA server for IEEE 802:
 
Called-Station-Id:  Authenticator Port MAC address or AP BSSID (potentially with the SSID)
Calling-Station-Id:  Supplcant MAC address
NAS-Identifier:  Authenticator identifier (IEEE 802.11r R1KH-ID)

>How do I know what the lower layer identity is unless the lower layer
>spec tells me
 
Lower layer specifications already define the source MAC addresses (e.g. IEEE 802), and in some cases, authenticator identities (IEEE 802.11r).   So no additional lower layer standards are required.
_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Bari, Farooq | 24 Apr 02:09 2007

Re: EAP WG Last Call on Network Discovery andSelectionProblem Document

Based on the email exchanges between Jouni and Bernard I propose the
following resolution to the issues raised by Jouni
--
Jouni's concern about the calculations can be addressed by presenting
them in the draft as standalone calculations without referring to
Velayo's paper. Bernard had done these independent calculations in his
response which to my understanding Jouni did not seem to have a problem
if they were not referring to Velayos paper. 

--

Jouni had some concern on scalability section  which can be addressed by
changing

"Similarly, "virtual AP" approaches introduce additional Beacons in
proportion to the number of networks being advertised.  Neither approach
scales to...". 

To

"Similarly, approaches that utilize separate Beacons for each "virtual
AP"  introduce additional Beacons in proportion to the number of
networks being advertised.  Neither approach scales to..."

--
Jouni comments on conclusion section can be addressed by following steps

Adding some explanatory text about Virtual APs

Hidden SSIDs.  Here Beacons are not sent for SSIDs defined as "hidden";
instead, stations are configured to send a Probe Request for each
"hidden  SSID".   As a result, Beacon traffic does not grow with
addition of new "hidden virtual APs".  Instead Probe Request traffic
increases with the number of users configured to probe for "hidden
SSIDs" and the number of "hidden SSIDs" they are configured to probe
for.   In some cases disclosure of station interest in a "hidden SSID"
may be considered a privacy risk, and additional latency may be
introduced where a substantial number of hidden SSIDs needs to be
probed.

Multiple SSIDs per Beacon.  In this approach, multiple SSIDs can be
advertised within a single Beacon or Probe Response. This approach
improves Beacon scaling as compared with advertisement of a single SSID
per Beacon, and also may reduce Probe Request traffic, so that it can
complement the "hidden SSID" approach.

By changing

"Studies such as [MACScale] and [Velayos], demonstrate that the IEEE
802.11 Beacon/Probe Response mechanism has substantial scaling issues,
and as a result a single physical access point is in practice limited to
less than a dozen virtual APs on each channel with IEEE 802.11b."

to

"Studies such as [MACScale] and [Velayos], demonstrate that with the
utilization of a separate Beacon for each "virtual AP", the IEEE 802.11
Beacon/Probe Response mechanism has substantial scaling issues, and as a
result a single physical access point is in practice limited to less
than a dozen virtual APs on each channel with IEEE 802.11b."

By changing 

"However, even with these enhancements it is not feasible to advertise
more than 50 different networks, and probably less in most
circumstances"

To

"However, even with these enhancements, when a separate Beacon is
utilized for each "virtual AP", it is not feasible to advertise more
than 50 different networks, and probably less in most circumstances.
These limitations however do not exist with alternative "virtual AP"
approaches now in development."

BR,

Farooq Bari
farooq.bari <at> att.com
+1 425 580 5526

> -----Original Message-----
> From: Jouni Malinen [mailto:j <at> w1.fi]
> Sent: Tuesday, March 27, 2007 7:11 PM
> To: Bernard Aboba
> Cc: eap <at> frascone.com
> Subject: Re: [eap] EAP WG Last Call on Network Discovery
andSelectionProblem
> Document
> 
> On Tue, Mar 27, 2007 at 09:52:22AM -0700, Bernard Aboba wrote:
> > BTW, I did some traces, and 170 octet Beacons are actually quite
common
> > (Apple Airport Extreme has Beacons of this size, for example).
> >
> > If you add up 1360 bits at 1 Mbps (1360us), 144 us for preamble, 48
us for
> > PLCP, 10 us for
> > SIFS, 50 ms for DIFS, and 1200 usec for CWmin/2 slot times, and
multiple by
> > 98 Beacons/sec, you get 27.6 percent.
> >
> > 200 octet beacons would give 30 percent.  So I don't think that the
Velayos
> > paper is that far off.
> 
> Sure, it is possible that beacons are longer. Though, I would assume
> that this would be more likely with 802.11g/a APs while the paper was
> talking about 802.11b which is unlikely to include many of the new IEs
> in beacon frames. Anyway, if the question is on how many "modern APs"
> one can have on a single channel, this kind of channel time usage may
> indeed be getting more likely since I would expect most 802.11g APs to
> continue beaconing at 1 Mbps rate.
> 
> --
> Jouni Malinen                                            PGP id
EFC895FA
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap


Gmane