[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CHANNEL and proxy credentials
Whether it is Kerberos V or proxy challenge or S/MIME (?), CHANNEL must have
some sort of authentication. Without it, we might have trouble progressing
the draft.
That said, this may be a non-solvable problem: what does the server pass
back when the result is a rtsp: response? a sip: response? a http: response?
etc...
Remember, there is a liklihood that the response to CHANNEL will result in a
physically separate node from the IMAP server.
-----Original Message-----
From: owner-ietf-imap-voice@xxxxxxxxxxxx
[mailto:owner-ietf-imap-voice@xxxxxxxxxxxx]On Behalf Of Lawrence
Greenfield
Sent: Tuesday, March 19, 2002 2:20 PM
To: ietf-imap-voice@xxxxxxx
Subject: CHANNEL and proxy credentials
Advanced authentication frameworks support proxy credentials.
The most obvious example of this is Kerberos V. An extremely naive
example is just sending your password to the server that you want to
act on your behalf. There have also been discussions of this in the
PKI world, though I'm not familiar with them.
This is something that might be useful for channel. While there's no
specification corresponding to SASL on how to ask for or transmit
credentials, attempting to add such a thing to channel would be
worthwhile so we can gain experience with it and see what's going on.
It would probably be sufficient to have another paren'd list send as
part of the channel command, so:
a CHANNEL ("KERBEROS_V5" <base64> "PKIX509BLAH" <base64>) ...
for the client to transmit some sort of proxy credentials to the
server which it thinks might be useful for the IMAP server to make the
established channel.
In the kerberos world the blob would be proxiable ticket (see 2.5 of
draft-ietf-krb-wg-kerberos-clarifications-00 for instance). The
server would decode the blob and stuff it into its kerberos (client)
ticket cache.
Larry