Subject: [NSIS] GIST: Authentication API Discrepancy

From: Elwyn Davies <[email-masked]>
Date: Tue, 21 Feb 2006 16:26:13 +0000

The NATFW NSLP may need to be able to access the authentication 
information that GIST obtains (e.g., to look at additional fields of 
certificates) and s8.2 of draft-ietf-nsis-ntlp-09 states:
>
> The abstract API of Appendix B leaves open such policy
>    and authentication interactions between GIST and the NSLP it is
>    serving.  However, it does allow applications to inspect the
>    authenticated identity of the peer to which a message will be sent
>    before transmission.
>
The last sentence of this implies that the API has a means for passing 
the certificate or other authentication data to the NSLP.  I take it 
that this would be a parameter of RecvMessage but it doesn't appear that 
it is available at present - the Transfer-Attributes have some info but 
not all of it seemingly.  Is this a drop-off?

Regards,
Elwyn

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 21 Feb 2006 22:49:09 -0000

Hi Elwyn,

The intention is that you should be able to get at this information
through the API. There are actually 2 places:

- RecvMessage (to say how a message was received)
- MessageStatus (to find out how a message is going to be sent)

You can also specify how a message is to be sent in SendMessage.

In each case, the information logically goes in the transfer
attributes provided with the message. The security points are noted
mainly in the SendMessage description, but the same points apply
to the other two primitives.

The description of the transfer attributes is deliberately left
open. Especially in the security case, I think it likely that 
these will be largely a pass through to whatever is provided by
the underlying TLS implementation, whatever it is. The main goal
of the API discussion is to indicate at what stage in a 
signalling transaction the information becomes available to
NSLPs and what they can do with it, rather than to specify how
much detail and in what format it should be provided.

Do you think the specification should say more?

r.

PS note that Pasi & Hannes' tls-in-gist draft indicates other
reasons why one might want more detail in the API description,
specifically to allow NSLPs to do channel bindings to the
underlying security association. So that would require at least
definition of the semantics of the information to be provided
by the API, even if the syntax is left up to the channel binding
specification.

> -----Original Message-----
> From: Elwyn Davies [mailto:[email-masked]] 
> Sent: 21 February 2006 16:26
> To: Nsis
> Subject: [NSIS] GIST: Authentication API Discrepancy
> 
>