Traducido del inglés al español - [Link].

com

6/8/24, 9:48 a.m. RFC 1288: Protocolo de información del usuario Finger

Grupo de trabajo de red [Link]

Solicitud de comentarios: 1288 Centro de Matemáticas Discretas y
Obsoletos: RFC 1196, 1194, 742 Informática Teórica
diciembre de 1991

El protocolo de información del usuario de dedo

Estado de este Memo

Este memorándum define un protocolo para el intercambio de información del

usuario. Este RFC especifica un protocolo de seguimiento de estándares de la IAB
para la comunidad de Internet y solicita discusión y sugerencias para mejoras.
Consulte la edición actual de los "Estándares de protocolo oficiales de IAB" para
conocer el estado de estandarización y el estado de este protocolo. La distribución de
este memo es ilimitada.

Abstracto

Esta nota describe el protocolo de información del usuario Finger. Este es un protocolo
simple que proporciona una interfaz para un programa de información de usuario
remoto.

Basado en RFC 742, una descripción del protocolo Finger original, este memorando
intenta aclarar la comunicación esperada entre los dos extremos de una conexión
Finger. También intenta no invalidar las muchas implementaciones existentes ni
agregar restricciones innecesarias a la definición del protocolo original.

Esta edición corrige y aclara RFC 1196.

Tabla de contenido

1. Introducción ........................................... 2
1.1. Intención ............................................... 2
1.2. Historia .............................................. 3
1.3. Requisitos ......................................... 3
1.4. Actualizaciones ................................................. 3
2. Uso del protocolo ................................. 4
2.1. Flujo de eventos ................................. Formato de 4
2.2. datos ...... ................................... Consultar especificaciones 4
2.3. ................................. 4
2.4. Comportamiento de RUIP {Q2} ................................... 5
2.5. Respuesta esperada de RUIP ............................... 6
2.5.1. consulta {C} .................................. 6
2.5.2. consulta {U}{C} ....................................... 6
2.5.3. {U} ambigüedad ...................................... 7
2.5.4. /W token de consulta ..................................... 7

Zimmerman [Página 1]

[Link] 1/12
6/8/24, 9:48 a.m. RFC 1288: Protocolo de información del usuario Finger

RFC 1288 Dedo diciembre de 1991

2.5.5. Máquinas expendedoras ................................... 7

3. Seguridad ............................................... 7
3.1. Seguridad de implementación .............................. 7
3.2. Seguridad RUIP ........................................ 8
3.2.1. {Q2} negativa ....................................... 8
3.2.2. {C} negativa ........................................ 8
3.2.3. Descarga atómica ................................... 8
3.2.4. Archivos de información del usuario ............................. 9
3.2.5. Ejecución de programas de usuario. ......................... 9
3.2.6. {U} ambigüedad ...................................... 9
3.2.7. Pistas de auditoría ....................................... 9
3.3. Seguridad del cliente ...................................... 9
4. Ejemplos ................................................. 10
4.1. Ejemplo con una línea de comando nula ({C}) Ejemplo . . . . .con
. . . nombre
....... 10
4.2. especificado ({U}{C}) Ejemplo con nombre ambiguo . . . . .especificado
............ 10
4.3. ({U}{C}) Ejemplo de tipo de consulta {Q2} ({U}{H} {H}{C}) ............. ....... 11
4.4. 11
5. Agradecimientos ........................................ 12
6. Consideraciones de Seguridad ................................ 12
7. Dirección del autor .................................. 12

1. Introducción

1.1. Intención

Esta nota describe el protocolo de información del usuario Finger. Este es un

protocolo simple que proporciona una interfaz para un programa de información
de usuario remoto (RUIP).

Basado en RFC 742, una descripción del protocolo Finger original, este memorando
intenta aclarar la comunicación esperada entre los dos extremos de una conexión
Finger. También intenta no invalidar las numerosas implementaciones actuales ni
agregar restricciones innecesarias a la definición del protocolo original.

Las implementaciones más frecuentes de Finger hoy en día parecen

derivarse principalmente del trabajo BSD UNIX en la Universidad de
California, Berkeley. Por lo tanto, este memorándum se basa en el
comportamiento de la versión BSD.

Sin embargo, la versión BSD ofrece pocas opciones para adaptar Finger RUIP a la
política de seguridad de un sitio en particular o para proteger al usuario de datos
peligrosos. Además, existen MUCHOS agujeros de seguridad potenciales que los
implementadores y administradores deben conocer, particularmente porque el
propósito de este protocolo es devolver información sobre los usuarios de un
sistema, un tema delicado en el mejor de los casos. Por lo tanto, este memorándum
hace una serie de comentarios y recomendaciones de seguridad importantes.

Zimmerman [Página 2]

[Link] 2/12
6/8/24, 9:48 a.m. RFC 1288: Protocolo de información del usuario Finger

RFC 1288 Dedo diciembre de 1991

1.2. Historia

El programa FINGER en SAIL, escrito por Les Earnest, fue la inspiración para el
programa NAME en ITS. Earl Killian del MIT y Brian Harvey de SAIL fueron
responsables conjuntos de implementar el protocolo original.

Ken Harrenstien es el autor de RFC 742, "Nombre/Dedo", con el que comenzó esta
nota.

1.3. Requisitos

En este documento, las palabras que se utilizan para definir la importancia de cada
requisito particular están en mayúscula. Estas palabras son:

* "DEBE"

Esta palabra o el adjetivo "REQUERIDO" significa que el elemento es un

requisito absoluto de la especificación.

* "DEBERÍA"

Esta palabra o el adjetivo "RECOMENDADO" significa que pueden existir razones

válidas en circunstancias particulares para ignorar este punto, pero se deben
entender todas las implicaciones y sopesar el caso cuidadosamente antes de
elegir un curso diferente.

* "PUEDE"

Esta palabra o el adjetivo "OPCIONAL" significa que este elemento es

verdaderamente opcional. Un proveedor puede optar por incluir el artículo
porque un mercado en particular lo requiere o porque mejora el producto, por
ejemplo; otro proveedor puede omitir el mismo artículo.

Una implementación no es conforme si no cumple con uno o más de los requisitos

MUST. Una implementación que satisface todos los requisitos DEBE y DEBE se dice
que "cumple incondicionalmente"; uno que satisface todos los requisitos DEBE pero
no todos los DEBE se dice que cumple "condicionalmente".

1.4. Actualizaciones

Las diferencias destacadas entre RFC 1196 y este memorando son:

o el interruptor opcional /W en la especificación de consulta Finger fue

colocado por error al final de la línea. El 4.3BSD Finger lo especifica al
principio, donde ahora también lo pone esta nota.

Zimmerman [Página 3]

[Link] 3/12
6/8/24, 9:48 a.m. RFC 1288: Protocolo de información del usuario Finger

RFC 1288 Dedo diciembre de 1991

o el BNF en la especificación de consulta Finger no estaba claro en el

Tratamiento del espacio en blanco. Este memorándum es más
exigente al incluir un token explícito.

o El flujo de eventos en una conexión Finger ahora es mejor

definido sobre el tema del cierre de la conexión Finger.

2. Uso del protocolo

2.1. Flujo de eventos

Finger se basa en el Protocolo de control de transmisión, utilizando el puerto TCP

79 decimal (117 octal). El host local abre una conexión TCP a un host remoto en el
puerto Finger. Un RUIP queda disponible en el extremo remoto de la conexión para
procesar la solicitud. El host local envía al RUIP una consulta de una línea basada en
la especificación de consulta Finger y espera a que el RUIP responda. El RUIP recibe
y procesa la consulta, devuelve una respuesta y luego inicia el cierre de la conexión.
El host local recibe la respuesta y la señal de cierre, luego procede a cerrar su
extremo de la conexión.

2.2. Formato de datos

Todos los datos transferidos DEBEN estar en formato ASCII, sin paridad y con líneas
terminadas en CRLF (ASCII 13 seguido de ASCII 10). Esto excluye otros formatos de
caracteres como EBCDIC, etc. Esto también significa que cualquier carácter entre
ASCII 128 y ASCII 255 debe ser realmente datos internacionales, no ASCII de 7 bits
con el bit de paridad establecido.

2.3. Especificaciones de consulta

Un RUIP DEBE aceptar toda la especificación de consulta Finger.

La especificación de consulta Finger está definida:

{Q1} ::= [{W}|{W}{S}{U}]{C}

{Q2} ::= [{W}{S}][{U}]{H}{C}

{U} ::= nombre de usuario

{H} ::= @nombredehost | @nombredehost{H}

{W} ::= /W

{S} ::= <SP> | <SP>{S}

{C} ::= <CRLF>

Zimmerman [Página 4]

[Link] 4/12
6/8/24, 9:48 a.m. RFC 1288: Protocolo de información del usuario Finger

RFC 1288 Dedo diciembre de 1991

{H}, al ser recursivo, significa que no hay un límite arbitrario en la cantidad de

tokens @hostname en la consulta. En ejemplos de la especificación de solicitud
{Q2}, la cantidad de tokens @hostname está limitada a dos, simplemente por
brevedad.

Tenga en cuenta que {Q1} y {Q2} no se refieren a un usuario que escribe "finger
user@host" desde un mensaje del sistema operativo. Se refiere a la línea que
realmente recibe un RUIP. Entonces, si un usuario escribe "finger
user@host<CRLF>", el RUIP en el host remoto recibe "user<CRLF>", que
corresponde a {Q1}.

Como ocurre con todo el conjunto de protocolos IP, "sea liberal en lo que
acepte".

2.4. Comportamiento de RUIP {Q2}

Una consulta de {Q2} es una solicitud para reenviar una consulta a otra RUIP. Una
RUIP DEBE proporcionar o rechazar activamente este servicio de reenvío (ver
sección 3.2.1). Si un RUIP proporciona este servicio, DEBE cumplir con el siguiente
comportamiento:

Dado que:

El host <H1> abre una conexión Finger <F1-2> a un RUIP en el host <H2>.

<H1> le da al RUIP <H2> una consulta <Q1-2> de tipo {Q2} (por

ejemplo, FOO@HOST1@HOST2).

Se debe derivar que:

El host <H3> es el host situado más a la derecha en <Q1-2> (es decir, HOST2)

La consulta <Q2-3> es el resto de <Q1-2> después de eliminar el token

"@hostname" situado más a la derecha en la consulta (es decir, FOO@HOST1)

Y entonces:

El RUIP <H2> debe entonces abrir una conexión Finger <F2-3> a <H3>,
usando <Q2-3>.

El RUIP <H2> debe devolver cualquier información recibida de <F2-3> a <H1>

a través de <F1-2>.

La RUIP <H2> debe cerrar <F1-2> en circunstancias normales solo cuando

la RUIP <H3> cierra <F2-3>.

Zimmerman [Página 5]

[Link] 5/12
6/8/24, 9:48 a.m. RFC 1288: Protocolo de información del usuario Finger

RFC 1288 Dedo diciembre de 1991

2.5. Respuesta esperada de RUIP

En su mayor parte, la salida de un RUIP no sigue una especificación estricta, ya

que está diseñada para ser leída por personas en lugar de programas. Debería
esforzarse principalmente en ser informativo.

El resultado de CUALQUIER consulta está sujeto a discusión en la sección de

seguridad.

2.5.1. consulta {C}

Una consulta de {C} es una solicitud de una lista de todos los usuarios en Un RUIP
línea. DEBE responder o negarse activamente (ver sección 3.2.2). respuestas,
Si se
entonces DEBE proporcionar al menos el nombre completo del usuario. El El
administrador del sistema DEBE poder incluir otra información útil (según la
sección 3.2.3), como por ejemplo:

- ubicación terminal
- Localización de la oficina
- número de teléfono de la oficina
- nombre del trabajo

- tiempo de inactividad (número de minutos desde la última entrada escrita o

desde la última actividad laboral).

2.5.2. consulta {U}{C}

Una consulta de {U}{C} es una solicitud de información detallada sobre el estado

de un usuario específico {U}. Si realmente desea rechazar este servicio,
probablemente no desee ejecutar Finger en primer lugar.

Una respuesta DEBE incluir al menos el nombre completo del usuario. Si el usuario
ha iniciado sesión, {U}{C} también DEBE devolver al menos la misma cantidad de
información devuelta por {C} para ese usuario.

Dado que se trata de una consulta de información sobre un usuario específico, el

administrador del sistema DEBE poder optar por devolver información útil adicional
(según la sección 3.2.3), como por ejemplo:

- Localización de la oficina
- número de teléfono de la oficina
- número de teléfono de casa
- estado del archivo de información del usuario de inicio de sesión (no iniciado sesión,
- hora de cierre de sesión, etc.)

Un archivo de información del usuario es una función en la que un usuario puede

dejar un mensaje corto que se incluirá en la respuesta a las solicitudes Finger. (Esto a
veces se denomina archivo de "plan"). Esto se implementa fácilmente (por ejemplo)
haciendo que el programa busque un texto con un nombre especial.

Zimmerman [Página 6]

[Link] 6/12
6/8/24, 9:48 a.m. RFC 1288: Protocolo de información del usuario Finger

RFC 1288 Dedo diciembre de 1991

archivo en el directorio de inicio del usuario o en algún área común; el método exacto se deja
en manos del implementador. El administrador del sistema DEBE tener permiso para activar y
desactivar específicamente esta función. Consulte la sección 3.2.4 para conocer las
advertencias.

PUEDE haber una manera para que el usuario ejecute un programa en respuesta a
una consulta Finger. Si esta función existe, el administrador del sistema DEBE poder
activarla y desactivarla específicamente. Consulte la sección 3.2.5 para conocer las
advertencias.

2.5.3. {U} ambigüedad

Los "nombres" permitidos en la línea de comando DEBEN incluir "nombres de

usuario" o "nombres de inicio de sesión" según lo define el sistema. Si un nombre
es ambiguo, el administrador del sistema DEBE poder elegir si todas las
derivaciones posibles deben devolverse de alguna manera (según la sección 3.2.6).

2.5.4. /W token de consulta

El token /W en los tipos de consulta {Q1} o {Q2} DEBE, en el mejor de los casos,
interpretarse en el último RUIP para indicar un mayor nivel de detalle en la salida de
información del usuario o, en el peor de los casos, ignorarse.

2.5.5. Máquinas expendedoras

Las máquinas expendedoras DEBEN responder a una solicitud {C} con una lista de
todos los artículos actualmente disponibles para su compra y posible consumo. Las
máquinas expendedoras DEBEN responder a una solicitud {U}{C} con un recuento o
lista detallada del producto o espacio de producto en particular. Las máquinas
expendedoras NUNCA NUNCA deberían comerse dinero.

3. Seguridad

3.1. Seguridad de implementación

La correcta implementación de Finger es de suma importancia. Las

implementaciones deben probarse contra diversas formas de ataque. En particular,En
un RUIP DEBE protegerse contra entradas con formato incorrecto. Los proveedores
que proporcionen a Finger el sistema operativo o el software de red deben someter
sus implementaciones a pruebas de penetración.

El dedo es una de las vías de penetración directa, como señaló claramente el gusano
Morris. Al igual que Telnet, FTP y SMTP, Finger es uno de los protocolos del
perímetro de seguridad de un host. En consecuencia, la solidez de la implementación
es primordial. La implementación debe recibir tanto escrutinio de seguridad durante
el diseño, implementación y pruebas como Telnet, FTP o SMTP.

Zimmerman [Página 7]

[Link] 7/12
6/8/24, 9:48 a.m. RFC 1288: Protocolo de información del usuario Finger

RFC 1288 Dedo diciembre de 1991

3.2. seguridad RUIP

¡¡Advertencia!! Finger divulga información sobre los usuarios; además, dicha

información puede considerarse confidencial. Los administradores de seguridad
deben tomar decisiones explícitas sobre si ejecutar Finger y qué información se debe
proporcionar en las respuestas. Una implementación existente proporciona la hora
en que el usuario inició sesión por última vez, la hora en que leyó el correo por
última vez, si le estaba esperando correo no leído y de quién era el correo no leído
más reciente. Esto hace posible realizar un seguimiento de las conversaciones en
curso y ver dónde se centró la atención de alguien. Los sitios que son conscientes de
la seguridad de la información no deberían ejecutar Finger sin una comprensión
explícita de cuánta información está revelando.

3.2.1. {Q2} negativa

Por cuestiones de seguridad de sitios individuales, el administrador del sistema

DEBE tener la opción de activar o desactivar individualmente el procesamiento RUIP
de {Q2}. Si el procesamiento RUIP de {Q2} está desactivado, el RUIP DEBE devolver
un mensaje de rechazo de servicio de algún tipo. "Servicio de transferencia de
huellas denegado" es adecuado. El propósito de esto es permitir que los hosts
individuales elijan no reenviar las solicitudes Finger, pero si así lo deciden, hacerlo
de manera consistente.

En general, hay pocos casos que justificarían el procesamiento de {Q2} y se ven

superados con creces por el número de casos en los que se niega a procesar {Q2}. En
particular, tenga en cuenta que si una máquina forma parte del perímetro de
seguridad (es decir, es una puerta de entrada desde el mundo exterior a algún
conjunto de máquinas interiores), activar {Q2} proporciona un camino a través de
ese perímetro de seguridad. Por lo tanto, se RECOMIENDA que la opción de
procesamiento {Q2} predeterminada sea rechazar el procesamiento. Ciertamente no
debería habilitarse en máquinas de puerta de enlace sin una cuidadosa
consideración de las implicaciones de seguridad.

3.2.2. {C} negativa

Por cuestiones de seguridad de sitios individuales, el administrador del sistema DEBE

tener la opción de activar o desactivar individualmente la aceptación RUIP de {C}. Si el
procesamiento RUIP de {C} está desactivado, el RUIP DEBE devolver un mensaje de
rechazo de servicio de algún tipo. "Lista de usuarios en línea con dedos denegada" es
adecuada. El propósito de esto es permitir que los anfitriones individuales elijan no incluir
a los usuarios actualmente en línea.

3.2.3. Descarga atómica

Todas las implementaciones de Finger DEBEN permitir a los administradores de

sistemas individuales adaptar qué átomos de información se devuelven a una consulta.
Por ejemplo:

Zimmerman [Página 8]

[Link] 8/12
6/8/24, 9:48 a.m. RFC 1288: Protocolo de información del usuario Finger

RFC 1288 Dedo diciembre de 1991

- Al administrador A se le debe permitir elegir específicamente la ubicación de la

oficina de devolución, el número de teléfono de la oficina, el número de teléfono de
casa y la hora de inicio y cierre de sesión.

- Al Administrador B se le debe permitir elegir específicamente devolver solo

la ubicación de la oficina y el número de teléfono de la oficina.

- Se debe permitir al administrador C elegir específicamente devolver la

cantidad mínima de información requerida, que es el nombre completo
de la persona.

3.2.4. Archivos de información del usuario

Permitir que un RUIP devuelva información de un archivo modificable por el usuario

debe considerarse equivalente a permitir que cualquier información sobre su
sistema se distribuya libremente. Es decir, es potencialmente lo mismo que activar
todas las opciones especificables. Esta violación de la seguridad de la información se
puede realizar de varias maneras, algunas de manera inteligente y otras de manera
directa. Esto debería perturbar el sueño de los administradores del sistema que
desean controlar la información devuelta.

3.2.5. Ejecución de programas de usuario.

Permitir que un RUIP ejecute un programa de usuario en respuesta a una consulta

Finger es potencialmente peligroso. ¡¡TEN CUIDADO!! -- el RUIP NO DEBE permitir
que ese programa comprometa la seguridad del sistema. Implementar esta
característica puede ser más problemático de lo que vale, ya que siempre hay
errores en los sistemas operativos que podrían explotarse mediante este tipo de
mecanismo.

3.2.6. {U} ambigüedad

Tenga en cuenta que el uso inteligente y/o persistente de esta característica por parte de un
usuario malintencionado puede generar una lista de la mayoría de los nombres de usuario en
un sistema. El rechazo de la ambigüedad {U} debe considerarse en la misma línea que el
rechazo de las solicitudes {C} (ver sección 3.2.2).

3.2.7. Pistas de auditoría

Las implementaciones DEBEN permitir a los administradores del sistema registrar consultas
Finger.

3.3. Seguridad del cliente

Se espera que normalmente haya algún programa cliente que el usuario ejecute
para consultar el RUIP inicial. De forma predeterminada, este programa DEBE
filtrar cualquier dato no imprimible, dejando solo caracteres imprimibles de 7 bits
(ASCII 32 a ASCII 126), tabulaciones (ASCII 9) y CRLF.

Zimmerman [Página 9]

[Link] 9/12
6/8/24, 9:48 a.m. RFC 1288: Protocolo de información del usuario Finger

RFC 1288 Dedo diciembre de 1991

Esto es para proteger contra personas que juegan con códigos de escape de terminales,
cambian los nombres de las ventanas X de otras personas o cometen otros actos
cobardes o confusos. SE DEBEN considerar dos opciones de usuario separadas para
modificar este comportamiento, de modo que los usuarios puedan elegir ver caracteres
internacionales o de control:

- uno para permitir todos los caracteres menores que ASCII 32

- otro para permitir todos los caracteres mayores que ASCII 126

Para entornos que viven y respiran datos internacionales, el administrador del sistema
DEBE contar con un mecanismo para habilitar la última opción de forma predeterminada
para todos los usuarios de un sistema en particular. Esto se puede hacer mediante una
variable de entorno global o un mecanismo similar.

4. Ejemplos

4.1. Ejemplo con una línea de comando nula ({C})

Sitio: [Link] Línea

de comando: <CRLF>

Acceso Nombre TTY inactivo Cuando Oficina

rinehart Mark J. Rinehart greenfie p0 1:11 lun 12:15 019 colina x3166
Stephen J. Greenfiel rapatel Rocky - p1 Lunes 15:46 542 colina x3074
Rakesh Patel agradable Mel p3 4d jueves 00:58 028 colina x2287
Pleasant p4 3d jueves 21:32 019 colina 908-932-
Dave Phillips p5 021: domingo 18:24 265 colina x3792
dmk David Katinsky p6 2d jueves 14:11 028 colina x2492
cherniss p7 5 lunes 15:42 127 Psicología x2008
harnaga Doug Harnaga p8 2:01 lunes 10:15 055 colina x2351
brisco Thomas P. Brisco 2:09 lunes 13:37
Educación física h055 x2351
ley establecida Angus Laidlaw q0 1:55 lun 11:26 E313C 648-5592
cje Chris Jarocha-Ernst q1 8 lun 13:43 259 colina x2413

4.2. Ejemplo con nombre especificado ({U}{C})

Sitio: [Link] Línea de

comando: pirmann<CRLF> Nombre de
inicio de sesión: pirmann En la vida real: David Pirmann
Oficina: 016 Hill, x2443 Directorio: / Teléfono particular: 989-8482
dimacs/u1/pirmann Shell: /bin/tcsh
Último inicio de sesión el sábado 23 de junio a las 10:47 en ttyp0 de [Link]. No
hay correo no leído
Proyecto:
Plan:
Horario de trabajo, verano de 1990
Operaciones de Rutgers LCSR, 908-932-2443

Zimmerman [Página 10]

[Link] 10/12
6/8/24, 9:48 a.m. RFC 1288: Protocolo de información del usuario Finger

RFC 1288 Dedo diciembre de 1991

Lunes 17:00 - 00:00

Martes 17:00 - 00:00
Miércoles 9 am - 5 p.m.

Jueves 9 am - 5 p.m.

Sábado 9 am - 5 p.m.

larf larf hoo hoo

4.3. Ejemplo con nombre ambiguo especificado ({U}{C})

Sitio: [Link] Línea de

comando: ron<CRLF> Nombre de
inicio de sesión: spinner En la vida real: Ron Spinner
Oficina: Cubby de Operaciones, x2443 Teléfono residencial: 463-7358
Directorio: /u1/spinner Shell: /bin/tcsh
Último inicio de sesión Lun 7 16:38 en ttyq7
Mayo Plan:
¿Debo?
California norte

metro a
' ... t
I .. i
! metro

! ! mi
pag !piscina
yo
mi
h

Nombre de usuario: surak En la vida real: Ron Surak

Oficina: 000 OMB Dou, x9256
Directorio: /u2/surak Shell: /bin/tcsh
Último inicio de sesión viernes 27 de julio a las 09:55 en
ttyq3 Sin plan.

Nombre de usuario: etter En la vida real: Ron Etter

Directorio: /u2/etter Shell: /bin/tcsh
Nunca inicié sesión.
Ningún plan.

4.4. Ejemplo de tipo de consulta {Q2} ({U}{H}{H}{C})

Sitio: [Link]
Línea de comando: hedrick@[Link] @[Link]<CRLF>
[[Link]]
[[Link]]
Nombre de usuario: hedrick En la vida real: Charles Hedrick
Oficina: 484 Hill, x3088

Zimmerman [Página 11]

[Link] 11/12
6/8/24, 9:48 a.m. RFC 1288: Protocolo de información del usuario Finger

RFC 1288 Dedo diciembre de 1991

Directorio: /math/u2/hedrick Shell: /bin/tcsh

Último inicio de sesión dom 24 de junio a las 00:08 en ttyp1 de [Link] No hay
correos no leídos
Ningún plan.

5. Agradecimientos

Gracias a todos los miembros del Grupo de Trabajo de Ingeniería de Internet por sus
comentarios. Un agradecimiento especial a Steve Crocker por sus recomendaciones de
seguridad y su prosa.

6. Consideraciones de seguridad

Las cuestiones de seguridad se analizan en la Sección 3.

7. Dirección del autor

David Paul Zimmerman

Centro de Matemáticas Discretas e
Informática Teórica (DIMACS) Universidad de
Rutgers
Apartado postal 1179
Piscataway, Nueva Jersey 08855-1179

Teléfono: (908)932-4592

Correo electrónico: dpz@[Link]

Zimmerman [Pagina 12]

[Link] 12/12