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ó:
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.
And that to me constitutes an assumption that the transport is not
necessarily reliable!
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
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
