Subject: [abfab] Architecture Document Issue

From: "Jim Schaad" <[email-masked]>
Date: Fri, 22 Jul 2011 14:09:42 -0400

I have been reading more documents (always a bad idea) and I think that the architecture document probably needs to cover some requirements on the host protocol to be used with ABFAB.  At this point in time I have the following issues that I think need to be checked:

1.  What is the assumption that EAP uses when being transported over RADIUS/DIAMETER.  Specifically does it make assumption that the transport is reliable and thus no retries ever need to be made.  If this is the case then the same assumption would need to either be placed on the host protocol or on the service provider.

2.  What are the trade-offs when running the server as an EAP pass-through service verses as a tunnel.   Specifically what are the security and functionality requirements that are imposed.  Two issues that I can think of are 1) is the EAP data masked from the server and 2) if the host protocol is not reliable, does the pass-through service need to provide the retry service.

3.  It would do well to re-state the requirements from GSSAPI in the document - specifically that it is required the host protocol provide a reliable service that will deliver items to GSSAP in order.  This means that an underlying protocol that wants to use UDP for some reason will have additional requirements placed on it that are not there for a TCP based service.

4.  Can a host protocol be writing as a pure query/response system or does it need to support full bi-directional, full duplex functionality.  Specifically are there any requirements from ABFAB itself (say from EAP) that make it impossible to run as a query/response system.  For example, if an EAP server needs to do a re-try and generates a message to be sent down, can this occur?  Is this going to be allowed by Radius/Diameter?  Is it an issue for the host protocol to understand.  These are issues that can be lost if one is looking just at the requirements of the host protocol.  (I do not currently know if this is an issue for creating of a GSS-API context or not.)

Jim

---

From: Josh Howlett <[email-masked]>
Date: Fri, 22 Jul 2011 19:26:05 +0000

Jim,

>1.  What is the assumption that EAP uses when being transported over
>RADIUS/DIAMETER.  Specifically does it make assumption that the transport
>is reliable and thus no retries ever need to be made.

No; check out section 2.3 of RFC3579: "As noted in [RFC2284], if an EAP
packet is lost in transit between the authenticating peer and the NAS (or
vice versa), the NAS will retransmit."

I'm not sufficiently familiar with Diameter to comment, but I hope that
someone who is will be able to chip in...

>2.  What are the trade-offs when running the server as an EAP
>pass-through service verses as a tunnel.   Specifically what are the
>security and functionality requirements that are imposed.  Two issues
>that I can think of are 1) is the EAP data masked from the server and 2)
>if the host protocol is not reliable, does the pass-through service need
>to provide the retry service.

I'm not sure what you mean by tunnel in this context; could you clarify
please?

>3.  It would do well to re-state the requirements from GSSAPI in the
>document - specifically that it is required the host protocol provide a
>reliable service that will deliver items to GSSAP in order.  This means
>that an underlying protocol that wants to use UDP for some reason will
>have additional requirements placed on it that are not there for a TCP
>based service.

I have no problem with that.

>4.  Can a host protocol be writing as a pure query/response system or
>does it need to support full bi-directional, full duplex functionality.
>Specifically are there any requirements from ABFAB itself (say from EAP)
>that make it impossible to run as a query/response system.

Not that I can think of.

>  For example, if an EAP server needs to do a re-try and generates a
>message to be sent down, can this occur?

I'm not sure what you mean by a "re-try"? Do you mean a re-transmission
following an assumed packet loss? Or some kind of unsolicited message?

>  Is this going to be allowed by Radius/Diameter?  Is it an issue for the
>host protocol to understand.

Regretfully I'm not sure what you mean. Do you have a specific use-case or
requirement in mind that we can work through?

Josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG

---

From: Sam Hartman <[email-masked]>
Date: Sat, 23 Jul 2011 15:49:50 -0400

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:

    Jim> I have been reading more documents (always a bad idea) and I
    Jim> think that the architecture document probably needs to cover
    Jim> some requirements on the host protocol to be used with ABFAB.
    Jim> At this point in time I have the following issues that I think
    Jim> need to be checked: 1.  What is the assumption that EAP uses
    Jim> when being transported over RADIUS/DIAMETER.  Specifically does
    Jim> it make assumption that the transport is reliable and thus no
    Jim> retries ever need to be made.  If this is the case then the
    Jim> same assumption would need to either be placed on the host
    Jim> protocol or on the service provider.

No, the RADIUS server would retransmit.

GSS does need to reliably transport context tokens.
IF 2743 doesn't say that we need to say that here.
If 2743 does say that adding a reference seems fine.

    Jim> 2.  What are the trade-offs when running the server as an EAP
    Jim> pass-through service verses as a tunnel.  Specifically what are
    Jim> the security and functionality requirements that are imposed.
    Jim> Two issues that I can think of are 1) is the EAP data masked
    Jim> from the server and 2) if the host protocol is not reliable,
    Jim> does the pass-through service need to provide the retry

    Jim> service.

    Jim> 3.  It would do well to re-state the requirements from GSSAPI
    Jim> in the document - specifically that it is required the host
    Jim> protocol provide a reliable service that will deliver items to
    Jim> GSSAP in order.  This means that an underlying protocol that
    Jim> wants to use UDP for some reason will have additional
    Jim> requirements placed on it that are not there for a TCP based
    Jim> service.

Context tokens must be delivered in order.
Per-message tokens need not be delivered in order.

s    Jim> 4.  Can a host protocol be writing as a pure query/response
    Jim> system or does it need to support full bi-directional, full
    Jim> duplex functionality.  Specifically are there any requirements
    Jim> from ABFAB itself (say from EAP) that make it impossible to run
    Jim> as a query/response system.  For example, if an EAP server
    Jim> needs to do a re-try and generates a message to be sent down,
    Jim> can this occur?  Is this going to be allowed by
    Jim> Radius/Diameter?  Is it an issue for the host protocol to
    Jim> understand.  These are issues that can be lost if one is
    Jim> looking just at the requirements of the host protocol.  (I do
    Jim> not currently know if this is an issue for creating of a
    Jim> GSS-API context or not.)

The GSS-API context protocol is query-response.
Per-message protocols can be whatever they like.

    Jim> Jim

    Jim> _______________________________________________ abfab mailing
    Jim> list [email-masked] https://www.ietf.org/mailman/listinfo/abfab

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 23 Jul 2011 17:20:18 -0400

Josh,

Good to hear from you.

> -----Original Message-----
> From: Josh Howlett [mailto:[email-masked]]
> Sent: Friday, July 22, 2011 3:26 PM
> To: Jim Schaad; [email-masked]
> Subject: Re: [abfab] Architecture Document Issue
> 
> Jim,
> 
> >RADIUS/DIAMETER.  Specifically does it make assumption that the
> >transport is reliable and thus no retries ever need to be made.
> 
vice
> versa), the NAS will retransmit."
> 

Actually that would make the assumption be true.  If it is the job of the
NAS to do the retransmit then the assumption is that the RADIUS layer is
going to be a reliable transport.  

> >that I can think of are 1) is the EAP data masked from the server and
> >2) if the host protocol is not reliable, does the pass-through service
> >need to provide the retry service.
> 

Ok - from the response to the above statement, it means that the NAS MUST
operate according to the rules of being an EAP pass-through service.  It
cannot just blindly pass the EAP packets on to the acceptor w/o ever looking
at them.  It needs to filter out known bad packets as well as dealing with
the rules of retransmission. 

> >Specifically are there any requirements from ABFAB itself (say from
> >EAP) that make it impossible to run as a query/response system.
> 
> Not that I can think of.
> 
> >  Is this going to be allowed by Radius/Diameter?  Is it an issue for
> >the host protocol to understand.
> 

We can change the questions a bit at this point.  Based on your responses we
can make the following assumptions:

1.  EAP over Radius is assumed to be running on a reliable transport.
2.  EAP over GSS-API is assumed to be running on a reliable transport.  If
the transport is not reliable then it must be made reliable by the host
protocol according to the rules of using GSS-API.
3.  The current assumption is that the NAS (using the Radius terminology)
and the GSS-API acceptor are in the same location thus there is no transport
between them.

This removes much of the issue that I was worried about as we can now assume
there is never a reason for an EAP server to retransmit an EAP message.

The only reason for this not to be true would be if statement 3 was not true
AND there was an unreliable transport between the terminus of the Radius
system and the service.  This means that the GSS-API acceptor is not the
NAS.  The NAS is going to do retransmission of EAP messages.  The GSS-API
would need to potentially need to catch the retransmission and remove
duplicate messages.  

Ok - if we make the above assumptions then it might not be necessary to have
a "NAS" that does the retransmission of EAP messages.  There would never be
any reason to assume that they are ever going to be lost and thus need to
get retransmitted as we have defined that there is a reliable transport all
of the way through.

The next question then is does the server need to act as a EAP pass-through
agent, or can it just tunnel the messages from the EAP side to the GSS-API
side w/o ever looking at the content of the message and following the rules
of an EAP pass-through agent (i.e. drop messages on the floor due to the
value of the code field and so forth).

Jim

> 
> Josh.
> 
> 
> 
> JANET(UK) is a trading name of The JNT Association, a company limited by
> guarantee which is registered in England under No. 2881024 and whose
> Registered Office is at Lumen House, Library Avenue, Harwell Oxford,
Didcot,
> Oxfordshire. OX11 0SG

---

From: Josh Howlett <[email-masked]>
Date: Wed, 27 Jul 2011 12:44:30 +0000

Jim,

>going to be a reliable transport.

That's not the conclusion I would draw, but perhaps I'm misunderstanding
you. The fact that the NAS has to consider retransmission is a consequence
of the fact that the underlying transport is not reliable.

>the rules of retransmission.

Yes; this is laid out in RFC 3748; specifically section 2.3 ('Pass-Through
Behaviour').

>protocol according to the rules of using GSS-API.

These aren't assumptions of the architecture, although I believe it will
end up being true in practice.

>and the GSS-API acceptor are in the same location thus there is no

Correct. Although bear in mind there could be intermediate RADIUS proxies
between the NAS and the EAP server.

>there is never a reason for an EAP server to retransmit an EAP message.

I think this is, in practice, unlikely but not impossible if unreliable
RADIUS transport is used (ie. RADIUS over TCP).

>would need to potentially need to catch the retransmission and remove

I think I would disagree with this characterisation; the GSS acceptor is
acting very much like a NAS at a protocol level. In terms of
implementation, it could looks quite different, of course. In our GSS EAP
implementation, the acceptor will eventually call out to a completely
separate process (the Identity Selector) which will manage the EAP state
machine.

>get retransmitted as we have defined that there is a reliable transport

I agree, although not for the reasons you state! It's more likely that
reliable transport will be deployed (ie. RADIUS over TCP, rather than UDP
as is commonly the case today).

>value of the code field and so forth).

It could do that, but it wouldn't conform to the existing architecture.
Why would you want to do this?

Josh.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 27 Jul 2011 10:31:08 -0400

>>>>> "Josh" == Josh Howlett <[email-masked]> writes:

    Josh> Jim,
    >>> 
    >>> >1.  What is the assumption that EAP uses when being transported
    >>> over >RADIUS/DIAMETER.  Specifically does it make assumption
    >>> that the >transport is reliable and thus no retries ever need to
    >>> be made.
    >>> 
    >>> No; check out section 2.3 of RFC3579: "As noted in [RFC2284], if
    >>> an EAP packet is lost in transit between the authenticating peer
    >>> and the NAS (or
    >> vice
    >>> I'm not sufficiently familiar with Diameter to comment, but I
    >>> hope that someone who is will be able to chip in...
    >> 
    >> Actually that would make the assumption be true.  If it is the
    >> job of the NAS to do the retransmit then the assumption is that
    >> the RADIUS layer is going to be a reliable transport.

    Josh> That's not the conclusion I would draw, but perhaps I'm
    Josh> misunderstanding you. The fact that the NAS has to consider
    Josh> retransmission is a consequence of the fact that the
    Josh> underlying transport is not reliable.

What Jim is saying is that RADIUS provides a reliable service to
EAP. That is, RADIUS is responsible for making sure that messages
reliably get from the NAS to the EAP server and back.
I believe he's approximately right and that the differences are not
things we need to worry abuot.

    >>> 
    >>> >3.  It would do well to re-state the requirements from GSSAPI
    >>> in the >document - specifically that it is required the host
    >>> protocol provide a >reliable service that will deliver items to
    >>> GSSAP in order.  This means >that an underlying protocol that
    >>> wants to use UDP for some reason will >have additional
    >>> requirements placed on it that are not there for a TCP >based
    >>> service.
    >>> 
    >>> >4.  Can a host protocol be writing as a pure query/response
    >>> system or >does it need to support full bi-directional, full
    >>> duplex functionality.  >Specifically are there any requirements
    >>> from ABFAB itself (say from >EAP) that make it impossible to run
    >>> as a query/response system.
    >>> 
    >>> Not that I can think of.
    >>> 
    >>> > For example, if an EAP server needs to do a re-try and
    >>> generates a >message to be sent down, can this occur?
    >>> 
    >>> I'm not sure what you mean by a "re-try"? Do you mean a
    >>> re-transmission following an assumed packet loss? Or some kind
    >>> of unsolicited message?
    >>> 
    >>> > Is this going to be allowed by Radius/Diameter?  Is it an
    >>> issue for >the host protocol to understand.
    >>> 
    >>> Regretfully I'm not sure what you mean. Do you have a specific
    >>> use-case or requirement in mind that we can work through?
    >> 
    >> We can change the questions a bit at this point.  Based on your
    >> responses we can make the following assumptions:
    >> 
    >> 1.  EAP over Radius is assumed to be running on a reliable
    >> transport.  2.  EAP over GSS-API is assumed to be running on a
    >> reliable transport.  If the transport is not reliable then it
    >> must be made reliable by the host protocol according to the rules
    >> of using GSS-API.

    Josh> These aren't assumptions of the architecture, although I
    Josh> believe it will end up being true in practice.

I actually believe these are carefully crafted aspects of the
architecture.  Making sure both the above could be assumed was something
I have been very careful to try and achieve since the issues were
discussed in the feasibility analysis.

    >> 3.  The current assumption is that the NAS (using the Radius
    >> terminology) and the GSS-API acceptor are in the same location
    >> thus there is no transport between them.

    Josh> Correct. Although bear in mind there could be intermediate
    Josh> RADIUS proxies between the NAS and the EAP server.

    >> This removes much of the issue that I was worried about as we can
    >> now assume there is never a reason for an EAP server to
    >> retransmit an EAP message.

    Josh> I think this is, in practice, unlikely but not impossible if
    Josh> unreliable RADIUS transport is used (ie. RADIUS over TCP).

There is never a case where an EAP retransmission is visible at the GSS
layer.  I think that's enough to get the properties Jim is interested
in.  Arguing about whether a duplicate EAP request is a RADIUS
retransmission or an EAP server retransmission is implementation
pedantry; I think 3748 resolves it as a RADIUS issue, but it doesn't
much matter.

    >> The only reason for this not to be true would be if statement 3
    >> was not true AND there was an unreliable transport between the
    >> terminus of the Radius system and the service.  This means that
    >> the GSS-API acceptor is not the NAS.  The NAS is going to do
    >> retransmission of EAP messages.  The GSS-API would need to
    >> potentially need to catch the retransmission and remove duplicate
    >> messages.

    Josh> I think I would disagree with this characterisation; the GSS
    Josh> acceptor is acting very much like a NAS at a protocol
    Josh> level. In terms of implementation, it could looks quite
    Josh> different, of course. In our GSS EAP implementation, the
    Josh> acceptor will eventually call out to a completely separate
    Josh> process (the Identity Selector) which will manage the EAP
    Josh> state machine.

    >> Ok - if we make the above assumptions then it might not be
    >> necessary to have a "NAS" that does the retransmission of EAP
    >> messages.  There would never be any reason to assume that they
    >> are ever going to be lost and thus need to get retransmitted as
    >> we have defined that there is a reliable transport all of the way
    >> through.

    Josh> I agree, although not for the reasons you state! It's more
    Josh> likely that reliable transport will be deployed (ie. RADIUS
    Josh> over TCP, rather than UDP as is commonly the case today).

    >> The next question then is does the server need to act as a EAP
    >> pass-through agent, or can it just tunnel the messages from the
    >> EAP side to the GSS-API side w/o ever looking at the content of
    >> the message and following the rules of an EAP pass-through agent
    >> (i.e. drop messages on the floor due to the value of the code
    >> field and so forth).

    Josh> It could do that, but it wouldn't conform to the existing
    Josh> architecture.  Why would you want to do this?

    Josh> Josh.

    Josh> JANET(UK) is a trading name of The JNT Association, a company
    Josh> limited by guarantee which is registered in England under
    Josh> No. 2881024 and whose Registered Office is at Lumen House,
    Josh> Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG

    Josh> _______________________________________________ abfab mailing
    Josh> list [email-masked]
    Josh> https://www.ietf.org/mailman/listinfo/abfab

---

From: Josh Howlett <[email-masked]>
Date: Wed, 27 Jul 2011 15:01:20 +0000

>things we need to worry abuot.

Right.

>architecture.

Really? Neither RADIUS nor some potential host protocols use reliable
transports. It's obviously possible to use transports that are reliable,
but we don't constrain the architecture to require the use of those. It's
true that the GSS acceptor is hidden from this by the API abstraction, but
it's possible for a GSS operation to fail because a token is lost by the
unreliable transport.

Josh.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 27 Jul 2011 13:16:21 -0400

>> reliably get from the NAS to the EAP server and back.  I believe
    >> he's approximately right and that the differences are not things
    >> we need to worry abuot.

    Josh> Right.

    >> I actually believe these are carefully crafted aspects of the

    Josh> Really? Neither RADIUS nor some potential host protocols use
    Josh> reliable transports. It's obviously possible to use transports
    Josh> that are reliable, but we don't constrain the architecture to
    Josh> require the use of those. It's true that the GSS acceptor is
    Josh> hidden from this by the API abstraction, but it's possible for
    Josh> a GSS operation to fail because a token is lost by the
    Josh> unreliable transport.

No, if RADIUS or the host protocol lose a message they are responsible
for retransmitting.

It's possible that a connection can fail because retransmissions fail
and RADIUS or the host protocol returns a protocol error.

    Josh> Josh.

---

From: Josh Howlett <[email-masked]>
Date: Wed, 27 Jul 2011 17:25:05 +0000

>and RADIUS or the host protocol returns a protocol error.

And that to me constitutes an assumption that the transport is not
necessarily reliable!

Josh.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Wed, 27 Jul 2011 13:36:05 -0400

Hi Josh,

That is also our interpretation of what rfc2743 says:

The GSS-API is independent of underlying protocols and addressing
    structure, and depends on its callers to transport GSS-API-provided
    data elements. As a result of these factors, it is a caller
    responsibility to parse communicated messages, separating GSS-API-
    related data elements from caller-provided data.  The GSS-API is
    independent of connection vs. connectionless orientation of the
    underlying communications service.

Hence, we understand that no assumptions at all can be done regarding 
the transport. For example, the transport for a GSS-API security 
association could be as unreliable as RAW UDP packets. Therefore, is our 
understanding that each GSS mechanism should provide enough information 
within their tokens to be able to detect and recover from these situations.

Indeed, you can see that GSS_API defines the following error codes:

GSS_S_DUPLICATE_TOKEN
GSS_S_OLD_TOKEN

that would be consequently sent when one of the mentioned situations 
were detected.

Just my 2 cents.

Regards,
Alejandro

El 27/07/11 13:25, Josh Howlett escribió:
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Sam Hartman <[email-masked]>
Date: Wed, 27 Jul 2011 14:14:35 -0400

>> No, if RADIUS or the host protocol lose a message they are
    >> responsible for retransmitting.  It's possible that a connection
    >> can fail because retransmissions fail and RADIUS or the host
    >> protocol returns a protocol error.

    Josh> And that to me constitutes an assumption that the transport is
    Josh> not necessarily reliable!

In that sense there exist no reliable transports.  TCP has the same
failure.  Typically what we mean by reliable transport is that the
transport will either deliver a message or signal failure.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 27 Jul 2011 14:16:50 -0400

>>>>> "Alejandro" == Alejandro Perez Mendez <[email-masked]> writes:

    Alejandro> Hence, we understand that no assumptions at all can be
    Alejandro> done regarding the transport. For example, the transport
    Alejandro> for a GSS-API security association could be as unreliable
    Alejandro> as RAW UDP packets. Therefore, is our understanding that
    Alejandro> each GSS mechanism should provide enough information
    Alejandro> within their tokens to be able to detect and recover from
    Alejandro> these situations.

Detect yes.

Recover from, no. I'm not aware of any existing GSS mechanism that can
recover from a lost or corrupted context token.